HL7 OMD messages communicate a dietary or nutritional order from a clinician to the dietary department — specifying what a patient should eat, any supplemental nutrition to be provided, and how individual meal trays should be prepared and delivered. An OMD message carries both diet-level instructions and, where needed, tray-level service details, and is sent from the ordering system to the dietary management system that fulfils the request. This page explains what an OMD message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMD dietary order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMD message represents
An OMD message — OMD stands for Dietary Order Message — communicates that a clinician has placed an order governing what a patient should receive from the dietary department. The core of the message is the ODS segment, which carries the diet or supplement specification for each ordered item: the type of order (supplement or tray) in ODS-1, the service period in ODS-2, the coded diet or supplement in ODS-3, and free-text instructions in ODS-4. When the order extends to specific tray preparation, the ODT segment within the ORDER_TRAY group carries tray-type, service period, and meal code.
The sender is the ordering clinician's system — typically an EHR or CPOE — and the receivers are the dietary management system and any downstream systems that schedule, prepare, and track patient meals. OMD is the ordering counterpart to the dietary fulfilment workflow: an OMD order tells the dietary department what has been prescribed, and the dietary department acts on it to schedule and deliver meals or supplements that comply with the patient's clinical needs.
When an OMD message is sent
An OMD message is sent when a clinician places or updates a dietary order. Common scenarios include admitting a patient and ordering a specific therapeutic diet, adding a nutritional supplement, modifying a diet order as the patient's condition changes, or cancelling a previous dietary instruction. Each change to the diet order produces a new OMD with the appropriate order control code in ORC to distinguish a new order from a change or cancellation.
Trigger event
The OMD message type carries a single trigger event:
OMD^O03– Diet order message.
Because OMD has one trigger event, the receiver's handling turns on the order control code in ORC — NW for a new order, CA for a cancellation, XO for a change — and on the contents of ODS rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the ordering system emitting a diet order event through the integration engine to the systems that fulfil and record it.
{{diagram: EHR / CPOE → OMD message → integration engine → dietary management system / nutritional record / scheduling}}
Typical senders: EHR, CPOE, or clinical workstation placing the dietary order.
Typical receivers: dietary management system, nutritional care record, meal scheduling and tray preparation system.
Direction: unidirectional notification from the ordering source to the dietary department and any systems that act on or record the diet order.
Segments in an OMD message
The OMD_O03 message is organised into three major parts: a required MSH, an optional PATIENT group (PID through AL1), and one or more ORDER_DIET groups, each opened by ORC and containing the ODS diet segment. An optional ORDER_TRAY group at the end of each order carries ODT 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 OMD message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMD^O03), 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 diet-order behaviour differs across EHR or CPOE releases. |
[PID] | Patient Identification. Identifies the patient for whom the dietary order is placed — 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. |
[PD1] | Patient Additional Demographic. Supplements PID with data such as the patient's primary-care facility. |
[{NTE}] | Notes and Comments. Patient-level notes that apply to the dietary order as a whole. Optional and repeating. |
[PV1] | Patient Visit. The encounter the diet order belongs to — patient class, assigned location, and the providers on the visit. Optional. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason and expected dates when a visit is present. |
[{IN1}] | Insurance. Primary insurance coverage for the patient. Optional and repeating; one IN1 per insurance plan. |
[IN2] | Insurance Additional. Supplemental insurance data for the most recent IN1. |
[IN3] | Insurance Additional Certification. Certification and pre-authorisation data related to the insurance. |
[GT1] | Guarantor. The party financially responsible for the patient's care. Optional. |
[{AL1}] | Allergy Information. Patient allergies and food intolerances carried with the diet order. Critical for dietary planning. Optional and repeating. |
ORC | Common Order. Opens each ORDER_DIET group and establishes the order identity and control. Carries the order control code (NW, CA, XO) in ORC-1, the placer order number in ORC-2, and the filler order number in ORC-3. Required, and the ORDER_DIET group repeats once per diet or supplement ordered. |
[{TQ1}] | Timing/Quantity. The schedule and timing for the dietary service — meal frequency, start date, and end date. 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 orders apply. |
ODS | Dietary Orders, Supplements, and Preferences. The core clinical segment of the ORDER_DIET group. ODS-1 carries the type code: S for a supplement or T for a tray order. ODS-2 holds the service period — the meal or service slot (breakfast, lunch, dinner, or a coded period) to which the order applies. ODS-3 carries the coded diet, supplement, or preference (e.g. low-sodium, diabetic, clear liquid). ODS-4 holds free-text instructions that accompany the coded order. The ODS segment is required within each ORDER_DIET group and may repeat to express multiple diet codes or preferences for the same order. |
[{NTE}] | Notes and Comments. Notes relative to this specific diet order, following the ODS. Optional and repeating. |
[{OBX}] | Observation/Result. Diet-related clinical observations associated with the order — for example, a recorded weight or nutritional assessment score that informed the order. Optional and repeating. |
[{NTE}] | Notes and Comments (within OBSERVATION group). Notes accompanying each OBX observation. Optional and repeating. |
ORC | Common Order (ORDER_TRAY group). Opens each ORDER_TRAY group, linking tray instructions to the diet order through the placer and filler order numbers. |
ODT | Diet Tray Instructions. Tray-level service detail within the ORDER_TRAY group. ODT-1 carries the tray type (the service type for the tray — e.g., a regular tray vs. a special-preparation tray). ODT-3 holds the tray service period — when the tray is to be delivered. ODT-4 carries the meal code identifying the specific meal. Used when per-tray preparation or delivery instructions differ from the general diet order. |
[{NTE}] | Notes and Comments (within ORDER_TRAY group). Notes relative to the tray instructions. Optional and repeating. |
[ ] = optional, { } = repeating
The ORDER_DIET group from ORC through the OBSERVATION group repeats once per diet or supplement order, so a single OMD message can carry multiple dietary instructions for the same patient. The ORDER_TRAY group repeats once per tray-level instruction set. The canonical segment pages carry the full field-by-field detail.
Sample OMD message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|CPOE|MERCYGEN|DIETARY|MERCYGEN|20260604083000||OMD^O03^OMD_O03|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^MARY^A||19520318|F
PV1|1|I|4N^401^A^MERCYGEN||||ATT001^JONES^ROBERT^^^DR
AL1|1|FA|EGG^Egg^L|MO|Hives
ORC|NW|PO55231^CPOE|DO77412^DIETARY|||^^^20260604^^^TID
TQ1|1|||TID|20260604|20260611
ODS|S|B^Breakfast^HL70160~L^Lunch^HL70160~D^Dinner^HL70160|SFT^Low Sodium Diet^L|Restrict sodium to 2g per day; avoid processed and canned foods
NTE|1||Ordered per nephrology consult 2026-06-03
ORC|NW|PO55232^CPOE|DO77413^DIETARY
ODS|S|B^Breakfast^HL70160|SUPGL^Nutritional Supplement — Glucose Limited^L|Provide 1 carton Glucerna at each breakfast tray
What this sample shows
The OMD^O03 in MSH-9 marks a dietary order. PID carries the medical record number MR98765, and PV1 places the patient in inpatient room 4N-401 under attending physician Dr. Jones. The AL1 segment records a moderate egg allergy, which the dietary system must honour when planning meals.
The first ORDER_DIET group opens with ORC carrying order control NW (new order) and placer order number PO55231. The TQ1 schedules the diet three times daily from 2026-06-04 through 2026-06-11. The ODS specifies S (supplement/diet type) in ODS-1, breakfast, lunch, and dinner service periods in ODS-2, the coded Low Sodium Diet in ODS-3, and a free-text restriction note in ODS-4. The NTE attributes the order to a nephrology consult.
The second ORDER_DIET group adds a breakfast-only nutritional supplement (Glucerna), demonstrating how a single OMD message carries multiple simultaneous dietary instructions.
Working with OMD messages
ODS is the authoritative diet instruction — read it carefully
All clinical dietary detail lives in ODS. ODS-3 carries the coded diet or supplement and is the field dietary systems act on; ODS-4 holds supplementary free text that should be displayed but must not be used as a substitute for the coded value. When ODS-3 is empty and ODS-4 is populated, treat the order as uncodeable and route it to a dietitian for manual review rather than discarding it.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the placer order number in ORC-2 together with the order control code in ORC-1 as the natural business key for the diet order lifecycle. Diet feeds are replayed after network outages, and treating a repeated control id as a duplicate prevents a replayed order from scheduling a duplicate diet service.
Order control codes determine the action
The ORC-1 order control code drives what the dietary system must do: NW creates a new diet order, CA cancels an existing one, and XO signals a change to an active order. Always inspect ORC-1 before processing ODS — applying a change order as a new order or ignoring a cancellation can result in a patient receiving the wrong diet.
Service period scope in ODS-2
ODS-2 defines which meal service slots the order covers. A diet order covering all meals will repeat the service-period codes for breakfast, lunch, and dinner as separate repetitions within ODS-2. Systems that map only the first repetition will miss meals. Iterate all repetitions of ODS-2 and apply the diet code to each named service period.
Vendor variance. The
ODS-2service period codes and the diet codes inODS-3are locally defined in many implementations. Confirm your trading partner's code tables for both fields before mapping — an unmapped code silently drops a dietary restriction from the patient's tray.
FHIR equivalent
A dietary order corresponds to the FHIR NutritionOrder 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 OMD_O03 and no ConceptMap for the ODS diet segment. A FHIR NutritionOrder produced from an OMD message is therefore mapped manually, taking the diet type, coded diet or supplement, service period, and textual instructions from ODS and populating the relevant NutritionOrder fields — oralDiet.type, supplement.type, oralDiet.schedule, and oralDiet.instruction — by hand.
Common pitfalls
Pitfall. Acting only on
ODS-4free text and ignoringODS-3. Free-text instructions are supplemental; the coded value inODS-3is what diet-management systems should action. Relying on text parsing to determine the diet type is fragile and misses orders whereODS-4is absent.
Pitfall. Processing only the first repetition of
ODS-2. A diet order that covers all three meals encodes breakfast, lunch, and dinner as separate repetitions inODS-2. Reading only the first repetition applies the diet to one meal and leaves the patient without dietary guidance at the others.
Pitfall. Ignoring the
ORC-1order control code. An OMD withORC-1set toCAis a cancellation; treating it as a new order keeps an incorrect or superseded diet active. Always resolveORC-1before processing theODScontent.
How Vorro handles OMD messages
Vorro ingests the OMD feed over MLLP or another transport, deduplicates on MSH-10, and routes each diet order to every subscribed destination in the format that system expects — the dietary management system, nutritional care record, and meal scheduling platform. Vorro reads the order control code from ORC to determine whether the message represents a new order, a change, or a cancellation; extracts the coded diet or supplement and service period from ODS; and surfaces allergy information from AL1 alongside the diet instruction so dietary staff can reconcile food restrictions at the point of preparation. Where a FHIR destination is configured, Vorro maps the order to a NutritionOrder resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- ORD — the dietary order acknowledgement returned by the dietary system in response to an OMD.
- ORM — the general order message for non-dietary clinical orders; shares the ORC-based order structure with OMD.
- OMG — the general clinical order message for ancillary departments, structurally parallel to OMD.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMD_O03
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for ODS
- HL7 Messaging Standard Version 2.5.1 product brief
