Why federated beats central for population-scale health data

The single biggest architectural mistake I see in national digital-health programmes is not a technology choice. It is the assumption that a central data warehouse is the natural end-state of a population-scale platform, and that a federated architecture is a compromise on the way to it.

The opposite is true. Federation is the destination. Centralisation is the compromise: the shortcut a first-generation programme takes because it does not yet know what it does not know.

Why the warehouse instinct returns

The warehouse is an appealing design because it makes the reporting problem easy. Every population-scale health programme has an appetite for reporting (for a minister, for a funder, for a public-health authority) and a warehouse pattern makes the reporting query trivial. Every architect who has ever fought with a distributed query recognises the temptation.

The temptation returns roughly once per generation. It returned in the 1990s as the enterprise data warehouse. It returned in the 2000s as the national health data spine. It is returning now as the health data lake and the AI-ready population dataset. The vocabulary changes. The design does not.

Why it does not survive

Three forces, in every jurisdiction I have worked in, defeat the central warehouse over time:

1. Sovereignty. In a federated state (Canada, Australia, India, the United States) the sub-national jurisdictions that own the clinical data will not, in the end, hand it to a central authority. They will insist on custody. The warehouse either does not get built or gets built as a shadow of the real record.
2. Consent. Patient consent, in most modern jurisdictions, is not a single decision. It varies by purpose, by data class, by recipient, and by time. A central warehouse is not a natural artefact for expressing that variability. A federated architecture, in which the data stays with the source and the source enforces consent locally, is.
3. Trust asymmetry. The clinicians and patients who generate the data trust their local institution more than they trust a national one. That trust asymmetry is not a bug to be overcome; it is a property of the health system, and any durable architecture has to respect it.

What federation actually looks like

The federated pattern that has held up over four decades is deceptively simple. It has four parts:

• Registries: small, authoritative indexes of people, providers, and facilities. Not clinical data; just identity.
• Repositories: the actual clinical data, kept by the institution that produced it.
• Locators: a service that, given a patient identity, returns the list of repositories that hold data about them.
• Viewers and agents: the read-side of the platform, which resolves a locator response into an actual clinical view or into a machine-consumable stream.

Every piece of this pattern is essentially a coordination pattern, not a storage pattern. That is the key. The federation is a coordination architecture that lets the clinical data stay where it belongs while still being reachable when it is needed.

The reporting problem, solved differently

The warehouse pattern solves reporting by co-locating the data. The federated pattern solves reporting by pushing the query to the data. The mature implementations of this (public-health surveillance grids, outbreak-response networks, quality-measurement programmes) send the query to the repositories, get back aggregated results, and combine them centrally.

This is more work, architecturally. It is also the only pattern that survives the sovereignty and consent constraints listed above. If you do the work now, you save yourself the two-generation cycle of building a warehouse, watching it fail, and rebuilding it as a federation.

The moment to make the choice

The choice between central and federated is usually made, implicitly, in the first three months of a programme. It is made by whoever writes the reference architecture, and it is made in a single paragraph. Once made, it is very hard to reverse. The federation-first jurisdictions I have worked with tend to have made that choice deliberately and to have written it into their principles document. The warehouse-first jurisdictions tend to have made it by default and to have inherited the assumption from whoever wrote their first strategy paper.

The lesson is straightforward: write the principles document, and put the federation choice in it, before anyone draws a diagram.

---

This essay is one of a series drawn from four decades of national digital-health architecture practice. The patterns described are anonymised generalisations from work with multiple jurisdictions.