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

Two systems share one order

The placer requests a service; the filler performs it. An EHR may place a laboratory test, while the laboratory information system accepts the order, manages the specimen and work, and returns a result. Each system assigns identifiers in its own namespace, so safe exchange preserves both sides of the correlation ¹.

The message family depends on version, domain, and profile. ORM^O01 is the classic general-order interaction. Later versions define more specific structures such as OMG^O19 for a general clinical order and OML events for laboratory orders. Do not translate between them by changing only MSH-9; the segment grammar and response pattern can differ ¹.

ORC describes the order action

The ORC segment carries information common to an order regardless of service type. Consequential fields include:

• ORC-1 — order control, the requested or reported action;
• ORC-2 — placer order number;
• ORC-3 — filler order number;
• ORC-4 — placer order group number;
• ORC-5 — order status;
• ordering, entering, verifying, timing, organization, and reason fields as profiled.

Do not confuse order control with order status. NW can request a new order; CA can request cancellation; OK can acknowledge an accepted order action; SC communicates a status change under the interaction’s rules. ORC-5 separately describes state. The allowable combination, sender responsibility, and response message belong in the implementation guide.

The order number fields use composite identifiers. Preserve identifier value, namespace or assigning authority, and the side that assigned it. Matching on a naked order string can collide across facilities or after system migration.

OBR describes the observation request

For diagnostic orders, OBR describes what is requested and supplies domain detail. Common fields include:

• OBR-2 and OBR-3 — placer and filler order numbers;
• OBR-4 — universal service identifier: the requested test or study;
• requested, collection, receipt, and result-status times;
• ordering provider, specimen-related information, priority, and reason fields.

The exact field usage varies by version and profile. Modern laboratory messages can use the SPM segment for specimen detail rather than forcing every specimen fact into OBR. Treat the profile as the wire contract.

An ORC/OBR pair is a group. If several orders repeat in one message, maintain group boundaries. Do not attach every OBR to the first ORC or collapse several specimens into one request.

A worked order lifecycle

Suppose an EHR orders a basic metabolic panel:

1. The placer assigns EHR-45017 and sends a new-order action.
2. The filler validates patient, encounter, service code, timing, and specimen requirements.
3. The filler accepts the order, assigns LIS-88301, and returns an application response under the agreed message pattern.
4. Collection and processing change order state.
5. The filler returns preliminary, final, corrected, or cancelled results as defined by the result workflow.

The crosswalk is the durable relationship:

These identifiers must not be substituted. A result’s message control ID can change on resend; the business order correlation should remain stable.

Acknowledgment is not order acceptance

An HL7 accept or application ACK answers the message-control conversation. The domain response—such as an ORR, ORG, or ORL interaction—can carry order-level acceptance, assigned filler number, status, and errors. The version and profile decide which response is used ².

This distinction prevents a common mistake: interpreting a technical AA as proof that the laboratory accepted and scheduled every order in the payload. A message can be structurally accepted while an individual order is rejected or held for missing information.

Changes, cancellations, and race conditions

Order workflows are not append-only happy paths. Consider:

• cancellation arrives after collection has begun;
• change request and result cross in flight;
• duplicate new order is retried with a new message control ID;
• filler sends a status update before the placer records the filler number;
• parent order creates reflex or add-on child orders;
• corrected result follows a final result;
• one order in a multi-order message fails while others succeed.

Define whether actions are allowed in each state, how partial success is reported, and which system owns the authoritative order state. A cancellation request is not necessarily a completed cancellation. Preserve requested action, response, effective state, reason, actor, and time.

Link result to request without guesswork

An ORU result commonly repeats order identifiers in OBR and carries observations in OBX. Correlation should use the agreed placer/filler identifiers, patient and encounter context, service code, and specimen context—not patient name plus “most recent test.”

Reconciliation should detect:

• result with no matching order;
• order with no expected result after a defined interval;
• result matched to multiple orders;
• filler number changed unexpectedly;
• final result followed by an unhandled correction;
• cancelled order that later produces a result.

Build the conformance table

For every order action, record:

Practice

Model new, accepted, in-progress, completed, cancellation-requested, cancelled, and corrected states for one laboratory order. Add duplicate send, delayed response, cancellation after collection, and result-before-domain-response cases. Then write one test message and expected response for each transition. The goal is not memorizing ORC codes; it is proving that both systems implement the same state machine.