openEHR

- What is openEHR?

- Key strengths

- Architecture

- Reference model

- Modelling methodology

- Archetype Query Language

- Clinical decision support

- Workflow & task planning

- Tooling

What is openEHR?

openEHR is an open standard supporting the definition, persistence and querying of structured clinical1 data. 

openEHR has been implemented at scale and in used in many places across the world as listed here.

The openEHR standard defines:

  1. A methodology for defining and curating clinical content; and
  2. The specification of an open API and query language that allows openEHR content to be stored and queried in a compliant Clinical Data Repository (CDR).

openEHR also provides support for:

    • Terminologies allowing the inclusion of any terminology such as SNOMED-CT;
    • Clinical Decision Support through its Guideline Definition Language (GDL); and
    • Workflow and Task Planning through its Task Planning Visual Modelling Language (TP-VML).

openEHR is technology and vendor neutral with a number of both open source and proprietary openEHR implementations using a range of technologies. 

Any interested party is free to use the openEHR methodology or to build an openEHR CDR.

The openEHR standard is maintained by the not-for-profit openEHR International based in London. Membership of openEHR is open to all interested parties who direct the development of openEHR.

There is a large and active global community using openEHR contributing to its development and sharing clinical content definitions.

openEHR is aligned with and draws on a number of international standards, in particular, ISO/TR 20514 and ISO/TS 18308. openEHR is one of a family of standards required to build an open platform which includes HL7 FHIR, SNOMED-CT and IHE-XDS. openEHR works well alongside these standards.

Comprehensive information on openEHR including its formal specifications are available on the openEHR website.

Note  1:  We use the terms “Clinical” as a synecdoche to cover the whole domain of health and social care, not just clinical medicine; and “Clinician” as a synecdoche for any health and social care professionals.

Key strengths

It is intended that clinical content defined using openEHR is stored in an openEHR compliant Clinical Data Repository (CDR). However, openEHR clinical models can also be used provide robust models for use in other modalities such as HL7 FHIR or RDF.

As a modelling methodology, openEHR:

  • Has an open governance model that encourages global standardisation, while supporting local variation.
  • Is designed for clinicians as the domain experts to build clinical models
  • Provides a robust modelling methodology, scalable to cover all of health and social care.
  • Is supported by a global community who collaborate on the creation and curation of clinical content.
  • Provides a growing library of open source clinical models.
  • It’s semantically coherent providing computable models for developers.
  • Human language agnostic - openEHR works in any language allowing common information models to appear in the local language. There are implementations in many Western European languages, Russian, Arabic, Chinese and Japanese.

When deployed natively on an openEHR CDR, there are significant additional benefits:

  • Vendor and technology neutrality - There are multiple proprietary and open source CDR implementations on a variety of technology stacks.
  • Zero-engineering deployment of new content - new openEHR models can be deployed to any CDR with no engineering (i.e. no involvement of the CDR provider, no schema changes and no data migration.) Only applications that use the new content are affected so no need for regression testing. New content can be developed in hours and deployed in seconds.
  • Sophisticated semantic querying - openEHRs Archetype Query Language (AQL) can be run over multiple openEHR Clinical Data Repositories irrespective of their technology and internal physical data structures. 
  • Automatic versioning and audit - openEHR CDRs maintain details of all changes and amendments to the data stored in them along with metadata to track provenance and attribution. This provides a robust medico-legally admissible audit trail with zero effort from application developers.

 

openEHR architecture

The openEHR architecture is described below.

openehr_architecture

The architecture uses:

  • Reference model to provide semantic coherence
  • archetypes to define detailed elements of clinical content; and
  • templates that combine and constrain elements from multiple archetypes to support a given use case.

Templates are used by developers to generate various artefacts that can be used to build applications.

openEHR allows terminologies like SNOMED-CT to be bound to both archetypes and templates.

openEHR provides a query language AQL that allows detailed querying of content stored in an openEHR CDR.

openEHR Reference Model

openEHR is underpinned by a stable reference model, which ensure semantic coherence providing:

  • Set of classes defining the generic structure of a patient health record:
    • Observation
    • Evaluation
    • Instruction
    • Action
    • Admin entry
  • Medico-legal context and+ audit details
  • Versioning
  • Datatype definitions
openehrRM

openEHR modelling methodology

The openEHR modelling methodology uses a two level modelling approach based on a stable underpinning reference model. The methodology uses:

  • archetypes to define detailed elements of clinical content; and
  • templates that combine and constrain elements from multiple archetypes to support a given use case.

openEHR archetype

An archetype represents a piece of clinical content. This might be a weight, a temperature, a blood pressure, a medication, a test or procedure. There are probably around 10,000 bits of clinical content that would need to be defined to cover the whole of health and social care.

openEHR archetypes are maximal data sets containing all of the data points required by all use cases. Even something simple like body temperature which a naive developer might imagine consists of just a value and unit of measure, has 12 data points plus many additional pieces of metadata.

Screenshot from 2019-05-04 12-16-27

The archetype also defines which data points are mandatory and which optional, their data type and validation criteria.

openEHR expects archetypes to be built by clinicians and other domain experts, not technologists, and the available tooling is designed to facilitate this. An IT literate clinician can be trained to build archetypes in their domain of expertise in a few hours.

The maximal data set approach makes it much easier to gain agreement than the more usual minimum data set approach.

While there is no requirement to do so, most archetypes are developed in the open and shared freely by the openEHR community. This gives users of openEHR access to at least 100,000 person hours of clinical modelling effort for free providing developers with the building bricks to build systems.

openEHR archetypes are shared via a network of Clinical Knowledge Manager implementations that allow interested parties to discover available openEHR archetypes and collaborate with others to create and review new archetypes.

openEHR template

Templates constrain and combine archetypes to create the information models needed to support a particular use case.

block

Further validations and terminology bindings can be added to a template in addition to those inherited from the underlying archetypes. Templates can be used to create document or message schemas, provide the data needed to create screens and other user interface components or define the payload of an API call.

Terminologies

Any appropriate terminology (e.g. SNOMED-CT, ICD, LOINC, etc.) can be integrated with openEHR models via terminology bindings.

Terminologies can be bound to both openEHR archetypes and templates, but terminology bindings are generally made at the template level to allow for local variations in the use of terminology to be more easily handled.

openEHR Archetype Query Language (AQL)

Archetype Query Language (AQL) is the query language of openEHR. Unlike query languages, such as SQL or XQuery, AQL is  a semantic query language rather like SPARQL expressing queries at the archetype level with a syntax that is independent of applications, programming languages, system environment, and storage models. This means that AQL queries can be run over multiple openEHR Clinical Data Repositories irrespective of their technology and internal physical data structures. Therefore to understand how to query an openEHR system via AQL, you only need to know what archetypes and templates have been registered with that system.

AQL syntax is a synthesis of SQL structural syntax and openEHR path syntax (similar to XPath) and has elements drawn from SQL and XQuery. Queries are human readable by those familiar with these query languages.

For example:

To select all nursing reports for a single patient with identifier ‘a4a3f0c8-254a-49a5-97dd-784d50c46b78 during a period of an admission, and return the narrative text of the report ‘synopsis’, along with the report date.

SELECT s as Synopsis, c/context/start_time as reportDate
FROM EHR e[ehr_id/value='a4a3f0c8-254a-49a5-97dd-784d50c46b78']
  CONTAINS Composition c[openEHR-EHR-COMPOSITION.report.v1]
  CONTAINS 
      Evaluation s[openEHR-EHR-EVALUATION.clinical_synopsis.v1]
  WHERE c/name/value matches {'Nursing report’}
  AND c/context/start_time >= '2014-04-19T00:00:00:00' 
  AND c/context/start_time < '2014-04-24T00:00:00:00'

And will return

"resultSet": [
        {
            "reportDate": "2014-04-20T00:11:02.518+02:00",
            "synopsis": "Pretty poorly overnight but better this morning"
        },
        {
             "reportDate": "2014-04-21T00:11:02.518+02:00",
             "synopsis": "Much better today. Possible discharge later"
        },

Tooling is available to simplify the creation and visualisation of AQL queries

AQL has the following features:

  1. It can extract data for an individual or a cohort of patients.
  2. It allows fine-grained queries or archetypes and their content
  3. A query can be global or restricted to a particular context (eg find all blood pressures for patient X or find only blood pressures for patient x recorded as part of a particular assessment.)
  4. Users can specify their preference on the retrieved data, such as ordering preferences, or total number of retrieved results.
  5. Users can specify their preference on the retrieved data, such as ordering preferences, or total number of retrieved results.
    • Naming of returned results.
    • Query criteria parameters.
    • Arithmetic and Boolean operations
    • A subset of XQuery functions such as current-date().

More information about AQL here

openEHR for Clinical Decision Support (CDS)

openEHR provides the Guidelines Definition Language (GDL) as an extension to the openEHR standard. GDL allows the representation of clinical guidelines in an open and computable format.

 

GDL

GDL is used in the National CDS system in Scotland.

openEHR for Workflow and Task Planning

openEHR provides the openEHR Task Planning Visual Modelling Language (TP-VML) to enable workflow and task planning to be managed. This is the most recent extension to the openEHR specification.

TP-VML

The development of TP-VML draws on work undertaken by the openEHR implementers Marand and DIPS, and the Activity-Based Design (ABD) project at Intermountain Healthcare in the USA. TP-VML is currently being piloted in Moscow, Slovenia and Norway.

openEHR Tooling

There are a wide range of tools available to assist those working with openEHR many of which are open source or free to use - details are here.