Observation Result

An HL7 Observation Result (ORU) message contains information about a patient’s clinical observations and is used in response to an order generated in a clinical system (HL7 ORM message). ORU messages are most commonly used within the context of EKG studies, laboratory results, imaging studies, and medical interpretations. They have also been used to communicate order and results information for the purpose of clinical trials (e.g. drug development). It is important to note that ORU messages do not natively contain images, but use a combination of text, codes and numbers to communicate results.

The ORU message has only two different message types:

      • ORU^R01 - Unsolicited transmission of an observation result. 
        • This message is generated when results from the receiving (results) system (LIS, RIS, EKG) need to be communicated to the sending (ordering) system (HIS, EMR) 
      • ORU^W01 - Waveform result, unsolicited transmission of requested information. 
        • This message type transmits waveform data (e.g. produced from electrocardiograms) produced by an ordered test or multiple observation


Below is an example of an HL7 version 2.4 ORU^R01 message:

OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||
OBX|2|TX|SR Text||Radiology Report History Cough Findings PA evaluation of the chest demonstrates the lungs to be expanded and clear. Conclusions Normal PA chest x-ray.||||||F||||||





Message Header. This segment is a mandatory part of an ORU message, and contains information about the message sender and receiver, the date and time that the message was created. This segment is required.


Patient Identification. An ORU message is a patient-specific message type, and must be linked to a particular patient. Therefore, patient information such as the patient identifier, name, date of birth, etc. must be included in an ORU. This segment is required.


Patient Visit. This segment contains information about patient visit details such as servicing facility, attending doctor, and visit ID. This segment is required.


Observation Request. This segment identifies the observation that was ordered in order to generate the ORU message.  This segment is required.



Observation Segment. Here is where information about the observation results is held. An OBX segment is used to communicate a single observation, so multiple observations would require this segment to repeat. This segment is optional and can be repeating.


Clinical Trial Identification. This is an optional segment and is only used if the results need to be linked to a clinical trial. Information such as the trial ID, study phase, and time point is included here. This segment is optional and can be repeating.

[ ] = optional, { } = repeating


For more information on implementing various HL7 message types, please refer to the HL7 Messaging Standard Implementation Guides corresponding to your required version. 




Other HL7 Message Types:

      • HL7 ADT (Admit, Discharge and Transfer)
      • HL7 ORM (Order Entry)
      • HL7 ORU (Observation Result)
      • HL7 MDM (Medical Document Management)
      • HL7 DFT (Detailed Financial Transactions)
      • HL7 BAR (Billing Account Record)
      • HL7 SIU (Scheduling Information Unsolicited)
      • HL7 RDS (Pharmacy/treatment Dispense)
      • HL7 RDE (Pharmacy/Treatment Encoded Order)
      • HL7 ACK (Acknowledgement Message)


Looking for professional advice? 

Iguana is the leading HL7 integration engine on the market, trusted globally for 20+ years. To learn more about HL7 data exchange, contact one of our integration engine experts today.

Additional Resources:

Debunking the Myths of HL7 Integration

There are many myths about what the HL7 standard can do and the implications for healthcare organizations. In this guide, we set the record straight on common HL7 claims.


Integration with HL7

HL7 is great standard, but anyone with first hand experience knows it's not without its challenges. We're here to help!

Let's talk

The ''non-standard" Standard

In practice, you'll find that everyone formats HL7 messages slightly different, even though it has a standard structure in place. With iNTERFACEWARE's integration engine, you can ensure that all data is normalized as intended for full compliance.


Version Compatiblity

What happens when the source destination is sending one version of HL7, while the recipient's system can only handle an older version of HL7? With Iguana you can convert HL7 versions on the fly.


Data Extraction

As you've seen, HL7 messages can contain a lot of information -- sometimes much more than you need. Simplify things using Iguana, by extracting the data from the specific HL7 fields you need. 


Future Proofing

The HL7 organization is always working on improving the standard and new versions will keep coming in the future. Ensure that your data always remains compatible with iNTERFACEWARE's integration engine, Iguana.