ORM — Order Message (general)

HL7 ORM messages carry orders — the requests one system makes of another to perform a service, whether a laboratory test, a radiology study, a medication, a diet, or a supply. ORM^O01 was the universal order message of HL7 v2 before v2.5, a single structure flexible enough to place, change, cancel, or hold an order across every clinical domain. It is still widespread in production interfaces despite being superseded for laboratory ordering by OML. This page explains what an ORM message represents, when it is sent, every segment the message can carry and what each one holds, and how an ORM message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.

What an ORM message represents

An ORM message — ORM stands for Order Message — communicates one or more orders and the action to take on each. The heart of the message is the repeating ORDER group, which opens with an ORC common order segment carrying the order control code that says what to do: place a new order (NW), cancel one (CA), hold it (HD), discontinue it (DC), or replace it. Beneath the ORC, an order-detail segment describes the thing being ordered — an OBR for a test or study, an RXO for a pharmacy order, an ODS for a diet.

The sender is the placer — the ordering application, typically the EHR or a departmental order-entry system — and the receiver is the filler, the ancillary system that will perform the service: the laboratory, radiology, or pharmacy. Because a single ORM message reports an action already decided by the placer, the ORC order control code is authoritative: the filler applies the requested action rather than negotiating it.

Every ORM message shares the same skeleton — an MSH header, an optional PATIENT group anchored by PID, and one or more ORDER groups each anchored by ORC. The order-detail segment chosen inside the ORDER group is what makes an ORM a lab order, a pharmacy order, or a diet order.

When an ORM message is sent

An ORM message is sent whenever the placer needs the filler to act on an order. A new order fires when a provider signs it; a cancellation or hold fires when the provider changes their mind or the patient's status changes; a status update fires as the order moves through its lifecycle. Because the ORDER group repeats, a single message can carry several orders placed together — a panel of labs, or a set of related studies.

Trigger event

The ORM message type carries a single trigger event:

• ORM^O01 – General order message.

Because ORM has one trigger event, the receiver's handling turns on the order control code in ORC-1 — NW, CA, HD, DC, and so on — rather than on the trigger code in MSH-9. A new order and a cancellation both arrive as ORM^O01; the order control code distinguishes them. Note that ORM was retired after v2.3.1 in favour of domain-specific order messages such as OML for laboratory, but the structure persists in HL7 v2.5.1 for backward compatibility and remains common in the field.

Integration topology

The diagram shows the ordering application emitting an order through the integration engine to the ancillary system that fills it.

{{diagram: ordering application / EHR → ORM message → integration engine → laboratory / radiology / pharmacy / dietary}}

Typical senders: EHR, CPOE / order-entry application, departmental ordering system.

Typical receivers: laboratory information system, radiology (RIS), pharmacy system, dietary, and other ancillary fillers.

Direction: typically unidirectional from placer to filler, though order status and acknowledgement often flow back on a companion interface.

Segments in an ORM message

The ORM_O01 message is organised into an optional PATIENT group and one or more repeating ORDER groups. Each ORDER group opens with an ORC and contains an ORDER_DETAIL group whose first segment is a choice — exactly one of OBR, RQD, RQ1, RXO, ODS, or ODT — that determines the order's domain. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The ORDER group from ORC through BLG repeats once per order, so a single ORM message can place, cancel, or update several orders together. Exactly one order-detail segment opens each ORDER_DETAIL group, and that choice determines whether the order is a test, a medication, or a diet. The canonical segment pages carry the full field-by-field detail.

Sample ORM message

Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.

MSH|^~&|EHR|MERCYGEN|LIS|MERCYGEN|20260701093000||ORM^O01^ORM_O01|MSG00031|P|2.5.1
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PV1|1|O|LAB^^^MERCYGEN||||1234^SMITH^JANE^A^^^MD|||MED
ORC|NW|ORD5501^EHR|||||||20260701093000|||1234^SMITH^JANE^A^^^MD
OBR|1|ORD5501^EHR||58410-2^CBC WITH DIFFERENTIAL^LN|||20260701093000|||||||||1234^SMITH^JANE^A^^^MD
DG1|1|ICD-10|D64.9^Anemia, unspecified^I10|ANEMIA|20260701093000|A

What this sample shows

The ORM^O01 in MSH-9 marks a general order message. PID carries the medical record number MR12345, and PV1 places the patient as an outpatient (O) in the lab with an ordering provider, giving the order its visit context. The ORC carries the order control code NW (new order) in ORC-1 and the placer order number ORD5501 in ORC-2. The OBR — the order-detail choice for this domain — identifies the CBC With Differential panel (LOINC 58410-2) in OBR-4. The DG1 carries the diagnosis that justifies the order.

Working with ORM messages

Read the order control code, not just the trigger event

Every ORM arrives as ORM^O01, so the trigger event tells you nothing about the action. Switch on the order control code in ORC-1: NW places a new order, CA cancels, HD holds, DC discontinues, XO changes an order. Treating every ORM as a new order duplicates orders the placer meant to cancel or change.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the placer order number in ORC-2 and filler order number in ORC-3 as the natural business key for an order. Order feeds are replayed after outages; treating a repeated control id as a duplicate prevents a replayed new-order message from placing the same order twice.

The order-detail choice determines the domain

Exactly one of OBR, RQD, RQ1, RXO, ODS, or ODT opens each ORDER_DETAIL group. Inspect which one is present before parsing the order detail — an RXO pharmacy order and an OBR lab order carry entirely different fields, and a parser expecting OBR will misread a medication order.

Multiple orders per message

The ORDER group repeats, so a single ORM message can carry several orders. Process each ORC/order-detail pair independently rather than reading only the first — a panel ordered together arrives in one message.

Vendor variance. ORM predates the domain-specific order messages, and senders differ widely in which optional groups and order-detail segments they populate; many lab interfaces still emit ORM^O01 where the standard now recommends OML^O21. Confirm a partner's order control codes and segment usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An ORM message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Patient and one ServiceRequest per order. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH, the Patient from PID and PD1, and a ServiceRequest from each ORC/OBR pair, with optional Encounter from the visit segments, Coverage from insurance, AllergyIntolerance from AL1, and Condition from DG1. A pharmacy order (RXO) produces a MedicationRequest, and a dietary or supply order can produce a SupplyRequest.

The Implementation Guide publishes an official Bundle map for ORM_O01.

Common pitfalls

Pitfall. Treating every ORM as a new order. The action lives in the order control code in ORC-1, not the trigger event; ignoring it turns cancellations and holds into duplicate new orders.

Pitfall. Assuming the order detail is always an OBR. The ORDER_DETAIL group opens with a choice of six segment types; a pharmacy (RXO) or dietary (ODS) order carries none of the fields an OBR parser expects.

Pitfall. Reading only the first order. The ORDER group repeats, so a message can carry several orders; processing only the first drops the rest.

How Vorro handles ORM messages

Vorro ingests the ORM feed over MLLP or another transport, deduplicates on MSH-10, and routes each order to the filler that performs it. Vorro switches on the order control code in ORC-1 to apply the correct action — new, cancel, hold, discontinue, or change — inspects the order-detail choice to determine the domain, and processes every order in the repeating ORDER group rather than only the first. Where a FHIR destination is configured, Vorro emits the corresponding Bundle using the Implementation Guide's published ORM_O01 map, producing one ServiceRequest per order and the appropriate MedicationRequest or SupplyRequest for pharmacy and supply orders.

Related messages

• OML — the laboratory order message that replaced ORM for lab ordering in v2.5+; carries first-class specimen and container detail.
• ORU — the observation result message that returns results against the order an ORM placed.
• ORC — the common order segment that anchors every ORDER group and carries the order control code.

Sources

• HL7 v2-to-FHIR IG — message maps index
• HL7 v2-to-FHIR IG — ORM_O01 to Bundle ConceptMap
• HL7 Messaging Standard Version 2.5.1 product brief
• HAPI HL7v2 v2.5.1 ORM_O01 message structure
• HAPI HL7v2 v2.5.1 ORM_O01_ORDER group structure
• HAPI HL7v2 v2.5.1 ORM_O01_ORDER_DETAIL group structure
• HAPI HL7v2 v2.5.1 ORM_O01_PATIENT group structure