HL7 OMB messages place an order for a blood product from the blood bank — the request that a specific unit of blood or a blood-derived product be prepared and made available for a patient. An OMB message is sent from the ordering clinical system to the blood bank information system, which uses it to identify, crossmatch, and stage the requested product. This page explains what an OMB message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OMB order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OMB message represents
An OMB message — OMB stands for Blood Product Order Message — communicates a clinician's order for a blood product. The core of the message is the BPO segment, which carries the blood-product-specific ordering data for a single product request: the product type, the processing requirements such as irradiation or leukoreduction, the quantity, the intended use date, and the requested dispense location. The BPO is deliberately different from the pharmacy order segment RXO — it records requirements that are particular to blood-bank practice, including ABO/Rh compatibility constraints and processing instructions that have no equivalent in a medication order.
The sender is the clinical ordering system or EHR, and the receiver is the blood bank information system. OMB initiates the blood-bank workflow: on receipt, the blood bank selects and crossmatches compatible units, applies any required processing, and prepares the product for dispense or infusion. Because the order drives all of that preparation work, the BPO — not a later dispense or transfusion message — is the authoritative record of what was requested and under what constraints.
When an OMB message is sent
An OMB message is sent when a clinician places a blood product order. Typical scenarios include pre-operative orders for packed red blood cells, standing orders for platelet transfusions in oncology patients, and urgent crossmatch requests in trauma or surgical settings. A separate order group within the same message is used for each distinct product type, so a single OMB can carry an order for both red cells and fresh frozen plasma placed simultaneously.
Trigger event
The OMB message type carries a single trigger event:
OMB^O27– Blood product order message.
Because OMB has one trigger event, the receiver's handling turns on the contents of BPO — the product type, processing requirements, quantity, and timing — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the clinical ordering system emitting a blood product order through the integration engine to the blood bank information system and the systems that record and act on it.
{{diagram: clinical ordering system → OMB message → integration engine → blood bank information system / EHR order record / billing / inventory}}
Typical senders: EHR or clinical ordering system, order-entry workstation, perioperative management system.
Typical receivers: blood bank information system, transfusion service, EHR order record, and billing or charge capture.
Direction: unidirectional order from the clinical source to the blood bank and downstream recording systems.
Segments in an OMB message
The OMB_O27 message is organised into groups: an optional PATIENT group (PID through AL1) that carries demographics, visit, insurance, and allergy data, and one or more ORDER groups, each opening with ORC and containing the BPO blood product order. 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 OMB message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OMB^O27), 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 or field population differs across ordering-system releases. |
[PID] | Patient Identification. Identifies the patient the blood product 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 blood bank orders almost always carry patient identification for crossmatch purposes. |
[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. The assigned location in PV1-3 is particularly important for blood product orders because it determines where the product will be delivered. |
[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 — one IN1 per insurance plan. Used for billing and prior authorisation when the blood product order triggers a charge. |
[IN2] | Insurance Additional Information. Extends IN1 with supplementary insurance data when present. |
[IN3] | Insurance Additional Information — Certification. Certification and pre-authorisation data for the insurance plan. |
[GT1] | Guarantor. Financial guarantor for the patient's account, used when blood product charges require a guarantor link. |
[{AL1}] | Allergy Information. Patient allergies carried with the order. Optional and repeating — relevant for the blood bank to flag known reactions to blood products or components. |
ORC | Common Order. Opens each order group and carries the order control code, placer and filler order numbers, and ordering provider. For a new blood product order the ORC carries order control code NW. Required, and the order group repeats once per blood product line. |
[{TQ1}] | Timing/Quantity. The dosing schedule and timing for the order — the transfusion start date, rate, and duration. 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 transfusion schedules apply. Optional and repeating. |
BPO | Blood Product Order. The core of the message and the only required clinical segment in the order. It carries the blood-product-specific ordering data: the set ID in BPO-1, the BP universal service ID in BPO-2 (the product code identifying the type of blood product), processing requirements in BPO-3 (irradiation, leukoreduction, washing, and similar instructions), the ordered quantity in BPO-4, the amount in BPO-5, the units in BPO-6, the intended use date and time in BPO-7, the intended dispense-from location in BPO-8, the intended dispense-from address in BPO-9, the requested dispense date and time in BPO-10, and the requested dispense-to location in BPO-11. |
[{NTE}] | Notes and Comments. Notes relative to the blood product order, following the BPO. Optional and repeating — used to communicate clinical context, special handling instructions, or crossmatch requirements to the blood bank. |
[{DG1}] | Diagnosis. Diagnosis codes associated with the order — relevant for blood product orders that require a clinical indication for the transfusion, such as an anaemia diagnosis for red-cell orders. Optional and repeating. |
[{OBX}] | Observation/Result. Clinical observations associated with the order — for example, the patient's most recent haemoglobin, ABO/Rh type on file, or antibody screen results. Optional and repeating; each OBX may carry its own NTE. |
[{NTE}] | Notes and Comments (Observation). Notes attached to the preceding OBX. Optional and repeating. |
[BLG] | Billing. Billing information for the order — the charge type, account number, and billing code — used when the blood product order must generate a charge at the time of ordering rather than at dispense. Optional. |
[ ] = optional, { } = repeating
The order group from ORC through BLG repeats once per blood product line, so a single OMB message can order multiple blood product types simultaneously. The canonical segment pages carry the full field-by-field detail.
Sample OMB message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|EHR|MERCYGEN|BLOODBANK|MERCYGEN|202406150730||OMB^O27^OMB_O27|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^A||19650315|F
PV1|1|I|3N^301^A^MERCYGEN||||5001^PATEL^RAVI^^^^MD|||SUR
ORC|NW|ORD2024061501^EHR||||||202406150730|||5001^PATEL^RAVI^^^^MD
TQ1|1|||||||202406151400|202406151600
BPO|1|E0670^Red Blood Cells Leukoreduced^HL70396|LR^Leukoreduced^HL70508|2|2|UNITS|202406151400|||202406151400|3N^301^A^MERCYGEN
NTE|1|L|Crossmatch required. Patient has anti-E antibody on file.
DG1|1||D64.9^Anaemia unspecified^ICD10
OBX|1|NM|718-7^Hemoglobin^LN||7.2|g/dL|12.0-16.0|L|||F|||202406150700
What this sample shows
The OMB^O27 in MSH-9 marks a blood product order. PID carries the medical record number MR98765, and PV1 places the patient on ward 3N, room 301, under surgeon PATEL. ORC opens the order group with control code NW (new order) and placer order number ORD2024061501. TQ1 schedules the transfusion window from 14:00 to 16:00. The BPO is the clinical core: product code E0670 identifies leukoreduced red blood cells, BPO-3 carries the processing requirement LR (leukoreduced), BPO-4 and BPO-6 order 2 units, and BPO-11 directs dispense to the patient's ward location. The NTE communicates the crossmatch requirement and a known antibody to the blood bank. DG1 provides the clinical indication, and OBX carries the triggering haemoglobin result of 7.2 g/dL.
Working with OMB messages
Read the product requirements from BPO, not from ORC
The blood-product-specific data — product type, processing requirements, intended use timing, and dispense location — lives in BPO, not in ORC. ORC carries the administrative order data; BPO carries the clinical blood-bank requirements. A blood bank system that reads only ORC will miss the processing instructions in BPO-3 and may issue an unprocessed unit where an irradiated or leukoreduced product was ordered.
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 BPO-1 (the set ID) as the natural business key for a blood product order line. Blood bank feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed order from issuing a second unit or generating a duplicate crossmatch request.
Processing requirements and product selection
BPO-3 carries a repeating coded field for processing requirements — a single BPO can specify both irradiation and leukoreduction, for example. The blood bank system must evaluate all repetitions of BPO-3 when selecting and preparing a unit; ignoring any one of them can result in a non-compliant product reaching the patient.
Intended use timing and urgent orders
BPO-7 records when the product is intended to be used, and BPO-10 records when the product is requested for dispense. A gap between these two times reflects preparation and transport lead time. For urgent orders, these fields may be equal or very close; build alerting logic on BPO-7 rather than message arrival time, since messages can be queued and delayed relative to the clinical need.
Vendor variance. The insurance and guarantor segments (
IN1,IN2,IN3,GT1) are optional and are included only when the sending system has billing information to convey. Many blood bank order interfaces omit them entirely and handle billing downstream from the dispense or transfusion message. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A blood product order corresponds conceptually to a combination of the FHIR ServiceRequest resource (the order intent and clinical parameters) and the BiologicallyDerivedProduct resource (the specific blood product type and processing requirements), 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 OMB_O27 and no ConceptMap for the BPO segment — blood-product-specific segments are not covered among the published pharmacy or order maps. A FHIR representation produced from an OMB message is therefore mapped manually, taking the product type, processing requirements, quantity, and timing from BPO and expressing the order intent as a ServiceRequest referencing a BiologicallyDerivedProduct.
Common pitfalls
Pitfall. Treating
BPO-3as a single value rather than a repeating field. Processing requirements such as irradiation and leukoreduction are carried as separate repetitions ofBPO-3; a parser that reads only the first repetition may issue a unit that meets only one of multiple required processing steps.
Pitfall. Routing the order without checking the intended dispense-to location in
BPO-11. Blood product orders for different wards or procedure locations in the same message each carry their delivery location inBPO-11; ignoring it and defaulting to the patient's current ward can send a unit to the wrong location.
Pitfall. Assuming a fixed date-time precision. Some senders populate
BPO-7asYYYYMMDDand others as a full timestamp with an offset; do not assume a timezone — normalize on ingest and alert when the urgency of the order means that ambiguity in the intended-use time has clinical significance.
How Vorro handles OMB messages
Vorro ingests the OMB feed over MLLP or another transport, deduplicates on MSH-10, and routes each blood product order to the blood bank information system and every other subscribed destination in the format that system expects — the order record, billing, and inventory. Vorro reads the product type, processing requirements, quantity, and timing from BPO, links each order line back to the common order through the placer order number in ORC, surfaces the patient's allergy information from AL1 and any supporting observations from OBX alongside the order, and, where a FHIR destination is configured, maps the order to a ServiceRequest and BiologicallyDerivedProduct — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- ORB — the blood product order acknowledgement returned by the blood bank in response to an OMB order.
- BPS — the blood product dispense status message that reports when a blood product has been issued from the blood bank.
- ORM — the general order message, which covers clinical orders outside the pharmacy and blood bank domains.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OMB_O27
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for BPO
- HL7 Messaging Standard Version 2.5.1 product brief
