FHIR: Fueling Innovation in Health IT

Interoperability of health IT systems has been — and continues to be — a challenge. If you’re like most in healthcare, you’re constantly coming up with “workarounds” to get your EHR to provide or accept data to and from various systems. The result of these workarounds is often a less-than-ideal user experience for the people you’re trying to serve: your clinicians. How many of you out there have settled for creating a PDF and pushing it into your EHR via MDM? Fear not, you’re not alone — and help is on the way in the form of HL7 FHIR.

Why FHIR Is Different

HL7’s FHIR specification was created to simplify how health IT systems exchange data with each other. FHIR is built on the foundation of RESTful APIs — a modern, web-based approach for computer systems to communicate. RESTful APIs operate on the HTTP protocols, the same protocols you use every day in your web browser to check email, read the news, and share vacation photos.

It may not sound big, but this is really big for healthcare. Healthcare is now thinking like the rest of the internet. We’ve opened up our talent pool to every programmer in the world who wouldn’t have touched HIT in the past. Prior HL7 standards were messaging-based (versions 2 and 3) or document-based (version 3). They used proprietary protocols and were often open to different interpretations that not everyone followed (IHE anyone?). With so much confusion about which standard to use, and how to map different terminologies, interoperability was only achieved by a handful of players with “old school” programmers. With FHIR, the doors are open to almost anyone — which means that anyone with a good idea can contribute new, innovative products to healthcare.

What FHIR Can Do Today

FHIR is still in its infancy and comes with its own workarounds, but they are far fewer and much more manageable. What can FHIR do today? FHIR APIs allow authorized client programs to search for data using various parameters and to fetch, add, update, and delete records. Data is exchanged as objects known as “resources.” FHIR defines resources for various types of objects such as Patient, Provider, MedicationRequest, Condition (a.k.a. Problem), and many others. The scope of FHIR’s resources also includes definitional artifacts such as Questionnaire, CodeSystem, and PlanDefinition. The latter resource type is used for creating clinical decision support artifacts such as rules and order sets. I’ll cover definitional artifacts more extensively in future posts, since my colleagues and I use them every day and are significant contributors to their design.

Why Adoption Is Accelerating

The specifications for FHIR continue to grow and evolve rapidly. Many of the largest health IT vendors already provide support for FHIR. The Argonaut group is working to promote and adopt FHIR for use in the US. In my opinion, the reason for the momentum in FHIR adoption — besides federal regulations — is the ease of implementing FHIR services and the ease of consuming them. Many, if not most, software developers already know how to develop web-based applications using REST services. This makes it easy for them to create apps based on FHIR.

The APIs make it simple not only for two systems to communicate with each other, but for innovators to create apps for needs that are not well met by existing products. The expanded FHIR ecosystem — including SMART-on-FHIR and CDS Hooks — makes implementation of such apps even easier. Elimu’s own Sapphire™ product takes ease and speed-of-adoption many steps further by enabling clinical informaticians and analysts to create new FHIR apps using only drag-and-drop capabilities — no programming required at all. HL7’s FHIR roundtable meetings (the last roundtable was big enough for a large auditorium at Duke University) showcase many innovative apps including Sapphire™.

I forgot to mention FHIR’s one downside — the barrage of puns its name inspires.