Achieving true interoperability likely requires healthcare providers to take key steps to addressing limitations in the connectivity of their health IT infrastructure.

January 31, 2017 - With the goal of achieving a learning health system enabled by true interoperability, various healthcare organizations and companies have undertaken efforts to unlock clinical data stored in various health IT systems with mixed results.

According to one health IT company looking to make its mark in the industry, the problem of limited healthcare interoperability stems from understanding where and how connections between health IT systems need to take place.

“Today, there are hundreds of technology solutions on the market attempting to solve these problems. The current class of interoperability solutions attempt to connect these software solutions directly to the health system’s legacy electronic health record,” wrote Redox Co-founder and President Niko Skievaski in a recent blog published by Milwaukee Journal Sentinel.

Dig Deeper

“This is where we’ve built our current business model,” he continued. “The applications we connect are chosen strategically by healthcare leadership. The goal for the apps and health systems we connect are to transmit data from A to B. They don’t care that we do this through a centralized network.”

According to Skievaski, a key building block for achieving true interoperability is networked interoperability. Rather than making the health IT systems and services of individual health systems interoperate, the goal needs to be connecting them to a much larger network, “the same network using the same data models.”

The next step in the process requires healthcare organizations and providers to embrace innovation as a strategy, Skievaski argues. Even the earliest EHR adopters and users of application programming interfaces (APIs) have work to do.

“Some companies have sprouted up to provide the API management tools for IT teams to do this more efficiently,” he maintained. “But these solutions only reduce the effort for the IT team. The innovations still need to integrate with that specific health system’s API specs. This only brings incremental improvement to technology adoption.”

The task then becomes enable provider end-users to choose the applications that best suit their preferences and workflows:

As long as the data securely syncs up to the organizational source-of-truth, it only makes sense that an end user chooses the technology appropriate to support her unique workflow, preferences, and style. Akin to the bring-your-own-device movement, in some circumstances a bring-your-own-app model will start to take shape. In a simplified example, I choose to use a specific email and calendar app on my phone. But I’m still accessing the same managed email account as my peers who may use whatever apps they please to interact with it.

With the provider side enabled in such ways, the focus can then move to providing patients with the benefits of true interoperability, otherwise known as patient-centered interoperability.

“The common thread in any interoperability use case is the patient. She is the one moving between specialists, being admitted to the hospital, and attempting to engage in her care. As such, true interoperability will not be achieved until her clinical data follows her effortlessly. This is patient-centered interoperability and it’s sadly missing from the typical discussion in our industry,” observed Skievaski.

“It requires seamless connectivity of source and destination systems,” he continued. “Moreover, the patient will need to be able to authorize access to her data for whomever she deems necessary. Because of the way EHRs were deployed, this is currently impossible. Things need to be networked. Patients, and the applications they’ll use, need a single network to plug into retrieve and utilize clinical data.”