HL7 OMN_O07 Non-Stock Requisition Order

The requisition order for items that are not ordinary on-hand stock.
HL7 message structure OMN_O07 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
NTE
 Notes and Comments No Yes
OMN_O07.PATIENT
 Patient group No No
PID
 Patient Identification Yes No
PD1
 Patient Additional Demographic No No
NTE
 Notes and Comments No Yes
OMN_O07.PATIENT_VISIT
 Patient Visit group No No
PV1
 Patient Visit Yes No
PV2
 Patient Visit - Additional Information No No
OMN_O07.INSURANCE
 Insurance group No Yes
IN1
 Insurance Yes No
IN2
 Insurance Additional Information No No
IN3
 Insurance Additional Information, Certification No No
GT1
 Guarantor No No
AL1
 Patient Allergy Information No Yes
OMN_O07.ORDER
 Order group Yes Yes
ORC
 Common Order Yes No
OMN_O07.TIMING
 Timing group No Yes
TQ1
 Timing/Quantity Yes No
TQ2
 Timing/Quantity Relationship No Yes
RQD
 Requisition Detail Yes No
RQ1
 Requisition Detail-1 No No
NTE
 Notes and Comments No Yes
OMN_O07.OBSERVATION
 Observation group No Yes
OBX
 Observation/Result Yes No
NTE
 Notes and Comments No Yes
BLG
 Billing No No

OMN_O07 is the non-stock requisition order. It looks a lot like OMS_O05, but the workflow is different: the requested item may need vendor catalog detail, purchasing review, substitution rules, or manual fulfillment instead of a simple pick from a supply room.

The message still uses ORC for order control and identifiers. RQD identifies the requisitioned item and quantity, while RQ1 is especially useful for manufacturer, vendor, catalog, taxable, and substitute-allowed details.

A small OMN O07 example

MSH|^~\&|SURGERY|CITYHOSP|PURCHASING|CITYHOSP|20260717122000||OMN^O07^OMN_O07|OMN070001|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L PV1|1|I|SURG^OR2^A^CITYHOSP ORC|NW|NSREQ9001^SURGERY||||||20260717122000|||44556^Planner^Paula TQ1|1||||||20260718100000 RQD|1|CUSTOM-SPLINT^Custom wrist splint^L|||1|EA|SURG|742500|OR2^Operating room 2^L|20260718 RQ1|175.00|ORTHOCO^Orthopedic Supply Co^L|WS-9931|ORTHOVENDOR^Ortho Vendor^L|OC-WS-9931|N|N NTE|1||Exact model requested by surgeon; substitution not allowed

What workflow it represents

The sender is usually requesting something that is patient-specific, procedure-specific, rarely stocked, or purchased on demand. The receiver may be purchasing, materials management, a departmental inventory system, or an integration engine routing to one of those systems.

Because the item may not exist in the receiver's normal stock catalog, vendor and manufacturer fields often matter more than they do in a stock requisition.

How to read the structure

The optional patient group carries patient and visit context when the requisition is tied to care. The required ORDER group contains ORC, optional timing, required RQD, optional RQ1, notes, optional OBX supporting observations, and optional BLG billing detail.

RQD should answer "what item and how many?" RQ1 should answer "which manufacturer, catalog, vendor, price, tax, and substitution rules?" Keep those questions separate.

Implementation traps

Non-stock requests fail when the requester sends a nice display name but no usable catalog or vendor detail. A human might recognize the item, but an automated purchasing route needs maintained identifiers.

Substitution is another quiet trap. If the item is clinically specific, send substitute-allowed rules clearly. If substitution is allowed, decide who can approve the substitute and how that approval comes back.

Reference notes

The HL7 v2+ OMN_O07 page describes non-stock requisitions as using RQD and RQ1 detail, either through older ORM-compatible patterns or through the dedicated OMN and ORN messages.