# Determine template version used from a composition

**URL:** https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128
**Category:** RM
**Created:** [19 June 2023 08:58 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128 "2023-06-19T08:58:18Z")
**Posts on this page:** 17
**Page:** 1

<div class="post-metadata">

### Author: ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)
#### Post date: [19 June 2023 08:58 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/1 "2023-06-19T08:58:19Z")

</div>

Hello,

is there a way to find out which version of a template was active when the composition was validated etc. ?

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [19 June 2023 11:07 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/2 "2023-06-19T11:07:55Z")

</div>

I don’t think that is currently possible as it is generally only the templateId that is carried in a composition which may or may not include the semver details.

---

<div class="post-metadata">

### Author: ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)
#### Post date: [19 June 2023 11:12 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/3 "2023-06-19T11:12:41Z")

</div>

I think this info should be contained in the Composition too.  
Can we add that to the spec etc. ?

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [19 June 2023 11:16 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/4 "2023-06-19T11:16:38Z")

</div>

I think we need to take another look at templateIds and versioning as we transition beyond ADL1.4 @pieterbos @sebastian.iancu @Bostjan_Lah - is this something we need to include in our transitional efforts?

---

<div class="post-metadata">

### Author: ![vanessap](https://discourse.openehr.org/user_avatar/discourse.openehr.org/vanessap/32/2088_2.png) [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [19 June 2023 11:30 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/5 "2023-06-19T11:30:22Z")

</div>

Hi! I completely agree with you. On the template you can see the semantic version of the template (this is on adl designer, at the sem\_ver attribute, I don’t know how it’s in the other modeling tools) but not in the composition. This issue you’re facing now, I was solving with internal governance, at the moment a template was updated, we knew the timestamp, and every composition saved from that moment upfront belonged to that template - for this, you need to have a page where you have this information documented (I do not know how it’s in your environment). In case we have a template shared across institutions that we could not manage, there was a small cluster archetype in the template composition context section recording this information - although I know it wasn’t the best, I couldn’t find anything on the RM to solve this case.

---

<div class="post-metadata">

### Author: ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)
#### Post date: [19 June 2023 11:44 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/6 "2023-06-19T11:44:19Z")

</div>

Thanks !  
Timestamp filter is a bad solution for long term, but obviously a workaround for now 😉  
I dont see why that info should not be contained in the composition.  
Do templates get a version element as the compositions do ?  
If yes one could just link that path in the composition with the version element ?!

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [19 June 2023 11:44 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/7 "2023-06-19T11:44:46Z")

</div>

Essentially this is (should be) a solved problem in [ADL2](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_adl_version_indicator)

```auto
template (adl_version=2.0.5; rm_release=1.0.2)
    uk.org.primary_care::openEHR-EHR-OBSERVATION.haematology_result.v1.2.15

```

However this assumes that templateIds are like current archetypeIds, whereas what we have now are more like conceptIds i.e largely non-technical and not defined

e.g. the example above we would currently have a templateId something like “UK\_PRIMARY \_CARE - Haematology result”

and we have stopped embedding the semver details directly in the templateId as this makes life very difficult in development, where we largely want to ignore breaking changes.

I actually think we need both that technical templateId

and a design-time conceptId to be displayed in tooling/ implementation guidance - that might also give us a transition path out of ADL1.4

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [19 June 2023 12:59 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/8 "2023-06-19T12:59:47Z")

</div>

> Do templates get a version element as the compositions do ?

Yes but only in the template itself , not in the composition as such.

What is recorded in the composition is just a templateId string - that string could carry the semver string in the `locatable/archetype_details/template_id`e.g.

`"template_id": "uk.org.primary_care::openEHR-EHR-OBSERVATION.haematology_result.v1.2.15" `

but right now that is not the case and adding it would break some existing queries for templates based on .oet type templateIds.

At the SEC group meeting we kicked off a number of work streams to get us past the current blockers keeping us on ADL1.4

---

<div class="post-metadata">

### Author: ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [20 June 2023 02:16 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/9 "2023-06-20T02:16:22Z")

</div>

Some years ago I got frustrated about the lack of version control for OPTs and decided to add the version in semver to the template\_id, since there wasn’t any formal agreement from the SEC despite we raised and discussed this topic many times. Our solution worked but only for our tools (EHRServer, Atomik and openEHR Toolkit).

Now I have removed that since we were checking the version came in the template\_id and people are using the Archetype Designer and other tools that don’t support the version there and were uploading templates to the openEHR Toolkit, complaining about the template upload not working.

Then we did implemented semver internally, so it’s not in the template\_id but in the database, so when you upload the same template many times, it allows you to choose if that is a patch, minor or major change and updates the internal semver accordingly. Of course when you send the template to other system, the versioning info doesn’t travel. I guess an easy fix would be to add a header value with the version which is supported by OPTs everywhere, though most systems don’t use that metadata.

So the current situation is: what you ask is not currently supported.

IMHO that is a hard requirement for correct long-term data management, so we lack something important as part of the specs, and different implementations need to deal with that internally while it could be something standardized.

---

<div class="post-metadata">

### Author: ![siljelb](https://discourse.openehr.org/user_avatar/discourse.openehr.org/siljelb/32/12_2.png) [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [20 June 2023 07:23 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/10 "2023-06-20T07:23:03Z")

</div>

> [@pablo](#):
>
> IMHO that is a hard requirement for correct long-term data management, so we lack something important as part of the specs, and different implementations need to deal with that internally while it could be something standardized.

Agree, and I think this is in itself a selling argument for moving on from ADL 1.4. We _have_ to be able to properly version templates _and_ connect the compositions to the correct template version to have any chance of being able to govern data over time.

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [20 June 2023 07:45 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/11 "2023-06-20T07:45:21Z")

</div>

Semver is exported in the current AD .opt generation.

```auto
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<template xmlns="http://schemas.openehr.org/v1">
    <language>
        <terminology_id>
            <value>ISO_639-1</value>
        </terminology_id>
        <code_string>en</code_string>
    </language>
    <description>
        <original_author id="date">2019-04-19</original_author>
        <lifecycle_state>in_development</lifecycle_state>
        <other_details id="licence">This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.</other_details>
        <other_details id="custodian_organisation">openEHR Foundation</other_details>
        <other_details id="original_namespace">org.openehr</other_details>
        <other_details id="original_publisher">openEHR Foundation</other_details>
        <other_details id="custodian_namespace">org.openehr</other_details>
        <other_details id="MD5-CAM-1.0.1">d9b099bbd45cebadb4394b5e8d91db37</other_details>
        <other_details id="version">0.0.1</other_details>
        <other_details id="sem_ver">1.2.1</other_details>
        <other_details id="build_uid"></other_details>
        <other_details id="PARENT:MD5-CAM-1.0.1">119dc65fa2910f90915adaf1b41cb303</other_details>
        <other_details id="is_singleton">ehr</other_details>
        <other_details id="Generated By">Archetype Designer v1.24.7, user=freshehr, repositoryId=one-lond-vu</other_details>
        <details>
            <language>
                <terminology_id>
                    <value>ISO_639-1</value>
                </terminology_id>
                <code_string>en</code_string>
            </language>
            <purpose>Not Specified</purpose>
        </details>
    </description>

```

although we do not yet have solid Semver rules for templates.

SEC is working hard to get past ADL1.4 - there are some practical challenges/barriers for current CDRs and ADL1.4 persisted data that were discussed in some detail at the recent SEC meeting in Barcelona. The good news is that there was a solid commitment from all the implementers to find mitigations and get us moving forwards.

---

<div class="post-metadata">

### Author: ![siljelb](https://discourse.openehr.org/user_avatar/discourse.openehr.org/siljelb/32/12_2.png) [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [20 June 2023 07:49 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/12 "2023-06-20T07:49:15Z")

</div>

> [@ian.mcnicoll](#):
>
> although we do not yet have solid Semver rules for templates.

This is something we definitely should get onto soon. Especially what are the rules wrt draft vs release templates.

> [@ian.mcnicoll](#):
>
> The good news is that there was a solid commitment from all the implementers to find mitigations and get us moving forwards.

That’s really great! Does it also include CKM?

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [21 June 2023 12:15 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/13 "2023-06-21T12:15:22Z")

</div>

> That’s really great! Does it also include CKM?

It does indeed @sebastian.garde and @Seref are both involved.

---

<div class="post-metadata">

### Author: ![Seref](https://discourse.openehr.org/user_avatar/discourse.openehr.org/seref/32/13_2.png) [@Seref](https://discourse.openehr.org/u/Seref)
#### Post date: [22 June 2023 18:53 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/14 "2023-06-22T18:53:28Z")

</div>

> [@siljelb](#):
>
> That’s really great! Does it also include CKM?

Yes, it does. To add a bit to what Ian said, we’re trying to identify the most important changes that were introduced beyond 1.4 from the point of modellers and vendors. Changes/additions that make an obvious positive impact for the modellers have higher priority from a CKM perspective. Therefore your feedback is most welcome and appreciated.  
Post 1.4 specs have lots of good ideas, but some of those address bigger pains than others and at least for Ocean, those have higher priority.

---

<div class="post-metadata">

### Author: ![birger.haarbrandt](https://discourse.openehr.org/user_avatar/discourse.openehr.org/birger.haarbrandt/32/24_2.png) [@birger.haarbrandt](https://discourse.openehr.org/u/birger.haarbrandt)
#### Post date: [22 June 2023 22:30 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/15 "2023-06-22T22:30:48Z")

</div>

Is this really an issue with ADL 1.4? This could also be addressed by just adding a new field to the RM storing a template version (apologies for oversimplification 🙂 )

---

<div class="post-metadata">

### Author: ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [23 June 2023 10:27 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/16 "2023-06-23T10:27:37Z")

</div>

Yes you are correct and that’s something that should possibly be raised at SEC.

It might be as simple as adding a template version attribute alongside templateId in the RM …

However, I suspect @pieterbos might argue that they already carry the full semver versionId as part of the templateID, in their ADL2-based system. That in turn raises some issues about transition from cADL1.4 templateIds.

Needs to be part of the ADL1.4 transition discussion.

---

<div class="post-metadata">

### Author: ![SevKohler](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sevkohler/32/3504_2.png) [@SevKohler](https://discourse.openehr.org/u/SevKohler)
#### Post date: [27 February 2025 13:02 UTC](https://discourse.openehr.org/t/determine-template-version-used-from-a-composition/4128/17 "2025-02-27T13:02:51Z")

</div>

Raised an issue, i think we should figure this out asap.  
[https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues/SPECPR-124?jql=project%20%3D%20"SPECPR"%20AND%20textfields%20~%20"template%20version"%20ORDER%20BY%20created%20DESC](https://openehr.atlassian.net/jira/software/c/projects/SPECPR/issues/SPECPR-124?jql=project%20%3D%20%22SPECPR%22%20AND%20textfields%20~%20%22template%20version%22%20ORDER%20BY%20created%20DESC)