Now you mention reuse and consistency and I understand you better, also because I know you are working on DCM. The context of your message becomes more clear.
The atxxxx codes are generated in the archetype-editors, so there is no semantics to them. The room for explanations of the node, as you know, is in the ontology-section. I think, this is the idea behind it: It is a requirement that those at-codes are unique inside an archetype (except from internal references), if they would be allowed to be not unique, it could easily come to messed up archetype-paths. Because they need to be unique, it is very inconvenient for archetype-editors to let them define manually by humans. The checks for at-codes for being unique would drive the human archetype designer crazy, especially in large archetypes. The at-nodes do not identify data points outside an archetype, that purpose is being served by the archetype-path, which also contains the archetypeids being involved (in case of slots, more then one) The items in ontology are very limited, only text and description. I must agree that this is not much, especially if you want the at-nodes being explained by code systems. But on the other hand, it is easy to introduce a sanity-rule. Let the text be a code, and let the description be the indicator of the code-system involved. I must agree that it is not forced, thus weak. Better was to extend the ontology with appropriate items. Do you think that would be a good idea? Bert Op zaterdag 31 augustus 2013 schreef William Goossen ( wgoossen at results4care.nl): > Dear Bert, > > I mean any kind of archetype, but in particular different archetypes for > the same concept, eg blood pressure. > > Thy can have internally the same atXxxx code for different nodes. > > I mean the the harmonization of data elements is done manually by human > beings, in order to allow data exchange by different systems. > > I find it awkward that similar to archetypes, the message or CDA content > for clinical concepts that are equal are coded / defined differently. This > prevents reuse and prevents consistency. > > > Vriendelijke groet, > > Dr. William Goossen > > Directeur Results 4 Care BV > +31654614458 > > Op 31 aug. 2013 om 08:44 heeft openehr-technical-request at > lists.openehr.orghet 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 50 (Bert Verhees) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sat, 31 Aug 2013 08:44:49 +0200 > > From: Bert Verhees <bert.verhees at rosa.nl> > > To: For openEHR technical discussions > > <openehr-technical at lists.openehr.org> > > Subject: Re: openEHR-technical Digest, Vol 18, Issue 50 > > Message-ID: > > <CAFL--x9vk8raLpuqH1V4SMAstJCx3j816j6_VyVk+3Y7PGMqsw at mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > Hi William, I do not understand some things in your comment. > > > > Do you mean with "same clinical concept variants of archetypes" that they > > have the same archetypeId? So different archetypes with the same id? > > > > Do you mean with "harmonizing" mapping from datapoints in different > > archetypes (with a different archetypeId) to each other? > > > > In my opinion, this kind of mapping must always be defined manually per > new > > case, like you define manually where to put your datapoints in > > Nictiz-messages. > > > > I think you can never let a machine guess and understand the context in > > which a datapoints exists. > > > > I also cannot imagine a use case in which such (IMO) a risky mapping, > > defined by machine, would be appropriate. > > > > I will be very pleased if you will clarify on this. > > > > thanks in advance > > > > Bert > > > > Op vrijdag 30 augustus 2013 schreef William Goossen ( > > wgoossen at results4care.nl): > > > >> Semantic interoperability is absolutely compromised when for the same > >> clinical concept variants of archetypes are created. > >> If justified for internal system development , the moment exchange with > >> another system requires harmonizing on datapoint to datapoint level. I > have > >> done about 2000 in perinatology 800 in stroke care 1250 in youth care > 100 > >> in nursing oncology 20 in reuma, 400 in general nursing 250 in diabetes > >> care 200 in GP care 100 in cardiology. In the past 13 years. > >> The inconsistencies for the same data element in the various domains are > >> BIG, without clinical justifiable reasons. > >> That same situation exists if you have locally / vendor specific > >> arechetypes . > >> > >> Vriendelijke groet, > >> > >> Dr. William Goossen > >> > >> Directeur Results 4 Care BV > >> +31654614458 > >> > >> Op 30 aug. 2013 om 17:02 heeft > openehr-technical-request at lists.openehr.org<javascript:;>het volgende > geschreven: > >> > >>> Send openEHR-technical mailing list submissions to > >>> openehr-technical at lists.openehr.org <javascript:;> > >>> > >>> 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 <javascript:;> > >>> > >>> You can reach the person managing the list at > >>> openehr-technical-owner at lists.openehr.org <javascript:;> > >>> > >>> 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 38 (Bert Verhees) > >>> 2. RE: Polishing node identifier (at-codes) use cases. (pablo pazos) > >>> 3. Re: Polishing node identifier (at-codes) use cases. (Thomas Beale) > >>> 4. Re: Polishing node identifier (at-codes) use cases. (Thomas Beale) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Fri, 30 Aug 2013 11:49:00 +0200 > >>> From: Bert Verhees <bert.verhees at rosa.nl <javascript:;>> > >>> To: openehr-technical at lists.openehr.org <javascript:;> > >>> Subject: Re: openEHR-technical Digest, Vol 18, Issue 38 > >>> Message-ID: <52206A8C.5050108 at rosa.nl <javascript:;>> > >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>> > >>> On 08/30/2013 12:26 AM, Thomas Beale wrote: > >>>> On 29/08/2013 20:53, Bert Verhees wrote: > >>>>> > >>>>> > >>>>> I think, it has to also some connection with the idea of one world > >>>>> wide archetype-repository. But we found out in discussion, this will > >>>>> never happen. So now, in the new ADL-standard, 1.5, there will be > >>>>> room for namespace. Archetypes will not be centralized maintained, > >>>>> but every company will have its own set. > >>>> > >>>> Companies could make their own set, and sometimes they will make their > >>>> own specific archetypes, but in the majority, I think they will re-use > >>>> what is already available. Consider: to create from scratch 20 or so > >>>> key archetypes (perhaps 400 data points) that has taken 100s of hours > >>>> of expert clinician time and quality assurance - very few companies > >>>> could attempt that. Also, companies that routinely make products with > >>>> archetypes that noone else uses and/or companies that don't share > >>>> truly new archetypes.... won't have many interoperability partners. > >>> > >>> In the environment I worked last few years, we created maybe 50 > >>> archetypes, few more or less. We did not use one of CKM, but a some > were > >>> inspired by CKM. > >>> > >>> My experience is that customers, users of our OpenEHR services, wanted > >>> their own archetypes. > >>> Interoperability was achieved by adopting a message-format which serves > >>> the purpose. > >>> ---- > >>> But I know, this is only my experience in those few projects I worked > on. > >>> > >>> When companies are using the same archetypes, as you indicate, then > >>> interoperability over those archetypes is of course no problem at all. > >>> And because they know very well the archetypes they send or receive, > >>> they will know exactly know what the meaning is of every data-item, and > >>> at-codes/archetype-paths are sufficient to identify the data-items. > >>> > >>> Bert > >>> > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 2 > >>> Date: Fri, 30 Aug 2013 10:23:19 -0300 > >>> From: pablo pazos <pazospablo at hotmail.com <javascript:;>> > >>> To: openeh technical <openehr-technical at lists.openehr.org<javascript:;> > >>> > >>> Subject: RE: Polishing node identifier (at-codes) use cases. > >>> Message-ID: <SNT145-W4862946AF7715A8B89C7A0C8350 at phx.gbl> > >>> Content-Type: text/plain; charset="windows-1252" > >>> > >>> Hi all, > >>> Maybe this is OT but is related. I remembered a problem I had some time > >> ago working with algorithms that traverses the archetype structure. > >>> For CObjects without nodeID, the path of the CObject is equal to the > >> path of it's parent CAttribute, so when I want to get the node with that > >> path using Archetype.node(path), only one of those nodes will be > returned. > >>> Of course there are workarounds, like checking the type of the returned > >> node, and if a CAttribute is returned but I want the CObject, I just get > >> the node.children()[0]. But that only can be implemented if you know > that > >> the path you're using is a path to a CObject, so it depends on the > context > >> of your algorithm to expect CObject or CAttribute for a path you have > (i.e. > >> if you previously visit a CAttribute and you algorithm traverses from > root > >> to leaves, you'll expect next nodes to be CObjects). > >>>> From a developer point of view, having unique paths would solve a lot > >> of workarounds and ugly code. So having a nodeID for each CObject node > is > >> something I would encourage on tooling. I really don't care of having > more > >> terms in the ontology :) > >>> > >>> -- > >>> Kind regards, > >>> Eng. Pablo Pazos Guti?rrez > >>> http://cabolabs.com > >>> > >>> From: damoca at gmail.com <javascript:;> > >>> Date: Fri, 30 Aug 2013 08:27:39 +0200 > >>> Subject: Re: Polishing node identifier (at-codes) use cases. > >>> To: openehr-technical at lists.openehr.org <javascript:;> > >>> > >>> > >>> > >>> > >>> 2013/8/29 Thomas Beale <thomas.beale at oceaninformatics.com<javascript:;> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> well the idea here has always been, and remains justified today: > >>> > >>> > >>> an archetype-local definition in words for the meaning of the > >>> node is needed, because this says _exactly_ what the designers > >>> intended > >>> those meanings are given by domain experts, and (with some > >>> review, QA process) will be as good as any linguistic definition > >>> in any ontology or terminology (probably better, because they > >>> are specific to the case at hand) > >>> > >>> > >>> if we are lucky enough to find some code that matches, or > >>> approximately describes the same thing in an ontology and/or > >>> SNOMED CT / LOINC etc, then we can add those bindings > >>> > >>> If we were only allowed to define nodes for which matching codes > >>> can be found in OBO, SNOMED or other supposedly reliable places, > >>> then we would have no chance of building anything but the most > >>> meagre archetypes, and no ability to build semantically enabled > >>> health information systems. > >>> > >>> > >>> > >>> I don't know of any facts that would contradict this > >>> long-standing position today... > >>> > >>> > >>> > >>> > >>> > >>> I'm not contradicting those positions, which I agree, I'm just saying > >> that this is a very subjective topic, dependant on the context of use, > the > >> availability of some resources (e.g terminological codes) and many other > >> factors. So, we can all do our best but it will be very difficult to > have > >> rules that guide which nodes of the archetype have to be identified just > >> based on a structural matter (the rules you asked for). > >>> > >>> > >>> > >>> -- > >>> 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) > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> openEHR-technical mailing list > >>> openEHR-technical at lists.openehr.org <javascript:;> > >> > 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/20130830/64b43b25/attachment-0001.html > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 3 > >>> Date: Fri, 30 Aug 2013 15:58:17 +0100 > >>> From: Thomas Beale <thomas.beale at oceaninformatics.com <javascript:;>> > >>> To: openehr-technical at lists.openehr.org <javascript:;> > >>> Subject: Re: Polishing node identifier (at-codes) use cases. > >>> Message-ID: <5220B309.5050703 at oceaninformatics.com <javascript:;>> > >>> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > >>> > >>> On 30/08/2013 14:23, pablo pazos wrote: > >>>> Hi all, > >>>> > >>>> Maybe this is OT but is related. I remembered a problem I had some > >>>> time ago working with algorithms that traverses the archetype > structure. > >>>> > >>>> For CObjects without nodeID, the path of the CObject is equal to the > >>>> path of it's parent CAttribute, so when I want to get the node with > >>>> that path using Archetype.node(path), only one of those nodes will be > >>>> returned. > >>> > >>> the usual thing to do here is to provide two (well actually 4, > including > >>> the 'has' ones) functions: > >>> > >>> c_attribute_at_path (a_path: String): C_ATTRIBUTE > >>> pre-condition > >>> has_attribute_path (a_path) > >>> > >>> c_object_at_path (a_path: String): C_OBJECT > >>> pre-condition > >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/4f72b24d/attachment-0001.html>
