Introduction

This document describes the terms of reference (ToR) for the activities of the openEHR Specification Program. The Specification Program has members drawn from the wider openEHR membership. Ideally the membership of the Program will include individuals from multiple language groups, cultures as well as with a diversity of technical, clinical and informatics backgrounds.

Status

This document is currently in pre-version 1.0 development. The development process is described here .

Change Log

Version	Change description	Who	Completed
0.93	Incorporate detailed feedback from Koray Atalag (U of Auckland, NZ): Improve consensus-based decision-making process of EC. Added conflicts of interest subsection in the Qualification section. Improved resignation rules. Added section on communications with other openEHR Programs.	T Beale	28 Apr 2012
0.92	Incorporate detailed feedback from Pablo Pazos (Uruguay). Added content to do with publicity and communications activities.	T Beale	26 Apr 2012
0.9	Incorporate feedback from David Moner (UPV) - scrap 'stacking' rule for single CMGs and SAGs (since these groups can have 1 member); strengthen qualification experience and adjust for SAG members.	T Beale	22 Apr 2012
0.8	Incorporate detailed feedback from Ken Rubin (HP), Stephen Chu (Nehta)	T Beale	03 Apr 2012
0.5	Initial development	T Beale	23 Mar 2012

References

Useful references from elsewhere in the e-health standards world:

HL7 Decision Making Practices

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

Group	Component	Documentary Specification	Computable / formal expressions	Description
CORE
Requirements	Standards conformance	ISO 18308 Conformance statement		Document describing conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures".
Architecture	Architecture	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	EHR IM	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...
	Terminology	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.
	Querying	Archetype Query Language, a-path	AQL grammar, a-path grammar
non-CORE
Implementation	XML	XML development guide	XSDs for all relevant specifications
		TDS (XSD) specification
	Java	Java development guide	Template => Java converter
		TDO specification
	.Net	.Net development guide	Template => .Net converter
		TDO specification
	Form languages	future: Form generation specification
		future: User interface specifications
	etc
Education	TBD	TBD	code samples
Standards Interfaces	ISO 13606	future: standardised mapping / converged model
	HL7v2	future: standard openEHR template library for message interfacing
	HL7 CDA	future: transformation algorithms
	ASTM CCR	future: Standard archetype / template expression.

Program Structure

The Specification Program consists of an Editorial Committee (EC), and two kinds of Groups - Component Maintainer Groups (CMGs), and Standards Advisory Groups (SAGs). CMGs are classified as 'core' and 'implementation-related'.

The Editorial Committee membership consists of 1 representative from each CMG and has up to 3 co-chairs.

The following chart illustrates the structure. Initial membership of the Program starts with membership of a CMG and/or SAG (PPT source here ).

Editorial Committee

The Program has an Editorial Committee (EC) which is the formal body for review and decision-making.

Responsibilities

The responsibilities of the Editorial Committee are:

maintaining the Roadmap:
- the identification & creation of new specifications;
- the definition of new releases;
- the prioritisation of CRs,
- the assignment of CRs to future releases;
PR/CR processing:
- the review of PRs;
- the raising of CRs either in response to PRs or de novo, according to perceived need;
- promotion of specifications through lifecycle states;
communication to the wider openEHR community of:
- roadmap changes
- CR reviews;
- completed CRs;
- new Releases.
publishing of the specifications and other materials.

In addition, the openEHR Operational Group may advise of requirements for releases and prioritisation of work.

The responsibilities of the co-chairs are as follows:

to run EC meetings;
to facilitate the execution of the work of the EC;
to arbitrate in case of disputes.

These processes are described in detail in the Change Management Plan .

Decision-making

Decisions are primarily made by consensus, i.e. general agreement with no serious objections voiced. Where there are objections, the following process will be used:

the co-chairs will manage a more formal round of discussions which seek to expose the points of difference and disagreement;
If this fails to result in consensus, the cochairs will facilitate an open community review of the issue with a fixed timeline;
The results of the community review will be the basis of a further round of discussions within the EC aimed at finding a consensus decsion;
If this still fails, a formal 2/3 majority vote will be taken, unless objections to this route are voiced from within the EC.

Where there is any outstanding dispute, it can be by the EC co-hairs to referred to the openEHR Operational Group for resolution. This may require an extraordinary meeting / conference.

Membership

The EC membership consists of one representative from each CMG and each SAG. Each CMG and SAG must have a distinct representative on the EC, in order to ensure that a dedicated person takes responsibility for representing the relevant interests.

Up to three, and preferably at least two, EC members are elected as co-chairs by the Program membership.

Membership of the Editorial Committee is for 2 years. New members come from nominations among the Program membership. At least one candidate is required from each CMG and SAG. Candidates are elected to the EC by the whole Program membership voting for each CMG / SAG position on the EC from among the candidates for that position.

Elections are held every 12 months, at a fixed date, or earlier in the case of resignation. At election time, the positions of all EC members who have spent 2 years in the position come up for re-election by the whole Program membership. Members who are not co-chairs may re-nominate directly for EC membership.

Co-chair positions last 2 years. Elections are held every 12 months at a fixed date, or earlier in the case of resignation. A vacating co-chair may not re-nominate for a successive term but may re-nominate after at least one 12 month period since the previous term served.

Component Maintainer Groups (CMGs)

Most Program members are members of one or more component maintainer groups (CMGs), where each component has such a group.

Responsibilities

The responsibilities of a CMG are:

to perform the execution of changes in CRs accepted by the Editorial Committee for that component, either directly, or by obtaining external expertise where agreed with the Editorial Committee;
(any external communications needed?)

Membership

A Program member can be in one or more CMGs, according to breadth of expertise. Each core CMG requires a minimum of 3 members. Non-core CMGs must have at least 1 member.

Each member must be sufficiently technically qualified to understand the relevant specifications / artefacts, and be able to participate actively in the processing of changes to the artefacts in that component.

The membership of each CMG is recorded online at the SPEC tracker location .

There is no limit on the duration of CMG membership, as long as the participation and competence are maintained, and the Program Fairness Rules are not broken.

Creation

A new core CMG is created by the EC, based on the requirement for a new specification component. It must be created with at least 3 members.

A new non-core CMG is created based on a successful proposal by any Program member to the EC, which details:

the purpose of the CMG;
the relevance to openEHR and the wider community;
the initial membership (at least one member must be proposed).

Standards Advisory Groups

In addition to the EC and CMGs, there are Standards Advisory Groups (SAGs) for interfacing with de jure standards development organisations (SDOs). The SAGs exist to address the existing gaps between SDO offerings (and those of non-SDOs like openEHR), which are a critical problem that needs to be resolved for major stakeholders, such as national e-health programmes and major vendors, because it prevents the individual offerings, no matter how good, from being easily adopted.

Each SAG is constituted for a particular standard or group of related standards managed by an official standards organisation, e.g. ISO 13606, SNOMED CT, etc.

Responsibilities

The responsibilities of a SAG are as follows:

To track the relevant standard and to advise if there are features that might affect openEHR specifications, e.g. should be incorporated, should be aligned to, or might require transformational tools;
To offer relevant openEHR specifications to the standards body, either as input to standards development, or as a formal standards proposal. (Finalising such a proposal would be an openEHR board decision and generally would involve an organisation - organisation MOU and legal advice);
To work on diminishing, removing and bridging the philosophical and engineering differences between specifications of openEHR and other SDOs. Practical efforts here may include:
- aligning jargon in documentation and other published material;
- making sure that openEHR specifications have a defined relationship to extant SDO standards;
- providing educational materials;
- proposing specifications that support data conversion,
- proposing specifications that support software interoperation and other integration approaches.
To act as the openEHR official liaison to the relevant SDO of subgroup thereof.

Membership

Each Standards Advisory Group includes members from the Specification Program who are knowledgeable about the standard and/or are directly involved in the relevant organisation's work. Each SAP elects one member as the representative to the EC. The Standards Advisory Groups do not create openEHR specifications, rather they create formal proposals for a) change to openEHR specifications - ultimately resulting in CRs and b) the target SDOs.

The membership of each SAG is recorded online at the SPEC tracker location .

Creation

A new SAG is created based on a successful proposal by any Program member to the EC, which details:

what particular SDO or SDO standards are proposed as the basis for the SAG;
the relevance to openEHR and the wider community;
how the SAG responsibilities will be performed
the initial membership (at least one member must be proposed).

Size

There is no maximum number of members of the Program. In the future it may well be possible that with say 8 core CMGs, 4 non-core CMGs and 4 SAGs, the membership could be as high as 50. The minimum number of members is that required to satisfy the 3 member-per-Component Maintainer Group rule (below). Since a Program member can be a member of more than one maintainer group, the actual total membership is variable.

Fairness

To ensure fairness and representativeness of the Program, the following rules are provided.

Core CMGs must have at least 3 members.
The EC must have one representative from each core CMG.
The EC must have at least 2 co-chairs.
The EC can have no more than two members from a single organisation, i.e. company, university, government agency, NGO or other enterprise.

If any of the above rules is broken by resignation, change of employer or other events, the appropriate election or other action will be taken.

Group Membership

This section describes the conditions for membership in CMGs and SAGs.

Qualifying Criteria

New members of the Specifications Program join as a member of one or more CMGs and/or SAGs. New nominations may be made in the following situations:

The Specification Program advertises within the community for a new member, e.g. due to a resignation, or need for more human resource;
Positions being available within the CMGs and SAGs, due to the CMG/SAG being too small (1 or 2 members), or the CMG/SAG requesting more members.

Note that the membership status of the CMGs and SAGs will be posted at all times, including vacancies / requests for participation.

A prospective new Specification Program candidate self-nominates as a member of one or more CMGs and/or SAGs. The nomination requires the support of two existing Program members. The candidate must satisfy the following criteria.

Qualifications

An understanding of the overall openEHR mission.
Health informatics background: a demonstrable knowledge of key health informatics issues such as EHR, interoperability, terminology, clinical environments, public health, medical research.
Technical competency: a knowledge of the modelling / language formalisms relevant to the proposed CMGs and/or SAGs.
openEHR experience: at least 1 year of active participation in the openEHR community and
- for CMGs: at least 1 year direct involvement in an openEHR implementation;
- for SAGs: at least 1 year involvement in a de jure standards body.

Commitment

An expressed interest in actively working on the specifications.
Availability to contribute sufficient time to perform the work, expected to be a minimum of 4h / week.

Conflicts of Interest

Any potential conflicts of interest must be declared by the candidate, and the candidate must agree to indicate any such conflict of interest in discussions and decision-making processes of the Program in which they are involved.

In addition, a successful nomination cannot cause any of the Program Fairness rules to be broken.

Candidature

The candidate should supply a CV and other qualifying information describing:

which CMGs and/or SAGs the candidate proposes to work on (at least one);
statement of interest in working on the Specification Program;
statement of commitment of time & availability;
statement of qualifications, according to the above list;
statement of known conflicts of interest.

Process

The process is as follows:

A new nomination is sent to any co-chair of the Editorial Committee, who will publish it to the current Program membership.
A period of up to 4 weeks may follow to allow for assessment by the membership. During this period:
- the candidate may be asked for more information;
- the candidate may be asked to participate in an online or face to face interview;
- the nomination may be rejected on formal grounds, such as lack of qualification;
If the nomination is not rejected, a formal vote is taken, in which the new member is accepted into the Program based on a 2/3 majority vote of the existing members.

Length of membership

There is no limit on duration of membership of the Program, as long as the participation and competence are maintained, and the Program membership rules are not broken. Membership of the EC and co-chair positions are limited to 2 years and are filled by election (described in the relevant section above).

Resignation

An existing Program member may resign at any time from the EC, and additionally from all involvement. In either case, the fact and effective date of resignation will be published, and the published Program membership updated accordingly.

If the resignation is of an EC co-chair, nominations for a new co-chair are called for, and the EC rules for co-chair election described above followed.

If the resignation is of any EC member, another member of the resignee's CMG or SAG are invited to fill the position on the EC.

If the departure leaves a CMG (see below) with less than 3 members then a new volunteer for the relevant component is sought initially from within the Program . If none is found, a new nomination is sought from the general membership.

Termination

An existing member who has been referred to the openEHR board by the Editorial Committee for disruptive or other unprofessional behaviour may be removed by he openEHR board following an appeal process, if all attempts at arbitration fail.

Where termination leaves a vacancy, the same rules as for resignations are followed.

Communications

With other Programs

The Specification Program needs to maintain communications with the other openEHR Programs on a fairly constant basis. Necessary communications include:

Clinical Models Program: TBD
Software Program: TBD
Localisation Program: TBD

Do we need official liaisons? How should other Programs be represented on the Spec Program (they need to be, since specifications affect everyone)?

With the wider openEHR Community

In order to keep the openEHR community at large informed about events in the Specification Program, regular and visible communications is needed. These include the following:

All governance documents are posted on the openEHR web.
The current membership of the Program, including Editorial Committee, CMGs and SAGs is posted and maintained on a wiki page.
The current roadmap of future releases and proposed Change Requests is posted in a visible place.
A way of clearly communicating completed Change Requests and new releases of openEHR is available.

Meetings

At least one face to face meeting, open to the Program membership is required per year. Ideally elections would be held at this meeting.

Online meetings of the Editorial Committee are held by teleconference at least once a quarter, in order to discuss pending PRs and CRs.

Professional Conduct

In order for the SpecP development and decision-making processes to occur efficiently, and to provide an enjoyable experience for participants, contributions should follow the following guidelines:

contributions to discussions and debates should be based on considerations (e.g. technical, clinical) relevant to the matter at hand;
debates (online and face to face) should be conducted in a professional manner, without emotion, with a willingness to follow the governance principles stated here, and in cases of dispute, to accept the outcome of arbitration.

In the unlikely event of a member's participation causing problems, the matter should be referred to in the first instance to the chair of the Editorial Committee, and if necessary, an extraordinary meeting or meetings called for the purpose of arbitration. Arbitration will proceed with the Editorial Committee. If an agreement cannot be reached this way, the matter will be referred to the openEHR Board.

Evolution of these Terms of Reference

The governance structures and procedures described above will inevitably need to change over time. The process for proposing and executing changes is as follows:

A change can be proposed by anyone within the Program, or by the openEHR board. This request should include a statement of the problem being experienced with the current governance.
The EC co-chairs undertake to refine the request into a specific change in the rules that addresses the problem.
This is then published within the EC for review for a stated period, e.g. 4 weeks.
Further refinement may be carried out on the back of the review.
A final detailed proposal is presented to the openEHR board by the EC co-chairs.
If accepted, the change is publicly notified to take effect on a certain date, at which time the governance provisions here are modified accordingly.

Frequently Asked Questions

What stops one company / organisation having undue influence?

Any number of people from a given organisation can participate in the Specification Program. However, two rules are designed to ensure that no single organisation can have an inappropriate influence. The first is that no organisation can have a majority of the members on any given CMG or SAG; the second is that no more than 2 members from a single organisation can work on the EC simultaneously.