Class steward is Orders/Observation
The instantiation of the intent or request to perform a particular service as represented in Master_service particular date for a particular patient by a particular provider.
Rationale: This class adds the ability to attach context information and modify default values as a plan for a particular target of service that is to receive a service itemized in the Master_service catalog.
OpenIssue: This name does not conform to the style guide.
Note: An additional attribute to identify each instance of this class is either an order or an intent must be added to this proposal. Both PC and OO agree to the additional attribute. See U004.21.
A code identifying someone or something other than the patient to be billed for this service.
|BLG^2^00235^Charge Type|
Telephone number to call for clarification of request or other information regarding the order
Rationale: previously unmatched V2.3 field
OpenIssue:
|ORC^14^00228^Call Back Phone Number|
A code depicting a condition that when satisfied should end the series of service orders.
Identifier of the physical device (terminal,PC) used to enter the order
Rationale: previously unmatched V2.3 field
OpenIssue:
|ORC^18^00232^Entering Device|
an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements is captured in another attribute.
Rationale: previously unmatched V2.3 field
OpenIssue:
|OBR^42^01033^Escort Required|
Time expected to perform this service instance for the target.
Rationale:
OpenIssue:
This attribute must use the EI datatype in all messages.
Rationale: these are alternate keys to the class
OpenIssue:
|FT1^23^00217^Filler Order Number| |OBR^3^00217^Filler Order Number| |ORC^3^00217^Filler Order Number| |TXA^15^00217^Filler Order Number|
Distinguishes an intent from an order.
Rationale: There exists reasons that require being able to distinguish the two types of instances.
A code indicating the status of the patient service order.
Rationale: ORC/Order Control and OBR/Order Status need separate representation in the RIM. This RIM08 attribute was selected to represent the ORC field, and renamed accordingly.
OpenIssue: should this name remain "status", or should the description be changed?
|ORC^1^00215^Order Control|
Explanation (either in coded or text form) of the reason for the order event.
Rationale: previously unmatched V2.3 field
OpenIssue:
|ORC^16^00230^Order Control Code Reason|
Date/time that the changes to the order took effect or are supposed to take effect
Rationale: previously unmatched V2.3 field
OpenIssue:
|ORC^15^00229^Order Effective Date/Time|
A composite identifier of a service order. Including the order id and the ordering application. Allows an order placing application to group sets of orders together and subsequently identify them. This attribute must use the EI datatype in all messages.
Rationale: previously unmatched V2.3 field
|ARQ^4^00218^Placer Group Number| |ORC^4^00218^Placer Group Number| |SCH^4^00218^Placer Group Number|
A unique identifier for the patient service order.
|FT1^23^00217^Filler Order Number| |OBR^2^00216^Placer Order Number| |OBR^3^00217^Filler Order Number| |ORC^2^00216^Placer Order Number| |ORC^3^00217^Filler Order Number| |TXA^14^00216^Placer Order Number| |TXA^15^00217^Filler Order Number|
The date and time the order was placed.
Rationale: To provide date-time precision required for representing pathways.
|ORC^9^00223^Date/Time of Transaction|
A means of specifying when the service described by the order segment is to be performed and how frequently. It is a complex multicomponent field that can have repeats. If a specimen is required for the order, the Priority component contains specimen collection priority rather than processing priority)
Rationale:
OpenIssue:
This attribute must use the EI datatype in all messages.
Rationale: these are alternate keys to the class. renamed to match definition
OpenIssue:
|OBR^2^00216^Placer Order Number| |ORC^2^00216^Placer Order Number| |TXA^14^00216^Placer Order Number|
code or free text comments on special requirements for the transport of the patient to the diagnostic service department
Rationale: previously unmatched V2.3 field
OpenIssue:
|OBR^43^01034^Planned Patient Transport Comment|
A phone number to be used to report results from the service order.
Rationale: to differentiate this attribute from ORC/Call Back phone number, which has a different meaning both from this attribute, and from this attribute's related V2.3 field: OBR/ order callback phone.
|OBR^17^00250^Order Callback Phone Number| |ORC^14^00228^Call Back Phone Number|
A code used to allow the placer application to determine the amount of information to be returned from the filler.
|ORC^6^00220^Response Flag|
Status of results for this intent or order.
Rationale: alignment with V2.3 name. missing definition in RIM08. This attribute represents the overall status of all observations for the request. Since each service event represents only a single observation, the status of all observations for an intent or order must be represented in the intent or order itself.
OpenIssue:
|OBR^25^00258^Result Status|
Body site where service is to be performed. Example sites are ears, arm, eye.
Rationale: previously unmatched usage for V2.3 field
OpenIssue:
|OBR^15^00249^Specimen Source|
Site modifier describing the site where the service should be performed. For example, the site could be anticubital foss, and the site modifier "right."
Rationale: previously unmatched usage for V2.3 field
OpenIssue:
|OBR^15^00249^Specimen Source|
Source name or code describing the site where the service should be performed. Example coded values are abscess, blood arterial, blood bag, burn, dose med or blood, ear, filter, gastric fluid, marrow, patient, tissue, urine
Rationale: previously unmatched usage for V2.3 field
OpenIssue: need to make the description a little bit clearer.
|OBR^26^00259^Parent Result|
Object which is target of the service
Rationale: This is not necessarily the patient.
OpenIssue: In order to make this consistent, Orders must move Processing_time and Typical_turnaround_time from the Master_observation_service to this class.
indicator of whether transport arrangements are known to have been made.
Rationale: previously unmatched V2.3 field
OpenIssue:
|OBR^41^01032^Transport Arranged|
An indicator of who is responsible for arranging transport of the patient to the planned diagnostic service. Examples: Requester, Provider, Patient
Rationale: previously unmatched V2.3 field
OpenIssue:
|OBR^40^01031^Transport Arrangement Responsibility|
A code indicating how (or whether) to transport a patient.
|OBR^30^00262^Transportation Mode|
Date and time to charge for the ordered service.
Rationale: required by components of V2.3 field
OpenIssue:
|BLG^1^00234^When to Charge|
A code determining the timing of billing the charges associated with the order service item.
Rationale: alignment with V2.3 component datatype
|BLG^1^00234^When to Charge|
Rationale:
OpenIssue: If we have the linkage between patient service event and healthcare chart document header right, this might not be needed as it duplicates existing connections. This is pending joint work between Information Management, Orders/Observations, and Patient Care committees.
Rationale: Establish Service_reason as the reason for a Service_intent_or_order.
Rationale: supports use of BLG segment in the ORM message
OpenIssue: Open issue: needs joint work with OO-PAFM
Rationale: previously unmatched V2.3 field
OpenIssue: