HL7 FHIR is not the architecture

Every so often the same infographic goes around again: two hospitals on the sides, an integration bus in the middle, a few arrows going back and forth and, on top of it all, the HL7 FHIR logo as a seal of guarantee. The implicit message is simple: install this and your systems will interoperate.

I have taken part in national and regional FHIR implementation guides. That is exactly why I can say it plainly: that infographic does not describe an interoperability architecture. At best, it describes a pipe.

Comparison between false simplicity and the reality of interoperability. At the top, two hospitals connected by arrows to a FHIR server in the middle. Below, the reality: an exchange process surrounded by patient identity, organization identification, security, documents, clinical files and databases.

Let's put it to the test with an everyday case. A 67-year-old woman with heart failure, treated for years at a private hospital, arrives at the emergency department of a public hospital at two in the morning. The doctor on duty needs her clinical summary: diagnoses, medications, allergies. They have five minutes.

At the private hospital she is registered under her national ID number. At the public one, under a file number and with her second surname misspelled. Who decides they are the same person? Nobody at the public hospital knows a summary exists at the private one, or which service it is available from.

When the query arrives, the private hospital will need to know who is making it, whether they are a licensed professional, from which organization and for what purpose. It will need to know whether she authorized sharing her information and who evaluates that authorization. Her furosemide will have to mean the same thing in both systems. And tomorrow someone will have to be able to show who saw what, when and why.

The infographic's arrows answer none of those questions. And none of them is solved by choosing the right FHIR resource.

What FHIR is

We should be precise, because the easy criticism is smoke too. FHIR is not "just syntax". It defines resources with clinical semantics, REST interactions, messaging and documents. It also defines conformance mechanisms, links to terminologies and even resources for consent, provenance and audit. It is probably the most important advance in health standards of the last two decades.

But the specification itself is clear about its scope. In its profiling section, HL7 describes FHIR as a platform specification. It is a common base on which different solutions are built, and it normally has to be adapted to each context of use through profiles and implementation guides. In its security section, it warns that FHIR is not a security protocol and that it depends on mechanisms defined elsewhere.

That distinction has practical consequences:

FHIR defines the Consent resource, but it does not decide which consent policy applies in a country or implement the engine that enforces it.
It defines AuditEvent, but it does not guarantee that anyone audits, nor does it define how long the record is kept or who reviews it.
It defines Patient, but it does not decide which identifier is the official one or how duplicates are resolved.

That is why saying a system "supports FHIR" says very little. Conformance is always against something: an implementation guide, a set of profiles, a version, a CapabilityStatement. Claiming that a system is interoperable because it "speaks FHIR" is like claiming that a contract is valid because it is written in English.

What the drawing does not answer

Back to the emergency department. Each question in the case corresponds to a capability that someone has to design, operate and govern.

Seven capabilities that interoperability requires around clinical data: patient identity (MPI), organizations and professionals, consent, clinical document and data exchange, cybersecurity and authorization, terminology, and audit and traceability.

Identity. Before asking for any data, both hospitals need to know they are talking about the same person. That requires a master patient index and matching rules. It also requires a policy on which identifier prevails and a procedure for when the algorithm gets it wrong.

Discovery. The public hospital needs to know which organizations participate, which professionals work in them and where their services are. That is a directory, with rules about who maintains it and how it is updated.

Exchange. The summary has to be published, found and retrieved. Here FHIR does the heavy lifting, but within a contract that says exactly who sends what to whom.

Content. A document that arrives is useless if it is not understood. The summary needs an agreed structure, such as the International Patient Summary and a national guide that adapts it. It also needs linked terminologies: SNOMED CT, LOINC, a medication catalog. This is the most "FHIR" part of the problem and still it requires governance: who maintains the value sets, which terminology is official, who pays for the licenses.

Access and consent. The private hospital has to verify who is asking, with what right and whether the patient authorized sharing. Profiles make that policy executable, but none of them writes it.

Traceability. Every access must be recorded in a verifiable way. For an audit to have value, all systems must agree on the time. Even the clock has to be governed.

IHE has specified each of these capabilities as profiles with concrete actors and transactions:

IHE as a layer of integration profiles (actors, transactions and contracts) on top of FHIR, connecting hospitals, clinics and laboratories.

Question in the case	Capability	IHE profile / HL7 guide
Is it the same person?	Identity	PIXm, PDQm; PMIR to manage it across the community
Who is who and where is the service?	Directory	mCSD
Where is the summary and how do I get it?	Document exchange	MHD (ITI-65, ITI-67, ITI-68)
Does the content mean the same thing?	Content and terminology	IPS + national guide; SVCM
Who is asking and with what right?	Authorization	IUA (OAuth 2.0); SMART App Launch
Did the patient authorize it?	Consent	PCF
Is there a verifiable trail?	Audit	ATNA, BALP
Do the clocks agree?	Consistent time	CT

One fact sums up the argument better than any opinion. IHE published MHDS, a profile whose purpose is to describe the minimum services of a FHIR-based document sharing community. MHDS does not invent a new standard: it groups MHD with identity, directory, audit and consistent time, among others. If a FHIR server were enough to exchange documents between institutions, that profile would have no reason to exist.

Not all of these profiles are mandatory in every project. What they show is that each capability has actors, transactions and responsibilities that do not appear just by installing a server.

Not even IHE is the architecture

It would be easy to turn this article into "FHIR versus IHE", but that would be another oversimplification. IHE profiles are reusable integration contracts, and many are built on FHIR. What a contract does not decide are the questions that come before:

Will the patient index be central or federated, and who operates it?
On what legal basis is information shared without consent in an emergency?
Which organization certifies the participants?
Who is accountable when a piece of data is wrong?

The frameworks that work best in the world start precisely there. OpenHIE builds its architecture from workflows. It assigns them to shared components and then maps them to IHE profiles. Those components include the client, facility and health worker registries, terminology, the shared health record and the interoperability layer.

The WHO SMART Guidelines place the Digital Adaptation Kits in a layer before the FHIR guide. Those kits contain personas, business processes, a data dictionary and decision logic. First the process; then the standard.

The United States offers the most telling example. It is the country that made FHIR APIs mandatory by regulation in certified health technology. Even so, to interoperate at national scale it needed TEFCA. TEFCA combines a trust framework, a common agreement signed by participants and designated networks (QHINs) with explicit obligations. Exchange between those networks relies largely on IHE profiles. The country with the most FHIR deployed in the world did not solve interoperability with FHIR alone: it solved it with governance.

The Refined eHealth European Interoperability Framework (ReEIF) expresses it in six layers: legal and regulatory, policy, care process, information, applications and infrastructure. FHIR occupies, at most, two of them. The other four are not bought; they are designed and agreed.

The cost of the shortcut

Confusing a platform with an architecture is not a theoretical error. It has costs that appear two or three years after the purchase, when they are already expensive to fix.

Vendor lock-in. A FHIR server with no national implementation guide fills up with proprietary extensions. The data stays in FHIR, but in a FHIR that only that product understands.

Point-to-point integrations in disguise. A bus that connects each institution with its own transformation rules does not remove the complexity: it hides it. Every new participant is a new project, and the solution cannot be reproduced in another region or with another vendor.

Security added at the end. When authorization, consent and audit were not designed from the start, they are added as patches, or simply not added. The risk falls on institutions and patients, not on whoever sold the platform.

The central repository that copies everything. Without identity, a directory or document location, the fastest way out is usually to centralize copies of everyone's data. It works in the demo and complicates everything else: responsibility for the data, synchronization, privacy and the trust of the institutions that must hand over their information.

Nothing can be verified. This is perhaps the most serious cost. Without declared profiles or conformance testing, nobody can show that two systems interoperate correctly. All that is left is trusting the presentation.

Before you buy, ask

A solution can be fully compatible with HL7 FHIR and still be insufficient for the case it was acquired for. That is why institutions should evaluate proposals by the capabilities they demonstrate, not by the list of technologies they mention. These questions help tell an architecture from a presentation:

Which implementation guides and profiles does it declare conformance to, and in which FHIR version? "We support FHIR" is not an answer.
Does it publish its CapabilityStatement?
Which IHE actors does it implement and which transactions does each support?
What testing evidence does it have: Connectathon, Gazelle, Inferno, national guide validators?
How is patient identity resolved and who governs the master index?
Where is consent evaluated and where is the audit recorded?
Which proprietary extensions does it use and how is the data exported if you change vendors?

If the answers are vague, the problem is not technical. There is no architecture behind it.

Architecture first, technology second

The patient in the emergency department does not need a FHIR server. She needs her doctor to see, in five minutes, the right information about the right person. She needs that to happen with her authorization or the legal basis that replaces it, and to leave a record. Achieving that requires deciding processes, roles, responsibilities, shared services and rules of trust. FHIR is indispensable for that, but it is not enough.

Institutions that start with the process end up choosing technology better. Those that start with the technology tend to discover the process after they have signed the contract.

FHIR gives us a common language to exchange health information. Architecture determines who can use it, for what, under which conditions and how that exchange becomes an interoperable health process. Let's not confuse speaking the same language with knowing how to work together.

References

←Blog