Release Date: 03-Nov-2025
Deployments: Starting Nov-2025

Table of Contents

Summary of Changes

CKM 1.21.0 is a very large release that addresses a total of

112 issues relating to new or improved functionality,
66 bug fixes, and
15 general tasks relating to upgrades or redesign under the hood.

Selected release highlights are described in the next section, followed by the detailed list of changes.

Selected Release Highlights

Overview of some highlights of the CKM 1.21.0 Release.

Search Improvements

Several enhancements have been made to the Find Resources tab to make search results more accurate and user-friendly. Notably, search terms are now treated more intelligently: quotation marks are honoured to ensure exact phrase matching (e.g., "Blood Pressure"), and special characters like slashes or parentheses no longer break search terms into irrelevant fragments. This means that searches like hl7.org/fhir, “Blood Pressure” or "ITEM_TREE matches" will now yield more precise results.

Additionally, the relevance ordering of results has been further improved: for example if your search exactly matches a resource’s main display name, it is now more likely to appear at the top of the list.

Complementing these changes, the UI has been refined to better display where search terms were found within a resource. Even for more complex searches, CKM now attempts to show the exact location of matches in both metadata and ontology sections. The search input field has also been widened to accommodate longer queries, and the number of matches within a resource is now clearly indicated, making it easier to explore results.

Significant performance improvements have been made to speed up searches and queries, especially for archetypes and templates.

REST API Enhancements

The REST API has been expanded to support more flexible and precise interactions. You can now retrieve archetypes using semantic versions (e.g., 1.0.1) instead of asset versions, and there's a new parameter to directly fetch the latest published version of a resource. This is especially useful for systems that rely on stable, production-ready content.

Additionally, new endpoints have been introduced to list Change Requests and Resource Proposals, complete with filtering options like status, priority, and date ranges. The API now also supports ISO date formats with fractional seconds, improving compatibility with third-party systems.

User and Membership Management Enhancements

The membership and role management experience has been revamped across projects as well as instance-wide roles:

Unified, modern panels: Both the Project Membership panel and the Users Per Roles panel have been redesigned for clarity. They now show all members, invitations, and requests in one view, grouped by role, with quick actions for inviting, accepting, or revoking roles.
Improved Usability: Panels now display user photos, full names, organisation, and country, with a responsive layout and quick-action menus for managing roles and viewing user activity.
Status Indicators: Both panels now highlight user status with clear icons for deactivated or suspended accounts and warnings for users inactive for over a year, including their last login date.

These changes make it easier to manage large teams and keep roles up to date.

In addition, several improvements have been introduced to streamline user administration and enhance security. Admins can now suspend user accounts (e.g., for spammers or malicious users), preventing self-reactivation—unlike the existing deactivation mechanism. Suspensions and reinstatements are audit-logged. When admins manually activate new users, this is now also audit-logged for transparency.

The Users Overview Panel has been reworked with paging support for scalability, displaying up to 500 users per page. It now includes a sortable activity status column to easily identify suspended, deactivated, or inactive users. Additionally, admins can now switch to editing a user profile directly from the (read-only) profile view, saving time when managing accounts.

Template & Archetype Management

Several improvements significantly enhance the handling of archetypes and templates.

CKM now supports direct links to specific semantic or asset versions, including the ability to always link to the latest published version. This is especially useful for sharing stable references in documentation or social media.

When you open an archetype or template that is under reassessment, you’ll be prompted to choose whether to view the latest published version or the latest development version, with an option to remember your preference. Your preference may differ for example depending on whether you are a pure consumer or an editor/developer of the models. The revision history has been aligned with the selected version view (development vs. publication view).

The revision history now includes powerful filtering options, allowing you to filter revisions for example by username, log message, or semantic version.

A new Release Notes view can be displayed from the revision history and provides a clean, exportable and printable (e.g. as PDF) summary of changes over time, ideal for documentation.

A new Markdown rendering feature allows for richer formatting of archetypes in fields like “Purpose” and “Use” and the description of elements.

Validation has also been strengthened during the template upload: uploading templates that use inactive archetypes or templates now trigger warnings.

The overall archetype validation report can now be better filtered, and exported as CSV.

Important information, such as resource status, including for remote archetype as well as the status of terminology bindings, is now more visible, reducing confusion. CKM can now also display inactive SNOMED CT codes inline when detected via a connected terminology server.

Inactive (deprecated or rejected) resources within projects can now be revealed on the Project Dashboard when needed, helping maintain transparency without cluttering the main view.

A new configuration option enables CKM to enforce future-proof template ids that are based on HRID (e.g. org.openehr::openEHR-EHR-COMPOSITION.test.v1.0.1-alpha.12) or, alternatively warn only.

Mappings & Queries

CKM now offers greatly extended support for managing and reporting on secondary models such as FHIR and OMOP mappings, AQL snippets, and subset models.

A new Mappings & Queries Report has been introduced, showing all secondary models (e.g., FHIR, OMOP mappings) associated with resources. It includes indicators for whether a mapping applies to the latest or latest published revision of a resource. This is especially helpful for ensuring mappings remain aligned with evolving archetypes and templates. For convenience, an equivalent report has also been added for each project and subdomain, respectively.

The semantic version and it corresponding status (such as Draft or Published) of FHIRConnect and OMOCL mapping files is extracted from the mapping files on upload and clearly displayed in CKM to avoid any uncertainty about the status of these mappings.

A bulk upload feature has been introduced for FHIRConnect and OMOCL mapping files. Metadata is automatically extracted to associate mappings with the correct archetypes and semantic versions. This streamlines the process of importing large sets of mappings and ensures consistency.

Additionally, mappings can now be attached to remote archetypes, and CKM instance-wide roles have been introduced for managing mappings and queries across all projects.

A new Mappings & Queries tab has been added to Release Sets, allowing editors to include relevant mappings alongside archetypes and templates. These mappings can be versioned or unversioned, and CKM ensures consistency between selected versions of the mappings and their associated archetypes and templates through validation checks.

Change Requests and Editorial Tasks Reporting

The Editorial Tasks and Change Requests dashboards and associated reports have been revamped to offer advanced filtering (e.g. by projects and subdomains, or status), grouping, and CSV export capabilities to help editors to stay on top of governance activities.

The new Detailed View for Change Requests provides a sortable, searchable grid of all requests, making it easier to manage large volumes of feedback.

Review Rounds Management Finetuning

Following up on the changes of the 1.20.0 release, the management of review rounds has been further enhanced. Editors can now start, modify, or add reviewers to review rounds directly from the resource’s Reviews tab, email reviewers from within the review round view, with preselected context, as well as initiate the first review round from the resource view if none exists. To reduce clutter and prevent accidental deletion of review rounds that already contain feedback, the “Delete Review Round” button is now only shown at that place if no reviews have been submitted and confirmation dialogues are now more robust. Additionally, adoption notifications are now only sent to content review initiators, avoiding unnecessary alerts for translation or terminology rounds.

Social Media & SEO Enhancements

CKM now supports BlueSky as a social media platform for automated posts of new and updated archetypes and templates, new review rounds, etc. This is to offer an alternative to CKM’s automated post functionality originally developed for Twitter. Relevant posts now include the semantic version of updated archetypes for clarity.

To improve visibility in search engines and social platforms, CKM now generates better crawler-friendly previews and OpenGraph metadata for archetypes and templates. This ensures that shared links display rich previews, including on platforms like LinkedIn, Discourse, BlueSky, Teams, and Slack, etc.

Direct links to archetypes have been improved to support semantic versions, asset versions, and latest published revisions, as well as using the archetype id instead of the default citeable id making them more robust and shareable. These advanced direct links can be constructed on the “Share with Colleagues” tab available for each archetype and template.

ADL 2.4 AT-Coded Archetype Export

A notable technical improvement in this release is the ability to export ADL2 archetypes as ADL 2.4 using AT-codes. Previously, as per the ADL2 specifications, archetypes in ADL2 were required to use so called ID-codes (e.g., id1, id2), which caused problems especially for existing downstream systems that rely on consistent and stable identifiers. With the ADL 2.4 specifications close to being officially released by openEHR, CKM now ensures that such archetypes are exported using AT-coded identifiers (e.g., at0001, at0002) - identical for both ADL 1.4 and ADL 2.4.

This functionality is based on the latest work in Archie and is to be regarded as experimental because the ADL 2.4 specifications have not officially been released at the time of writing and consequently, the ADL 1.4 to at-coded ADL 2.4 conversion is yet to be finalised.

Performance and Scalability

Significant performance improvements have been made to speed up searches and queries, especially for archetypes and templates. Specific individual queries run roughly 50 times faster (depending on the result set), leading to an overall speed increase for a typical request of roughly factor 3.

Paging has been introduced for user management panels, ensuring smooth navigation even in large CKM instances.

A maximum display limit of 10000 entries has been introduced for very large audit logs to maintain responsiveness.

Caching has also been optimised for example for common downloads, such as ZIP exports of archetypes, which is particularly useful during training sessions or bulk operations.

UI/UX Enhancements

The user interface has seen a wide range of refinements aimed at improving usability and clarity. These include:

Tag-style classification displays for resources, now visible to all users, logged in or not.
A new language selector in the login toolbar now allows users to switch the CKM interface language, with appropriate warnings if tabs will be closed.
Spanish localisation has been added, and other translations have been fine-tuned.
Improved tooltips for remote archetypes, clearly indicating their origin and status.
Icons and layout updates across panels, including new SVG icons for the Resource States such as Draft, Team Review and Published for crisper scaling.
A Countdown timer for planned outages will be available for future update to more directly communicate the outage time globally.
Additionally, CKM now supports preheaders in some email notifications for better previews in some email clients.

Detailed List of Changes

✨New & Improved Functionality

Key	Summary	New or Improved Functionality Description

Key

Summary

New or Improved Functionality Description

CKM-1253

Resource Classification Tab: Use tags to display the individual classifications for read-only purposes

In the Resource Classification tab displayed for each resource, the current classification could use tag-like display if read-only by normal users instead of the grid table:

Old Grid style.

New Tag style.

Users that can edit the classifications for the resource (such as CKAs and editors of the respective project) may still need to have access to the grid in order to quickly remove the classifications from a resource. In this case, this grid should be collapsed and moved underneath the tree view of the ontology.

CKM-1393

Add/replace some of the Dashboard Community Images

Replace some of the not-logged in Dashboard’s Community images (“Become a Part of Our Online Community“) and add additional ones. One image is chosen at random on each load. To be able to show a slightly greater variety of different images without reducing the visibility of some of the images (such as the CKM “C” image), a simple weight-mechanism is being introduced to so that some images are displayed more often than others.

CKM-1468

Find Resources Tab: Don't split the search text into individual fragments quite as eagerly for more focussed search results

Some search strings in the Find Resources tab should not be split into individual components quite as eagerly. This is to improve the relevance of search results in CKM.

In particular:

Non-alphanumeric chars should not be considered as word-breaking when splitting the search text into fragments. E.g. hl7.org/fhir should not yield results if only the individual parts hl7 org fhir are found somewhere in the resource.
Text surrounded by quotation marks should be considered as one text fragment, e.g. "Blood Pressure" is a different search than Blood Pressure. The first yields less results, generally speaking.
Search text fragments that start or end with a non-word character should be found, e.g. a search for "(openEHR Editor)" should yield a result even if the text is …(openEHR Editor)”. Note the )” sequence at the end which is not a word boundary!

Example Search	Expected Result	Change
Blood Pressure	All resources that contain any or all (depending on OR or AND logical connector) words of Blood and Pressure (case-insensitively) in any order. “...I am under pressure and blood is flowing..." would be a match.	None. This was always the case.
"Blood Pressure"	All resources that contain the exact string Blood Pressure, case-insensitively. “...I am under pressure and blood is flowing..." would NOT be a match.	Quotation Marks are now honoured and words not split if they are inside quotation marks. Previously, this would have searched literally for “Blood and/or pressure” (i.e. including the quotation marks, which will rarely yield the desired search results.
hl7.org/fhir	All resources that have the search string included verbatim. NOT included are archetypes where only all (for and search) or any (for or search) of hl7 org fhir are found separately. For example “hl7 is an org that publishes fhir" would NOT yield a result, whereas “hl7.org/fhir is a search text" would yield a result.	Previously, the search text would have been split into in this case 3 words: hl7 org fhir Thus, generally more (inadequate) results would have been found previously, especially in or search.
"hl7.org/fhir"	The expected result is identical to the above.	Previously, the search text would have been split into in this case 3 words and the quotation marks ignored: hl7 org fhir Thus, search results would previously return the exact results as previously for the same string without quotation mark,.
speciali?e	Matches e.g. specialise or specialize	Unchanged.
E-Health	Matches e-health but not e and/or health separately.	Used to match separately.
"(openEHR Editor)"	Matches in …"Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor)", "Bjoern Naess, DIPS ASA, Norway",… Note: The brackets are word breaking chars, but the position between ) and ” is not considered a word break. It still needs to match though whether it is or not, or even if it is the end of the string. (i.e. \b cannot be used to identify the word break here.	Would have matched either openEHR and/or Editor due to the way words were split previously. It would not have matched if the final bracket is followed by a non-word char such as in this case the quotation mark in the text.
“ITEM_TREE matches”	Matches the exact ITEM_TREE matches sequence, but NOT for example: ITEM_TREE at0002 matches This example enables the search for ITEM_TREEs without an at code	Used to match separately, including for example ITEM_TREE at0002 matches

CKM-1493

For resources currently under reassessment, force the user to choose between opening the latest published or the latest development revision including the ability to remember the selection

With more and more published archetypes and templates, it may be desirable that for any resources that have been published but are now under reassessment to open the latest published instead of the latest development revision when

double-clicking on the resource in the left hand panel, or
clicking on its context menu in the left hand panel, or
opening it from a search in the Find Resources tab, or
opening it from a direct link that does not specify any of the following
- explicitly the asset version (e.g. 24)
- explicitly the semantic version (e.g. 1.0.1)
- implicitly the LATEST version (“latest”)
- implicitly the LATEST PUBLISHED version (“latestpublished”)

To avoid confusion, the user is the required to choose between the latest and latest published version of the archetype or template when the resource is being opened:

To do this, the user is presented with a dialogue:

Dialogue to confirm the desired revision of the archetype is opened.

Remember my selection Tooltip: “CKM can remember your selection for the future. You can change the behaviour at any time via Tools/Options & Notifications.”

Because each user has different preferences, in Tools/Options & Notifications, a new select box is added to control the behaviour for each user:

Default revision to open for resources under reassessment:

Latest published
Latest revision (unstable)
Ask me each time

For example, in the screenshot below from the left-hand accordion, the “Age assertion” archetype is currently under reassessment. Therefore, when double-clicking on it, the above dialogue will appear forcing the user to decide on the revision to be displayed.

NB: For REASSESS archetypes from remote, there may under exceptional circumstances not be a PUBLISHED revision. Typically, only those resource versions are imported that are considered usable within the CKM at hand, therefore the best option in this case seems to be to open the latest version.

NB2: Not logged-in users will be presented with the same dialogue each time to select the appropriate revision, albeit without the “Remember my selection” checkbox.

CKM-1513

Rework Project Membership, Invitations & Request panel

The project membership panel including invitations and requests to join a project has been reworked and improved in e.g. the following ways:

Present memberships and requests/invitations on one page making use of CKM-1968 - Users per Role panel rework. This shows a better overview of users with additional information and additional functionality available to editors to go to the user profile, view the user activity etc.
Same style, but in addition to “Add” also have an “Invite” button for editors and a Request to Join Button for non-members. The latter should be available for users without any role in the project so far and is restricted to non-editorial roles (Reviewer, Translator, Terminology Reviewer).
Existing invitation and requests are displayed underneath each role with different colouring and the appropriate actions such as accept, decline or revoke, respectively.
Use full height and possibly make it wider - one problem currently is that there are projects with a lot of reviewers and translators and in this case this is currently not making efficient use of screen real estate.
Various streamlining

Also partially related to the discussion at https://discourse.openehr.org/t/tooling-support-for-inviting-reviewers/2236/15.

Example of the revamped Project Memberships Panel.

CKM-1756

Revision History: Add a filter for username and log message fragments

In the Revision History of a resource, add a Filter to be able to quickly find any revision where any parts of the

log message,
commiter’s login name,
committer’s current first name + last name,
Semantic Revision Number
Commit Date/Time

matches the provided search text.

It is possible to search for more than one word (no partials) in any order or use quotation marks around the whole search text for an exact match only.

All filtering is case-insensitive. If resetting the filter to nothing, ensure that only the trunk is expanded, not the branches.

This functionality can be used to quickly filter commits by users, search for a specific semantic revision number (e.g. 2.0.1), all changes in a year (2024), any log messages mentioning e.g. a particular translation language such as “Norwegian”, etc., a search string with quotation marks like "blood pressure" or "English to Slovenian".

For example:

This a test log message only.

Search Text	Matches?
test	Yes
test log	Yes
log test this	Yes
“test log”	Yes
“log test”	No
“test message”	No

Example search within the revision history of the Blood Pressure archetype. Non-applicable revisions are hidden.

CKM-1765

Improve speed of some frequently used queries, especially for text based searches of archetypes and templates

There are some frequently used queries especially for text based searches of archetypes and templates.

By completely separating the query parts in separate where clauses, some very significant performance benefits have been achieved for archetype and template text searches.

Individual queries run roughly 50 times faster (depending on the result set), leading to an overall speed increase for a typical request of roughly factor 3.

For example: Search for “blood” in “Complete Search” for all resource types:

The core archetype search query: 1.32s -> 0.023s

The total time until fully displayed: 8.58s -> 2.34s

CKM-1778

Remote Archetypes Import/Update Panel: Ability to filter by Resource Status

As editors would often only consider already published archetypes, it is desirable to filter (especially the new) archetypes by their (remote) resource status - e.g. only published ones.

A Checkbox “Published Only” has been added to the Filter Options to restrict to published and reassess states for new and, in addition, “deprecated” archetypes for “Updated Remote Archetypes”.

If unchecked, everything remains as is.

If checked, resulting archetypes are filtered in the following way:

For “New Remote Archetypes”: Restrict results to archetypes with a remote status of Published or any of the reassess states.
For “Updated Remote Archetypes”: In addition to published and reassess states. we also keep any “Deprecated” archetypes. (To be able to deprecate the archetype locally as well if desired.)
Likewise any Warnings and Information is filtered accordingly as well.

Importing Archetypes from Remote: Add Filter Option for Published Archetypes only.

CKM-1836

For resources under reassessment: Align Revision History Publication View and Development View with the revision currently displayed

The distinction between a Publication View and Development View for the Revision History of a resource has been an important recent addition to more clearly differentiate between the governance and consumption of the resources.

However, it is somewhat misleading that for REASSESS resources, a normal user opens the LATEST, but in the revision history, the Publication view is the default view for normal users.

Therefore, for resources under reassessment: Align Revision History Publication View and Development View with the revision currently displayed: With CKM-1493: For resources currently under reassessment, force the user to choose between opening the latest published or the latest development revision, we can now display it according to the currently selected revision.

If you are currently viewing the LATEST revision AND this is different to the LATEST PUBLISHED version, then the Development view should always be displayed by default. (The latest revision would typically be in a REASSESS state in this case.)
If you are currently viewing the LATEST PUBLISHED revision, then the view displayed depends on the user’s role for the resource by default. For example, project editors of the resource’s owning project would see the development view, whereas normal users or users that have not logged in would see the publication view by default. (This behaviour is unchanged).
If you are currently viewing a specific revision (e.g. selected from the revision history directly) that is neither the latest nor the latest published revision:
1. If we know that it is a stable (published) revision, then the same logic as for LATEST PUBLISHED is used (see #2), i.e. it depends on the user’s roles.
2. If we know that it is an unstable (e.g. -alpha) revision, then the Development View should always be displayed by default for all users.
3. If we don’t know the status at the version, then the same logic as for LATEST PUBLISHED is used (see #2), i.e. it depends on the user’s roles.

CKM-1864

Users Overview Panel Scalability: Introduce Paging Mechanism

With more and more registered users in some CKM instances, it has become necessary to rework the users overview panel using paging. This panel is accessible to admins via Tools/Manage Users.

While in some ways, it is convenient to have all users on one page, this does not scale endlessly: Despite massive optimisations to the panel, it now seems inevitable to significantly rework the panel and functionality by introducing a paging mechanism.

Each page will now display up to 500 users. CKM instances with less than 500 users will not be shown the paging toolbar at all.

To make paging as convenient as possible, existing “Search” texts (filters) will automatically be reapplied when paging through the users.

The paging mechanism supports complete sorting of all users. For example, if the admin clicks on a header column to change the sort column (e.g, from ‘last name’ to ‘organisation’, the grid will sort ALL users, not only the users of the current page and reapply any search text filter.

There are two limitations:

A search text filter will only apply to one page at a time though. For direct searches across all users, Tools/Lookup User remains the best option.
When selecting users for e.g. review invitations via the complete user list, it is only possible to select users of the same page.

Example Overview of Users with the new paging toolbar, displaying a maximum of 500 users per page.

CKM-1902

Project Dashboards: My Active Reviews Widget to always show the Recommendation column by default and Adoption fine-tuning

The “My Active Reviews” Panel on the Project Dashboard has been fine-tuned to always show the Recommendation column with the user’s recommendation for that review round (if any).

For active review rounds of resources of the respective project, where the user has not been invited to, special functionality exists to adopt the resource in order to be invited by the editors. For this, at the end of the row, the “Adopt” heart is shown and the tooltip contains a statement “Adopt <RESOURCETYPE> to be invited”. This issue fine-tunes this behaviour so that these are only be shown if the review round is a main (content) review type for the resource, not a secondary review type such as translation or terminology review rounds.

Example Active Reviews from the Dashboard of a Project.

CKM-1908

Opening an archetype via a direct link using its archetype id: v0 and v1 should both be supported

The direct links to an archetype also support using the current archetype id. The archetype id however changes on v0->v1 publication. At that stage a direct link using v0 would become invalid.

It would be useful to ensure that the user does not need to know whether the current id is a v0 or v1 version, and arguably we could support this by always looking for both versions.

In essence this means that

https://ckm.openehr.org/ckm/archetypes/openEHR-EHR-OBSERVATION.four_a_test.v1 and

https://ckm.openehr.org/ckm/archetypes/openEHR-EHR-OBSERVATION.four_a_test.v0

point to the same place, namely the latest version of that archetype, whether this is in v0 or v1.

(Note: This is different to looking into all possible archetype ids an archetype asset may have had in CKM pre-publication. That would be more difficult to do, because a) we’d need to look through all asset versions and b) this may lead to conflicts if the previous archetype id was later used as the archetype id of another archetype.)

CKM-1932

Expand archetype direct links to be able to go to a SEMANTIC revision directly

Currently (i.e in CKM 1.20), the following direct links to archetypes are supported:

Direct link type	Example
Using the archetype’s citeable identifier	https://ckm.openehr.org/ckm/archetypes/1013.1.3317
Using the archetype’s citeable identifier and an action. i.e. a CKM tab to open	https://ckm.openehr.org/ckm/archetypes/1013.1.3317/adl
Using the archetype’s citeable identifier and an asset version	https://ckm.openehr.org/ckm/archetypes/1013.1.3317/2
Using the archetype’s citeable identifier, an asset version and an action, i.e. a CKM tab to open	https://ckm.openehr.org/ckm/archetypes/1013.1.3317/2/adl
Using the archetype id	https://ckm.openehr.org/ckm/archetypes/openEHR-EHR-OBSERVATION.acvpu.v1
Using the archetype id and an action, i.e a CKM tab to open	https://ckm.openehr.org/ckm/archetypes/openEHR-EHR-OBSERVATION.acvpu.v1/adl

This issue adds support for the following in CKM 1.21.0:


Using the archetype’s citeable identifier and a semantic revision (1.0.1)	https://ckm.openehr.org/ckm/archetypes/1013.1.3664/1.0.1

CKM Release 1.21.0

Summary of Changes

Selected Release Highlights

Detailed List of Changes

✨New & Improved Functionality