Background

As of August 2024 the International CKM reports 365 Change Requests (CR) in 212 archetypes.

This includes demographic archetypes and all ‘open’ and ‘in-process’ CRs for the entire CKM content. Note that there are also 9 CRs for Templates outstanding.

This process document describes an approach to prioritising and processing these CRs.

Please note that the CPB or the openEHR Board has not yet approved this process document, and it remains in draft form.

Approach

This outline process is subject to revision as the CPB and other team members apply it to CR management as and when new issues or other methods are discovered during the application of the process.

Prioritisation

The CPB will address ‘high value’ CRs first by ranking them using a scoring methodology based on their complexity and benefit. Lower-ranking CRs will not be prioritised at this time but will need to be addressed in due course, probably alongside the CR management for higher-value items, once this process is operational.

Demographics

This CR process will not be applied to CRs for Demographic Model Archetypes. Similarly to the lower-priority EHR archetypes, demographic model archetype CRs will be addressed in the future once this process is refined and operational. There are 15 CRs for 9 archetypes outstanding for the demographic model.

CR Managers

CPB chairs will lead CR management, but each CR will require the input of at least 2 independent reviewers other than the CR requestor. CR teams will report to the CPB. Team members will be CPB members in the first instance or from the expert openEHR community where CPB members cannot support the specific CR.

Managing new CRs

In addition to processing the backlog of CRs, we need to manage new CRs as they arise to reduce the total number of outstanding CRs.

New CRs will not be subject to prioritisation scoring and should be managed simply in order of submission.

One of the benefits of this parallel approach is that the CR requestor should be active and available for discussion. If we add more to the backlog, then the context of the CR and the availability of the requestor may be harder to recall by the time we can process it.

Managing new CRs in this way should commence as soon as possible after this process is implemented for the backlog.

Process

This section describes the steps and processes for managing the backlog of CRs, as illustrated in the process diagram below. Currently, the process does not include managing ‘lower priority’ CRs, demographic model CRs, template CRs, and new CRs. All these outstanding requirements will need to be addressed as we progress through the backlog and better understand the pipeline's throughput and resourcing requirements.

Tracking

CRs will be imported in the Clinical Program Jira Project (not the CPB Project) using a custom issue type, and via *.csv file created from exported data from CKM. This is quite a complex process and will probably just be a ‘one-off’ event rather than used routinely.

The CRs can then be managed in Jira as this will allow the CR managers to link issues and dependencies, have multiple, dated contributions and custom status values.

Selecting CRs for initial review and prioritisation

In the first instance the team needs to prioritise and review CRs to scope and direct the required work. This needs CR managers to review the CRs and apply a priority score using the methodology described below. Ideally each CR will be reviewed by 2 people.

A method for selecting CRs in Jira for this process will need to be agreed. We should aim to review them first chronologically by CKM Created Date, and for CRs that apply to Published archetypes.

We need to avoid duplication of work so we need a way to filter or sort CRs based on prioritisation status and who has reviewed them.

This initial review may also lead to other actions:

• Closing the CR as it is no longer relevant

• Splitting a CR into multiple other (linked) CRs where a CR in CKM contains more than one request

• Linking CRs together where dependencies can be identified

Archetype status

In the first instance we will look at CRs that apply to ‘published’ archetypes.

Once this is complete we will review CRs that relate to archetypes with a status of ‘Draft’ and then ‘Team review’.

Is it still relevant?

The CR manager should review the CR to ensure it remains relevant. For example, has any subsequent change resolved it, or has the archetype been superseded in some way? Do the CR comment notes indicate that the status is incorrect? For example, could it be ‘closed’?

If it appears that the CR is no longer relevant, the CR manager should confirm this with another reviewer. If both are in agreement, the CR should be updated with a note and its status changed to ‘closed’ in both CKM and Jira.

Otherwise, the CR should be scored for prioritisation.

Priority scoring

CR managers should score the CR using an estimation of its complexity and potential benefit using the grid below:

Open

The scores should be recorded in the Jira issue and a note made on the reasoning used.

If the agreed score is 5 or more, then, for now, the CR is not prioritised for review via this current process.

If the agreed score is 4 or less, this process will actively manage the CR and progress to the next steps.

A CR may be flagged as ‘priority’ in CKM by the requestor. This should influence the benefit rating allocated by this process, if the ‘priority’ flag=true then CR managers may rank the benefit of the CR higher.

Establishing if there is an active requestor or community

To progress, a CR will require an active requestor or community for that archetype, as they will need to be engaged in the discussion to bring it to resolution.

The first step for the CR managers is to establish contact with the requestor or other members of the archetype’s community, probably from the adopters (if any).

If no one can be located to act in this role, a note should be added to the CR in Jira and CKM to this effect.

The CR should be highlighted to the CPB. CPB should discuss and agree on how to manage the CR going forward.

Does the CR need further refinement?

If the CR is ambiguous or non-specific or needs further discussion by the community, the CR managers should progress this in discussion with the archetype's principal stakeholders, who would be the archetype's original author, editors, and adopters.

• If this process cannot agree on an outcome for the CR, it should be escalated to the CPB for further discussion.

• This process may close (reject) a CR. This should be agreed by at least two reviewers. The status should be changed in both Jira and CKM, and a note made in CKM describing the decision reasoning.

• This process may agree upon a CR, and changes to the archetype will need to be made.

Changing the archetype in a branch

The agreed changes should be made (by the CR Managers or the Archetype Editors) in a new branch in CKM, but not yet committed.

The intended change should be posted to the openEHR community via Discourse, and a link should be provided to the changed content model.

If there are no objections or further queries after a week (or agreed period), the change should be committed to the trunk.

The outcome should be added to the the Jira issue and as a comment to CKM CR. The CR status should be closed in Jira and CKM.

CPB review of blocked CRs

Through this process, some CRs may become stuck. This could be because no owner/author or lead can be found to progress the CR, or an agreement cannot be reached. Other circumstances will likely occur where a CR is blocked with no clear route to resolution.

Where this occurs, the CR should first be posted to the openEHR Discourse community to obtain further input and discussion.

If this does not result in any progress, then the CR will be brought to the CPB for discussion to decide on the next steps. The CPB should ensure that a decision is made to allow the CR to be unblocked.

CRs scored at 5 or more

As this process is implemented and progress is made, the CR managers should agree on a method for starting to process these items. The exact timing and approach can be decided later.

Process Diagram

Needs updated as of 30th Aug.