|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|
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:
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 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 current baseline specifications page.
Each logical Specification within a Component consists of:
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.
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.
The responsibilities of the Specification Editorial Committee are:
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.
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:
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.
The minimum membership of the Specification Editorial Committee is determined by the following needs:
An absolute minimum of five (5) is required. Beyond this, it is intended that there are members representing:
SEC Membership is created initially with the inception of the Specifications Program, and progresses as follows:
Maximum membership is limited to 40.
The SEC current membership will be openly posted online at all times.
Membership of the SEC is by nomination. New nominations may be made in the following situations:
A new nomination must satisfy the following criteria.
The candidate should supply a short CV and other qualifying information describing:
The process is as follows:
There is no limit on duration of membership in the SEC.
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.
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.
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.
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:
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.
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:
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.
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:
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.
The governance structures and procedures described above will inevitably need to change over time. The process for proposing and executing changes is as follows:
Where decisions go to a formal vote, each organisation gets only one vote.