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.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 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 >>> has_object_path (a_path) >>> >>> in the ADL workbench, we actually pre-compute this in the parse phase, >>> but that isn't necessary of course. >>> >>> - thomas >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130830/ad1d82f6/attachment-0001.html >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Fri, 30 Aug 2013 16:01:56 +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: <5220B3E4.1080706 at oceaninformatics.com <javascript:;>> >>> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >>> >>> >>> You are probably right. I think for the moment I would like to get >>> ADL/AOM 1.5 completed (more or less) with the current assumptions, at >>> least until we can obtain some more evidence (particularly from vendor >>> companies with actual production implementations) and modellers whose >>> archetypes are deployed for real, that would show that we need to change >>> the current status quo. Call me conservative, but I don't like changing >>> things without real world justification! >>> >>> If anyone thinks they can invent better rules for node identification in >>> the meantime, please feel free to post them. It may be that we can make >>> ADL/AOM work in a way that accommodates different 'modes' of operation. >>> >>> - thomas >>> >>> On 30/08/2013 07:27, David Moner wrote: >>>> >>>> >>>> >>>> 2013/8/29 Thomas Beale <thomas.beale at oceaninformatics.com<javascript:;> >>>> <mailto: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). >>>> >>>> - >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >> http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130830/3393322e/attachment.html >>> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org <javascript:;> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> ------------------------------ >>> >>> End of openEHR-technical Digest, Vol 18, Issue 50 >>> ************************************************* >> >> _______________________________________________ >> 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/20130831/59bbf533/attachment.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 52 > *************************************************
