What is the difference between OBR and OBX in HL7?

OBR is the order/observation request — the test that was ordered, with placer and filler order numbers and the service identifier. OBX is an individual observation (result value) produced under that OBR. One OBR typically groups many OBX segments, such as each analyte in a lab panel.

What do HL7 result status codes mean?

OBX-11 carries the observation result status: P (preliminary), F (final), C (corrected), and X (cannot be obtained), among others. They are clinically important — a preliminary result must not be shown as final, and a corrected result must supersede the original rather than being appended alongside it.

Is ORM still used for HL7 orders?

ORM^O01 was the classic general order message and is still widely in production, but newer implementations often use OMG^O19 for general orders or OML for laboratory orders. Regardless of the message type, orders and their results are correlated through placer and filler order numbers.

HL7 ORM & ORU: Orders and Results Messaging Done Right

How do HL7 orders and results messages actually work?

If ADT tells the hospital who the patient is, orders and results tell it what's being done and what came back. ORM (and its modern replacement OMG/OML) carries orders — a lab test, an imaging study, a procedure — and ORU carries the results. These are the interfaces most tied to clinical safety, because a dropped or mis-mapped result is a patient-safety event, not just a data bug. This guide covers the OBR/OBX backbone, result status codes, corrections, and the patterns that keep orders-and-results interfaces correct.

The order/result lifecycle

A typical flow: a clinician places an order, the EHR sends an order message (historically ORM^O01, now often OMG^O19 for general orders or OML for labs) to the ancillary system (LIS, RIS). The ancillary system performs the work and sends results back as an ORU^R01. The two halves are linked by placer and filler order numbers — the identifiers that let you correlate a result to the order that requested it. Losing that linkage is how results end up unattached to anything.

OBR: the order/observation request

The OBR segment is the request-level container. It carries the placer order number (assigned by the ordering system), the filler order number (assigned by the performing system), the universal service identifier (what was ordered — often a LOINC or local code), and timing. In a result message, one OBR groups the set of observations it produced. Think of OBR as "the test that was ordered" and OBX as "each value that came back."

OBX: the individual observation

OBX-2 is the value type (NM numeric, ST string, TX text, CE/CWE coded, etc.) — it tells you how to interpret OBX-5.
OBX-3 is the observation identifier — ideally a LOINC code identifying exactly what was measured.
OBX-5 is the value itself; OBX-6 the units; OBX-7 the reference range.
OBX-8 carries abnormal flags (H, L, HH, LL, A) — clinically critical and easy to drop if you only map the value.
OBX-11 is the observation result status — see below.

Result status codes matter for safety

OBX-11 (and OBR-25 at the order level) carry the result status, and treating them as noise is dangerous. A 'P' (preliminary) result is not a 'F' (final) result, and a 'C' (corrected) result must replace a prior value, not append to it. Common statuses: P preliminary, F final, C corrected, X cannot be obtained. An interface that shows a preliminary result as final, or that displays both the original and corrected value side by side, creates real clinical risk.

Corrections and amendments

Results change. A lab re-runs a specimen; a radiologist amends a read. HL7 handles this with corrected result status and re-sent messages that reference the original via order numbers. Your interface must apply a correction as an update to the existing result — superseding the prior value while retaining an audit trail — not as a brand-new independent result. Append-only handling of corrections is a subtle but serious defect.

Grouping and panels

A single ORU can carry a whole panel: one OBR (e.g. a metabolic panel) followed by many OBX segments (glucose, sodium, potassium, and so on), and a message can contain multiple OBR groups. Parsing must preserve the OBR→OBX grouping so each value lands under the right ordered test. Flattening all OBXs into one list and losing which OBR they belonged to is a classic mistake that scrambles panels.

Patterns for correct orders/results interfaces

Correlate strictly on placer/filler order numbers so every result attaches to its order.
Honor result status — never render preliminary as final, always supersede on corrected.
Preserve abnormal flags, units, and reference ranges, not just the raw value.
Maintain OBR→OBX grouping so panels stay intact.
Map observation identifiers to LOINC where possible for downstream interoperability.

Why this is the interface to get right

Orders and results sit closest to patient care. A demographic glitch in ADT is annoying; a lost critical result or a preliminary value shown as final can harm a patient. Investing in correct OBR/OBX handling, status and correction logic, and strict order correlation is not gold-plating — it is the baseline for an interface that clinicians can safely trust.