Hi all, First of all, sorry for not replying earlier. The discussion seems to have moved on from the term bindings to the possible use of ontological terms in EHR systems. This gives me the opportunity to make a few points which I hope will be helpful whether one uses the information-model approach, the ontology approach, or a combination of both.
1) Ceusters and Smith (2010) is an interesting paper but maybe not such a good introductory paper to what I what would call the BFO (basic formal ontology) approach, a particular approach to developing ontologies (more on that distinction later). For those of you interested in the BFO approach, I recommend Smith (2006) for the refinement of terminologies into ontologies, and Ceusters and Smith (2006) for the use of ontological terms in the EHR. To be fair to Ceusters and Smith (2010), it is actually a response to a previous assertion that "BFO has shortcomings for representing medical information at the granular level". So the statements are intentionally complex to respond to the need of some clinicians who may want to describe what they observe at that level of complexity. It does not preclude other clinicians from developping a BFO ontology with the desired level of complexity or simplicity. If an ontology developped to talk about malaria at a high level of complexity has nonetheless more generic terms that other clinicians can use to communicate in a particular setting, then they may reuse the terms. Otherwise they may develop their own ontology. Reuse, reuse, reuse. Sounds familiar? Indeed an unused ontology is as useless as an unused set of archetypes. The point here is: ontologies, like archetypes, are supposed to be developped by people who will use them, or by people close enough to the users so that they won't have to use terms and relationships which are irrelevant to the information they want to convey. 2) The mutual criticism about concept-oriented and ontology approaches found in the literature seems to come partly from a mutual (intentional?) misunderstanding on the definition of terms like "concept" or "reality". Both camps will tend to use a restrictive definition of the terms to show the limitations of the other camp's approach. Event if all SNOMED terms are called concepts, more precisely "SNOMED concepts", and if reference model objects are information model components, they are not necessarily outside the reality defined by the BFO approach, and definitely not outside the more general ontological approach. The fact that Cimino (2006) defines diseases, diagones, and aspirin allergies as concepts does not mean, of course, that he does not believe in their existence outside clinician's heads. And if you look at the reality defined even in the restricted BFO approach, you will find that it is more inclusive than is usually understood: Ceusters and Smith (2010) state that BFO "is intended to represent exclusively types of entities that exist in reality, including information entities such as databases or clinical charts, as well as disease entities such as malaria or influenza." But reference model objects and instructions found in archetypes ARE information entities, the instances of which are found in repositories and messages expressed in various formats. A reference model object would probably be a kind of "generically dependent continuant" according to the Ontology for General Medical Science (OGMS) see http://ogms.googlecode.com/svn/releases/2010-01-29/web/ogms.html), basically an enduring class which depends on another information bearer (e.g. a database). This realism approach isn't so scary, and the conceptual approach not so messy. Partly the ontological approach, and the BFO one in particular, wants to introduce some rigor in developping ontologies, which information models and terminologies are, even if not perfect (nor are BFO ontologies by the way). The refinement does not need to be some systematic attemp to introduce high levels of complexity. It can just consist in distinguishing, for example, between "malaria" as denoting the disease and "malaria" as denoting the fact that one clinician found malaria in the patient. One can speculate on finding something like "suspicion of malaria" as a special kind of the ambiguous "malaria" defined above. The ontological approach can be limited to this common sense clean-up, which does not mean it's not a laborious task in itself. 3) What? The openEHR specifications are ontologies? Let me explain: What is ontology development? Is it not just an agreement (implies collaboration) between domain experts on the representational units (codes, terms) pointing to the domain entities (classes, types) they wish to talk about and the relationships between such entities? Smith et al. (2006) states that an ontology is a "representational artifact, comprising a taxonomy as proper part, whose representational units are intended to designate some combination of universals, defined classes, and certain relations between them". Or, as some presenter said in a webinar I attended, ontologies are just good documentations. And so are the openEHR specifications, they tell us about classes named ARCHETYPE, COMPOSITION, ITEM_LIST, and so on, and by using these terms (but they could be codes, icons), you all know what I am talking about because I point to the documentation. So are the openEHR specifications ontologies? I'd say yes. Are they BFO ontologies (following BFO guidelines for ontology development)? Not quite. Some work is required to link up to an upper-level ontology like the BFO. But just like openEHR reference model is orthogonal to the archetype object model, most ontologies are expected to be orthogonal, i.e. not to overlap. If they weren't, it would show duplication, lack of reuse during ontology development. So it's ok for nurses, clinicians, lab people to develop ontologies if they don't find their classes in the already developed ontologies. Ontology development is descriptive, not prescriptive. 4) If two or more orthogonal ontologies are used in combination, one has to define how much of each one will use. The openEHR and EN13606 approaches, for example, describe structures of reference model objects and offer a way to label each component with a code from an external terminologies. It does not mean (and that's not the intention of archetypes), that each component or node now also denotes the entity pointed at by the code in the chosen terminology. It doesn't mean either that the relationships between the node in the archetype (as described in the model) are mimicking relationships between the entities denoted by the codes used to label the nodes in the archetype. All of this is perfectly fine and, as Sam said, as long as experts will know how to extract the information and as they know about the relationships between entities denoted by codes (relationships which are not in the archetype), they have no problem interpreting the information. If we pretend that the reference model describes paper-based components, where our objects are folders, separators, sheets, it means that our archetypes lead to very structured pages (ignoring the folder and separator arrangements), with sub-sub-sections and sub-sub-paragraphs with sentences (leaf nodes) which are very short. In contrast, the BFO people would probably like a more balanced use/combination of the two approaches/ontologies. The page is still very structured, but at one point the ADL switches to some other formal language which may or may not allow complex statements such as the ones described in Ceusters and Smith (2010). Note that this more balanced approach may not necessarily lead to a better semantical interoperability of data captured by different groups of health care professionals. If the reality of the HCPs is to far apart, the ontologies they use, even if they follow the BFO guidelines, will be very orthogonal to each other and the data they describe might not be easily integrated. Hopefully, these realities overlap, and so will the terms and archetypes used at different locations of care delivery. That's it. I hope these points are useful (they were for me), and that they show that the different approaches, all very valuable of course, involving decades of work, are closer than it appears, and will hopefully yield real benefits to health care, whether they're used independently or combined in a more or less balanced way. Happy Easter, Fabrice * Werner Ceusters and Barry Smith (2006). Strategies for Referent Tracking in Electronic Health Records. Journal of Biomedical Informatics. Volume 39 , Issue 3 (June 2006). Special issue: Biomedical ontologies. Pages: 362 - 378. * Ceusters W, Smith B (2010). Malaria Diagnosis and the Plasmodium Life Cycle: the BFO Perspective. In: Mizoguchi R and Smith B (eds.) Interdisciplinary Ontology; Proceedings of the Third Interdisciplinary Ontology Meeting (InterOntology 2010, Tokyo, Japan, February 27-28,2010). Tokyo, Keio University Press, 2010, 25-34. * Cimino JJ. (2006). In defense of the desiderata. J Biomed Inform. 2006;39:299-306. * Barry Smith (2006). From Concepts to Clinical Reality: An Essay on the Benchmarking of Biomedical Terminologies. J Biomed Inform. 2006 Jun;39(3):288-98. * Smith et al. (2006). Towards a reference terminology for ontology research and development in the biomedical domain. Proc. of KR-MED 2006. Sam Heard wrote: > Hi, > > This is an interesting discussion. I think we need to keep a sense of > purpose here in what we are doing. We need to understand that the complexity > of biomedicine is probably unsurpassed and the language of health > professionals is a way of dealing with this. It has historical roots which > allows people to drill down when appropriate. The paper by Werner and Barry > on malaria illustrates the difficulties. So we will find, if we look hard > enough, that there are massive imperfections in what clinicians record but > these imperfections are generally understood by those that need to know > about them. > > I remember a story about a medical teacher when I was young asking a rather > impertinent student what they knew about the cause of rheumatoid arthritis. > He said "Nothing". And then he asked the student "And what do I know about > the cause?" He again said "Nothing". The teacher nodded and added "But don't > underestimate the gap between what you know about the cause of rheumatoid > arthritis and what I know". > > We don't call rheumatoid arthritis idiopathic arthritis because we have > accepted the syndrome and its histological features. We know the prognosis > and outcomes in many situations. Patient's would like to know why - but we > can't tell them. Malaria is actually four diseases - two of which actually > are rather different from the other two. Pneumonia, from the perspective of > causation, is actually 100s of diseases all with a similar pathology. When I > read the paper on malaria by the ontology guys I learned a lot. I have > diagnosed and treated malaria quite a few times in my life but did not know > some features of the life cycle of the plasmodium and the features that > Werner and Barry are describing at times are not of clinical significance. > > So where does ontology get in the way of good health care? I would suggest > it is when there is no 'drill down'; that complexity is presented as a flat > knowledge space. Deep knowledge in clinical practice, what is needed to > provide the best care, is not necessarily detailed knowledge - the latter is > usually the preserve of bioscientists and clinicians researching an area. > They might come back to us with more detail that alters the knowledge > required to provide the best care. It is then that deep knowledge shifts. > More detailed knowledge does not necessary lead to more complex deep > knowledge. Asthma is a good example. Treatment used to be a nightmare but as > we have learned more it is really quite simple to manage. > > So I just want to challenge the approach of linking to ontologies. I would > like to propose a simplification. If we take the archetypes as the purest > expression available of what clinicians want (or are able) to record then we > have something. We can organise and classify these in future to make them > very available. CKM has started that process and it will get more > sophisticated. > > The task then for term_bindings is to link points in archetypes to > terminology so that other people can understand from that perspective what > we are talking about. I would argue that there are two approaches. First is > to find a term in a terminology that says exactly what the archetype is > recording. The second approach is to find the observable entity that is > being recorded. > > It becomes absurd at one level to think about the things that you might > describe: > - the notion of the thing that might be observed (blood CO2 level) > - the procedure for measuring it (which might be complex) and everything > about that > - the recording of the value of the thing that has been observed and any > confounding factors > - the actual value of the thing observed. > The archetype actually records many of these things as well as the value. A > pure ontology for such a thing will get massively complex. Do we have the > procedure for measuring the confounding factors, the recording of the > procedures for measuring them, the actual value of these etc. If we are > measuring the blood gas there may be may features of the measuring process > that we want to record - do we have observable entities for all of these, > procedures for measuring them and recording and values. > > I hope you can see where we are going here. We have to stay anchored in what > is useful and effective clinical practice. The fractal nature of this is > becoming clear and we will see just how fractal things get when we start > recording genetic features of cancers (and people). > > I think we should start by working purely with term_bindings for the > observable entity that is expressed in the archetype - as a whole and then > for each entry in the data section of the observation if that is helpful. > > I find this a very fruitful area of enquiry and I do not want to stifle it > at all - just to point out that what might appear imperfections often are > important kludges that are shared widely and work in real practice. > > Cheers, Sam > > >> -----Original Message----- >> From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr- >> technical-bounces at chime.ucl.ac.uk] On Behalf Of Fabrice Camous >> Sent: Friday, 12 March 2010 2:47 AM >> To: openEHR-technical at openehr.org >> Subject: Re: Term bindings in archetypes and templates >> >> 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 >> _______________________________________________ >> 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
