TL;NR: the concept in archetypes is at0000 (the root node_id) and in templates the concept is the template ID (a name), which I find inconsistent.
I have noticed that the OPTs published in the CKM and the ones exported from the Archetype Designer, in the <concept> field, there is a copy of the <template_id>. But in ADL, the concept field corresponds to the node_id of the root constraint.
Isn’t the concept in the template being wrongly used?
The use of ‘concept’ has always been very vague. I can recall that in the very early days of .oet tooling, at one time ‘concept’ was used to hold the filename of the template. Then it was decided (correctly) that this was a very bad idea, and at some point .oet→.opt generation basically duplicated the template_id.
@sebastian.garde chatted about this as part of the discussions about adopting more formal ADL2-like template_id going forward. It was recognised that if template_id turns into a more technical name, then we need something that is more human readable . The solution for ADL2 was to introduce a new ‘title’ attribute, and the proposal is to add this in adl1.4 other_details. We could potentially have used’concept’ but we were anxious to not trip over local, variant use of ‘concept’ - a clean start, aligned ot ADL2 seemd the best solution.
In ADL archetypes, all the ones that I’ve checked have at0000 as the concept (or its equivalent in specialized archetypes), and the spec is very clear, so I don’t think it’s a vague concept.
8.3.4. Concept Section
All archetypes represent some real world concept, such as a “patient”, a “blood pressure”, or an “antenatal examination”. The concept is always coded, ensuring that it can be displayed in any language the archetype has been translated to. A typical concept section is as follows
concept
[at0010] -- haematology result
So it seems it’s used inconsistently in modeling tools and specifically in templates.
An implementer reading the specs would consider this as an inconsistent implementation, or even as a violation to the specs.
I don’t remember the behavior of the Template Designer, as soon as I can get my hands on a Windows box I’ll test it, and also try on LinkEHR. Maybe @damoca or @yampeku remember how this behaves in LinkEHR when exporting an OPT.
Yes but ADL1.4 templates are not archetypes (unlike ADL2). There is no top-level archetype node, or associated atCode, unlike ADL2 where the template is a specialisation of the root archetype , and where interestingly , there is no ‘concept’ attribute since it just ‘is’ the at/idCode of the root archetype.
I’m not trying to defend where we are , just saying that historically this has been populated a bit variably, and even if it had been used as you suggest was really redundant since it is always going to be identical to the root atCode of the root archetype.
Agree. Though the template concept is clearly derived from the archetype concept, or someone at some time had too much to drink to actually model the same thing in different places as totally different things
My point is: semantically the template and archetype concepts in 1.4 should be the same thing.
Note I’m just discussing 1.4 because I know nothing about ADL2 and 1.4 is the only thing I use.
On the other hand, and it’s a totally different discussion, I see the concept as a required field that is actually redundant, because it’s always the root node’s node_id(at least I couldn’t find a case where the concept is different from at0000 or at0.1). I guess @thomas.beale realized the concept was redundant in ADL2 and removed it?
For the consistency issue, I would like to raise a ticket on JIRA to check what other SEC members think.