Application Programming Interfaces are up for discussion today, is this the future of interoperability with medical records? Anyone in the HIT/EHR business today can pretty much attest to the complexities that have evolved and is there anything or anyone to fault? Not really it is just the way it happened.
Do we have to continue to travel down the same road? Not really, there are ways to change some of this and think outside the box, but that is not a cakewalk either. What is the value of open source with connecting medical records systems and how can such a partnership work with commercial vendors? Dr. Billings today explores this topic with his latest blog post and brings about the discussion of APIs, and will healthcare follow the rest of the business verticals some day?
Anyone who understands the importance of continuity of care knows that health information exchange is essential. How are we supposed to cut waste and duplication from the healthcare system and truly focus on patient welfare if doctor B has no idea what tests doctor A conducted, or what the results were?
The predominant proprietary HIT vendors know this, yet have engaged in prolonged foot-dragging on interoperability and even basic data interfacing. Yes healthcare IT is their business, but interoperability is not in their nature.
As we’ve seen before, the problem is with the business model.
The proprietary business model makes the vendor the single source of HIT for hospital clients. Complexity and dependence are baked into both solutions and client relationships, creating a “vendor lock” scenario in which changing systems seems almost inconceivable.
In the proprietary world, interfacing with third-party products is a revenue generation strategy and technical challenge; the latter, though unnecessary, justifies the former. When we go looking for the reasons that healthcare is a laggard compared with other industries, this single-source model—the obstacle to much-needed competition and innovation—is a primary culprit.
To be fair, provider organizations, with little if any incentive to exchange patient data before the advent of Meaningful Use, haven’t shown much collaborative spirit either. In the fee-for-service model, why would a healthcare organization let patients slip from their grasp? Health reform is finally mandating needed change, but when will proprietary vendors actually enable the interoperability hospitals and practices soon have to demonstrate?
Recent rumblings from Washington, DC, suggest the feds are losing patience.
“If we do not see sufficient progress or … our policy goals for standards-based exchange are not being met, we will revisit these more specific measurement limitations and consider other policies to strengthen the interoperability requirements…,” Farzad Mostashari, National Coordinator for Health IT, said last week at the 2013 Academy Health National Health Policy Conference. “I want there to be no question about the seriousness of our intent on this issue. [The] bottom line is it’s what’s right for the patient and it’s what we have to do as a country to get to better healthcare and lower costs.”
Even before Mostashari’s comments made the news, rumors were flying of Cerner and McKesson working on an agreement to make their EHRs “interoperable”. Framed as a technical development in the world of health IT, the potential Cerner/McKesson agreement is nothing more than a business decision—an attempted differentiator—driven by the success of Epic.
In fact, the technical interfaces and open standards are well established. There is no great technical interoperability challenge that requires the coordinated efforts of two industry heavyweights. We should recognize Cerner and McKesson for making tentative steps toward openness, but casting this as some kind of technical breakthrough does nothing to advance the cause.
Indeed, when Cerner CEO Neil Patterson recently told a joint public hearing organized by the Office of the National Coordinator that “no single vendor” can meet all the needs of a provider, he was talking about Epic.
“Cerner is … committed to an open healthcare ecosystem… to enabling data liquidity for every product … to enabling our solutions to send and receive data in a universal manner … to putting these principals to work for every system in every venue of care.”
In other words, Cerner is willing to do everything Epic is not.
Again, while the commitment to data exchange is progress, we are still just talking about exchanging data, not true interoperability. Let’s look at a couple of definitions.
From the Institute of Electrical and Electronics Engineers (IEEE) Glossary definition on Wikipedia:
The ability of two or more systems or components to exchange information and to use the information that has been exchanged.
So narrowly tailored, this concept might be better defined as “interface-ability” or simply data exchange. And it completely lacks context, which matters a lot to those of us in health IT. There is no mention of the technical challenge and costs. There is no concept of separate systems operating together, which is requisite. And there is no mention of the alternatives.
Compare that with another interoperability definition found on Wikipedia:
Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation.
This definition, much closer to genuine interoperability, is arguably what Kenneth Mandl and Isaac Kohane of Harvard Medical School had in mind in 2011 when they published “Escaping the EHR Trap – The Future of Health IT” in the New England Journal of Medicine:
“We believe that EHR vendors propagate the myth that health IT is qualitatively different from industrial and consumer products in order to protect their prices and market share and block new entrants…”
Speaking to InformationWeek later on, Kohane went further and named names:
“Leading companies like Epic will claim that it’s unsafe for health IT to be done outside their monolithic system and that their monolithic system is actually enabling patient safety and the correct conduct of healthcare process.”
Mandle and Kohane describe an interoperability that goes beyond mere interfaces and data exchange. Indeed, the fulcrum of this advanced interoperability is open application programming interfaces (APIs), which enable applications to quickly, easily and affordably integrate with the core EHR. Think of all those iPhone apps in the iTunes store and then recall that Apple doesn’t even make open systems.
Right now open APIs are most frequently associated with the Web and work being done by companies like Facebook, Google, Salesforce and LinkedIn, which might seem irrelevant but is anything but. True interoperability in healthcare will result from tightly secured Web-based applications that enable a circle of accountable clinicians to work together with optimal patient health—not a billable test or procedure—as the ultimate goal. Does that sound like something simple data exchange can accomplish?
Policy and industry dynamics are moving toward data exchange, which is merely a precursor to a new healthcare business model and a safer health system with lower costs and better quality. As the paradigm shifts, we will follow other industries and move from interfaces to interoperability and real collaborative care. And we’ll recognize that open APIs eliminate the obstacles to interoperability that stifle competition and innovation.
Edmund Billings, MD, is chief medical officer of Medsphere Systems Corporation, the developer of the OpenVista electronic health record.