IMO having both representations (pre and postcordinated) is not bad
per se (in fact, knowing that they are equivalent is pretty good). The
main problem is that technical people (including myself) shouldn't
just dump the entire snomed ct into a data field and call it a day. To
design better and useful systems you need a first "curation" phase
where you define your relevant subsets that fit your system. The
boundary problem is less of a problem if even if different terms were
used when the record was created we can assess that they are in fact
the same thing.
I think people are a little unaware of this step and causes problems
as the ones you and Thomas mentioned
2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland
<[email protected]
<mailto:[email protected]>>:
I read Thomas’ reply with great interest, and I generally agree
that with a well thought out information model, the very detailed
precoordinated expressions are redundant. At the same time I
understand Mikael’s point of view too. BUT, what I’m often met
with is that because these precoordinated expressions exist (like
for example “lying blood pressure” and “sitting blood pressure”),
we should use them INSTEAD OF using our clever information models
(that we do have) for recording new data.
In my opinion this is wrong because it doesn’t take into account
that healthcare is unpredictable, and this makes recording more
difficult for the clinician. How many different variations would
you have to select from? Take the made up example “sitting
systolic blood pressure with a medium cuff on the left upper arm”;
this will be a lot of possible permutations, especially if you
take into account all the different permutations where one or more
variable isn’t relevant.
So while I don’t think the existence of these precoordinated terms
in itself is a problem, it’s a potential problem that people get a
bit overzealous with them.
Regards,
*Silje*
*From:*openEHR-technical
<[email protected]
<mailto:[email protected]>> *On Behalf
Of *Mikael Nyström
*Sent:* Friday, March 23, 2018 10:06 AM
*To:* For openEHR technical discussions
<[email protected]
<mailto:[email protected]>>
*Subject:* SV: SV: [Troll] Terminology bindings ... again
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]
<mailto:[email protected]>] *För *Thomas
Beale
*Skickat:* den 23 mars 2018 01:06
*Till:* [email protected]
<mailto:[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...
(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]
<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]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
--
VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>
Twitter <https://htmlsig.com/t/000001C47QQH>LinkedIn
<https://htmlsig.com/t/000001C4DPJG>Maps
<https://htmlsig.com/t/000001BZTWS7>
Diego Boscá Tomás / Senior developer
[email protected]<mailto:[email protected]>
[email protected] <mailto:[email protected]>
VeraTech for Health SL
+34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023
<tel:+34%20627%2001%2050%2023>
www.veratech.es <http://www.veratech.es/>
Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF
B98309511) cuya finalidad es la de mantener el contacto con usted.
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos
de acceso, rectificación, cancelación y, en su caso oposición,
enviando una solicitud por escrito a [email protected]
<mailto:[email protected]>.
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
