This is a very important question and it’s a question that’s not always given the attention it deserves.
FHIR is fast becoming the default choice for storing and sharing healthcare data. In some companies and organizations it’s mandated for new projects — either officially or unofficially.
Pushing back against this can be difficult.
Let’s say your organization is starting a new healthcare data project. You’re the technical architect and the project lead comes to you and says “Let’s use FHIR.” The team doesn’t have much experience with FHIR and neither do you.
Or maybe you’re the product lead and the technical architect is the one coming to you with the same suggestion. “FHIR is the way to go,” they might say.
What do you do? How do you question this and make sure the right decision is made for the project?
To start, you need to understand that FHIR comes with a LOT of overhead. The technical team will have to build infrastructure around FHIR servers and APIs that they would not need to build around a regular relational database. This work can add months or more of extra time to even a small project.
You do not want to take on this extra workload and complexity unless there’s a good reason.
On top of this FHIR comes with a LOT of limitations. It’s NOT a database and you can’t do things with a FHIR API or with a FHIR server that you can easily do with a database.
So again — make sure you have a good and valid reason for using FHIR in your project.
What are good reasons to use FHIR?
- Interoperability
- Regulations
- Customer expectations
Let’s look at each of these in turn.
FHIR is all about interoperability.
It’s about sharing data. Does your project have a requirement to share data with others? Other organizations, other businesses, even other applications or services within your own organization.
If it does, this is a good reason to use FHIR.
Next reason.
Are there regulations that mandate or suggest the use of FHIR in the region or country your solution or app will be used in? Or maybe there are regulations that mandate or suggest data sharing in some way without mentioning FHIR.
If there are, this is another good reason to use FHIR.
And finally, what do your customers or future users expect?
Are you working with organizations of businesses that already share data using FHIR APIs? Are they consuming data via FHIR queries or FHIR subscriptions from other sources? Are they sending data to others using FHIR?
If they are, then not using FHIR may lead to unmet expectations. It may even mean you can’t work with those potential customers or users at all.
Customer expectations are a very good reason to use FHIR.
So we have Interoperability, Regulations and Customer expectations — all good and valid reasons to use FHIR.
What are the wrong reasons to use FHIR?
Let me tell you a story.
The first FHIR project I worked on, many years ago, should not have used FHIR at all.
There was no requirement to share data. Regulations did not come into play at all as it was an internal application that was not the primary source of patient or clinical data. And the only customer was an internal team who accessed the data via some custom web pages.
In short, there was no reason to use FHIR and no benefit to doing so. The project would have been better served using a Postgres database with a simple schema.
Why was FHIR used in this case?
FHIR was in regular use throughout the wider business. It was seen as the future and technical people were encouraged to use it where possible.
There was an element of “learning by doing” on the project — of catching up with the other teams who were already using FHIR.
And all the decisions around FHIR were made by the technical team and NOT by the business. The devs and the architects wanted to learn FHIR so they used FHIR. There was no business input at all.
Lastly, it was just as easy to spin up a new FHIR server as it was to create a new Postgres database. All the company’s infrastructure was on Microsoft Azure, where creating a new FHIR server involved only a few clicks.
Nobody ever asked “Should we use FHIR?”
Back then no one on the team had the experience to ask the question. It should have been the very first question.
The project itself suffered because of that poor technical decision, with timelines being pushed out and data models poorly defined.
If we’d had a short “Should you use FHIR checklist” at the start of that project, that poor decision might not have been made and the project would have been better for it.
So let’s repeat, what are the reasons for using FHIR.
- Interoperability
- Regulations
- Customer expectations
Look at your own project, whether it’s a new project just getting started or an existing project. Even a mature project that you’ve been working on for some time.
Can you put a check mark beside at least one of these reasons?
If you can’t you need to go back to your team and ask the hard questions.
Ask why you’re using FHIR. Ask how the decision was made to use FHIR.
Look for any ADR documents — that’s Architecture Decision Records — where the reasons behind the decision were documented, and challenge them.
And if no one can provide a strong reason, push back on that decision.
FHIR is great at what it does. But it’s not the solution to all problems involving healthcare data. You need to make sure you’re using FHIR for the right reasons.
~~~
The first episode of my new podcast “The Business of FHIR” was released yesterday. In this episode I talk about the reasons for using FHIR.
---