HL7 ORU Messages Explained: Observation Results

An ORU message carries a result. Pathology findings, radiology reports, vital signs, point-of-care observations — when a healthcare system has produced a clinical finding and needs to deliver it somewhere, it usually arrives as ORU^R01.

Of all the HL7 message types, ORU is the one where getting it wrong has the most direct clinical consequence. A missing order is an inconvenience that somebody eventually chases. A missing result is a finding that no clinician ever saw.

How a result message is structured

ORU is hierarchical, and understanding the hierarchy is most of understanding the message:

• PID — the patient.
• OBR — the observation request: which order this result belongs to, when the specimen was collected, who requested it, and the overall result status.
• OBX — the individual observations. One per analyte, measurement or component of the report.
• NTE — notes, which can attach at several levels.

A full blood count arrives as one OBR with a dozen or more OBX segments hanging off it. A radiology report typically arrives as one OBR with the narrative text spread across OBX segments. A single message can carry several OBR groups for different orders.

The fields that determine correctness

OBX-11 — observation result status. This is the field that decides whether you can act on the value:

• P — preliminary. Real, but subject to change.
• F — final. The verified result.
• C — correction. This value replaces one previously sent as final.
• X — cannot be obtained.
• D — delete this observation.

OBX-5 — the value itself, whose type is declared by OBX-2. A numeric result, coded value, structured name or free text all arrive in the same field with different type codes. Systems that assume everything is numeric fall over on the first text-based report.

OBX-8 — abnormal flags. H, L, HH, LL, A and so on. If your system triages or alerts, this is what it triages on.

OBX-7 — reference range. Ranges vary by age, sex, method and laboratory. Storing the value without the range that came with it means you cannot correctly interpret it later.

Corrections are the part people get wrong

Most result interfaces are built for the happy path: a final result arrives, it is filed, everybody is satisfied. Then a laboratory issues a correction, and the design gaps surface all at once.

A corrected result is not a new result. It supersedes a specific earlier observation, and the system needs to make that supersession visible — not quietly overwrite the old value, and certainly not display both as though they were independent findings. If a clinician made a decision on the original value, the correction has to be prominent enough that somebody notices.

The related failure is the preliminary-to-final transition. A preliminary result that is silently replaced by a final one with a different value, with no indication anything changed, is a genuine clinical safety issue. Systems need to keep both, show which is current, and make the history reachable.

I have written separately about why a cancelled or voided record still needs to say so — result corrections are the sharpest version of that problem.

Matching results to orders

Results reference the order they came from via the placer and filler order numbers in OBR. When those do not match anything the receiving system holds, you have an unsolicited result — and every result interface eventually receives them. The order was placed on paper, or in a different system, or the ADT feed had not yet created the patient when the order was raised.

Unsolicited results must go somewhere a human looks. Silently discarding results that fail to match is the single most dangerous behaviour a result interface can have, and it is depressingly common because discarding is the path of least resistance when the match fails.

Practical advice

Store the raw message. Store the reference range and the abnormal flag alongside the value, not just the number. Keep every version of every observation rather than overwriting in place. Make unmatched results visible rather than dropping them. And build a reconciliation that counts results against orders, because ten out of twelve is a failure, not a result.

FHIR models this as Observation and DiagnosticReport, with an explicit status element covering the same preliminary, final, corrected and entered-in-error states. The model is cleaner. The obligations — never lose a result, never hide a correction — are exactly the same.

Need a result interface built or reviewed? Get in touch.