^R30
ORU^R30 — Unsolicited Point-of-Care Observation
ORU^R30 is an unsolicited observation result message specifically designed for point-of-care testing (POCT) devices that push results directly without a prior order. Unlike ORU^R01, it does not require a matching order to exist in the receiving system.
When Is This Sent?
Used by POC devices (glucometers, bedside monitors, i-STAT analyzers) that push results without a prior order. Also used for continuous monitoring data streams from bedside equipment.
Real-World Usage
ORU^R30 is common in ICU and ward POCT workflows where devices like glucometers and blood gas analyzers generate results at the bedside without a formal CPOE order. The receiving system (EHR or middleware) must be configured to accept unsolicited results and create an implicit order if needed. Many middleware solutions (e.g., Orchard Harvest, Data Innovations) normalize ORU^R30 from POC devices before forwarding.
Message Structure
Segment names link to their field-level reference pages.
| # | Segment | Purpose in this message | Req | Repeat |
|---|---|---|---|---|
| 1 | MSH | Message header with ORU^R30 in MSH.9 | R | — |
| 2 | PID | Patient demographics — patient identification is critical for unsolicited results | R | — |
| 3 | PV1 | Visit context — location where the POC test was performed | R | — |
| 4 | ORC | Order common segment — ORC.1=RE (observations to follow) for unsolicited results | R | — |
| 5 | OBR | Observation request identifying the test type performed | R | — |
| 6 | OBX | Result value(s) from the POC device | R | Yes |
| 7 | NTE | Device or operator notes | O | Yes |
Example Message
Realistic example with fake patient data. Paste into the HL7 Message Viewer to explore interactively.
1MSH||^~\&|GLUCOMETER|HOSPITAL_A|MIDDLEWARE|HOSPITAL_A|20260310150000||ORU^R30^ORU_R30|POC00001|P|2.5.1 2PID||1||123456^^^HOSP_A^MR||Smith^John^M^^Mr.||19850315|M 3PV1||1|I|4A^201^1^^^HOSP_A 4ORC||RE 5OBR||1|||2345-7^Glucose^LN|||20260310145900 6OBX||1|NM|2345-7^Glucose^LN||142|mg/dL|70-100|H|||F|||20260310145900
Troubleshooting Scenarios
POC results rejected by EHR with 'order not found' error
Cause
The EHR is configured to require a matching order for all ORU messages, including ORU^R30. It is treating the unsolicited result like a standard ORU^R01.
Fix
Configure the EHR to accept ORU^R30 as unsolicited (no prior order required). Many EHRs have a separate POCT result handling configuration. Alternatively, use a middleware layer to pre-create shadow orders before forwarding results.
Patient not matched — results posted to wrong patient or lost
Cause
PID.3 (patient identifier) from the POC device doesn't match the identifier format the EHR uses for patient matching. Devices often store only a partial MRN.
Fix
Review PID.3 from the device — confirm the MRN format, length, and assigning authority match the EHR's patient matching rules. Consider using a middleware solution that enriches PID demographics before forwarding.
Common Confusions
ORU^R30 (unsolicited POCT) vs ORU^R01 (standard unsolicited result). Both deliver results, but ORU^R01 typically references a prior order via OBR.2/OBR.3. ORU^R30 is explicitly unsolicited and does not require a prior order. In practice many systems use ORU^R01 for all result types — check the receiving system's documentation to see whether it distinguishes between the two trigger events.
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^R30.
View HL7 Integration Toolkit →