- Research funding follows feasibility: conditions without data infrastructure look like bad bets to funders and to busy researchers alike.
- Most of what a disease registry costs — consent management, privacy engineering, audit, security, vocabulary mapping — is identical across diseases.
- Building that stack once and sharing it drops the marginal cost of adding a condition to roughly the cost of its disease-specific layer alone.
- Shared infrastructure also makes cross-condition and comorbidity research possible in a way siloed registries never could.
On this page
Every year the National Institutes of Health publishes how much it spends on each disease category — hundreds of lines, public for anyone to read on NIH RePORT. Some lines are long. Many are startlingly short, and not because the diseases on them are rare or mild.
Behind that table sits a second, invisible one that nobody publishes: which conditions have research infrastructure — a registry, a phenotyped cohort, a consent pipeline — and which have nothing. The two tables track each other closely, and the causality runs in both directions.
Funding follows infrastructure
Money flows toward studies that look feasible, and feasibility means data that already exists. A condition without infrastructure is not merely underfunded — it is structurally hard to write a fundable proposal about.
Picture a researcher choosing between two projects. Condition A has a registry: thousands of consented, characterized patients, outcomes tracked for years. Condition B has prevalence estimates and a Facebook group. The grant for A writes itself — preliminary data, power calculations, a recruitment plan that is mostly a database query. The grant for B must budget years and significant money just to assemble a cohort before science begins, which reviewers correctly read as risk. Rational researchers pick A. So do rational funders.
The trap is circular: no data means no grants, no grants means no data. Recruitment failure deepens it — a large share of the trials registered on ClinicalTrials.gov miss their enrollment timelines, a drag we examine in why most clinical trials miss enrollment deadlines, and conditions without findable cohorts fare worst. Breaking the loop does not require more advocacy for any single disease. It requires making infrastructure stop being a per-disease purchase.
What a registry actually costs
The expensive part of a disease registry is almost never the disease. It is the machinery underneath — and the machinery is nearly identical no matter what condition sits on top.
The Agency for Healthcare Research and Quality publishes a well-known user's guide for patient registries, and a glance at its table of contents is instructive: consent, governance, data standards, privacy, security, quality assurance. Chapter after chapter of requirements that have nothing to do with any particular diagnosis. Lay the full stack out and the pattern is hard to miss:
| Layer | What it involves | Disease-specific? |
|---|---|---|
| Consent management | Per-study authorization, revocation handling, versioned documents | No |
| Privacy engineering | De-identification, k-thresholds, release gating | No |
| Audit and compliance | Tamper-evident logs, retention rules, regulatory mapping | No |
| Data standards | FHIR storage, OMOP research views, vocabulary mapping | No |
| Research workflow | Ethics-approval gating, query review, researcher access | No |
| Clinical content | Phenotype definitions, validated symptom instruments | Yes |
| Community | Trust, recruitment, lived expertise | Yes |
Five of seven layers are pure plumbing. Under the per-disease model, every patient organization that wants a registry must fund, build, and maintain all seven — which is why so many registries are understaffed, why some run on spreadsheets, and why most conditions never get one at all.
The marginal-cost argument
Build the five generic layers once, at full engineering quality, and the cost of adding a condition collapses to the two layers that are genuinely its own: clinical content and community. That is the entire economic case, and it is decisive.
This is the standard infrastructure story — no town builds its own power plant — applied to a domain that has resisted it for decades. The deeper point is about quality, not just cost. Privacy engineering, consent management, and auditability are unforgiving disciplines; done per-disease on charity budgets, they are done thinly. A shared spine means the smallest, least-funded condition community gets the same consent machinery, the same release gates, and the same audit rigor as the largest — a level of engineering none of them could justify alone. We make the rent-don't-rebuild case in detail in patient registries: the quiet workhorses of chronic-disease research.
What sharing does not flatten
A shared spine is not a merged database, and it must not flatten what makes each condition itself. The disease-specific layers stay sovereign.
Phenotype definitions — the executable logic that decides who counts as having the condition, which we unpack in computable phenotypes — are written and validated per disease. Symptom instruments differ: a bladder-pain index measures nothing useful in epilepsy. And community trust is not transferable at all; it is earned per condition, usually over years. Consent enforces the separation structurally: on a per-study, scope-limited model, sharing infrastructure with 27 other conditions never means sharing data with them. The spine is common. The data, the definitions, and the decisions are not.
The cross-condition dividend
Here is what siloed registries can never do, even in principle: see across conditions. Chronic diseases travel in clusters, and overlapping symptom syndromes are well described in the literature — yet each siloed registry sees exactly one silhouette of a patient who may live with three conditions.
When 28 conditions share one data architecture — same record format, same vocabularies, same query machinery — comorbidity questions become askable within these registry communities: how often the conditions co-occur among consented participants, whether treatment responses differ in the overlap groups, what the registries had each been missing alone. On a federated, aggregate-only architecture, those questions get answered without any record leaving its region, a pattern we describe in federated analytics.
This is the wager Mithras Health has made: one spine, 28 chronic conditions across 12 categories, urology to oncology. Every condition — flagship or newly added — sits on the identical non-negotiable machinery: per-study revocable consent, the hard k ≥ 5 release floor, the append-only audit trail with six-year retention, FHIR R4 records with OMOP views for research. The flagship cohort, interstitial cystitis / bladder pain syndrome, exists precisely because IC spent decades as the canonical underfunded condition — the story we tell in why IC research has been so hard — and the blueprint built for it is what every subsequent condition inherits at near-zero marginal cost.
The short lines in the NIH spending table are usually read as a ranking of how much anyone cares. Read them instead as a map of where infrastructure never got built — because care, it turns out, was never the scarce input. Plumbing was. And plumbing, unlike care, only has to be built once.
Appendix · questions
Questions, answered
Why do some diseases get so little research funding?
What does disease research infrastructure actually include?
Why not build a separate registry for each condition?
What stays disease-specific on a shared platform?
The sun is rising on chronic-disease research.
One email when we launch — and nothing else. Patients, researchers, sponsors, and programs all start here.
Mithras