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...
(another 3x)
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] 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
