Client
A UK blood and transplant service responsible for donor collection, blood processing and stock distribution across a regional network of hospital blood banks
Sector
Healthcare & Life Sciences
Engagement
Live cross-site blood stock visibility platform linking hospital blood bank inventory, donation centre processing output and transport courier status into one shared operational view - multi-quarter programme.
What the client needed
Every hospital blood bank in the network held its own stock in its own local system, refreshed by whoever was on shift and reconciled against the central donation service on a batch cycle measured in hours, not minutes. That worked well enough for common blood types held at every site. It broke down for rare types, unusual phenotypes and cross-matched units held for a specific patient, where the actual answer to "where is the nearest matching unit" lived in the heads of blood bank staff at each site rather than in any system. When a treating clinician needed a unit their own hospital didn't hold, the standard process was a round of phone calls between blood banks - starting with the largest nearby site and working outward - each call asking the same question of a colleague who then had to physically check a fridge to answer it. The service's own audit found that process averaged over 90 minutes for a genuinely rare match, and in the worst cases ran past two hours, time that mattered most in exactly the clinical situations where it was hardest to spare.
How we worked
- Built a live stock visibility layer that pulled directly from each hospital blood bank's existing local inventory system, rather than asking staff to double-enter stock into a new one on top of their existing workload.
- Indexed stock by blood type, phenotype and any existing patient cross-match, so a search for a rare match returned a ranked list of holding sites instead of a single yes-or-no answer.
- Connected donation centre processing output directly into the same index, so newly processed units became searchable within the same shift they were produced, not the next reconciliation cycle.
- Integrated live transport and courier status, so a clinician searching for a unit could see not just where it was held but a realistic estimate of when it could arrive.
- Ran the platform alongside the existing phone-call process for eight weeks across four pilot sites, comparing search results against what the phone-call chain actually found before removing the fallback.
- Trained blood bank staff at every site to treat the shared index as the system of record for stock queries, since the timing gain only holds if every site is both reading from and updating the same view.
Measured results
All figures verified with the client. Specific site, patient and personnel detail withheld in line with our standard confidentiality terms and clinical data governance requirements.
- Average time to locate a matched, compatible unit of a rare blood type fell from over 90 minutes of sequential phone calls to under ten.
- Newly processed units from donation centres became searchable across the network within the same shift, rather than after the next batch reconciliation.
- The pilot period surfaced a recurring gap where units held for one patient's cross-match were not being released back into general stock promptly once no longer needed - now flagged automatically by the platform.
- Blood bank staff report fewer calls placed purely to ask "do you have any," since the index now answers that question before a call is needed.
- The service is extending the same visibility layer to plasma and platelet stock, beyond the red cell scope the programme was built for.
"We were good at processing and good at transport. The gap was always the ninety minutes in between, spent asking each other the same question one site at a time. Nobody had been able to see the whole network at once, so nobody had noticed how much of that time was just the asking."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
A blood service's data problem is unusual in one specific way: the thing it's tracking is perishable, physically distributed, and occasionally needed within an hour rather than a day. That combination ruled out the kind of central-warehouse thinking that works for most inventory problems - there was never going to be a single physical location holding "the stock," only a network of hospital blood banks each holding a slice of it, refreshed constantly by donation, transfusion and transfer between sites. The brief was explicit that the platform had to make each site's existing local system more visible to the rest of the network, not replace those systems, since every hospital blood bank already had a working, clinically validated process for managing its own fridge - the problem was entirely in what happened between sites, not within one.
Clinical safety requirements shaped the build more than any other constraint. A search result that showed a unit as available when it had already been used, or matched to the wrong phenotype, would be worse than no search tool at all. The platform was built to treat each local system as the authoritative source for its own stock at all times, refreshing the shared index continuously rather than caching it, and to show a confidence indicator alongside any result more than a few minutes old rather than presenting stale data as current.
Making rare-match search actually useful, not just fast
The harder design problem wasn't retrieving stock data quickly, it was presenting a ranked, clinically meaningful answer to a query that used to depend on a blood bank scientist's own judgement about which nearby site was worth calling first. We worked with hospital transfusion laboratory staff to encode the logic they already used informally - proximity, transport time, phenotype specificity, and whether a unit was already earmarked for another patient - into the ranking the platform surfaced, so the tool reproduced expert judgement rather than replacing it with a simpler distance-only search that would have missed cases their existing process handled well.
Running in parallel long enough to trust it
We ran the platform alongside the existing phone-call process for eight weeks across four pilot sites before removing the fallback, deliberately comparing what the index found against what the phone chain found for the same real requests. That parallel period caught a specific and consequential gap: units held for a patient's cross-match that was no longer needed were often not being released back into general stock promptly, because the release step depended on someone remembering to do it once a patient's clinical situation changed. The old phone-call process never surfaced that gap because a caller asking "do you have any of this type" would simply be told no by a site that, unrecorded, actually did. The platform now flags an aged cross-match hold automatically, prompting a release decision rather than relying on memory.
Lessons learned
The first lesson was that a genuinely distributed inventory problem - stock that must stay physically local, perishable and clinically owned at each site - calls for a shared visibility layer over existing systems, not a single replacement system, and getting that distinction right early avoided a much larger and slower programme.
The second lesson was that encoding expert judgement into a ranking is a different task from building a search index, and it took direct, sustained input from transfusion laboratory staff to get the ranking right - the platform's usefulness came from that judgement being captured accurately, not from the underlying search technology.
The third lesson was that running in parallel with the old process for long enough to compare outcomes, not just long enough to test uptime, is what surfaced the cross-match release gap - a gap the eight-week pilot caught specifically because it compared what the index said against what experienced staff already knew, rather than assuming the index was correct by default.
If your organisation manages a perishable or time-critical resource distributed across multiple sites, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.