The Experience of Interoperability Thus Far

John D. Halamka, MDAs I travel across the country and listen to CIOs struggling with mandates from Meaningful Use to ICD-10 to the HIPAA Omnibus rule to the Affordable Care Act, I'm always looking for ways to reduce the burden on IT leaders.

All have expressed frustration with the health information exchange (HIE) policies and technologies for care coordination. quality measurement, and patient engagement. As a country, what can we do to reduce this anxiety?

Meaningful Use Stage 1 brought some interoperability especially around public health reporting. Stage 2 brought additional interoperability, with well defined content, vocabulary, and transport standards for transitions of care.

Most CIOs have implemented certified EHRs and the required standards.  Here’s a capsule summary of what I’ve heard

HL7 2.x

HL7 messaging addresses lab result and public health use cases very well.   Lab results interfaces are straight forward, however there is still some need to reduce optionality in implementation guides so that the average lab interface costs $500 and not $5000.    Public health transactions for immunizations, reportable lab, and syndromic surveillance are standardized from a content perspective but  there is still a need to specify a single transport mechanism for all public health agencies.

CCDA/Direct

CCDA documents address transitions of care use cases reasonably well.  CCDA is easier to work and parse than CCD/C32 because it has additional constraints and specifications, but there is still enough optionality that merging CCDA data into an EHR can be challenging.    In addition, most EHRs generate a CCDA automatically and include all data that may possibly be relevant.  In some cases, this leads to C-CDAs that are rendered at 50+ pages.   We need to reduce optionality so that CCDAs are easier to generate correctly and parse.  EHR workflow needs to better support the creation of clinically relevant documents with narrative and data more specific to transitions.

Direct was a good first step for transport - we needed to pick something.  We could have required sFTP, REST, SOAP, SMTP/SMIME or even Morse Code as long as it was completely standardized. Unfortunately, we picked multiple options.   Some EHRs use XDR (a SOAP transaction) and some use SMTP/SMIME.   Whenever standards have an "OR", all vendors must implement an "AND". XDR must be translated into SMTP/SMIME and SMTP/SMIME must be translated into XDR.   The reality of Direct implementation has show us that this optionality provides a lot of plumbing challenges.   Certificate and trust issues are still an ongoing project.   Getting data from medical devices via Direct is challenging since devices tend to use heterogeneous transmission protocols. Finally, SMTP/SMIME was never designed for large payloads of multiple files, so sending datasets greater than 10 megabytes can be a struggle.   The use of XDM for zipping files before they are sent is overly complex to use as part of a transport protocol.

Although Direct works, it is often not well integrated into the EHR workflow.

FHIR, as discussed in multiple recent posts, can help address these challenges and leverage the lessons learned.  The FHIR concept is that every EHR will provide a standardized interface for the query, retrieval, and submission of specific data elements and documents using a web-based RESTful transport mechanism and OAuth security.   This use case can easily support unique modules or “bolt on” application functionality to EHRs.    It significantly simplifies the interfacing challenge, works for large payloads, and minimizes optionality.   There are no multiple transport options, no certificates to manage, and the query/retrieve processes can occur behind the scenes, enabling smoother workflow.

FHIR can even be helpful as a transition strategy while Direct is still used for pushing payloads between EHR.   If FHIR/REST/OAuth replaced the XDR/XDM options of Direct, that provides a glide path to the eventual end to end replacement of Direct with FHIR.

Once FHIR is available, EHR vendors should design a user experience that follows the IEEE definition of interoperability - “the ability of a system or a product to work with other systems or products without special effort on the part of the customer. "

In summary, think of HL7 2.x as good enough for messages  pushed between systems,  Direct/CCDA as suitable but challenging for pushing XML documents between systems, and FHIR as a means to integrate multiple platforms via the use of application program interfaces that support the simple query/retreat/submission of data among applications.

FHIR will solve many of our interoperability challenges with appropriate support from EHR developers for clinically relevant workflow. We have to be careful not to oversell it, but for many use cases, FHIR is our best hope for the future.