Federating a Nation's Health Record: Why the Whiteboard Design Keeps Losing

The first two posts in this series were about one agency's health record: the requirements worksheet and the interface matrix.

This one asks what changes when the same problems are posed across 340 million people — and the honest answer is that almost nothing changes conceptually, while everything changes about which architectures survive.

The two designs, stated fairly

Centralized. One national data store. Every encounter writes to it; every query reads from it. Identity is a primary key. Consistency is a transaction. Reporting is a query against one schema.

Federated. Data stays in the systems that produce it. A national layer provides identity resolution, an addressing directory, and an exchange protocol. A query fans out, gathers, and assembles a view at read time.

The centralized design is enormously more attractive on a whiteboard, and it is the one that has failed everywhere it has been attempted at national scale.

England's National Programme for IT was the purest attempt: a national care record, contracted top-down to a handful of suppliers, dismantled in 2011 after costs approached £12.7 billion against roughly £2.6 billion in realized benefits. The design was not defeated by technology. It was defeated by the fact that every existing system in the country had to be migrated *into* it before any of it worked, so value arrived only at the end — and nothing in a democracy is funded that long without visible progress.

Denmark's national portal did the opposite and is the reference implementation worth studying: it presents a unified clinical picture assembled from more than 120 different sources, without storing or duplicating the data centrally. Estonia's X-Road achieves comparable results with an interoperability rate independent rankings put at 99.1%.

Both are federations with a strong identity spine. Neither required a national migration event.

The property that actually matters: incremental value

The engineering argument for federation isn't elegance. It's the shape of the value curve.

Centralized:   value ────────────────────────────┐
                                                 │  (arrives at cutover)
               ──────────────────────────────────┘

Federated:     value      ┌──┐  ┌──┐  ┌──┐  ┌──┐
                       ┌──┘  └──┘  └──┘  └──┘     (arrives per source connected)
                    ───┘

A federation delivers usable capability the moment the second source connects, and every source after that is additive. A centralized migration delivers nothing until it delivers everything.

That distinction is technical, but its consequence is political, and the two cannot be separated in public sector work. A program whose benefits arrive only at the end is a program betting that four consecutive administrations will keep funding an invisible thing. That bet has an unbroken losing record. A federation can lose its funding in year six and the five years of connected sources keep working.

Architecture that assumes institutional continuity is architecture that assumes away the defining feature of a republic.

The identity spine, and the one the US refuses to build

Every federation needs a way to know that the person in system A is the person in system B.

Denmark has a civil registration number. Estonia has a national identity infrastructure. Both make linkage *deterministic* — the join is exact, and the correctness question is closed.

The United States has legally prohibited itself from having one. HIPAA called for a unique patient identifier in 1996; since fiscal 1999 an appropriations rider has barred HHS from spending money to adopt one, renewed annually for more than a quarter century, repeatedly stripped by the House and repeatedly reinserted.

So American federation must resolve identity probabilistically, forever. Engineering consequences, in order of how much they'll cost you:

Matching is a service, not a library. If every participant matches independently, they will disagree, and the disagreements are invisible until someone gets the wrong record. National-scale federation needs matching as a governed shared service with a published algorithm, published thresholds, and a measured error rate.

Both error directions have to be measured, separately. A false match merges two humans — the clinically catastrophic direction. A false non-match splits one human across two records — the expensive-and-common direction. A single "accuracy" number that averages them is useless, because the tolerable rate for each is different by orders of magnitude.

The middle band needs staff. Every threshold produces an ambiguous zone. That zone is not an algorithm problem; it's a staffed queue with a service level. Programs that skip it don't eliminate the ambiguity — they resolve it silently in whichever direction the default happens to point.

Merges must be reversible and audited. At national volume, erroneous merges are a certainty, not a risk. An unmergeable merge is data loss wearing the costume of data quality.

What the US actually built instead

Absent an identifier, the country built a trust and exchange framework, and it is worth understanding on its own terms because it is the closest thing to a national architecture that exists.

TEFCA — the Trusted Exchange Framework and Common Agreement — defines a network-of-networks. Designated QHINs (Qualified Health Information Networks) act as exchange hubs; participants connect to a QHIN rather than to each other. Designated QHINs now include eHealth Exchange, Health Gorilla, Epic Nexus, MedAllies, KONZA, and CommonWell.

Two things make this more than a standards document:

Information blocking has teeth. The practice of knowingly interfering with lawful access to electronic health information carries real consequences, which changes the negotiating posture of a party that would prefer not to share.

USCDI sets a floor. The United States Core Data for Interoperability defines a required baseline data set, and as of January 1, 2026, data created or captured and sent must conform to USCDI v3 classes, elements, and vocabulary. A floor is exactly what a federation needs: it makes the assembled view predictable without requiring anyone to migrate.

Notice the shape. This is Denmark's architecture reached by a different route — a layer over existing systems, no national data store, value with each connection — but with probabilistic identity instead of deterministic, and with contractual trust instead of a single national operator.

Segmentation: the requirement that breaks naive federation

Here is where a national design gets genuinely hard, and where most architecture diagrams quietly cheat.

Not all health data may flow under the same rules. Substance use disorder records from federally-assisted programs fall under 42 CFR Part 2, materially stricter than HIPAA and requiring that the protected subset be separable, tagged, and governed by its own consent. Recent rulemaking simplified consent — a single consent can now cover future treatment, payment, and operations uses — but the underlying obligation remains.

The engineering demand is *data segmentation for privacy*: the ability to tag a subset of a record, carry the tag across an exchange boundary, and have the receiver honor it — including on redisclosure.

And the state of the art is not good. Most health records and exchanges do not meaningfully support segmentation, which produces a bad binary: over-disclose, or opt the program out of integrated care entirely. Neither serves the patient.

For a federation, this is the design constraint that should drive the model, because it settles the centralized-versus-federated argument on privacy grounds rather than engineering ones:

• In a centralized store, segmentation is an access-control problem over data you already hold. Once assembled, the protected data is *there*, and the only thing standing between it and a future policy change is a permission check. The record built to coordinate care is one administrative decision away from being the record that enforces.
• In a federation, the protected data never leaves its source unless a consent evaluation permits it. The default is non-disclosure by *topology*, not by policy — which is a materially stronger guarantee, because it survives a change in who's running the permission system.

That is the strongest technical argument for federation, and it's an argument about power rather than performance. A federated design is harder to query and harder to abuse. Those are the same property.

Local and national are the same problems at different constants

The through-line of this series is that the county problem and the national problem are structurally identical:

| Concern | County scale | National scale |

|---|---|---|

| Identity | Master patient index, one agency | Governed matching service, no national identifier |

| Interfaces | ~10 systems, versions from 2008 | Thousands of participants, versions from everywhere |

| Consent | Part 2 segmentation in one record | Segmentation across trust boundaries |

| Money | GL, payroll, AP, state MIS | Claims, eligibility, 50 state variants |

| Adoption | Superusers per shift | Same, times ten thousand |

| Exit | Data portability clause | Standards conformance as the exit |

What changes with scale is not the list. It's that at national scale you cannot fix anything by having someone walk down the hall, so every informal process must become an explicit protocol with an owner and a service level. The county agency that resolves ambiguous patient matches by asking the front desk clerk who remembers the family has a working process that does not survive a single order of magnitude.

This is why national programs that begin by designing the national layer fail, and ones that begin by connecting two real systems succeed. The second approach discovers the informal processes while they're still cheap to formalize.

If I were specifying it

1. Federate. Don't migrate. No national data store. The layer provides identity, directory, and exchange.
2. Fund the identity spine first and separately, and publish its error rates in both directions. Everything else is downstream of it, and pretending probabilistic matching is solved is the single most common national-scale lie.
3. Set a data floor, not a data ceiling. A required baseline every participant must expose, with local extension permitted. Uniformity beyond the floor is how you get an unwinnable migration.
4. Make segmentation a first-class requirement from day one, not a later phase. Retrofitting consent into an exchange that already flows is not a project; it's a rebuild.
5. Require a working exit. Every participant can extract its own data in a documented standard format. Exit rights are what keep a federation a federation instead of a monopoly with extra steps.
6. Connect two real systems before designing the national one. Whatever you learn in that pair, you would otherwise have learned in year seven at a thousand times the cost.

None of this requires new technology. It requires refusing the whiteboard-attractive design and accepting that the boring, federated, incrementally-valuable version is the only one with a track record of surviving the political clock it has to run on.

---

Earlier in this series: The 800-Line Requirements Worksheet · The Interface List Is the Project.

The policy argument: The National Health Record a Republic Can Actually Build and How You'd Actually Deliver It.