ORU — Observation Result

HL7 ORU messages return observation results — the values a laboratory, imaging department, or monitoring device produces and reports back to the systems that ordered them or need to record them. ORU^R01 is the general-purpose result message of HL7 v2, used across every clinical domain from chemistry panels to microbiology to vital signs. Where an ORM or OML message places an order, an ORU message returns the result. This page explains what an ORU message represents, when it is sent, every segment the message can carry and what each one holds, a deep-dive on the OBX result segment, and how an ORU message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.

What an ORU message represents

An ORU message — ORU stands for Observation Result, Unsolicited — communicates one or more observations produced for a patient. The message nests results under the order that requested them: each OBR observation request carries a set of OBX observation segments, and each OBX holds one discrete result value with its units, reference range, abnormal flag, and status. A single ORU can report a whole panel of results, several panels, or results for several patients.

The sender is the producing system — a laboratory information system, a radiology system, or an instrument — and the receivers are the systems that record and act on results: the EHR, the ordering provider's inbox, clinical decision support, and billing. Although the message name says "unsolicited", ORU^R01 is also the response to a query in solicited workflows; the trigger event is the same and the receiver handles the body identically. Because the OBX carries the result value and its status, OBX-11 is the field a receiver reads to know whether a value is preliminary, final, or a correction.

Every ORU message shares the same skeleton — an MSH header and one or more PATIENT_RESULT groups, each pairing an optional PATIENT group (PID) with one or more ORDER_OBSERVATION groups (OBR plus its OBX results).

When an ORU message is sent

An ORU message is sent when results are available. A single order may generate several ORU messages over time as results move from preliminary to final and as corrections are issued. Each message stands alone: the receiver does not need the original order message to process an ORU, though the result links back to its order through the filler and placer order numbers in OBR.

Trigger event

The ORU message type's principal trigger event is:

• ORU^R01 – Unsolicited transmission of an observation result.

Because the everyday result workflow uses one trigger event, the receiver's handling turns on the result status in OBR-25 and the per-observation status in OBX-11 — final, preliminary, corrected — rather than on the trigger code in MSH-9. A first result and a corrected result both arrive as ORU^R01; the status fields distinguish them.

Integration topology

The diagram shows the producing system emitting a result through the integration engine to the systems that record and act on it.

{{diagram: laboratory / radiology / device → ORU message → integration engine → EHR / ordering provider inbox / clinical decision support / billing}}

Typical senders: laboratory information system, radiology information system, instrument or device, and result repositories.

Typical receivers: EHR or clinical application, ordering provider's result inbox, clinical decision support, and billing / charge capture.

Direction: unidirectional notification from the producing system to the systems that record, present, and act on the results.

Segments in an ORU message

The ORU_R01 message is built from one or more repeating PATIENT_RESULT groups. Each PATIENT_RESULT group holds an optional PATIENT group (PID and companions) and one or more ORDER_OBSERVATION groups. Each ORDER_OBSERVATION group carries an OBR and the OBX results beneath it. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The PATIENT_RESULT group repeats once per patient, the ORDER_OBSERVATION group repeats once per ordered panel, and the OBSERVATION group repeats once per discrete result within a panel. A single ORU message can therefore carry many results across several panels and patients. The canonical segment pages carry the full field-by-field detail.

The OBX observation/result segment

OBX — the Observation/Result segment — carries a single discrete result. It is the payload of the ORU message, and the fields an integration team reads most often:

The value type in OBX-2 governs how OBX-5 is parsed, and the result status in OBX-11 governs how the receiver stores it — a preliminary value is superseded by a later final, and a correction replaces the prior value rather than appending. These are the fields a result receiver acts on first. The full field list is on the canonical OBX page.

Sample ORU message

Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.

MSH|^~&|LIS|MERCYGEN|EHR|MERCYGEN|20260701101500||ORU^R01^ORU_R01|MSG00042|P|2.5.1
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PV1|1|O|LAB^^^MERCYGEN||||1234^SMITH^JANE^A^^^MD|||MED
ORC|RE|ORD5501^EHR|RES7788^LIS
OBR|1|ORD5501^EHR|RES7788^LIS|58410-2^CBC WITH DIFFERENTIAL^LN|||20260701100000|||||||||1234^SMITH^JANE^A^^^MD||||||20260701101500|||F
OBX|1|NM|6690-2^Leukocytes [#/volume] in Blood^LN||7.2|10*3/uL|4.5-11.0|N||F|||20260701101500
OBX|2|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||13.9|g/dL|12.0-16.0|N||F|||20260701101500
OBX|3|NM|777-3^Platelets [#/volume] in Blood^LN||245|10*3/uL|150-400|N||F|||20260701101500
NTE|1||Specimen received without incident.

What this sample shows

The ORU^R01 in MSH-9 marks an observation result. PID carries the medical record number MR12345, and PV1 supplies the visit context. The ORC carries the order control code RE and links to the originating order through the placer number ORD5501 and filler number RES7788. The OBR identifies the CBC With Differential panel (LOINC 58410-2) with a final result status F in OBR-25. Three OBX segments carry the discrete results — WBC, Hemoglobin, and Platelets — each declaring a numeric value type (NM) in OBX-2, a value in OBX-5, units in OBX-6, a reference range in OBX-7, an abnormal flag N in OBX-8, and a final status F in OBX-11. The NTE carries an order-level comment.

Working with ORU messages

Read the result status before storing

The panel status in OBR-25 and the per-observation status in OBX-11 govern how a result is stored. A preliminary result (P) is provisional and will be followed by a final (F); a correction (C) must replace the prior value for that observation identifier rather than append a second row. Storing every result as final, or appending corrections, surfaces superseded values to clinicians.

Parse the value by its type

OBX-2 declares the type of OBX-5 — numeric, string, coded, or structured. A numeric result parses to a number; a coded result (CE/CWE) carries a code and text; a structured numeric (SN) carries a comparator and value. Reading OBX-5 without checking OBX-2 misparses non-numeric results such as "POSITIVE" or "<0.01".

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the filler order number in OBR-3 together with the observation identifier in OBX-3 and the result status as the natural business key for a result. Result feeds are replayed after outages and corrections generate a second message for the same order; deduplicating on the control id prevents a replay from creating a second result record.

Nest results under the right order

The OBSERVATION group nests inside the ORDER_OBSERVATION group, which nests inside the PATIENT_RESULT group. Attribute each OBX to the OBR that precedes it within the same ORDER_OBSERVATION group, not to the first OBR in the message — a multi-panel ORU carries several OBR segments and misattribution assigns results to the wrong test.

Vendor variance. Senders differ in how they populate OBX-2 value types, whether they include the v2.5 SPECIMEN group, and how they encode reference ranges and abnormal flags. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An ORU message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Patient, one DiagnosticReport per order, and one Observation per result. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH, the Patient from PID, a DiagnosticReport from each OBR, and an Observation from each OBX that the DiagnosticReport references, with optional Encounter from the visit segments, Specimen from the SPM group, ServiceRequest from ORC/OBR, and RelatedPerson from NK1.

The Implementation Guide publishes an official Bundle map for ORU_R01.

Common pitfalls

Pitfall. Ignoring the result status in OBX-11. A preliminary result (P) and a final result (F) for the same observation represent different clinical states; storing both as equivalent can surface a superseded value to a clinician, and treating a correction (C) as a new result appends a duplicate.

Pitfall. Reading OBX-5 without checking OBX-2. The value type governs parsing; a numeric parser applied to a coded or structured value silently corrupts the result.

Pitfall. Attributing every OBX to the first OBR. A multi-panel ORU nests each OBSERVATION group under its own ORDER_OBSERVATION group; misattribution assigns results to the wrong test.

How Vorro handles ORU messages

Vorro ingests the ORU feed over MLLP or another transport, deduplicates on MSH-10, and routes each result set to every subscribed destination in the format that system expects — the EHR, the ordering provider's result inbox, clinical decision support, and billing. Vorro attributes each OBX to the OBR that anchors its ORDER_OBSERVATION group, parses each value by its OBX-2 type, and handles result corrections by updating the existing record when OBX-11 carries C rather than appending a duplicate. Where a FHIR destination is configured, Vorro emits the corresponding Bundle using the Implementation Guide's published ORU_R01 map — one DiagnosticReport per order and one Observation per result.

Related messages

• ORM — the general order message that places the order an ORU returns results against.
• OML — the laboratory order message that precedes an ORU result in modern lab workflows.
• OBR — the observation request segment that anchors each ORDER_OBSERVATION group and links results to their order.

Sources

• HL7 v2-to-FHIR IG — message maps index
• HL7 v2-to-FHIR IG — ORU_R01 to Bundle ConceptMap
• HL7 Messaging Standard Version 2.5.1 product brief
• HAPI HL7v2 v2.5.1 ORU_R01 message structure
• HAPI HL7v2 v2.5.1 ORU_R01_PATIENT_RESULT group structure
• HAPI HL7v2 v2.5.1 ORU_R01_ORDER_OBSERVATION group structure
• HAPI HL7v2 v2.5.1 ORU_R01_OBSERVATION group structure