Tag Archives: Open Ecosystems

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


openEHR a Game Changer Comes of Age

I’ve been watching openEHR over more than fifteen years, and although I have always been impressed by its potential to enable us to do things differently, I must admit it has been a slow burn, and take up has been limited, particularly in the UK where it was invented. However, due to some recent developments, I think this is about to change, and that openEHR is going to take off in a big way. This is going to revolutionise how we think about and do digital health, and it should increase the speed at which we can do it by at least two orders of magnitude. Why do I say this, and what evidence is there to support my assertion?

openEHR has come of age with a large number of successful small implementations, and a few much larger ones (1) which have proven the approach works at scale. We have also seen the use of openEHR by governments and major health providers across the globe, including the NHS (2), as the mechanism for the creation and curation of clinical content standards in their territories. In addition, changes to the openEHR Foundation have made it unarguably an open source organisation with a global user community; a growing vendor community has developed offering both open source and proprietary tools and components supporting the standard; and there is serious interest from major system integrators. These changes make openEHR look like a much better alternative to the hegemony of the big US megasuite providers, who still want to shape health and care systems in their image and who own the platforms on which these providers will increasingly depend.

UPDATE (12 April 16)

Possibly the best explanation of openEHR I’ve seen “openEHR technical basics for HL7 and FHIR users” Well worth reading.

UPDATE (15 March 16)

Some great videos here which provide an easy way to understand various aspects of openEHR.

In particular:

Clinician-led e-health records – An introduction to openEHR for clinicians

National governance of openEHR archetypes in Norway – A national approach to building information models with openEHR. Many lessons here for HSCIC who have just started doing something similar here.

UPDATE (13 July 15)

In their PQQ which kicks of the procurement for the Datawell to support Devo Manch,  Manchester have mandated openEHR along with other established standards including IHE-XDS. This could potentially lead to the largest implementation of openEHR in the UK with Manchester building on pioneering work in Moscow and Leeds

UPDATE  (24 Apr 15) Further information and news about the growing interest in openEHR will be found here

Firstly, everything I read and all of the people I talk to across the globe about digital health agree on a couple of things.

  • Firstly, we need to move towards a platform architecture into which we can plug the thousands of apps and hundreds of traditional systems that we currently use in health and care; an architecture which will enable all of these to interoperate and work together.

  • Secondly, we need to separate content (the data, information and knowledge that applications consume and update) from the applications that process it; and that content needs to be expressed in a modular, computable and reusable format.

Beyond this, agreement breaks down – people do argue about business models (who should own and control the platform), and also the details of the particular standards and technology to be used – but on the core principles, everyone with any credibility agrees.

When it comes to business models, some would like to own the platform, because doing so would create a massive commercial opportunity. And while some still pursue this goal, most significantly Apple, others have decided, as I have, that ownership of the platform is neither achievable (competitive and customer pressures mean even the mighty Apple can’t win this battle) nor is it desirable from the perspective of citizens, health and care providers and payers – none of whom wish to be locked in or to pay the ‘fruit tax’ or its equivalent.

Others, including me, and more significantly some big players, have come to the view that while it might be great to own the platform, that isn’t going to happen and so we need to move to an open platform which nobody owns (in the sense that nobody owns the Internet). As for commercial opportunities, they will still exist higher up the value chain, and the existence of the platform will create such opportunities by the spadeful. Surely it’s more fruitful to concentrate on these, rather than waste time and resource on a battle no one can win.

On the details of implementation, disagreement is less significant. The two major contenders, openEHR and the Healthcare Consortium, both have similar approaches, and they are already converging through the Clinical Information Modeling Initiative (CIMI) to reduce their differences to the point where they really don’t matter and can be dealt with at a purely technical level, with their components being easily interchangeable.

So, if we want to create an open platform, what do we need? We need openEHR or something like it – and frankly there is nothing else as mature or as well supported as openEHR.

OpenEHR is not software, nor is it a particular technology. It’s an open specification or standard for the representation of a key bit of content – the health and care record. The specification is open source (insofar as you can apply this term to something that is not software), and it’s curated by the openEHR Foundation, which is a not-for-profit company democratically controlled by those who choose to be part of the global openEHR community (and anybody can). The community is truly global and growing, and consists of both users and developers; and is supported by a number of vendors who can offer tools, components and services supporting the standard.

openEHR provides a simple, robust and stable over-arching reference model (3) which defines a formalism for the representation of the modular components of a health and care record. openEHR calls these ‘archetypes’ and they define the elements of a record, their properties, and how they are represented (including bindings to terminologies and classifications). Archetypes are intended to represent a superset of all those properties that might be associated with the concept they represent (at a high level these will be either an observation, an evaluation, an instruction or an action). Archetypes can then be constrained and/or combined in a ‘template’ to provide practical interoperable components for use in a particular context or system.

The tools available for the creation of archetypes and templates are open source (as are the vast majority of the archetypes and templates created with them), and this makes openEHR easily accessible to clinicians and other domain experts while also providing system developers with robust components to handle many of the technical complexities. openEHR enables clinicians to concentrate of the clinical stuff, and developers to concentrate on the technical stuff, without needed to understand more about the other domain than they want to.

By building systems using openEHR, system development work shifts from the technical level to the domain level. A repository that has been built to store an openEHR health and care record does not need to take account of the particular content of a given archetype. Whatever that archetype might represent, the repository will be able to store it, and you will be able to query that repository about its content. This feature of openEHR is the key enabler of much faster application development, because the addition of new features will not require changes to database schemas (with all the associated testing and data migration that entails). Instead, all that is needed is the addition of some archetypes and/or templates – and these may already be available as the result of work by others in the community, or else they can be created rapidly by a relevant domain expert – plus the creation of some new user interface components, and these can often be generated automatically from the underlying templates. In this way changes can be made by end users, or by people close to them. This will reduce the time to add new features from months to hours, and the time to build new systems from years to weeks.

openEHR is also technology independent. Applications don’t need to concern themselves with the technology of a particular implementation of an openEHR repository – that’s purely a matter for the implementer, who can chose whatever technology works best for them at a particular time and in a particular context. The applications that use it will not be affected, so long as they remain compliant with the standard. We can see this happening in the dozen or so existing implementations of openEHR repositories: they use different operating systems, different databases (SQL and NOSQL) and various development tools to create both open source and proprietary implementations of the standard. Compliant implementations of the standard from different vendors are interchangeable, and a single query can be executed across multiple implementations. openEHR is vendor independent, and it eliminates vendor lock-in.

Suppliers of openEHR repositories will have to compete on performance, security, robustness, value and service – they cannot rely on customer lock-in, as the vendors of many traditional EHR systems have in the past. From the perspective of health and care providers, openEHR puts them back in charge of their own destiny. This contrasts with most of the current successful approaches to the delivery of enterprise-wide EHR, where customer institutions have adopted one of the four big US megasuites, and then have had to adapt internal processes and organisation to fit with the chosen system – in effect, you become an EPIC, Cerner, Allscripts or Meditech institution, rather than a customer who calls the shots.

The ‘megasuite model’ has worked spectacularly well (if expensively) in a number of big US hospitals, particularly for EPIC, but that model starts to break down when you seek to extend the scope of a system from an institution to an integrated health and care community. It also fits badly with UK and other European models of health and care, which are not so close to the US model as the megasuite vendors might hope them to be.

Of course European health and care providers don’t want to remodel their processes along American lines – why would relatively successful European providers want to adopt systems designed primarily for the inequitable and unsustainable US system? According to the well respected US Commonwealth Foundation the United States ranks last among eleven leading developed countries on measures of access, equity, quality, efficiency, and healthy lives (and, by the way, the UK’s NHS takes the number one spot).

Much of my conviction about openEHR comes from work I’ve been involved in with HANDI, in building HANDI-HOPD – the HANDI Open Platform Demonstrator, which has now been adopted by NHS England as the NHS England Code4Health Platform. This platform provides a simulation environment for any system or service that wants to expose an API (interface) within an open ecosystem, and it includes an openEHR repository loaded with test data from the Leeds Lab Project.

We have exposed SMART and FHIR APIs, as well as the native openEHR service API, on top of the repository; we have used this to build a number of apps, and also demonstrated how you can simply plug in apps that were developed elsewhere using the SMART API. We have also used this platform to prototype a UK localisation of an open source ePrescribing product (www.openep.org), and the speed at which we have been able to carry out the localisation and meet some special mental health requirements has been impressive – indeed so impressive that we will shortly be announcing the first NHS Trusts who will be taking the system live.

Work is currently being completed to re-brand the HANDI platform as the NHS Code4Health Platform, and this will shortly be available for those who want to learn more and experiment with this and other open technologies.

openEHR has come of age – If you don’t believe, me give it a try.


This is a slightly updated version of the original with a few minor changes to make it more readable to the general reader and correct some typos my thanks for this to my friend and colleague Conrad Taylor.

1) Large scale implementations of openEHR include:

Moscow – Integrated health and social care 12 million population 

Slovenia – Country wide 2 million population

Brazil – Unimed Medical cooperative

2) Health systems using openEHR to create curate and publish clinical content.


NHS Scotland





openEHR Foundation 

Applications built on openEHR platform

OPENeP EPMA product www.openep.org

Marand Think!Med Clinical, Ljubljana Children’s Hospital http://www.marand-thinkmed.com

Ocean Multiprac Infection control, Queensland Health, Australia http://www.multiprac.com/?portfolio_4=infection-control-2

Ocean LinkedEHR, Western Sydney, Australia  http://openehr.org/news_events/industry_news.php?id=121

DIPS Arena, Norway http://openehr.org/news_events/industry_news.php?id=97

mConsole, Mental Health patient portal, Code24, Netherlands

Clinical Decision Support, Cambio, Sweden http://www.cambio.lk/News-and-facts/Produktnytt/COSMIC-Clinical-Decision-Support1/

See also http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities

3 Some key documents on OpenEHR

OpenEHR Architecture Overview

OpenEHR Reference Model