Choosing a FHIR server provider happens early in a project.
The decision is often made without asking key questions.
If you don’t factor in the unique requirements of your project when making the decision, chances are it’s the wrong decision and you’ll pay the price down the road.
How do you make the decision?
There is no checklist for what makes the “best” FHIR server.
Most managed or “off-the-shelf” servers implement 99% of the FHIR API.
A query that runs on AWS will run on Firely. A Bundle that loads into Aidbox will load into Google or HAPI.
So how do you compare FHIR servers in a way that leads to a decision you won’t regret?
You start by building your own checklist.
You should focus on how a server meets the key business and technical requirements of your project and on what’s required to get that project into a live production environment.
But don’t stop there, look 5 years into the future.
Switching server providers after you release to production is almost unheard of. The choice you make early in the project is one you’ll be stuck with for years.
Here’s a sample checklist — yours should be different:
- Will the pricing model work long term?
- Our project requires FHIR Subscriptions, does the server support them?
- If not, is there a workaround that external consumers can use?
- How difficult is it to implement Smart-on-FHIR?
- What about element level access control for year 2?
- How can we build in multi-tenancy?
- The project will require analytical queries. How is that supported?
- How difficult is it to customize the server with new operations?
- Will the server provider be around in 5 years?
- Where is the data stored? Will that work for the countries we’re selling to?
I can’t stress enough how important this early decision is.
It defines and dictates so much of the work your development teams will have to do.
It directly impacts your release timelines. It directly impacts the product you deliver.
Do not trivialize this decision.
Do not make it for the wrong reasons.
---