HL7 FHIR and its Applicability to the Cloud

HL7 FHIR and its Applicability to the Cloud

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.

Patient Resource-UML View

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:

Figure 2 - Patient Resource - XML Structure View

The JSON representation of the Patient Resource is:

JSON

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.

  1. 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.

  2. 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.

 

Author

Rajie RagbeerRajie 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.

 

2 Comments

  • Ranjan Kumar says:

    Nice informative article on FHIR. Please suggest the detailed tutorial about FHIR if any apart from FHIR tutorial by HL7.

  • Rajie Ragbeer says:

    Hi Ranjan

    We do sometimes provide HL7 tutorials to clients and these are customized to the client’s needs and requirements. We make these tutorials relevant to the projects and to the project teams with the successful execution of the project objectives as the primary goal.

    I am not aware of any other tutorials apart from that offered by HL7. I have found over the years that HL7 tutorials and education are best offered in specific context to an organization and or project team and to make the content relevant to the needs of the audience, The attendees of the tutorials offered by HL7 generally have a higher level interest and knowledge in HL7 already and these audiences do benefit greatly from these sessions. However, if you are new to HL7 or if you have a larger team which require general or specific education around the HL7 Standards including FHIR, tailored sessions are best, in my opinion.

    If you have a project which includes HL7 (e.g. v2., v3, FHIR, CDA) and or exchange of healthcare data and or integration of healthcare data, it’s best to consider a session targeted to your entire team and specific to your project.. The session should be structured in such a way that all team members will benefit from it. There should be content relevant to the project sponsors and executives, project managers, architects, business analysts, technical analyst, developers and QA resources. I typically set this up such that team members can attend one or more 2 hour blocks which are relevant to them. For example, project execs and stakeholders may attend the first session, project managers and project leads will be there are about 2 sessions. BAs, Architects, developers and testers will attend the entire session.

    I do hope this has been helpful. Please do not hesitate to contact us if we can be of assistance further.

Leave a Reply