HL7 OMS messages order stock supply items from central supply or materials management — items that are already listed in the facility's standard inventory catalogue. An OMS message is sent when a care unit or department needs to replenish standard catalogue supplies, and it communicates the item identifiers, quantity, requested delivery location, and date needed to the supply system. This page explains what an OMS message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMS stock order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMS message represents
An OMS message — OMS stands for Stock Requisition Order — communicates that a care area or department is requesting catalogue supply items from central supply or materials management. The core of the message is the RQD segment, the Requisition Detail, which carries the item identifiers, the quantity requested, the unit of measure, the location to deliver to, and the date the items are needed. Each RQD covers one line item in the requisition.
The sender is the system originating the supply request — a nursing station, an operating-room system, or a departmental application — and the receiver is the materials management or central supply system that fulfils the order. OMS is specifically for items already in the standard inventory catalogue: items that are stocked, have known internal or external item codes, and can be picked and delivered without special procurement. This distinguishes it from OMN, which handles non-catalogue items that require special or ad-hoc procurement and uses the same RQD segment structure but a different trigger event.
When an OMS message is sent
An OMS message is sent when a department or care unit requests a resupply of standard catalogue items. A single OMS message can carry multiple order groups — one RQD per line item — so an entire cart requisition can travel in one message. The materials management system returns the response in an ORS message.
Trigger event
The OMS message type carries a single trigger event:
OMS^O05– Stock Requisition Order message.
Because OMS has one trigger event, the receiver's handling turns on the contents of RQD — the item codes, quantity, delivery location, and date needed — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system emitting a stock requisition through the integration engine to central supply or materials management.
{{diagram: requesting system → OMS message → integration engine → central supply / materials management system}}
Typical senders: nursing station system, operating-room management system, departmental ordering application, EHR supply module.
Typical receivers: materials management information system (MMIS), central supply or sterile processing system, warehouse management application.
Direction: unidirectional order from the requesting department to the supply fulfilment system; acknowledgement and fulfilment status travel back in an ORS response.
Segments in an OMS message
The OMS_O05 message is organised into an optional PATIENT group (PID through insurance) and one or more ORDER groups, each opening with ORC and containing the RQD requisition detail. 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 OMS message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMS^O05), 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 requisition behaviour differs across materials management system releases. |
[PID] | Patient Identification. Identifies the patient the supplies are being ordered for — the identifier list in PID-3, the name in PID-5. The PATIENT group as a whole is optional; many stock requisitions are department-level rather than patient-specific and omit it entirely. |
[PD1] | Patient Additional Demographic. Supplements PID with data such as the patient's primary-care facility. Present only when the PATIENT group is present. |
[{NTE}] | Notes and Comments. Patient-level notes that apply when the PATIENT group is present. Optional and repeating. |
[PV1] | Patient Visit. The encounter the supply requisition belongs to — patient class and assigned location. Optional; present when items are being ordered for a specific patient visit. |
[PV2] | Patient Visit Additional. Companion to PV1 with admit reason and expected dates when a visit is present. |
[{IN1}] | Insurance. Insurance coverage information for the patient. Optional and repeating; relevant when the supply order generates a patient charge. |
[IN2] | Insurance Additional Information. Supplements IN1 with additional coverage detail. |
[IN3] | Insurance Additional Information — Certification. Certification and pre-authorisation data linked to the insurance in IN1. |
[GT1] | Guarantor. The financial guarantor for the patient, when the requisition is patient-specific and billable. |
ORC | Common Order. Opens each order group and establishes the requisition order. It carries the order control code, the placer and filler order numbers, the ordering provider, and the ordering facility. Required, and the order group repeats once per line item. |
[{TQ1}] | Timing/Quantity. The requested timing and quantity for the order. 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 supply applies. Optional and repeating. |
RQD | Requisition Detail. The core of the message and the only required clinical segment in the order. It carries the line item number in RQD-1, the internal item code in RQD-2, the external item code in RQD-3, the hospital item code in RQD-4, the requested quantity in RQD-5, the unit of measure in RQD-6, the deliver-to location identifier in RQD-9, and the date the item is needed in RQD-10. |
[RQ1] | Requisition Detail-1. Supplemental detail for the requisition — manufacturer identifier, manufacturer catalogue number, and vendor identifier. Optional; used when additional procurement reference data accompanies the catalogue item. |
[{NTE}] | Notes and Comments. Notes relative to this order line item. Optional and repeating. |
[{OBX,[{NTE}]}] | Observation/Result (OBSERVATION group). Clinical observations associated with the requisition line item — for example, an indication or a patient condition that supports the supply need. Each OBX may be followed by its own optional repeating NTE notes. The OBSERVATION group itself is optional and repeating. |
[BLG] | Billing. Identifies the account or cost centre to charge for this supply order. Optional; used when supply items are charged to a specific billing account rather than a department budget. |
[ ] = optional, { } = repeating
The order group from ORC through BLG repeats once per requisition line item, so a single OMS message can carry an entire multi-item supply order. The canonical segment pages carry the full field-by-field detail.
Sample OMS message
Note. Constructed for illustration. Item codes, order numbers, locations, dates, and identifiers are fictional.
MSH|^~&|NURSESTN|MERCY|MMIS|MERCY|20260604083000||OMS^O05^OMS_O05|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCY^MR||SMITH^PATRICIA^A||19720315|F
PV1|1|I|3N^301^A^MERCY||||ATT001^JONES^CAROL^^^^MD
ORC|NW|REQ20260604-001^NURSESTN|||IP||||20260604083000|||ATT001^JONES^CAROL^^^^MD
RQD|1|IC0042^Sterile Gauze 4x4 10pk^MERCY||HC0042^Gauze4x4^MERCY|5|PK|||3N^301^A|20260604
NTE|1||Needed for wound care this shift.
ORC|NW|REQ20260604-002^NURSESTN|||IP||||20260604083000|||ATT001^JONES^CAROL^^^^MD
RQD|2|IC0118^Exam Gloves Med 100ct^MERCY||HC0118^GloveMed^MERCY|2|BX|||3N^301^A|20260604
What this sample shows
The OMS^O05 in MSH-9 marks a stock requisition order. PID identifies patient MR98765 and PV1 places her in inpatient bed 3N-301-A. The message carries two order groups — two line items on the same requisition. The first ORC uses order control NW (new order) and carries placer order number REQ20260604-001. The first RQD requests 5 packs of sterile gauze (RQD-5 = 5, RQD-6 = PK), identified by internal code IC0042 in RQD-2 and hospital code HC0042 in RQD-4, to be delivered to 3N-301-A in RQD-9, needed by 2026-06-04 in RQD-10. The NTE adds a free-text note for the first line. The second order group requests 2 boxes of medium exam gloves by the same date and location.
Working with OMS messages
Identify items by the correct code in RQD
RQD carries up to three item code fields: internal (RQD-2), external (RQD-3), and hospital (RQD-4). Materials management systems typically resolve items on the internal or hospital code; the external code refers to a supplier catalogue number. Confirm which code field your MMIS uses for item lookup — a mismatch silently routes the requisition to the wrong item or fails with an unknown-item error.
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 RQD-1 (line number) as the natural business key for a requisition line. Supply feeds are replayed after outages; treating a repeated control id as a duplicate prevents the same cart from being picked twice.
Patient-specific vs. department-level requisitions
The PATIENT group is optional. When a requisition is for a specific patient, include PID and PV1 so the MMIS can link the items to the encounter and, if applicable, generate a patient charge via BLG. When the requisition replenishes a department's stock without a specific patient, omit the PATIENT group and use BLG to direct the charge to a cost centre.
Date needed in RQD-10
RQD-10 carries the date the item must be delivered. Some MMIS implementations use this field to prioritise pick queues; others treat it as informational. Confirm handling with the MMIS vendor — a missing or malformed date may cause the requisition to be queued with lowest priority or rejected on validation.
Vendor variance. The
RQ1supplemental detail segment is optional and is included only when the receiving application requires manufacturer or vendor reference data. Some departmental ordering systems always populate it; others never do. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A stock supply requisition corresponds to the FHIR SupplyRequest 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 OMS_O05 and no ConceptMap for the RQD requisition detail segment. A FHIR SupplyRequest produced from an OMS message is therefore mapped manually, taking the item identifier, quantity, unit of measure, requested delivery location, and occurrence date from RQD and linking to the requesting Patient and Encounter derived from the PATIENT group.
Common pitfalls
Pitfall. Resolving the item on
RQD-3(external code) when the MMIS expectsRQD-2(internal code). The two code fields represent different coding authorities; using the wrong one causes the requisition to fail item lookup silently or with an ambiguous error.
Pitfall. Omitting
RQD-9(deliver-to ID) on patient-specific requisitions. Without a delivery location the MMIS cannot route the pick to the correct ward or room, causing manual rerouting or delivery failure.
Pitfall. Sending OMS for non-catalogue items. OMS is for standard inventory items only; a non-catalogue or special-procurement item must travel as an OMN message. Sending a non-catalogue item in an OMS message will fail MMIS validation or silently match the wrong catalogue entry.
How Vorro handles OMS messages
Vorro ingests the OMS feed over MLLP or another transport, deduplicates on MSH-10, and routes each requisition to the configured materials management destination in the format that system expects. Vorro reads the item codes, quantity, unit of measure, delivery location, and date needed from RQD, links each line item to its order through the placer order number in ORC, and applies the patient and visit context from PID and PV1 when present. Where a FHIR destination is configured, Vorro maps the requisition to a SupplyRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- ORS — the stock requisition response returned by the MMIS to acknowledge and confirm an OMS order.
- OMN — the non-stock requisition order for items not in the standard catalogue that require special procurement.
- ORM — the general order message used for orders outside pharmacy, supply, and imaging.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMS_O05
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RQD
- HL7 Messaging Standard Version 2.5.1 product brief
