Plasma Collection Center Software Problems: The 7 That Cost Throughput and Compliance, and How to Avoid Them

Why does a first release that tries to cover every center at once go wrong?

The instinct is understandable. A deferral is a network fact, so the system has to be a network system, so surely it should go live everywhere. That reasoning skips the part that actually breaks projects here, which is that a screening station is a production line with a clock on it. Staff have roughly fourteen minutes to confirm identity, run the deferral check, take vital signs, complete protein and hematocrit, work the health history questionnaire, confirm the donation interval and compute the permitted collection volume from the donor weight band. A new workflow costs throughput before it improves it, every single time.

Roll that cost across twenty centers simultaneously and you get a bad month that management remembers for two years, plus a support load nobody staffed for, plus a quality function trying to review deviations from twenty sites at once. Projects that do this rarely fail technically. They fail politically, and the software gets blamed for a rollout decision.

The fix is to go live in two centers and keep the existing system running everywhere else. Pick one high volume site and one that is representative rather than exemplary, run them for several weeks, and let the screening staff tell you where the workflow costs seconds. Those seconds are the whole product. A focused first release covering the network donor record, cross center deferral enforcement, health screening and the eligibility engine runs $110,000 to $220,000 over 14 to 20 weeks in our delivery experience, and that band assumes a staged cutover rather than a single switch.

What goes wrong when donor and deferral history is migrated?

Two failures, and they pull in opposite directions.

The first is migrating too much. Teams try to bring across every historical donation record because it feels safer, and they inherit years of data quality problems that then have to be resolved inside a regulated record. Duplicate donor records created when someone presented with a different identity document. Deferrals recorded as free text in a comment field rather than as a structured event. Interval calculations that were correct under a policy that has since changed.

The second is migrating too little. A donor arrives on day one of go live and their eligibility depends on a deferral applied three years ago with an indefinite interval, and it did not come across because someone scoped the migration to the trailing twenty four months.

The rule that resolves both is to migrate exactly what eligibility evaluation needs, in full, and to keep everything else retrievable under a documented retention plan rather than loading it. That means every deferral of any age, the last qualifying donation per donor, and the identity resolution set. It also means deferrals arrive as structured objects with type, reason, interval, owner and release conditions, not as text somebody has to read. Free text deferrals that survive migration will be missed by the eligibility engine, and a missed deferral is the exact failure the build exists to prevent.

Why do device and laboratory integrations break after launch?

Because both are treated as interface exercises in the quote and are physical realities on the floor.

Plasmapheresis devices on a live floor behave differently from a specification document. Firmware versions differ between machines bought in different years. A device that was fine in the test lab produces a slightly different record when an operator interrupts a procedure, and interruption is normal. Ask any prospective developer which specific device models they have pulled procedure data from and what surprised them, because a team that has done it has a story and a team that has not will discover yours in production.

The laboratory interface fails differently and more expensively. Results do not only update a donor status. They drive retroactive deferral, unit disposition and quarantine, so a result that arrives malformed, late, or matched to the wrong donation is a product safety problem rather than a data problem. The pattern that holds up is an inbound feed that validates structure before it acts, refuses to guess at an ambiguous donor match, and pushes anything it cannot resolve into an exception queue owned by a named person in quality rather than into a log file. Silent failure in either of these integrations is worse than a loud one, because the system keeps telling the floor that everything is fine.

What happens when the override path and validation are not covered?

Every real center needs a physician substitute to be able to override an eligibility decision in defined circumstances. Build a system with no override path and it will be worked around within a week, usually by a shared login and a phone call. Build one with an unlogged override and you have made things worse than paper, because you have created a route around the control with no evidence that it was used.

The override has to be a first class object: who, when, which rule, what reason, what authority, attached to the donation and visible in the decision record. That decision record is the other thing projects skip. The output of an eligibility evaluation should not be a yes or a no. It should be a stored list of every rule evaluated with its result, so an inspector, a physician substitute, and you in two years can all read exactly why this donor was accepted on that day.

Underneath both sits computer system validation, and this is where builds in this sector go wrong when they are run like ordinary business software. The donor and donation records are part of a regulated manufacturing record, federal expectations for electronic records and signatures apply, and the system will be inspected. That means an append only model where corrections are new events referencing the original, individual authentication with no shared logins at the screening station, a complete audit trail, and a change control process that produces evidence as a by product of how the team works. A developer who does not raise validation before you do is the wrong developer, and one who plans to write the documentation at the end will hand you a system that fails inspection and a project that reopens.

Should you build custom or configure what you already own?

Below roughly five centers, buy. Haemonetics NexLynk and Mak-System are real systems built by organisations that understand this domain, and at that scale a validated commercial product costs far less than owning the validation burden yourself. Your differentiation at five centers is donor experience inside the building, not the software behind it, and a build would consume the management attention that should go into staffing and site selection. This is a straightforward recommendation and we make it often.

The economics change when the operating model diverges from what a shared product can express. Build when two or more of these are true. You operate enough centers that a deferral must be a network fact and your current answer involves the word synchronisation. You compete on compensation and loyalty and cannot change a schedule without a vendor request. You are opening centers faster than your vendor can configure them. Your throughput varies between centers and nobody can explain why with data. Or device and laboratory data reaches the donation record through transcription.

One hard precondition either way: do not build if you have no quality assurance function capable of owning computer system validation. The software is half the obligation, and the half you cannot outsource.

How do hidden costs get into the quote?

Center count is the obvious one, but it hides in rollout rather than in engineering. Training, staged cutover, parallel running and the operational discipline of switching a screening workflow are real line items and they scale with sites, not with features.

Device integration is the second, and the honest question is how many device models rather than whether devices are integrated. The payment card provider integration is the third, and it is usually underpriced because reconciliation is treated as reporting when it is actually a control. The fourth is validation depth, which is set by your own quality system rather than by the developer, so a quote produced without reading your validation procedures is a guess.

The fifth is the one nobody warns you about: compensation flexibility. Quotes price a compensation model. What you need is versioned, effective dated schedules by center and donor segment that marketing can change on a Monday. Building the second is meaningfully more work than the first, and skipping it is how promotions end up on spreadsheets with payments adjusted by hand, which is both an operating cost and exactly what fraud looks like in an audit.

What separates a build that works from one that fails here?

Ask a prospective developer to describe what happens when a test result comes back reactive. A team that has done regulated collection work will immediately talk about retroactive deferral, finding every unit collected since the relevant date across all centers, quarantine, disposition and notification. A team that describes updating a donor status field has built a booking system with a medical vocabulary.

Ask how eligibility rules are structured. They come from different sources with different change processes: federal requirements for source plasma collection, industry quality programme rules including the qualified donor concept that creates the inventory hold, your own stricter company policy, and center specific rules under a corrective action. If they are mixed into one hardcoded check, nobody can tell which change needs validation evidence, so nothing changes safely and the system ossifies within a year.

Ask what computer system validation means for this build before you raise it yourself, and listen for whether validation runs alongside development or gets promised for the end.

Then settle ownership in writing before kickoff: the repository, the infrastructure accounts, and the validation documentation. The validation package matters as much as the source code here, because without it your next developer starts the evidence trail from zero. At Digital Heroes the client owns the code from the first commit, and in this category the same should be true of every artefact an inspector would ask to see.