Barriers to EHR Interoperability Are Contractual and Cost

The barriers to EHR interoperability are not just technical. They are contractual and cost, as well.  I’m speaking as a first-hand source of knowledge about this, as a healthcare CIO.

EHR vendors who enjoy the benefit of our tax dollars under the HITECH act are preventing interoperability-- and innovation around the edges of their EHR products by third party developers-- by placing limitations and restrictions in their contracts with clients. The vendors who are engaged in this type of exclusive behavior can point to their technology and say, "See? We can share data. We follow data sharing technical standards. Quit criticizing us." But when you look into these vendors’ contracts, the license fees associated with interoperability are cost prohibitive, and the interoperability clauses are surrounded by onerous contractual obstacles that are veiled to protect the vendors' intellectual property, yet are actually ensuring the vendors' continued stranglehold on data and preventing innovation around their products.

This behavior on the part of some EHR vendors is strikingly ironic, given the enormous success of open source, easily accessible APIs that benefit interoperability.  The more open your products are, from a software architecture perspective, the more value you accrete to your products’ intellectual property.  Open, transparent APIs create a greater dependence and ecosystem around your products, not less.

Several years ago, I sponsored a meeting with senior executives from four large EHR vendors, lobbying them to open their APIs and migrate their software engineering architecture from tightly coupled, difficult-to-modify-and-upgrade, message oriented architectures; to loosely coupled, flexible, services oriented architectures (SOA) with open, published APIs, so that my engineering teams could write innovative products around the edges of these EHR products.  We even sketched the architecture of an SOA-based EHR, along with about 20 core services-- it was easy; it is not rocket science. Within 18 months after those meetings, three of the four vendors launched formal initiatives in their companies to create more open, friendly APIs, both technically and contractually, and they’ve stayed the course.

I will never forget the response from the fourth of those EHR senior executives.  That person said, “We see ourselves as more than a database vendor.”  Meaning, of course, “Our closed APIs are a market and proprietary advantage.”  Bill Gates and Microsoft used to think the same thing about Windows, Office, and Internet Explorer.  You can see how that worked out for them when you compare what’s happened with the openness of Android, iOS, the browser market, and office suite products; and you can also see Microsoft’s amazing pivot towards open architectures and interoperability in the last few years.  SalesForce.com is the supreme example of business success based upon an open API and open culture.

One of my current colleagues, who has been deeply involved in the interoperability environment for many years, described his thoughts in an email to me, summarized below:

Current “Interoperability” standards, selected by the ONC and required by MU-S2 do not contain an adequate amount of data/data types to support the quality measurement requirements of the same MU-S2 program. This gap in data is what enables the EHR suppliers to continue the veil of “interoperability” while still protecting their proprietary intellectual property, serving the interests of the owners of these companies with little regard to what may be best for care, providers, patients or consumers.

Several EHR vendors are banning together around a new magic bullet technical standard called HL7-FHIR based on JASON technology.  While this new standard is great from a technical perspective (XML, REST, etc.), in its current form, based largely on existing HL7 v2, v3 and CDA concepts, it does NOT improve the accessibility of proprietary EHR data types, and those data types are needed for quality and cost performance improvement in healthcare.  While FHIR could be expanded to include this type of data, it appears the first efforts are focused on reinventing the technology for currently defined interoperability data types.

I’m not sure what, if anything, Congress can do at this point to fix the ills of Meaningful Use Stage 1, which, in effect, rewarded existing vendors with billions of dollars in tax money to maintain those vendors’ closed and proprietary APIs.  Decertification by ONC will become a bureaucratic mess, but I appreciate the symbolic stance taken by Congress around decertification, nonetheless. One thing that must happen—and maybe our legal courts are the only option for this—the contractual threats and cost barriers in EHR vendor contracts that stand in the way of interoperability and innovation must be removed.

Interoperability and innovation in healthcare IT are suffering, both technically and contractually, by old-fashioned, old-school thinking on the part of some EHR vendors.

And, as an outcome, our healthcare system and patient care are suffering, too. We can do better as a country, and the EHR vendors can actually profit from being more open, not suffer.