Specification Progam Charter


This page is a working area for the description of the openEHR Specification Program. The completed documents will move at some point to an official location, most likely on the openEHR website.


These governance documents have benefited from review by a number of people. In particular, the following provided feedback and changes:

  • Koray Atalag, PhD, University of Auckland, New Zealand;
  • Stephen Chu, MD, NeHTA - detailed review and specific input on quality criteria, priorities and professional conduct;
  • Sam Heard MD, Chair openEHR Foundation;
  • Prof David Ingram, founder of openEHR, professor emeritus University College London;
  • Alan James, PhD, senior architect GE Health;
  • David Moner, Polytechnic University, Valencia
  • Pablo Pazos Gutiérrez, medical informatics consultant, Uruguay;
  • Ken Rubin, HP - provided detailed feedback on process and structure;
  • Erik Sundvall, Linköping University, Sweden - provided feedback on IP and licensing.


The goals of the Specification Program include:

  • quality in health information: to enable data quality, validity, reliability, consistency and currency of clinical data across the data lifecycle from creation to archival, and across enterprises and sectors;
  • support current technology: to actively support widely used ICT technologies e.g. major programming languages and frameworks;
  • de jure standards connections: to provide means for the specifications to be useful to users of related de jure standards, e.g. by providing additional transformation or mapping specifications and/or implementation guides;
  • manage impact of change: to ensure the preservation of validity of clinical data created according to previous releases of the openEHR specifications.


The openEHR Specification Program is the part of openEHR that develops, manages and maintains specifications and their computable expressions, in support of the openEHR goal to enable the development and deployment of open, interoperable and computable patient-centric health information systems. The responsibilities of the Program are:

  • to build and maintain quality of the specifications library
  • to ensure the utility and relevance of the specifications to the larger e-health community
  • to work with de jure standards development organisations (SDOs) to improve the coherence and robustness and reduce the cost of use of formal standards.

The Program achieves its goals in the following way:

  • By developing new technical specifications where required by the community;
  • By accepting and adapting donated specifications;
  • By managing and maintaining the openEHR specifications in a coherent way, so that they satisfy the needs of production systems/solutions developers, application and data users (including patients), and user organisations.
  • By making all specifications openly available and free to use, under liberal open source / content licenses.


In order to realise the mission, the Specification Program adopts the following quality criteria for its work.

  • clear scope: the scope of any specification or computable artefact should be clearly described, indicating which use cases, situations etc, for which the artefact is appropriate.
  • modularity: the specifications should be organised into a set of components, following basic principles of low coupling and uni-directional dependence, enabling a) incremental deployability and b) limited impact of any given change to a particular specification.
  • 'designed': the specifications are not created by committees, but designed in an appropriate technical way for the given artefact, based on the following precepts:
    • requirements-based: the development process includes a requirements capture phase in which requirements are either documented de novo, or obtained by research and communication with the community. This ensures a) that it is stated what requirements a specification tries to satisfy and b) provides the specification user an idea of its valid scope.
    • theory-based: a clear design philosophy should be evident and stated in all specifications. References to published works should be included where relevant.
    • evidence-based: the models and specifications must be based on evidence: knowledge of how well current implementations have functioned; knowledge of clinical data and workflow; knowledge of real use cases.
  • coherent: the specifications are all mutually compatible, forming a coherent whole. No specifications are added or changes made that cause inconsistencies within the specification library.
  • comprehensible: the specifications must be easily understandable to a person with the appropriate general competencies; complexity of models and documentation must be consciously managed.
  • unambiguous: particular effort should be made to eliminate the possibility of misinterpretation, misuse, and inconsistency in use.
  • computable: all specifications describing formal models and languages should have an associated computable expression available for tool use. The computable expression should have the same semantics as the documentary form (ideally it would be used to generate some / all of the documentary form, but this is not always practically possible). Specifications which are essentially guides or overviews do not need formal expressions, although concrete examples in the form of code etc are always encouraged.
  • implementable: all formal specifications have expressions in implementation technologies. In any given technology, usually only a partial view of a specification can be expressed, and there may be semantic differences. For example in XML Schema, behaviour, some constraints and inheritance are not available, or are substantially different to these things in the core specifications. Nevertheless, XML schema is widely used, hence the need for a normative expression of the relevant specifications.
  • change-managed: the specifications are managed over time in a known way, i.e. following industry norms for versioning, releases and so on. The versioning rules at semver.org are applied to all specifications (although they may not have been in the past, i.e. prior to current governance rules). Issue trackers are used to record problem reports and change requests. Breaking or major changes are assigned to major releases, and impact carefully assessed before proceeding.

Achieving these is a combination of good judgement, engineering and the use of clear governance.


The openEHR Specification Program manages the specifications and related educational materials as 'components' in two groups. 'Core' components are those covering requirements and architecture, while 'non-core' components cover various implementation technologies, as well as education. The following is an indicative list.



Documentary Specification

Computable / formal expressions








Standards conformance

ISO 18308 Conformance statement


Document describing conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures".



Architecture Overview


"Read me first" document for the whole architecture. provides a summary of the reference, archetype and service models, and describes global semantics.


Reference Model


UML source files; XMI;
openEHR BMM models

The information model of the openEHR EHR.



EHR Extract IM


The information model of the EHR Extract, which is a serilialisation of content from an EHR.



Common IM


Information model containing common concepts, including the archetype-enabling LOCATABLE class, party references, audits and attestations, change control, and authored resources.



Data Structures IM


Information model of data structures, incuding a powerful model of HISTORY and EVENT.



Data Types IM


Information model of data types, including quantities, date/times, plain and coded text, time specification, multimedia and URIs.



Support IM


Support model defining identifiers, assumed types, and terminology interface specification used in the rest of the specifications.


Archetype Model

ADL 1.4

UML source files

Abstract syntax specification for archetypes 1.4 edition of language (used in ISO 13606-2).



AOM 1.4


Object model of archetypes corresponding to ADL 1.4.



ADL 1.5


ADL 1.5 draft: ADL now includes dedicated section on specialisation, many new examples, improved descriptions and corrections of errors.



AOM 1.5


AOM 1.5 draft - the AOM description now includes uniquely identified formally testable validity conditions (suitable for output by compilers), revised primitive types, improved ontology section, and constraint model extended to represent differential archetypes.



Template model


Object model of templates.


Service Model

EHR Service, etc

WSDL files; WADL files...




openEHR Vocabulary

XML source file

Documentary form of the openEHR terminology, which is a set of vocabularies and code sets used by the reference and archetype models.



Archetype Query Language, a-path

AQL grammar, a-path grammar









XML development guide

XSDs for all relevant specifications




TDS (XSD) specification





Java development guide

Template => Java converter




TDO specification





.Net development guide

Template => .Net converter




TDO specification




Form languages

future: Form generation specification





future: User interface specifications











code samples


Standards Interfaces

ISO 13606

future: standardised mapping /
converged model




future: standard openEHR template
library for message interfacing





future: transformation algorithms





future: Standard archetype /
template expression.




The operation of the Specification Program is governed by its Terms of Reference, which defines its structure, how its membership works and its decision-making processes. The Program operates as an open meritocracy in which qualified persons from the wider openEHR community obtain positions of responsibility in the Program based on their recognised expertise and interest in the Program mission.

Creating the terms of reference for a program with the above scope and mission is not critical. This page describes the migration process, currently underway. The current draft of the Terms of Reference is here .

Change Management Plan

The details of how the various artefacts are managed is described in the Change Management Plan (CMP). This details the lifecycle of each kind of artefact, and the processes followed by the various constituted groups and committees of the Program to manage its evolution.

Intellectual Property and Licensing

The Specification Program generates artefacts which are intended to be freely usable by all stakeholder types, including commercial enterprises. Controlled copyright, and open source and content licenses are used to achieve these aims. The IP rights and licensing are described here .

Outreach and Training