Defining An Open Platform for Health IT

Ewan DavisIt 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. This blog aims to answer the first question and to provide some guidance on the second.

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.

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 [email protected]