Guest post by Ruby Raley, Director, Healthcare Solutions, Axway.
Farzad Mostashari, the national coordinator for health information technology (HIT), wants software vendors to enable and ease interoperability.
Meaningful use Stage 2 expects providers to be able to exchange data with other EHRs.
The CommonWell Health Alliance — a collaboration of executives from Cerner, McKesson, Allscripts, athenahealth, Greenway, and RelayHealth — aims “to push the needle on interoperability . . . to enable care integration and data liquidity.”
So does that mean that the silos that inhibit interoperability are about to come tumbling down?
No. Not at all. In fact, I believe we have a long way to go before that comes to pass.
For context, let’s review the two ways interoperability works:
- The point-to-point, or asynchronous (pull) method. A sender transmits an item to a recipient via a secure channel, which provides non-repudiation and ensures the item isn’t altered during its journey.
- The conversational, or synchronous-with-discovery-services (push) method. These systems use enterprise-service buses and complex interaction patterns to enable conversations between parties who haven’t exchanged information before. An inquirer enters criteria, like a patient’s demographics, and receives results, like a list of practitioners who have seen a similar patient. The inquirer then sends a request for that similar patient’s records, a conversational cycle ensues, and the patient’s records are imported into the inquirer’s system.
The pull method requires all parties involved to have a level of sophistication that supports a 24/7 real-time conversational exchange of information. But despite all the incentives for investment in interoperability, many of our healthcare partners still don’t have the ability to support this type of transaction.
We shouldn’t expect:
- Our healthcare partners to achieve real-time conversations anytime soon, as it won’t be cost effective for them.
- Our vendors to achieve real-time conversations anytime soon, either, as they don’t have any incentive to achieve interoperability, and many believe that only a handful of large-scale players need to interoperate in a given healthcare community, anyway. (That latter point is only accurate in acute care, however, and not in, for example, ambulatory care, where a completely different set of players needs to interoperate.)
- Anyone to voluntarily adopt a standard way to communicate, i.e. semantics. (When a sender enters a value into a field [e.g., a patient’s weight], semantics determines what that value is [e.g., pounds or kilograms]. When a doctor receives laboratory test results, semantics identifies whether a value of “high” or “low” means the same thing to the doctor as it does to the laboratory. )
Still, without all of these expectations — without aligning our policies with our communities’ actual capabilities, rather than their ideal capabilities; without ensuring our vendors can support those capabilities; and without establishing a standard way to communicate — we will never have anything close to interoperability. So how do we build systems that facilitate interoperability and, as Mostashari insists, make them easy to use?
Do we turn to standards?
Probably not. Standards like IHE, HL7 and EDI were all meant to simplify communication, yet most practitioners feel they’re still too complex.
Do we use the ONC’s direct model, which calls for expensive, federally certified bridge certificates, discovery areas, physician-certificate registries, and registry-onboarding processes?
No. That’s also too complex.
I believe we need to find something simple, something with security features that are good enough, rather than the best possible. We need to come up with simple semantics that, quite frankly, don’t require a user to have a PhD in XML.
We need to abandon discovery and turn to something like an integration hub, a “well-established communications paradigm that allows any number of publishers to communicate with any number of subscribers asynchronously via an event channel.” We need to know which patient is being seen by which primary-care physician so that patient stakeholders (e.g., a doctor who needs to know that their patient has been discharged) can use intelligent routing to be apprised of status updates.
By using these older techniques — some of which were pioneered as far back as the 80s — we can begin to address the interoperability challenges of the 21st century in a realistic, cost-effective way.
It’s wrong to insist that all providers come online. It’s wrong to push them to learn how to use enterprise-service buses or real-time communications. It’s wrong to expect them to have the ability to unencrypt a physician’s digital e-signature from an organization they don’t know. It simply expects too much from the healthcare community’s current maturity level.
Instead, let’s step back, set up standard communications, hone our ability to notify stakeholders promptly, implement methods for sharing the most-wanted health documents electronically, get to the point where we can actually provide discovery services, and give all stakeholders the ability to find out what they need to know about their patient.
Admittedly, these goals may be a bridge too far for HIT this year. The silos aren’t coming down anytime soon, and no one is going to voluntarily adopt a higher level of technology when there is literally no cost benefit to it.
But in the coming years, I’m certain these goals could be well within our reach. The decisions we make today will determine whether the bridge is still too far by the dawn of the next decade, or if it’s a bridge far behind us that we remember crossing months, or perhaps even years, earlier.
Ruby Raley is Director of Healthcare Solutions at Axway. With more than 20 years of experience, Raley collaborates with prospects and customers to develop value-added solutions for healthcare and life sciences. She enables pharmaceutical manufacturers, distributors, healthcare providers, healthcare exchange, and health plans to meet regulatory requirements while strengthening their IT infrastructure.