Comparing FHIR servers
A few weeks ago I began work on a project that I expect will take me to the end of 2025 — comparing FHIR servers. One of the first decisions businesses face when they start using FHIR is which server provider to go with — that’s assuming they don’t decide to “roll their own” or build a façade on top of an existing data source.
There are many layers to this decision, but I started at a very basic level — comparing how 8 FHIR servers behaved when faced with some common search queries. To do this I populated the servers with test data and ran a small set of queries against the Observation resource.
My query can be summarized as variations of:
Give me Observations where the patient’s body weight is above 80kg.
These are the servers I tested — a combination of big name providers and small startups:
- Microsoft Azure
- AWS Healthlake
- Google Cloud
- Firely
- HAPI
- Medplum
- Aidbox
- Oystehr
The results were surprising. Only two server providers successfully ran all five queries on the first attempt. Once I published the results, two other providers (Medplum and Oystehr) immediately introduced improvements that addressed some of their previous failures.
I see some lessons here. The first is that there is great diversity in which search parameters different FHIR servers support, even commonly used search parameters such as those that reference Observation quantity. Secondly, the response time of the smaller server providers in fixing issues or introducing changes far surpasses the larger providers.
There’s a big difference between a one day turnaround and a one year turnaround when it comes to bug fixing or feature introduction. This is not insignificant when you consider how critical FHIR server downtime can be.
The state of FHIR around the world in 2024
Every year HL7 and Firely send out a survey to affiliates and organizations around the world with a number of questions on FHIR use in their country. The results of the 2024 survey have been out for 6 months but I seem to have missed them when they were released. It makes for interesting reading.
My key takeaway was how many countries around the world either mandate FHIR use in regulations or mention FHIR use — 20 in total. When I posted the survey on LinkedIn a number of people commented to highlight regulations that existed in their own country that did not appear in the survey results. These included Israel, Spain and a number of African countries.
A second takeaway for me was that “EHR vendors” and “App developers” were the two categories that dominated FHIR adoption. It always surprises me how little attention is given publicly to FHIR usage in private enterprise. “App developers” are choosing FHIR as their primary data sharing mechanism even when it’s not mandated by regulation.
These same developers rarely appear in the FHIR chat forum, at the connectathons or at FHIR DevDays, but their importance to the FHIR ecosystem should not be understated, as in many cases they are pushing the boundaries of what can be done with FHIR.
An example of a real-world Implementation Guide
I was browsing through the public Implementation Guides on Simplifier a couple of months ago and came across a guide from the NHS in the UK that struck me as well structured and well maintained.
The NHS Digital FHIR Medicines IG is broken down into “FHIR assets” and “Design” sections that together document the FHIR profiles, ValueSets, extensions and operations used as well as providing the business context and data flows.
I’m always looking for good examples of IGs as documentation is a big factor in how quickly and effectively different consuming applications work with an Implementation Guide, and it’s something that a lot of guides lack. Simplifier.net is a great resource for this as many of these IGs are published on the platform, although finding them can be difficult.
Implementing Consent Management in FHIR
I’ve referenced Mohammad Jafari’s work on consent management in FHIR before. In a recent post he summarizes some of the most important consent management use cases and what should be documented in an Implementation Guide that covers them.
- Initiating consent capture
- Reviewing consent
- Signing and executing consent
- Reviewing existing consent
- Revoking consent
- Auditing
The complexities involved in consent management are many but the use cases are common. If you get to the point in your project where you’re trying to manage patient consent in FHIR you should read Mohammad‘s posts and look at the FHIR Consent Management Implementation Guide (IG) Project. There’s some great work being done here that benefits the whole community.
The article.
The Implementation Guide.
Vanya website & Testimonials
A couple of weeks ago we launched a new website for the Vanya FHIR Viewer. This came after the latest release which finished the first version of the search query functionality. Response from users has been positive, with many leaving testimonials on the website.
There’s a short video on the home page where I show you how to run 5 different queries in Vanya — each one tracking a single Patient through various Encounters where Observations were made.
The part of Vanya that I’m most proud of is the hierarchical view that displays included resources. From day one I saw this as a requirement — something that was missing from tools like Postman but that would make the lives of developers so much easier.
The new website expands the documentation and includes specific pages on:
- Running search queries
- Viewing OperationOutcomes
- Understanding conformance errors
- PHI and PII data handling in Vanya
- Connecting to your FHIR server
Vanya website and download: https://vanyalabs.com/
---