Program Board

Governance

Revision History

Issue	Description	Who	Accepted	Date
1.0.0	Initial Writing	T Beale	K Atalag MD (University of Auckland), R Chen MD (Cambio Health Systems, Sweden), G Klein MD (Örebro University School of Business), I McNicoll MD (FreshEhr), T Nordheim Alme MD (DIPS asa Norway), S Iancu (Code24, Netherlands)	19 Dec 2014

Introduction

This page and the associated Change Process page constitute the terms of reference (ToR) for the openEHR Specification Program. The Specification Program has members drawn from the wider openEHR membership, particularly openEHR solution vendors and other implementers for whom the specifications are of concrete importance. 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.

The sections below describe in detail how the Specifications Program functions. The essentials are as follows:

A Specifications Editorial Committee (SEC) is the governing body and has between 5 and 40 members, representing major stakeholders, particularly implementers;
The specifications are change-managed and released as separate Components, e.g. 'Reference Model', 'Conformance' etc, each of which has its own visible online Change Tracker, enabling community and public involvement possible at all stages;
A global Problem Tracker is available to the whole community for reporting issues with the specifications;
Decision-making is normally based on consensus, with wider consultation and then formal voting used when no agreement is available.

The governance provisions here are intended to be as lightweight and transparent as possible, with progress depending primarily on a) the experience and goodwill of the members, and b) on high quality tool support for efficient e-working.

Heavy used is made of modern project and issue tracking tools, in order to automate the great majority of the process described here.

The Specifications Program will work closely with the other programs to ensure coherence with outputs of the Clinical Modelling Program, implementability for the Software program, and usability in terms of the Localisation Program.

The following diagram illustrates the Specifications Program.

The Specifications

The specifications under management by the Program are identified 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 site home page.

Each logical Specification within a Component consists of:

a definitive publishable documentary form, typically in PDF and/or HTML format;
the source materials required to create the publishable specification;
a definitive publishable computable form, typically a UML model XMI file, parser grammar(s) and so on;
formal educational materials accompanying the specification, including example uses and files.

At any point in time, a Specification is in one of the lifecycle states: Planned, Development, Trial, Stable, or Retired.

Each specifications Component has a dedicated Change Tracker.

Specifications Editorial Committee (SEC)

The Specification Program is managed by the Specifications Editorial Committee (SEC). The SEC membership consists of community members who are qualified and who have an interest in maintaining the specifications into the future on behalf of the community. The SEC aims to be as representative as possible of the interests of major stakeholders, including vendors, healthcare professionals and government, with implementers having a certain precedence, since it is software products that are directly based on the specifications.

Primarily the work of the SEC consists of change management and publishing (i.e. releasing) of the specifications. Change Management is tool-based, and the change history, current state and projected state of the specifications are always visible online.

A subset of the SEC membership act as designated Component Maintainers, one for each Component, and are responsible for a) managing the relevant Component Change Tracker and b) making and committing changes agreed by the SEC to the specifications.

Between one and three members of the SEC are elected as co-chairs and perform a facilitation role.

Changes are formally documented using Change Requests (CRs), which are uniquely numbered and visible online. A CR has a lifecycle, and if not rejected, will define specific changes to the specification(s) it relates to.

Issues with the specifications can also be formally raised; these are known as Problem Reports (PRs).

The change management process aims to resolve all CRs and PRs within a planned series of releases.

Responsibilities

The responsibilities of the Specification Editorial Committee are:

maintaining the Roadmap, i.e. set of future releases, entailing:
- the identification & creation of new specifications;
- the definition of new releases;
- the prioritisation of CRs and PRs;
- the assignment of CRs and PRs 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;
- implementation of CR changes in the specifications;
- promotion of specifications through lifecycle;
communication to the wider openEHR community of:
- requests for technical input;
- roadmap changes;
- CR reviews;
- completed CRs;
- new Releases;
- changes to governance documents;
- changes to Specification Editorial Committee.
publishing of the specifications and related materials.

These processes are described in detail in the Change process.

In addition, the openEHR Management Board may advise of requirements for releases and prioritisation of work.

Structure

The Specifications Editorial Committee has 1-3 elected co-chairs, who facilitate the work of the committee. The exact number is based on practical needs, and will normally increase with the growth of committee numbers. The responsibilities of the co-chairs are as follows:

to run SEC meetings;
to facilitate the execution of the work of the SEC, mainly by managing completion of modification of task deadlines;
to report progress and issues to the openEHR Management board;
to arbitrate in case of disputes.

In addition, a number of SEC members agree to act as Component Maintainers. This role is to ensure that each Component has at least one member capable of implementing changes determined by the change process on it. A member becomes a Component Maintainer by volunteering, and may resign from the responsibility at any time.

Membership

The minimum membership of the Specification Editorial Committee is determined by the following needs:

to have one member acting as the Maintainer of each Specifications Component;
to have sufficient members from the openEHR Industry Partners to be representative of the interests of implementers;
to have two or more members with health informatics / clinical expertise, who perform clinical impact review.

An absolute minimum of five (5) is required. Beyond this, it is intended that there are members representing:

other major openEHR implementations (including academic).
other major stakeholders, particularly government e-health programmes, and the healthcare sector.

SEC Membership is created initially with the inception of the Specifications Program, and progresses as follows:

New members come from nominations openEHR community which are voted on by the SEC.
Members leave by natural attrition (i.e. resignation).

Maximum membership is limited to 40.

The SEC current membership will be openly posted online at all times.

Qualifying Criteria

Membership of the SEC is by nomination. 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;
Community members, typically representing a newly joined organisation may nominate at any time.

A new nomination must satisfy the following criteria.

Qualifications

An understanding of the overall openEHR mission.
Health informatics background: a demonstrable knowledge of key health informatics areas such as EHR, interoperability, terminology, clinical environments, public health, medical research.
Technical competency: a knowledge of the modelling / language formalisms used in the specifications.
openEHR experience: at least 1 year of active participation in the openEHR community.

Commitment

An expressed interest in actively working on the specifications.
Availability to contribute sufficient time to perform the work, expected to be a few hours a month.

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.

Candidature

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

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 the co-chairs of the Specification Editorial Committee, who will publish it to the committee.
A period of up to 4 weeks may follow to allow for assessment by the current 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 simple majority vote of the existing members, with no objections.

Length of membership

There is no limit on duration of membership in the SEC.

Resignation

An existing Program member may resign at any time from the SEC. In this case, the fact and effective date of resignation will be published, and the published Program membership updated accordingly.

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

If the departure is of a Component Maintainer, the SEC solicits a volunteer to take on the Component.

Termination

An existing member who has been referred to the openEHR board by the Specification 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.

Co-chair Elections

Elections are held every 12 months, at a fixed date, or earlier in the case of resignation. At election time, the positions of 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 SEC 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 re-nominate for a successive term.

Decision-making

Consensus Process

Decisions on change and release management are primarily made by consensus, i.e. agreement of a quorum of members 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 SEC aimed at finding a consensus position;
If this still fails, a formal vote (see below) will be taken, unless objections to this route are voiced from within the SEC.

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

Formal Vote Process

Sometimes a formal vote will be required. This can only occur when there is a quorum of 2/3 of the SEC members available in a face to face meeting or live teleconference / webconference. It may not be undertaken asynchronously. The procedure is as follows:

a motion is tabled;
the motion is seconded;
votes are gathered, with a maximum of one vote per company, institution or other individual;
vote by proxy is allowed, supported by a written confirmation (e.g. email) from the absent voter;
the motion is considered passed if a simple majority (50% + 1) of the SEC membership is obtained.

Meetings

Most work of the SEC is performed via teleconferences, and asynchronously (primarily via the online issue tracker). Online meetings of the SEC are held by teleconference at least once a quarter.

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

Professional Conduct

In order for the SEC 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 Specification Editorial Committee, and if necessary, an extraordinary meeting or meetings called for the purpose of arbitration. Arbitration will proceed with the Specification Editorial Committee. If an agreement cannot be reached this way, the matter will be referred to the openEHR Management 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 Management board. This request should include a statement of the problem being experienced with the current governance.
The SEC co-chairs undertake to refine the request into a specific change in the rules that addresses the problem.
This is then published within the SEC 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 SEC 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 organisation having undue influence?

Where decisions go to a formal vote, each organisation gets only one vote.