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-0001.html>
