Draft Website - For Review Purposes Only

General (taken from ASTM E1238)

The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.

The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations (e.g., vital signs or physical exam). When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest X-ray, a separate order segment will usually be generated for each diagnostic study.

Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations.

In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted.

When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process.

OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.)

HL7 Attribute Table - OBR - Observation Request Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OBR
1	00237	Set ID – OBR			[0..1]	[1..4]			SI
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	00238	Universal Service Identifier	SHALL		[1..1]			0612	CWE
5	00239	Priority	SHALL NOT	W	[0..0]
6	00240	Requested Date/Time	SHALL NOT	W	[0..0]
7	00241	Observation Date/Time #	MAY True: False:	C	[1..1] [0..1]				DTM
8	00242	Observation End Date/Time #			[0..1]				DTM
9	00243	Collection Volume *		B	[0..1]				CQ
10	00244	Collector Identifier *		B	[0..*]				XCN
11	00245	Specimen Action Code *			[0..1]	[1..1]		0065 Specimen Action Code	ID
12	00246	Danger Code			[0..1]			0613	CWE
13	00247	Relevant Clinical Information		=	[0..*]		300	0916 Relevant Clinicial Information	CWE
14	00248	Specimen Received Date/Time *	SHALL NOT	W	[0..0]				DTM
15	00249	Specimen Source	SHALL NOT	W	[0..0]
16	00226	Ordering Provider	SHALL NOT	W	[0..0]
17	00250	Order Callback Phone Number			[0..2]				XTN
18	00251	Placer Field 1		=	[0..1]		199		ST
19	00252	Placer Field 2		=	[0..1]		199		ST
20	00253	Filler Field 1 +		=	[0..1]		199		ST
21	00254	Filler Field 2 +		=	[0..1]		199		ST
22	00255	Results Rpt/Status Chng – Date/Time +	MAY True: False:	C	[1..1] [0..1]				DTM
23	00256	Charge to Practice +			[0..1]				MOC
24	00257	Diagnostic Serv Sect ID			[0..1]	[2..3]		0074 Diagnostic Service Section ID	ID
25	00258	Result Status +	MAY True: False:	C	[1..1] [0..1]	[1..1]		0123 Result Status	ID
26	00259	Parent Result +			[0..1]				PRL
27	00221	Quantity/Timing	SHALL NOT	W	[0..0]
28	00260	Result Copies To	SHALL NOT	W	[0..0]
29	00261	Parent Results Observation Identifier			[0..1]				EIP
30	00262	Transportation Mode			[0..1]	[4..4]		0124 Transportation Mode	ID
31	00263	Reason for Study			[0..*]			0951	CWE
32	00264	Principal Result Interpreter +	SHALL NOT	W	[0..0]
33	00265	Assistant Result Interpreter +	SHALL NOT	W	[0..0]
34	00266	Technician +	SHALL NOT	W	[0..0]
35	00267	Transcriptionist +	SHALL NOT	W	[0..0]
36	00268	Scheduled Date/Time +			[0..1]				DTM
37	01028	Number of Sample Containers *		=	[0..1]		16		NM
38	01029	Transport Logistics of Collected Sample *			[0..*]			0614	CWE
39	01030	Collector's Comment *			[0..*]			0619	CWE
40	01031	Transport Arrangement Responsibility			[0..1]			0620	CWE
41	01032	Transport Arranged			[0..1]	[1..1]		0224 Transport Arranged	ID
42	01033	Escort Required			[0..1]	[1..1]		0225 Escort Required	ID
43	01034	Planned Patient Transport Comment			[0..*]			0621	CWE
44	00393	Procedure Code			[0..1]				CNE
45	01316	Procedure Code Modifier			[0..*]				CNE
46	01474	Placer Supplemental Service Information			[0..*]			0411 Supplemental Service Information Values	CWE
47	01475	Filler Supplemental Service Information			[0..*]			0411 Supplemental Service Information Values	CWE
48	01646	Medically Necessary Duplicate Procedure Reason	MAY True: False:	C	[1..1] [0..1]			0476	CWE
49	01647	Result Handling			[0..1]			0507 Observation Result Handling	CWE
50	02286	Parent Universal Service Identifier	SHALL NOT	W	[0..0]
51	02307	Observation Group ID			[0..1]				EI
52	02308	Parent Observation Group ID			[0..1]				EI
53	03303	Alternate Placer Order Number			[0..*]				CX
54	00222	Parent Order			[0..*]			0119 Order Control Codes	EIP
55	00816	Action Code			[0..1]	[2..2]		0206 Segment Action Code	ID

(Definition from OBR.1 in Ch. 4)

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

(Definition from OBR.1 in Ch. 7)

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

(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.

(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.

(Definition from OBR.4 in Ch. 4)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OBR.4 in Ch. 7)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OM7.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or service.

(Definition from AIS.3 in Ch. 10)

Definition: This field contains an identifier code for a service to be scheduled. This field may contain a universal service identifier describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the universal service identifier defined for the OBR segment in the Order Entry chapter (Chapter 4). This code can be based on local and/or universal codes. The use of universal codes is recommended.

(Definition from TCC.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. The alternate elements represent the test code identifier that has been assigned by the manufacturer to this particular test code. Refer to Table 0787 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from TCD.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. Refer to Table 0789 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OBR.5 in Ch. 4)

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

(Definition from OBR.5 in Ch. 7)

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

(Definition from OBR.6 in Ch. 4)

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

(Definition from OBR.6 in Ch. 7)

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

(Definition from OBR.7 in Ch. 4)

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.

(Definition from OBR.7 in Ch. 7)

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.

(Definition from OBR.8 in Ch. 4)

Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

(Definition from OBR.8 in Ch. 7)

Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

(Definition from OBR.9 in Ch. 4)

Definition: Deprecated in version 2.9 in favor of SPM-12.

(Definition from OBR.9 in Ch. 7)

Definition: Deprecated in version 2.9 in favor of SPM-12.

(Definition from OBR.10 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.

When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.

(Definition from OBR.10 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.

When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.

(Definition from OBR.11 in Ch. 4)

Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.11 in Ch. 7)

Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.12 in Ch. 4)

Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.

(Definition from OBR.12 in Ch. 7)

Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.

(Definition from OBR.13 in Ch. 4)

Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.13 in Ch. 7)

Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.14 in Ch. 4)

Attention: The OBR-14 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. See SPM in Chapter 7.

(Definition from OBR.14 in Ch. 7)

Attention: The OBR-14 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. See SPM in Chapter 7.

(Definition from SPM.18 in Ch. 7)

Definition: The specimen received date/time is the time that the specimen is received at the diagnostic service facility. The actual time that is recorded is based on how specimen receipt is managed and may correspond to the time the sample is logged in. This is fundamentally different from SPM-17 Specimen Collection date/time.

(Definition from OBR.15 in Ch. 4)

Attention: The OBR-15 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. See SPM in Chapter 7.

(Definition from OBR.15 in Ch. 7)

Attention: The OBR-15 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. See SPM in Chapter 7.

(Definition from SAC.6 in Ch. 13)

Attention: This field was deprecated and retained for backward compatibilityonly as of v2.5 and withdrawn and removed as of v2.7.

(Definition from TCC.3 in Ch. 13)

Attention: As of version 2.5 this field was deprecated and retained for backward compatibility only and withdrawn as of v2.7.

(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.

(Definition from OBR.17 in Ch. 4)

Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

(Definition from OBR.17 in Ch. 7)

Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

(Definition from OBR.18 in Ch. 4)

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

(Definition from OBR.18 in Ch. 7)

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

(Definition from OBR.19 in Ch. 4)

Definition: This field is similar to placer field #1.

(Definition from OBR.19 in Ch. 7)

Definition: This field is similar to placer field #1.

(Definition from OBR.20 in Ch. 4)

Definition: This field is definable for any use by the filler (diagnostic service).

(Definition from OBR.20 in Ch. 7)

Definition: This field is definable for any use by the filler (diagnostic service).

(Definition from OBR.21 in Ch. 4)

Definition: This field is similar to filler field #1.

(Definition from OBR.21 in Ch. 7)

Definition: This field is similar to filler field #1.

(Definition from OBR.22 in Ch. 4)

Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

(Definition from OBR.22 in Ch. 7)

Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

(Definition from OBR.23 in Ch. 4)

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

(Definition from OBR.23 in Ch. 7)

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

(Definition from OBR.24 in Ch. 4)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.24 in Ch. 7)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OM1.49 in Ch. 8)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries. Same as OBR-24.

(Definition from OBR.25 in Ch. 4)

Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.25 in Ch. 7)

Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.26 in Ch. 4)

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

(Definition from OBR.26 in Ch. 7)

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

(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.

(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.

(Definition from OBR.28 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. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".

(Definition from OBR.28 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. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".

(Definition from OBR.29 in Ch. 4)

Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.

(Definition from OBR.29 in Ch. 7)

Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.

(Definition from OBR.30 in Ch. 4)

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.30 in Ch. 7)

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.31 in Ch. 4)

Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.

(Definition from OBR.31 in Ch. 7)

Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.

(Definition from OBR.32 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.6 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.32 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.6 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.33 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.33 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.34 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.34 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.35 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.35 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.36 in Ch. 4)

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).

(Definition from OBR.36 in Ch. 7)

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).

(Definition from OBR.37 in Ch. 4)

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

(Definition from OBR.37 in Ch. 7)

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

(Definition from OBR.38 in Ch. 4)

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.

(Definition from OBR.38 in Ch. 7)

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.

(Definition from OBR.39 in Ch. 4)

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.

(Definition from OBR.39 in Ch. 7)

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.

(Definition from OBR.40 in Ch. 4)

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.

(Definition from OBR.40 in Ch. 7)

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.

(Definition from OBR.41 in Ch. 4)

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.41 in Ch. 7)

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.42 in Ch. 4)

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.42 in Ch. 7)

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.43 in Ch. 4)

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.

(Definition from OBR.43 in Ch. 7)

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.

(Definition from OBR.44 in Ch. 4)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.25 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems (from HL7 Table 0396)

Code	Description	Comment / Source
C4	CPT-4	American Medical Association, P.O. Box 10946, Chicago IL 60610.
C5	CPT-5	(under development – same contact as above)
HCPCS	CMS (formerly HCFA) Common Procedure Coding System	HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.
HPC	CMS (formerly HCFA )Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.
I10P	ICD-10 Procedure Codes	Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.

(Definition from PR1.3 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

(Definition from OBR.44 in Ch. 7)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from CDM.7 in Ch. 8)

Definition: This field contains the procedure code for procedure, if any, associated with this charge description. Repeating field allows for different procedure coding systems such as CPT4, ICD9. Coded entry made up of code plus coding schema. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values.

(Definition from IIM.14 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally Defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems

Coding System	Description	Comment
C4	CPT-4	American Medical Association, P.O. Box 10946, Chicago IL 60610.
C5	CPT-5	(under development – same contact as above)
HCPCS	CMS (formerly HCFA) Common Procedure Coding System	HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.
HPC	CMS (formerly HCFA) Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.

(Definition from ITM.27 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally defined Table 0088 - Procedure code for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems. Refer to HL7 Table 0088 – Procedure Coding Systems in Chapter 2C, Code Tables, for valid values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from SCD.32 in Ch. 17)

Definition: The unique identifier indicating the type of procedure performed on the patient with the supplies being sterilized.

Refer to HL7 Table 0088 – Procedure Code in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the referenced table. If the code set you are using is in this table, then you must use that designation.

(Definition from OBR.45 in Ch. 4)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.26 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in FT1-25 - Procedure Code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if FT1-25 - Procedure Code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Modifier Coding Systems (From HL7 Table 0396)

Code	Description	Comment / Source
CPTM	CPT Modifier Code	Available for the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL).
HPC	CMS (formerly HCFA )Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.
I10P	ICD-10 Procedure Codes	Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.
I9C	ICD-9CM	Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105 (includes all procedures and diagnostic tests).
ICD10AM	ICD-10 Australian modification
ICD10CA	ICD-10 Canada

(Definition from PR1.16 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in field 3, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.45 in Ch. 7)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from IIM.15 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in IIM-14 Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from ITM.28 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in ITM-27, Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.46 in Ch. 4)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.46 in Ch. 7)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.11 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the placer system to the filler system for the universal procedure code reported in field AIS-3. This field will be used to provide scheduling information detail that is not available in other, specific fields in the AIS segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 – Supplemental Service Information Values in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.47 in Ch. 4)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.47 in Ch. 7)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.12 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the filler system to the placer system for the procedure code reported in field AIS-3. This field will be used to report scheduling information details that is not available in other, specific fields in the AIS segment. Typically it will reflect the same information as was sent to the filler system in AIS-11-Placer Supplemental information unless the scheduling was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables, for valid values..

(Definition from OBR.48 in Ch. 4)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.28 in Ch. 6)

Definition: This field is used to document why the procedure found in FT1-25 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry. This field is intended to provide financial systems information on who to bill for duplicate procedures. Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.48 in Ch. 7)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.49 in Ch. 4)

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.

(Definition from OBR.49 in Ch. 7)

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.

(Definition from OBR.50 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.

(Definition from OBR.50 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.

(Definition from OBR.51 in Ch. 4)

Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.

(Definition from OBR.51 in Ch. 7)

Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.

(Definition from OBR.52 in Ch. 4)

Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.

(Definition from OBR.52 in Ch. 7)

Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.

(Definition from OBR.53 in Ch. 4)

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

(Definition from OBR.53 in Ch. 7)

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

(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.

(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.