The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

ORC - Common Order Segment

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested).

There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections.

HL7 Attribute Table - ORC - Common Order Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
ORC
1 00215 Order Control SHALL [1..1] [2..2] ID
2

00216 Placer Order Number MAY
True:
False:
C
[1..1]
[0..1]
EI
3

00217 Filler Order Number MAY
True:
False:
C
[1..1]
[0..1]
EI
4 00218 Placer Order Group Number [0..1] EI
5 00219 Order Status [0..1] [1..2] ID
6 00220 Response Flag [0..1] [1..1] ID
7 00221 Quantity/Timing SHALL NOT W [0..0]
8 00222 Parent Order [0..*] EIP
9 00223 Date/Time of Order Event [0..1] DTM
10 00224 Entered By SHALL NOT W [0..0] XCN
11 00225 Verified By SHALL NOT W [0..0]
12 00226 Ordering Provider SHALL NOT W [0..0]
13 00227 Enterer's Location [0..1] PL
14 00228 Call Back Phone Number [0..2] XTN
15 00229 Order Effective Date/Time [0..1] DTM
16 00230 Order Control Code Reason [0..1] CWE
17 00231 Entering Organization SHALL NOT W [0..0]
18 00232 Entering Device SHALL NOT W [0..0]
19 00233 Action By SHALL NOT W [0..0]
20 01310 Advanced Beneficiary Notice Code [0..1] CWE
21 01311 Ordering Facility Name SHALL NOT W [0..0]
22 01312 Ordering Facility Address SHALL NOT W [0..0]
23 01313 Ordering Facility Phone Number SHALL NOT W [0..0]
24 01314 Ordering Provider Address SHALL NOT W [0..0]
25 01473 Order Status Modifier [0..1] CWE
26

01641 Advanced Beneficiary Notice Override Reason MAY
True:
False:
C
[1..1]
[0..1]
CWE
27 01642 Filler's Expected Availability Date/Time [0..1] DTM
28 00615 Confidentiality Code [0..1] CWE
29 01643 Order Type [0..1] CWE
30 01644 Enterer Authorization Mode [0..1] CNE
31 02287 Parent Universal Service Identifier SHALL NOT W [0..0]
32 02301 Advanced Beneficiary Notice Date [0..1] DT
33 03300 Alternate Placer Order Number [0..*] CX
34 03387 Order Workflow Profile [0..*] CWE
35 00816 Action Code [0..1] [2..2] ID
36 03509 Order Status Date Range [0..1] DR
37 03515 Order Creation Date/Time [0..1] DTM
38 02482 Filler Order Group Number [0..1] EI

ORC use notes

  1. placer order groups

The Standard supports a mechanism to collect several orders together in a group. Most often this is used to represent an "ordering session" for a single patient. A common use case is the grouping of laboratory batteries and tests ordered together by a physician for a patient with a common diagnostic goal (e.g. preoperative blood testing, diabetes follow-up, …).

An order group is a list of orders (ORCs) associated with an ORC-4-placer group number. A group is established when the placer supplies a placer group number with the original order or when the filler accessions the order group and supplies a filler group number with the received order. The order group may be identified by the placer or by the filler or by both applications. The order group consists of all the ORCs and order detail segments that have the same placer group number, or using the assign number/number assigned mechanism. Orders can be removed from the group using cancel, or added using the replacement or parent-child mechanisms. New orders cannot otherwise be added to the group.

  1. duplicate fields

The ORC is intended to uniformly define the fields that are common to all orders (i.e., requested services). Some ORC fields are duplicated in some order detail segments (e.g., OBR, RXO). For example, ORC-2-placer order number has the same meaning and purpose as OBR-2-placer order number field. This promotes upward compatibility with past versions and ASTM.

The rule for using these fields is that the value must appear in the order detail segment if it does not appear in the ORC. However, it is recommended to transmit the field value in both places to avoid confusion.

  1. parent/child – cancel, hold, discontinue

During transmission of a request to cancel, hold, or discontinue a parent order, the request is intended to apply recursively to the parent order and all associated child orders.

For example:

  1. An EKG application receives an order for three EKGs on successive mornings.

  2. The EKG application creates three child orders, one for each requested EKG..

  3. The first daily EKG has already been performed when a request is received to cancel the original parent order. (The parent is beyond the point of cancellation.)

  4. The remaining, unperformed, children are canceled as a result of the request.

  5. Date/Time Use Notes:

  6. Various dates are available in ORC that seem overlapping, but serve distinct purposes. The following provides use notes on these relationships, while the individual field definitions provide further details.

  7. ORC-7 Quantity/Timing - This field was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 – Timing/Quantity and TQ2 – Timing/Quantity Relationship segments described in sections 4.5.4 and 4.5.5, respectively. The purpose of this field (and now these segments) is to capture Priority, Frequency, and Timing of the service being ordered. For example, an order for a unit of blood to be administered to a patient every morning for 3 days..

  8. ORC-9 Date/Time of Order Event – This field is the date/time when the action indicated in ORC-1 was initiated. Every time a new action, as indicated by ORC-1, occurs the date/time of that action should appear in ORC-9. This field is not equivalent to MSH-7 Date and Time of Message, which reflects the date/time of message generation.

  9. ORC-15 Order Effective Date/Time – The field focuses on when the information communicated is to take effect. It is most appropriate when used on an order that is by nature a “continuing” (or continuous) order. This field has a close relationship to ORC-9 and the TQ1, TQ2 segments in so much as the value in ORC-15 takes precedence over both. For example, an order is placed on June 1, for an activity that is to be performed over ten days as indicated in the TQ1 segment. The Filler then receives a cancel message on June 2 with the ORC-9 value of June 2, but the ORC-15 Order Effective Date/Time indicated the cancel is to be effective on June 7th. ORC-15 by taking precedence over TQ1 and ORC-9, would tell the Filler to continue to perform the order event until June 7, and cancel all remaining events (treatment, procedures etc.) after that time.

  10. ORC-27 Filler’s Expected Availability Date/Time – This field focuses on when the filler expects to complete the order, e.g., have the results available, the prescription ready, etc. This is a Filler assigned field and would typically only be sent from Filler to Placer on either application level acknowledgments or order status messages. (Could be delivered with result messag but would have little relevance at that time.)

  11. ORC-32 Advanced Beneficiary Notice Date – This field contains the date the patient gave consent to pay for potentially uninsured services or the date that the Advanced Beneficiary Notice Code (ORC-20) was collected.

  12. ORC-36 Order Status Range – This field is a Filler assigned date/time indicating a date range that the ORC-5 Order Status is intended to be effective. For example, if the Filler recommends an alternate test, and sets the ORC-5 status to “Hold”, this date/time reflects how long the Filler will keep the order in that status (barring additional communications from the Placer or Filler in regard to this order.)

  13. ORC-37 Order Creation Date/Time – focuses on the date that the order was originally created; whether as an electronic order or as an initial paper requisition. This date/time is designed to preserve the creation date/time from initial order to final result, and for all stages in-between. (Acknowledgments, Updates, Cancels, etc.)

ORC-1: Order Control (ID) 00215

Definition: Determines the function of the order segment. Refer to HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, for valid entries. Depending on the message, the action of the control code may refer to an order or an individual service. For example, the code CA in an OMP message cancels the order. The same code in an RDS message, cancels the dispense. Very detailed explanatory notes are given at the end of this section.

This field may be considered the "trigger event" identifier for orders. The codes fall roughly into the following three categories:

  1. event request – Codes like "NW" (new order) and "CA" (cancel order request) are used to initiate an event .

  2. event acknowledgment – Codes like "OK" (order accepted) and "CR" (canceled as requested) are used to reply to the event request .

  3. event notification – Codes like "OC" (order canceled) and "OD" (order discontinued) are used to notify other applications that an event has occurred. No application reply is necessary.

Event request codes are intended to initiate an event. Event acknowledgment codes are intended to reply to an application that requested an event. Event notification codes are intended to notify another application that, e.g., the filler has performed some action on an order that the other application, e.g., the placer, needs to know.

Fillers, placers, and other applications can use event requests, event acknowledgments, and event – notification-type trigger events interchangeably. However, certain order control codes can originate only from the filler (e.g., CR) and others can only originate from the placer (e.g., CA).

Refer HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables.

ORC-2: Placer Order Number (EI) 00216

(Definition from ORC.2 in Ch. 4)

Definition: This field is the placer application's order number.

This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

There are three situations in which the true placer is somewhat arbitrary (and thus not unique):

  1. in ORC-1-order control value of RO, following an RU replacement;

  2. in ORC-1-order control value of CH (child orders); and

  3. in ORC-1-order control value of SN (send number).

See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.

The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from OBR.2 in Ch. 4)

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from OBR.2 in Ch. 7)

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from TXA.14 in Ch. 9)

Definition: This field is the placer application's order number.

This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters.

TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.

(Definition from ARQ.24 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.

(Definition from SCH.26 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.

This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.

ORC-3: Filler Order Number (EI) 00217

(Definition from ORC.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from OBR.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from FT1.23 in Ch. 6)

Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.

(Definition from OBR.3 in Ch. 7)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from TXA.15 in Ch. 9)

Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.

The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.

TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

For further details, please see the definitions provided in Chapter 4, "Orders".

(Definition from ARQ.25 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.

(Definition from SCH.27 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.

This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.

ORC-4: Placer Order Group Number (EI) 00218

(Definition from ORC.4 in Ch. 4)

Definition: This field contains a unique identifier for an Order Group as referenced by the Placer application. An Order Group is a set of orders grouped together by the placer application.

The first component is a string that uniquely identifies all order groups from the placer application. A limit of fifteen (15) characters is suggested but not required.

The second through fourth components constitute a placer or filler application ID identical to the analogous components of ORC-3-filler order number . Order groups and how to use them are described in detail in Section 4.5.1, "ORC – Common Order Segment."

(Definition from ARQ.4 in Ch. 10)

Definition: This field contains a unique identifier for the Placer Group as referenced by the Placer application. A Placer Order Group is a set of appointments grouped together by the placer application, and subsequently identified by the placer application.

The second through fourth components contain the assigning authority identifying information.

(Definition from SCH.4 in Ch. 10)

Definition: This field contains a unique identifier for the Placer Group as referenced by the Placer application, the Filler application, or both. A Placer Group is a set of appointments grouped together by the placer application, and subsequently identified by the placer application and/or by the filler application.

Within each of the two subcomponents, the first component is a string that identifies a group of appointment requests. It is assigned by the Placer or Filler application, and it identifies an appointment group uniquely among all such groups of requests from a particular requesting application.

ORC-5: Order Status (ID) 00219

Definition: This field specifies the status of an order. Refer to HL7 Table 0038 – Order status in Chapter 2C, Code Tables, for valid entries. The purpose of this field is to report the status of an order either upon request (solicited), or when the status changes (unsolicited). It does not initiate action. It is assumed that the order status always reflects the status as it is known to the sending application at the time that the message is sent. Only the filler can originate the value of this field.

Although HL7 Table 0038 – Order status contains many of the same values contained in HL7 Table 0119 – Order control codes and their meaning, its purpose is different. Order status may typically be used in a message with an ORC-1-order control value of SR or SC to report the status of the order on request or to any interested party at any time.

ORC-6: Response Flag (ID) 00220

Definition: This field allows the placer (sending) application to determine the amount of information to be returned from the filler. Sometimes the requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send the information. When the field is null, D is the default value of the field. Refer to HL7 Table 0121 – Response flag in Chapter 2C, Code Tables, for valid entries.

ORC-7: Quantity/Timing

(Definition from ORC.7 in Ch. 4)

Attention: The ORC-7 field was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5, respectively.

(Definition from OBR.27 in Ch. 4)

Attention: The OBR-27 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from RXE.1 in Ch. 4A)

Attention: The RXE-1 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from RXG.3 in Ch. 4A)

Attention: The RXG-3 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).


(Definition from OBR.27 in Ch. 7)

Attention: The OBR-27 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

ORC-8: Parent Order (EIP) 00222

(Definition from ORC.8 in Ch. 4)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 under order control code PA. This field uniquely identifies the parent order; no other information is required to link the child order with its parent order. It can be used to link the order to the results that triggered this order (e.g., a reflex order) or other order it relates to as an occurrence. This field repeats to allow linking to more than one parent, if necessary.

The first component has the same format as ORC-2-Placer Order Number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-Filler Order Number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54 – Parent Order, but neither one is the same as OBR-29 – Result Observation Identifier.

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 Must carry the same value.

(Definition from OBR.54 in Ch. 4)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.

The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.

(Definition from OBR.54 in Ch. 7)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.

The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.

ORC-9: Date/Time of Order Event (DTM) 00223

Definition: This field contains the date and time of the event that initiated the current transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 Date and Time of Message, which reflects the date/time of message generation.

Examples: When ORC-1 is “NW” this date represents the date/time when the order was placed by the ordering provider; when ORC-1 is "CA" this date represents the date/time when request for a cancellation was made by the placer, while for a "CR" this date represents the date/time when the cancellation was accepted by the filler (e.g., the change request was applied). When an ORC is included in an ORU message and ORC-1 is "RE", then the date represents the date/time when the observation(s) on the transaction were made available by the source system.

ORC-10: Entered By

(Definition from NTE.5 in Ch. 2)

Definition: This field contains the identity of the person who actually keyed the comment into the application. It provides an audit trail in case the comment is entered incorrectly and the ancillary department needs to clarify the comment. By local agreement, either the ID number or name component MAY be omitted.

(Definition from ORC.10 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

(Definition from ACC.7 in Ch. 6)

Definition: This field identifies the person entering the accident information.

(Definition from MFE.7 in Ch. 8)

Definition: This field contains the identity of the person who actually keyed the master file entry into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.

(Definition from OM7.20 in Ch. 8)

Note: This field is deprecated and retained for backward compatibility as of v 2.8.

Definition: This field contains the identity of the person who actually keyed the service item into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.

ORC-11: Verified By

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-12: Ordering Provider

(Definition from ORC.12 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

(Definition from OBR.16 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.

(Definition from OBR.16 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.

ORC-13: Enterer's Location (PL) 00227

Definition: This field specifies the location (e.g., nurse station, ancillary service location, clinic, floor) where the person who entered the request was physically located when the order was entered. Note that this refers to the current transaction as reflected in ORC-1 Order Control Code. Only those subcomponents relevant to enterer's location should be valued (commonly, nursing unit; facility; building; floor). The person who entered the request is defined in ORC-10-entered by.

ORC-14: Call Back Phone Number (XTN) 00228

Definition: This field contains the telephone number to call for clarification of a request or other information regarding the order. ORC-14-call back phone number is the same as OBR-17-order callback phone number.

ORC-15: Order Effective Date/Time (DTM) 00229

Definition: This field focuses on when the information communicated is to take effect. It is most appropriate when used on an order that is by nature a “continuing” (or continuous) order. This field has a close relationship to ORC-9 and the TQ1, TQ2 segments in so much as the value in ORC-15 takes precedence over both. For example, an order is placed on June 1, for an activity that is to be performed over ten days as indicated in the TQ1 segment. The Filler then receives a cancel message on June 2 with the ORC-9 value of June 2, but the ORC-15 Order Effective Date/Time indicated the cancel is to be effective on June 7th. ORC-15 by taking precedence over TQ1 and ORC-9, would tell the Filler to continue to perform the order event until June 7, and cancel all remaining events (treatment, procedures etc..) after that time. If the order identified in the ORC has children, the children which have not started should be canceled; if there is a child in process, it should be discontinued; if a child has progressed beyond the point where it can be discontinued, its status is unaffected.

ORC-16: Order Control Code Reason (CWE) 00230

Definition: This field contains the explanation (either in coded or text form) of the reason for the order event described by the order control code (HL7 Table 0119 - Order control codes). Whereas an NTE after the order-specific segment (e.g., RXO, ORO, OBR) would provide a comment for that specific segment, the purpose of the order control code reason is only to expand on the reason for the order event.

ORC-16-order control code reason is typically not valued when ORC-1-order control is NW, although it could be. In the case of a canceled order, for example, this field is commonly used to explain the cancellation. A Pharmacy system that canceled a drug order from a physician because of a well-documented allergy would likely report the fact of the allergy in this field.

If it canceled the order because of a drug interaction this field might contain at least the names (and codes, if needed) of the interacting substances, the text describing the interaction, and the level of severity of the interaction.

Refer HL7 Table 0949 – Order Control Code Reason in Chapter 2C, Code Tables.

ORC-17: Entering Organization

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7. Refer to Table 0666 - Entering Organization in Chapter 2C for valid values.

ORC-18: Entering Device

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7. Refer to Table 0668 - Entering Device in Chapter 2C for valid values.

ORC-19: Action By

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-20: Advanced Beneficiary Notice Code (CWE) 01310

(Definition from ORC.20 in Ch. 4)

Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. The values for this field are drawn from User-Defined Table 0339 – Advanced Beneficiary Notice Code in Chapter 2C, Code Tables.

(Definition from FT1.27 in Ch. 6)

Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. Refer to User-defined Table 0339 - Advanced Beneficiary Notice Code in Chapter 2C, Code Tables, for suggested values.

ORC-21: Ordering Facility Name

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-22: Ordering Facility Address

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-23: Ordering Facility Phone Number

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-24: Ordering Provider Address

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

ORC-25: Order Status Modifier (CWE) 01473

Definition: This field is a modifier or refiner of the ORC-5-Order status field. This field may be used to provide additional levels of specificity or additional information for the defined order status codes. Unlike the Order Status field, which is controlled by an HL7 defined table, this field is a CE data type allowing applications to support an unlimited library of Order Status Modifier codes.

Usage Rule: This field may only be populated if the ORC-5-Order Status field is valued.

Examples: An LIS processing an order with an order status of IP may send an update using the order status modifier to indicate the progress of the order through the laboratory or to indicate that the order has been sent to an external laboratory. Another example using the non-medical orders would be a case in which a phone has been ordered delivered to a patient's room but has been disconnected temporarily. The ORC-5-Order status indicates IP and the ORC-25-Order status modifier would indicate a disconnected status. A third example involves pharmacy dispenses. It is sometimes not enough to know that a prescription is being dispensed. The ORC-25-Order status modifier would indicate if a label had been printed, the prescription filled, or the prescription sold.

Refer HL7 Table 0950 – Order Status Modifier in Chapter 2C, Code Tables.

ORC-26: Advanced Beneficiary Notice Override Reason (CWE) 01641

Definition: This field contains the reason why the patient did not sign an Advanced Beneficiary Notice. The reason may be coded or it may be a free text entry. Refer to HL7 Table 0552 – Advanced beneficiary notice override reason in Chapter 2C, Code Tables.

Condition: This field is required if the value of ORC-20 Advanced Beneficiary Notice Code indicates that the notice was not signed. For example, additional qualifying or explanatory information would be justified if ORC-20 was populated with the values "3" or "4" in User-defined Table 0339 – Advanced Beneficiary Notice Code, or similar values in related external code tables.

ORC-27: Filler's Expected Availability Date/Time (DTM) 01642

Definition: This field specifies the date/time the Filler expects to complete the order, e.g., have the results available, the prescription ready, etc. This is a Filler assigned field and would typically only be sent from Filler to Placer on either application level acknowledgments or order status messages. (Could be delivered with result message, but would have little relevance at that time.)

ORC-28: Confidentiality Code (CWE) 00615

(Definition from ORC.28 in Ch. 4)

Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 – Confidentiality Code in Chapter 2C, Code Tables, for allowed values. The specific treatment of data with a particular confidentiality level is subject to site-specific negotiation.

(Definition from OM1.30 in Ch. 8)

Definition: This field contains the degree to which special confidentiality protection should be applied to the observation. For example, a tighter control may be applied to an HIV test than to a CBC. Refer to User-defined Table 0177 - Confidentiality Code in Chapter 2C, Code Tables, for suggested values.

ORC-29: Order Type (CWE) 01643

Definition: This field indicates whether the order is to be executed in an inpatient setting or an outpatient setting. If this field is not valued, the system default is assumed. Refer to HL7 Table 0482 – Order Type in Chapter 2C, Code Tables, for suggested values.

Examples: Before discharge an order is placed for follow-up physical therapy, or to pick up a prescription at a community pharmacy. The patient is an inpatient according to PV1, but the order is an outpatient order.

ORC-30: Enterer Authorization Mode (CNE) 01644

Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. Refer to HL7 Table 0483 - Authorization Mode in Chapter 2C, Code Tables, for suggested values.

ORC-31: Parent Universal Service Identifier

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9.

ORC-32: Advanced Beneficiary Notice Date (DT) 02301

Definition: This field contains the date the patient gave consent to pay for potentially uninsured services or the date that the Advanced Beneficiary Notice Code (ORC-20) was collected.

ORC-33: Alternate Placer Order Number (CX) 03300

Definition: This field enables a shorter number to be communicated that is unique within other identifiers.

ORC-34: Order Workflow Profile (CWE) 03387

The Order Workflow Profile references/represents the information necessary to define the workflow variant when that is not fully described through the use of ORC-1 Order Control and MSH-21 Message Profile. This enables contributing systems to apply locally agreed to rules. See User-defined Table 0934 - Order Workflow Profile for a list of suggested values.

ORC-35: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

ORC-36: Order Status Date Range (DR) 03509

Definition: This field is a Filler assigned date/time indicating a date range that the ORC-5 Order Status is intended to be effective. For example, if the Filler recommends an alternate test, and sets the ORC-5 status to “Hold”, this date/time reflects how long the Filler will keep the order in that status (Barring additional communications from the Placer or Filler in regard to this order.) When the date is outside the specified order status date range, ORC-5 (Order Status) should be considered an unspecified status, i.e., the status represented in ORC-5 would not necessarily be reflective of the actual status anymore.

ORC-37: Order Creation Date/Time (DTM) 03515

Definition: This field represents the official date/time when the order was originally created; whether as an electronic order or as an initial paper requisition. This may also be known as Prescription Date/Time. This date/time is designed to preserve the creation date/time from initial order to final result, and for all stages in-between. (Acknowledgments, Updates, Cancels, Results etc.). When ORC-1 Order Control Code is “NW” for a new order, this date/time, if valued, is typically expected to be the same as ORC-9 Date/Time of Order Event. An example where the ORC-37, Order Creation Date/Time, is not the same as ORC-9, Date/Time of Order Event, while ORC-1, Order Control Code, is “NW” is when the order originally was recorded and signed by a physician on paper (ORC-37), but not entered in a system until some time (ORC-9) thereafter.

As different date/times can be considered the initiation of the order (the first person entering it or a subsequent step), or data is not available (e.g., a paper request without a date/time when it was created), the system where the order was first documented determines which date/time it reflects according to the organization's policies and would represent that in ORC-37.
When an order is resulted (ORC-1 = “RE”) the value in ORC-37 does not change from the value supplied in the original order.

ORC-38: Filler Order Group Number (EI) 02482

Definition: This field contains a unique identifier for the Order Group as referenced by the Filler application. An Order Group is a set of orders grouped together by the placer application.

The first component is a string that uniquely identifies all order groups from the filler application. A limit of fifteen (15) characters is suggested but not required.

The second through fourth components constitute a filler application ID identical to the analogous components of ORC-3-filler order number . Order groups and how to use them are described in detail in Section 4.5.1, "ORC – Common Order Segment."