Specification Program
Overview
The openEHR Specification Program develops, manages and maintains specifications and their computable expressions, in support of the openEHR goal of enabling the development and deployment of open, interoperable and computable patient-centric health information systems.
The openEHR Specifications Program is managed by its Program Board, the Specifications Editorial Committee (SEC), and is formally governed according to the rules and guidelines in its Terms of Reference (ToR).
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 industry technologies: to actively support the use of widely used ICT technologies e.g. major programming languages and frameworks;
- de jure standards integration: 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.
Responsibilities
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.
Activities
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.
Deliverables
The specifications under management by the Program are defined in terms of Specifications Components, each consisting of one or more concrete Specifications relating to a topic area. A Component is defined as being something that is separately releasable. In openEHR, Components include the Reference Model, the Archetype Model, Querying, Conformance and CDS.
The definitive list of Components at any time is shown in the 'Component' column of the specifications home page.
At any point in time, a Specification is in one of the lifecycle states: Planned, Development, Trial, Stable, or Retired as shown on the Change Process page.
Users of specifications may raise Problem Reports (PRs). Changes made to the specifications as a result are documented in Change Requests (CRs), which are found on the dedicated change tracker for each component. Links to the PR and CR trackers may be found on the specifications home page.
The following diagram illustrates the Specifications Program structure.
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.
- Design: 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 that it is stated what requirements a specification tries to satisfy and 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.
- Coherence: the specifications are all mutually compatible, forming a coherent whole. No specifications are added or changes made that cause inconsistencies within the specification library.
- Comprehensibility: the specifications must be easily understandable to a person with the appropriate general competencies; complexity of models and documentation must be consciously managed.
- Clarity: particular effort should be made to eliminate the possibility of misinterpretation, misuse, and inconsistency in use.
- Computability: 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.
- Implementability: 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-management: 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.