The Interoperability Paradigms of HL7 FHIR

I recently had the pleasure of attending a presentation by Grahame Grieve, the originator of FHIR, on the details behind this evolving health IT standard. I have written a couple of blogs previously to introduce FHIR, including 5 Things to Know About HL7 FHIR and Review of The HL7 FHIR Session at HIMSS13. This standard is evolving steadily within the HL7 organization and is fully expected to reach Draft Standard for Trial Use (DSTU) by the end of 2013.

In his presentation, Grieve discussed four interoperability paradigms as they relate to FHIR.  The interoperability paradigms are:

Graphic courtesy of Grahame Grieve.

Graphic courtesy of Grahame Grieve.

  1. REST
  2. Documents
  3. Messages
  4. Services

REST – REST is at the heart of the FHIR standard. It provides simple, out-of-the box interoperability. REST commands such as GET and POST can be leveraged, along with predefined operations such as Create, Read, Update, and Delete. REST works best in environments where control resides on the client side and a trust relationship exists.

Documents – Documents, such as those required for the transfer of care, are part of the FHIR paradigm as well. A document can be handled as a collection of resources bundled together. Similar to the way a CDA document has a header to define the context for a document, in the FHIR world a resource could be applied for the same purpose. Also, these documents can be shared using an ATOM feed to make sure that all facilities have the most up-to-date document.

Messaging – FHIR can accommodate messaging similar to HL7 v2 and v3 messaging. Similar to documents, messages can be handled as a collection of resources, and they can utilize ATOM feeds for updates. FHIR allows request/response behavior with these bundles, they are event driven, and can be asynchronous.

Services – Custom services have the same content and base rules. FHIR is based on SOA principles, leaving it flexible to accommodate a variety of workflows from ultra-complex to ultra-simple. These workflows can be addressed through an individual resource or a collection of resources. Essentially, one can do whatever they desire. The only constraint is that FHIR resources are being passed in some shape or manner.

One key element to point out is that regardless of the paradigm, the content is the same. This means that it is straightforward to share content across these paradigms.

For example, an application might receive a lab result message and turn around and package it in a summary of care document. In addition, constraints can be shared across paradigms. For example, a profile can be established for blood pressure and used in all of the domains discussed above.

FHIR is meant to be flexible to use and easy to implement. FHIR does not care about the architectural design of the systems. It works equally well for light (mobile) clients and heavy (infrastructure) clients. It can be used for push-based requirements or query-based requirements.

FHIR is promising in many different ways and it will be interesting to watch as it develops and more folks voice their praises and concerns.

robMore from Rob Brull


The following two tabs change content below.

Rob Brull

Rob Brull is the product manager for Corepoint Health. He has worked with software products for over 15 years as both a product manager and sales engineer. Past companies and organizations include Tyco Electronics, Deloitte Consulting, and various distributors of software monitoring and control products. His main focus is to ensure his solutions enable customers to simplify healthcare integration complexities with user-friendly yet powerful software capabilities. This includes meeting applicable Meaningful Use requirements as well as fully supporting related healthcare standards such as CCD, CCR, and greenCDA. Rob is also a Certified HL7 CDA Specialist.