We empower healthcare innovators to provide affordable, personalized, quality care at scale.
Thanks for joining our newsletter.
Oops! Something went wrong.
Join our community
Breaking down FHIR and why it's critical for the future of digital health.
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.
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.
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.
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:
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.
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.
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.
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.