No, currently all atNNNN codes are also found at the ontology in
LinkEHR, even if they are empty, to be compatible with the VATDF2 check,
although we would like to avoid it 
In my opinion we talk of two different levels of meaning. One is the
explicit meaning, where the definition of the node is defined through a
natural text or a terminology binding and that is, of course, the needed
for a complete semantic interoperability. The other is the implicit
meaning, when you create e.g. an OBSERVATION with occurrences {1..1} you
are creating "An OBSERVATION that only happens once". That means something
(otherwise you wouldn't have defined that constraint), even if you cannot
give it a natural name or a terminology code. And if it means something, it
shall have an identifier.
David, I am not totally clear on what you mean. OBSERVATION is a class
that always has an at-code on it anyway, because it is a high-level class
and needs its clinical meaning defined anyway. If you impose {1..1} on it,
you will do that via a SECTION or COMPOSITION slot.
I know that the openEHR archetype editor only allows introducing
OBSERVATIONs and the other clinical classes through a slot at the
COMPOSITION and SECTION, and probably that is a good methodological
approach or good practice to improve archetype governance, but technically
it is not the only possibility. You can create an archetype from the top
COMPOSITION to the leaf data values in one single archetype. And in any
case, it is just an example, we can use MY_CLASS_NAME or whatever to avoid
thinking this is a problem about how things work at the openEHR reference
model.
I don't think a clinical modeller would have to mind about these
aspects. He/she creates an archetype node (internally, a unique atNNNN code
is created). He/she optionally gives it a name or defines a terminology
binding (internally the ontology structures are created). When the
archetype is used or processed, the systems will only use the information
they have available.
Ok, but if tools have no rules, then we can end up with an archetype like
this:
OBSERVATION matches {
data matches {
HISTORY matches {
....
}
}
}
with no meaning on anything. What is to prevent that?
To be exact, in our approach all those classes should have an atNNNN code,
even if it is not described at the ontology section. But in any case,
current atNNNN rules does not force to put a description with a sense
either, except for the root node because it corresponds to the same concept
as the archetype identifier when you create the archetype. It is more a
duty of the clinical validation team to check those kind of things, not
something that can be automatically validated by rules. Look at the
following brand new archetype created with the openEHR editor, just
choosing an OBSERVATION root:
definition
OBSERVATION[at0000] matches { -- Test example
data matches {
HISTORY[at0001] matches { -- Event Series
events cardinality matches {1..*; unordered} matches {
EVENT[at0002] occurrences matches {0..1} matches { -- Any event
data matches {
ITEM_TREE[at0003] matches {*}
}
}
}
}
}
}
ontology
term_definitions = <
["es"] = <
items = <
["at0000"] = <
text = <"Test example">
description = <"unknown">
>
["at0001"] = <
text = <"Event Series">
description = <"@ internal @">
["at0002"] = <
text = <"Any event">
description = <"*">
["at0003"] = <
text = <"Tree">
description = <"@ internal @">
>
The only "meaning" there is the "Test example" name of the OBSERVATION,
because it corresponds to the archetype name. But all the others have no
meaning and no existing rules are checking that (having "Event series",
"Any event" and "Tree" is the same as not saying anything). So, again,
those ontological descriptions will be always checked by the authors, not
by the tools.
By the way, following the specifications, even that example archetype
created with the openEHR editor is not perfect. Both the at0001 and the
at0003 codes should not be needed according to the rules, since they are
members of single value attributes without sibling nodes...
