Order Workflow — ORM/OMG and the ORC and OBR Segments

The placer and the filler

Ordering is a conversation between two roles. The placer is the application that requests something — a lab test, an imaging study, a medication. The filler is the application that performs it and owns the result. Almost every order interface is structured around this pair, and HL7 gives each side its own identifier so a single order can be tracked across systems even as both assign their own numbers to it ¹.

The order messages

The classic general order message is ORM^O01; newer versions introduced domain-specific order messages such as OMG^O19 (general clinical order) that refine the same idea ¹. Whichever is used, two segments do the heavy lifting:

• ORC — Common Order. Carries the information common to any order regardless of what is being ordered: the order control code (e.g., NW new order, CA cancel, OK accepted), the placer and filler order numbers, the ordering provider, and timing. ORC is what makes an order trackable and cancellable across its life.
• OBR — Observation Request. Carries what is specifically being requested: the test or study code, the requested date/time, the specimen, and the priority.

A single message can contain repeating ORC/OBR pairs, so one message may place several related orders at once ².

Order control codes drive the state machine

The ORC-1 order control code turns a static message into a workflow. A new order is NW; the filler accepting it replies with OK; a cancellation is CA; a status change is SC. The same ORC/OBR structure thus carries the entire life of an order — placed, accepted, in progress, cancelled, completed — by changing one code rather than inventing new message types ¹.

From order to result

When the filler completes the work, it returns results in an ORU^R01 message — the subject of the next two lessons. The link between request and result is the OBR: results echo the order’s OBR so the placer can match each result back to the order that requested it, and then the individual values arrive as OBX observation segments beneath it.

Keep the roles straight and the rest follows: the placer asks (ORC + OBR), the filler confirms and works the order (ORC codes), and the filler reports (ORU with OBR + OBX). That request-and-report loop is the backbone of clinical data exchange.