Hiding the Onions – Interop and Open Platforms


With 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 architecure 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 recognise 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 qou 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 authorised 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 organisation 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 peusdo-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 authorised 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 recognise 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.

Stuffed Turkey
By No machine-readable author provided. Chensiyuan assumed (based on copyright claims). – No machine-readable source provided. Own work assumed (based on copyright claims)., CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1491125

Defining an Open Platform


It is widely agreed that the future of digital health lies in an “Open Platform”. However, it’s not clear as to exactly what an Open Platform is or how we get there. With McKinsey tell us that health care systems that create an open platform can save more than 11% of total health care cost this is a question we urgently need to answer

“…….each national or federal health system should consider an open innovation platform that holds healthcare data ……………., and provides data access that is enabled for application programming interfaces as well as common technical IT services such as identity, access, or consent management. This platform would serve as the basis for an ecosystem of digital-health-services innovation……”

“In 2014, we did considerable research into the economic value of digital technologies in healthcare and found ……..  net economic benefits of 7 to 11 percent of total healthcare spending. Over this past year, our work on the ground has confirmed this original analysis. However …………  we believe an even greater impact can be achieved through coordinated joint effort. This would involve the interconnection of all digital-health stakeholders through an open innovation platform.”

McKinsey and Co., Jan 2016

This blog is an attempt to do so on which feedback from others would be welcomed..

While any given instance of an Open Platform will be a specific implementation of a set of software components owned and operated by a particular organisation (this might be a health and social care organisation or a third party, operating the platform on behalf of a local health and care community), it is most usefully defined by a set of principles rather than the specific details of a particular implementation.

Open Platform Principles

Any platform implementation that is truly to meet the definition of being ‘open’ should comply with the following principles:

  • Be Open Standards Based – The implementation is based on open standards which any willing party can use, free of charge, to build an instance of the Open Platform – what these standards are will be described later in this article.
  • Share Common Information Models – There should be a set of common information models used by all instances of the Open Platform, independent of the specific technical details of a particular implementation.
  • Support Application Portability – Applications written to run on one implementation of the Open Platform can run with little or no change on another independently developed implementation.
  • Be Federateable – Any implementation of the Open Platform can be connected with all other independently developed implementations in a federated structure  to allow the sharing of appropriate information and workflows between them.
  • Be Vendor and Technology Neutral While those building an implementation of the Open Platform will chose particular technologies and may choose to use or include proprietary components, the standards should not depend on particular technologies or require components from particular vendors.
  • Support Open Data – An implementation of the Open Platform can expose all of the data it contains in an open, shareable, computable format in near real-time; it is for implementors to decide if they choose to use this format natively in their persistence (storage) layer of the Open Platform, or meet this requirement by means of mappings and transformation from some other open or proprietary format.
  • Provide Open APIs – APIs are the means by which applications connected to the Open Platform are able to access and update the data it contains. There are a number of available open APIs (see below) and ideally any platform should support a number of these to give the maximum flexibility for applications that wish to connect to it.

Open Platform Standards

Meeting these characteristics implies the use of certain approaches and the adoption of certain standards. However, it is important to understand that by its very nature an open platform, just as with the Internet, is not something that can be rigidly defined and indeed is something that will continually evolve. There are multiple ways to build an open platform and for these to work together we don’t need and can’t have rigorous standardisation; we need just enough of a common approach to make things work. This approach is different to that historically adopted in NHS IT, but it is the model on which the Internet and World Wide Web were built and have succeeded. See these two pieces on my blog here and here.

At the core of an open platform is the need for common information models, which define the clinical content (information) to be represented on the platform and which provide a sharable, open and computable format for that information. Currently there are only two approaches that have current support from the global health informatics community.  These are the Clinical Element Models (CEMs) and openEHR. They adopt very similar approaches, coordinated through the CIMI initiative. In the NHS, the HSCIC has chosen to use openEHR; which is the model that has achieved the most widespread global acceptance and use.

Information models, such as those created by openEHR can be used natively in the persistence (storage) and messaging components of the platform or be used simply to inform the design of these components using either another open standard such as HL7 FHIR, XML, JSON, or by using proprietary approaches. The critical point is that  an open platform can produce and consume data in a form compatible with the standard information models. It is for the designers of the platform to decide how to do this, but I would expect those building from scratch to use openEHR natively in the persistence layer and those adapting existing systems to converge their internal representation on these standards over time.

Open Platform Architecture

The architecture of an open platform will evolve over time and it is likely that different implementations of the platform will vary in the detail of the architecture and the particular components included. What’s important is not that different implementations are identical, but that they comply with the principles described above. The diagram below proposes a possible architecture. Any open platform of this kind is likely to have similar components, arrayed in a functionally equivalent architecture and to implement a similar set of standards.

Open Platform Architecture

The heart of the platform is an Enterprise Service Bus (ESB) which links the components together and provides authentication along with the management of the Application Programming Interfaces (APIs), which serve both platform components or services and external systems connected to the platform.

Core components of the platform include:

  • repositories for both structured and unstructured data (documents, images, etc);
  • a Master Patient Index (MPI) and Registry which stores basic demographic data and provides a locator service to help find where the records for a particular patient are held (e.g. on the platform, elsewhere in the local health community or on other federated platforms);
  • knowledge services that provide access to knowledge (particularly workflows, processes and decision support);
  • a range of external connectors which allow applications on the platform to connect to existing systems relevant to the local health community including other local systems and national services (such as NHS Spine);
  • a range of platform services, none of which are essential, but which, if available, remove the burden of dealing with the functions they support from application developers. These might include:
    • terminology services;
    • identity management;
    • consent management; and,
    • access control (role based access (RBAC) legitimate relationships (LRs) and workgroups.
  • Connectors and federation services to other platforms to allow platforms to be connected in a federated web allowing an authorised user to discover and access any relevant data in any location.

It is my strong view that the right choice for a structured data repository is openEHR and the right choice for the unstructured data store is IHE-XDS. (IHE-XDS also provides a suitable option for the registry). Both of these open standards are well supported by vendors with a number of proven proprietary implementations and emerging open source options. However, there are alternative approaches that could comply with the principles described above.

I don’t have fixed views with regard to the best approach with regard to the knowledge repository, but the work of Synapta to draw together a number of available standards including BPMN 2.0, GDL, CMMN, Drools and PROforma looks promising.

Examples of Open Platforms

There are a number of examples of open platforms that adhere to the principles outlined here and a number of people working to create more.

Established platforms that include both openEHR and IHE-XDS, working together include Moscow City support health and social care for 12 million patients and Slovenia support the entire population of 2 million. There are many more examples based on one or other of these standards that could easily be extended to do the same, including a number of UK projects.

There are also a number of other projects in the UK working together to refine the definition of an open platform and build implementations these include.

  • NHS England Code4Health This is based on my work with Dr Ian McNicoll for HANDI. The Code4Health Platform provides a simulated environment where people can explore open platform concepts and APIs and build applications to test their ideas.
  • Ripple who have an operational open platform based on openEHR in Leeds.
  • The Endeavour Health Charity who are building a platform using HL7 FHIR and a number of connectors to legacy systems.
  • Operon who are developing Synapta to provide components to support open workflow standards including BPMN 2.0, GDL, CMMN, Drools and PROforma

All of these projects are working together coordinated by the Apperta Foundation  (a clinically led not-for-profit company established with initial grant aid from NHS England) and are already committed to using a common set of information models created using the openEHR tools. The aim is to agree a common set of standards and components which will enable them to build implementations of open platforms which comply with the principles here. Each implementation will be different, enabling us to learn what works best, but similar enough to enable federation and interoperability.

We are actively talking to a number of projects in the pipeline and some other existing projects already using one or more of the core standards described here, so we expect to see many more open platforms complying with the principles outlined here. If you like to join us get in touch ewan@woodcote-consulting.com