Specification Progam Charter

Status

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.

Acknowledgements

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.

Goals

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.

Mission

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.

Quality

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.

Scope

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.

Governance

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

TBD