HL7 BPO Segment: Blood Product Order

The BPO (Blood Product Order) segment communicates the details of a request for one or more blood products. It identifies the universal service being ordered, how many units are requested, any special processing the products must undergo before dispensing, and where and when the products should be made available. The BPO segment is the order-detail backbone of blood bank ordering messages and works alongside companion segments that report dispense status and transfusion outcomes.

Purpose

The purpose of the BPO segment is to convey what blood product is being ordered and under what conditions. It captures the BP Universal Service ID (the coded product being requested), the BP Quantity (how many units), and the BP Processing Requirements (special handling such as irradiation, leukoreduction, or CMV-negative status). It also records intended use timing, requested dispense locations and addresses, the clinical indication for use, and whether informed consent has been obtained. Each BPO instance represents a single ordered blood product within a larger order group.

Used in

The BPO segment appears in OMB — Blood Product Order messages, where it carries the order detail for each requested blood product. A single OMB message can contain multiple order groups, each anchored by an ORC and an OBR with one BPO segment describing the specific product requested.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/BPO.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
BPO-1	Set ID - BPO	si	—	R	—	—	Sequence number for this BPO within the message
BPO-2	BP Universal Service ID	cwe	—	R	—	—	Coded identifier of the blood product ordered
BPO-3	BP Processing Requirements	cwe	—	O	Y	HL70508	Special processing the product must undergo
BPO-4	BP Quantity	nm	—	R	—	—	Number of units of the product requested
BPO-5	BP Amount	nm	—	O	—	—	Amount of the product per unit requested
BPO-6	BP Units	ce	—	O	—	—	Units of measure for the BP amount
BPO-7	BP Intended Use Date/Time	ts	—	O	—	—	Date and time the product is intended to be used
BPO-8	BP Intended Dispense From Location	pl	—	O	—	—	Location the product should be dispensed from
BPO-9	BP Intended Dispense From Address	xad	—	O	—	—	Address the product should be dispensed from
BPO-10	BP Requested Dispense Date/Time	ts	—	O	—	—	Date and time dispensing is requested
BPO-11	BP Requested Dispense To Location	pl	—	O	—	—	Location the product should be dispensed to
BPO-12	BP Requested Dispense To Address	xad	—	O	—	—	Address the product should be dispensed to
BPO-13	BP Indication for Use	cwe	—	O	Y	HL70509	Clinical indication justifying the order
BPO-14	BP Informed Consent Indicator	id	—	O	—	HL70136	Whether informed consent has been obtained

Most-used fields

In practice, four fields carry the weight of nearly every blood product order:

BPO-1 (Set ID - BPO) — establishes the order of BPO segments and lets receivers correlate each product detail with its place in the message.
BPO-2 (BP Universal Service ID) — the coded product being ordered (for example, red blood cells, platelets, or fresh frozen plasma). This is the central identifier of the order.
BPO-3 (BP Processing Requirements) — frequently populated and repeating, this field tells the blood bank which special preparations are mandatory (irradiated, leukoreduced, washed, CMV-negative).
BPO-4 (BP Quantity) — the number of units requested, which the blood bank uses for inventory allocation and dispensing.

BPO-7 (Intended Use Date/Time) and BPO-13 (Indication for Use) are commonly added to give the blood bank scheduling context and clinical justification.

Version differences (2.3 to 2.8.2)

The BPO segment, along with the broader blood bank ordering and product messaging, was introduced in HL7 v2.5. It does not exist in v2.3 or v2.3.1, where blood product orders were typically handled through generic pharmacy/treatment order segments rather than a dedicated blood product segment. From v2.5 onward the field list remained stable through v2.5.1, v2.6, v2.7, v2.8, and v2.8.2. The most visible evolution across these versions is the data type of coded fields: BP Universal Service ID, BP Processing Requirements, and BP Indication for Use are expressed using CWE in v2.5.1, consistent with the move toward CWE for coded-with-exceptions fields, while BP Units remained CE. Integrators bridging a pre-2.5 sender to a modern blood bank system must construct the BPO segment from order data that the older message expressed differently.

Common mistakes

Omitting BPO-1 (Set ID). Even when only one product is ordered, the Set ID is required and must be present so receivers can index the segment.
Treating BPO-3 (Processing Requirements) as single-valued. It is optional repeating; multiple requirements (for example, irradiated and leukoreduced) must be sent as separate repetitions, not concatenated into one component.
Confusing BPO-4 (Quantity) with BPO-5 (Amount). Quantity is the count of units; Amount with BPO-6 Units describes the volume or measure per unit. Sending volume in the Quantity field causes incorrect allocation.
Leaving BPO-2 (Universal Service ID) loosely coded. A free-text or locally invented code that the blood bank cannot resolve will cause the order to be rejected or held.
Misusing the dispense location and address fields. BPO-8 and BPO-9 describe where the product comes from; BPO-11 and BPO-12 describe where it goes. Swapping them misroutes the product.

Examples

A minimal valid segment:

BPO|1|^^^RBC^Red Blood Cells||2

A fully-populated segment:

BPO|1|^^^RBC^Red Blood Cells|^^^IRR^Irradiated~^^^LR^Leukoreduced|2|250|^^^mL^milliliters|20260615120000|WARD3^^^MercyGen^^^^^Ward 3|123 Health Way^^Springfield^IL^62704|20260615060000|OR5^^^MercyGen^^^^^Operating Room 5|123 Health Way^^Springfield^IL^62704|^^^ANEMIA^Symptomatic Anemia|Y

An annotated breakdown:

BPO|1|^^^RBC^Red Blood Cells|^^^IRR^Irradiated~^^^LR^Leukoreduced|2|250|...|Y
    |  |                     |                                     |   |       |
    |  |                     |                                     |   |       +--> BPO-14 BP Informed Consent Indicator (Y)
    |  |                     |                                     |   +----------> BPO-5 BP Amount (250)
    |  |                     |                                     +--------------> BPO-4 BP Quantity (2 units)
    |  |                     +------------------------------------------------------> BPO-3 BP Processing Requirements (Irradiated, Leukoreduced; repeating)
    |  +-----------------------------------------------------------------------------> BPO-2 BP Universal Service ID (Red Blood Cells)
    +--------------------------------------------------------------------------------> BPO-1 Set ID - BPO (1)

In-context excerpt inside an OMB message ordering a single product:

MSH|^~&|CPOE|MercyGen|BLOODBANK|MercyGen|20260612083000||OMB^O27^OMB_O27|MSG00045|P|2.5.1
PID|1||MR789012^^^MercyGen^MR||Carter^Eleanor^R||19580322|F
ORC|NW|ORD556677^CPOE|||CM||||20260612083000|||DR456^Nguyen^Linh
OBR|1|ORD556677^CPOE||^^^RBC^Red Blood Cells|||20260612083000
BPO|1|^^^RBC^Red Blood Cells|^^^IRR^Irradiated|2|250|^^^mL^milliliters|20260615120000

In-context excerpt inside an OMB message ordering multiple products in separate order groups:

MSH|^~&|CPOE|MercyGen|BLOODBANK|MercyGen|20260612091500||OMB^O27^OMB_O27|MSG00046|P|2.5.1
PID|1||MR334455^^^MercyGen^MR||Brooks^Daniel^J||19720910|M
ORC|NW|ORD778899^CPOE|||CM||||20260612091500|||DR789^Okafor^Amara
OBR|1|ORD778899^CPOE||^^^PLT^Platelets|||20260612091500
BPO|1|^^^PLT^Platelets|^^^LR^Leukoreduced|1|||20260612140000
ORC|NW|ORD778900^CPOE|||CM||||20260612091500|||DR789^Okafor^Amara
OBR|2|ORD778900^CPOE||^^^FFP^Fresh Frozen Plasma|||20260612091500
BPO|1|^^^FFP^Fresh Frozen Plasma||2|||20260612140000

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for BPO. Conceptually, a blood product order corresponds to a FHIR ServiceRequest, where the requested product maps to the request's code, the quantity and amount map to ordered quantity, and the processing requirements and indication map to order detail and reason fields. Because there is no published ConceptMap, any transformation to ServiceRequest is implementation-defined and should be validated against the receiving system's expectations.

Engine considerations

When configuring an interface engine to handle BPO:

Treat BPO-3 and BPO-13 as repeating fields. Iterate every repetition rather than reading only the first occurrence, or processing requirements will be silently dropped.
Validate that BPO-1, BPO-2, and BPO-4 are present before forwarding, since these are required by the standard and missing values typically cause downstream rejection.
Preserve coded values in BPO-2, BPO-3, and BPO-13 exactly. CWE fields carry identifier, text, and coding-system components; flattening them to text loses the codes the blood bank relies on.
Map dispense-from (BPO-8, BPO-9) and dispense-to (BPO-11, BPO-12) explicitly so the direction is never reversed during transformation.
Normalize date/time fields (BPO-7, BPO-10) to a consistent precision and time zone policy across senders.

How Vorro parses and produces BPO

Vorro parses the BPO segment field by field against the HL7 v2.5.1 structure, preserving the repetition of BPO-3 (Processing Requirements) and BPO-13 (Indication for Use) as ordered lists so no value is collapsed. Coded fields are decomposed into their CWE components and exposed individually, allowing downstream mappings to read the identifier, text, and coding system separately. When producing a BPO segment, Vorro enforces presence of the required Set ID, Universal Service ID, and Quantity, emits repeating fields with the correct repetition separator, and renders dispense-from and dispense-to locations and addresses into their respective fields without crossing the order direction. Empty optional fields are emitted as empty delimited positions so field alignment is preserved for strict receivers.

Sources

← Back to HL7 v2 Guide