Template ID in Composition Examples

This document discusses only the issue of how LOCATABLE.archetype_details.template_id should be populated. Issues of how these IDs should be handled in templates and how the composition ‘knows’ which type of ID to use are discussed in a separate document.- ‘TemplateID in design-time artefacts’ (TBD)

On the call/other discussions there appears to be full support for allowing/formalising versioning in ‘COMPOSITION(LOCATABLE)/archetype_details/template_id. On the call there was general consensus to use the ADL2 Human-Readable Identifier (HRID) alongside the legacy template ID version in compositions, in preference to any interim ‘versioned strings’ but for querying purposes, both legacy and HRID must be supported and queryable. Template ID version discussion https://openehr.atlassian.net/browse/SPECPR-124

i.e if people (rightly) want to move to use semantically versioned strings in LOCATABLE.archetype_details/template_id, they should use an ARCHETYPE_HRID, (complete with namespace?), as this provides a smoother path to ADL2 and may allow for some extra support in AQL in terms of partial matches.

Ideally modelling tools would generate the HRID automatically in a similar way to the process for creating both archetype_ids and concept names for new archetypes.

What would this look like in compositions?

ADL1.4 Composition with legacy ADL1 TEMPLATE_ID (free text)

ADL1.4 Composition with ADL2 HRID

AQL to retrieve both variants

To cope with legacy data where the query is dependent on knowing the template_id, we can do

However in reality we are going to need to query on a partial match of HRID or indeed the legacy ID as matching is most likely required at the major version.

Or we might use the idea of ADL2 archetype referencing https://specifications.openehr.org/releases/AM/latest/Identification.html#_referencing
which allows sub-matches on an HRID but does not solve the problem of specialised templates.

where `hrid_ref_matches()` might be a new AQL function that does a partial match on an HRID e.g.

org.highmed::openEHR-EHR-COMPOSITION.trial.v3` would match v3.1, v3.2 etc but not v2 or v4.

Issues to be resolved

1. Is it ok to overload the archetype_details/template_id attribute with legacy and HRID based ids, or should we introduce a new template_hrid attribute (RM change) to make this explicit?

2. Does it make sense to introduce some kind of hrid_matches() function which is also likely to be needed for resolving archetype_ids in AQL paths, CONTAINS etc.

To resolve this safely, we also need to consider what will happen in transition to ADL2

ADL2 composition equivalent

Looking at an ADL2 equivalent composition (as per NEDAP), things are a little different, as there is no need for an archetype_details/template_id attribute, since the archetype_id is itself the identifier of the template. It is always a specialisation of the underlying archetype rather than (as in ADL1.4) the archetype_id of the underlying parent COMPOSITION archetype e.g. openEHR-EHR-COMPOSITION.report.v2.0.0 which is not carried in the composition at all.

This does not actually matter in terms of this template_id discussion, but it is critical in the parallel discussion on how the spec of ARCHETYPE_ID needs to change. https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues/SPECPR-363?filter=recentlyviewed&jql=project%20%3D%20%22SPECPR%22%20ORDER%20BY%20lastviewed%20DESC https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues/SPECPR-463?filter=recentlyviewed&jql=project%20%3D%20%22SPECPR%22%20ORDER%20BY%20lastviewed%20DESC https://openehr.atlassian.net/browse/SPECBASE-35

In the NEDAP CDR the resolution of that chain of specialisations is handled by the template registry as a lookup. There is no means of figuring out the specialisation lineage of a template , or specialised archetype directly from the archetypeId in the composition, or even by textual matching. The name of the specialisation does not have to contain the name of the parent, as in ADL1.4

ADL2.4 Composition (NEDAP example)

Implications of transition to ADL2.4

For the template identifier, as things stand, we may actually have 3 variants in play in composition data

1. A legacy Template identifier in archetype_details/template_id in ADL1 compositions

2. An HRID-style identifier in archetype_details/template_id in ADL1 compositions

3. An HRID-style identifier in archetype_details/archetype_id in a true ADL2 compositions and no template_id

Proposal

1. The use of an explicit new template_hrid attribute is not necessary and actually confuses things even more as we transition fully to adl2 compositions.

2. An RM change is necessary since currently, templateId is mandatory on archetype roots. Instead keep it mandatory and force ADL2 systems to populate it, even if it is redundant, to remove the complexity of queries i.e. this would be sufficient.