Thanks Stef, It's a nice paper indeed, and it formulates the confusions I had about SNOMED, which is covering different perspectives of the medical reality. But this leads me to questions I have precisely about the bindings of the ontology part of the archetype. They may need to be more specific. Depending on what ontology we bind to (and here I include everything documenting reality, a reality including models, archetypes, everything!), the binding will have different meanings. For example, let's say we have an archetype node at0000 which we name "blood pressure" in an openEHR.OBSERVATION archetype and we wish to bind this node to an external terminology. I can see three kinds of bindings: 1) Let us assume that there is, available to us, an ontology of information-bearer (or information container) entities, the development of which is so advanced that there is actually a type of such information-bearer entities which corresponds perfectly to the recording of a blood pressure observation, the so-called "perfect match". And by that I'm not saying that the ontology also indicates that such a type has whole-part relationships with recording of systolic blood pressure observation, etc, which is another problem. Well even if this "perfect match" exists, and since the paper introduced by Stef mentions the realist ontological approach (OBO, BFO), I will use their distinctions and say that the EHR is about particulars (instances) and the information-bearer ontology about universals (types, categories, kinds). Therefore, the binding here is a relationship which we would call "instance-of". Note that OBO also develops an ontology of relationships (RO, http://www.obofoundry.org/ro/) where you can find an "instance_of" relationship. 2) Now let's consider that the ontology we want to bind our at0000 node to describes observations, but not their recording. It means that the ontology encountered in 1) was documenting the recording of observations (which, I think, is what an obervation archetype does). In this case we can not use "instance-of", but something like "recording-of" if it exists in the relation ontology. Note that technically, we should probably bind to the particular instance of the blood pressure observation, not directly to the type (category, universal). We may have to compose/coordinate relationships. Something like "recording-of" + "instance-of". 3) Finally let's say that we have available an ontology which is not about the information-bearer entities, not about observations, but about "dependent continuants" (entities which endure, but depend on another entity for existing) which we observe, for example qualities, such as the blood pressure is the quality of a human, or a blood system. We need an "observation-of" relationship, and the final binding will look like "recording-of" + "observation-of" + "instance-of".
The relationships help the system to make sense of the meaning pointed to in the archetype ontology and thus actually use the reasoning/knowledge available externally. Is there a way to integrate them in the AOM? Stef Verlinden wrote: > For those of you interested in the 'problems' within Snomed as an ontology, > here (http://precedings.nature.com/documents/3465/version/1) you can find a > good and recent article describing them. This doesn't mean we shouldn't use > Snomed, but knowing where the problems are is helpful to find solutions as > Thomas already stated. > > Cheers, > > Stef > > > Op 11 mrt 2010, om 11:06 heeft Mikael Nystr?m het volgende geschreven: > > >> Hi Michael, >> >> I agree that post-coordination is useful when mapping to SNOMED CT and it >> works well in many cases. However, to be able to create post-coordinated >> concepts the pre-coordinated "building blocks" have to already exist in the >> terminology, which are not always the case. There are sometimes also harder >> to reuse information mapped to post-coordinated concepts than >> post-coordinated concepts, because the hierarchies around the >> post-coordinated concepts are generally not so tailored for the >> post-coordinated concepts as the hierarchies around pre-coordinated concepts >> are. >> >> It is also only SNOMED CT and a few other terminology systems that allow >> post-coordination, so for the majority of terminology systems >> post-coordination isn't possible to use. >> >> My view is therefore still that creating archetypes and the terminology >> bindings in parallel is better than fist create the archetypes and >> afterwards add terminology bindings. >> >> Greetings, >> Mikael >> >> >> >> -----Original Message----- >> From: openehr-technical-bounces at chime.ucl.ac.uk >> [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of >> Michael.Lawley at csiro.au >> Sent: den 11 mars 2010 01:46 >> To: openehr-technical at chime.ucl.ac.uk >> Subject: Re: Term bindings in archetypes and templates >> >> >> Hi Mikael, >> >> You may be interested in our mapping tool, Snapper, which is designed to >> tackle this problem for mapping to (not from) SNOMED CT. It provides >> extensive support for mapping to post-coordinated expressions where >> single-concept maps are not possible and can be used to create unofficial >> extensions to SNOMED CT. >> >> More details and a short screen-cast are on our website >> http://aehrc.com/snapper >> >> Cheers, >> michael >> >> -- >> Dr Michael Lawley >> Principal Research Scientist >> The Australia e-Health Research Centre http://aehrc.com/ >> +61 7 3253 3609; 0432 832 067 >> >> "Ein Fl?gel und einen Schnabel machen kein Vogel" >> >> >> On 11/03/10 9:49 AM, "Mikael Nystr?m" <mikael.nystrom at liu.se> wrote: >> >> Thomas Beale wrote: >> >> >>> On 10/03/2010 22:16, Mikael Nystr?m wrote: >>> >>>> I belong to a group that, except for openEHR related research, also do >>>> research about terminology systems and terminology systems mapping. >>>> During mapping from one terminology system to another terminology >>>> system is it quite common to be unable to map properly, because the two >>>> terminology systems have divided the domain in different ways. This >>>> problem appears even when mapping to SNOMED CT, which have a broad >>>> coverage and a concept model allowing a broad set of relationships. My >>>> view is that the same problem will appear when finalized archetypes are >>>> bound to existing terminology systems. >>>> >>> it will certainly appear. The question is: for those archetype nodes that >>> it is useful to bind to terminology (likely to be 10% or less), how close >>> is the match? For example, in labs, it should be nearly spot on. For >>> anatomy, it should be pretty close. For diseases, the disease concept in >>> an archetype will assume that it is coded in the first place by >>> terminology, so the only problem there is mapping problems from ICD to SCT >>> etc. I think we need to look at the actual size of the concrete problem, >>> not its theoretical worst case. >>> >> I agree that we have to wait and see how much problems we will get. That was >> also my reason to reply to Sebastian's e-mail which told that there is no >> problem to add terminology bindings after the archetypes are finalized. >> >> However, I didn't refer to "theoretical worst case". I referred to actual >> problems that have appeared for us during both our research work and in our >> national SNOMED CT project in Sweden. >> >> Greetings, >> Mikael >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
