HL7 ORR Messages: General Order Response

HL7 ORR messages are the application-level response to an order — the message a filler sends back to confirm that it received, accepted, or rejected the order it was asked to act on. An ORR message answers an ORM general order message, telling the placer what the filler did with the request and, when needed, echoing the order back with the filler's own identifiers attached. This page explains what an ORR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ORR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ORR message represents

An ORR message — ORR stands for General Order Response — is the application acknowledgment to an ORM order. Where the ORM asks a filler to do something — place a new order, cancel one, hold one — the ORR reports the outcome of that request back to the placer. The core of the message is the MSA segment, which carries the acknowledgment code and ties the response to the original message, optionally followed by the order itself echoed back so the placer can see what the filler now holds.

The sender of an ORR is the filler — the laboratory, radiology, or pharmacy system that received the order — and the receiver is the placer that originally sent the ORM. The response is solicited: it is returned in reply to a specific order message rather than broadcast. What the response means turns on two codes read together — the acknowledgment code in MSA and the order control code in ORC — because the same message type carries an acceptance, a rejection, and a confirmation of a cancellation.

When an ORR message is sent

An ORR message is sent in reply to an ORM order, once the filler has decided what it will do with that order. A new-order request returns an ORR confirming the order was accepted (or reporting why it was not); a cancellation request returns an ORR confirming the cancellation. Because the response is keyed to the original message, the placer correlates it through the message control id echoed in MSA-2.

Trigger event

The ORR message type carries a single trigger event:

ORR^O02 – General order response message; the response to any ORM^O01.

Because ORR has one trigger event, the receiver's handling turns on the contents of the message — the acknowledgment code in MSA-1 and the order control code in ORC-1 — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the filler returning an order response through the integration engine to the placer that sent the original order.

{{diagram: placer system → ORM order → integration engine → filler system → ORR response → integration engine → placer system}}

Typical senders: laboratory information system, radiology information system, pharmacy system — the filler that received the order.

Typical receivers: the order-placing application (EHR, CPOE) that sent the original ORM.

Direction: a solicited reply from the filler back to the placer, correlated to the original order message.

Segments in an ORR message

The ORR_O02 message opens with the mandatory MSH and MSA header pair, followed by optional error and note segments, and an optional RESPONSE group. Within the RESPONSE group an optional PATIENT group (PID with notes) precedes one or more ORDER groups, each opening with ORC and a choice of one order-detail segment. The whole RESPONSE group is optional because an error response can consist of nothing more than MSH, MSA, and an ERR. 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 ORR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (`ORR^O02`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`MSA`	Message Acknowledgment. The segment that makes this a response. `MSA-1` carries the acknowledgment code from HL7 Table 0008 (for example `AA` application accept, `AE` application error, `AR` application reject), and `MSA-2` echoes the message control id of the original ORM so the placer can correlate the reply with the order it sent. Required.
`[{ERR}]`	Error. Carries the detail behind a non-accept acknowledgment — which field was at fault and why. Optional and repeating; present when `MSA-1` reports an error or rejection.
`[{NTE}]`	Notes and Comments. Header-level notes that apply to the response as a whole. Optional and repeating.
`[PID]`	Patient Identification. Identifies the patient the order concerns — the identifier list in `PID-3`, the name in `PID-5`. Required when the PATIENT group is present; the PATIENT group, and the enclosing RESPONSE group, are both optional, so an error response can omit the patient entirely.
`[{NTE}]`	Notes and Comments. Patient-level notes following `PID`. Optional and repeating.
`ORC`	Common Order. Opens each order group and carries the response at the order level. `ORC-1` holds the order control code from HL7 Table 0119 (for example `OK` order accepted, `UA` unable to accept), `ORC-2` the placer order number, and `ORC-3` the filler order number the filler assigned. Required within the ORDER group, and the ORDER group repeats once per order.
`<OBR``	`[`RQD`](/academy/hl7/segments/rqd)`
`[{NTE}]`	Notes and Comments. Notes relative to the order detail. Optional and repeating.
`[{CTI}]`	Clinical Trial Identification. Identifies a clinical trial and study phase the order is associated with. Optional and repeating.

[ ] = optional, { } = repeating

The ORDER group from ORC through CTI repeats once per order, so a single ORR can respond to several orders that were placed together. The canonical segment pages carry the full field-by-field detail.

Sample ORR message

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

MSH|^~&|LAB|MERCYGEN|CPOE|MERCYGEN|202006150905||ORR^O02^ORR_O02|MSG00021|P|2.5.1
MSA|AA|MSG00018
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|OK|ORD789^CPOE|FILL456^LAB
OBR|1|ORD789^CPOE|FILL456^LAB|CBC^Complete Blood Count^L

What this sample shows

The ORR^O02 in MSH-9 marks an order response. MSA reports AA — application accept — and echoes MSG00018, the control id of the original ORM, so the placer can correlate the reply. PID carries the medical record number MR12345. The ORC carries the order control code OK (order accepted), the placer order number ORD789, and the filler order number FILL456 the lab assigned. The OBR echoes the request being accepted — a Complete Blood Count — with both the placer and filler order numbers attached.

Working with ORR messages

Read the response from MSA and ORC together

The outcome of an order lives in two places. The acknowledgment code in MSA-1 reports whether the message was accepted at the application level, and the order control code in ORC-1 reports what the filler did with the order itself. Read them together: an AA in MSA-1 with OK in ORC-1 is an accepted order, while an AE/AR in MSA-1 signals a problem detailed in the ERR segment.

Correlate to the original order

MSA-2 echoes the message control id (MSH-10) of the ORM that the ORR responds to. Use it as the correlation key to match the response to the outstanding order. At the order level, the placer order number in ORC-2 and the filler order number in ORC-3 together identify the order across both systems — the placer assigns ORC-2, and the filler returns ORC-3 in the response so the placer can record the filler's own reference.

Error responses can be minimal

The RESPONSE group is optional, so a rejected message can be nothing more than MSH, MSA, and one or more ERR segments. Do not assume an ORR always carries a patient and an order group; handle the bare error form so a rejection does not fall through as an unparseable message.

Choosing the order-detail segment

The order detail is a choice of one segment type per order, matching the kind of order being responded to — OBR for diagnostics, RXO for pharmacy, ODS / ODT for dietary, and RQD / RQ1 for supplies. Parse whichever single detail segment follows the ORC rather than assuming OBR.

Vendor variance. Some fillers echo the full order detail back in the ORR while others return only the MSA and a minimal ORC; the RESPONSE and order-detail segments are optional in the base standard. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An ORR is an order acknowledgment, so its closest FHIR expression is a messaging Bundle whose MessageHeader's response element carries the acknowledgment, alongside the order resource — a ServiceRequest or MedicationRequest — that the order detail describes.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide publishes message-level maps for a fixed set of messages — ADT (A01/A02/A05/A06/A09/A11/A17), OML_O21, ORM_O01, VXU_V04, ORU_R01, MDM_T02, and SIU_S12 — and ORR_O02 is not among them. There is no official ConceptMap for the ORR message. A FHIR representation of an ORR is therefore derived manually, taking the acknowledgment from MSA and composing the order resource from the per-segment maps for ORC and the order-detail segment.

Common pitfalls

Pitfall. Reading only MSA-1 and ignoring ORC-1. The message-level acknowledgment in MSA-1 and the order-level control code in ORC-1 answer different questions; an application accept does not by itself confirm the order was accepted.

Pitfall. Assuming every ORR carries a patient and an order. The RESPONSE group is optional — an error response can be MSH + MSA + ERR only. Parsing that assumes a PID or ORC is always present will fail on rejections.

Pitfall. Failing to correlate on MSA-2. Without matching the echoed control id back to the outstanding ORM, a response cannot be tied to the order it answers, and acceptances or rejections are applied to the wrong order.

How Vorro handles ORR messages

Vorro receives the ORR over MLLP or another transport, deduplicates on MSH-10, and correlates the response back to the outstanding ORM through the echoed control id in MSA-2. It reads the acknowledgment code in MSA-1 together with the order control code in ORC-1 to decide whether the order was accepted, rejected, or held, records the filler order number from ORC-3 against the placer order, and routes the outcome to each subscribed destination in the format that system expects. Where a FHIR destination is configured, Vorro composes the response from the per-segment maps, since the v2-to-FHIR Implementation Guide publishes no map for this message.

ORM — the general order message that an ORR responds to.
ORU — the observation result returned once the ordered work is complete.
ORL — the laboratory order response, the response counterpart for laboratory order messages.

Sources

</invoke>

← Back to HL7 v2 Guide