The General problem with the at codes is that each archetype has the same at codes. Hence it is not an ontology it refers to but is an internal micro-ontology only .
In the DCM approach each node SHALL have a minimum of one external code, preferable Snomed CT, which links the data element in the archetype to an external ontology, which importantly allows external maintenance and governance and facilitates the use in other archetypes or templates as defined in OpenEHR. Vriendelijke groet, Dr. William Goossen Directeur Results 4 Care BV +31654614458 Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at lists.openehr.org het volgende geschreven: > Send openEHR-technical mailing list submissions to > openehr-technical at lists.openehr.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > or, via email, send a message with subject or body 'help' to > openehr-technical-request at lists.openehr.org > > You can reach the person managing the list at > openehr-technical-owner at lists.openehr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openEHR-technical digest..." > > > Today's Topics: > > 1. Re: Polishing node identifier (at-codes) use cases. > (Gerard Freriks) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 28 Aug 2013 13:26:14 +0200 > From: Gerard Freriks <gfrer at luna.nl> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org> > Subject: Re: Polishing node identifier (at-codes) use cases. > Message-ID: <C6BF076F-3040-442B-B9D7-69D04EEC599A at luna.nl> > Content-Type: text/plain; charset="windows-1252" > > David, > > Can I summarise it for my understanding as: > - ATxxxx codes are pointers to an 'ontology'. > - ATxxxx codes can be considered symbols that represent a particular concept > - The 'ontology' provides a name that will be used to display the name of a > node (concept) in an archetype. > - When a node is specialised the node name used will indicate a new concept > (its meaning has changed) > - When the archetype is specialised ideally the new concept in the > specialisation is a subordinate concept. > - When a Node is specialised the standard does not prescribe that the new > concept is a sub-set of the previous one. > - The question is: is each Node (and the concept it represents) unique or not. > - The question is: is it obligatory that each node in the archetype carries a > unique code of the form ATxxxx . > > My answers to both questions are: > - Each archetype node is a unique concept that must have attached to it a > unique identifier. > - Archetype editors must support this. > > And I would like to add: > - When specialising each specialised concept must be a subset of its previous > one. > > > Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 28 aug. 2013, at 09:13, David Moner <damoca at gmail.com> wrote: > >> >> I'll try to summarize the origin of the different views we have regarding >> this topic and maybe this can be also useful to see why this is not just a >> configuration problem of the tools. >> >> We can find the explanation of node identifiers in two places (I use the >> latest drafts, I think): >> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, >> used to distinguish sibling nodes of the same type. [Previously called >> ?meaning?]. Each node_id must be defined in the archetype ontology as a term >> code." >> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of the >> form [atNNNN] following a type name is used to identify an object node, i.e. >> a node constraint delimiting a set of instances of the type as defined by >> the reference model." and "A Node identifier is required for any object >> node that is intended to be addressable elsewhere in the same archetype, in >> a specialised child archetype, or in the runtime data and which would >> otherwise be ambiguous due to sibling object nodes" >> >> The definition in AOM is the one followed by the openEHR editor, i.e. a node >> identifier or atNNNN code is just a pointer to the ontology section and a >> mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the >> tool does not introduce that code in order not to dirty the ontology section. >> >> The first part of the definition in ADL is the one followed in LinkEHR and, >> in our opinion, more correct formally. When you introduce an archetype >> constraint for a C_OBJECT you are in fact creating a definition of a type (a >> sub-type of the more generic type defined by the reference model class) that >> will be used to create a subset of instances. We have to distinguish this >> sub-type from the RM type, and since the class name cannot be changed, the >> only solution is to use the atNNNN as type identifier. In other words, our >> interpretation is that atNNNN codes are unique identifiers of each type >> defined in the archetype, that may be also used to link to the ontology >> section, but that is the optional part. In fact, the only exception to this >> would be when you create constraints using a path, because then you are just >> navigating through the RM but do not change the meaning of the intermediate >> classes. >> >> The logic of the tools and the validation checks of archetypes are built >> based on those interpretations. I agree with Bert in one thing: tools >> shouldn't change things without notifications, but in this case we face a >> methodological difference, not just a configuration one, and that's why it >> is not easy to be solved. >> >> David >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ------------------------------ > > End of openEHR-technical Digest, Vol 18, Issue 37 > *************************************************
