HL7 OMN messages order non-stock supply items — items not held in the standard catalogue or standing inventory that require special procurement outside the normal supply chain. An OMN message is sent from the requesting application to the supply or materials management system and initiates a purchase or procurement action for the specified item. This page explains what an OMN message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMN requisition relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMN message represents
An OMN message — OMN stands for Non-Stock Requisition Order — communicates that a clinical or administrative area is requesting a supply item that is not part of the standard inventory. The core of the message is the RQD segment, which carries the requisition detail for a single line item: it identifies the item by internal code, external code, or hospital item code; records the quantity and unit of measure requested; specifies where the item should be delivered; and states the date by which it is needed.
The sender is typically a clinical application, an EHR, or a departmental system that has identified a need for an item outside the normal catalogue. The receiver is the materials management or supply chain system responsible for procuring and fulfilling the request. Because the items are non-stock, the RQD does not assume the item already has an established internal inventory record — it carries enough identification data for the receiving system to locate or create one. An optional RQ1 segment can supplement the requisition with manufacturer and catalogue information when the requesting department already knows the specific product source.
When an OMN message is sent
An OMN message is sent when a department or clinical user raises a requisition for a non-catalogue item that cannot be fulfilled through a standard stock order. Common scenarios include one-time clinical trials, research supplies, specialty surgical instruments not held on the shelf, and patient-specific items ordered outside the routine supply cycle.
Trigger event
The OMN message type carries a single trigger event:
OMN^O07– Non-stock requisition order message.
Because OMN has one trigger event, the receiver's handling turns on the contents of RQD — the item identification, the requested quantity, the delivery location, and the date needed — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system emitting a non-stock requisition through the integration engine to the materials management system that procures and fulfils it.
{{diagram: requesting system (EHR / clinical app) → OMN message → integration engine → materials management / supply chain system}}
Typical senders: EHR or clinical application, departmental ordering system, research or clinical-trials management platform.
Typical receivers: materials management system, supply chain or procurement platform, inventory management application.
Direction: unidirectional requisition from the requesting department to the system responsible for procurement and fulfilment.
Segments in an OMN message
The OMN_O07 message is organised into an optional PATIENT group (PID through insurance) and one or more ORDER groups, each opening with ORC and containing the requisition detail. The RQD requisition detail segment is required within each order group and is the only mandatory clinical segment. An optional RQ1 can follow to supply manufacturer and catalogue data. 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 OMN message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMN^O07), 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 ordering-system releases. |
[PID] | Patient Identification. Identifies the patient the non-stock item is being requisitioned for, when the request is patient-specific — the identifier list in PID-3, the name in PID-5. The PATIENT group as a whole is optional; departmental or facility-level requisitions with no specific patient may omit it. |
[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 to the requisition as a whole. Optional and repeating. |
[PV1] | Patient Visit. The encounter the requisition is associated with — 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. Insurance plan information for the patient when coverage data is relevant to the procurement. Optional and repeating. |
[IN2] | Insurance Additional Information. Extended insurance data supplementing IN1. |
[IN3] | Insurance Additional Information, Certification. Certification details associated with the insurance plan in IN1. |
[GT1] | Guarantor. Guarantor information for billing purposes when the requisition carries financial responsibility data. Optional. |
ORC | Common Order. Opens each ORDER group and provides the controlling information for the requisition line. It carries the order control code, the placer and filler order numbers, the order status, and the ordering provider. Required, and the ORDER group repeats once per requisitioned line item. |
[{TQ1}] | Timing/Quantity. The requested timing and quantity schedule 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 requisitions apply. Optional and repeating. |
RQD | Requisition Detail. The core of the message and the only required clinical segment in the order. It carries the requisition line number in RQD-1; the item code internal in RQD-2, item code external in RQD-3, and hospital item code in RQD-4 — providing three identification axes for the non-catalogue item; the requisition quantity in RQD-5 and unit of measure in RQD-6; the deliver-to location in RQD-9; and the date the item is needed in RQD-10. |
[RQ1] | Requisition Detail-1. Supplements RQD with manufacturer-specific procurement data: manufacturer ID, manufacturer's catalogue number, auxiliary code for the item, and the item's natural account code for general-ledger mapping. Optional; present when the requesting department has identified the specific manufacturer and catalogue reference. |
[{NTE}] | Notes and Comments. Notes relative to the requisition line, following the RQD. Optional and repeating. |
[{OBX}] | Observation/Result. Clinical or contextual observations associated with the requisition — for example, justification data or specification details for the non-stock item. Optional and repeating. |
[{NTE}] | Notes and Comments (Observation). Notes attached to individual OBX observations. Optional and repeating. |
[BLG] | Billing. Billing information for the requisition — the charge type, the account identifier, and the payment when the procurement needs to be charged to a specific account. Optional. |
[ ] = optional, { } = repeating
The ORDER group from ORC through BLG repeats once per requisitioned line item, so a single OMN message can request multiple non-stock items in one transaction. The canonical segment pages carry the full field-by-field detail.
Sample OMN message
Note. Constructed for illustration. Patient identifiers, order numbers, item codes, dates, and names are fictional.
MSH|^~&|EHRSYS|GENERALHOSPITAL|MATMGMT|GENERALHOSPITAL|20260604083000||OMN^O07^OMN_O07|MSG00047|P|2.5.1
PID|1||PT98765^^^GENERALHOSPITAL^MR||SMITH^MARY^A||19750315|F
PV1|1|I|4NORTH^412^A^GENERALHOSPITAL
ORC|NW|REQ20260604001^EHRSYS||||||20260604083000|||DR99^JONES^PAUL^^^DR
RQD|1|INT4892^Custom Wound VAC Canister^L|EXT77341^VAC Canister 300cc^MFR||2|EA|||4NORTH^412^A|20260605
RQ1||MFR001^Smith Medical^L|CAT-VAC-300||6200.0000
NTE|1||Patient requires non-standard canister size not held in central supply.
What this sample shows
The OMN^O07 in MSH-9 marks a non-stock requisition order. PID carries the medical record number PT98765, and PV1 places the patient in inpatient bed 4NORTH-412-A. The ORC carries order control code NW (new order) with placer order number REQ20260604001, the ordering date and time, and the ordering provider DR99. The RQD is the core of the requisition: line number 1 (RQD-1), internal item code INT4892 for a Custom Wound VAC Canister (RQD-2), external code EXT77341 for cross-reference to the manufacturer's catalogue (RQD-3), quantity 2 (RQD-5), unit EA for each (RQD-6), deliver-to 4NORTH-412-A (RQD-9), and date needed 20260605 (RQD-10). The RQ1 supplements the line with manufacturer Smith Medical, catalogue number CAT-VAC-300, and a natural account code of 6200.0000. The NTE carries a free-text justification for the non-stock procurement.
Working with OMN messages
Read the item identification from RQD, not assumed defaults
Non-stock items may carry an internal code (RQD-2), an external code (RQD-3), a hospital item code (RQD-4), or all three. Do not assume a single coding system — populate whichever axes the receiving materials management system uses to locate or create a procurement record, and surface all three when present so the receiving system can match against its own item master or create a new record.
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 requisition line number in RQD-1 as the natural business key for a line item. Procurement feeds can be replayed after outages; treating a repeated control id as a duplicate prevents a replayed requisition from raising a second purchase order.
Date needed and delivery location
RQD-10 carries the date by which the item must arrive, and RQD-9 carries the deliver-to location. Both fields drive the procurement urgency and logistics routing in the receiving system. Surface them on the purchase order rather than discarding them — a non-stock item with a same-day date needed requires different handling from a standing special-order with a week's lead time.
RQ1 as a procurement shortcut
When RQ1 is present, the requesting application has already identified the manufacturer and catalogue reference. Pass this data directly to the purchasing system rather than requiring a manual lookup — it eliminates one step in the procurement workflow and reduces the risk of sourcing the wrong product variant.
Vendor variance. The
RQ1segment is optional and is omitted when the requesting application does not know the manufacturer details, leaving the receiving procurement system to source the item fromRQDidentifiers alone. Some implementations also carry all item identification in a singleRQDfield and leave the others empty; confirm a partner's field usage against their interface specification rather than assuming all three item code fields are populated.
FHIR equivalent
A non-stock requisition order corresponds conceptually 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 OMN_O07 and no ConceptMap for the RQD requisition detail segment. A FHIR SupplyRequest produced from an OMN message is therefore mapped manually, taking the item identification, requested quantity, unit of measure, deliver-to location, and date needed from RQD, supplementing with manufacturer and catalogue data from RQ1 where present, and referencing the requesting Patient derived from PID.
Common pitfalls
Pitfall. Assuming the item already exists in the receiving system's item master. Non-stock items by definition may not have an established record; the receiving system must be prepared to create a new procurement record from the codes and description carried in
RQDrather than rejecting an unrecognised item code.
Pitfall. Discarding
RQD-10, the date needed. The date needed is the primary urgency signal for a non-stock procurement. Dropping it collapses all requisitions into a default lead-time queue and can cause clinical delays when an item is required for a procedure the following day.
Pitfall. Treating
RQ1as always present. BecauseRQ1is optional, processing logic that expects manufacturer data must handle its absence gracefully and fall back to the item codes inRQDfor sourcing rather than erroring or stalling the requisition.
How Vorro handles OMN messages
Vorro ingests the OMN feed over MLLP or another transport, deduplicates on MSH-10, and routes each requisition line to the materials management or procurement system in the format it expects. Vorro reads the item identification, quantity, delivery location, and date needed from RQD and, when RQ1 is present, passes manufacturer and catalogue data directly to the purchasing workflow. Each requisition line is linked to its order context through the placer order number in ORC, and patient and visit context from PID and PV1 is carried through to support patient-specific procurement and charge allocation. 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
- ORN — the non-stock requisition order acknowledgement returned in response to an OMN.
- OMS — the stock requisition order message for items held in standard inventory.
- ORM — the general order message that covers a wide range of clinical order types.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMN_O07
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RQD
- HL7 Messaging Standard Version 2.5.1 product brief
