Specification Program
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.
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 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.
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.
- 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.