There is plenty of health informatics science that tells that combining data from various systems is only possible when each data element is uniquely coded.
That single use case alone - reusing data from multiple systems - justifies the SHALL linkage between data element/node and terminology as Snomed CT. I agree with Sam that the meaning should be derived from the DCM and the collection of data elements in it. Here is where the science of data Modelling and the science of clinical terminologies meet and team up. Vriendelijke groet, Dr. William Goossen Directeur Results 4 Care BV +31654614458 Op 28 aug. 2013 om 23:55 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: openEHR-technical Digest, Vol 18, Issue 37 (William Goossen) > 2. RE: openEHR-technical Digest, Vol 18, Issue 37 (Sam Heard) > 3. Re: openEHR-technical Digest, Vol 18, Issue 37 (Hugh Leslie) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 28 Aug 2013 19:16:13 +0200 > From: William Goossen <wgoossen at results4care.nl> > To: "openehr-technical at lists.openehr.org" > <openehr-technical at lists.openehr.org> > Cc: "openehr-technical at lists.openehr.org" > <openehr-technical at lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 > Message-ID: <41D62117-1409-4EBB-B352-3CA1B71DDC5E at results4care.nl> > Content-Type: text/plain; charset=us-ascii > > 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 >> ************************************************* > > > > ------------------------------ > > Message: 2 > Date: Wed, 28 Aug 2013 19:58:10 +0100 > From: Sam Heard <sam.heard at oceaninformatics.com> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org> > Subject: RE: openEHR-technical Digest, Vol 18, Issue 37 > Message-ID: <BLU404-EAS150A57B3DF007FCD8490EA2854B0 at phx.gbl> > Content-Type: text/plain; charset="utf-8" > > Hi William > > That road is seductive but assumes that SNOmed or the like covers the concept > unambiguously. The fact is that the world experts on SNOMED spent weeks > discussing what codes applied to the BP archetype nodes.....and finally > agreed with the ones I had proposed. > > The fact is that the archetypes are often far less ambiguous than the terms > in an ontology. > > Modeling in openEHR will accelerate now we have a widening implementation > base. The models won't be perfect or all encompassing but they will support > high fidelity processes and sharing evolving data expressions. > > Ontological based approaches may be suitable in 20 years, but will need to be > based on the clinical models, not the other way around. Clinicians need to > define what they want to record. > > My 2p - Cheers Sam > > Dr Sam Heard > FRACGP, MRCGP, DRCOG, FACHI > Chairman, Ocean Informatics > Chairman, openEHR Foundation > Chairman, NTGPE > +61417838808 > ________________________________ > From: William Goossen<mailto:wgoossen at results4care.nl> > Sent: ?28/?08/?2013 6:16 PM > To: openehr-technical at lists.openehr.org<mailto:openehr-technical at > lists.openehr.org> > Cc: openehr-technical at lists.openehr.org<mailto:openehr-technical at > lists.openehr.org> > Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 > > 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 >> ************************************************* > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/34ab97de/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Wed, 28 Aug 2013 23:55:21 +0200 > From: Hugh Leslie <hugh.leslie at oceaninformatics.com> > To: For openEHR technical discussions > <openehr-technical at lists.openehr.org>, William Goossen > <wgoossen at results4care.nl> > Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 > Message-ID: > <140c6ec5f97.27fb.243087f8365f3372debbc7646d5c4c1f at oceaninformatics.com> > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Hi William > > The whole point of at codes is that they ARE an internal terminology and > that an archetype only has to be consistent internally. Of course any node > in an archetype can be bound or mapped to one or more terminologies as > necessary. The openEHR work is well proven in many contexts, and your > statements are only a matter of opinion rather than any science. > > Regards Hugh > > > > --- Original message --- > From: William Goossen <wgoossen at results4care.nl> > Date: 28 August 2013 7:16:13 PM > Subject: Re: openEHR-technical Digest, Vol 18, Issue 37 > To: "openehr-technical at lists.openehr.org" <openehr-technical at > lists.openehr.org> > CC: "openehr-technical at lists.openehr.org" <openehr-technical at > lists.openehr.org> > >> 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 >>> ************************************************* >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > > ------------------------------ > > 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 38 > *************************************************
