The European Commission is putting together a position on disruptive innovation in health. Their preliminary opinion paper references Clayton Christensen’s The Innovator’s Prescription a number of times, as I did aeons ago in this post on the Crisis in e-health Standards. It made me think about how to explain openEHR’s innovations.

Sometimes it is hard to see the wood for the trees on this question. As an insider, I’ll try to expose what have turned out to be the true innovations of openEHR, distinct from features that are just ‘its way of doing things’.

Universal Clinical Data Representation (Reference Model)

The openEHR Reference Model (RM) enables systems to use one representation for all clinical care settings, and all types of clinical data, including device data. The openEHR RM took a long time to get right, and of course is still evolving.

[Edit 05/11/2015] One of the reasons it’s unique is that we refined it by enabling clinicians to build archetypes based on it from very early on and then listening to their direct feedback on what was missing or wrong. You won’t find this method in any textbook!

• ⇒ This enables true technology-independent, patient-centric EHRs, since the EHR content is not dependent on the capture method, screen forms, message formats, implementation technology or any other specifics.
• ⇒ Enables community-based care, so that provider institutions and clinics work together, not in care siloes (Christensen’s “distributed health service delivery”) – a Blood Glucose measurement is the same across all settings and user interfaces.
• ⇒ Enables longitudinal computation across all patient data, leading to risk analytics and personalised healthcare.

An openEHR patient record can be exchanged from a Moscow hospital to an Australian GP office, with all its structured data and meaning being preserved.

Abstract Domain Modelling Formalism (Archetypes)

The ‘archetype’ innovation addresses a core difficulty in IT in general: the fact that data follows patterns from the real world which are too numerous to model in the software or databases, but nevertheless need to be formalised, to be computable. Previously in health IT, the only proxy for models of content was screen form definitions locked inside each EMR product. This is described in the business purpose of archetypes.

• ⇒ now we have hundreds of detailed models of clinical content created directly by clinical and health informatics professionals, without reference to concrete message formats or web technologies, nor technical languages like UML. This required a new language and new tools – the ‘standards factory’. IT people don’t go near these models. This is a first in health IT.
• ⇒ Enables data processing and persistence to be built independently of clinical content specifics and clinical models deployment, including by completely different companies or institutions;
• ⇒ It also allows all technical expressions of content for exchange and the web to be tool-generated – URIs for REST APIs for example. A reasonable amount of UI can now be tool-generated. The combination of archetypes and Reference Model constitute a near-complete semantic expression of system data. We no longer need hand-built ‘message’ standards as such.

Portable Query Language

We created something called Archetype Query Language (AQL) in openEHR. In AQL, queries are written solely based on the logical Reference Model and the archetypes, completely independently of the underlying persistence representation.

• ⇒ AQL queries are therefore semantic statements that only need to be developed once, and can be reused across products, CDR implementations forever. This is a first in health IT.
• ⇒ We now have a basis for Clinical Decision Support industry, since CDS developers can develop the queries to talk to CDRs once rather than once for each product.
• ⇒ We also now have a basis for semantic big-data analytics.

Does openEHR solve everything?

Rhetorical question! Certainly not… What we did in openEHR is like any other halfway decent technology: it sits on the shoulders of others, including the wisdom and research of those in the broad health informatics community. I think we did our homework properly and considered theoretical bases as well as empirical evidence. I would say that the openEHR effort crystallised out good thinking (which we reference in the specifications) in the area of clinical requirements, EHR semantics, web technologies, added archetypes and AQL, and integrated all these elements together into a coherent engineering framework.

This framework in turn has to be connected with the products of other major spheres of work, including terminology, guidelines, analytics and so on to build full e-health computing environments. openEHR is an enabling layer, but a necessary one.

It’s also a work in progress (you can watch it on Jira), like anything else, but the evidence of some years’ of implementation and deployment shows that the innovations are real.

How does it line up against EC innovation areas?

I’ve extracted the preliminary report’s list of innovation areas (p64), and marked them either blue where openEHR is an ‘enabler’, or blue/bold where openEHR is a ‘direct hit’.

• Person-centred care
• Complex  Adaptative  System  approach;  clinical  governance;  leadership  for  high-value care in clinical practice
• Tele-Health, remote medicine, mobile health
• Electronic health records
• Big-data utilization in the care of patients and the management of Health Systems
• Community based mental health
• Systems of pricing new medicines; affordable access to new medicines
• Population  based   accountable organisations;   chronic   disease   management; systems   enabling   continuous   care;   coordination   between   social   and   health systems
• Early palliative care
• Waste reduction in clinical processes
• Tobacco control strategy

Barriers to Innovation

The preliminary report talks about the various kinds of barriers to innovation adoption (p46). The key ones are (remembering that these are to do with health, not just e-health):

• workforce barriers – loss of ownership; professional/cultural barriers; lack of training;
• patient / person barriers – cultural acceptance, training, mobility of solution;
• organisational barriers – no realistic business model; procurement; lack of planning; inadequte information systems; lack of system interoperability; lack of coordination of authorities;
• economic and legal barriers – lack of investment in infrastructure; prices; lack of retail market; payment models;
• lack of political support – lack of political buy-in;
• lack of evaluation.

Quite a few of these impede the adoption of the innovations of openEHR, and other similarly powerful approaches. Today I would say we are still stuck in a paralysis of various factors, all of which the EC could help with the following.

• The EHR still isn’t solved in Europe, but EC funding frameworks act as if it is. This is the single biggest problem in all current EC funding programmes for e-health, including Horizon 2020. because making nearly everything else work relies on a working EHR.
• Bureaucrats need a technology update: we are now way past needing hand-rolled message definitions or web APIs for clinical content, but current activities and funding still focus on these outdated approaches.
• There is only limited visibility at the political level of the platform concept, even though the entire tech world is now shifting to it. Making progress in e-health for Europe relies on using this concept at all levels, including policy.