HL7 ORG messages are the acknowledgement counterpart to the general clinical order — they travel from the fulfilling department or ancillary system back to the ordering application to confirm that an OMG^O19 general clinical order was received and accepted. An ORG message does not carry results; it is a transactional receipt that closes the request–acknowledge handshake, echoes back the order identifiers the sender needs for correlation, and surfaces any errors that prevented acceptance. This page explains what an ORG message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ORG response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an ORG message represents
An ORG message — ORG stands for General Clinical Order Response — communicates that the fulfilling system has received a general clinical order and is reporting on its acceptance. The core of the message is the MSA segment, which carries the acknowledgement code — AA for application accept, AE for application error, AR for application reject — and the original message control ID from MSH-10 of the triggering OMG. Alongside MSA, the ORC in the optional RESPONSE group echoes the placer order number back to the sender and, critically, assigns the filler order number that will identify the order in all subsequent communications from the fulfilling department. The OBR echoes the universal service identifier so the ordering system can confirm that the correct service was understood.
The sender is the fulfilling department or ancillary system — the same application that received the original OMG — and the receiver is the order-entry system or EHR that placed the order. ORG sits immediately downstream of the OMG in the order workflow: the ordering system sends an OMG, the fulfilling system responds with an ORG, and the filler order number established in that ORG is the key that links every subsequent status change and result back to the original order.
When an ORG message is sent
An ORG message is sent in response to an OMG^O19 general clinical order message. Each OMG that the fulfilling system receives — whether a new order, a cancellation request, a status change, or any other order lifecycle action — produces one ORG in reply. The acknowledgement code in MSA tells the sender whether the action was accepted or rejected; the order control code echoed in ORC confirms which lifecycle event was acknowledged.
Trigger event
The ORG message type carries a single trigger event:
ORG^O20– General clinical order response message.
Because ORG has one trigger event, the receiver's handling turns on the acknowledgement code in MSA — AA, AE, or AR — and on the order control code in the echoed ORC, rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the fulfilling department system returning an order response through the integration engine to the ordering application.
{{diagram: ancillary department system → ORG message → integration engine → order-entry / EHR}}
Typical senders: ancillary department system (cardiology, respiratory, physical therapy, nutrition), order management system, or any fulfilling application that receives general clinical orders.
Typical receivers: EHR order-entry module, CPOE system, ambulatory ordering application — the same system that originated the OMG^O19.
Direction: unidirectional response from the fulfilling system back to the ordering source, completing the request–acknowledge handshake.
Segments in an ORG message
The ORG_O20 message opens with header and acknowledgement segments, followed by an optional RESPONSE group that carries patient context and one or more echoed orders. Within the RESPONSE group, the patient sub-group (PID, optional NTE, optional PV1 and PV2) is itself optional, and the ORDER group repeats once per acknowledged order. Each ORDER group contains the echoed ORC and OBR along with their supporting 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every ORG message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (ORG^O20), carries the message control id in MSH-10, and pins the HL7 version. The sending and receiving applications are reversed relative to the originating OMG — the fulfilling department is now the sender. |
MSA | Message Acknowledgement. The required acknowledgement segment. MSA-1 carries the acknowledgement code (AA application accept, AE application error, AR application reject) and MSA-2 echoes the message control id from MSH-10 of the originating OMG message. Required; it is the segment that makes ORG an acknowledgement rather than a standalone order message. |
[{ERR}] | Error. Error detail when MSA-1 is AE or AR — the error code, location, severity, and a human-readable description. Optional and repeating to accommodate multiple errors on a rejected message. |
[{NTE}] | Notes and Comments. Message-level notes applying to the acknowledgement as a whole. Optional and repeating. |
[PID] | Patient Identification. Echoes or confirms the patient identity from the originating OMG. Present only when the RESPONSE group is included. The RESPONSE group as a whole is optional, so a pure application-level ACK can omit patient and order detail entirely. |
[{NTE}] | Notes and Comments. Patient-level notes within the RESPONSE group. Optional and repeating. |
[PV1] | Patient Visit. The encounter context from the original order, echoed when visit data is relevant to the acknowledgement. Optional. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason and expected dates when a visit is present. Optional. |
ORC | Common Order. Opens each ORDER group within the RESPONSE. Echoes the placer order number from ORC-2 of the originating OMG and, on acceptance, assigns the filler order number in ORC-3. The filler order number established here is the persistent identifier that the fulfilling department uses in all subsequent messages — status updates, results, and cancellation confirmations — for this order. The order group repeats once per acknowledged order. |
[{TQ1, [{TQ2}]}] | Timing/Quantity and Relationship. Echoes or confirms the dosing schedule and timing from the original order (TQ1), and the relationship of this order's timing to another order when sequenced services apply (TQ2). Optional and repeating. |
OBR | Observation Request. Echoes the universal service identifier from OBR-4 of the originating OMG, confirming that the fulfilling system correctly interpreted the service being requested. Also echoes the placer and filler order numbers in OBR-2 and OBR-3. Present within each ORDER group. |
[{NTE}] | Notes and Comments. Order-level notes following the echoed OBR — clarifications or instructions from the fulfilling department. Optional and repeating. |
[CTD] | Contact Data. Contact information for a provider or facility at the fulfilling department relevant to the acknowledged order. Optional. |
[{OBX, [{NTE}]}] | Observation/Result group. Observations returned at the time of acknowledgement — scheduling confirmations, queue position, or preliminary clinical data. Each OBX may carry its own optional, repeating NTE comments. The observation group as a whole is optional and repeating; results proper travel in a subsequent ORU message rather than in the ORG. |
[ ] = optional, { } = repeating
The ORDER group from ORC through the observation group repeats once per acknowledged order, so a single ORG message can confirm several orders sent together in one OMG. The canonical segment pages carry the full field-by-field detail.
Sample ORG message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|CARDIO|MERCYGEN|CPOE|MERCYGEN|20260604083200||ORG^O20^ORG_O20|MSG00042|P|2.5.1
MSA|AA|MSG00041
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^M||19721115|F
PV1|1|I|3W^302^A^MERCYGEN||||1234^PATEL^ROHAN^^^DR^^^NPI
ORC|OK|ORD20260604-001^CPOE|CARD-2026-00391^CARDIO
TQ1|1||||||20260604090000||R^Routine^HL70485
OBR|1|ORD20260604-001^CPOE|CARD-2026-00391^CARDIO|93000^12-Lead ECG^CPT4
What this sample shows
The ORG^O20 in MSH-9 marks a general clinical order response. The sender and receiver in MSH-3 and MSH-5 are reversed relative to the originating OMG — CARDIO is now the sender, CPOE the receiver. MSA carries acknowledgement code AA (application accept) in MSA-1 and echoes the original message control id MSG00041 in MSA-2, closing the handshake. PID and PV1 echo the patient and visit context. ORC carries the order control code OK (order accepted), echoes the placer order number ORD20260604-001 in ORC-2, and assigns the filler order number CARD-2026-00391 in ORC-3 — the identifier the cardiology department will use for this order going forward. TQ1 confirms the requested timing. The OBR echoes both order numbers and the universal service identifier 93000 (12-Lead ECG), confirming the correct service was understood.
Working with ORG messages
Capture the filler order number from ORC-3
The most important field in an ORG message is ORC-3, the filler order number assigned by the fulfilling department. This number does not exist in the originating OMG — it is created on acceptance — and it is the key that links every subsequent message from the fulfilling system back to this order: status updates, scheduling confirmations, and results returned in ORU messages. Store it immediately on receipt of an AA acknowledgement and associate it with the placer order number in ORC-2.
Read the acknowledgement code before processing order detail
The order detail in the RESPONSE group is meaningful only when MSA-1 is AA. When MSA-1 is AE or AR, the ERR segment carries the reason for rejection, and the ordering system must take corrective action — typically alerting a clinician or routing the message for manual review — rather than treating the echoed order numbers as accepted. Processing ORC or OBR content without first checking MSA-1 silently discards error information.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key. Integration feeds are replayed after outages, and a replayed AA response with the same control id must not overwrite a filler order number that has already been stored or trigger a duplicate acceptance notification. Treat the placer order number in ORC-2 together with MSA-2 as the natural business key for a specific acknowledgement event.
The RESPONSE group is optional
Some fulfilling systems send a minimal ORG containing only MSH and MSA, with no patient or order detail. This is valid for an application-level acknowledgement, but it means the filler order number will not be present — the ordering system must request it through a subsequent status query or wait for it to appear in a later message. Confirm with each integration partner whether they populate the RESPONSE group, and do not assume ORC-3 will always be present on an AA.
Vendor variance. The depth of the RESPONSE group varies widely in practice. Some fulfilling systems echo the full patient, visit, timing, and observation request segments; others return only
MSH,MSA, and a minimalORC. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A general clinical order response conceptually maps to the echoed FHIR ServiceRequest resource — the same resource that the originating OMG^O19 produces — with the acknowledgement status represented in the ServiceRequest.status field.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no official message map for ORG_O20 — among the order response message types, ORG has no entry in the message maps index, and no ConceptMap exists for the ORG message structure. A FHIR ServiceRequest produced from an ORG message is therefore mapped manually, taking the service code from the echoed OBR-4, the placer order number from ORC-2, the filler order number from ORC-3, and the acceptance status from MSA-1.
Common pitfalls
Pitfall. Ignoring
MSA-1and treating every ORG as an acceptance. AnAEorARcode signals that the order was not accepted; processing the echoed order numbers as confirmed when the message actually carries an error silently loses the rejection and leaves the ordering system believing an order is in progress when it was never accepted.
Pitfall. Failing to store the filler order number from
ORC-3. The filler order number is assigned once — in the firstAAORG for an order — and is required to correlate all subsequent messages from the fulfilling department. A system that discardsORC-3cannot reliably match incoming status updates or results to the correct order.
Pitfall. Assuming the RESPONSE group is always present. A valid ORG can consist of only
MSHandMSA. Systems that require patient or order detail from the ORG without first confirming the partner sends it will fail silently when a minimal acknowledgement arrives.
How Vorro handles ORG messages
Vorro ingests the ORG feed over MLLP or another transport, deduplicates on MSH-10, and reads the acknowledgement code from MSA before any further processing. On AA, Vorro captures the filler order number from ORC and stores it against the originating placer order number so that downstream results from ORU messages can be correlated back to the correct order. On AE or AR, Vorro routes the message — along with the error detail from ERR — to the configured error queue or alert channel for clinician or analyst review. Where a FHIR destination is configured, Vorro maps the echoed order to a ServiceRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OMG — the general clinical order message that an ORG acknowledges; the ORG^O20 is always a response to an OMG^O19.
- ORM — the older general-purpose order message for which ORR provides the equivalent acknowledgement.
- ORR — the general order response message that acknowledges ORM orders, analogous to ORG for OMG.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for ORG_O20
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for the ORG message
- HL7 Messaging Standard Version 2.5.1 product brief
