Kōami
Back to Resources
Operations6 min read

The Blood Bank Is a Licensed Establishment, Not a Module

K

Kōami

Editorial team

Share this article
The Blood Bank Is a Licensed Establishment, Not a Module — Operations | Kōami

Most hospital software treats the blood bank as a stores problem with unusual units. Items come in, items go out, keep track of expiry. It is an understandable model and it is wrong in a way that only shows up under inspection, or on the night a transfusion reaction has to be traced back through three donations.

A blood centre is a separately licensed establishment operating under drug law. The unit of stock is a human donation, and the record has to survive scrutiny years later.

What makes a blood bank different from any other inventory?

Every unit has an origin that must remain traceable to a named donor, and every unit is released only after tests that are legally mandated.

That produces requirements ordinary inventory never has:

  • A donor record, with eligibility screening at each donation and a deferral history that must be honoured at the next visit.
  • Mandatory transmissible-infection testing before any unit is released, with results recorded against the specific unit.
  • Component separation, where one donation becomes several products with different shelf lives and storage conditions.
  • Cold chain that is monitored and recorded, not assumed.
  • Traceability that runs in both directions: from donor to every recipient of every component, and from a recipient back to the donation.
  • Retention of records for the period the rules specify, long after the unit itself is gone.

An inventory module that models units as fungible stock cannot express most of that.

Where the licensing sits

Blood centres operate under the Drugs and Cosmetics Act and its rules, with separate licences for whole blood and for component preparation, and with defined requirements for premises, equipment and technical staff.

The practical consequence for software is that the licence conditions describe records the establishment must maintain, and an inspection tests whether those records exist and agree with each other. Registers that agree with each other are exactly what software should be good at and what parallel paper systems are bad at.

Apheresis, component preparation and storage centres each carry their own conditions. Verify what your establishment is licensed for against the current rules and your own licence, rather than assuming a general answer applies.

The donor is a longitudinal record, not a form

Treating each donation as an isolated event is the design error that causes the most trouble later.

A donor has a history: previous donations with dates, which matters because minimum intervals apply; deferrals, temporary or permanent, with the reason; adverse reactions during donation; and test results from previous visits. When the same person returns eight months later, the system should recognise them and apply what it already knows, rather than starting a blank form.

This matters most for deferrals. A permanent deferral recorded on paper in a register at one desk, in an establishment where the donor can present at a camp instead, is a deferral that will not be honoured. The registry has to be one registry.

Testing, release and the quarantine that must be enforced

No unit should be issuable before its mandatory tests are complete and recorded, and that has to be enforced by the system rather than by convention.

The pattern to build is a quarantine state that is the default: a unit enters quarantine on collection, testing results attach to the unit, and release requires a complete and negative set plus an authorised person's sign-off. Anything not released cannot be crossmatched or issued, and the block is at the point of issue, not a warning on a screen somebody can dismiss.

Where a test is reactive, the workflow branches into discard and donor notification, and both need recording — the notification especially, because informing a donor of a reactive result is a clinical and ethical obligation, and evidence that it was done is part of the record.

The most dangerous unit in a blood bank is one that is physically in the fridge and administratively in limbo. Software's job is to make sure the fridge and the record agree on which units exist.

Crossmatch to bedside, which is where identity fails

Transfusion errors are overwhelmingly identity errors, and they happen at the two ends: sample collection and administration.

The sample drawn for grouping and crossmatch has to be provably from the patient it is labelled for, which argues for labelling at the bedside from the patient's own wristband rather than from pre-printed labels carried to the ward. The unit issued has to be provably matched to the patient at the moment of administration, which is where a second check by a second person, or a scan of both wristband and unit, does the work.

Everything in between — the crossmatch itself, the issue register, the transport — matters, but the two identity checks at the ends are where the catastrophic errors are prevented.

The transfusion event itself belongs in the patient's clinical record: which unit, at what time, given by whom, with observations during and after, and any reaction. A blood bank register that records issue but not administration cannot answer what happened to a unit after it left the counter.

Reactions and traceability, both directions

When a transfusion reaction is reported, the system has to answer two questions quickly, and it should answer them without anyone opening a register.

The first is what this patient received: every unit, its donation, its components, its test results. The second is the reverse lookup — this donation produced these components, which went to these patients, so who else needs to be considered. That second query is the one paper systems cannot do in useful time, and it is the one that matters when a look-back is triggered.

Build the reaction workflow as a first-class record: reported by whom, clinical features, samples sent, investigation findings, conclusion, and any action on the donor. It is a reportable event, and the investigation is a record in its own right.

What to check in your current system

  • Can you produce, in one query, every recipient of every component of a given donation?
  • Can a unit be issued before its test results are complete? Try it.
  • Does a permanent deferral recorded at a camp block that donor at the main centre?
  • Is the transfusion administration recorded in the patient's chart, or only the issue in the bank's register?
  • Are storage temperatures logged automatically, with alarms and acknowledgements recorded?
  • Does the discard record say why, and who authorised it?
  • Can you reconcile physical stock in a refrigerator against the system, and has anyone done it recently?

A blood bank that answers those cleanly is running a licensed establishment. One that cannot is running an inventory module with red bags in it, and the difference becomes apparent at the worst possible moment.

Found this useful? Pass it on to someone on your team.

Share this article