openEHR

Block diagram of openEHR specification components.

The architecture of the openEHR specifications as a whole consists of the following key elements:

• information models (aka 'Reference Model');
• the archetype formalism;
• the portable archetype query language;
• service models / APIs.

The use of the first two enable the development of 'archetypes' and 'templates', which are formal models of clinical and related content, and constitute a layer of de facto standards of their own, far more numerous than the base specifications on which they are built. The query language enables queries to be built based on the archetypes, rather than physical database schemata, thus decoupling queries from physical persistence details. The service models define access to key back-end services, including the EHR Service and Demographics Service, while a growing set of lightweight REST-based APIs based on archetype paths are used for application access.

The openEHR Architecture Overview provides a summary of the architecture and the detailed specifications.[5]

A central part of the openEHR specifications is the set of information models, known in openEHR as 'reference models'.[6] The models constitute the base information models for openEHR systems, and define the invariant semantics of the Electronic Health Record (EHR), EHR Extract, and Demographics model, as well as supporting data types, data structures, identifiers and useful design patterns.

Some of the key classes in the EHR component are the ENTRY classes, whose subtypes include OBSERVATION, EVALUATION, INSTRUCTION, ACTION and ADMIN_ENTRY, as well as the Instruction State Machine, a state machine defining a standard model of the lifecycle of interventions, including medication orders, surgery and other therapies.

A key innovation in the openEHR framework is to leave all specification of clinical information out of the information model (also known as "reference model") and instead to provide a powerful means of expressing definitions of the content clinicians and patients need to record that can be directly consumed at runtime by systems built on the Reference Model. This is justified by the need to deal scalably with the generic problem in health of a very large, growing, and ever-changing set of information types.[7]

The semantic framework of openEHR

Clinical content is specified in terms of two types of artefact which exist outside the information model. The first, known as "archetypes" provides a place to formally define re-usable data point and data group definitions, i.e. content items that will be re-used in numerous contexts. Typical examples include "systemic arterial blood pressure measurement" and "serum sodium". Many such data points occur in logical groups, e.g. the group of data items to document an allergic reaction, or the analytes in a liver function test result. Some archetypes contain numerous data points, e.g. 50, although a more common number is 10-20. A collection of archetypes can be understood as a "library" of re-usable domain content definitions, with each archetype functioning as a "governance unit", whose contents are co-designed, reviewed and published.

The second kind of artefact is known in openEHR as a "template", and is used to logically represent a use case-specific data-set, such as the data items making up a patient discharge summary, or a radiology report.[8] A template is constructed by referencing relevant items from a number of archetypes. A template might only require one or two data points or groups from each archetype. In terms of the technical representation, openEHR templates cannot violate the semantics of the archetypes from which they are constructed. Templates are almost always developed for local use by software developers and clinical analysts. Templates are typically defined for GUI screen forms, message definitions and document definitions, and as such, correspond to "operational" content definitions.

The justification for the two layers of models over and above the information model is that if data set definitions consist of pre-defined data points from a library of such definitions, then all recorded data (i.e. instances of templates) will ultimately just be instances of the standard content definitions. This provides a basis for standardised querying to work. Without the archetype "library" level, every data set (i.e. chunk of operational content) is uniquely defined and a standard approach to querying is difficult.

Accordingly, openEHR defines a method of querying based on archetypes, known as AQL (Archetype Querying Language).[9]

Notably, openEHR has been used to model shared care plan. The archetypes have been designed to accommodate the concepts of the shared care plan.[10]

While individual health records may be vastly different in content, the core information in openEHR data instances always complies to archetypes. The way this works is by creating archetypes which express clinical information in a way that is highly reusable, even universal in some cases.[11]

Following the openEHR approach, the use of shared and governed archetypes globally would ensure openEHR health data could be consistently manipulated and viewed, regardless of the technical, organisational and cultural context. This approach also means the actual data models used by any EHR are flexible, given that new archetypes may be defined to meet future needs of clinical record keeping. Recently, work in Australia has demonstrated how archetypes and templates may be used to facilitate the use of legacy health record and message data in an openEHR health record system, and output standardised messages and CDA documents.

The prospect of gaining agreement on design and on forms of governance at the international level remains speculative, with influences ranging from the diverse medico-legal environments to cultural variations, to technical variations such as the extent to which a reference clinical terminology is to be integral.

The openEHR framework is consistent with the Electronic Health Record Communication Standard (ISO 13606), and the Archetype Object Model 2 (AOM2) has been officially accepted by ISO TC 215 as the draft specification for the 2017 revision of ISO 13606:2.

openEHR archetypes are being used by the National e-Health Transition Authority of Australia, the UK NHS Health and Social Care Information Centre (HSCIC), the Norwegian Nasjonal IKT organisation, and the Slovenian Ministry of Health.

openEHR has been selected as the basis for the standardised EHR in Brazil.[20]

It is beginning to be utilised in commercial solutions throughout the world, including those produced by the openEHR Industry Partners.

One of the outcomes of openEHR modelling approach is the open development of archetypes, templates and terminology subsets to represent health data. Due to the open nature of openEHR, these structures are publicly available to be used and implemented in health information systems. Community users are able to share, discuss and approve these structures in a collaborative repository known as the Clinical Knowledge Manager (CKM). Some currently used openEHR CKMs:

• openEHR Clinical Knowledge Manager
• NEHTA Clinical Knowledge Manager
• UK Clinical Knowledge Manager
• Norwegian National ICT Clinical Knowledge Manager
• Slovenian MoH Clinical Knowledge Manager

• Archetype (information science)
• European Institute for Health Records
• Electronic Health Record Communication (ISO/CEN EN 13606 - EHRcom)
• Health Level 7
• Health Informatics Service Architecture (HISA)
• HIPAA
• ProRec
• SNOMED CT

• openEHR Foundation website
• openEHR specifications
• openEHR 2015 white paper