OML — Order Message, Laboratory

HL7 OML messages carry laboratory orders — the requests a provider or ordering system makes of a laboratory, together with the first-class specimen and container detail that laboratory workflows depend on and that the older ORM message was never designed to carry. OML^O21 was introduced in HL7 v2.5 as the laboratory-specific successor to ORM^O01 for placing lab orders, and it is the message the standard now recommends for the laboratory domain. This page explains what an OML message represents, when it is sent, every segment the message can carry and what each one holds, and how an OML message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.

What an OML message represents

An OML message — OML stands for Order Message, Laboratory — communicates one or more laboratory orders and the action to take on each. Like every order message its heart is the repeating ORDER group anchored by an ORC whose order control code says what to do — place (NW), cancel (CA), hold (HD). What distinguishes OML from ORM is its structured specimen support: OML_O21 carries a SPECIMEN group built on the SPM specimen segment and a nested CONTAINER group built on the SAC specimen-container segment, so an order can describe exactly what specimen is to be collected, in which container, and under what conditions.

The sender is the placer — the EHR or laboratory order-entry system — and the receiver is the laboratory information system that will collect the specimen and perform the tests. Because a lab order turns on the specimen as much as the test, OML models the specimen as its own group rather than squeezing it into the observation request as ORM did.

Every OML message shares the same skeleton — an MSH header, an optional PATIENT group anchored by PID, and one or more ORDER groups anchored by ORC — with the observation request, specimen, and container detail nested inside each order.

When an OML message is sent

An OML message is sent whenever the laboratory needs to act on an order. A new order fires when a provider signs a lab request; a cancellation or hold fires when the order changes; specimen collection detail is carried when the placer knows it. Because the ORDER group repeats, a single message can carry several tests ordered together on one or more specimens.

Trigger event

The principal OML trigger event is:

• OML^O21 – Laboratory order.

The OML message family defines further trigger events for specimen- and container-centric ordering (for example OML^O33 and OML^O35), but OML^O21 is the general laboratory order and the one an integration team handles most often. As with ORM, the receiver's handling turns on the order control code in ORC-1 — a new order and a cancellation both arrive as OML^O21 and are distinguished by ORC-1.

Integration topology

The diagram shows the ordering application emitting a laboratory order through the integration engine to the laboratory that fills it.

{{diagram: ordering application / EHR → OML message → integration engine → laboratory information system / specimen collection / instrument manager}}

Typical senders: EHR, laboratory order-entry / CPOE application.

Typical receivers: laboratory information system, specimen collection and accessioning, and instrument-manager middleware.

Direction: typically unidirectional from placer to filler, with order status and results returning on companion ORU or OUL interfaces.

Segments in an OML message

The OML_O21 message is organised into an optional PATIENT group and one or more repeating ORDER groups. Each ORDER group opens with an ORC, followed by an optional TIMING group, an OBSERVATION_REQUEST group carrying the OBR and its SPECIMEN and observation detail, and optional financial and trial segments. 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; within it the SPECIMEN group repeats once per specimen and the CONTAINER group repeats once per physical container. A single OML message can therefore order several tests across several specimens and containers together. The canonical segment pages carry the full field-by-field detail.

Sample OML message

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

MSH|^~&|EHR|MERCYGEN|LIS|MERCYGEN|20260701090000||OML^O21^OML_O21|MSG00055|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|ORD6602^EHR|||||||20260701090000|||1234^SMITH^JANE^A^^^MD
OBR|1|ORD6602^EHR||58410-2^CBC WITH DIFFERENTIAL^LN|||20260701090000|||||||||1234^SMITH^JANE^A^^^MD
DG1|1|ICD-10|D64.9^Anemia, unspecified^I10|ANEMIA|20260701090000|A
SPM|1|SPEC001||BLD^Whole Blood^HL70487|||||||||||||20260701091500
SAC|||CTR001|||EDTA_TUBE

What this sample shows

The OML^O21 in MSH-9 marks a laboratory order. PID carries the medical record number MR12345, and PV1 supplies the visit context. The ORC carries the order control code NW (new order) in ORC-1 and the placer order number ORD6602. The OBR opens the OBSERVATION_REQUEST group and identifies the CBC With Differential panel (LOINC 58410-2) in OBR-4, and the DG1 supplies the justifying diagnosis. The SPM opens the SPECIMEN group, describing a whole-blood specimen (BLD) — the detail that distinguishes OML from ORM — and the nested SAC describes the EDTA tube it is collected into.

Working with OML messages

Read the order control code, not just the trigger event

Every OML arrives as OML^O21, so the trigger event does not tell you the action. Switch on the order control code in ORC-1: NW places a new order, CA cancels, HD holds, DC discontinues. Treating every OML as a new order duplicates orders the placer meant to cancel or change.

Use the specimen group — do not force OML into an ORM parser

OML's defining feature is its structured SPECIMEN group and nested CONTAINER group. Parse the SPM and SAC segments as the specimen and container the order applies to. An ORM-era parser that expects specimen detail inside the OBR will miss the specimen and container entirely.

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; deduplicating on the control id prevents a replayed message from placing the same order twice.

Multiple orders, specimens, and containers per message

The ORDER group repeats once per order, the SPECIMEN group once per specimen, and the CONTAINER group once per container. Process each nested group independently — a panel drawn into two tubes carries two CONTAINER groups, and attributing all results to one container loses chain-of-custody detail.

Vendor variance. Adoption of OML over ORM^O01 varies — many laboratories still receive orders as ORM even where OML is the recommended message — and senders differ in whether they populate the SPECIMEN and CONTAINER groups. Confirm a partner's message type and specimen handling against their interface specification rather than assuming the base standard.

FHIR equivalent

An OML message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Patient, one ServiceRequest per order, and a Specimen for the collected specimen. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH, the Patient from PID and PD1, a ServiceRequest from each ORC/TQ1/OBR combination, and a Specimen from the OBR and SPM detail, with optional Encounter from the visit segments, Coverage from insurance, Condition from DG1, and AllergyIntolerance from AL1.

The Implementation Guide publishes an official Bundle map for OML_O21.

Common pitfalls

Pitfall. Treating every OML 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. Ignoring the SPECIMEN and CONTAINER groups. The SPM and SAC detail is the reason OML exists; parsing an OML as if it were an ORM drops the specimen and container the laboratory needs to collect and accession the order.

Pitfall. Reading only the first order or specimen. The ORDER, SPECIMEN, and CONTAINER groups all repeat; processing only the first drops the rest.

How Vorro handles OML messages

Vorro ingests the OML feed over MLLP or another transport, deduplicates on MSH-10, and routes each order to the laboratory that fills it. Vorro switches on the order control code in ORC-1 to apply the correct action, parses the SPM specimen and nested SAC container detail as first-class specimen data, and processes every order, specimen, and container in the repeating groups rather than only the first. Where a FHIR destination is configured, Vorro emits the corresponding Bundle using the Implementation Guide's published OML_O21 map — one ServiceRequest per order and a Specimen resource from the specimen and container detail.

Related messages

• ORM — the general order message OML replaced for laboratory ordering; still common in legacy environments.
• ORU — the observation result message that returns results against the order an OML 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 — OML_O21 to Bundle ConceptMap
• HL7 Messaging Standard Version 2.5.1 product brief
• HAPI HL7v2 v2.5.1 OML_O21 message structure
• HAPI HL7v2 v2.5.1 OML_O21_ORDER group structure
• HAPI HL7v2 v2.5.1 OML_O21_OBSERVATION_REQUEST group structure
• HAPI HL7v2 v2.5.1 OML_O21_SPECIMEN group structure
• HAPI HL7v2 v2.5.1 OML_O21_CONTAINER group structure