HL7 ORD messages confirm that a dietary or nutrition order has been received and accepted by the dietary department. An ORD message is sent in direct response to an OMD dietary order request and echoes back the key order data — the order control code, the filler order number, the diet order, and any tray instructions — so the originating system can confirm the order was accepted and tracked. This page explains what an ORD message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ORD response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an ORD message represents
An ORD message — ORD stands for Dietary Order Response — communicates that the dietary department has accepted a nutrition or diet order originally submitted in an OMD message. The core of the response is the ORC segment, which echoes back the order control code and assigns or confirms the filler order number that the dietary system will use to track the order. The ODS segment, when present, echoes the diet order details — diet type, supplements, and preparation instructions — confirming exactly what was accepted. The ODT segment, in the ORDER_TRAY group, echoes any tray instruction details back to the sender.
The sender is the dietary information system, and the receiver is typically the EHR, nursing application, or order-entry system that originated the OMD request. The ORD message is a confirmation, not a new order — its purpose is to close the acknowledgement loop and supply the filler order number that downstream systems need to reference the accepted order.
When an ORD message is sent
An ORD message is sent in response to an OMD dietary order message, once the dietary department's system has processed the request and accepted the order. Each ORD is paired with the OMD that triggered it: the message acknowledgement segment (MSA) carries the control id of the original OMD so the sender can match the response to its request. If the dietary system encounters a problem processing the order, ERR segments carry the error details.
Trigger event
The ORD message type carries a single trigger event:
ORD^O04— Dietary order response.
The trigger is generated by the dietary system as a direct response to an OMD^O03 dietary order request. The receiver's handling turns on the order control code in ORC — typically OK for accepted or UA for unable to accept — rather than solely on the trigger code in MSH-9.
Integration topology
The diagram shows the dietary system emitting an order response back through the integration engine to the order-entry or nursing application that originated the request.
{{diagram: order-entry / EHR → OMD^O03 → dietary system → ORD^O04 → integration engine → order-entry / EHR / nursing application}}
Typical senders: dietary information system, nutrition management platform, hospital food-service system.
Typical receivers: EHR order-entry system, nursing or clinical application, care-coordination platform.
Direction: response from the dietary department back to the originating ordering system, closing the request-response cycle.
Segments in an ORD message
The ORD_O04 message is organised into a required outer structure followed by an optional RESPONSE group. The outer structure carries the message acknowledgement and any errors or notes. The RESPONSE group, when present, contains optional patient and visit data followed by one or more ORDER_DIET groups (each with the diet order details) and one or more ORDER_TRAY groups (each with tray instructions). 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 ORD message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (ORD^O04), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and match the response to its originating OMD request using MSA-2. |
MSA | Message Acknowledgement. Required. Carries the acknowledgement code in MSA-1 (typically AA for application accept) and echoes the message control id of the originating OMD^O03 in MSA-2, allowing the sender to match this response to its request. |
[{ERR}] | Error. Carries structured error details when the dietary system could not accept the order. Optional and repeating, so multiple error conditions can be reported in a single response. |
[{NTE}] | Notes and Comments. Message-level notes that apply to the response as a whole. Optional and repeating. |
[PID] | Patient Identification. Within the optional RESPONSE group, identifies the patient the dietary order was placed for — the identifier list in PID-3, the name in PID-5. Present only when the RESPONSE group is included; the group as a whole is optional. |
[{NTE}] | Notes and Comments. Patient-level notes within the RESPONSE group. Optional and repeating. |
[PV1] | Patient Visit. The encounter the dietary order belongs to — patient class, assigned location, and the providers on the visit. Optional within the RESPONSE group. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason and expected dates when a visit context is present. |
ORC | Common Order. Opens each ORDER_DIET group and is the central segment of the dietary order response. It echoes back the order control code (e.g. OK for accepted) from the originating OMD and carries or confirms the filler order number in ORC-3, which the dietary system assigns to track the order. The placer order number from the originating OMD is echoed in ORC-2. Required, and the ORDER_DIET group repeats once per diet order line. |
[{TQ1}] | Timing/Quantity. The schedule and timing for the diet order — meal frequency, start and stop times. Optional and repeating; introduced as the replacement for the deprecated quantity/timing field in v2.5. |
[TQ2] | Timing/Quantity Relationship. Relates this order's timing to another order, when sequenced or conditional diet schedules apply. |
[ODS] | Dietary Orders, Supplements, and Preferences. Echoes the diet order from the originating OMD back to the sender — diet type, supplements, and any preparation or texture instructions. The presence of ODS in the response confirms the specific diet that was accepted. Optional at the segment level, but its presence is the primary clinical confirmation of what the dietary department accepted. |
[{NTE}] | Notes and Comments. Notes relative to the diet order, following ODS. Optional and repeating. |
[{OBX}] | Observation/Result. Diet-order-level observations such as a nutritional assessment value or a caloric target confirmed at acceptance. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes relative to each OBX observation. Optional and repeating. |
ORC | Common Order. Opens each ORDER_TRAY group, echoing the order control code and filler order number for the tray instruction. Required within the ORDER_TRAY group, which repeats once per tray instruction line. |
[ODT] | Diet Tray Instructions. Echoes the tray instructions from the originating OMD — service period, tray type, or special delivery notes — back to the sender. Optional within the ORDER_TRAY group. |
[{NTE}] | Notes and Comments. Notes relative to the tray instruction, following ODT. Optional and repeating. |
[ ] = optional, { } = repeating
The ORDER_DIET group from ORC through its NTE repeats once per diet order line, and the ORDER_TRAY group repeats once per tray instruction, so a single ORD message can confirm multiple diet orders and tray instructions together. The canonical segment pages carry the full field-by-field detail.
Sample ORD message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|DIETARY|MERCYGEN|EHR|MERCYGEN|202310041130||ORD^O04^ORD_O04|MSG00088|P|2.5.1
MSA|AA|MSG00075
PID|1||MR67890^^^MERCYGEN^MR||SMITH^JANE^M||19651122|F
PV1|1|I|3N^312^A^MERCYGEN
ORC|OK|PO1122^EHR|DIET9981^DIETARY|||^^^202310041200^^R
ODS|D||2^Low Sodium Diet^HL70159|Soft texture; no added salt
NTE|1||Patient reports shellfish allergy — dietary staff notified
ORC|OK|PO1122^EHR|TRAY9981^DIETARY
ODT|1^Breakfast tray^HL70160|202310050800
What this sample shows
The ORD^O04 in MSH-9 marks a dietary order response. MSA carries acknowledgement code AA and echoes the originating OMD's control id MSG00075 in MSA-2, closing the request-response loop. PID carries the medical record number MR67890, and PV1 places the patient on ward 3N, room 312. The first ORC carries order control code OK — accepted — echoing the placer order number PO1122 and assigning filler order number DIET9981. The ODS echoes the accepted diet: a Low Sodium Diet (code 2, table HL7 0159) with soft texture and no added salt. The NTE following ODS passes a dietary staff note about an allergy. The ORDER_TRAY group opens with a second ORC carrying filler order number TRAY9981, and ODT echoes the breakfast-tray instruction scheduled for 202310050800.
Working with ORD messages
Match the response to the request using MSA-2
The MSA segment's MSA-2 field contains the message control id of the originating OMD^O03 message. Always use this field — not the order numbers — as the primary key for pairing a response to its request. Order numbers can be assigned or changed by the dietary system during processing, but MSA-2 is an immutable echo of the original MSH-10.
Read acceptance from ORC, not just MSA
MSA-1 signals transport-level acknowledgement, but the clinical acceptance of each order line is in the order control code in ORC. A response with MSA-1 of AA and ORC order control code UA (unable to accept) means the message was received but the order was rejected. Process both fields to determine the true outcome for each order line.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key. Dietary response feeds can be replayed after outages, and treating a repeated control id as a duplicate prevents a replayed acceptance from creating a second order record or triggering a second notification to clinical staff.
Verify the echoed ODS against the original order
The ODS in the ORD response echoes what the dietary system accepted. Compare it against the ODS sent in the originating OMD to detect silent modifications — some dietary systems adjust diet codes or texture descriptors during acceptance. A discrepancy should trigger a reconciliation workflow rather than being silently overwritten.
Vendor variance. The RESPONSE group — including
PID,PV1, andPV2— is optional, and some dietary systems omit it entirely, returning onlyMSH,MSA, and the ORDER_DIET and ORDER_TRAY groups. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A dietary order response conceptually corresponds to an echoed FHIR NutritionOrder resource, representing the accepted order, along with 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 ORD_O04 and no ConceptMap for the ODS or ODT segments — the dietary order segments are absent from the published segment-map index. A FHIR NutritionOrder produced from an ORD message is therefore mapped manually, taking the diet type, texture, and supplement data from ODS and the timing from TQ1, and referencing the accepted order via the filler order number in ORC-3.
Common pitfalls
Pitfall. Treating
MSA-1ofAAas full clinical acceptance without checkingORC. The message acknowledgement and the order acceptance are separate:MSA-1confirms the message arrived; the order control code inORCconfirms whether the dietary department accepted each order line.
Pitfall. Ignoring the echoed
ODSand assuming the accepted diet matches the ordered diet exactly. Dietary systems sometimes normalise or adjust diet codes during acceptance; always compare the echoedODSagainst the originating OMD to detect any changes.
Pitfall. Not storing the filler order number from
ORC-3. The filler order number assigned by the dietary system inORC-3is the key the dietary department uses to reference the order in all subsequent communications, including cancellations and updates; discarding it severs the downstream linkage.
How Vorro handles ORD messages
Vorro ingests the ORD response over MLLP or another transport, deduplicates on MSH-10, and matches each response to its originating OMD request using MSA-2. Vorro reads the order control code from each ORC to determine per-line acceptance, extracts the filler order number assigned by the dietary system, and routes the confirmation — with the echoed diet details from ODS and tray instructions from ODT — to every subscribed destination in the format that system expects. Where a FHIR destination is configured, Vorro maps the accepted order to a NutritionOrder resource composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OMD — the dietary order message that an ORD message responds to.
- ORM — the general order message used for orders outside the specialised order types.
- ORR — the general order response message, the non-dietary counterpart to ORD.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for ORD_O04
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for ODS or ODT
- HL7 Messaging Standard Version 2.5.1 product brief
