openEHR is an open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in electronic health records
(EHRs). In openEHR, all health data for a person is stored in a "one
lifetime", vendor-independent, person-centred EHR. The openEHR
specifications include an EHR Extract specification
but are otherwise not primarily concerned with the exchange of data
between EHR-systems as this is the focus of other standards such as EN 13606 and HL7.
The openEHR specifications are maintained by the openEHR Foundation, a not for profit foundation supporting the open research, development, and implementation of openEHR EHRs. The specifications are based on a combination of 15 years of European and Australian research and development into EHRs and new paradigms, including what has become known as the archetype methodology for specification of content.
The openEHR specifications include information and service models for the EHR, demographics, clinical workflow and archetypes. They are designed to be the basis of a medico-legally sound, distributed, versioned EHR infrastructure.
The openEHR specifications are maintained by the openEHR Foundation, a not for profit foundation supporting the open research, development, and implementation of openEHR EHRs. The specifications are based on a combination of 15 years of European and Australian research and development into EHRs and new paradigms, including what has become known as the archetype methodology for specification of content.
The openEHR specifications include information and service models for the EHR, demographics, clinical workflow and archetypes. They are designed to be the basis of a medico-legally sound, distributed, versioned EHR infrastructure.
Architecture
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.
Reference model
A central part of the openEHR specifications is the set of information models, known in openEHR as 'reference models'.
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.
Archetypes and multi-level modelling
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.
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.
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).
Notably, openEHR has been used to model shared care plan. The
archetypes have been designed to accommodate the concepts of the shared
care plan.
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.
Archetype formalism
openEHR
archetypes are expressed in "Archetype Definition Language", an openEHR
public specification. Two versions are available: ADL 1.4, and ADL 2, a new release with better support for specialisation, redefinition and annotations, among other improvements.
The 1.4 release of ADL and its "object model" counterpart Archetype
Object Model (AOM) are the basis for the CEN and ISO "Archetype
Definition Language" standard (ISO standard 13606-2).
Templates have historically been developed in a simple, de facto
industry-developed XML format, known as ".oet", after the file
extension. ADL 2 defines a way to express templates seamlessly with archetypes, using extensions of the ADL language.
Quality assurance of archetypes
Various principles for developing archetypes have been identified.
For example, a set of openEHR archetypes needs to be quality managed to
conform to a number of axioms such as being mutually exclusive. The
archetypes can be managed independently from software implementations
and infrastructure, in the hands of clinician groups to ensure they meet
the real needs on the ground. Archetypes are designed to allow the
specification of clinical knowledge to evolve and develop over time.
Challenges in implementation of information designs expressed in openEHR
centre on the extent to which actual system constraints are in harmony
with the information design.
In the field of Electronic health records there are a number of existing information models with overlaps in their scope which are difficult to manage, such as between HL7 V3 and SNOMED CT. The openEHR approach faces harmonisation challenges unless used in isolation.
International collaboration
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.
International adoption
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.
It is beginning to be utilised in commercial solutions throughout the world, including those produced by the openEHR Industry Partners.
Clinical Knowledge Manager (CKM)
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:
