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

16.3.380 ORU - Unsolicited Observation Message (Event R01) (7.3.1)

The ORU message is for transmitting observational results, including lab, clinical or other observations, to other systems.. The OUL message is designed to accommodate the laboratory processes of laboratory automation systems.

With the segment (OBX) defined in this chapter, and the OBR defined in Chapter 4, one can construct almost any clinical report as a multi-level hierarchy, with the PID segment defined in Chapter 3 at the upper level, an order record (OBR) at the next level with one or more observation records (OBX), followed by the specimen information (SPM) and one or more observations (OBX) directly associated with the specimen.

One result segment (OBX) is transmitted for each component of a diagnostic report, such as an EKG or obstetrical ultrasound or electrolyte battery.

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

Segment Cardinality Must Implement Status
ORU^R01^ORU_R01
MSH 1..1 Yes
SFT  
PATIENT_RESULT 1..* Yes
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
NTE  
NK1  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
ORDER_OBSERVATION 1..* Yes
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
ORDER_DOCUMENT 0..1  
OBX 1..1 Yes
PRT  
TXA 1..1 Yes
OBR 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
CTD 0..1  
OBSERVATION  
OBX 1..1 Yes
PRT  
NTE  
FT1  
CTI  
SPECIMEN  
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
DSC 0..1  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
ACK^R01^ACK
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  

 

We need some ER7 examples...
We need some XML examples...
Note: The ORC is permitted but not required in this message. Any information that could be included in either the ORC or the OBR must be included in the OBR on reporting. Notice also that the ORU (and the QRY) messages accommodate reports about many patients.

Many report headers (OBR) may be sent beneath each patient segment, with many separate observation segments (OBX) related to the order / observation request beneath each OBR. OBX segments that are related to specimens immediately follow the SPM segments. Note segments (NTE) may be inserted at different locations in the message. The note segment applies to the entity that immediately precedes it, i.e., the patient if it follows the PID segment, the observation request if it follows the OBR segment, and the individual result if it follows the OBX segment.

16.3.381 OUL - Unsolicited Laboratory Observation Message (Event R21) (7.3.2)

Attention: Retained for backwards compatibility only as of v 2.5 and withdrawn as of v 2.7.  

16.3.382 QRY/ORF - Query for Results of Observation (Events R02, R04) (7.3.3)

Attention: Retained for backwards compatibility only as of v 2. .and withdrawn as of v 2.7.

16.3.383 ORU - Unsolicited Point-Of-Care Observation Message without Existing Order - Place an Order (Event R30) (7.3.4)

This event trigger instructs the receiving system to create a new order for the observation(s) contained in the message.

One example of this trigger's use case occurs when a Doctor verbally instructs a nurse to perform a test. Looking at this use case from an information management perspective, one might expect that, the nurse would enter an order into laboratory information or ordering system before performing the test. However, there usually isn't time for order entry in these use cases. In fact, it is highly desirable for the POC measurement process to become automated so that the only action a user needs to take is to make a measurement on the POC Device, with all other processes for generating an order and tying it in to the observation handled by the "machines."

In order to allow for the passing of specific information relating to the Patient, responsible Doctor, placing doctor, patient location, etc., there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type. One example of this trigger's use case occurs when a Doctor at a remote site without a shared Patient index instructs a nurse to perform a test. The testing is carried out without prior entry of a request into the LIS. Once performed, the results, along with the patient information are transmitted to the LIS. In some circumstances, the LIS may add clinical interpretation to this and report it back to the placing system and/or another system. In order to allow for this to take place, the requester, location, etc., information is required.

To allow the sending system to correlate every result with its associated order, the receiving system will return the placer order number in the ORC segment of the ORA^R33 message. If the receiving system cannot place an order it must returning an application level error description in the Application Acknowledgement Message MSA Text Message field.

The sending system must return a commit-level acknowledgement in response to the ORA^R33 message.

Segment Cardinality Must Implement Status
ORU^R30^ORU_R30
MSH 1..1 Yes
SFT  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
ORC 1..1 Yes
PRT  
OBR 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT  
NTE  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
ACK^R30^ACK
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  

 

We need some ER7 examples...
We need some XML examples...

16.3.384 ORU - Unsolicited New Point-Of-Care Observation Message - Search for an Order (Event R31) (7.3.5)

This event trigger instructs the receiving system to search for an existing order for the observation(s) contained in the message.

In this case, the sending system does not know if an order has been placed. This transaction instructs the receiving system to search for an existing order for the associated results. If the receiver finds an existing order, it should return the Placer ID to the sender in the ORC segment of an OML^O21 message. This information allows the Observation Reviewer to correlate every result with its associated order.

The institution's business rules will determine what the receiving system does if it can't find a matching order. Possibilities include automatically placing an order (as in trigger event R30), or returning an application level error description in the Application Acknowledgement MSA Text Message field..

If it is necessary to pass specific information related to the Patient, responsible Doctor, placing doctor, patient location etc, there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type (see also ORU^R30 for description).

Segment Cardinality Must Implement Status
ORU^R31^ORU_R30
MSH 1..1 Yes
SFT  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
ORC 1..1 Yes
PRT  
OBR 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT  
NTE  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
ACK^R31^ACK
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  

 

We need some ER7 examples...
We need some XML examples...

16.3.385 ORU - Unsolicited Pre-Ordered Point-Of-Care Observation (Event R32) (7.3.6)

This event trigger instructs the receiver to place the result with the order information included in the message.

From a traditional clinical laboratory perspective, this event trigger's use case is probably the predominant (if not exclusive) one. However, in the POC environment, it is actually uncommon to have an order already generated when a test is performed. It does happen sometimes, though. If it is necessary to pass specific information related to the Patient, responsible Doctor, placing doctor, patient location, etc., there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type (see also ORU^R30 for description).

If the receiving system accepts both the order and the result, it will return an ORA^R33 Application Acknowledgement message with the acknowledgement code of AA. A comment may be included in the Acknowledgement Message MSA Text Message field.

If the receiving system is unable to accept both the order and the result, no order or result should be placed and an ACK^33 Application Acknowledgement message must be returned to the sender with the error identified in the MSA Text Message field.

The sending system must return a commit-level acknowledgement in response to the ORA^R33 message.

Segment Cardinality Must Implement Status
ORU^R32^ORU_R30
MSH 1..1 Yes
SFT  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
ORC 1..1 Yes
PRT  
OBR 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT  
NTE  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
ACK^R32^ACK
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  

 

We need some ER7 examples...
We need some XML examples...

16.3.386 ORA - Observation Report Acknowledgement (Event R33) (7.3.7)

This message enables a response to the ORU^R30 message to provide an application level acknowledgement that may include a placer order number.

Segment Cardinality Must Implement Status
ORA^R33^ORA_R33
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
ORC 0..1  

 

We need some ER7 examples...
We need some XML examples...

16.3.387 OUL - Unsolicited Specimen Oriented Observation Message (Event R22 ) (7.3.8)

This message was designed to accommodate specimen oriented testing. It should be applicable to container-less testing (e.g., elephant on a table) and laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results related to a specimen from a patient, where this specimen has been in none, one, or multiple containers.

In addition to the patient results themselves it permits the communication of the following kinds of information:

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

Segment Cardinality Must Implement Status
OUL^R22^OUL_R22
MSH 1..1 Yes
SFT  
NTE 0..1  
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
NTE  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
NK1  
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
CONTAINER  
SAC 1..1 Yes
INV 0..1  
ORDER 1..* Yes
OBR 1..1 Yes
PRT  
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
ORDER_DOCUMENT 0..1  
OBX 1..1 Yes
PRT  
TXA 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
RESULT  
OBX 1..1 Yes
PRT  
TCD 0..1  
SID  
NTE  
CTI  
DSC 0..1  

 

We need some ER7 examples...
We need some XML examples...

16.3.388 OUL - Unsolicited Specimen Container Oriented Observation Message (Event R23) (7.3.9)

This message was designed to accommodate specimen oriented testing. It should be applicable to, for example, laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results related to one or more specific containers with one or more specimens from a patient.

In addition to the patient results themselves it permits the communication of the following kinds of information:

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

Segment Cardinality Must Implement Status
OUL^R23^OUL_R23
MSH 1..1 Yes
SFT  
NTE 0..1  
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
NTE  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
NK1  
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
CONTAINER 1..* Yes
SAC 1..1 Yes
INV 0..1  
ORDER 1..* Yes
OBR 1..1 Yes
PRT  
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
ORDER_DOCUMENT 0..1  
OBX 1..1 Yes
PRT  
TXA 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
RESULT  
OBX 1..1 Yes
PRT  
TCD 0..1  
SID  
NTE  
CTI  
DSC 0..1  

 

We need some ER7 examples...
We need some XML examples...

16.3.389 OUL - Unsolicited Order Oriented Observation Message (Event R24) (7.3.10)

This message was designed to accommodate multi-specimen oriented testing. It should be applicable to, e.g., laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results, each one related to none, one or more specific containers with one or more specimens from a patient. (Example: Creatinine Clearance result with detailed information about the urine and serum specimens and their containers.)

In addition to the patient results themselves it permits the communication of the following kinds of information:

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

Segment Cardinality Must Implement Status
OUL^R24^OUL_R24
MSH 1..1 Yes
SFT  
NTE 0..1  
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
NTE  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
NK1  
ORDER 1..* Yes
OBR 1..1 Yes
PRT  
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
ORDER_DOCUMENT 0..1  
OBX 1..1 Yes
PRT  
TXA 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
SPECIMEN  
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
CONTAINER  
SAC 1..1 Yes
INV 0..1  
RESULT  
OBX 1..1 Yes
PRT  
TCD 0..1  
SID  
NTE  
CTI  
DSC 0..1  

 

We need some ER7 examples...
We need some XML examples...

16.3.390 OPU - Unsolicited Population/Location-Based Laboratory Observation Message (Event R25 ) (7.3.11)

This message supports unsolicited population or location-based surveillance reporting to a central repository where the accession / visit may contain references to multiple patients, multiple specimens, non-patient specimens, and multiple orders per specimen.

This message structure represents the way most submissions to veterinary laboratories occur. There is a multi-tier hierarchy in which a single individual (for example, a veterinarian or an owner of a production facility) submits one or more specimen samples from one or more animals or non-living entity, such as environmental specimens or feed. This grouped submission of specimens from multiple animal 'patients' is usually referred to as an 'accession' which can be considered analogous to a 'visit' in the veterinary laboratory context. This is what accounts for the unusual structure where the PV1 segment precedes a repeatable ACCESSION_DETAIL group.

Since specimens can originate from non-patients the PATIENT group is optional. This allows for specimens that are both associated with patients as well as those associated with non-patients to be included under the same accession (visit). Each specimen may have one or more orders assigned, each of which may have one or more individual results.

The OBX segment at the visit level provides the reason for submission. The repeatable PRT segment at the visit level represents the person(s) or organization submitting the request and other interested parties and locations who (that) play a role in the disposition of the accession/visit.

The NK1 segment contains owner and/or responsible party information for the patient and/or specimen.

Segment Cardinality Must Implement Status
OPU^R25^OPU_R25
MSH 1..1 Yes
SFT  
NTE 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
PATIENT_VISIT_OBSERVATION  
OBX 1..1 Yes
NTE  
PRT  
ACCESSION_DETAIL 1..* Yes
NK1 1..* Yes
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
NTE  
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
NTE  
CONTAINER  
SAC 1..1 Yes
INV 0..1  
ORDER 1..* Yes
OBR 1..1 Yes
PRT  
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
RESULT 1..* Yes
OBX 1..1 Yes
PRT  
NTE  

 

We need some ER7 examples...
We need some XML examples...

16.3.391 ORU - Unsolicited Alert Observation Message (Event R40) (7.3.12)

The R40 trigger event is used for observation reports that include an alertable condition, i.e., for which some timely human or application intervention in patient care may be indicated by the findings. The ORA^R41 provides the application level response to the ORU^R40.

The ORU^R40 message is outside of the order-fulfilling cycle of the ORU and OUL messages with other trigger events, and is supplemental to those order-fulfilling observations. As such, the results conveyed in the ORU^R40 do not replace, edit, or override the results of messages with other trigger events.

The ORU^R40 message represents a unitary alert, which is to be acknowledged as a whole by an ORA message. Multiple alerts requiring separate acknowledgement must be sent as individual messages.

The ORDER_OBSERVATION Segment Group which has OBR-49 value A (Alert provider when abnormal) conveys the alert observation(s). One or more OBX segments in this Segment Group will typically have OBX-8 Interpretation Codes value of LL. HH, or AA. At least one OBR segment shall have OBR-49 value A. Other ORDER_OBSERVATION Segment Groups within the message shall be considered supporting information for the alert observation(s).

An alert observation report may simply replicate observations conveyed in another observation message, e.g., sent in an ORU^R01 (the source observation). In such an instance the ORDER_OBSERVATION Segment Group shall replicate the OBR (and ORC, if present) of the source observation.

An alert observation reporting application may also derive a new alertable observation, e.g., from a combination of other observations from multiple orders, processed by a clinical decision support rule set. In this case, the ORDER_OBSERVATION Segment Group with the alertable observation may use an OBR representing the "order" for clinical decision support, with this instance uniquely identified in the OBR-51 Observation Group ID. Supporting source observations may be conveyed in subsequent ORDER_OBSERVATION Segment Groups in the message using their original OBR information.

If the reporting application can identify a preferred recipient for the alert, that may be conveyed in the PRT segment related to the OBR or OBX (with PRT-4 value RCT "Results Copies To"). This recipient may not be the same as the recipient(s) identified in a source observation. There is no expectation that the reporting application will a priori know a preferred recipient, nor that the receiving application will deliver the alert to the identified recipient (e.g., it may be delivered to an "on-call" clinician in lieu of the identified recipient).

Segment Cardinality Must Implement Status
ORU^R40^ORU_R01
MSH 1..1 Yes
SFT  
PATIENT_RESULT 1..* Yes
PATIENT 0..1  
PID 1..1 Yes
PD1 0..1  
PRT  
NTE  
NK1  
ARV  
PATIENT_OBSERVATION  
OBX 1..1 Yes
PRT  
VISIT 0..1  
PV1 1..1 Yes
PV2 0..1  
PRT  
ORDER_OBSERVATION 1..* Yes
COMMON_ORDER 0..1  
ORC 1..1 Yes
PRT  
ORDER_DOCUMENT 0..1  
OBX 1..1 Yes
PRT  
TXA 1..1 Yes
OBR 1..1 Yes
NTE  
PRT  
TIMING_QTY  
TQ1 1..1 Yes
TQ2  
CTD 0..1  
OBSERVATION  
OBX 1..1 Yes
PRT  
NTE  
FT1  
CTI  
SPECIMEN  
SPM 1..1 Yes
SPECIMEN_OBSERVATION  
OBX 1..1 Yes
PRT  
DSC 0..1  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
ACK^R01^ACK
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  

 

We need some ER7 examples...
We need some XML examples...

16.3.392 ORA - Observation Report Alert Acknowledgement (Event R41) (7.3.13)

This message enables application level acknowledgements in response to the ORU^R40 alert observation message.

The R41 trigger event is used to indicate that the alert observation has been delivered to, and acknowledged by, a clinical user. If the clinical user can be identified, that identity can be conveyed in the PRT segment (with PRT-4 value AAP Alert Acknowledging Provider).

Considering that the alerts may be received by multiple providers, multiple acknowledgements may be returned. The behavior associated with the user acknowledgement may be specified in a local implementation agreement or implementation guide and may be indicated in MSH-21 Message Profile Identifier.

Segment Cardinality Must Implement Status
ORA^R41^ORA_R41
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
PRT  

 

We need some ER7 examples...
We need some XML examples...