HL7 BPO Blood product order

HL7 field reference BPO fields from HL7 v2.5.1 Show fields

These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.

Fields

FieldNameRequiredRepeatableTypeTable
BPO.1 Set ID - BPO Yes No SI
BPO.2 BP Universal Service ID Yes No CWE
BPO.3 BP Processing Requirements No Yes CWE 0508
BPO.4 BP Quantity Yes No NM
BPO.5 BP Amount No No NM
BPO.6 BP Units No No CE
BPO.7 BP Intended Use Date/Time No No TS
BPO.8 BP Intended Dispense From Location No No PL
BPO.9 BP Intended Dispense From Address No No XAD
BPO.10 BP Requested Dispense Date/Time No No TS
BPO.11 BP Requested Dispense To Location No No PL
BPO.12 BP Requested Dispense To Address No No XAD
BPO.13 BP Indication for Use No Yes CWE 0509
BPO.14 BP Informed Consent Indicator No No ID 0136

BPO describes a blood product order: what product is requested, how much is needed, when it is needed, and how the blood bank should treat the request.

The standard describes BPO this way: Blood product order messages require additional information that is not available in other standard HL7 order messages. Blood product order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction) and the amount of the blood product to be administered.

Blood product segments are about tightly controlled inventory and patient-safety workflow. The same unit may be ordered, prepared, dispensed, transfused, returned, wasted, or otherwise dispositioned.

Keep product identifiers, unit numbers, status, timing, and responsible staff precise. A receiver should never have to guess whether a field describes the requested product, the issued product, or what actually happened to it.

The v2.5.1 structures show BPO in BPS_O29 - BPS - Blood product dispense status, BRP_O30 - BRP - Blood product dispense status acknowledgment, BRT_O32 - BRT - Blood product transfusion/disposition acknowledgment, and BTS_O31 - BTS - Blood product transfusion/disposition, and 2 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.

For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.

BPO-1 Set ID - BPO RequiredR SingleS TypeSI

BPO-1 is the sequence number for this BPO segment within its repeating group. It keeps multiple BPO lines in order; it is not the business identifier for the blood product workflow.

BPO-2 BP Universal Service ID RequiredR SingleS TypeCWE

BPO-2 identifies the BP Universal Service ID for this blood product workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.

BPO-3 BP Processing Requirements OptionalO RepeatableR TypeCWE Table0508

BPO-3 carries BP Processing Requirements for this blood product workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.

The generated panel links this to HL7 table 0508; many real interfaces narrow that list further, so follow the receiver's implementation guide.

BPO-4 BP Quantity RequiredR SingleS TypeNM

BPO-4 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.

BPO-5 BP Amount OptionalO SingleS TypeNM

BPO-5 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.

BPO-6 BP Units OptionalO SingleS TypeCE

BPO-6 supplies the units that make the companion numeric field meaningful. Units should be coded consistently, especially for medication, lab, specimen, and billing quantities.

BPO-7 BP Intended Use Date/Time OptionalO SingleS TypeTS

BPO-7 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.

BPO-8 BP Intended Dispense From Location OptionalO SingleS TypePL

BPO-8 places the blood product workflow in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.

BPO-9 BP Intended Dispense From Address OptionalO SingleS TypeXAD

BPO-9 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.

BPO-10 BP Requested Dispense Date/Time OptionalO SingleS TypeTS

BPO-10 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.

BPO-11 BP Requested Dispense To Location OptionalO SingleS TypePL

BPO-11 places the blood product workflow in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.

BPO-12 BP Requested Dispense To Address OptionalO SingleS TypeXAD

BPO-12 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.

BPO-13 BP Indication for Use OptionalO RepeatableR TypeCWE Table0509

BPO-13 carries BP Indication for Use for this blood product workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.

The generated panel links this to HL7 table 0509; many real interfaces narrow that list further, so follow the receiver's implementation guide.

BPO-14 BP Informed Consent Indicator OptionalO SingleS TypeID Table0136

BPO-14 tells the receiver the state of this blood product workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.

The coded value should follow HL7 table 0136 or the narrower table in the local profile.

Related links