Document status: FINISHED

Document approval date: Jan 5, 2026

Meeting Date: 15 October 2025

Meeting Time: 13:30 - 17:00h CEST

Location: Sala Raval - CCCB Barcelona

CHAIR: CPB: @Paul Miller openEHR

NOTE-TAKER: CPB: @Vanessa Pereira

Attendance

Agenda

Minutes

Moving from ADL 2 to ADL 2.4

Overview

ADL2.4 addresses several limitations of ADL1.4 and ADL 2.0, adding improved template handling, proper multilingual support, and clearer versioning with namespace and HRID structure (e.g. uk.openehr::openehr-ehr-composition.t_end_of_life.v1.2.0) and a title for the template (e.g. One London Care Plan v1.2).

ADL enhancements

• Default values can be set on any node.

• Supports node ordering.

• Allows direct archetype inclusion for reuse.

• Cardinality and existence constraints are now optional.

• Strengthened terminology binding support.

Terminology binding and constrains

Now includes codesystems and valuesets, following a FHIR Terminology like approach. The group welcomed this, noting it could ease licensing concerns.

@Heather Leslie and @Silje Ljosland Bakke mentioned they would like to review documentation and provide feedback.
Ian clarified that this case will be a section in Arcehtype Designer that serves as write in information about the terms used (e.g. valuesets).

Reference repo: https://github.com/SevKohler/Terminologies which will to be moved to openEHR terminology list on GitHuband should be used to set codesystems (similar to the openEHR terminology list already available)

Namespace in archetype IDs

Example:
uk.openehr::openehr-ehr-composition.end_of_life.v1.2.0
no.openehr::openehr-ehr-composition.end_of_life.v1.2.0
Ensures consistency between archetypes. Questions raised about international CKM naming (e.g. using .org) and differences between original and current namespaces.

Implications for modellers

• Tooling usability concerns - migration from slots to direct inclusion needs discussion.

• Modelling guidelines require updates to reflect the new changes. Training is needed before ADL2.4 rollout to avoid migration issues.

• SEC highlighted vendor version discrepancies - some vendors use 1.4 and 2.0. Is recommended phased adoption and coordinated project management to ease the migrations. Upgrade should be ad-hoc instead of all at once.

  • The move to ADL 2.4 aims to unify vendors, as most use 1.4 and others uses 2.0 (now deprecated), harming interoperability.

Template IDs and versioning

• No consistent template versioning standard currently exists.

  • Previously, version numbers were appended to template names (e.g. One London Care Plan v1.2.1)., affecting compositions.

• ADL 2.4 introduces HRIDs to standardize this.

• Older templates remain valid and new templates should adopt HRIDs.

• Discussion ongoing regarding AQL behavior for this (whether it should query all template versions).

• Namespace questions raised for multi-country vendors. @Severin Kohler suggested registry for namespace allocation for vendors that have multiple clients over different countries.

• Rules for template versioning to be updated on the specification site.
  
  

Translations

CKAs raised issues managing translation references, particularly in scales and scores, where validated tools lack proper multilingual handling. For example, when an archetype represents a validated tool, that tool may be available in multiple languages. These language specific versions need to be listed in the references section of the archetype. However, since there is currently only one shared references section, both content and translation references appear mixed together. A possible solution would be to use a unilingual reference for the main content and a multilingual reference for the translations.
Was referred by @Sebastian Garde that future CKM updates will support markdown rendering within archetypes for better formatted multilingual content.

Multilingual templates and valuesets

@Silje Ljosland Bakke and one of the observer members highlighted the challenges of creating templates that support multiple languages and require multilingual value sets. For example, when using a SNOMED value set for diagnoses in English, switching the template language to French should display the same SNOMED codes with French descriptions. This has been a long-standing request from modellers.

Demographics archetypes

Discussion on “abandoned” demographic archetypes (mainly used in the Netherlands and Argentina, based on HL7v2, primarily for referral letters).
Severin noted their use in HighMed CDR for research data points and that it is preferable to have it in a single repository. @Vanessa Pereira also mentioned the potential need to keep these archetypes in a single repository for research purposes, to avoid running multiple queries across different databases and whether it would be better to retain these (even if outdated) archetypes in the CKM, or to allow users to create multiple local archetypes for the same concept but with different structures. Even if the existing CKM archetypes are not perfect, they help prevent local discrepancies.

The main challenge is the lack of time and resources to update and align these specific archetypes with current best models, especially since most users manage demographic data separately.

Further intra-collaboration between both programs

• Heather suggested more cross-group meetings which everyone agreed with. Sebastian Iancu and Wouter proposed a small working group (2 to 3 CPB senior members + SEC members) fixed recurring meeting slots and at least a bi-annual meeting between both full groups and Sebastian suggested holding them in the Netherlands. From those, at least one CPB/SEC meeting will be hosted in EHRCONs.

AOB

Specifications Website Update

• UML diagrams to be replaced by BMM.

• Specification site to migrate to Antora for improved navigation, search, and maintainability.

• Current specs tooling needs a legacy software to procude the documentation which is outdated and slow.

• @Silje Ljosland Bakke raised a request to retain permalinks and maintain legacy access of the current specs pages.

Reference Model (RM)

• Heather noted the need for a more readable RM version for modellers.

• Diego mentioned plans for “DeepWiki” with AI-assisted explanations.

• Highlighted the need to expose essential RM fields currently missing in tooling (e.g Archetype designer) to prevent duplication in archetypes.

Working Groups

List of all working groups from both programmes to be provided.

Discourse

Proposal to open private sections between CPB and SEC groups to enable secure, non-public discussions.

List of action points

Action points will be added to Jira after the minutes are reviewed by both programmes.