Transplant Program Software: Who Is Actually Watching the Waitlist Updates, Donor Offers and Follow Up Forms?

Why transplant coordination breaks every system the hospital already owns

It is 2:14am and a kidney offer arrives. The response window is short and the coordinator on call has to answer four questions before she can accept or decline. Is this candidate still active, or did infectious disease put her on hold on Friday after the line infection. Is her most recent crossmatch still usable. Is there a surgeon and an operating room inside the window the procurement organization gave. Has anything changed in her file since the selection committee last looked at her. The listing status lives in one system. The hold lives in a progress note somebody typed. The crossmatch is in the HLA lab system. The surgeon call schedule is a PDF on a shared drive. She opens three tabs and a phone, and the clock keeps running.

That is the operating reality of a transplant program, and it is why the systems a hospital already bought do not fit. Epic and Cerner are built around encounters. A transplant candidate is not an encounter. She is a status that persists for years, changes without a visit, and has to reconcile daily against an external registry that the hospital does not control. Every other clinical service in the building is episodic. Transplant is a register with a queue attached to it, and the register is regulated.

The cost of the gap is specific. Across programs we have worked with, coordinators spend six to twelve hours a week reconciling their own tracking spreadsheet against what is actually in the national system, and the reconciliation is the only thing standing between the program and a data submission finding. When the senior coordinator leaves, that reconciliation logic leaves with her, because it never existed anywhere except in her habits and her spreadsheet.

The waitlist is a regulated record, not a list of names

Candidate registration, status changes, inactivations, reactivations and removals each carry a submission obligation, and the record has to be defensible years later. A candidate placed on hold for a dental clearance in March and never reactivated is not a clerical error, it is a patient who sat past their window while the file said inactive. Nobody sets out to do that. It happens because the reason for the hold lived in a note, the person who set it moved services, and nothing in the system was counting the days.

CareDx OTTR is the established system of record for centers, and it holds the longitudinal candidate structure that the EHR does not. Where programs get stuck with it is change velocity: adding a field to an evaluation checklist, altering a committee route or building a report your quality director actually wants goes through the vendor and lands on the vendor's schedule, not yours. UNOS DonorNet is not a program management system at all, and was never meant to be. It is the offer channel. It knows the national queue and nothing about whether your candidate is medically clearable tonight.

What a custom build does: model candidate status as a first-class object with an explicit state machine, so every transition has an owner, a reason, a timestamp and an expiry. A hold has to be given a review date when it is created. Nothing sits open silently. The daily reconciliation against your registry export runs as a job, not as a person, and it produces one list each morning of the candidates where your record and the national record disagree. That single list is usually the first thing a program director asks for and the last thing anyone gets today.

Donor offer decisions have to be reconstructable at 2am

An offer decision is a clinical judgement made under time pressure by whoever is awake. Six months later it may be reviewed. The question will be what the coordinator and surgeon knew at the moment they declined, not what was true in hindsight. If the answer is that she checked three systems and phoned the attending, the decision exists nowhere.

What a custom build does: assemble the offer decision packet automatically the moment the offer lands. Current status, active holds, last crossmatch and its date, current labs, allergy and infection flags, insurance authorization state, surgeon and OR availability pulled from the call schedule, and the candidate's own recorded preferences on donor criteria. Push it to the on-call phone. Capture the decision, the reason code and the person, with the packet frozen alongside it. Now the decision has a defensible record and the coordinator stops assembling it by hand while the clock runs. Programs that get this piece right also start seeing patterns in their own declines, which is the first honest input into an offer acceptance conversation with the surgeons.

Evaluation is a committee process, and no EHR has a committee

Getting a candidate from referral to listed means cardiac clearance, psychosocial assessment, dental, imaging, financial and insurance approval, sometimes weight or abstinence criteria, and then a selection committee that meets weekly and produces a decision with minutes. Every organ program has a different checklist and different criteria. In an EHR this becomes a pile of orders and notes with no completion state, so the coordinator keeps the real checklist in Excel and chases the missing items by email.

What a custom build does: an evaluation template per organ program, each item with an owner, a validity period and a status that updates from the source when possible. Cardiology clearance that expires after a defined interval shows as expiring, not as done forever. The committee agenda builds itself from candidates whose checklist is complete, the committee decision writes back to candidate status, and the minutes are generated rather than typed. The measurable result is time from referral to listing decision, which is the number your referring nephrologists and cardiologists judge you on and which almost no program can currently report without counting by hand.

Follow up runs for the life of the recipient, and for living donors too

Post transplant follow up is where programs quietly accumulate risk. Recipient follow up forms are due on a schedule that runs for years, on patients who moved away, changed nephrologists or stopped coming to clinic. Living donors carry their own mandated follow up at fixed intervals after donation, on people who are healthy and have no reason to come back. Chasing them is unglamorous work that falls to whoever has capacity, which means it falls behind, and the program's data completeness rating is what gets hit.

What a custom build does: generate the due schedule the moment the transplant or donation is recorded, assign it, escalate it, and give the coordinator a work queue sorted by days remaining rather than by whoever shouted last. Route outreach through text and patient portal rather than phone tag. Pull labs directly from outside sources where you have an interface, because a serum creatinine drawn at a community lab is the single item that most often makes a form late. Living donor follow up gets its own queue and its own owner, because it competes badly against sicker patients and always loses.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. 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 and ships in 16 to 22 weeks. A full platform adding recipient and living donor follow up queues, multi-organ programs, outcome and submission reporting, and interfaces to the EHR and HLA lab runs $250,000 to $600,000 phased across 9 to 18 months.

What pushes the number up here specifically: the number of organ programs, because each has its own evaluation logic and none of it is shared. HLA laboratory integration, because typing and crossmatch results are a genuinely awkward data model and every lab system exposes them differently. Registry data submission automation, which is worth doing but is real engineering against formats you do not control. And validation and documentation depth, since this system touches a regulated process and your quality team will want traceability from requirement to test.

What keeps it down: starting with your largest organ program only, and leaving submission automation to phase two while the first release simply tells people what is late. Most of the pain relief is in visibility, not in automation.

Build versus buy, and when buying is the right call

Buy if you are a single organ program with one or two coordinators and a stable caseload. OTTR or iTransplant plus disciplined use of the EHR is genuinely enough at that size, and a custom build would be an expensive way to reproduce what you can license. Buy also if your institution has no appetite to own a clinical system, because ownership means someone internally has to make decisions about it forever.

Build when two or more of these are true. You run three or more organ programs and each one has invented its own spreadsheet. Your offer response process depends on a specific coordinator being reachable. You have had a data submission or documentation finding and the corrective action plan was to try harder. Your center participates in research or paired exchange programs whose data needs sit outside anything a packaged product models. Or the honest one: you have already paid the vendor for two change requests this year and both are still queued.

Our position is that transplant is one of the few clinical services where the coordination logic is the program. The surgery is not the differentiator, the queue management is. A center that can answer an offer faster and with better information gets more organs into more patients, and that capability should not sit on someone else's release schedule.

How to choose a developer for transplant program software

Ask them to model candidate status on a whiteboard before you sign anything. If they draw a patient table with a status column, they have not understood the problem. What you want to see is a state machine with reason codes, effective dates, review dates and an event log, and a developer who asks unprompted what happens when the registry and your record disagree.

Ask what they have integrated in a hospital, specifically. Epic and Cerner interfaces, HL7 feeds, and an HLA lab system are three different problems with three different failure modes. A team that has only done web products will learn hospital interface work on your budget and your timeline.

Ask how they handle audit trail and validation. This system will be looked at by your quality department and potentially by a regulator. Append-only event logging, requirement traceability and test evidence should be things they offer before you ask.

Ask who owns the code and get it written down before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any developer who hedges on that question.