Some archetype nodes/constraints (like element and entry) can record a ’name’, ‘description’ and a ‘comment’. The name seems defined in LOCATABLE. But where are description and comment defined in the openEHR spec?
Are you looking for this?
It holds the text, description, comment (or other) language-dependent items.
Similarly in 2.x here:
(Now with text+description explicitly defined)
1 Like
Probably yes.
So I understand even in adl2 ‘comment’ is an unstandardised item in an archetype? And in adl1 so is ‘description’ and ‘text’. This is quite fundamental to me, since ‘health concepts’ are (for a big part) defined by their elements, e.g. if you want to know the definition of a blood pressure, you learn it by knowing it has elements like systolic bp. (In contrast to ontologies, where definitions are expressed using ‘is-a’ statements). so if those elements don’t have a specified structure it’s somewhat open to how an element is defined and thus how ‘health concepts’ are defined in openEHR. ISO 13972 seems to be more precise in this effort.
I know this isn’t much of a practical issue atm. But I’m curious how people look at this issue? Maybe we can improve by being more explicit here along the lines of ISO13972.
Also, I’m curious about the ADL2 syntax for ‘comment’. According to the spec this needs to be in a key value hash inside the other_items attribute. But (in CKM/archie ADL2) it seems a sibling attribute:
["id22"] = < text = <"*Severity category(en)"> description = <"*Category representing the overall severity of the symptom or sign.(en)"> comment = <"*Defining values such as mild, moderate or severe in such a way that is applicable to multiple symptoms or signs plus allows multiple users to interpret and record them consistently is not easy. Some organisations extend the value set further with inclusion of additional values such as 'Trivial' and 'Very severe', and/or 'Mild-Moderate' and 'Moderate-Severe', adds to the definitional difficulty and may also worsen inter-recorder reliability issues. Use of 'Life-threatening' and 'Fatal' is also often considered as part of this value set, although from a pure point of view it may actually reflect an outcome rather than a severity. In view of the above, keeping to a well-defined but smaller list is preferred and so the mild/moderate/severe value set is offered, however the choice of other text allows for other value sets to be included at this data element in a template. (en)"> >
Also, how does the ARCHETYPE_TERM class relate to other classes like LOCATABLE, AUTHORED_ARCHETYPE etc. I feel it should be much easier to discover and understand the relations form this spec. Maybe something for a custom (plant)UML diagram?
Yes and no. They are also mentioned in the adl 1.4 specs then
Each term is defined using a structure of name/value pairs, and must at least include the names “text” and “description”, which are akin to the usual rubric, and full definition found in terminologies like SNOMED-CT.
The link above and similar in ADL2, describes that the key value pairs are indeed constructed like this in ADL. This is - I agree - inconsistent if you are aiming for a serialisation that directly maps to the AOM. However, I assume, this may have been done as a simplification to avoid the extra layer of items / other_items here. (This generally works fine, but it is slightly problematic that the structure of the keys is not clearly defined anywhere or at least I am not aware of it. As long as it is all lower-case chars without special characters, especially of course white-space it is unproblematic.)
1 Like