openEHR: A Game Changer Comes of Age

I’ve been watching openEHR over more than fifteen years and have always been impressed by its potential to enable us to do things differently, but it’s been a slow burn, with limited take up, particularly in the United Kingdom (UK) where it was invented. However, recent developments mean that I think this is about to change and that openEHR is going to take off in a big way which is going to revolutionize how we think about and do digital health and 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 numerous successful small implementations and a few much larger ones that have proven the approach at scale (1). We have also seen the use of openEHR by Governments and major health providers across the globe, including the UK's own Natinoal Health System (NHS), as the mechanism for the creation and curation of clinical content standards in their territories (2). Add to this changes to the openEHR Foundation to make in unarguable an open source organization with a global user community, the emergence of a growing vendor community offering both open source and proprietary tools and components supporting the standard and serious interest from major system integrators and openEHR looks like a much better alternative to the hegemony of the big US megasuite providers who want to shape health and care systems in their image and own the platforms on which these providers will increasingly depend.

Everything I read and all of the people I talk to across the globe about digital health agree on a couple of things:

1. 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 and which will enable them to interoperate and work together.
2. 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 argue about business models (who should own and control the platform) as well as the details of the particular standards and technology to be used. However,  everyone with any credibility agrees on the core principles.

On business models, there are some who would like to own the platform, as 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) or 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 significant some big players have come to the view that while it would be great to own the platform, that it won’t happen and that we need to move to an open platform which nobody owns (just like the Internet) and look for commercial opportunities higher up the value chain which the existence of the platform will create by the spadeful, rather than wasting time and resource on a battle no one can win.

On the implementation detail disagreement is less significant with the two major contenders, openEHR and the Healthcare Consortium both having similar approaches that are already converging through the CIMI initiative to reduce their differences to the point where they really don’t matter and 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 there is nothing else as mature or well supported.

What then is openEHR? It’s not software, it’s not 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) it’s curated by the openEHR Foundation, 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 user 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 overarching reference model (3) which defines a formalism for the representation of the modular components of a health and care record which openEHR calls archetypes which define record elements, their properties and how they are represented (including binding 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, evaluation, instruction or an action) and can 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 make openEHR easily accessible to clinicians and other domain experts while providing robust components for system developers that handle many of the technical complexities. openEHR enables clinicians to concentrate of the clinical and developers to concentrate on the technical without needed to understand more about the other domain than they want to.

By building systems using openEHR system development shifts from the technical to the domain level. A repository 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 it will be able to store it and you will be able to query the repository about it’s content. This feature of openEHR is the key enabler of much faster application development as the addition of new features will not require changes to database schemas and the associated testing and data migration, but simply the use of additional Archetypes and/or Templates (which may already be available as the result of work by others in the community or can rapidly be created by the relevant domain expert) and the creation of some new user interface components which can often be automatically generated from the underlying templates. In this way changes can be made by or nearer end users reducing the time to add new features from months to hours and the time to build new systems from years to weeks.

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 eliminates vendor lock-in.

openEHR is technology independent. Applications don’t need to concern themselves with technology of a particular implementation of an openEHR repository, that’s a matter purely for the implementer, who can chose that that works best for them without effecting the applications that use it as long as they remain compliant with the standard. Technology capabilities and fashions continually change and the particular technology choice will depend on what works best for a particular developer, at a particular time and for a particular context of use. We can see this in the dozen of so existing implementations of openEHR repositories which use different operating systems, databases (SQL and NOSQL) and development tools to create both open source and proprietary implementations of the standard. This means that suppliers of openEHR repositories have to compete on performance, security, robustness, value and service and cannot rely on customer lock-in as the vendors of many traditional EHRs have in the past.

From the perspective of health and care providers openEHR puts them back in charge of their own destiny. Currently the most successful approaches to the delivery of enterprise wide EHR has been to adopt one of the four big US megasuites and to adapt your processes and organization to fit with your chosen system – You become an EPIC, Cerner, Allscripts or Meditech Institution (not a customer who calls the shots.) This model has worked spectacularly, if expensively, well, particularly for EPIC, in a number of big US Hospital, but starts to break down when you seek to extend the scope from an institution to an integrated health and care community and fits badly with UK and other European models of health are care, which are not so close as the meagsuite vendors might hope to the US model and don’t want to be – After all why would relatively successful European health and care systems want to adopt systems primarily designed for the inequitable and unsustainable US system, which according to the well respected US Commonwealth Foundation ranks last among eleven countries on measures of access, equity, quality, efficiency, and healthy lives while the UK takes the number one spot.

Much of my conviction about openEHR comes from work I’ve been involved with with HANDI to be build 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 of service that wants to expose an API (interface) in an open ecosystem and 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 and used this to build a number of apps and also demonstrated how you can simply plug in apps developed elsewhere using the SMART API. We have also use this platform to prototype a UK localization of an open source ePrescribing product www.openep.org and the speed we have been able to carry out the localization 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

Notes:

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 HSCIC
• NHS Scotland
• Australia
• Norway
• Slovenia
• Brazil
• openEHR Foundation 

Applications built on openEHR platform

• OPENeP EPMA 
• Marand Think!Med Clinical, Ljubljana Children’s Hospital 
• Ocean Multiprac Infection control, Queensland Health, 
• Ocean LinkedEHR, Western Sydney, Australia  http://openehr.org/news_events/industry_news.php?id=121
• DIPS Arena, Norway
• mConsole, Mental Health patient portal, Code24, Netherlands
• Clinical Decision Support, Cambio, Sweden
•  

See also: OpenEHR Deployed Solutions

3) Some key documents on OpenEHR

• OpenEHR Architecture Overview
• OpenEHR Reference Model