Coordinating a transplant, against the clock.
A coordination layer for the part of organ allocation that still runs on the phone — the scramble after the ranked centres say no, which is where kidneys are actually saved or lost.
01The problem
Roughly one in four deceased-donor kidneys recovered for transplant in the US is never transplanted [1]. Not because it was unusable when recovered, but because the search for a recipient outran the organ's shelf life.
On ice, a kidney degrades by the hour: delayed graft function runs about one in five when cold ischemia stays under 16 hours, and more than one in three past 32 [6]. When the ranked centres decline, what happens next is a coordinator on the phone, one centre at a time, reading the same donor details aloud. Fax, email, portal logins, a spreadsheet. When they run out of time or centres, the organ is discarded.
Five things are wrong with that:
- Nobody knows what time it is. Cold ischemia decides viability and lives in someone's head.
- Distribution is serial when it should be parallel. Call, wait, call, wait.
- Nobody sees what anyone else worked out. The fourth centre repeats the first three's evaluation and reaches the same conclusion, burning an hour.
- The decision and the delivery are different systems. Placement on the phone, transport in another app, the cold ischemia that determined viability recorded nowhere.
- Nothing is attributable. Who was asked, when, what they said.
The metric is organs not discarded. Response time, acceptance rate and average ETA are instrumentation for that one outcome.
02What the decisions rest on
The research here came in four kinds, and a fifth column lists what nobody did. The first column is the original client engagement, described without names; the rest was done for the rebuild. Every item says what it found, and which part of this page it changed.
Asked the original engagement
Read for the rebuild
Mapped the work
Checked my own work
Not done said plainly
03The constraint, and how it was found
The national registry provides no API to third-party products. The original architecture — offers flowing in through a registry integration — was impossible.
How the team found out, in weeks of the original engagement:
- week 2Centres key patient data into the registry by hand. The team sets out to read its API documentation.
- week 3Manual offers are added alongside automated ones, and developer access to the registry's sandbox is requested.
- week 5A call with the registry's integration team: no API for third-party products, by design.
- week 7Screen work pauses until the data picture is clear.
- week 10The product is reframed around the procurement organisation: kidneys first, donors entered by hand.
- week 17Registry and match IDs become typed fields on the donor form, and the open board is designed.
That is not a footnote, it is the design. The product became a layer that runs beside the registry rather than through it: the registry stays the legal system of record, its IDs are typed in as reference fields, and the procurement organisation enters the donor and alerts centres directly.
And the reason it works: the scramble was always manual. A digital layer over a manual process is not a compromise forced by a missing API. It is a truer fit than the integration would have been.
04One run, two roles
Two artefacts come out of the thread before a screen is drawn: a feature list, one tab per role, and a workflow diagram that puts the list, the information architecture and the user flow in one picture. Here they are one component, read two ways. Neither is a client file — both are drawn against my own rebuild, from its running build and its router, so what is in them is checkable rather than remembered.
One tab per role, never one combined list: split by role, the gaps are on the face of the document.
Pick a crossing, or step through all nine. Each names what one role's screen writes and opens the feature-list rows of the screens it joins. The counts under "every screen" are derived from the rows, not typed.
05The decision I'd defend
The practice this digitises — expedited, out-of-sequence placement — is not an uncontroversial good. It is under active criticism and increasing regulatory oversight [4].
The core mechanic has a documented equity problem
Of out-of-sequence placements, 3 organisations performed 64% and 2 transplant centres received 25% of the kidneys [3].
When a process relies on informal relationships between organizations, there is potential for exacerbating existing inequity in access to transplantation by excluding some candidates when certain transplant centers are favored over others. [2]
The brief I was working from listed, as a feature: “favourite centres drive prioritisation.” That is the exact mechanism the research criticises, shipped as a selling point.
The objection describes the absence of this product
The criticism is fundamentally that out-of-sequence placement happens on the phone, with no record, between people who know each other. A system that logs who was offered, in what order, and why anyone was skipped converts an informal favour network into an auditable process — which is what a regulator tightening oversight is asking for.
So the pitch is not “place organs faster”. It is place organs faster, and make the fast path defensible.
Concretely: the favourites list is gone. Centres declare their own criteria in advance — KDPI ceiling, HCV and DCD appetite, distance limit — and the fast list is computed per donor. Nobody is picked by hand, and every centre not on the list says why.
Seven centres, one donor, both mechanisms. The eligibility test is the same in each — only the way the list is chosen changes. Centre names and criteria are demo data from my own rebuild.
06The thread, screen by screen
Everything below is the running build, not a mockup. The clocks are live, the data is seeded, and you can open any of it in the demo.
A coordinator does not arrive at a screen wanting to browse. They arrive holding a donor and losing time. So the list leads with the clock and the distribution state, and the primary action — alerting centres — is one click from the row.
This is the screen the equity argument lives on, and the decision above is about the middle of it. The panel underneath it is the part I would show first in an interview: it is the difference between a product that helps you work and one that works when you have stopped.
The response table is the record. Not a report generated beside one — the thing the coordinator works in all night is the same object a regulator would read afterwards. That is the whole answer to the equity objection, and it only works if it is the primary surface.
Most of the hard decisions in this product are about what the other side sees. A centre that accepted and was not chosen used to find out by nothing arriving.
07Checked, and corrected
Three calls reversed on a second look: twice by the literature, once by the running build. Each one changed the product, not just this page.
I had the eligibility rules raise an amber caution at cPRA ≥ 80%: “crossmatch risk is high.” Wrong twice over.
80% is not a line allocation recognises — on the sliding scale a candidate at 80 gets about 2.5 priority points and one in the low 90s under 7, while one at 100 gets more than 200 [29]. And the framing pointed the wrong way: KDPI's association with graft survival is not modified by how sensitised the recipient is, so there is no benefit in holding out for a better kidney on their behalf — while a compatible offer may not come again for years.
The fix was not a new threshold. It was noticing that “cautions” is a rhetorical category, not a severity level: everything in it argues against acting. A high cPRA is a reason the offer matters more. The verdict now carries a third list, rendered muted rather than amber.
[29]the build's eligibility rules
The eligibility rules raised an amber caution at cPRA ≥ 80% reading “crossmatch risk is high”. Amber on this page means weigh this against acting — and a high cPRA is a reason the offer matters more, not less. It now reads as muted context: sensitised. Allocation priority climbs steeply from here. Same fact, opposite instruction.
I had concluded that the left/right laterality preference was over-modelled — outcomes are equivalent, so why let a centre rank them? True of long-term graft survival. The first six months are not: right kidneys carry higher delayed graft function (28% against 25.8%) and more technical failure, because the right renal vein is short and the anastomosis is harder [19].
And I had the actor wrong. The ranking is set by the centre's coordinator — the one whose surgeon has to sew that vein. When two kidneys go to two centres, a stated preference beats a coin-flip and leaves a record.
The feature stayed. What it was missing was its reason, which it now carries — both halves, because right runs worse without and the difference is gone by six months turns a preference into a refusal.
Twenty changes went in without stepping back. Every one was defensible alone, and the screens still ended up crowded — because a band, a column or a caption added in week three does not know about the two added in weeks one and two.
Rows in one table measured 62 / 48 / 48, because a legend wrapped inside a single cell. The open board's only action sat behind a horizontal scrollbar. Three stacked bands put 213px of chrome before a single row.
The one underneath the rest: the signed-in coordinator's shift was seeded to end 25 minutes after load so the demo would reach the handover prompt. The prompt fires inside thirty minutes — so it was on from the first render of every run she held, and the product's normal state was never once visible. A warning that is always showing is not a warning.
the design audit's density pass
One cell was setting the height of every row. The progress legend wrapped to a second line whenever a run had a fourth status, so rows measured 62 / 48 / 48 — and it printed zero counts, which is what forced the wrap. Two columns went with it: “Centers” restated a figure the legend beside it already summed, and “Donor status” read Out to centers on every row, because a run only exists once a donor is distributed.
08Where it landed
Shipped
The live build. A whole placement — donor, alert, run, patients, assignment, dispatch, arrival — walks end to end across both roles, with the clock running.
What I'd defend
The numbers are derived, never stored twice, so they cannot disagree with each other. The assignment screen makes the constraint the layout instead of a validation. And the honesty rules: no fake registry, no fake proof of handover.
Not done
It has never met a user. Nobody has watched a coordinator use it under a running clock, and the prototype feedback from the original project came second-hand. The 3am path is undesigned: the offer that expires while you're on another call, the centre that accepts then withdraws, two coordinators editing one donor.
First test
A coordinator placing a kidney while the clock runs, watching for the moment the order of the form stops matching the order information arrives in.
One constraint sits under all of it: the user turns over every three years. Coordinator attrition runs 17–28% annually and mean tenure is under three [24], so expertise never accumulates, and nothing here can rely on a practised user.
This is a coherent, well-argued design that has never met a user. For a portfolio piece that may be exactly right. For a product it is step one of three.
09Sources
- 1Does a changing donor pool explain the recent rise in the United States kidney nonuse rate? — American Journal of Transplantation
- 2Out-of-sequence placement of deceased donor kidneys is exacerbating inequities in the United States — medRxiv
- 3Deceased donor kidneys allocated out of sequence by organ procurement organizations — American Journal of Transplantation
- 4Changes in Deceased Donor Kidney Recovery and Transplantation following Increased Regulatory Oversight of Allocation Out of Sequence — PMC
- 5Cold ischemia time exceeding 12 hours is a risk factor for delayed graft function and increased mortality — Transplant International
- 6Cold Ischemia Time, Kidney Donor Profile Index, and Kidney Transplant Outcomes: A Cohort Study — Kidney Medicine
- 19Outcomes From Right Versus Left Deceased-Donor Kidney Transplants: A US National Cohort Study — PMC
- 24Improving the Recruitment and Retention of Organ Procurement Coordinators: A Survey Study — American Journal of Transplantation
- 29Calibration of Priority Points for Sensitization Status of Kidney Transplant Candidates in the United States — Clinical Journal of the American Society of Nephrology
Every clinical threshold in the build carries its citation in the code, so a reviewer can check it rather than trust it.