SV: [Troll] Terminology bindings ... again

Heather Leslie heather.leslie at atomicainformatics.com
Sun Mar 25 16:36:45 EDT 2018


Hi Jussara,

Our approach to building archetypes at present are intended to represent the data as domain experts require it and making no assumptions about the terminology used, including use of pre/post coordination principles etc. The models have to allow end users to choose how they engage with terminology and ensure that it can be represented. As such the international archetypes are maybe overly comprehensive but we have to cater for those using heavily post coordinated SCT terms through to others using only local value sets.

We have deliberately avoided having separate models that assume pre/post coordination as per CIMI equivalents because we view that as being ungovernable, and maintenance of semantic equivalence adds layers of complexity that will likely be impossible to maintain.

However I do see a time when we need to publish associated documentation for models that propose ‘best practice’ use of SNOMED and maybe other terminologies, which will then support interoperability with the same value sets being used in the same way.

It is that ‘best practice’ that I’d love to see start to evolve, which includes requirements gathering that results in parallel archetype AND value set definition/development for use cases and defined contexts.

As clinical program co-lead, to the best of my knowledge, at the moment the formal part of openEHR has no direct influence on the SNOMED CT work/priority and that is frustrating.

Collaborative work is where the magic will start to happen!

Cheers

Heather

From: openEHR-technical <openehr-technical-bounces at lists.openehr.org> On Behalf Of Jussara Macedo Rötzsch
Sent: Sunday, 25 March 2018 7:53 AM
To: For openEHR technical discussions <openehr-technical at lists.openehr.org>
Subject: Re: SV: [Troll] Terminology bindings ... again

Heather,

As  you know Brazil has chosen to adopt SNOMED CT on a business case basis, trying to create clinical models that make the better use of structures and meaning.
Therefore my research group has dedicated to study detailed clinical models and to deepen our knowledge of Snomed CT. We agree with GF that we have four ways to do it and that depends  on the use cases.  As Mikael said there’s no fix boundary between when you use pre or post coordinatinated expressions, although context to me naturally is easier to be represented in the structure ( templates).
TO leverage our knowledge os Snomed CT everyone in our team has taken the Snomed CT Foundation Course. I think that many assumptions made here are explained there.
BRAZIL has just joined Snomed CT International. We intend to propose  a creation of a Worlgroup   focussed on DCMs, for the openEHR community, as Thomas tried to do years ago.
I will be In London for the next Business meeting, and gladly would have a meeting with others with the same objective.
Jussara Rötzsch

Em sáb, 24 de mar de 2018 às 04:42, Heather Leslie <heather.leslie at atomicainformatics.com<mailto:heather.leslie at atomicainformatics.com>> escreveu:
Totally agreed, Silje. I think preordination for anatomical location is invaluable, but it’s the only use case that I have identified as one we absolutely can’t do without.

But I would love the opportunity to really investigate this properly, and with others who understand SNOMED better than I. That will help with the boundary issue/semantically grey area.

I’d prefer that we could use and reuse simpler, really high quality value sets from in multiple archetypes for different contexts eg a list of diagnoses in the Problem/diagnosis archetype as well as the Family History archetype. The archetype context is invaluable here. And the terminology community focussing on high value terms that would provide great impact.

Regards

Heather


From: openEHR-technical <openehr-technical-bounces at lists.openehr.org<mailto:openehr-technical-bounces at lists.openehr.org>> On Behalf Of Bakke, Silje Ljosland
Sent: Friday, 23 March 2018 8:35 PM

To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>>
Subject: RE: SV: [Troll] Terminology bindings ... again

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 <openehr-technical-bounces at lists.openehr.org<mailto:openehr-technical-bounces at lists.openehr.org>> On Behalf Of Mikael Nyström
Sent: Friday, March 23, 2018 10:06 AM
To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>>
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:openehr-technical-bounces at lists.openehr.org] För Thomas Beale
Skickat: den 23 mars 2018 01:06
Till: openehr-technical at lists.openehr.org<mailto:openehr-technical at 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 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:image001.png at 01D3C4D5.2B7AC2A0]

(another 3x)

[cid:image002.png at 01D3C4D5.2B7AC2A0]

[cid:image003.png at 01D3C4D5.2B7AC2A0]

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, Michael.Lawley at csiro.au<mailto:Michael.Lawley at csiro.au> 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
openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
[https://docs.google.com/a/coreconsulting.com.br/uc?id=0B7CiG-jOknUHWjE0LUhwZEp2UWs&export=download]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180325/ccb89c96/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20446 bytes
Desc: image001.png
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180325/ccb89c96/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 20006 bytes
Desc: image002.png
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180325/ccb89c96/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 30114 bytes
Desc: image003.png
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180325/ccb89c96/attachment-0005.png>


More information about the openEHR-clinical mailing list