SRTR Interactive Reports
Interactive reports over a federal transplant registry's analysis output, built for patients and clinicians.
The situation
The Scientific Registry of Transplant Recipients publishes data for every transplant program in the country. Waitlist mortality, transplant rates, organ acceptance, survival after transplant in order to deliver key metrics to people in the field.
The analysis is careful work done by statisticians who know exactly what the numbers mean and exactly how far they can be pushed.
The results reached their audience as static documents in the past. The next move was to take the existing data and along side PDF documents, to publish this information in informative and interactive charts.
The hard part
Three things made this different from a normal data visualization project.
The application could not do statistics. The analysis lives in R and it is the authoritative version. A web application that recomputes anything, even something that looks as harmless as a rounded percentage or a re-derived confidence interval, creates the possibility of disagreeing with the published result. The application consumes what the analysis produces and renders it. It does not reinterpret it.
The combinations multiply fast. Every program, every organ, every metric, every cohort and every reporting period. The result is a very large number of views over a dataset that is regenerated on a cycle. Keeping it fast is a data modeling problem before it is a front end problem.
What I built
Interactive reports that open on a specific program and answers questions without making the reader hunt for the data.
Filtering by organ and metric. Charts rendered with HighCharts over the analysis output. Geography handled with Mapbox to make it easy for patients to find which programs are close enough to them. Comparison across programs so the numbers have context.
Every view has its own URL to allow anyone can send a patient or doctor a link to exactly the view they were just discussing instead of a set of instructions for reproducing it.
What changed
The reports went from documents you read to a tool you use. The audience that had the most trouble with the old format is the audience the new one is built for.
The annual cycle
New data lands on a schedule. That single fact changes what this kind of project is worth building.
If republishing means rebuilding, every cycle costs about the same as the last one. If the pipeline is built so a new cycle is a data operation rather than a development effort, each release costs less than the one before it.
That is worth deciding at the start rather than on the second release.
Stack
Related work on the same data: the organ procurement organization reports, the liver waiting list outcomes calculator and Transplant Center Search.
Publishing research data?
Registries, annual data reports and outcomes studies often reach their audience as static documents. I build the interactive layer over them.
Start a conversation →More on health and research data platforms.