HL7 has developed a new standard known as FHIR. In addition to FHIR, HL7 also has two major standards (HL7 v2, HL7 v3) which are targeted to healthcare interoperability and these are as relevant today given their level of implementation and maturity. This article addresses how they are likely to interoperate as Cloud solutions become more prevalent.
So let’s discuss FHIR, Fast Healthcare Interoperability Resources. There are significant benefits to FHIR when compared to v2 and v3. While FHIR addresses some shortfalls around v2 and v3, FHIR effectively accomplishes two major objectives and I’ll try to describe these objectives without being critical of v2 and v3 since these versions continue to provide benefits of their own.
FHIR allows the HL7 organization to maintain its position of relevancy as a Standards Development Organization as the Cloud technology platforms and solutions continues to mature
FHIR allows healthcare organizations to implement FHIR-based solutions using technologies which are conducive to Cloud-based and mobile-friendly platforms with a faster implementation cycle
How is FHIR relevant in today’s technologies?
FHIR allows smaller more discrete units of data to be sent across the wire. These units of data are known as Resources. Hence the word Resource in Fast Healthcare Interoperability Resource. In addition to these small units of data, these Resources may be compiled, inline or by reference, into larger business appropriate groups to accommodate varying business processes within the healthcare continuum. For example, the Patient, Observation and DiagnosticReport Resources may be assembled into a Composition Resource to form the equivalent of a clinical document.
Example of a Resource
The Patient Resource is used to communicate data about the patient. Here is the UML representation of the Patient Resource. As can be seen from the model, the Patient Resource allows all of the relevant data about a patient to be exchanged.
As with other HL7 artifacts, there are several other formats to use when trying to understanding the data structure. The following shows the Patient Resource using the XML structure and JSON structure. The XML structure representation of the Patient Resource is:
The JSON representation of the Patient Resource is:
Sending and Receiving FHIR Resources
FHIR Resources are primarily designed for RESTful based implementation, however, there are other ways or exchange frameworks to send a FHIR resource over the wire.
The RESTful framework allows a total of six “interactions” or operations to be performed on resources of a given type. This provides for a very predictable and simple mechanism when sending or receiving data. These interactions are 1) Reads, 2) Updates, 3) Deletes, 4) Creates, 5) Searches, and 6) Conformance.
FHIR Resources may also be exchanged using SOAP or even MLLP. A custom built adapter will be required to support MLLP in the Cloud. See our blog for more information on our v2 solution using MLLP in the Cloud.
Overall Status and Maturity Level of FHIR
The FHIR standard may be tagged with one of the following:
Draft – This indicates that the Standard is not considered to be complete enough or sufficiently reviewed to be safe for implementation. It’s essentially “use at your own risk”
DSTU – The content has been well reviewed and is considered by the authors to be ready for use in production systems. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. Future versions may make significant changes to DSTU-level content that are not compatible with previously published content
Normative – The content has been subject to review and production implementation in a wide variety of environments and is considered to be stable and has been ‘locked’. Although changes are possible, they are expected to be infrequent and are tightly constrained.
In addition to the “Standard” level, FHIR also has a maturity level indicator for each Resource. A Resource may be one of the below:
Level 0 – the resource or profile (artifact) has been published on the current build
Level 1 – The artifact produces no warnings during the build process and the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation
Level 2 – The artifact has been tested and successfully exchanged between at least three independently developed systems at a Connectathon whose results have been reported to the FHIR Management Group
Level 3 – The artifact has been verified by the work group as meeting the DSTU Quality Guidelines and has been subject to a round of formal balloting with at least 10 implementer comments drawn from at least 3 organizations resulting in at least one substantive change
Level 4 – The artifact has been tested across its scope (see below), published in a formal publication (e.g. DSTU), and implemented in multiple prototype projects. As well, the responsible work group agrees the resource is sufficiently stable to require implementer consensus for subsequent non-backward compatible changes
Level 5 – The artifact has been published in two formal publication release cycles at FMM1+ (i.e. DSTU level) and has been implemented in at least 5 independent production systems in more than one country
As of the time of writing this article, December 2015, here is the overall status of FHIR:
FHIR is currently at DSTU 2-1.0.1
Published Oct 24 2015
Three earlier versions – Dec 2014, Apr 2015, Aug 2015
Hope to finalize DSTU 2 in 2017 with normative edition likely in 2018
“Degree of testing has varied. Some resources have been well tested in a variety of environments. Others have received relatively little real-world exercise”
“Regardless of the degree of prior implementation, all aspects of the FHIR specification are potentially subject to change”
Changes may be minor (clarifications of definitions, etc.) or major (refactoring of resources, changes to serialization rules, eliminating or adding data types, etc.)
No commitment to backward or forward compatibility during the DSTU process
The interests of long-term implement-ability will generally trump the impact on early adopters when determining what changes should be made
There are four Resources at Maturity Level 3. All other Resources are at Level 0, 1 and 2.
FHIR is here to stay and will provide significant advantages going forward. Using v2 and v3 with the more traditional MLLP and SOAP frameworks are well understood by virtue of their maturity level and market penetration. Organizations must understand how to leverage FHIR into its implementation toolkit knowing that, like v2 and v3 co-existing, FHIR will be a part of this multi-standard, multi-exchange environment. After all, the business processes and data have not changed; it’s the same data.
Rajie Ragbeer, Senior Enterprise Consultant
Rajie has worked within the healthcare IT industry for more than 17 years and brings to Dapasoft his in-depth knowledge of HL7 message development methodology (v2 and v3). This combined with technical and integration expertise has proven to be a unique skill set in the industry and is of tremendous value to our healthcare clients. Rajie is a domain expert for “EHR and Healthcare Integration” at Dapasoft. He teaches HL7 and has also provided expert level consulting to Canada Health Infoway (CHI) in the development and implementation of the pan-Canadian HL7 specifications. He was instrumental in the design and development of the pan-Canadian HL7 v3 specifications.