I’ve worked on three greenfield FHIR projects. In each case I onboarded early and in each case I stayed past the first production release.
I got to see where all the bodies were buried.
Though each project touched on different areas of healthcare and medtech, some things were the same.
– No dev on the team had prior knowledge of FHIR
– Most were new to healthcare data
– FHIR server decisions were made early and quickly
– Experts were not brought in until AFTER the key decisions were made
We could have done better. We should have done better.
The third time I watched this happen I was the FHIR expert, brought in 4 months too late.
My aim here is to provide a “Getting Started” guide for the dev team so that those early decisions and actions come from a place of knowledge rather than ignorance.
A starting point so that you know the questions to ask and the things to learn.
Action 1: The FHIR server
Azure, GCP, AWS, Firely, Smile (HAPI), Medplum, Kodjin, Aidbox, Helios, etc., etc.
FHIR has experienced almost hockey stick growth over the past few years, driven in part by regulatory changes and in part by a growing desire to better share patient data.
The result is a FHIR landscape that can be difficult to navigate for those new to FHIR.
When you start thinking about your FHIR server ask yourself these questions:
– Are you looking to expose data in your existing database or warehouse via a FHIR API?
– Do you want to use a FHIR server to store your data?
– Are you considering syncing data from your primary data source with your FHIR server?
– Are you thinking Cloud or on-prem?
– If you’re leaning towards Cloud, are you considering a managed FHIR server?
– Have you got the experience to manage the FHIR server yourselves?
– Do you need or want direct database access to the data stored in your FHIR server?
– Will you need to run heavy analytics queries on the data in the future?
– Do you need to control the release cycle of server updates?
The answers to these questions should point you in one direction or another when choosing a FHIR approach and server.
You have the following choices, ranked from the easiest to get off the ground to the most difficult:
1. Managed cloud FHIR server
2. Commercial stand alone FHIR server
3. Open source FHIR server
4. Build your own FHIR API (Façade)
I’m dumbing things down a little, but essentially you will probably find yourself choosing one of the above.
You should avoid number 4 unless you have solid reasons for discounting all others and unless you have the in-house experience to build a FHIR API.
Cloud servers are the quickest to get started with and are often an easy sell inside the business, where Azure, AWS or GCP accounts may already exist, but the price is high.
– No database access
– No release management process
– No ‘ownership’ of the server environment
The true price is paid later in the project, but it is paid.
Don’t discount the smaller software companies building FHIR servers. It’s a growing space and many of these companies offer better support than the Cloud behemoths.
Action 2: The Technology and the Platform
The Language Choice
Developers like to say that they’re language agnostic, that the choice of which language or technology to use is based on the needs of the project.
Sounds good, but it’s rarely true.
.NET shops write C#. If you use Ruby or TypeScript, then chances are that’s your first choice for each new project.
Here’s the thing about FHIR: It looks simple on the surface but it’s filled with complexity. Picture an iceberg with 90% of its bulk hidden away below the waterline. That’s FHIR.
You should not be thinking about rolling your own FHIR client, writing your own DTOs, serializing and de-serializing your FHIR request bodies.
Do not do this.
Use one of the existing SDKs, even if it’s in a language your team do not normally use. The most well known and up to date SDKs are provided by commercial software companies working in the FHIR space. All of them come with permissive open source licenses.
– C# by Firely
– Java by Smile Digital Health
– Python by Beda Software
Other SDKs exist but they’re either incomplete or rarely updated. Here’s a comprehensive list I put together earlier in the year.
Dev Environments — Localhost
Each FHIR server is different and comes with its own compromises. For this reason, you should endeavor to mirror your production server in each dev’s local environment.
You could use a shared DEV server, but most developers will be more comfortable working locally. If you don’t help them set up a local environment, they’ll find a way to set one up themselves — probably using the wrong FHIR server.
Here are a few options:
– Microsoft Azure’s managed FHIR server.
Uses the same codebase as their OS server, which can be run from a Docker container.
– Smile’s HAPI server.
Also comes with a Docker instance.
– Most commercial vendors provide a way to run their server inside a container.
You may need to negotiate with them for this, but it’s worth doing.
Action 3: Learning FHIR
The FHIR documentation is vast and difficult to navigate. Though it makes some claim to having different onboarding paths for different types of users, the dev path is of little practical value.
Here’s how I recommend your team of devs learn FHIR:
1. Understand how to read a resource’s documentation page.
The highlights.
2. Read up on the different FHIR data types — the building blocks of FHIR.
More about data types.
3. Load in some sample data.
Synthea data.
4. Learn how to run queries on that data.
More about queries.
5. Read about some advanced FHIR concepts that you won’t need today but will need in 6 months.
Seven FHIR concepts.
Give them a couple of days to work through the above, reading all the accompanying links and playing with the sample data.
Once they’re done, have them write code using the SDK in your chosen language to run those same queries and to add or update some resources.
At this point your team should be ready to get to work.
Action 4: Architect Q&A
Your project Architect will have a lot of decisions to make that will not be obvious at the beginning of the project.
Here are some questions that she should be thinking about from Day 1:
Q. When data flows into the FHIR server, how do we track who sent it?
A. Look at a resource’s Tags, Security Labels and Meta.source elements. Look also at the Provenance resource.
Q. How do we ensure duplicate records are not created?
A. Consider using or enforcing Conditional PUT requests for incoming data.
Q. Should we intercept data flowing into or out of our FHIR server?
A. Probably. Intercepting the request allows you to change the data if required, apply tags to resources, run queries and perform business validation in ways not easily done using FHIR profiles.
Q. Can the server handle heavy analytical queries?
A. This is beyond the capabilities of a FHIR API. All the cloud providers encourage some form of FHIR to Data Warehouse syncing for this purpose.
Q. Do we really need to handle Smart on FHIR?
A. Yes, even if it seems like you don’t. In some countries it’s a regulatory requirement; in all countries it’s an industry standard.
Q. Everyone else is using FHIR R4, but should we consider using R5?
A. Which FHIR version to use is not a technical decision. In the US R4 is mandated by regulation. This is a business decision.
Q. I’ve been reading about ValueSets and Terminology servers. Do we need one?
A. Almost certainly yes, although you may not think you do. Once your product begins to interact with real healthcare users and once you start sharing data with other organizations, the need for a standard terminology will become glaringly obvious.
Getting terminology wrong is almost a right of passage for new teams building new products in the healthcare space.
There is decades of knowledge to draw upon here. If you try to re-invent the wheel when it comes to terminology, yours will be the only car on the road you built.
---