Class: Service_intent_or_order

Description of: Service_intent_or_order

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.

Attribute definitions for: Service_intent_or_order

charge_type_cd

A code identifying someone or something other than the patient to be billed for this service.

|BLG^2^00235^Charge Type|

clarification_phone

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|

end_condition_cd

A code depicting a condition that when satisfied should end the series of service orders.

entering_device_code

Identifier of the physical device (terminal,PC) used to enter the order

Rationale: previously unmatched V2.3 field

OpenIssue:

|ORC^18^00232^Entering Device|

escort_required_indicator

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|

expected_performance_time_qty

Time expected to perform this service instance for the target.

Rationale:

OpenIssue:

filler_order_id

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|

filler_txt

intent_or_order_cd

Distinguishes an intent from an order.

Rationale: There exists reasons that require being able to distinguish the two types of instances.

join_cd

order_control_code

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|

order_control_reason_code

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|

order_effective_dttm

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|

order_group_id

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|

order_id

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|

order_placed_dttm

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|

order_quantitytiming_qt

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:

placer_order_id

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|

placer_txt

planned_patient_transport_code

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|

report_results_to_phone

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|

response_requested_cd

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|

results_status_cd

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|

service_body_site_code

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|

service_body_site_modifier_code

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|

service_body_source_code

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|

target_of_service_cd

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.

transport_arranged_indicator

indicator of whether transport arrangements are known to have been made.

Rationale: previously unmatched V2.3 field

OpenIssue:

|OBR^41^01032^Transport Arranged|

transport_arrangement_responsibility_code

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|

transport_mode_cd

A code indicating how (or whether) to transport a patient.

|OBR^30^00262^Transportation Mode|

when_to_charge_dttm

Date and time to charge for the ordered service.

Rationale: required by components of V2.3 field

OpenIssue:

|BLG^1^00234^When to Charge|

when_to_charge_text

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|

Connection definitions for: Service_intent_or_order

is_fulfilled_by (0,n) :: Service_event :: fulfills (0,1)

may_be_referred_to_in (0,n) :: Clinical_document_header :: is_related_to (0,1)

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.

is_an_instance_of (1,1) :: Master_service :: is_instantiated_as (0,n)

is_target_for (0,n) :: Service_intent_or_order_relationship :: has_as_target (1,1)

is_source_for (0,n) :: Service_intent_or_order_relationship :: has_as_source (1,1)

has_as_participant (0,n) :: Active_participation :: participates_in (0,1)

is_billed_to (0,1) :: Patient_billing_account :: is_billed_from (0,n)

Rationale: supports use of BLG segment in the ORM message

OpenIssue: Open issue: needs joint work with OO-PAFM

is_entered_at (1,1) :: Patient_service_location :: is_entry_location_for (0,n)

Rationale: previously unmatched V2.3 field

OpenIssue:

has_as_target (1,n) :: Target_participation :: is_target_of (0,1)

has_as_reason (0,n) :: Service_reason :: is_reason_for (0,1)

Rationale: Establish Service_reason as the reason for a Service_intent_or_order.