HL7 BPS messages report the dispense status of a blood product — the record that a unit was issued to a patient, released back to inventory, returned to the blood bank, or reserved for a pending transfusion. A BPS message is sent by the blood bank information system to update the clinical and transfusion-management systems that need to know the current disposition of each unit. This page explains what a BPS message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a BPS dispense status relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a BPS message represents
A BPS message — BPS stands for Blood Product Dispense Status — communicates the current status of one or more blood product units being tracked by the blood bank. The core of the message is the BPX segment, which carries the dispense status for a single blood product unit: the donation ID that uniquely identifies the unit, the component type, the blood group, the current status — issued, returned, released, or reserved — and the date and time that status became effective.
The sender is the blood bank information system, and the receivers are the clinical and transfusion-management applications that must track each unit's location and disposition — most often the EHR, the transfusion service, and the charge capture system. BPS sits downstream of the blood product order: an OMB blood product order tells the blood bank what product a patient needs, and the BPS message reports what the blood bank did with that product. Because the dispense status is the authoritative record of whether a unit left the blood bank, was held for a patient, or came back, the BPX — not the original order — is the record that drives transfusion documentation and inventory reconciliation.
When a BPS message is sent
A BPS message is sent each time the status of a blood product unit changes. A single ordered unit can produce a series of BPS messages over time: first reserved, then issued when the unit is dispatched to the clinical area, and then either confirmed as transfused (closing the loop via a BTS) or returned. Each BPS message carries the status effective date and time in BPX, so the sequence of status changes for a unit can be reconstructed from the messages themselves.
Trigger event
The BPS message type carries a single trigger event:
BPS^O29– Blood product dispense status message.
Because BPS has one trigger event, the receiver's handling turns on the contents of BPX — the dispense status code, the donation ID, the component type, and the status effective date and time — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the blood bank information system emitting a dispense status event through the integration engine to the systems that record and act on it.
{{diagram: blood bank information system → BPS message → integration engine → EHR / transfusion service / charge capture / inventory}}
Typical senders: blood bank information system, transfusion management system.
Typical receivers: EHR clinical application, transfusion service, charge capture, and blood product inventory management.
Direction: unidirectional notification from the blood bank to the systems that record, bill, and reconcile blood product disposition.
Segments in a BPS message
The BPS_O29 message is organised into groups: an optional PATIENT group (PID through PV2) and one or more ORDER groups, each opening with ORC and closing after the dispense status and any donor segments. Within an order, the timing segments are optional, and the BPX blood product dispense status segment is the required clinical core. 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 BPS message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (BPS^O29), 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 dispense status behaviour differs across blood bank system releases. |
[PID] | Patient Identification. Identifies the patient the blood product is intended 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, so blood bank messages sent before patient assignment can omit 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 patient context as a whole. Optional and repeating. |
[PV1] | Patient Visit. The encounter the blood product dispense 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. |
ORC | Common Order. Opens each order group and ties the dispense status to its order. The ORC carries the order control code and the filler order number, which links the dispense status back to the originating OMB blood product order. Required, and the order group repeats once per blood product unit. |
[{TQ1}] | Timing/Quantity. The timing and quantity information 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 infusion applies. |
BPX | Blood Product Dispense Status. The core of the message and the only required clinical segment in the order. It records the current disposition of the blood product unit: the set ID in BPX-1; the dispense status code in BPX-2 (LD dispensed/issued, RD returned, RE released, RS reserved); the status effective date and time in BPX-3; the donation ID that uniquely identifies the unit in BPX-4; the blood component type in BPX-5; the donation type or intended use in BPX-6; the commercial product name in BPX-7; the commercial product manufacturer in BPX-8; the commercial product lot number in BPX-9; the blood group (ABO and Rh) in BPX-10; special testing results in BPX-11; the product expiration date and time in BPX-16; the dispensed quantity in BPX-17; and the blood product unique ID in BPX-21. |
[{NTE}] | Notes and Comments. Notes relative to the dispense status event, following the BPX. Optional and repeating. |
[{DON}] | Donation. Carries donor-specific information associated with the blood product unit. Optional and repeating; present when the downstream system requires traceability back to the donation record. |
[ ] = optional, { } = repeating
The order group from ORC through DON repeats once per blood product unit, so a single BPS message can report the status of several units simultaneously. The canonical segment pages carry the full field-by-field detail.
Sample BPS message
Note. Constructed for illustration. Patient identifiers, donation IDs, dates, and names are fictional.
MSH|^~&|BBIS|MERCYGEN|EHR|MERCYGEN|20260604143000||BPS^O29^BPS_O29|MSG00047|P|2.5.1
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^A||19720315|F
PV1|1|I|4NORTH^401^A^^^MERCYGEN
ORC|RE|ORD1102^EHR|BB8842^BBIS
BPX|1|LD|20260604142800|DON2026-00341^^^BBIS^DONATE|E0700^Red Blood Cells^HL70427|A^Allogeneic^HL70565|||LOT-2026-341|O+^O Positive^HL70426||||||20261130235959|1|||||BB-UNIT-00341^^^BBIS
NTE|1||Unit issued to 4 North nursing station at 14:28.
What this sample shows
The BPS^O29 in MSH-9 marks a blood product dispense status message. PID carries the medical record number MR98765, and PV1 places the patient in bed 401 on 4 NORTH. ORC carries order control code RE with filler order number BB8842, linking the status update back to the originating blood product order. The BPX reports the dispense: status LD (dispensed/issued) effective at 20260604142800 (BPX-2, BPX-3); donation ID DON2026-00341 identifying the specific unit (BPX-4); component E0700 Red Blood Cells (BPX-5); allogeneic donation type (BPX-6); lot number LOT-2026-341 (BPX-9); blood group O Positive (BPX-10); expiration 20261130235959 (BPX-16); quantity 1 (BPX-17); and unique product ID BB-UNIT-00341 (BPX-21). The NTE records a human-readable dispatch note.
Working with BPS messages
Read the unit status from BPX, not the order
The current disposition of each blood product unit lives in BPX, not in the order. BPX-2 is the authoritative status code — LD means the unit was issued to the clinical area, RE means it was released back to the general blood bank pool, RD means it was physically returned, and RS means it is reserved for a specific patient but not yet issued. Never infer unit status from the order alone; the order describes what was requested, not what happened to each unit.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the donation ID in BPX-4 together with the status effective date and time in BPX-3 as the natural business key for a status event. Blood bank systems are replayed after connectivity outages, and treating a repeated control id as a duplicate prevents a replayed LD status from posting a second charge or moving a unit's inventory state forward incorrectly.
Sequencing status changes for a unit
Multiple BPS messages for the same unit — identified by BPX-4 — should be sequenced by the status effective date and time in BPX-3 rather than by message arrival order, so a delayed delivery does not misrepresent the unit's history. A unit progressing from RS (reserved) to LD (issued) out of arrival order must be applied in chronological order to reconstruct the correct audit trail.
Blood group and special testing fields
BPX-10 carries the ABO and Rh blood group of the unit, and BPX-11 carries any special testing results — for example, CMV-negative or irradiated status. These fields should be persisted with the transfusion record rather than discarded; they are the traceability data required for haemovigilance and adverse-event investigation.
Vendor variance. The
DONsegment is optional and is included only when the downstream system requires traceability back to the donation record, so some blood bank systems always send it while others omit it entirely. Commercial product fieldsBPX-7throughBPX-9apply to manufactured plasma derivatives and are typically empty for collected cellular components. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A blood product dispense status corresponds conceptually to the FHIR BiologicallyDerivedProduct resource, which represents a biological material — including blood components — and can carry status, storage, and processing information. The patient context maps to a Patient resource, and for a messaging exchange a MessageHeader would appear 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 BPS_O29 and no ConceptMap for the BPX segment. A FHIR BiologicallyDerivedProduct produced from a BPS message is therefore mapped manually, taking the component type, blood group, donation ID, status, and expiration from BPX and referencing the requesting ServiceRequest derived from the blood product order.
Common pitfalls
Pitfall. Treating
LD(dispensed) as confirmation that transfusion occurred. ALDstatus means the unit was issued from the blood bank to the clinical area — it does not mean the product was infused. Transfusion confirmation arrives in a BTS blood product transfusion status message; do not close a transfusion record on a BPSLDalone.
Pitfall. Ignoring the
REandRDstatus codes. A unit sent back asRE(released) orRD(returned) must update both the patient's transfusion record — removing or voiding the planned unit — and the blood bank inventory. Discarding non-LDstatuses leaves inventory counts incorrect and transfusion records incomplete.
Pitfall. Assuming a fixed date-time precision. Some senders stamp
BPX-3asYYYYMMDDand others as a full timestamp with offset; do not assume a timezone — normalize on ingest.
How Vorro handles BPS messages
Vorro ingests the BPS feed over MLLP or another transport, deduplicates on MSH-10, and routes each dispense status event to every subscribed destination in the format that system expects — the EHR clinical record, transfusion service, charge capture, and inventory management. Vorro reads the dispense status code, donation ID, blood group, and expiration from BPX, links each status event back to its order through the filler order number in ORC, and applies the correct status transition — distinguishing issued, released, returned, and reserved units — so that inventory and transfusion records remain accurate. Where a FHIR destination is configured, Vorro maps the dispense status to a BiologicallyDerivedProduct resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OMB — the blood product order that a BPS message reports status against.
- BTS — the blood product transfusion status message that confirms a unit was actually infused.
- ORB — the general order response for blood product orders.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for BPS_O29
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for BPX
- HL7 Messaging Standard Version 2.5.1 product brief
