Federate, don't centralize: why clinical data should stay where it originates
Centralizing medical records in a single repository looks simple until the first audit. FHIR federation offers another path: query the data where it lives.
For two decades, the standard answer to fragmented health data was the same: build a central repository and copy everything into it. It is an intuitive idea. It is also the reason so many national health record projects stall in phase two.
The hidden cost of copying
Every copy of a clinical record is a new risk surface, a new legal agreement and a new place where information goes stale. When a hospital corrects a diagnosis, the central copy never finds out.
The most trustworthy data is the data that never left the place where it was created.
What federation changes
In a federated model, each institution keeps its own system and exposes its data through a standard interface. A query layer — in our case, Acordia — resolves the question in real time and returns a consolidated result.
- The hospital remains the owner and custodian of its records.
- Queries are audited at the source.
- There is no central repository to protect.
A concrete example
To get the allergies of a patient treated at three institutions, the broker sends a FHIR query to each node:
GET /AllergyIntolerance?patient=Patient/8841&clinical-status=activeThe responses are combined, deduplicated and delivered to the clinician in seconds. No record is persisted outside its source.
What it does not solve
Federation does not remove the need to standardize. If a node does not speak FHIR, it has to be translated first. That is the job of Harmony, and the topic of our next article.
