Include a version() method on TEMPLATE_ID

Description

It seems current templates doesn't have a version, just an id that can be a name (e.g. the Template Designer uses a name for the template_id).

Since we need to manage templates, like we manage archetypes that will change over time, we need an effective way of differentiating 2 versions of the same template.

CR: add a version to the format of the parent OBJECT_ID.value on TEMPLATE_ID, and make that version mandatory in the id. For tooling we might suggest to use "1" as default version, like the Archetype Editor does.

Environment

None

Activity

Show:
skoba
April 26, 2018, 1:25 PM

This proposal would be helpful to manage templates, but it could affect wide range of current templates and tools. I think this should be on 1.1.0.

Thomas Beale
April 26, 2018, 1:56 PM

Yes, I think it would need to be 1.1.0 - I'm marking it that way for now.

Pablo Pazos
April 26, 2018, 4:50 PM

OET doesn't have a formal versioning mechanism. It has an open "other_details" field that is a key/value mapping. There a version can be stored but informally.

Check this sample https://github.com/ppazos/cabolabs-ehrserver/blob/master/opts/production/psychotherapy_note/psychotherapy_note.en.v1.oet#L12-L61

OPT 1.4 also have the other_details key/value mapping, but has the template_id that can be formatted. The Template Designer doesn't apply any format to the template_id. What I'm using is concept.language.version like this: https://github.com/ppazos/cabolabs-ehrserver/blob/master/opts/production/psychotherapy_note/psychotherapy_note.en.v1.opt#L37-L39

BTW, OET is not part of the specs AFAIK, IMO we need to focus on OPT versioning not OET. Different implementers might have their own template source format different from OET. In fact I'm using OET just because the TD works with that, but the TD has a lot of problems and I will switch to other modeling tools as soon as I can.

Thomas Beale
May 1, 2018, 7:48 PM

I am inclined to think that we should just use ARCHETYPE_HRID (the new version of ARCHETYPE_ID) for everything. See https://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_the_archetype_package

I am not sure that TEMPLATE_ID really has a use. It was added to the model years ago when I thought that Templates would be differently identified.

Pablo Pazos
September 30, 2019, 4:04 PM

On the SEC 09/19 meeting we decided to define which fields would be part of the template_id

I can give a reference to the ones we use, full doc is here

We use: concept.language.version

So it is easy to find different versions of the same OPT or the same OPT exported for different languages, like:

  • demographic_data.en.v1

  • demographic_data.es.v1

  • demographic_data.es.v2

An we also use that format for the OPT file name, similar to what we do with archetypes. The idea is to be able to find files easily without looking at the content (as I think is the idea for ADL file names).

Maybe others can think of other fields that might be useful to add.

 

Reporter

Pablo Pazos

Components

Priority

Major
Configure