Readers Write: The Many Flavors of Interoperability

The Many Flavors of Interoperability
By Niko Skievaski

As the shift towards value-based care persists, the demand for data is as hot as ever. That means the term “interoperability” will be thrown around a lot this year. Let’s describe the various flavors in which it will inevitably be discussed. I’ve seen many conversations become confused as the context for the buzzword is mixed. Here’s an attempt at outlining the various i14y use cases. (Can we start abbreviating it like we do i18n?)

Interoperability for Care Continuity

This is the iconic use case that first comes to mind. Chronically ill patients with binders full of paper records and Ziplocs bulging with pill bottles. As patients bounce around town seeing specialists, they often need to repeat demographic data, med lists, allergies, problems, diagnoses, prior treatment, etc. The solution to this use case calls for ad hoc access to a patient’s data at the point of care. A provider’s chart doesn’t necessarily need to be synced to all other providers in the disjointed care team. Rather, the data needs to be available upon request from the relevant provider.

New payment models have fueled demand for this solution. In a fee-for-service world, redundant tests actually brought more income to the health system,  whereas in value-based models, excessive costs are eaten by the organization. This aligns the provider and patient by incentivizing only the tests and treatments that have the highest likelihood of impacting the patient’s health. Understanding the value of any given treatment also requires looking across a wide set of patients. This brings us to the second use case.

Interoperability to Measure Value

In order to understand how to pay for healthcare based on value, we must make an attempt to measure the impacts to health: a patient’s health is a function of the healthcare they receive as well as a slew of other variables. Estimating this relationship requires a magnitude more data than we’ve traditionally measured. Beyond knowing the diagnosis and treatment, we’d need to control for behavior, family history, comorbidities, prior treatments, etc. Basically everything we can know about a patient’s health. And that’s for a single patient. To build a model, we’d need this information from a large sample of patients to determine the impact of each of these variables. But as treatments are provided to patients and we receive more results, we’ll need to be updating our models to refine their accuracy over time.

Much of this data is stored in an electronic health record over the time period a patient was cared for by that health system. But it’s likely missing data from care outside of that health system. And beyond that patient, how could we combine this record with a sizable population to make a predictive (or even representative) model? Even at very large health systems, limiting their records down to the few who have a rare diagnosis for a given sex and age, the sample set can become insignificantly small.

This i14y use case requires large sets of longitudinal data, rather than single patient records in an ad hoc query. Current attempts at producing such data sets have been extremely resource intensive and normally centered around research efforts focused on a single diagnosis in a de-identified manner. We’ve also seen rampant consolidation in the industry, partially driven by the notion that taking care of larger and larger populations of patients will enable more accurate estimations of value.

Interoperability to Streamline Workflows

This i14y use case has been around since before the term garnered widespread adoption in healthcare. HL7 was created back in 1987 to develop a standard by which health data could be exchanged between the various systems deployed at a health system: electronic health records, lab information systems, radiology information systems, various devices, and pretty much everything else deployed in data center. These systems are most often tied to a centralized interface engine that acts as a translation and filtering tool bouncing transactional messages between each.

So problem solved, right? Not quite. Over the past few decades, health systems have customized their HL7 deployments just as isolated communities evolve a language into a dialect. This proves problematic as each new software application adopted by the health system requires extensive interface configuration and the precious FTE that entails. Interface teams are increasingly the most backlogged tranche of the IT department. As health systems search for more efficient ways to deliver care, they’re more often turning to cloud-based software applications because of the dramatically reduced infrastructure costs and mobility.

This use case likely requires upgraded infrastructure that allows a health system to efficiently connect with and communicate with cloud applications. The customized HL7 dialects will need to be replaced or translated into something consistent and usable for cloud applications. HL7, the organization, is currently developing FHIR as a much needed facelift to a graying standard. In the coming years we look forward to seeing more FHIR adoption in the industry, and hope to avoid the level of customization we have seen with HL7v2 — although initial feedback and documentation from EHR vendors is not promising.

Interoperability to Engage Patients

This is likely the most interesting need for i14y because of its potential. Patients don’t currently walk into doctor’s office and demand that their health data be electronically sent to applications of their choosing. But then again, where are these applications? The inability for patients to authorize API access to their health data has undoubtedly stifled the development of innovative applications. Instead, new application creation has focused on the B2B space in search of enterprise revenue.

If a patient could download an app on their phone and authorize it to pull their medical history, an army of coders would mobilize in creating apps to engage patients as consumers. Application adoption would be holistically democratized and new apps would get to market instantaneously, as opposed to the usual 18-month B2B sales cycles. Applications would be developed to help patients decipher the complexities of care, track care plans and medication adherence, and benchmark against others with similar comorbidities. They could effortlessly download and store their records and be the source of truth. They could contribute their records to research banks that would be willing to pay for their use. Widespread adoption of patient authorized access to health data would almost make the other i14y use cases moot.

Luckily, we’re getting closer. There’s mention of its mandate in MU3. One of the challenges is solving for the chicken-or-egg problem. We need enough widespread adoption of a single authentication framework and data standard to simultaneously sway the development community and health systems to adopt. MU3 seeks to force the right hand side of that equation, however failing to mandate a prescriptive framework or standard in its current draft while wavering in its timeline. As written, it’s possible that health systems can comply with differing technology making the problem only slightly better.

I’m optimistic as accelerating demand has spurred i14y innovation across the sector. HL7 is rapidly organizing support around FHIR and SMART. Incumbent integration engines are stepping up their game and outside integrators are rapidly moving into healthcare. Startups are sprouting to tackle pieces. Some health systems are proactively standing up their own i14y strategies. EHR vendors are vowing to adopt standards and roll out tools to encourage application development. I don’t doubt that we’re beginning to see the fruits of the solutions that will be adopted in the years to come. But it’s on us — as providers, technologists, developers, and patients — to continue the rally cry by demanding i14y now.

Niko Skievaski is  co-founder of Redox.