Why Your Healthcare Organization Needs to Catch FHIR

By: Charlie Provenzano

For many in healthcare IT, FHIR might be viewed as a radical shift in interoperability standards, “yet another standard” that requires retooling of multiple systems.  For those institutions and individuals who have been working in the healthcare interoperability space for years (and for some of us decades) it can be viewed as a natural and welcome evolution of the standards, and an evolution that brings with it many benefits we have sought for years.

The Medium is the Message

First attempts at interoperability between systems involved parsing messages.  Message standards allow data sharing in its most basic form, the only drawbacks being timeliness (messages must be published and “listened” to so real-time integration was elusive at best), and customization of messages. Standardized message formats like HL7 (and I include document specifications in this definition) are still the most popular method of data sharing between systems, despite these drawbacks.

Standardization of messages though, even with a specification as well designed as HL7v3, has its limits.  Z-segments, designed to allow customization of the standards, are very commonly used to carry data that is actually covered elsewhere in the specification. Re-use of “unused” segments is also common.  These types of customizations are harmless for interoperability within the four walls of an IT organization. In this context, customizations can be standardized across all systems that will consume the messages.  It can be messy but it’s manageable. However, this breaks down the minute those messages need to be shared outside of the originating IT organization.

And then sometimes the four walls move.  As designers, we tend to think of our own IT organization as the center of the integration universe.  Due to that fact, few integration designers have ever thoughtfully considered the possibility of a merger of institutions when architecting their message-based solutions. Even when we do consider it, we tend to assume that “our” standards will prevail. The result is usually a tangle of confused standards that has to be continually re-scripted as the systems evolve.  If you believe that your own IT organization is slow to roll out upgrades, this could well be one of the main causes.

APIs and the Quest for “Real-Time”

I always feel like “real-time” should be in quotes because it is defined contextually.  Usually though, it refers to request-based as opposed to event-based integration. For illustration purposes, we can generalize that messages are generated based on events, an admission, discharge, order, etc. Other systems can listen for these events and capture the messages, or they can filter through messages historically and look for particular events. A real-time integration is usually request-based.  One system requests data from another system as needed.

In the pursuit of more real-time integration, in the last 10 or so years, API (Application Programming Interface) based integrations have become more popular.1  The decision by some large EMR vendors to open up their system APIs to outside consumers has provided more meaningful and actionable integrations for the end users. Simultaneously, it also provides stickiness for the associated EMR vendor.

Vendor-specific API integrations provide the greatest flexibility and leverage of existing systems.  However, they are also expensive to create and maintain. Part of that expense comes from the skill set required to build those integrations in the first place.  Where message-based integrations may often be built and maintained through configuration of a tool designed for message handling (i.e., an enterprise service bus), potentially combined with some form of scripting, API integrations require a coder’s skill set which is often more expensive. Additionally, each vendor’s API will have its own structure for calls to that API. That is, the code required to query a system for something like patient allergies can be completely different for each system. It may require different arguments, multiple lookup calls, different security protocols, etc. The fundamental architectures could also differ (SOAP vs. RESTful). In addition, some APIs may be accessible from the web, and others not.

FHIR Evolution

FHIR (Fast Healthcare Interoperability Resources) aims to bring together the best aspects of message-based and API-based interoperability into one standardized API. As such, FHIR combines the standardization of an HL7 message with the real-time request-based structure of an API. From the HL7.org/FHIR website:

“(FHIR) is designed to enable information exchange to support the provision of healthcare in a wide variety of settings. The specification builds on and adapts modern, widely used RESTful practices to enable the provision of integrated healthcare across a wide range of teams and organizations.

The intended scope of FHIR is broad, (and) … is intended for global use and in a wide variety of architectures and scenarios.”

FHIR IS:

• • • An API addressable via http protocol, i.e., a web-based API

    • A standardized API built around a set of defined resources backed by HL7.org

    • A flexible API in that resources are standardized, but the returned data is customizable based on the request

This allows developers/integrators to build applications based on data from disparate applications using the same API calls throughout.  FHIR improves on message-based interoperability by providing real-time request-based access that is backed by standards. It improves on proprietary API implementations in that the structure of the calls is standardized for each resource. This level of standardization allows a single developer to build an application that can pull data from numerous discrete sources.  The sources themselves can be from across the institution or from across the world.

Perhaps the best illustration of this concept is the most prevalent real-world example, the Apple Health app. Apple Health is an app for the iPhone which recently added the ability (in beta test) to hold all of a user’s medical records.  The records are gathered from participating institutions using the FHIR standard. (Apple Health uses Draft Standard for Trial Use #2 of FHIR.  The current version is DSTU3, with DSTU4 destined to be the first production ready version.) Included resources are: allergies, conditions, immunizations, lab results, medications, procedures, and vitals. Because of the FHIR standard, information can be collected from multiple institutions without having to write code that is institution specific.

Within my own record, I can view procedures performed in multiple locations and institutions within the same view, and I can trace those records back to their originating source.  A standardized API makes all of that possible.

That same standardization can work for integrators inside of their own IT walls in ways that are just as impactful.  Most institutions have a combination of vendor and home-grown systems spanning any number of technologies from the last two decades.  Imagine if building an application that draws data from those systems could be as easy as creating a web page. If all of those systems provide FHIR end-points (and also participate in the same security paradigm), it can be just that easy.  With a standard as flexible and powerful as FHIR, we are likely to see rapid progress in its adoption. In fact, with Apple and its participating healthcare providers, it’s already happening on a national scale. This adoption will likely be limited more by each institutions ability to publish FHIR interfaces than by any other factor.

What’s Next?

FHIR is revolutionary in our journey to more patient-centered, data-driven healthcare in the U.S. It has reached a tipping point with its adoption by 82% of hospitals, the ten largest electronic health vendors, the Centers for Medicare and Medicaid Services, and a majority of clinicians.

Check back for Part II in this three-part blog series where we take a deeper dive into FHIR and the challenges it poses for healthcare organizations who are slow or roadblocked to change. In Part III, we’ll share implementation and adoption strategies you can use to put FHIR to work for your organization.

1.      Roy Thomas Fielding, the originator of the REST standard describes an API this way:            

“A library-based API provides a set of code entry points and associated symbol/ parameter sets so that a programmer can use someone else’s code to do the dirty work of maintaining the actual interface between like systems, provided that the programmer obeys the architectural and language restrictions that come with that code.” (Source.)

An API can be thought of as a set of code objects addressable by other systems through a programmed interaction.  In some cases, vendors have chosen to make public the very objects that comprise the fundamentals of their systems, i.e., they publish the same objects used by their own engineers.  In other cases, they have provided a specific API that is only used by third-party applications. Both methods provide the same benefits to end users.

An API-based integration is preferable for real-time integrations because the data may be requested from the API as needed rather than listened for as with a message.  This is request-based integration as opposed to event-based. This allows other systems to call on data as needed and in real time. For example, an order system in a walk-in clinic may want to request allergy information at the time the order is created from a local hospital that treats many of the same patients.  Some vendors have gone as far as to include hooks for integrators to insert their own custom workflows and screens. For example, a user may wish to view notes from an outside system when updating orders in the primary system.