“We can always switch to a different FHIR server later.”
I’ve heard this so many times in the early stages of FHIR projects.
Technically it’s true but practically it’s not.
Mature FHIR projects prove how wrong it is.
Every real-world FHIR implementation depends on things that are outside the FHIR standard:
- Element level access control (ABAC)
- Custom resource types
- FHIR query interceptors
- Custom operations
- Multi-tenancy
Many of these are unavoidable, yet each vendor implements them differently.
Take custom operations for example.
- One vendor treats them as C# plug-ins
- Another as “bots” your devs write in JavaScript
- Another recommends you build a proxy and add a custom endpoint
All of these are valid but none of them are portable.
Vendor lock-in does not live in the data, it lives in the surrounding architecture.
You can migrate FHIR data relatively easily but you can’t migrate a FHIR implementation without wholesale redesign.
The more mature the FHIR project the more common these non-standard features become.
Some will argue that this is no different to any other platform lock-in. That any system built on a proprietary platform using proprietary functionality is expensive to move.
But that misses what makes FHIR different.
These “extras” are not edge cases any more. They’re becoming requirements for heavy duty FHIR projects. That’s why vendors keep building them.
But they’re not part of the standard.
This begs the question:
If you can’t change FHIR server providers without redesigning your architecture, how open is the FHIR standard in practice?
---