1 Background

The open source openEHR^{^[1]} architecture specifications^{^[2]}have evolved as the result of over 20 years of research and international implementations, including the Good European Health Record (GEHR). The IP of the specifications are held under the auspice of the not-for-profit openEHR Foundation.

The traditional view of an EHR usually refers to a specific vendor application or system with the resulting risk of vendor lock-in of data. In contrast to this, openEHR emphasises that the health record comprises the clinical data itself, and ensures that it is available in a standardised, non-proprietary format.

The technical approach utilized by openEHR is a unique multi-level design paradigm which clearly demarcates between generic, technical models of data, and clinical content. Technicians / engineers manage the software engineering and clinicians manage the clinical content.

One of the key principles in openEHR is that common, coherent and clinician-approved clinical information models are essential for accurate and advanced health-related computing, shared EHRs and coordination of clinical care across clinical systems. Content models agreed at an organisational, regional, national or international level provide a firm basis for establishing technical and semantic interoperability. The broader the level of content model agreement, the greater the potential for unambiguous and detailed health information exchange, decision support and analytics.

The development of a clinician-led library of clinical content specifications will be a foundation piece of national health IT infrastructure, intended to support interoperability of all granular health information, rather than simply exchange a limited selection of inflexible messages or documents as is common today.

Over the past two decades the openEHR clinical modelling methodology has gradually evolved. The strategy underpinning it is one in which engagement and involvement of even the least technical of clinicians is prioritised and their participation supported and encouraged. Active clinician participation is the only means to ensure that the clinical content of our EHRs is clinically safe and fit for both direct patient care and secondary purposes.

2 Approach

The openEHR clinical modelling approach involves:

Development of the clinical knowledge resources that are used to represent the health data:
- Archetypes, which are the foundation building blocks at the clinical concept level – one archetype per clinical concept;
- Templates, which aggregate, combine and constrain the archetypes to create context-specific clinical data sets and documents such as clinical notes, discharge summary documents or messages that will be used in EHR systems;
- Terminology value-sets, which provide allowable coding for specific data fields, based on underlying terminologies such as SNOMED CT, ICDx, ICPC, and many others.
Online collaboration processes for clinicians and other domain experts to ensure that the archetypes and templates are clinically validated, agreed and approved;
A governance process that ensures that a cohesive library of archetypes, templates and terminology subsets are developed, maintained, managed and disseminated according to business rules that are transparent, and the entire governance process accountable to the participating modelling community; and
Local teams of clinicians, health informaticians and engineers are trained to manage this end-to-end process to meet eHealth programme requirements.

2.1 Archetypes

openEHR archetypes are clinical content specifications that formalise the patterns and requirements for representation of detailed, computable health-related data. Each archetype defines a topic-related set of data groups and elements. For example, there are separate archetypes for recording symptoms, a blood pressure measurement, an ultrasound report and a medication order. Over time, it is expected that low thousands of archetypes will be needed to cover all of mainstream medicine.

Each archetype is intentionally designed to be inclusive of all possible data elements that could be relevant for the topic and for all possible clinical use cases – this is termed a maximal data set for the universal use case. Often there is initial scepticism that this is achievable, however it is easier to start with a pragmatic data set and incrementally grow it as requirements are identified, rather than trying to get agreement on a minimum data set. As a result the Blood Pressure archetype has grown over time to be inclusive of all data elements that are required for:

a patient to record their blood pressure using an automatic machine at home;
a paramedic to record vital signs for a trauma patient in the field;
devices to record intermittent measurements in the Intensive Care Unit; or
analysis of multiple records for the purposes of a national population health analysis.

Non-technical clinicians and other domain experts are able to use clinical modelling tools with a ‘drag and drop’ interface to create and edit archetypes without having to understand the full complexity of the technology that underlies it. This is the first methodology that allows typical clinicians to actively and directly engage with EHR content development.

There is no language primacy and all archetypes are potentially multilingual, with original authoring able to occur in any language and be translated into as many languages as required. Archetypes are also terminology agnostic, permitting multiple terminology codes to be bound to each data element, plus potentially binding of structured subsets as valid value sets.

Terminology binding to archetypes may occur over time, and may not even commence until after the archetype has been initially deployed, allowing implementing organisations to get started with data, regardless of the state of terminology preparedness, often a slow, national issue.

Archetypes are regarded as the ‘source of truth’ for representation of data and require rigorous governance. This ensures that provenance, modifications and changes in publication status are transparent to implementers and downstream disruption to software is managed and understood.

Most archetypes used on a project are obtainable from elsewhere – either the international openEHR archetype repository, or one or more other national repositories. Thus, archetypes represent a growing global library of re-usable content models, greatly reducing the amount of work required in any new project or jurisdiction to define needed content. An incremental effort of 15% of the total content models deployed, plus translation where relevant, is a realistic expectation in terms of work for a new project.

2.2 Templates

openEHR templates are more detailed specifications that represent the implementable data sets – the documents, clinical notes, messages and screens required for use within, and between, EHRs. Templates are aggregations of specific elements of one or more archetypes; for example, up to 60 archetypes may be required to represent all of the clinical data elements that are needed for a discharge summary or antenatal record.

Each archetype in the template is constrained for the proposed clinical scenario, hiding non-essential data elements and revealing only the required ones – effectively reducing the authored maximal data set to the ‘clinically relevant’ data set. Templates can also include other Entry-level templates and are where most of the context-appropriate binding to terminology subsets will occur. Critically, Composition templates are the unit of commitment into an EHR.

Templates are extremely important as they allow the expression of clinical diversity, even when using identical archetypes. For example, the same 10 archetypes could be used to represent cardiac examination findings, but differing constraints will enable appropriate levels of detail to be expressed for use by a primary care clinician or for a cardiologist.

As long as the underlying archetypes are tightly governed, governance of the resulting templates can be lightweight, unless the template is representing something that has an official status, such as a formalised and structured data report to government.

3 Tools

3.1 Clinical Modelling Suite

Current openEHR tools for clinical modelling consist of:

Archetype Editor – an open source tool with a ‘drag and drop’ user interface that enables local authoring and editing of archetypes. The complex technical attributes of the openEHR Reference Model and Archetype Definition Language (ADL) that underpin the archetypes is largely hidden to clinician authors. The Editor enables all classes of archetypes to be created: Compositions; Sections; all types of Entries, including Observation, Evaluation, Instruction, Action and Admin Entry; and Cluster and Elements.
Template Designer – a free tool with a ‘drag and drop’ user interface that enable local authoring and editing of templates. In addition, the Template Designer is used in production contexts to generate template-specific downstream software artefacts, including Template Data Objects (TDOs), which are programming facades, and also Template Data Schemas (TDSs), which are XML Schemas that define an XML payload that can be used in a message, document or other communication. These downstream artefacts allow non-openEHR trained developers to immediately use openEHR semantic models to build and deploy software.

3.2 Clinical Knowledge Governance

As openEHR archetypes and templates were developed by the international community, it rapidly become apparent these clinical models required a formal publishing and governance support to be able to achieve the goal of semantic interoperability. Development of an online knowledge repository commenced testing in late 2008, and is known as the Clinical Knowledge Manager[3] (CKM). It holds and manages archetypes, templates and terminology subsets as primary assets, as well as associated documentation

CKM has also been developed to leverage the notion of collective intelligence, where “individuals decide to mutualize their knowledge, know-how and experience in order to generate a higher individual and collective benefit than if they remained alone^{^[4]}”. By combining a crowd sourcing approach with the collaborative power of the internet CKM supports a shared online community to collaborate together to define high quality, well reviewed clinical archetypes and templates for use in patient care. There are no barriers to participation, anyone interested can volunteer to join in archetype reviews or submit a candidate archetype to the community.

The third key aspect of CKM is about rigorous but transparent governance – guaranteeing appropriate processes for the management, maintenance and dissemination of the clinical resources. Clinical Knowledge Administrators are responsible for the operations of the CKM tool, management of the participating community and management of a coherent and high quality library of clinical content resources – minimising any gaps between archetype concepts as well as avoiding potential overlaps between archetypes. Editors coordinate community reviews of archetypes and templates, gradually refining each resources until they are fit to be published as stable artefacts ready for implementation. Translators are able to submit translations and terminologists add terminology bindings, once archetypes are stable and published. Grassroots clinicians require minimal training in order to participate in archetype or template reviews – they contribute where they have domain expertise, ensuring the clinical content is appropriate – while informaticians and engineers can contribute their expertise to ensure that the archetype is technically valid, and appropriate for implementation.

The openEHR Clinical Knowledge Manager (CKM), under the auspice of the openEHR Foundation, is used as an international source of excellence. As of July 2014 there are over 1100 experts registered on the openEHR CKM from 83 countries, with many archetypes translated into multiple languages to enable cross country sharing of health data. Norway, Slovenia and Australia have established CKM instances for their national eHealth programs. Negotiations are underway with Brazil for a national instance. The UK instance currently serves Scottish NHS, and is being proposed for use for NHS England.

4 Summary

In essence:

The openEHR clinical content specifications will be defined, reviewed and declared fit for purpose by clinicians and domain experts, not just software developers/engineers.
The archetype and template development, quality control, standardisaton and governance processes should be managed by expert health informaticians who understand health data and how it will be implemented and used in the clinical environment.
The end users will be the vendors and organisations building clinical information systems and applications and organisations who need to utilise quality health data for secondary purposes.
The overall project governance should be led by clinical professional groups +/- a potential consortia with appropriate political/industry groups etc.
Clinical professional and government organisations can endorse the resulting clinical models as fit for use.
openEHR Solutions can be deployed at any time with respect to the development of clinical content models – including before any are complete. The release and deployment of each model (template) requires no changes at all to openEHR-based EHR back-end implementations, i.e. services and database; changes / additions are limited to user screens and content-specific logic.

The outcome of such a program of coordinated clinical content standardisation provides a long term and sustainable national approach to developing, maintaining and governing jurisdictional health data specifications. It can form the backbone for a national health data strategy and is a key way to ensure that clinicians contribute their expertise to jurisdictional and organisational eHealth programs.

Download as PDF: 2014 07 openEHR approach.pdf

Dr Heather Leslie

Clinical Programme Lead, openEHR Foundation

Director of Clinical Modelling, Ocean Informatics

heather.leslie@oceaninformatics.com

July, 2014

[1] http://www.openEHR.org

[2] http://www.openehr.org/programs/specification/releases/1.0.2

[3] http://www.openehr.org/ckm/

[4]Jean-Francois Noubel - http://www.community-intelligence.com/blogs/public/archives/000226.html