HL7 ORU_R30 Point-of-Care Observation Without Existing Order

The result arrives first, and the receiving system is expected to create the order.
HL7 message structure ORU_R30 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
PID
 Patient Identification Yes No
PD1
 Patient Additional Demographic No No
ORU_R30.VISIT
 Visit group No No
PV1
 Patient Visit Yes No
PV2
 Patient Visit - Additional Information No No
ORC
 Common Order Yes No
OBR
 Observation Request Yes No
NTE
 Notes and Comments No Yes
ORU_R30.TIMING_QTY
 Timing Quantity group No Yes
TQ1
 Timing/Quantity Yes No
TQ2
 Timing/Quantity Relationship No Yes
ORU_R30.OBSERVATION
 Observation group Yes Yes
OBX
 Observation/Result Yes No
NTE
 Notes and Comments No Yes

ORU_R30 is for point-of-care observations performed without a pre-existing order in the receiving system. The message carries the patient, visit, order shell, observation request, and results, and instructs the receiver to create an order around those observations.

This happens in real life when workflow outruns order entry: a clinician verbally asks for a bedside test, a remote site performs a measurement, or a device captures a result before the LIS has a matching order. R30 is the standard way to make that event explicit instead of pretending an order always existed.

A small ORU_R30 example

MSH|^~\&|POCDEVICE|CITYHOSP|LIS|CITYHOSP|20260715123000||ORU^R30^ORU_R30|ORU300001|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|I|EDOBS^12^1^CITYHOSP||||12345^Careful^Clara|||||||||||VN000345^^^CITYHOSP^VN ORC|NW|POC448812^POCDEVICE||| OBR|1|POC448812^POCDEVICE||2339-0^Glucose^LN|||20260715122500 OBX|1|NM|2339-0^Glucose^LN||7.8|mmol/L|3.9-7.7|H|||F

What systems do with it

The sender may be a point-of-care device, device middleware, nursing application, or integration engine. The receiver is often an LIS, EHR, or order/result repository. The receiver creates an order or order-like record, files the observation, and returns the identifiers needed for future correlation.

This is not just a normal ORU_R01. R01 reports observations against an order context that usually already exists. R30 asks the receiver to create that context.

How to read the structure

The local structure starts with MSH, PID, optional PD1, optional visit context through PV1 and PV2, required ORC, required OBR, optional timing through TQ1 and TQ2, and one or more observation groups with required OBX.

Implementation traps

The hardest part is order creation. If the receiver cannot create the order, it needs to return a clear application-level error rather than filing an orphan result. Also make sure retries are idempotent; a resent R30 after an ACK problem should not create duplicate orders.

Patient and visit context matter more than usual here. Without a good patient identifier, location, responsible provider, and local ordering rules, the receiver may create an order that nobody owns.

Reference notes

The HL7 v2+ ORU_R30 page says this trigger instructs the receiving system to create a new order for the observations in the message and describes point-of-care workflows where order entry did not happen before testing.