Transplant Coordination Software Problems: The 5 That Cost Organs, Time and Credibility

Why does the scope of a transplant build get set too small so often?

The brief that reaches a development team is usually a tracking brief: coordinators are keeping candidates in a spreadsheet, so build a better list. What arrives is a candidate table with a status column, filters and a nice export. It is prettier than the spreadsheet and it fails at the same point, because a status column cannot hold the information anyone actually needs.

This is specific to transplant because a candidate is not an encounter and not a task. She is a status that persists for years, changes without a visit, and has to reconcile daily against an external registry your center does not control. Every other clinical service in the building is episodic, which is why Epic and Cerner do not fit the problem: they model encounters correctly and were never designed for a register with a queue attached to it. A status column inherits none of what matters. Who set this hold. For what reason. On what date. When should someone look at it again. What was the state on the day of the offer six months ago.

The fix is to insist on a state machine before any screen is designed. Every transition carries an owner, a typed reason, a timestamp and, where relevant, a review date mandatory at creation. Nothing sits open silently. Ask a candidate developer to model candidate status on a whiteboard, and if they draw a patient table with a status column, the conversation is finished. You want reason codes, effective dates, review dates and an event log, plus a developer who asks unprompted what happens when the registry and your record disagree.

What goes wrong when candidate data and registry reconciliation are set up?

The reconciliation against the national record is the piece everyone underestimates and the piece that produces most of the value. Coordinators currently do it by eye, which is why senior coordinators spend hours each week comparing their own tracking spreadsheet to what is actually in the national system, and why that logic leaves the program when they do.

Migration goes wrong in two ways. First, teams import the spreadsheet's current view and lose the history behind it, so the system starts life unable to answer what the record said on any past date, which is the exact question a review asks. Second, they match candidates on names and dates of birth and inherit every duplicate and every transcription difference the spreadsheet accumulated, then discover that the local record and the registry record disagree for a set of patients and nobody can say which is right.

The fix is to treat reconciliation as the first release rather than a later feature. Run it as a scheduled job against your registry export and produce one list every morning of the candidates where your record and the national record disagree. That list is unglamorous, it is the first thing a program director asks for, and it prevents the failures that hurt. Before go live, work the backlog of disagreements down deliberately with a named owner rather than importing them and hoping. Every disagreement resolved during migration is a submission finding that never happens.

Why do EHR and HLA laboratory interfaces break after launch?

They are three different problems quoted as one line called integration. Epic and Cerner interfaces, message feeds carrying results and demographics, and a human leukocyte antigen laboratory system each have their own failure modes, and the last one is genuinely awkward because typing and crossmatch results are a difficult data model and every lab system exposes them differently.

What breaks after launch is usually content rather than connection. A lab changes how it reports a result, a message adds a segment, an outside facility starts sending creatinine results in a different unit. The interface keeps running and reports itself healthy while values land unmapped, which matters more here than elsewhere: a missing or stale crossmatch date is exactly the field a coordinator relies on at two in the morning to answer an offer.

The fix is to give every inbound feed an owner, an exception queue and a volume monitor rather than only error alerting, because a source that stops sending is invisible to an error based alarm. Show data age on the screens that matter, so an offer packet displays the crossmatch date rather than only the result. And insist the developer names what they have integrated inside a hospital before you sign, because interface work is mostly negotiation with other teams rather than code, and a team that has only built web products will learn it on your timeline.

What happens when recipient and living donor follow up is not covered?

Follow up is where programs quietly accumulate risk, and it is the first thing cut when a scope needs to shrink because it feels administrative. Recipient follow up runs for years on patients who moved away, changed nephrologists or stopped attending clinic. Living donors carry their own mandated follow up at fixed intervals after donation, on healthy people who have no reason to come back.

Left out of the build, this stays with whoever has capacity, which means it falls behind, and the program's data completeness is what takes the hit. The living donor queue loses every time it shares a list with sicker patients, because a human triaging one list will always work the acute case first. That is not a discipline problem, it is a design problem.

The fix is to generate the due schedule the moment a transplant or donation is recorded, assign an owner, and present a queue sorted by days remaining rather than by whoever shouted most recently. Escalate before the deadline rather than after. Give living donor follow up its own queue and owner so it never competes with recipients. Then pull outside laboratory results wherever an interface exists, since a creatinine drawn at a community laboratory is the item that most often makes a form late, and route outreach through text and patient portal instead of phone tag.

Should you build custom or configure what you already own?

If you are a single organ program with one or two coordinators and a stable caseload, do not build. CareDx OTTR or Transplant Connect iTransplant plus disciplined use of the electronic health record is genuinely enough at that size, and a custom build would be an expensive way to reproduce something you can license. If your institution has no appetite to own a clinical system, that is also a legitimate reason to buy, because ownership means someone internally makes decisions about it forever.

Be accurate about what the incumbents do. OTTR is the established system of record for centers and holds the longitudinal candidate structure the electronic health record does not, and for most single programs it is the right answer. The friction programs report is change velocity: adding a field to an evaluation checklist, altering a committee route or producing a report your quality director actually wants goes through the vendor and lands on the vendor's schedule. UNOS DonorNet is not a program management system and was never meant to be. It is the offer channel, and it knows the national queue rather than whether your candidate is medically clearable tonight.

The build case shows up when three or more organ programs have each invented their own spreadsheet around the product, when offer response depends on a specific coordinator being reachable, when a submission finding produced a corrective action plan amounting to trying harder, or when two change requests you paid for are still queued. In those cases the coordination logic has outgrown a configured product, and that logic is the program.

How do hidden costs get into the quote?

A first release covering candidate status with the reconciliation job, offer decision packets and one organ program's evaluation checklist and committee workflow runs $90,000 to $180,000 over 16 to 22 weeks. A full platform adding recipient and living donor follow up, multi organ support, outcome and submission reporting and interfaces to the electronic health record and the tissue typing laboratory runs $250,000 to $600,000 phased over 9 to 18 months. The drift between those is predictable.

Organ program count is the first driver and it is not a simple multiplier. Each program has its own evaluation logic, criteria and committee cadence, and almost none of it is shared. Laboratory integration is the second. Registry submission automation is the third, worth doing and real engineering against formats you do not control. Validation depth is the fourth, because this system touches a regulated process and your quality team will want traceability from requirement to test evidence, which is work whether or not it appears in the estimate.

The fifth is the one that catches schedules rather than budgets: discovery. Each organ program will find during discovery that its written selection criteria and its actual practice differ, and the build cannot proceed until that is resolved by people with authority. Budget three to five weeks with coordinators and surgeons before build starts, and treat documented criteria as a precondition rather than an output.

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

Starting with the least glamorous thing. If the budget covers one phase, build candidate status with the daily reconciliation job. It produces one morning list of everywhere your record and the national record disagree, it takes that work off your senior coordinator, and it survives her leaving. Offer decision packets are the natural second phase, and they are where coordinators feel the difference at two in the morning.

Second, decisions have to be reconstructable. An offer decision made under time pressure may be reviewed six months later, and the question will be what the coordinator and surgeon knew at that moment, not what was true in hindsight. Assemble the packet automatically when the offer lands, capture the decision, the reason code and the person, and freeze the packet alongside it. Programs that do this also start seeing patterns in their own declines, which is the first honest input into an offer acceptance conversation with surgeons.

Third, build for audit from the start rather than retrofitting. Append only event logging so history cannot be quietly edited, reason codes on every status change, traceability from written requirement to test evidence, and role based access. Ask any developer how they handle those four before discussing features, and involve your quality department during design rather than at go live.

Finally, settle ownership in writing before kickoff: repository, cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit, and a developer who hedges on that question is building a dependency rather than a system.