HL7 OMG Messages: General Clinical Order

HL7 OMG messages carry a general clinical order — the instruction, sent from an ordering provider system to a fulfilling department or ancillary service, to perform a clinical service that is neither a laboratory test nor a radiology exam. An OMG message is used when the ordered service does not fit the specialised lab or imaging workflows handled by OML or the older general-purpose ORM, and it encodes the order with enough clinical context — patient demographics, visit, diagnoses, specimen, and observations — for the receiving system to act without making additional inquiries. This page explains what an OMG message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMG order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an OMG message represents

An OMG message — OMG stands for General Clinical Order Message — communicates a clinical order for any service outside the dedicated lab and imaging domains. Cardiology studies, respiratory therapy, physical therapy, nutrition assessments, EEG monitoring, wound care, and similar ancillary services are all candidates for an OMG. The core of the message is the OBR segment, which carries the universal service identifier — the coded name of the service being ordered — together with the requested date and time, the ordering and results-reporting providers, and the specimen source when a specimen is required for the procedure.

The sender is the order-entry system — typically an EHR or CPOE application — and the receivers are the department or ancillary system that will fulfil the order, together with any scheduling, billing, or results-routing systems that need to act on it. OMG sits at the beginning of the order workflow: downstream, results may return as an ORU observation message keyed back to the same placer and filler order numbers established in the OMG.

When an OMG message is sent

An OMG message is sent when a clinician places a new general clinical order, and subsequent messages carry status changes through the same trigger event. A new order, an update, a cancellation request, and an order acknowledgement all travel as OMG^O19 messages distinguished by the order control code in the ORC segment — NW for a new order, CA for a cancellation request, SC for a status change, and so on. The receiving system branches on the ORC order control code rather than on the trigger event code.

Trigger event

The OMG message type carries a single trigger event:

OMG^O19 – General clinical order message.

Because OMG has one trigger event, all order lifecycle actions — new, change, cancel, hold, release — are distinguished by the order control code in ORC, not by separate trigger codes in MSH-9.

Integration topology

The diagram shows the order-entry system emitting a clinical order event through the integration engine to the systems that fulfil and track it.

{{diagram: order-entry / EHR → OMG message → integration engine → ancillary department system / scheduling / billing / results routing}}

Typical senders: EHR order-entry module, CPOE system, ambulatory ordering application.

Typical receivers: ancillary department system (cardiology, respiratory, physical therapy, nutrition), scheduling system, billing or charge capture, and results-routing infrastructure.

Direction: primarily unidirectional from the ordering source to the fulfilling department, with acknowledgements returning to the sender and results flowing back separately as ORU messages.

Segments in an OMG message

The OMG_O19 message is organised into groups: an optional PATIENT group (PID through AL1) and one or more ORDER groups, each opening with ORC and containing the observation request and its supporting segments. Within an order, specimen data can be carried in one or more SPECIMEN groups, each pairing an SPM specimen segment with its own observations. 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.

Segment	Description
`MSH`	Message Header. Opens every OMG message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (`OMG^O19`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`[{SFT}]`	Software Segment. Identifies the software product behind the sender — vendor, product, and version. Useful when order behaviour differs across EHR or CPOE releases.
`[PID]`	Patient Identification. Identifies the patient the order was placed for — the identifier list in `PID-3`, the name in `PID-5`. Required when the PATIENT group is present; the group as a whole is optional, though most clinical workflows include it.
`[PD1]`	Patient Additional Demographic. Supplements `PID` with data such as the patient's primary-care facility and disability status.
`[{NTE}]`	Notes and Comments. Patient-level notes that apply to the order context as a whole. Optional and repeating.
`[PV1]`	Patient Visit. The encounter the order belongs to — patient class, assigned location, and the providers on the visit. Optional within the PATIENT group.
`[PV2]`	Patient Visit Additional. Companion to `PV1` with admit reason and expected dates when a visit is present.
`[{IN1, [IN2], [IN3]}]`	Insurance. The patient's insurance coverage — plan, group, and subscriber data (`IN1`); additional benefits and coordination information (`IN2`); Medicare and certification detail (`IN3`). Optional and repeating to accommodate multiple insurance layers.
`[GT1]`	Guarantor. The party financially responsible for the order. Optional.
`[{AL1}]`	Allergy Information. Patient allergies carried with the order. Optional and repeating.
`ORC`	Common Order. Opens each order group and is the authoritative carrier of the order's lifecycle state. `ORC-1` holds the order control code (`NW`, `CA`, `SC`, and others) that tells the receiver what action to take. `ORC-2` carries the placer order number assigned by the ordering system; `ORC-3` carries the filler order number assigned by the fulfilling department. Required, and the order group repeats once per ordered service.
`[{TQ1, [{TQ2}]}]`	Timing/Quantity and Relationship. The schedule and timing for the order (`TQ1`), and the relationship of this order's timing to another order when sequenced or conditional services apply (`TQ2`). Optional and repeating; introduced in v2.5 as the replacement for the deprecated quantity/timing field.
`[{ROL}]`	Role. Provider roles associated with the order — ordering provider, referring provider, and others — when the detail exceeds what `ORC` carries. Optional and repeating.
`[OBR]`	Observation Request. The clinical core of the order. `OBR-4` carries the universal service identifier — the coded name of the service — and is the field that tells the fulfilling department exactly what is being requested. `OBR-6` carries the requested date and time; `OBR-5` the priority (`R` routine, `S` stat, `A` as-available); `OBR-15` the specimen source when a specimen drives the procedure; `OBR-16` the ordering provider; and `OBR-28` the results-reporting provider. Optional at the segment level but always present in practice, since it carries the substance of the order.
`[{NTE}]`	Notes and Comments. Order-level notes following the `OBR` — clinical instructions, special handling requirements, or free-text detail for the fulfilling department. Optional and repeating.
`[CTD]`	Contact Data. Contact information for a provider or facility relevant to the order. Optional.
`[{DG1}]`	Diagnosis. The diagnoses supporting the order — the clinical indication — coded in `DG1-3`. Optional and repeating; required by many payers and ancillary departments to authorise the service.
`[{OBX}]`	Observation/Result. Order-time observations supporting or contextualising the order — patient height, weight, clinical findings, or other data the fulfilling department needs before performing the service. Optional and repeating.
`[{{PRT}}]`	Participation Information. Participation details — device, location, or provider — associated with an observation. Optional and repeating at the order level; appears after `OBX` when present.
`[{FT1}]`	Financial Transaction. Charge and billing information associated with the order. Optional and repeating to accommodate multiple charge and pricing scenarios.
`[{CTI}]`	Clinical Trial Identification. Associates the order with a clinical trial — study, phase, and time point. Optional and repeating.
`[BLG]`	Billing. Billing instructions specific to this order — charge type and account. Optional.
`[{SPM, [{OBX}]}]`	Specimen group. One `SPM` per specimen associated with the order, each carrying specimen type, source, collection details, and handling requirements. Each specimen may carry its own optional, repeating `OBX` observations — specimen condition, volume, or collection site detail. The specimen group as a whole is optional and repeating.

[ ] = optional, { } = repeating

The order group from ORC through the specimen group repeats once per ordered service, so a single OMG message can carry several orders for one patient encounter. The canonical segment pages carry the full field-by-field detail.

Sample OMG message

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

MSH|^~&|CPOE|MERCYGEN|CARDIO|MERCYGEN|20260604083000||OMG^O19^OMG_O19|MSG00041|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^M||19721115|F
PV1|1|I|3W^302^A^MERCYGEN||||1234^PATEL^ROHAN^^^DR^^^NPI
ORC|NW|ORD20260604-001^CPOE||||||20260604083000|||1234^PATEL^ROHAN^^^DR^^^NPI
TQ1|1||||||20260604090000||R^Routine^HL70485
OBR|1|ORD20260604-001^CPOE||93000^12-Lead ECG^CPT4|R|20260604090000|||||||||1234^PATEL^ROHAN^^^DR^^^NPI
NTE|1||Perform resting 12-lead ECG. Patient reports intermittent palpitations.
DG1|1||I49.9^Cardiac arrhythmia, unspecified^ICD-10-CM

What this sample shows

The OMG^O19 in MSH-9 marks a general clinical order message. PID carries the medical record number MR98765. PV1 places the patient in an inpatient bed on unit 3W, room 302. ORC carries the order control code NW — a new order — with placer order number ORD20260604-001 assigned by the CPOE system, and ordering provider 1234^PATEL^ROHAN. TQ1 requests the study at 09:00 with routine priority. The OBR names the service as 93000 (12-Lead ECG, CPT4) in OBR-4, sets priority to R (Routine) in OBR-5, and repeats the requesting provider in OBR-16. The NTE passes a clinical note to the cardiology department. The DG1 carries the supporting diagnosis I49.9 — the clinical indication authorising the study.

Working with OMG messages

Branch on ORC order control code, not trigger event

Because OMG^O19 is the only trigger event for the OMG message type, all order lifecycle actions travel under the same MSH-9 value. Read ORC-1 — the order control code — to determine what the message is asking: NW initiates a new order, CA requests a cancellation, SC updates the order status, HD places the order on hold, and RL releases it. Routing logic that inspects only MSH-9 cannot distinguish a new order from a cancellation.

Link orders and results through placer and filler numbers

The placer order number in ORC-2 (and OBR-2) is assigned by the ordering system and does not change through the order lifecycle. The filler order number in ORC-3 (and OBR-3) is assigned by the fulfilling department when it accepts the order. Results returned in an ORU message reference both numbers in their OBR segment, so the original order and its results can be joined on either key. Preserve both numbers from the initial NW message and carry them through every status-change message.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. Integration feeds are replayed after outages, and a replayed NW message with the same control id must not create a duplicate order. Treat the placer order number in ORC-2 together with the order control code in ORC-1 as the natural business key for order lifecycle events.

Diagnosis is required by many receivers

The DG1 segment carrying the clinical indication is optional in the standard but effectively required by most ancillary departments and payers to authorise a service. Validate that DG1-3 is populated and correctly coded before forwarding the message; a missing or malformed diagnosis is a common cause of order rejection at the receiving system.

Vendor variance. The OBR segment is technically optional in the OMG_O19 structure, but every real-world implementation includes it — it is the only place in the message where the universal service identifier lives. Similarly, some senders populate specimen data in OBR-15 (specimen source) while others use the SPM specimen group, and some systems send both. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A general clinical order corresponds to the FHIR ServiceRequest resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OMG_O19 — among the order message types, only OML lab and ORM general order have entries in the message maps index, and no ConceptMap exists for the OMG message structure. A FHIR ServiceRequest produced from an OMG message is therefore mapped manually, taking the service code from OBR-4, the requested datetime from OBR-6, the priority from OBR-5, the ordering provider from OBR-16, the supporting diagnoses from DG1, and the patient context from PID.

Common pitfalls

Pitfall. Treating every OMG^O19 as a new order without reading ORC-1. A cancellation request (CA) or status change (SC) carries the same trigger event as a new order (NW); applying new-order processing to a cancellation duplicates the order rather than withdrawing it.

Pitfall. Dropping the filler order number on status-change messages. When a department sends back an acknowledgement with a filler order number, that number must be stored and echoed in every subsequent message for the same order. Systems that fail to persist ORC-3 lose the ability to correlate status changes and results back to the original order.

Pitfall. Ignoring DG1 as optional. Many ancillary systems and payers will reject or queue an order without a valid diagnosis code. Treat a missing DG1-3 as a validation error rather than a warning, particularly for orders that require prior authorisation.

How Vorro handles OMG messages

Vorro ingests the OMG feed over MLLP or another transport, deduplicates on MSH-10, and routes each order to every subscribed destination in the format that system expects — the ancillary department, scheduling, and billing. Vorro reads the order control code from ORC to apply the correct lifecycle action, extracts the universal service identifier and clinical context from OBR, and links each order to its placer and filler numbers so that downstream results from ORU messages can be correlated back to the originating order. Where a FHIR destination is configured, Vorro maps the order to a ServiceRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

ORM — the older general-purpose order message that OMG supersedes for non-lab, non-imaging orders in v2.5 and later.
OML — the laboratory order message for test orders requiring lab processing.
ORU — the observation result message that carries results back from the fulfilling department, keyed to the placer and filler order numbers established in the OMG.

Sources

HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMG_O19
HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for the OMG message
HL7 Messaging Standard Version 2.5.1 product brief

← Back to HL7 v2 Guide