Health IT Vendors Hiding the Onions from Interop and Open Platforms

Ewan DavisWith McKinsey telling us that open platforms can save more that 11% of total health care costs, we really have to sweep away the barriers and make it happen. This means moving to an open platform architecture meeting the principles I described in my last blog, which require open standards, open data and open APIs. While most in the vendor community understand this and some actively promote it for others asking them to open up their systems and data and adopt open standards is like asking the turkey’s to help make the stuffing – They might help you find the sage, but they are going to hide the onions.

Many existing vendors recognize the need to move open standards, open data and open interfaces (APIs) but while some are moving in the right direction, they are not there yet Others drag their feet knowing their current success relies on existing proprietary solutions, customer lock and their pseudo-ownership of customer data. Getting to the tipping point at which open platforms can really take off is going to require new players challenging the status quo and a willingness from the health and care community to help them successfully engage.

The objective is to move towards what is now being described as a Post Modern EHR this is an architecture that separates data (describing both record content and work-flows) from the applications that create and process it storing it in an open computable format available to all authorized applications.

There are almost certainly no vendors who think interoperability is a bad thing and this is exemplified by the techUK Interoperabity Charter, to which many vendors have signed up . While some have described this as “Motherhood and Apple Pie” in nonetheless contains some specific commitments and there is certainly no justification for any health or care organization to do business with companies that are not signatories (it is not necessary to be a member of techUK to sign up to the charter). Having signed the Charter should be a mandatory condition in the PQQ of any IT procurement in Health and Care.

However, vendors commitment to interoperability is not always what it seems and varies between companies and within companies depending on what particular aspect of interoperability at issue.

Most vendors are keen to facilitate interoperability that enhances the range and quality of data in their systems or which adds functionality that they don’t and and have no desire or ability to provide. Vendors are less keen to support interoperability that allows competitors products more easily to replace some or all of their system or which loosens their pseudo-ownership of their customers data – True interoperability does both of these things.

For a system to be fully interoperable the following needs to be true:

• It should be possible to access all of the data in a system in an open, shareable and computable format, either for an individual patient or any cohort of patients (include all patients). Interfaces should be provided to efficiently access data and where the customer wishes to maintain a near real-time replica of the data in a parallel system.
• It should be possible to upload to a system any data that could otherwise be manually entered into a system, subject to relevant user defined work-flows and quality assurance.
• All business functions that can be executed using a system should be exposed via an appropriate API to allow them to be executed by an authorized external application.

Looking at the API’s than vendors are now providing, few come close to meeting the criteria above. For some systems and to some extent there are real technical barriers to opening up systems and making the data they hold available in an open format, but there can also be pressing commercial reason for not opening up systems and it can be very difficult for customers to determine the extent to which vendors have genuine technical challenges to overcome or are simple looking for excuses to hang on the commercial benefits of limiting what can be done through their APIs.

Customers need to push vendors towards open platform architectures, open standards, open data and open APIs, but need to recognize that this transition cannot be achieved overnight and will require investment by vendors that will ultimately need to be paid for by customers. The trick is to link new business to an evolution to open standards without making unrealistic demands, that in the end you will have to allow vendors to ignore.

Vendors need to appreciate the value of open platforms and the commercial opportunities they bring. The increasing complexity of digital health means that I can foresee only two future options:

• The first based on open platforms creates opportunities for vendors, particularly innovative SMEs, to enter the market and compete with the larger players on a level playing field and forces vendors to compete on quality, performance, support and value rather than relying on customer lock-in and pseudo-ownership of customer data.
• The second is increasing market consolidation with a few very large vendors owning competing proprietary platforms, that allow access to other vendors on their terms with customers locked into their platform

The first option drives innovation and value, creating a competitive market for both the provision of federatable open platforms and the applications that run it. The second will result poor value and reduces both the opportunity and motivation for innovation and gives the platform provider too much influence in the way health and care services are provided.

There is a great future for vendors of all sizes in an open platform environment, which by delivering value to the health and care system, will result in market growth delivering greater revenue opportunities for those that can adapt their business models to take advantage – For those that can’t there always the cranberry sauce.