Electronic Health Reporter

By Drew Ivan, EVP of Product and Strategy, Rhapsody  and Corepoint Health.

Healthcare is home to some of the most mind-blowing technological advances when it comes to diagnostics and therapies. At the same time, the healthcare system is responsible for many of the most head-scratching operational difficulties related to standard IT processes, such as those involved with moving data from one system or site to another. The same industry that successfully deploys remote-controlled surgery robots to heal a patient also struggles to send a discharge summary to a physical therapist for the same patient.

How can we explain this apparent paradox?

A Model of Interoperability

The simple answer is that interoperability in healthcare is a journey, not a destination. The question “why haven’t we solved interoperability?” assumes that interoperability is a one-time problem, when in fact the systems, standards, and data flows that constitute interoperability are constantly changing as the underlying patterns of treatment and reimbursement change.

Interoperability today spans more systems and settings than ever before, and “interoperability” means different things to different audiences, so it’s worth taking a moment to ponder the modern interoperability landscape. The following model is an expansion of one suggested by the National Academy of Medicine[1].

In the center, provider, or organizational, interoperability indicates data flows within a single organization, typically a hospital or hospital system. This has historically been dominated by HL7 v2 transmitted over a TCP connection on a private network, although other standards and technologies are also used.

At the top, community, regional, and national cross-organizational Interoperability refers to communication of healthcare data across different organizations, for example ACOs, HIEs, and provider-to-payer data flows. In this part of the model, we often see IHE style integrations that exchange entire patient records in a single, secure transaction over a public network.

At the bottom, the Internet of Medical Things (IoMT) is divided into two parts: medical device interoperability, which concerns devices used in a clinical setting, and consumer device interoperability – commercially available devices marketed directly to consumers, such as fitness devices and in-home monitors.

On the left, healthcare IT vendors need to enable their products to interoperate at different levels of the interoperability model, depending on which markets they serve. For example, an EHR vendor will need its product to send and receive HL7 v2 messages in order to participate in the organizational interoperability space.

On the right, we are seeing an increased demand for patient or consumer access to their data, whether it is from a fitness device, a hospital’s EHR, or a payer’s disease management system. Integration in this box is often accomplished using APIs, including FHIR.

Common Pitfalls

Within each box of the diagram, interoperability is working “well enough”. The state of the art is far from perfect, but systems are integrated at a level where work can productively be done. However, as more workflows and dataflows begin to span the different vertical layers of the interoperability model, there are more opportunities for disconnects due to differing standards, data types, person identifiers, code systems, and so on.

This is a big problem, for example, when a hospital wants to import blood pressure data from a bedside device (MDI layer) into their EHR (organizational layer) and then include that information in a C-CDA that is sent to an HIE (regional layer). IT departments are beleaguered by the number of data translations and format changes along the way. Each transformation is a project in its own right and introduces potential translation errors and losses in fidelity.

This is an even worse problem for patients and consumers. Without an IT department to programmatically smooth out the differences between various systems’ data feeds, they’re left with no option but to leave their data unaggregated in different, siloed system and applications.

The Path Forward

In spite of today’s gaps, there is tremendous cause for optimism, because improvements are being made on several fronts.

1. Standards development organizations, such as HL7, IHE, and the Center for Medical Interoperability, are refining existing standards and creating new ones to meet the demands of new data interchange patterns.
2. Legislation and regulations, like TEFCA, and the proposed rules from CMS and ONC, are defining the common ground that all interoperability participants can rely on.
3. Vendors continue to innovate and solve new problems as they emerge from technological evolution. An emphasis on modular components connected through APIs will enable a new generation of data-sharing applications.

Conclusion

Today’s interoperability landscape is replete with gaps, challenges, and discontinuities. This is unquestionably frustrating, but it is, in fact, a sign of progress. As the healthcare interoperability landscape broadens and begins moving data at different scales, we are inevitably encountering new challenges even as we surmount old ones. Today’s interoperability gaps are a symptom that we’re achieving a higher level of sophistication, and as big as our challenges seem today, they’ll look trivial in a few years when we’ve reached an even higher level.

[1] Diagram Represents Rhapsody’s Interpretation of Procuring Interoperability: Achieving High-Quality, Connected, and Person-Centered Care
https://nam.edu/procuring-interoperability-achieving-high-quality-connected-and-person-centered-care/