FHIR Is Not a Modern Interface — It Is an Architectural Decision
Why “we need a FHIR API too” rarely means progress — and what separates the architectural decision from the format decision.
Many interoperability projects begin with a single sentence: “We need a FHIR API too.” It sounds like progress. Usually it is not.
What happens next
The usual sequence is well rehearsed. HL7 v2 is transformed into FHIR, a REST layer is placed in front of the legacy system, profiling is done per project — exactly as far as the current use case demands. The terminology question is deferred.
Technically there is little to fault. The mappings work, the conformance tests pass, the API delivers. And strategically nothing changes all the same. Introducing FHIR as just another exchange format does not modernise a hospital — it adds one more interface.
The flawed assumption
The mistake is already in the opening question. “Do we need a FHIR API?” treats FHIR as a format. An interface connects two systems. An architecture defines the common basis on which all systems speak about the same data. The former is a project with a beginning and an end. The latter is a commitment against which future decisions must be measured.
What the decision means
Taking FHIR seriously as an architecture means not building the next point-to-point connection, but establishing a canonical data layer that all connecting systems refer to:
- A shared, canonical data basis instead of island solutions retrofitted project by project.
- Standardised semantics, defined bindingly — not buried implicitly in each individual mapping.
- Event-based, so that changes to the patient context propagate rather than disappearing into batch exports.
- Vendor-independent, so that data sovereignty stays with the institution, not the supplier.
- A foundation for an app and AI ecosystem that only becomes viable once the underlying basis is stable.
Only once this foundation is in place does integration become a technical detail. Before that, every new connection remains the next layer of complexity over an unresolved basis.
The 60 percent no one talks about
FHIR projects are sold as technology projects. In practice they are so by at most 40 percent. The remaining 60 percent are organisation and architecture: who owns the data model? Who decides on profiles? Who maintains the terminology — and who is allowed to change it?
These questions cannot be answered by a cleaner API. They are organisational, and they need names, not roles. As long as they remain open, even the technically best FHIR project produces only formal conformance — and formal conformance is not the same as semantic interpretability.
What it comes down to
FHIR makes semantic differences visible. It does not resolve them. The question is not whether an institution has a FHIR API. The question is whether FHIR is part of its target architecture — or merely another format in the collection.
We support hospitals and their IT in exactly this architectural work — profile governance, terminology binding, and the formal description of what the exchanged data actually are. If you want to think of FHIR as a target architecture rather than an exchange format: get in touch.
The formal foundation of this work — the AION model and the CAIRN reference implementation — is documented at aion-clinical.eu.