Readers Write: EHR Vendors: Barriers to Interoperability
EHR Vendors: Barriers to Interoperability
By King Coal
As patients and taxpayers, I encourage everyone to contact your Congressional members about this topic. Mention that the barriers to EHR interoperability are not just technical — they are contractual as well.
EHR vendors that 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 threats in their contracts with clients. The vendors who are engaged in this antitrust 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 at these vendors’ contracts, the license fees associated with interoperability are cost prohibitive. In addition, the interoperability clauses are surrounded by onerous contractual obstacles that are veiled to protect the vendors’ intellectual property, but are actually ensuring the vendors’ continued monopoly 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 products are from a software architecture perspective, the more value that accretes to a product’s intellectual property. Open, transparent APIs create a larger dependence and ecosystem around products, not less.
Several years ago, I sponsored a meeting with senior executives from three 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 with open, published APIs so that my development teams could write innovative products around the edges of these EHR products.
I will never forget the response from one of those EHR vendor’s senior executives: “We see ourselves as more than a database vendor.” Meaning, of course, “Our closed APIs are a market 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. Salesforce.com is the supreme example of business success based upon an open API and open culture.
A colleague described his thoughts in an email:
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 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 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 EHR vendors. As a consequence, our healthcare system and patient care are suffering, too.
It’s true that FHIR is largely based on existing v2, v3, and CDA concepts – it’s important to walk before you run.
As for “But when you look at these vendors’ contracts, the license fees associated with interoperability are cost prohibitive” – I don’t know what they are, but how do you know what would be reasonable? Interoperability itself is onerous.
Have you seen the limitations and threats in vendor contracts? You suggest that you’ve seen multiple, please provide an example.
Can you quantify the cost of the prohibitive license fees? Is it a cost per patient, per transaction, per API hit? And prohibitive for whom? Provider or third party?
I’m not going to run to my congressman about something I read from an anonymous guy on the internet without something objective to tell them.