Over the past few weeks I’ve written three posts that explore a pattern I see repeatedly in FHIR projects.
Each one addresses a different issue but they all point to the same underlying problem.
We assume that if we “do FHIR,” interoperability, data quality and flexibility will naturally follow.
They don’t.
1. The Illusion of Interoperability
FHIR makes it straightforward to move data between systems. Resources are structured, APIs are consistent and server validation confirms whether something conforms to a profile.
But interoperability is not the same as data flow.
A resource can pass validation and still be incomplete, misleading or unusable. Two systems can exchange perfectly valid FHIR resources and still not understand each other.
Example: A five year old male patient, married and pregnant
True interoperability means the receiving system can safely and reliably use the data. Without this you may have structured data movement but you don’t have interoperability.
2. FHIR Validation Is Not Data Governance
Validation is important. It enforces structure, ensures required elements are present and confirms that terminology come from the expected value sets.
But validation answers only one question:
Does this resource conform to the standard and profile?
It does not answer:
- Is the data trustworthy?
- Is it clinically safe?
- Does it make sense in context?
- Should we allow this system to submit this type of data at all?
When teams rely on validation as a substitute for data governance, they create blind spots. Data governance requires clearly defined ownership, oversight, policies and auditability. It requires control over who can write what and under what circumstances.
FHIR does not provide this out of the box. It was never intended to.
Confusing validation with data governance is one of the most common architectural mistakes I see.
3. The Reality of FHIR Server Vendor Lock-In
FHIR R4 is the same regardless of server. This makes it easy to assume that FHIR servers are interchangeable.
To a degree they are. You can move millions of FHIR resources from one server to another. It’s challenging but certainly possible.
In practice, mature implementations rarely stay within “vanilla” FHIR. Over time, organizations adopt vendor-specific capabilities.
- Custom operations
- Built-in element level access control
- Multi-tenancy
- Query interceptors
- etc.
These become architectural dependencies.
Switching vendors then stops being a data migration exercise and becomes a redesign exercise.
Lock-in happens because of the vendor specific architectural decisions that build up around the server.
The Common Thread
All three issues share the same misunderstanding:
FHIR is a standard, not a strategy.
It defines structures and exchange patterns.
- It does not guarantee meaningful interoperability
- It does not replace data governance
- It does not protect you from architectural dependencies
Those outcomes depend on the decisions made by architects, technical leaders and project leaders.
If you are involved in a FHIR project, you need to have these discussions as early as possible.
Each post generated some lively discussion on LinkedIn and are well worth reading for the comments alone.
FHIR & The Illusion of Interoperability
FHIR Validation Is Not Data Governance
---