2013/8/28 Thomas Beale <thomas.beale at oceaninformatics.com> > On 28/08/2013 10:07, David Moner wrote: > > > > > 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... -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/aad85b12/attachment-0001.html>