Everything I read about digital health, and all of the people I talk to across the globe, 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 that 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 argue about business models, or who should own and control the platform, and about the details of the particular standards and technology to be used.
Business models: several contenders, but really only one
When it comes to business models, some would like to own the platform, because doing so would create a massive commercial opportunity.
Yet while some still pursue this goal (most significantly Apple) others have decided, as I have, that ownership of the platform is not 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. If that’s the case, then we need to move to an open platform which nobody owns (in the sense that nobody owns the internet).
Commercial opportunities will still exist higher up the value chain, and the existence of the platform will create such opportunities by the spadeful. Surely it is more fruitful to concentrate on these, instead of wasting time and resources on a battle nobody can win?
The two major contenders for this platform are openEHR and the Healthcare Consortium. Both have similar approaches, and they are already converging through the Clinical Information Modeling Initiative.
This aims 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. Having said that, there is frankly nothing as mature or as well supported as openEHR.
What is openEHR?
OpenEHR is not software, nor is it a particular technology. It is 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. This 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; it 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, 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.
Advantages of openEHR
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).
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. Otherwise, they can be created rapidly by a relevant domain expert – along with the creation of some new user interface components, which 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.
More advantages of openEHR
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.
End of the megasuite mentality?
This contrasts with most of the current successful approaches to the delivery of enterprise-wide EHR, in which customer institutions adopt one of the four US megasuites; and then have to adapt internal processes and organisation to fit with the chosen system.
In effect, your organisation becomes an Epic, Cerner, Allscripts or Meditech institution, rather than a customer that 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?
Platform in action
There are some large scale implementations of openEHR in place (for example in Moscow), a long list of health systems using openEHR to curate and publish clinical content, and plenty of apps built on the platform.
However, much of my conviction about openEHR comes from the work I’ve been involved in with HANDI in building HANDI-HOPD. This is the HANDI Open Platform Demonstrator that 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; and we have used this to build a number of apps. We have 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 e-prescribing product, 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, it’s been so impressive that we will shortly be announcing the first NHS trusts that will be taking the system live. openEHR has come of age – If you don’t believe, me give it a try.
Ewan Davis
Ewan Davis is a digital health strategist at Woodcote Consulting, and a consultant to NHS England on open source. He is a founder of HANDI, a not for profit venture that aims to promote openness and collaboration that developed the HANDI-HOPD online open platform demonstrator.
This column is a syndicated version of a recent post on the Woodcote Consulting blog, which has links to useful articles about openEHR and its use.