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:
- REST
- Documents
- Messages
- 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.
