HL7 BRP_O30 Blood Product Dispense Status Acknowledgment

The response that acknowledges a BPS dispense-status update.
HL7 message structure BRP_O30 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
MSA
 Message Acknowledgment Yes No
ERR
 Error No Yes
SFT
 Software Segment No Yes
NTE
 Notes and Comments No Yes
BRP_O30.RESPONSE
 Response group No No
BRP_O30.PATIENT
 Patient group No No
PID
 Patient Identification Yes No
BRP_O30.ORDER
 Order group No Yes
ORC
 Common Order Yes No
BRP_O30.TIMING
 Timing group No Yes
TQ1
 Timing/Quantity Yes No
TQ2
 Timing/Quantity Relationship No Yes
BPO
 Blood product order No No
BPX
 Blood product dispense status No Yes

BRP_O30 acknowledges a BPS_O29 blood product dispense status message. It tells the sender whether the status update was accepted, rejected, or accepted with returned product/order context.

The message is ACK-like at the top, but it can carry blood product detail in the response group. That is useful when both systems need to agree exactly which order, product, unit, or status was accepted.

A small BRP O30 example

MSH|^~\&|EHR|CITYHOSP|BLOODBANK|CITYHOSP|20260717143504||BRP^O30^BRP_O30|BRP300001|P|2.5.1 MSA|AA|BPS290001 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L ORC|OK|BPORD7001^EHR|BBK8801^BLOODBANK||||||20260717143502 TQ1|1||||||20260717150000 BPO|1|RBC^Red blood cells^L|IRR^Irradiated^HL70508~LR^Leukoreduced^HL70508|2|600|mL^milliliter^ISO+|20260717150000|BLOODBANK^^^CITYHOSP|||20260717143000|WARD3^312^A^CITYHOSP||ANEMIA^Symptomatic anemia^L|Y BPX|1|DISP^Dispensed^L|F|20260717143000|DON12345^BLOODBANK|RBC^Red blood cells^L|PATIENT^Patient use^L||||O POS^O positive^L|IRR^Irradiated^L|20260718120000|1|300|mL^milliliter^ISO+|UNIT12345^BLOODBANK|WARD3^312^A^CITYHOSP||44556^Receiver^Rita|77889^Issuer^Ivan

What systems do with it

The BPS sender uses BRP to know whether the receiver accepted the dispense status update. If the receiver rejects the update, ERR should identify the problem, such as an unknown patient, order mismatch, duplicate unit, invalid status transition, or unsupported product code.

For high-safety workflows, a successful MSA is not just a transport nicety. It is evidence that the receiving system has accepted the product-status fact into its own audit trail.

How to read the structure

MSH, MSA, optional ERR, software details, and notes form the response header. The optional RESPONSE group can include patient context and order groups. Each order group can carry ORC, timing, BPO, and repeating BPX.

When BPX is present, read it as the product-level status that the receiver is acknowledging. ORC tells you the order context; BPX tells you the unit/product context.

Implementation traps

Do not create an acknowledgment loop. BRP is already the application-level response to BPS; it should not normally demand another application acknowledgment back.

Also avoid accepting a status update when the unit identity is ambiguous. A product-level status without the right donation ID or unique product ID is hard to trust later.

Reference notes

The HL7 v2+ BRP_O30 page shows MSA, ERR, and an optional response group with patient, ORC, BPO, and BPX detail. Its acknowledgment notes follow the same pattern as other order-response acknowledgments: application acknowledgment messages should not themselves create another application acknowledgment cycle.