Re: SV: SV: [Troll] Terminology bindings ... again

[Thomas Beale]

Hi Mikael,

On 23/03/2018 09:05, Mikael Nyström wrote:


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.




but that would appear to be an argument that since data in systems is 
dirty, badly designed, so SNOMED will reflect this by being badly 
designed! I don't agree with this at all. I think that the majority of 
SCT concepts which are arbitrary pre-coordinations (presumably due to 
the fact that someone saw them in real data, or knows they are in use in 
their hospital) constitute part of a (pretty messy, but practically 
useful) interface terminology. I remember myself and others arguing for 
this in the I standing committee in about 2011.


That should be moved to a whole separate 'piece' of SNOMED - leaving a 
clean core that follows proper rules like mutual exclusion, collective 
exhaustiveness, coherence in distinction criteria down the IS-A tree and 
so on. That core would be small, manageable, and the concept model could 
then be worked on properly to build it out, providing a far richer basis 
for pre-coordination. This model would be something that certain 
archetype structures could be harmonised with. (Note though that many 
archetype structures don't have a biochemical or biophysical basis, but 
something like 'cultural models of recording').


The interface part could then start to be cleaned up and have some 
discipline of its own; it could be more effectively connected to tools 
that are actually used in real interfaces, like choosing widgets, or 
underlying logic for searching. These terms would all be mapped back to 
the core via post-coordinated expressions - the ultimate test of the 
approach.


The main problem with the current state of affairs is simply that the 
vast majority of concepts creates incoherent cognitive noise when people 
are trying to:


 * bind archetype elements to terminology
 * create terminology subsets for particular uses - form fields and so on
 * curate SNOMED itself

In these situations, anytime anyone looks up a concept lexically, they 
get what I showed in the previous post (the actual list for BP is 3 
times that) - a huge list that they try to mentally process - 
unnecessarily. Errors will of course come with this.



- thomas



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




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

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:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 23 mars 2018 01:06
Till: openehr-technical@lists.openehr.org
Ä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 

SV: SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Heather,

SNOMED International collaboration site is nowadays located at the address 
https://confluence.ihtsdotools.org/ . (It seems unfortunately that the link is 
more clicks away from the start page than before. :-( ) At that address, you 
can click "Spaces" in the upper left corner of the page and then "Space 
directory". You will then find a long list with the collaboration space for 
different groups and other resources. To my knowledge there aren't any group 
called exactly "information modelling group", but there are several groups that 
work will modelling, so maybe the group has another name? If you only would 
like to read the material, I think that you don't need any account on the site, 
but if you would like to participate a little closer, you can apply for an 
account on the Confluence site.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Heather Leslie
Skickat: den 22 mars 2018 08:01
Till: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Ämne: RE: SV: [Troll] Terminology bindings ... again

HI Michael,

I have no idea what teleconferences are happening. I don't know how to engage. 
It's not easy from the outside!

Heather

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of michael.law...@csiro.au<mailto:michael.law...@csiro.au>
Sent: Thursday, 22 March 2018 11:26 AM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: SV: [Troll] Terminology bindings ... again




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


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Heather Leslie 
<heather.les...@atomicainformatics.com<mailto:heather.les...@atomicainformatics.com>>
Sent: Thursday, 22 March 2018 9:46 AM
To: For openEHR technical discussions
Subject: RE: SV: [Troll] Terminology bindings ... again

Hi Mikael,

What efforts are being made to resolve the boundary problem?

I applied to get involved with the  SNOMED information modelling group but 
wasn't successful, to try to engage on exactly that  point.

I'm not aware of any work going on. I'd be very pleased to get involved if I 
could. It's a fiendish problem and we need cooperation and collaboration from 
both sides of the fence.

Regards

Heather

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi Tom,

I believe that you proposal to "move / remove the pre-coordinated codes out of 
SNOMED" is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don't have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on inco

SV: SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Tom,

I believe that you proposal to ”move / remove the pre-coordinated codes out of 
SNOMED” is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don’t have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to critique SNOMED, as long as that critique is collegial, and 
above all intelligent. (BTW maybe Philippe was not entirely diplomatic, but he 
did implement a very nice post-coordinating terminology and clinical noting 
system, so he knows a thing or two).

So in that sense, I stand by my earlier comments that it would have helped (and 
still would help) if SNOMED International would consider some of my suggestions 
on separation of technology from content, separate the meta-model, and also a 
more serious effort to help connect terminology to information models / content 
models.  We are slowly solving this on our side, but strategic cooperation 
would be better.

One thing is clear: terminology is not a standalone proposition.

- thomas

On 21/03/2018 13:48, Mikael Nyström wrote:

Hi Philippe,



I think that you have missed that SNOMED CT is created for multiple use cases.



Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED 
CT Compositional Grammar and SNOMED CT's concept model.



Another use case, that many implementers consider is important but you don't 
seem to care about, is the ability to handle legacy data to be able to keep a 
life-long  health record. Most people alive today where born when simple health 
records that only used simple coding where in massive use. (When that era 
started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts 
that can represent that kind of information. But SNOMED CT also has a machinery 
to transform between the different representations.  Your example "fracture of 
the left ankle" is not