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
From: openehr-technical-bounces@chime.ucl.ac.uk [mailto:openehr-
technical-bounces@chime.ucl.ac.uk] On Behalf Of Fabrice Camous
Sent: Friday, 12 March 2010 2:47 AM
To: openEHR-technical@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
From: openehr-technical-bounces@chime.ucl.ac.uk
[mailto:openehr-technical-bounces@chime.ucl.ac.uk] On Behalf Of
Michael.Lawley@csiro.au
Sent: den 11 mars 2010 01:46
To: openehr-technical@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"
Thomas Beale 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@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@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@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@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
)