At Capable, I help architect our data model to be compatible with national healthcare standards, including FHIR.

I get asked all the time by developers who are new to healthcare, what exactly is FHIR? Here’s the 101, breaking down FHIR, its principles, and why it's critical for the future of digital health solutions.

What is FHIR?

FHIR — pronounced fire — stands for Fast Healthcare Interoperability Resources. It is an open standard that facilitates the exchange of healthcare information between different systems regardless of how those records are stored.

FHIR opens up records to developers by providing a common interface with the hopes of reducing duplication of labs & imaging, and building a more integrated and seamless user experience.

For example, one study found duplicate tests in 32% of records examined. FHIR hopes to reduce these duplications and make a record available to all the practitioners a patient sees, all at once — not just the ordering physician.

Not just another standard

Upon hearing about a new standard, any seasoned developer will immediately send you this in Slack:

... which is valid if we are arguing about HD-DVD vs. Blue Ray. But in the case of FHIR, there are some pretty big players demanding conformity.

The U.S. government's Centers for Medicare and Medicaid (CMS), which represents roughly 57% of healthcare spend for payers, has published regulation demanding providers conform to FHIR. I am a betting man, but I wouldn’t bet against the federal government.

How does it work?

At its core, FHIR is a RESTful API. Base resources schemas are defined by the governing body Health International Seven (HL7). There are specifications for CRUD, and it can work on JSON and XML.

There are common resource types, such as:

• “Patient” which has contact information, basic demographic information, and related persons,
• “Observation” to track vital signs, and
• “Encounters” which details an interaction between a patient and healthcare provider(s).  

With the complexities of healthcare, HL7 has learned that the key to an interoperability standard is to define a way to extend resources to unforeseen use cases. That is, resources are extensible. This is done through a foundational component of “Extensions,” a well-defined and governed component of FHIR which helps ensure interoperability and simplicity for everyone.

Extensions can be used to create custom resources known as profiles. A common profile is the US Core Profile which defines profiled resources that have elements that are important in the United States. For example, it adds “race” and “ethnicity” to the patient resource. You will notice this is missing from the base patient resource. The standard can still facilitate an exchange through a HL7 base profile and a US Core Profile through this extension mechanism.

FHIR challenges

As great as this all sounds, information blocking and general foot dragging by legacy EMR providers doesn’t always make this seamless. Additionally, the data from legacy data formats needs to be in a state that can be mapped to FHIR, which is more common than you think.

Finally, a new developer in the healthcare space will find challenges in navigating the semantics of different resources, and extremely complex taxonomy (just look at SNOMED and LOINC codes). But that is a different blog post.

Help with FHIR

Drawn by its usability, FHIR is utilized by healthcare developers around the world, and represents a huge milestone in removing barriers to healthcare data exchange.

At Capable Health, our goal is to decrease the complexities and worries of implementing FHIR for our healthcare builders. Capable’s all-in-one care delivery and management platform enables providers to launch and scale their own HIPAA-compliant digital health solution — with a clinical data model built on the principles of FHIR that’s secure, interoperable, and scalable.

If you’re a developer or provider who’s building a digital health solution, we're here to help. Book a demo with the Capable team today.

‍