Let’s talk about why FHIR is great, what isn’t so good and what the standard is not built to do. Here is what you get with FHIR:
- A strong community of developers to discuss complex problems
- A standard, documented information model
- Modern web technologies that are easy to implement
- Future interoperability
- Development tools like FHIR servers and libraries
What’s Great About FHIR
Here are the reasons I love FHIR and why I see much use in it as a standard:
- Great data models for common medical and financial data. FHIR is a great data model for storing clinical and financial data because it has the accumulated wisdom of many experts.
- The FHIR community is incredible. FHIR is an open source standard with a passionate community of experts deeply involved in discussions of better solutions for complex problems. You can often get your question about FHIR answered by experts in a matter of hours or even minutes. This might be the most important factor in driving FHIR adoption, and the significant traction of the standard and incomparable community engagement gives the industry a real chance to transform and modernize the health IT ecosystem.
- Application programming interface (API) and tools that are easy to learn and use for web and mobile apps. You can build enterprise-level web and mobile applications in a matter of months with FHIR APIs, cutting months (and even years) of development time.
- FHIR facilitates interoperability with legacy standards. Even if legacy systems aren’t using the FHIR standard, there are well-documented FHIR mappings for Health Level 7 v2 and the Continuity of Care Document, which allow easy integrations with legacy systems.
- The FHIR specification describes an easy way to use terminology services. Organizations using FHIR platforms get easy access to the most commonly used medical terminologies such as RxNORM, LOINC, ICD-10, SNOMED, NPI and others.
FHIR is the real deal that can be applied to solve different clinical, administrative and business problems. It’s a tool that can create miracles in the hands of multidisciplinary teams of engineers and healthcare innovators.
What Isn’t So Good About FHIR
Here are a few challenges I found when working with FHIR:
- A generic informational model is not always the easiest and fastest way to implement specific use cases. It requires careful analytic and synchronization with the FHIR standard and community. And you will probably need to extend and adopt FHIR models to your specific needs.
- Migration between FHIR versions is painful because of no backward compatibility. But there are promises of backward compatibility starting from the normative version.
- FHIR Extensions and profiles can be complicated to use. FHIR resources need to be extended when dealing with specialty health data that falls outside of the most commonly used clinical data. This creates an additional layer of complexity and can be time-consuming or even overwhelming when an implementation needs a lot of extensions.
FHIR is supported by all major EHR vendors and some of them even offer FHIR marketplaces. But some vendor marketplaces are quite expensive. They also tend to not have friendly intellectual property terms, so the FHIR API is currently limited in its usability and lagging behind the FHIR adoption curve across the industry.
Electronic Attachments Tell a Comprehensive Health Story
Recommendations to Guide Secure Interoperability
What FHIR is Not
There are many benefits of FHIR, but like any standard it comes with limitations. FHIR was not built to take care of certain technical requirements (though that might change in the future). This is why a company leveraging the FHIR specification for their enterprise solutions need to compliment it with additional features to meet comprehensive technical needs of a solution.
Here’s what FHIR is not built to do:
- FHIR does not address technological concerns such as your system architecture, system to system integration, security and analytics. The standard was built to enable interoperability and not meant to address these technical considerations. These are problems that still need to be solved by engineers working on the solution.
- FHIR standard API is limited and probably won’t be enough for your real app. Life is always more complicated than we think and while doing real implementations you probably will need to extend the FHIR API with additional capabilities and endpoints.
- FHIR is not a security protocol, nor does it define any security-related functionality. The standard wasn’t meant to address security. Engineers should understand the importance of security in healthcare and implement necessary security features including HIPAA safeguards.
- FHIR doesn’t address infrastructure. A highly available cloud infrastructure is very important when building modern solutions to replicate, secure and quantify your healthcare data. Because of this, engineers should look at platforms that offer automated cloud infrastructure out-of-the-box.
FHIR is designed to do great things for health IT. Despite a few limitations around the standard, the benefits it brings will make it a standard that is here to stay. As long as you are aware of what FHIR is built to do and what it isn’t built to do, you will be able to find solutions in the marketplace that compliment FHIR to meet your data and solution needs.
The views and opinions expressed in this blog or by commenters are those of the author and do not necessarily reflect the official policy or position of HIMSS or its affiliates.
Originally published March 5, 2018