HL7 ORU_R01 Observation Result

The result message most people meet first, and debug for years.
HL7 message structure ORU_R01 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
ORU_R01.PATIENT_RESULT
 Patient Result group Yes Yes
ORU_R01.PATIENT
 Patient group No No
PID
 Patient Identification Yes No
PD1
 Patient Additional Demographic No No
NTE
 Notes and Comments No Yes
NK1
 Next of Kin / Associated Parties No Yes
ORU_R01.VISIT
 Visit group No No
PV1
 Patient Visit Yes No
PV2
 Patient Visit - Additional Information No No
ORU_R01.ORDER_OBSERVATION
 Order Observation group Yes Yes
ORC
 Common Order No No
OBR
 Observation Request Yes No
NTE
 Notes and Comments No Yes
ORU_R01.TIMING_QTY
 Timing Quantity group No Yes
TQ1
 Timing/Quantity Yes No
TQ2
 Timing/Quantity Relationship No Yes
CTD
 Contact Data No No
ORU_R01.OBSERVATION
 Observation group No Yes
OBX
 Observation/Result Yes No
NTE
 Notes and Comments No Yes
FT1
 Financial Transaction No Yes
CTI
 Clinical Trial Identification No Yes
ORU_R01.SPECIMEN
 Specimen group No Yes
SPM
 Specimen Yes No
OBX
 Observation/Result No Yes
DSC
 Continuation Pointer No No

ORU_R01 is the common unsolicited observation result message. Labs, radiology systems, cardiology systems, devices, and clinical reporting systems use it to send results to EHRs, repositories, portals, registries, and integration engines. It is "unsolicited" because the result is pushed when available, not returned inside a synchronous request.

The message is built around a patient, one or more orders, and one or more observations. That sounds tidy until you meet multi-panel labs, corrected reports, text blobs, PDFs, microbiology, imaging narratives, and devices that send one tiny measurement at a time. ORU_R01 can handle a lot, but only if the order and observation layers stay clear.

A small ORU result example

MSH|^~\&|LAB|CITYLAB|EHR|CITYHOSP|20260715143000||ORU^R01^ORU_R01|ORU00001|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|CLINIC^12^^CITYHOSP ORC|RE|ORD448811^EHR|LAB998877^CITYLAB OBR|1|ORD448811^EHR|LAB998877^CITYLAB|718-7^Hemoglobin^LN|||20260715113000|||||||||12345^Careful^Clara||||||20260715142500|||F OBX|1|NM|718-7^Hemoglobin^LN||128|g/L|115-155|N|||F|||20260715142000 OBX|2|ST|59408-5^Specimen comment^LN||Specimen checked before release||||||F

What systems do with it

The sender is usually the filler or result-producing system. The receiver files the result, matches it back to the order or encounter, updates clinical worklists, triggers notifications, and sometimes posts charges. The integration engine may transform local codes, split panels, route copies, or hold corrected results for review.

OBR describes the observation request or report header. OBX carries the actual observation values. That separation is important. The OBR says what was ordered or reported; the OBX says what was found.

How to read the structure

The patient result group can repeat. Inside it, the optional patient group identifies the patient and visit, and the order observation group repeats for each reportable order. ORC may appear to carry order state and identifiers. OBR is required in each order observation group. OBX repeats under OBR for result lines, components, comments encoded as observations, or structured report content.

Specimen detail may appear through SPM, especially in later lab-style profiles. Notes in NTE are common, but use them carefully. If a value needs to be coded, trended, or interpreted by a receiver, OBX is usually a better home than free text.

Status and corrections

Result status matters. Receivers need to distinguish preliminary, final, corrected, cancelled, and appended content. OBR and OBX status fields should agree with the workflow, and corrected results should identify the same order and observation so the receiver updates the old result rather than adding a duplicate.

OBX-5 is the field everyone looks at, but OBX-2, OBX-3, units, reference range, abnormal flags, observation status, and timestamps are what make the value usable. A naked number without units or a code is rarely enough.

Reference notes

HL7 v2 Chapter 7 covers observation reporting, and public implementation notes commonly describe ORU_R01 as a three-level patient, order, and observation hierarchy. See HL7 v2.5.1 Chapter 7 and practical ORU summaries such as iNTERFACEWARE's ORU overview.