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

 

2 thoughts on “Defining an Open Platform”

  1. Hi Ewan,

    Your latest blog provides one perspective on what an open platform is and how to achieve this, but I believe that you are conflating a number of ‘open’ concepts, namely open source, open APIs, and open data. There is not one recognised definition of ‘open platform’, partly because the word ‘open’ is so ambiguous in the English language. This is why we often have to borrow a term from the French – ‘libre’ – which, when translated, is closer to the English word ‘freedom’.

    A libre platform really means one where the user has the freedom to use it at as they wish without restriction and for whatever purpose. It is often open source but this is not a requirement. In order for a platform to be used openly, it must expose application programming interfaces (APIs) that provide functionality that developers of software applications can build on unrestrictedly. Where those APIs adhere to accepted open standards, the applications are portable across multiple instances of the open platform.

    That said, two platforms offering the same APIs do not have to have identical internal structures, providing they look the same and behave the same way from the outside. Internally, the vendor could implement the platform in whatever way they wish, without reference to any standards, open or otherwise. Similarly, if the information that is presented via an API is structured correctly and is logically consistent, then the internal information model is somewhat irrelevant. The important question that needs to be considered is – does it pass the duck test*?

    The blog argues that an open platform has to be “federeratable”. This is a nice concept and a desirable feature, but I do not believe that it is a requirement for an open platform. An open platform that doesn’t talk to its neighbours isn’t a reflection of the restriction on its openness nor does it take away any of the freedoms to use the platform’s services.

    We do however agree on some points, in particular that an open platform has to offer open APIs, and applications written for one implementation of the platform should be easily portable to other implementations.

    openEHR certainly fits with my definition of an open platform. However, so do other health information platforms; if they provide open APIs and a freedom to use the platform without restriction then they too are open platforms. The most important considerations for the NHS are whether the platform is scalable, robust, supports the NHS data model and information requirements, as well as allowing anyone to build their own applications/solutions/products leveraging the open APIs implemented in the platform. It is about promoting an ecosystem that allows a community to build upon the existing open platform, by developing new functionality or enhancing existing functionality. It’s not about the provider of the platform.

    * If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Leave a Reply

Your email address will not be published. Required fields are marked *