A couple of years ago I worked on a project where the decision to use FHIR was made at the business level before any technical people got involved.
But once that decision was made, every subsequent decision to do with FHIR was made by software developers.
This is wrong.
Many decisions to do with FHIR are not technical at all and should be made or influenced by the business.
1. Which FHIR version to use
If you leave it to developers they’ll choose the latest version.
It’s the default action in software development — always use the latest release of every code library, API, or package. There are rational reasons for this.
Many companies only support current releases. Bug fixes and security patches often go into the latest versions, leaving projects that fail to upgrade at risk.
The HL7 FHIR website doesn’t help here. New visitors to the website are shown R5 — the latest version. You need to be an old hand to know to add “R4” to every page to access the previous version.
R5: the default version: http://hl7.org/fhir/
R4: the most widely adopted version: http://hl7.org/fhir/R4/
Which version should you use and why is that a business decision?
Many countries have regulations that govern the use of FHIR. The US — by way of The Cures Act that came into force in January 2023 — mandates all healthcare organizations use FHIR R4.
There are subtleties in the regulations, but on the whole if you’re building a solution that you aim to sell to healthcare in the US, you will NOT be compliant with current regulations if you use FHIR R5.
Country and region specific regulations like The Cures Act affect the version of FHIR your project should use.
This makes it a business decision.
2. Cloud or on-prem?
Most brand name cloud providers host and sell managed FHIR servers.
- Google Healthcare API
- AWS Healthlake
- Azure Health Data Services
There’s an old saying that’s been updated a few times over the decades. Its current incarnation is “Nobody ever got fired for buying Microsoft.”
This makes choosing a FHIR server from one of these companies a safe decision, but often a wrong one.
Creating and getting started with a managed FHIR server on the cloud is less than 30 minutes work. There’s no Enterprise sales channels involved.
It’s quick and easy and your developers will love it. As someone who writes code for a living, there isn’t much of a living to be made these days if you’re not building on the cloud. If the choice is between cloud or on-prem, we’ll choose cloud — our resume depends on it.
So what’s the problem? Why is this a business decision?
Your business sells to hospitals, clinics, medtech companies and other healthcare organizations.
Have your devs asked those hospitals if they will accept having sensitive patient data stored on an Amazon or Google server in the cloud?
Most hospitals will opt for an on-premises solution — store the data on their servers, in their basement, managed by their experienced IT people.
Your developers won’t know this because your developers are not talking to your customers.
Cloud is a business decision.
Even if your customers are happy to use cloud servers there are still problems. Do your devs know which country those cloud servers are in?
If you’re looking to sell your solution to organizations in one country, is the data being stored on a cloud server in that same country?
Regulations come into play here again. Some countries require sensitive patient data to only be stored on servers in their country.
Cloud providers do not offer FHIR servers in all countries.
For example, if you’re setting up a FHIR server on Azure today in the EU, you have the choice of three locations — North Europe, West Europe and Sweden Central.
French regulations do not allow patient data to be stored outside France, and if my knowledge here is correct, Azure’s “West Europe” FHIR servers are in Germany.
Woops!
Again, cloud is a business decision. It should be based on knowledge of your customer’s needs and requirements, and on the regulations that apply in their country.
3. Which FHIR server provider to use
Alongside the big cloud providers I mentioned earlier, there are half a dozen other companies operating in the FHIR server space. They include:
- Smile Digital Health
- Firely
- Health Samarui
- 1UpHealth
- Medplum
- Intersystems
They’re not all equal.
Every server provider implements FHIR in different ways. Some are strong where others are weak. All of them have issues that could affect your use case and your business.
The FHIR specification is vast. No single provider implements everything in the FHIR spec.
You — and your business — need to know which features of FHIR your solution depends on. You need to build a list of those features and you need to go through each server provider, one by one, and find the one that meets those needs.
Here are some examples of core FHIR features that not all servers support:
- Terminology operations
- Subscriptions
- Composite search parameters
- Asynchronous exports and imports
- Full use of _include and _revInclude search parameters
This checklist of required features must come from the business or from business use cases.
But don’t stop here. Once you’ve refined your list down to a couple of providers, go looking for references.
This is easier than you think, but it involves talking to people outside the company. Developers are not good at this.
LinkedIn will help you here. Use the search filters on LinkedIn to find software developers working with FHIR at different companies, filter further by server provider if possible, then reach out to them and ask for a call.
This is where you pull in your developers or technical architects.
On your call, ask about the problems they’re having with their FHIR server. Ask about workarounds they’ve had to put in place. Ask about things they can’t do but want to do. Ask about performance metrics under production work loads.
You won’t find the perfect FHIR server, but these steps should help you find the most suitable one for your business.
As I hope I’ve demonstrated, many of the most important decisions to be made about FHIR are not technical at all.
Unfortunately, most of these decisions need to be made at the start of a project, when knowledge of FHIR at the business and technical level is at its lowest.
Thanks for reading.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.