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==