Hi tom,
I can agree with you that if SNOMED CT was created when all patients in the
world already had all information in their health record recorded using
cleverly built and structured information models (like archetypes, templates
and similar), but that is not the case. Instead SNOMED CT also tries to help
healthcare organizations to do something better also with their already
recorded health record information, because that information to a large extent
still belongs to living patients.
It would be interesting to have your opinion about why it is a real problem
with the "extra" pre-coordinated concepts in SNOMED CT in general and not only
for the use case of creating archetypes or what would be nicest in theory.
Regards
Mikael
Från: openEHR-technical [mailto:[email protected]]
För Thomas Beale
Skickat: den 23 mars 2018 01:06
Till: [email protected]
Ämne: Re: SV: [Troll] Terminology bindings ... again
I have made some attempts to study the problem in the past, not recently, so I
don't know how much the content has changed in the last 5 years. Two points
come to mind:
1. the problem of a profusion of pre-coordinated and post-coordinatable
concepts during a lexically-based choosing process (which is often just on a
subset).
this can be simulated by the lexical search in any of the Snomed search
engines, as shown in the screen shots below. Now, the returned list is just a
bag of lexical matches, not a hierarchy. But - it is clear from just the size
of the list that it would take time to even find the right one - usually there
are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood
pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood
pressure' and many more.
I would contend (and have for years) that things like 'sitting blood pressure',
'stable blood pressure', and 'blood pressure unrecordable' are just wrong as
atomic concepts, each with a separate argument as to why. I won't go into any
of them now. Let's assume instead that the lexical search was done on a subset,
and that only observables and findings (why are there two?) show up, and that
the user clicks through 'blood pressure (observable entity)', ignoring the 30
or more other concepts. Then the result is a part of the hierarchy, see the
final screenshot. I would have a hard time building any ontology-based argument
for even just this one sub-tree, which breaks basic terminology rules such as
mutual exclusivity, collective exhaustiveness and so on. How would the user
choose from this? If they are recording systolic systemic arterial BP, lying,
do they choose 'systemic blood pressure', 'arterial blood pressure', 'systolic
blood pressure', 'lying blood pressure', or something else.
Most of these terms are pre-coordinated, and the problem would be solved by
treating the various factors such as patient position, timing, mathematical
function (instant, mean, etc), measurement datum type (systolic, pulse, MAP
etc), subsystem (systemic, central venous etc) and so on as post-coordinatable
elements that can be attached in specific ways according to the ontological
description of measuring blood pressure on a body. This is what the blood
pressure archetype does, and we might argue that since that is the model of
capturing BP measurements (not an ontological description of course), it is the
starting point, and in fact the user won't ever have to do the lexical choosing
above. Now, to achieve the coding that some people say they want, the archetype
authors would have the job of choosing the appropriate codes to bind to the
elements of the archetype. In theory it would be possible to construct paths
and/or expressions in the archetype and bind one of the concepts from the list
below to each one. To do so we would need to add 40-50 bindings to that
archetype. But why? To what end? I am unclear just who would ever use any of
these terms.
The terms that matter are: systemic, systolic/diastolic, terms for body
location, terms for body position, terms for exertion, terms for mathematical
function, and so on. These should all be available separately, and be usable in
combination, preferably via information models like archetypes that put them
together in the appropriate way to express BP measurement. Actually creating
post-coordinated terms is not generally useful, beyond something like 'systemic
arterial systolic BP', or just 'systolic BP' for short, because you are always
going to treat things like exertion and position separately (which is why these
are consider 'patient state' in openEHR), and you are usually going to ignore
things like cuff size and measurement location (things considered as
non-meaning modifying 'protocol' in openEHR).
2. similar problems in the authoring phase, i.e. addition of concepts to the
terminology in the first place. If more or less any manner of pre-coordinated
terms is allowed, with the precoordinations cross-cutting numerous ontological
aspects (i.e. concept model attribute types), what rules can even be
established as to whether the next proposed concept goes in or not? It is very
easy to examine the BP hierarchy, and suggest dozens of new pre-coordinated
terms that would fit perfectly alongside the arbitrary and incomprehensible set
already there...
[cid:[email protected]]
(another 3x)
[cid:[email protected]]
[cid:[email protected]]
I've picked just the most obvious possible example. We can go and look at
'substances' or 'reason for discharge' or hundreds of other things, and find
similar problems. I don't mind that all these pre-coordinated concepts exist
somewhere, but they should not be in the primary hierarchies, which really, in
my view should look much more like an ontology, i.e. a description of reality
which provides a model of what it is possible to say. If that were the case,
the core would be much smaller, and the concept model much larger than it is
today.
- thomas
On 22/03/2018 00:26, [email protected]<mailto:[email protected]>
wrote:
Hi Heather,
In general, anyone is welcome to participate in the work; you don't need to be
one of the small number of Advisory Group members. That helps with travel
costs, but most of the real work is done on teleconferences, not so much at the
face to face meetings.
I would be very interested to hear people's articulations of where they think
the boundary should be for this boundary line. I'd also be interested to
understand better what people think the problem is with having "extra" /
unnecessary pre-coordinated concepts; what advantage is to be gained from
removing them, and what is the perceived scale of the problem.
michael
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture
blog<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
