Not every healthcare data project should be a FHIR project.
FHIR server vendors will be quick to disagree, telling you that FHIR is versatile and comprehensive and that your project would benefit from using FHIR even if isn’t a requirement.
I strongly disagree.
FHIR comes with a LOT of overhead and a LOT of limitations. Your technical team would need to build infrastructure around FHIR APIs and FHIR servers that they would not need to build around a regular database. Project scope can balloon when even simple requirements such as running analytics against FHIR data appear.
You do not want to take on this extra work unless you have to.
A couple of months ago I gave a talk at FHIR DevDays to business leaders and project leaders heading up healthcare data projects. I highlighted what I see as the three key reasons for using FHIR.
1. Interoperability
Does your project have a requirement to share patient or clinical data with others? These others may be external to your business or organization or they may be different departments internal to your organization.
If this requirement exists it’s a good reason to use FHIR. FHIR is all about interoperability. It’s what it was designed for and it’s what it excels at.
2. Regulations
Are there regulations that mandate the use of FHIR in the region or regions in which you operate? If not, are there regulations that mandate data sharing without mentioning FHIR specifically?
These are all strong reasons to use FHIR and one of the key reasons for the growth of FHIR in various countries around the world. The yearly “State of FHIR Survey” produced by HL7 and Firely shows a clear increase in countries with regulatory FHIR mandates and data sharing mandates.
3. Customer expectations
What do your customers or potential customers expect?
Are they working with other organizations who expose data via FHIR or who accept data from them via FHIR? Do they have expectations of being able to access your data via FHIR Subscriptions or FHIR APIs?
If they do, this is another good reason to use FHIR.
You should be able to put a check mark beside at least one of these reasons for using FHIR. If you can’t, that’s a strong indication that you should not be using FHIR at all. Maybe a regular database with a simpler schema might be more appropriate.
If you have an existing project that uses FHIR and you can’t identify with one of the three reasons outlined above, you or your team may have made a mistake. You should revisit the decision.
Go back and look at the early design documents and work out why the decision to use FHIR was made. Weigh up the pros and cons of continuing with FHIR with an emphasis on future requirements and how FHIR might meet those requirements. Ask yourself: “Would a simpler database or data warehouse be a better solution?”
Don’t fall for the sunk cost fallacy. Make the decision that’s best for your project today and tomorrow.
FHIR is great at what it does. It’s the answer to a lot of problems in healthcare data. But it’s not the answer to all problems.
---