No FHIR server is “Production Ready”
Managed FHIR servers in the cloud are winning the server race.
Microsoft Azure, AWS and Google Cloud dominate over the smaller providers in the space. For a company building a new solution that uses FHIR choosing a server from one of the big three is almost a default action.
They provide:
- Integration with a company’s existing cloud infrastructure
- Pay as you go offerings
- Synchronization with data warehouses
- Simple to get started (no sales call)
- HIPAA compliant (they say)
I’m not here to argue the pros and cons of managed servers — I’ve done that before. But I will say that no FHIR server is “production ready”.
A commercial, off-the-shelf FHIR server is a starting point. To make it production ready and capable of receiving and delivering patient and clinical data, you have to build around it and on top of it.
You have to write a lot of code.
The biggest surprise for new teams working with a FHIR server is how much they have to do themselves. They’re sold what appears to be a polished solution, then they find themselves facing a year’s development that can easily stretch into two or more years.
The starting point is when they realize they need to build a proxy of some kind in front of the server they just bought. Much of what a professional FHIR server needs is simply not there by default:
- Extra business validation
- Custom operations that need to be built
- Attribute level access control
- Applying security labels to incoming data
- Actioning security labels for data flowing out
- Restricting access to specific FHIR resource types
- Writing to audit tables
- Implementing Smart-on-FHIR
- Automated resource change notifications
- Tagging and managing AI data
If you’re in the early stages of a FHIR project and you’re only now realizing the work load ahead of you, you have my sympathies. There is no quick solution here, no “magic” server provider that can give you all of this out-of-the-box.
To get you started, I recommend you look at the open source “Azure Health Data Services Toolkit” provided and maintained by Microsoft. It gives you a shell and foundation on which you can build the advanced proxy I just mentioned.
The toolkit: https://github.com/microsoft/azure-health-data-services-toolkit
The very fact that Microsoft have invested so much time in this open source application is an admission on their part that you have a long development path ahead of you.
Though I single out the big three cloud providers, no FHIR server provider gives you everything or even close to everything you need.
‘Closed’ versus ‘open’ FHIR profiles
The prevailing opinion in the FHIR community is that ‘open’ models are preferred. A FHIR server should be liberal in what it accepts. This is the ideal and you’ll find no dissenting voices amongst the FHIR evangelists on the chat forum.
FHIR profiles can restrict certain elements, alter the cardinality of others or bind them to specific ValueSets. But they should not prevent elements from being populated — even if the data model in its current form has no use for those elements.
I agree. Where possible, this ideal should be upheld.
But it’s not always possible. Sometimes restrictive data models are required — even for FHIR data. A product or solution may involve data flowing into a FHIR server from many different countries, each with their own regulations governing how patient data is managed and stored.
Legal and compliance teams can have strong opinions on what data should and should not be stored. It’s seldom a developer’s job to make these decisions.
A couple of weeks ago I spent some time trying to construct a patient profile that restricts what data can be sent in the Patient resource. I was particularly interested in how to block unwanted extensions. It was an academic exercise on my part, but one driven by questions I’d had from more than one company I work with.
I managed to construct such a profile but it wasn’t easy and involved some manual editing of the StructureDefinition file for the profile. I successfully tested it on an Azure FHIR server.
This is not something that you’ll find discussed or approved of on the FHIR chat forum, but that doesn’t mean there are not real-world use cases for such profiles.
You can read about how I built the profile here: https://darrendevitt.com/negative-fhir-profiles/
Resource truncation issue on Azure
A common limitation of managed FHIR servers is how they restrict the number of “included” resources returned in a FHIR query.
Users are often unaware of this until they hit the problem in code, encountering an OperationOutcome in the returned Bundle telling them their results were truncated.
Most FHIR server providers truncate “included” results in some way, and Microsoft Azure is no exception. But they’re working on changing that, as outlined in a recent email I received.
By the end of this month Azure will be raising the number of included resources returned in a search query from 100 to 1,000. This will affect the “_include” and “_revinclude” parameters. Even better, they’re working on a larger solution to implement pagination for “included” resources with a view to removing the limitation entirely.
Microsoft is the most popular managed FHIR server by far, and this change will have a positive impact on many large scale FHIR projects around the world.
---