MajwareMAJWARE
ORU
^R01
Observation/Results4 required / 4 optional segments

ORU^R01Unsolicited Observation Result

The primary message for delivering clinical results: lab values, radiology reports, vital signs, pathology findings, and other observations. It carries the order reference (OBR) and one or more results (OBX segments).

When Is This Sent?

When a lab analyzer produces results, a radiologist finalizes a report, a bedside monitor records vitals, or any ancillary system has observations to report. Results can be preliminary (P) or final (F).

Real-World Usage

ORU^R01 is arguably the most important message in clinical HL7 interfaces — it delivers lab results and radiology reports that clinicians rely on for patient care. A hospital's ORU^R01 volume is typically 3-10x its ADT volume. Critical results (flagged H/L/HH/LL in OBX.8) must be received reliably and trigger appropriate alerts.

Message Structure

Segment names link to their field-level reference pages.

#SegmentPurpose in this messageReqRepeat
1MSHMessage header with ORU^R01 in MSH.9R
2PIDPatient demographics for result linkingR
3OBROrder/observation request details — links results to the original orderR
4OBXOne or more observation/result valuesRYes
5ORCOrder common segment (included in some implementations)O
6PV1Patient visit contextO
7NTEComments on resultsOYes
8DSCContinuation pointer for very large messagesO

Example Message

Realistic example with fake patient data. Paste into the HL7 Message Viewer to explore interactively.

HL7 v2.x Message
1MSH||^~\&|LIS|HOSPITAL_A|MIRTH_PROD|EPIC|20260310150000||ORU^R01^ORU_R01|RES00001|P|2.5.1
2PID||1||123456^^^HOSP_A^MR||Smith^John^M^^Mr.||19850315|M
3OBR||1|ORD20260310001^EPIC|ACC20260310001^LIS|85025^CBC with Auto Differential^CPT4|||20260310143205|20260310150000|||||||1234^Ahmed^Dr.^Khalid|||||ACC20260310001||LAB|F
4OBX||1|NM|718-7^Hemoglobin^LN||13.2|g/dL|13.5-17.5|L|||F|||20260310150000
5OBX||2|NM|789-8^Erythrocytes^LN||4.1|10*6/uL|4.5-5.5|L|||F|||20260310150000

Troubleshooting Scenarios

Results not appearing in the ordering system after delivery

Cause

The order linking identifiers don't match. OBR.2 (placer order number) in the result doesn't match OBR.2 in the original ORM^O01.

Fix

Verify the placer order number format is consistent between the ordering system's ORM and the lab/RIS ORU. The filler (lab/RIS) must echo back the exact placer order number it received.

Result values showing as garbled text

Cause

OBX.2 (value type) doesn't match the actual content of OBX.5. For example, OBX.2=NM but OBX.5 contains text like '> 100'.

Fix

Review OBX.2 for each result type. Numeric values should use NM. Text ranges like '> 100' or 'NEGATIVE' should use ST. Formatted text reports should use FT. Structured numerics (>100, ~10) should use SN.

Common Confusions

ORU^R01 (unsolicited results) vs ORM^O01 (order request). ORU flows from the ancillary system back to the ordering system — it's the answer. ORM flows from the ordering system to the ancillary system — it's the question. Also note: ORU^R01 can carry preliminary results (OBR.25=P) which are later superseded by final results (OBR.25=F). Ensure downstream systems handle both status values.

Related Message Types

Segment Reference

Paste this message into our viewer

Interactive HL7 parser. Decodes every field, validates structure, highlights errors. Free, no signup.

Open HL7 Message Viewer →

Need mapping templates?

The HL7 Integration Toolkit includes field mapping worksheets and interface spec templates for every major HL7 message type including ORU^R01.

View HL7 Integration Toolkit →
← Back to HL7 Message Types Reference