About

• What is openEHR?
• Vision and Mission
• Developer Ecosystem


• Origins of openEHR
• History 2002 - 2018


• Logos
• Contacts

What is openEHR?

'openEHR' is the name of a technology for e-health, consisting of open specifications, clinical models and software that can be used to create standards, and build information and interoperability solutions for healthcare. The various artefacts of openEHR are produced by the openEHR community and managed by openEHR International, an international non-profit organisation originally established in 2003 and previously managed by the openEHR Foundation.

Motivations

In recent decades, it has become clear that the value of information technology in health (often called e-health) has lagged far behind other domains such as banking, process control and logistics. Consumers in all countries still wonder why their health records don't move with them when they move, why hospitals and general practice can't share medication lists, and why they repeatedly get asked the same questions at every clinic or hospital encounter.

Healthcare professionals wonder why it is that their Electronic Medical Record (EMR) systems create more work, not less, but still don't talk to each other or to other products; why there has not been more progress on computing with health data for disease prevention; why there isn't a reliable shared medications list; and why they still have to use non-computable guidelines and protocols instead of having IT tool support, such as we use when navigating in our cars.

The single greatest problem in care provision is the lack of support for continuity of care, across provider facilities and independent of particular EMR vendors. Missed referrals, hand-offs, investigation orders continue to frustrate basic care provision, often dangerously for the patient. The lack of a process view driven by care pathways and guidelines is a major impediment to quality and continuity of care.

Additionally, in the medical research and public health arenas, workers wonder why most of their budget is routinely lost on endlessly transforming clinical data to obtain a minimum computable form necessary for their studies.

It is the goal of openEHR community to fundamentally change the quality of information technology in the service of medicine, so as to improve outcomes in clinical healthcare, public health and the value of secondary data use.

The openEHR Programs

The main work of the openEHR International is performed by four 'programs' which respectively focus on specifications, clinical modelling, software, and education. The first three of these programs correspond to the primary types of output of the openEHR community. Work on all of the programs is performed by community members. A lightweight system of governance, influenced by the governance of Apache Foundation, has been created to promote efficient and transparent decision-making.

	Specification Program The Specification Program defines the formal models and languages defining the openEHR technical platform, and includes information model, query language, the Archetype Language for openEHR content models (archetypes and templates) and specifications for openEHR services and APIs. These specifications are published (main site) and used for software engineering and also underpin the Clinical Modelling Program (for which they provide the language of archetypes) and the Software Program (for which they provide schemas and interface definitions for software). The Architecture Overview provides a complete summary of the openEHR specifications architecture.
	Clinical Modelling Program The work of the Clinical Modelling Program is performed by clinical professionals and health informatics experts working in the Clinical Knowledge Manager (CKM) environment, building archetypes which act as international standards for re-usable clinical content. These archetypes can be used by national and local e-health programs, and are the basis for building openEHR templates, from which software artefacts are generated by tooling.
	Software Program The Software Program is responsible for the development of open source implementations of both tools and healthcare information system components. Such components can be freely used by openEHR implementers to build their own tooling and systems, and are available under the industry-friendly Apache 2 licence. Many of the software program's projects are found in the openEHR Github project.
	Education Program Bringing the technical outputs of the other programs to the real world is the job of the Education Program, which aims to enable the efficient use and uptake of the outputs of openEHR available and usable in local languages and within diverse healthcare cultures and funding environments.

 

openEHR as a Model-driven Technology

There are many contingent reasons for the poor progress of IT in health relating to politics, commercial interests, and inability to focus funding across the mixture of public and private economic actors, but there are also in-principle causal factors at work, which continue to block progress. Chief among these are:

• complexity and rate of change of information and processes - reflecting the innate complexity both of human biology and society;
• the growth of specialisation and team-based care, such as for acute stroke and sepsis, requires an over-arching model of care process, plans and real-time notification across facilities and to the patient;
• patients routinely move across enterprise and jurisdictional boundaries while expecting seamless care;
• the rapid march of technology versus the longevity of care processes: healthcare process state must be constantly transferrable across changing OSs, DBs, programming languages and user devices.

The first factor can only be addressed by a technology approach that makes domain semantics a central concern. The sheer size and rate of change of the semantics of the domain, in life science and clinical and organisational contexts renders standard methods of IT architecture unsustainable. Thus, a new paradigm for modelling domain semantics is needed.

The challenge of supporting simultaneous teamwork across multiple activities, coupled with case complexity requires a new generation of clinical process support, including computable care pathways and executable adaptive task plans.

The third factor - the moving patient - presents a challenge to standard IT architectures in which data usually reside inside single institutions and then inside single products. The need in healthcare however is that the health record be associated with the patient, not with the institution or product.

The last factor - the problem of technology churn - requires data representation separate from specific technologies, but that can always be converted to technologies currently in use. This requires the primary expression of domain semantics to be separate from concrete technologies like XML schemas, REST APIs and so on. 

These four challenges must be addressed by any technology that aims to materially improve the current situation in the e-health domain. openEHR is designed to fulfill this need, by providing a comprehensive architecture for specifying, designing and building e-health solutions:

• A multi-level modelling framework that separates data representation from domain content;
• An open platform architecture that can be used to represent patient-centric health data, which are accessed by institutions and products but not controlled by them;
• A domain modelling formalism supporting composition, specialisation, localisation and flexible binding to terminology;
• A modelling factory environment that builds a library of data points, known as archetypes, developed by domain experts, in any language;
• An ability to recombine data points into data sets, known as templates, for local use cases;
• Tools that machine-convert domain models into technical forms that can be used to build:
  • applications (e.g. screen definitions);
  • interoperability components (message definitions) and
  • be consumed by platform implementations at runtime (data set definitions).

We can visualise the openEHR technology ecosystem that implements the above as follows:

Under this architectural approach, the entirety of the deployed software solution is based on and driven at runtime by computable models of content and process created by domain users. Notably, the data representation depends only on the data model, which ensures that physical database schemas and contents are not affected by new domain models.

Healthcare Information

The openEHR specifications include information models for healthcare data, including

• the EHR (how to record clinical observations?) and demographics (parties, roles and relationships);
• a portable query language;
• the archetype formalism (adopted by ISO) for expressing domain content (what does a 'blood pressure measurement' look like?) and data sets (what does the clinical note for a 12-month diabetic visit look like?);
• an open API specification.

The openEHR query language (AQL) represents a major innovation, which enables the writing of model-based queries that are independent of physical DB schemas, and thus portable across systems. This enables a sustainable approach to clinical decision support and business analytics, which are otherwise either tied to a single database, or else have to be rewritten for every target system.

The development pathway from models → data → persistence → querying is shown below.

Healthcare process

For process-based care (including Clinical Decision Support (CDS)), model-level artefacts include Guidelines (GDL2), and Care Pathways and Order Sets, representation is in terms of archetype-based modelling applied to an adaptive workflow model (Task Planning), and a Decision Language. The relationship between todays 'paper' guidelines and openEHR computable representation is illustrated below.

The Specifications

The openEHR specifications have attained de facto standards status in the industry, form the basis of openEHR implementations of the platform (both open and closed source), as well as the modelling tools. They also define openEHR clinical data in a form independent of any particular technology, but of course expressible in currently available technologies (XML, JSON, modern DBs etc).

Interoperability is solved in a way commonplace outside of the healthcare domain, which is by machine-generation of schemas and software components from models, rather than by hand-building of point-to-point messages or document definitions, the historical approach in e-health. Where messages or documents are an integration requirement, a significant degree of automated openEHR model-based mapping is available.

In a similar way, the difficulty of application development is greatly reduced via machine-generation of application software and UI components. Using specialised tools, the building of some UI applications directly by clinical professionals is now possible.

The Value of Using openEHR

An openEHR platform solution may be deployed in a single hospital much as any EMR solution is, but also across a city, region or whole country. It is in the latter deployments where the capability of persisting data in a patient-centric rather than institution- or product-centric fashion is realised, and vendor lock-in is avoided.

The separation of domain models from the technical layers qualitatively changes the software engineering economics of solutions, because it allows the platform to be built and deployed independently, with the domain models being injected at runtime, removing one of the major sources of cost at a stroke. It also allows domain professionals, who know their own data and workflows, to be in the driving seat when specifying the semantics of Hospital Information Systems (HISs).

In their most advanced form, the technical advances of openEHR lead naturally to a plug-and-play platform economy, in which any vendor or developer can produce a solution component, as long as it conforms to the published data and API base standards of openEHR, and additionally, to the domain content models created by the community of clinical professionals, including those from the customer. This puts the customer back in charge of their own system environment, while enabling incremental procurement of new components.

Significant benefits are available in more typical environments in which openEHR is deployed in a 'bimodal' form, alongside monolithic EMR systems, to add semantic power and flexibility, and to provide a high-fidelity common data repository, independent of commercial products and contracts.

The openEHR White Paper provides a more detailed discussion of the advantages of an open, extensible health computing platform. The Apperta Foundation white paper provides another perspective on the platform paradigm.

Getting Involved

This website will give you information on how it all works, and how to become a member of openEHR. The openEHR approach offers opportunity and value to many different stakeholders, including clinicians, health care providers, governments, software developers and research institutions.