Governance of openEHR Specifications

What is the openEHR Intellectual Property (IP)?

The openEHR Foundation is the custodian of an extensive range of intellectual property which is managed to achieve the aims of its community: robust health record solutions, clinical engagement and trust of the wider community. There are three groups of openEHR IP.

• Specifications and schemas: these are technical documents defining models of information, services and other artefacts for health information and in particular the Electronic Health Record (EHR). The specifications are in three groups:

• Stable: specifications that have been tested in software and are in use in the community;
• Trial: new specifications that have been worked on by a design group and validated in test software to the point where they are ready for community use on a trial basis;
• Development: draft forms of specification documents, made available for the purposes of review, input and limited experimental use.

• Archetypes: these are, for the electronic health record, computable clinical and administrative models of content. The archetype methodology can apply to models other than the EHR model, such as the openEHR demographic model, allowing archetypes for such concepts to be authored as well.
• Open source software: software and related artefacts built according to the specifications or which support implementation of the specifications.

We use the term 'specifications' to refer to the first group, which formally defines the openEHR computing platform. It is the specifications that are seen as being equivalent to official standards such as those issued by HL7 (RIM or CDA release 2 schema), CEN (13606 Parts I and II), ASTM (CCR) and so on. The archetypes and software are built from and both support and depend on the specifications. For this reason, the management of the specifications is very important to the user community, and is taken very seriously by the openEHR Foundation. This FAQ describes the governance of the specifications.

How are the Specifications Managed?

The specifications are in the form of a set of documents and technical artefacts such as XML-schemas, UML diagrams and vocabulary. All are held in a central repository under version control software (see the openEHR Subversion page) which means each change to the specifications is captured and can be rolled back if necessary. At suitable points in time, the whole set of documents is officially released under a release identifier, such as 'Release 1.0' and 'Release 1.0.1'. New minor releases vary in the 3rd digit (e.g. 'Release 1.0.2'), significant releases which remain compatible with existing software vary in the second digit (e.g. 'Release 1.2'), and major new releases are indicated by a new number in the first position, e.g. 'Release 2.0'; in a major release, there are very substantive changes and existing software will have to be updated to cope with changed models or formalisms.

From any given release, e.g. 'Release 1.0', subsequent releases are created by making agreed changes to the specifications. Each change is documented in a Change Request (CR), which documents the whole process of a specific change. In some cases, a CR is preceded by a Problem Report (PR), which simply documents a problem or issue with the openEHR platform. PRs and CRs are managed online using another tool called Jira, which has kindly been provided by Atlassian. Thus every change made to the specifications has an associated CR, and all the documents affected include the CR identifier in their revision history. This means it is possible to see exactly what has changed since the last release and why it was done. The change process used in openEHR is documented in detail in the Change Management Plan.

Who works on the Specifications?

The specifications have historically been developed and maintained by a small Project Group (PG) acting as editors, and bringing in outside expertise to create things like XML schemas, validate modelling elements and so on. The PDF document front pages and revision histories indicate the people involved. Post Release 1.0.1, members of the core project team continue to work on many of the specifications, but in a framework of more diverse work groups. This is possible due to the larger number of organisations and users familiar with Release 1.0 and 1.0.1 of openEHR. The focal point for each specification work group is a wiki page which will usually be established by the head of the work group in the specifications wiki area. Anyone can join the team. Contributors are recognised in the documentation.

Who can Propose Changes?

Any member of the openEHR community can propose a change, including a new specification. They usually do this by raising the issue on a mailing list and discussing it until there is some level of community consensus about the change. If there is a general consensus that there is a problem, but no real idea of the solution, then a PR is raised. A PR can be raised by anyone. If the basic analysis of a solution is available, a CR will usually be raised directly. The purpose of a CR is to document a change done to the specification base. CRs can only be added to the Jira server by a member of the Project Group. PRs and CRs are an integral part of the openEHR IP, and some effort is taken to ensure that the function not just at the original time of raising, but as high quality documentation into the future.

New proposals for specifications can come from anywhere - from industry, individuals, academic institutions or government. There may be competing proposals for a new specification, in which case an open design review process occurs, whose goal is to generate a single specification from the original inputs. The core project team manages this. One of their main goals is to ensure that any specification added to the existing set is completely compatible with them, guaranteeing that the total set of specifications remains coherent for its lifetime.

Who Decides on the Changes?

All changes to the specifications, no matter how small, are documented in a Change Request and are managed by the Architectural Review Board (ARB). This is a group of people who have long term experience in health informatics, EHRs and related topics, and who review all proposed changes. Most ARB members are from organisations that are implementing or using openEHR in a significant way, and have a material interest in correct management of change. The ARB operates according to a published Terms of Reference. The basic voting procedure is that a PR or CR has to be acted upon within 1 month of being raised, and that votes are by simple majority. The decision process of the ARB is illustrated in the Change Management Plan, and can be summarised as follows:

• Initially, the Project Group reviews the CR. If there is a PR, sufficient analysis will be done to create a CR that indicates what kind of change will be made to solve the reported problem.
• If the proposed change does not change the design or requirements of the openEHR platform, and has low impact, and requires minimal effort to implement, the Project Group will implement the change and pass it by the ARB for review. This is the case for documentary typos, and obvious errors in the text of a specification. Usually the change would be made in the next minor release, although the ARB may decide otherwise.
• For all other changes, the ARB performs the analysis, and uses a formal voting process to decide what to do with the change request.
• For a CR that has been approved, a target release will be decided. For releases later than Release 1.0, this is a key decision, and may be done in consultation with the community, by notifying the community of CR, including an impact analysis, description of the change, and proposed target release. A decision on target release is arrived at by online discussion. The input of strategic users and implementers would normally be expected to carry the most weight.
• Once a target release is decided, the changes are made in the Subversion server in a copy of the specifications corresponding to the candidate for the target release.
• Changes are validated, where possible by implementation in code and/or XML-schema or other relevant implementation technologies.
• Once the changes are complete and validated, the ARB reviews the result and votes on whether to accept it.
• If accepted, the CR is closed, and the changes are made part of the target release (e.g. by tagging in Subversion).

The community can review the changes at any time in the process and provide input.

What About New Specifications?

New specifications are treated in the same way as normal changes at the CR level: the ARB will propose a target release and timeline for the appearance of drafts. However, they do involve a greater degree of design and review work. This is carried out using a process based on the OMG's process, as follows:

• Candidate proposals for a given specification are made available on the openEHR.org website.
• A wiki page is created for discussion of the new specification, and the community invited to provide input.
• A design group is formed whose job it is to create the new specification based on the candidates. Authors of the candidate proposals would usually be members of this group.
• This group creates the new specification by working together online or in physical meetings, and provides a draft version at each agreed timepoint.
• The result of the work will be a version 1.0 specification, which if accepted by the ARB, will be release with the status of 'for trial use' in the next (or an agreed) release of openEHR.
• The status of the specification will move to 'Stable' after a period during which user organisations use and provide feedback. This will typically be a year.

What Protection is there against a Change 'breaking' openEHR in some way?

For strategic users and vendors of openEHR-based products, clearly there is a need for controlled change. Some kinds of change would have serious repercussions on software, archetypes, systems. The mechanisms described above are designed to prevent such problems, while still allowing progress, and can be summarised from the point of view of impact:

• strategic users and implementers are generally represented on the ARB, and can directly influence the trajectory of a change;
• there are guidelines in the Change Management Plan for what kinds of releases are appropriate for a certain kind of change.

What is the History of openEHR Changes so far?

The existing releases can be seen here.

What is the Roadmap for the Future?

The plan for the current year is described in the roadmap document. A detailed view of CRs and releases is available in the issue tracker.