Most FHIR servers are incomplete.
By “incomplete” I mean they’re missing key features that allow them to be used with real patient and real clinical data.
It’s rare to see an application with direct access to a FHIR server outside of a student or research project. Not an “off-the-shelf” FHIR server at least.
What tends to happen is the technical team working with the FHIR server builds a layer of code that sits between the FHIR server and the outside world.
This goes by many names:
- Interceptor
- Wrapper
- Proxy
Or more commonly, a made up name unique to the organization.
What’s the purpose of this wrapper layer? Why is it needed?
It allows requests to be intercepted before they reach the FHIR server and responses to be intercepted before they reach the consumer.
Here are some examples of what happens inside these “wrapper” layers. These are taken from real-world projects I’ve been involved in.
Incoming requests:
- Apply custom business validation
- Make changes to the data before it reaches the server
- Build custom operations
- Channel requests to different FHIR servers
- Access cached queries
Outgoing responses:
- Apply attribute based access control (ABAC)
- Anonymize FHIR resources dynamically
- Change a resource’s elements or add new elements
- Cache a query result
- Trigger custom events or notifications
None of this extra functionality is in the FHIR spec, nor should it be. But real-world projects often require it.
A small number of commercial FHIR servers support their own version of “Interceptors” but most do not, making it necessary for your technical team to build it themselves.
This is not a trivial undertaking.
If you’re starting a new project with a FHIR server at the center, expect to build a “wrapper” like this at some point.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.