What You Need to Know About Using FHIR

By Pavel Smirnov, an exhibitor at the HIMSS Interoperability Showcase™ at the 2018 HIMSS Global Conference & Exhibition, and CEO of Health Samurai

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. Migration between FHIR versions is painful because of no backward compatibility. But there are promises of backward compatibility starting from the normative version.
  3. 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.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Experience up-and-coming digital health innovations at the HIMSS Interoperability Showcase™.