HL7 OMP messages communicate a pharmacy or treatment order — the record that a prescriber has requested a medication, in what amount and form, for a specific patient. An OMP message is the v2.5+ replacement for the older ORM^O01 for pharmacy orders, and is sent from the prescribing or order-entry system to the pharmacy information system that will fill it. This page explains what an OMP message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMP order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMP message represents
An OMP message — OMP stands for Pharmacy/Treatment Order Message — communicates a new or updated pharmacy order from the prescriber to the filling pharmacy. The core of the message is the RXO segment, which carries the order as the prescriber expressed it: the requested medication, the minimum and maximum give amounts, the dosage form, the dispense amount, and any provider instructions. The RXO is a prescriber-facing expression of the order — it records what was requested, not what the pharmacy has encoded or dispensed.
The sender is the order-entry or clinical application, and the receiver is the pharmacy information system that will process and fill the order. OMP sits at the start of the pharmacy workflow: an OMP message places the order, and downstream messages such as RDE carry the pharmacy-encoded form and RDS reports the dispense. Because the order is the event that authorises medication preparation, the RXO — not any subsequent message — is the authoritative record of what the prescriber requested.
When an OMP message is sent
An OMP message is sent when a prescriber places or modifies a pharmacy order. A single prescription may produce an initial OMP when it is placed, followed by further OMP messages if it is modified or discontinued. The order control code in ORC identifies whether the message is a new order, a change, or a cancellation, so the sequence of orders for a patient can be reconstructed from the messages themselves.
Trigger event
The OMP message type carries a single trigger event:
OMP^O09– Pharmacy/treatment order message.
Because OMP has one trigger event, the receiver's handling turns on the order control code in ORC — new order NW, replace RP, cancel CA — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the order-entry system emitting a pharmacy order through the integration engine to the pharmacy information system that fills it.
{{diagram: order-entry / prescribing system → OMP message → integration engine → pharmacy information system → (RDS dispense back to EHR / medication record)}}
Typical senders: EHR or CPOE system, clinical workstation, outpatient prescribing platform.
Typical receivers: pharmacy information system, automated dispensing cabinet controller, outpatient or retail pharmacy platform.
Direction: unidirectional order from the prescribing source to the filling pharmacy, with a separate ORP^O10 acknowledgement returned by the pharmacy.
Segments in an OMP message
The OMP_O09 message is organised into groups: an optional PATIENT group (PID through AL1) and one or more ORDER groups, each opening with ORC and ending with optional financial and billing segments. Within an order, the RXO order segment is required and carries the prescriber's intent. 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 OMP message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMP^O09), 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 order behaviour differs across CPOE or EHR releases. |
[PID] | Patient Identification. Identifies the patient the medication is ordered for — 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, though virtually all implementations include it. |
[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 order as a whole. Optional and repeating. |
[PV1] | Patient Visit. The encounter the 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. Insurance plan information for the patient. Optional and repeating to accommodate primary, secondary, and tertiary coverage. |
[IN2] | Insurance Additional Information. Supplementary insurance detail accompanying an IN1 segment. |
[IN3] | Insurance Additional Information, Certification. Certification and pre-authorisation data for the insurance plan. |
[GT1] | Guarantor. The financial guarantor for the patient's account, when relevant to the pharmacy order. Optional. |
[{AL1}] | Allergy Information. Patient allergies carried with the order. Optional and repeating. |
ORC | Common Order. Opens each order group and is the top-level record of the order itself. The ORC carries the order control code in ORC-1 — NW for a new order, RP for replace, CA for cancel — the placer order number in ORC-2, and the filler order number in ORC-3 when assigned. Required, and the order group repeats once per ordered item. |
[{TQ1}] | Timing/Quantity. The dosing schedule and timing 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 dosing applies. |
RXO | Pharmacy/Treatment Order. The core of the message and the required clinical segment in the order. It carries the requested give code in RXO-1 (the medication as the prescriber requested it), the requested give amount minimum in RXO-2, the requested give amount maximum in RXO-3, the requested give units in RXO-4, the requested dosage form in RXO-5, provider's pharmacy or treatment instructions in RXO-7, the requested dispense amount in RXO-11, and the requested dispense units in RXO-12. |
[{NTE}] | Notes and Comments. Notes relative to the order, following the RXO. Optional and repeating. |
[{RXR}] | Pharmacy/Treatment Route. The route of administration (oral, IV, IM) and site requested by the prescriber. Optional and repeating — a medication with more than one acceptable route carries one RXR per route. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound or IV preparation — each base and additive with its amount. Optional and repeating; each component may carry its own trailing NTE segments. |
[{OBX}] | Observation/Result. Order-time observations such as patient weight, height, or a clinical indicator used to justify the order. Optional and repeating; each observation may carry its own trailing NTE segments. |
[{FT1}] | Financial Transaction. Charge or pricing information associated with the order. Optional and repeating. |
[BLG] | Billing. Billing instructions for the order — when to bill and to which account. Optional. |
[ ] = optional, { } = repeating
The order group from ORC through BLG repeats once per ordered item, so a single OMP message can carry multiple pharmacy orders for the same patient. The canonical segment pages carry the full field-by-field detail.
Sample OMP message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|CPOE|MERCYGEN|PHARM|MERCYGEN|20260604091500||OMP^O09^OMP_O09|MSG00047|P|2.5.1
PID|1||MR78901^^^MERCYGEN^MR||SMITH^JANE^A||19750315|F
PV1|1|I|3N^301^A^MERCYGEN
ORC|NW|ORD2026-004^CPOE|||||||20260604091500|||PROV01^JONES^MICHAEL^^^^MD
TQ1|1||BID||20260604091500|20260614091500
RXO|00093310905^Metformin 500 MG Oral Tablet^NDC|500|500|MG|TAB||Take with meals||||||30|TAB
RXR|PO^Oral^HL70162
OBX|1|NM|29463-7^Body Weight^LN||82|kg|||||F
What this sample shows
The OMP^O09 in MSH-9 marks a pharmacy order. PID carries the medical record number MR78901, and PV1 places the patient in inpatient bed 3N^301^A. ORC carries the order control code NW (new order) with placer order number ORD2026-004, along with the ordering provider PROV01. TQ1 specifies twice-daily dosing from the order date for ten days. The RXO carries the core prescriber intent: Metformin 500 MG (RXO-1), give amount 500 in both minimum (RXO-2) and maximum (RXO-3) fields, units MG (RXO-4), dosage form TAB (RXO-5), instructions to take with meals (RXO-7), and a dispense amount of 30 tablets (RXO-11, RXO-12). RXR gives the oral route, and OBX carries the patient's body weight of 82 kg, which may be used by the pharmacy for dose verification.
Working with OMP messages
Read the order from RXO, not downstream segments
The prescriber's intent lives in RXO, not in any pharmacy-encoded segment. RXO records what was requested — the give code, the give amounts, the dosage form, and the dispense quantity — so validation and clinical decision support should operate against RXO fields, not against a derived or encoded representation that may not be present in every implementation.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the placer order number in ORC-2 as the natural business key for an order. CPOE feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed new order from creating a second prescription or a replayed cancel from cancelling a different order.
Order control codes and the order lifecycle
ORC-1 drives the order lifecycle: NW creates a new order, RP replaces it, CA cancels it, and DC discontinues it. Process each ORC code explicitly — do not treat every incoming OMP as a new order. A replace message should update the existing record keyed on ORC-2, and a cancel should suppress any pending fill rather than create a new order entry.
Give amount minimum and maximum
RXO-2 and RXO-3 carry the minimum and maximum give amounts as separate fields. When both are equal the prescriber intends a fixed dose. When they differ, as in a PRN range order, the pharmacy is authorised to dispense any amount within that range. Store both values and surface the range to pharmacists rather than collapsing to a single quantity.
Vendor variance. The patient insurance and guarantor segments (
IN1,IN2,IN3,GT1) are optional and their population varies widely by implementation — ambulatory platforms often include full insurance detail while inpatient CPOE systems omit it entirely. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A pharmacy order corresponds to the FHIR MedicationRequest 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 directly for this message. The HL7 v2-to-FHIR Implementation Guide provides no message map for OMP_O09 — the published pharmacy order map covers ORM_O01, the older general order message, which has an official Bundle map. Among the pharmacy/treatment segments, RXO does have a published ConceptMap targeting MedicationRequest, so field-level guidance is available for the core order segment. A FHIR MedicationRequest produced from an OMP message is assembled by applying the RXO segment map and supplementing with patient demographics from PID, visit context from PV1, and allergy data from AL1.
Common pitfalls
Pitfall. Treating every OMP as a new order. The order control code in
ORC-1determines whether the message creates, replaces, or cancels an order. IgnoringORC-1and processing all incoming OMP messages as new orders duplicates prescriptions and misses cancellations.
Pitfall. Collapsing the give amount range to a single value.
RXO-2andRXO-3are distinct fields for minimum and maximum. Storing only one silently discards PRN range orders and misrepresents the prescriber's intent to the pharmacist.
Pitfall. Assuming the route is always present.
RXRis optional in OMP — some implementations omit it when the route is implicit in the dosage form or the medication code. Build a default or a null-check rather than assuming a populated route segment.
How Vorro handles OMP messages
Vorro ingests the OMP feed over MLLP or another transport, deduplicates on MSH-10, and routes each order to the pharmacy or dispensing system in the format that system expects. Vorro reads the order control code from ORC to determine whether to create, update, or cancel the order, extracts the prescriber's intent from RXO — medication, give amounts, dosage form, and dispense quantity — and links each order to its patient through PID and visit through PV1. Where a FHIR destination is configured, Vorro maps the order to a MedicationRequest resource using the published RXO segment ConceptMap, supplementing with demographics and visit context — since the v2-to-FHIR Implementation Guide publishes no complete message map for OMP_O09.
Related messages
- ORP — the pharmacy order acknowledgement returned by the receiving pharmacy in response to an OMP message.
- RDE — the pharmacy encoded order, in which the pharmacy expresses the prescription in its own dispensing terms after receiving the OMP.
- RDS — the dispense message that records what was actually supplied against the order.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMP_O09
- HL7 v2-to-FHIR IG — segment maps index — confirms RXO ConceptMap targeting MedicationRequest
- HL7 Messaging Standard Version 2.5.1 product brief
