HL7 FHIR, the Future of Healthcare Messaging

By jasonDevelopment

HL7 FHIR, the Fast Healthcare Interoperability Resources standard, was built originally to assist with compliance of Meaningful Use interoperability standards (now Promoting Interoperability Programs). The draw of the FHIR standard was that it was a combination of HL7 v2 and v3, as well as CDA, standards, but in a web friendly, human readable format. One draw of the new standard, as expressed by the HL7 group, is that they are offering the FHIR standard for free. This is a departure from their v2 and v3 standards which in the past would cost thousands of dollars to obtain. These are now too available with signup on the web.

From a technical perspective it does remind us of HL7 v2 and v3 in that it offers a schema for communications between systems, making it simpler for solutions developers to build products that can work with any supporting system. A nice addition to the FHIR standard is the SMART on FHIR implementation that allows EHR launch with context sharing. This allows us to easily develop extensions to the EHR (Electronic Health Record) that can use the existing patient and provider contexts available within a workflow to provide custom solutions, such as proprietary interventional model visualizations, embedded in the EHR. In the past this would require development in the EHR’s back and front end languages, and require code be reviewed at each upgrade due to the tight integration between the EHR’s programming APIs and the solution.

DSTU2? R4? STU3?

One issue we feel is causing pain and confusion in the industry is the rate of change of the HL7 standards, and the variable rate that EHRs are adopting those changes. Right now, a single EHR might implement resources using a mixture of DSTU2 or STU3 standards. While it’s understandable the standards body is attempting to keep up with the needs of the healthcare world, several standards versions have been released relatively quickly, at least from the perspective of the healthcare world. This is causing EHRs to make available some subsets of each standard, but no full standard implementation.

Many application developers without HL7 experience, or with lack of knowledge of the slow pace of healthcare, are trying to implement solutions using the newest standards which few EHR vendors support, either partially or in full. This is causing understandable dismay from developers, and healthcare IT’s clinical and business partners, that their solution cannot be implemented. It’s also causing stress between the business and IT as technical teams try to explain the reasons behind their inability to implement cutting edge solutions.

Availability of Resources

Another issue that’s arising, is many EHRs are only implementing bits and pieces of the read and search resources, and few are implementing write resources. When they do implement write resources it is a subset and not all write resources. Currently IT groups need to stand up proxy servers to ingest FHIR messages, determining if they can support the request via FHIR. If not, those messages are transformed into HL7 v2 or v3, or to a message format available via a proprietary restful service within the EHR. While this is nothing new for healthcare IT to support different messaging formats and their transformation via an ESB (enterprise service bus), many integration teams are hesitant to take on the chore of consuming and converting what should be a standards based web service message. In addition this adds complexity to already complex EHR implementations.

Bulk Messaging

Another pain point arising is that there are many potential solutions that would require a bulk message dump, such as analytics products and data sharing with government agencies. We know that Epic Systems’s product line contains Kit, a bulk FHIR messaging extension of Caboodle their EDW (Enterprise Data Warehouse). Outside of that, availability of such a product is spotty. And even with the implementation of bulk messaging products we are at the mercy of the FHIR implementation limitations of the vendor, which might not provide all resources for any single standard.

Security

Primary on the mind of healhcare organization’s CISOs is the safety and security of patient data. In our modern world, hospitals have become a hotspot target for bad actors. Medical records fetch large sums on the black market, and healthcare IT is often years, or decades, behind the rest of the IT world as far as the use of security technology. With this, the idea of having externally developed, patient facing applications that make calls into the EHR is making many in information security squirm. That we cannot tightly control and review solutions that patients are trusting with their medical data is causing hesitation to allow FHIR to be turned on at all. And the idea of allowing these same applications to have write access to the medical record, a legal document, is as complete turn off to ISO and legal.

Wrap up

While we in healthcare IT that work with research groups, patient facing solutions, and interventional analytics see great things eventually coming from HL7 FHIR, there are still many roadblocks to having FHIR take over the world. For one, the HL7 standards group needs to slow down their development of the standard to allow EHR vendors and healthcare organizations to catch up, or make it very clear which standards are generally available, and which are in development (no more R#, STU, DSTU!). EHR vendors also need to take on a portion of this, and make an industry wide decision to implement a full version. Next we need more education and guidance to those developing solutions, who most likely do not have a HIPAA compliance office or med legal group, on what makes security and legal compliance squirm in their chairs. This would include guidance from healthcare organizations on what they themselves find acceptable, and what raises a red flag. Finally, there needs to be a push among all EHR vendors to support bulk messaging using the FHIR standard, so organizations do not have to implement one off solutions using products such as HapiFHIR.

FHIR is a great step forward for healthcare, and brings us into at least the last decade from a messaging standards perspective. We are seeing many great ideas turn into products quickly due the easy availability of technical information, and innovative products being implemented in the EHR due to the nature of SMART on FHIR. I think, with some time and tweaks to the way the standards body and vendors think about, and implement, the FHIR standard it truly could take over healthcare messaging.

For more information on FHIR, SMART on FHIR, and vendor implementations, here are some good resources.