Hello,
is there a way to find out which version of a template was active when the composition was validated etc. ?
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.
I think this info should be contained in the Composition too.
Can we add that to the spec etc. ?
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?
1 Like
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.
2 Likes
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 ?!
Essentially this is (should be) a solved problem in ADL2
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
1 Like
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_ide.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
2 Likes
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.
1 Like
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.
2 Likes
Semver is exported in the current AD .opt generation.
<?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.
This is something we definitely should get onto soon. Especially what are the rules wrt draft vs release templates.
That’s really great! Does it also include CKM?
1 Like
That’s really great! Does it also include CKM?
It does indeed @sebastian.garde and @Seref are both involved.
2 Likes
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.
1 Like
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 
)
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.
1 Like