If the ADT feed is the backbone of a hospital interface, the ORU result feed is its nervous system. The ORU^R01 (Unsolicited Observation Result) message is how a laboratory information system (LIS), a reference lab, a microbiology analyzer, or a cardiology workstation pushes finished results back to the ordering EHR. When you build or upgrade a lab interface, the very first thing you need is a supply of valid ORU^R01 test messages that exercise every result type your receiver will encounter — numeric chemistry, coded micro, textual narratives, and the dreaded corrected result. This guide explains the ORU^R01 structure precisely as defined in the HL7 Version 2.5.1 standard (Chapter 7, Observation Reporting), then shows how to produce clean, PHI-free test data with our HL7 Message Generator and inspect it segment-by-segment in the HL7 Viewer.
The ORU^R01 Message Hierarchy
ORU^R01 is not a flat list of segments — it is a nested hierarchy, and most interface bugs come from engineers treating it as flat. HL7 v2.5.1 Chapter 7 defines the abstract message structure as a repeating PATIENT_RESULT group, each containing an optional PATIENT group (PID, optional PV1) and one or more ORDER_OBSERVATION groups. Each ORDER_OBSERVATION carries one OBR (the order/battery) followed by one or more OBSERVATION groups, each consisting of an OBX (a single result) with optional NTE notes.
The practical consequence — the rule every LIS interface developer eventually learns the hard way — is that OBR is the parent and OBX is the child. A single complete blood count (CBC) order produces one OBR and roughly a dozen OBX rows (WBC, RBC, hemoglobin, hematocrit, platelets, and the differential). A panel that combines a chemistry battery with a hematology battery produces two OBR segments under one PID, each with its own cluster of OBX results. Receivers that flatten this structure will mis-attribute results to the wrong order and produce clinically dangerous reports.
The Minimal Valid ORU^R01
The smallest message a conformant receiver should accept contains MSH, PID, OBR, and one OBX:
MSH|^~\&|LAB_LIS|MAIN_LAB|EHR_APP|HOSP|20260730081500||ORU^R01|MSG000042|P|2.5.1 PID|||TEST000042^^^HOSPMRN^MR||TEST^PATIENT^A||19000101|U OBR|1|ORD000042|FILL000042|CBC^Complete Blood Count^L|||20260730080000 OBX|1|NM|6690-2^Leukocytes^LN||7.4|10*3/uL|4.0-11.0|N|||F
That single OBX says: result number 1, data type NM (numeric), observation identifier LOINC 6690-2 (Leukocytes/WBC), value 7.4, units 10*3/uL, reference range 4.0-11.0, interpretation N (normal), result status F (final). Every component of that OBX is a separate test case waiting to happen.
OBX-2: The Value Type Is Everything
OBX-2 (Value Type) tells the receiver how to parse OBX-5. Getting it wrong is the single most common ORU defect. The HL7 v2.5.1 data type table (Chapter 2A) defines the values your test suite must cover:
NM— Numeric. The workhorse of chemistry and hematology. OBX-5 is a plain number; OBX-6 carries units, OBX-7 the reference range.ST— String. Short free text, e.g., a specimen description or a qualitative "Positive".TX— Text. Longer narrative, used by microbiology and anatomic pathology for free-form interpretations. May contain embedded line breaks encoded as\.br\.CE/CWE— Coded with Exceptions. A coded result like an organism identification (SNOMEDor local code). CWE replaced CE in 2.5.1 and is preferred for new interfaces.SN— Structured Numeric. For results like>^1000or10^-^20(ranges and inequalities) that a bare NM cannot represent.
A robust test set sends one OBX of each type through your receiver and confirms it stores and displays each correctly. The classic production failure: an analyzer reports a titer as >1:640 using SN, the receiver was only tested with NM, and it either rejects the message or silently truncates the value to 640 — a clinically wrong result. Generate an SN example deliberately and watch what your receiver does with it.
Coding OBX-3 with LOINC
OBX-3 (Observation Identifier) is the coded name of the test. The US Meaningful Use program and the ONC Certification regulations (45 CFR 170.205) mandate LOINC for laboratory result observations, so your test data should use real LOINC codes in the code^display^LN format, where LN is the HL7-registered code system identifier for LOINC. Examples drawn from the official LOINC database (Regenstrief Institute):
2345-7^Glucose^LN— serum glucose.2160-0^Creatinine^LN— serum creatinine.718-7^Hemoglobin^LN— hemoglobin.2951-2^Sodium^LN— serum sodium.
Many real interfaces dual-code, putting the local LIS code in the second triplet of OBX-3 (after the ~ alternate-identifier separator is not used here — the standard CWE field has primary and alternate triplet positions). A thorough test message includes both the LOINC code and a local code so you can verify the receiver maps correctly when its own catalog is keyed on local codes rather than LOINC.
OBX-8: Abnormal Flags and Clinical Routing
OBX-8 (Abnormal Flags) drives clinical alerting. The HL7 v2.5.1 table 0078 defines the allowed values: N normal, L low, H high, LL critically low (panic low), HH critically high (panic high), A abnormal (for non-numeric results), and AA very abnormal. Critical-value handling is the highest-stakes path in any lab interface because a missed panic value can be fatal, so your test set must include:
- A normal result (
N) — baseline, confirms no spurious alerting. - A high result (
H) — confirms the receiver flags it visually but does not trigger a critical alert. - A critical-high result (
HH) — for example a potassium of 7.2 mmol/L flaggedHH— and verify the receiver fires its critical-result notification workflow. - A coded abnormal (
A) — for a positive culture, to confirm non-numeric flagging.
Send a deliberately critical OBX and watch the entire downstream chain: does the result land in the provider's inbox as urgent, does the closed-loop critical-value acknowledgment workflow start, does it page the covering clinician? This is exactly the kind of clinical behavior that unit tests cannot cover and only end-to-end ORU injection can validate.
OBX-11 and OBR-25: Result Status
Status is where lab interfaces get genuinely subtle. OBX-11 (Observation Result Status) and OBR-25 (Result Status) both draw from HL7 v2.5.1 table 0085. The values that matter for testing are P (preliminary), F (final), C (correction of a previously final result), and X (results cannot be obtained / cancelled). The preliminary-to-final lifecycle is fundamental: a chemistry result may be released as P while still on the analyzer, then re-sent as F when verified by a technologist.
The Corrected Result — The Test Everyone Skips
The C (correction) status is the single most under-tested ORU scenario and the most dangerous when broken. When a lab amends a result — say a glucose first reported as 95 was actually 950 due to a dilution error — it resends the OBX with OBX-11 set to C and the corrected value. A correct receiver replaces the prior result and visibly marks it as corrected; a broken receiver appends it as a second result, leaving both the wrong and right values in the chart with no indication which is current. Build a deliberate sequence — an F result followed minutes later by a C result for the same OBR filler number and OBX-3 code — and verify your EHR shows exactly one current value, clearly marked corrected. This is the highest-priority correctness test for any lab interface and is closely related to the ACK round-trip you must also verify; see our companion guide on debugging HL7 ACK failures for how to confirm the corrected message was actually accepted, not silently dropped.
Linking the Order: OBR-2, OBR-3, and the Filler Number
For a result to attach to the right order in the EHR, OBR-2 (Placer Order Number) and OBR-3 (Filler Order Number) must echo the values from the original order (the ORM^O01 or OML^O21 the EHR sent). The filler number is assigned by the lab and is the durable key that ties preliminary, final, and corrected results to the same logical observation. Test data that uses inconsistent filler numbers across a P→F→C sequence will produce orphaned results in the EHR even when each individual message is structurally perfect. Keep OBR-3 stable across the lifecycle, exactly as you keep PID-3 and PV1-19 stable across an ADT sequence — the same "golden thread" discipline described in our guide to HL7 ADT test messages for interface testing applies to the result feed.
Building a Realistic Multi-Result Message
A representative basic metabolic panel (BMP) message exercises the OBR-to-OBX parent-child relationship with several numeric results under one battery:
MSH|^~\&|LAB_LIS|MAIN_LAB|EHR_APP|HOSP|20260730081500||ORU^R01|MSG000043|P|2.5.1 PID|||TEST000043^^^HOSPMRN^MR||TEST^PATIENT^B||19000101|F OBR|1|ORD000043|FILL000043|BMP^Basic Metabolic Panel^L|||20260730080000|||||||||1001^DOCTOR^TEST|||||||||F OBX|1|NM|2345-7^Glucose^LN||95|mg/dL|70-99|N|||F OBX|2|NM|2160-0^Creatinine^LN||1.1|mg/dL|0.6-1.3|N|||F OBX|3|NM|2951-2^Sodium^LN||128|mmol/L|136-145|L|||F OBX|4|NM|6298-4^Potassium^LN||7.2|mmol/L|3.5-5.1|HH|||F
Note OBX-3 (sodium) flagged L and OBX-4 (potassium 7.2) flagged HH — that single message simultaneously tests normal results, a borderline-low result, and a critical-high result, all attached to one battery. Drop it into your test channel and verify all four results land under the same BMP order with correct flags and that the potassium triggers the critical workflow.
Generating Clean Test Data
Open the HL7 Message Generator, choose ORU^R01 from the trigger-event dropdown, and click "Fill with sample data" to populate MSH, PID, OBR, and OBX with obviously synthetic values (TEST^PATIENT, MRN TEST000042, DOB 19000101). Adjust OBX-2 to test each value type, edit OBX-8 to inject abnormal flags, and flip OBX-11 to C to build your corrected-result scenario. The preview updates live and every message parses cleanly through our HL7 parser, so any failure you see downstream is a genuine semantic problem in the receiver — exactly what interface validation should surface.
Before sending, click "Open in HL7 Viewer" to inspect the message in the HL7 Viewer. The viewer renders the OBR/OBX hierarchy explicitly, so you can confirm at a glance that your OBX rows sit under the correct OBR and that field positions match the v2.5.1 specification before a single byte reaches your integration engine. Build a small library of these messages — one per value type, one per status, one critical, one corrected — and you have a regression suite that catches the lab-interface defects that genuinely harm patients.