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

[Philippe Ameline]

Le 05/04/2018 à 15:43, Thomas Beale a écrit :

> we really should build a combined descriptive architecture to show how
> all this fits together to solve:
>
>   * the continuum of deterministic - non-deterministic utterances
> possible in healthcare
>   * the linguistic interface v structured info behind question
>

It would be great.
I can provide the wine for those who are interested ;-)

> the second is not the same as the first - there are many docs who
> prefer a language /document / writing / speaking interface than a
> structured form, even if the information really is or could be
> structured in a standard way.
>

Yes, you are plainly right and IMHO they are entitled to do whatever
they want as long as they "feed the ongoing processes with needed
information".
The pity being that there is no such notion in medicine so far... reason
why my current effort is oriented toward providing citizen with a
"personal health project manager" in order to have them demand that
their practitioners behave as contributors in a multidisciplinary team.

> Well, I knew that more than 10y ago when we first talked about this
> ... So much to do :)
>

Probably 15 years ago ;) But at that time, your task was to go get the
legacy systems where they were and offer openEHR as an evolutionary process.
Maybe times are changing... this kind of articles becomes mainstream and
I my bet is that the solution is not inside the box and that a
Copernican revolution from care places to patients as reference frames
is needed.
https://hbr.org/2018/03/to-combat-physician-burnout-and-improve-care-fix-the-electronic-health-record

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

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

[Thomas Beale]

On 05/04/2018 13:50, Philippe Ameline wrote:


In my mind, fils guides and archetype are of different kind: an 
archetype is a flexible information schema and nodes that were "build 
using this mold" keep a link to it ; on the contrary, a fil guide is 
nothing more than a UI helper that makes a one step deep proposal 
(since, when validating a proposed son, you now are on a different 
path (previous one + validated node) and the system will try to find a 
fil guide for this path). Since the process is fully dynamic and local 
to the user (depending on the set of fil guides he uses) the nodes 
don't have to remember what fil guide they originate from.


To sum it up, you can have a journey walking in well known areas 
(archetypes) and finding your way in the wild (tree filling 
interface). When in the wild, you can sometimes be presented with a 
"step wide carpet" (Fil guide) that helps you walk more comfortably 
(this process being iterative, you can "follow the carpet as it 
unfolds", but can also head on in another direction).


well maybe 'structural terminology' is a bad term; what I am really 
talking about is /models of possible content/ (possible utterances).


I was mainly talking about the extra structural elements such as 
"Entry", etc.


Besides, if "models of possible content" are very important inside the 
deterministic area, it would be pretty limited to have the only 
alternative "model of free text". If only because, if you provide 
users with a structured language, you will also be able to detect that 
they enter an area where you can present them with a model. When I 
wrote that a fil guide only makes a "one step ahead" proposal, I 
forgot to mention that it can also trigger an archetype (hey, since 
you are mentioning blood pressure, why not simply fill this form?).


we really should build a combined descriptive architecture to show how 
all this fits together to solve:


 * the continuum of deterministic - non-deterministic utterances
   possible in healthcare
 * the linguistic interface v structured info behind question

the second is not the same as the first - there are many docs who prefer 
a language /document / writing / speaking interface than a structured 
form, even if the information really is or could be structured in a 
standard way.


Well, I knew that more than 10y ago when we first talked about this ... 
So much to do :)


- thomas


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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

Can I understand that you file-guide are patterns that fit archetypes so 
Healthcare Providers can compose whatever they want.
The file-guides insertions are context driven.
The system of file-guides acts like an Ontology for clinical/administrative 
content.
Archetypes define how things are presented in a system-interface.


Gerard Freriks
+31 620347088
gf...@luna.nl

> On 05 Apr 2018, at 14:50, Philippe Ameline  wrote:
> 
> Le 05/04/2018 à 12:16, Thomas Beale a écrit :
> 
>> On 02/04/2018 18:38, Philippe Ameline wrote:
>>> 
>>> Actually, I don't think that I use grammar in an unusual way. If I do it 
>>> technically, lets assume for the sake of the discussion that I am really 
>>> talking about a grammar, ie a set of rules that allows you to interpret an 
>>> arrangement of concepts as a discourse. Typically, a dependency grammar is 
>>> not just a tree representation, but a tree representation where you take as 
>>> a rule that the sons of an element qualify this element. Since every 
>>> natural language sentence can be represented as a dependency grammar tree 
>>> and vice versa, it is possible to assert that a dependency grammar is a 
>>> sufficient grammar.
>> 
>> Right - but the normal sense of 'grammar' is something that controls / 
>> validates sentences made up of words so at least they have acceptable 
>> structural forms, even if they say semantically nonsensical things. The fils 
>> guides 'grammar' is supplying both levels - correct form (by implication, 
>> due to ordering of tree elements as you pass through them) and valid 
>> semantics (due to the content of the tree elements, thus preventing 'colon 
>> of stenosis' but allowing the reverse).
> 
> Let's imagine that there is no fils guide.
> 
> A "patient record" is a graph of trees (means trees which nodes can be 
> interconnected by typed traits, either to connect the description tree that 
> implements a given document description tree, or to follow a given issue over 
> time, etc).
> 
> If you assume that this trees are organized as a dependency grammar and their 
> nodes are filled using an ontology, you don't need anything else to read it, 
> feed smart agents, etc. It is a story told using a structured language (ie a 
> grammar and an ontology).
> 
> Of course, as you mentioned, it is possible that it contains "wrong entries" 
> like "colon located at stenosis".
> 
> In the wild, it can be achieved by providing practitioners with just an 
> interface where they can freely express themselves by building trees (this is 
> the usual interface for encounter notes since it is fully non deterministic).
> Now, for many good reasons, we could want to guide the way (some/most) trees 
> are elaborated (to ease and speed up the process, to make certain that the 
> information we want to process will be "well put", etc).
> In deterministic areas, we can use archetypes. In semi-deterministic areas, 
> we can use fils guides (a flexible way to guess and propose the next "sons" 
> depending on current path).
> 
> In my mind, fils guides and archetype are of different kind: an archetype is 
> a flexible information schema and nodes that were "build using this mold" 
> keep a link to it ; on the contrary, a fil guide is nothing more than a UI 
> helper that makes a one step deep proposal (since, when validating a proposed 
> son, you now are on a different path (previous one + validated node) and the 
> system will try to find a fil guide for this path). Since the process is 
> fully dynamic and local to the user (depending on the set of fil guides he 
> uses) the nodes don't have to remember what fil guide they originate from.
> 
> To sum it up, you can have a journey walking in well known areas (archetypes) 
> and finding your way in the wild (tree filling interface). When in the wild, 
> you can sometimes be presented with a "step wide carpet" (Fil guide) that 
> helps you walk more comfortably (this process being iterative, you can 
> "follow the carpet as it unfolds", but can also head on in another direction).
> 
>> well maybe 'structural terminology' is a bad term; what I am really talking 
>> about is models of possible content (possible utterances).
> 
> I was mainly talking about the extra structural elements such as "Entry", etc.
> 
> Besides, if "models of possible content" are very important inside the 
> deterministic area, it would be pretty limited to have the only alternative 
> "model of free text". If only because, if you provide users with a structured 
> language, you will also be able to detect that they enter an area where you 
> can present them with a model. When I wrote that a fil guide only makes a 
> "one step ahead" proposal, I forgot to mention that it can also trigger an 
> archetype (hey, since you are mentioning blood pressure, why not simply fill 
> this form?).
> 
>> 
>> yes, there is no  doubt that the way you engineered fils guides achieves 
>> this very well, and we have 

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

[Philippe Ameline]

Le 05/04/2018 à 12:16, Thomas Beale a écrit :

> On 02/04/2018 18:38, Philippe Ameline wrote:
>>
>> Actually, I don't think that I use grammar in an unusual way. If I do
>> it technically, lets assume for the sake of the discussion that I am
>> really talking about a grammar, ie a set of rules that allows you to
>> interpret an arrangement of concepts as a discourse. Typically, a
>> dependency grammar is not just a tree representation, but a tree
>> representation where you take as a rule that the sons of an element
>> qualify this element. Since every natural language sentence can be
>> represented as a dependency grammar tree and vice versa, it is
>> possible to assert that a dependency grammar is a sufficient grammar.
>
> Right - but the normal sense of 'grammar' is something that controls /
> validates sentences made up of words so at least they have acceptable
> structural forms, even if they say semantically nonsensical things.
> The fils guides 'grammar' is supplying both levels - correct form (by
> implication, due to /ordering/ of tree elements as you pass through
> them) and valid semantics (due to the /content /of the tree elements,
> thus preventing 'colon of stenosis' but allowing the reverse).

Let's imagine that there is no fils guide.

A "patient record" is a graph of trees (means trees which nodes can be
interconnected by typed traits, either to connect the description tree
that implements a given document description tree, or to follow a given
issue over time, etc).

If you assume that this trees are organized as a dependency grammar and
their nodes are filled using an ontology, you don't need anything else
to read it, feed smart agents, etc. It is a story told using a
structured language (ie a grammar and an ontology).

Of course, as you mentioned, it is possible that it contains "wrong
entries" like "colon located at stenosis".

In the wild, it can be achieved by providing practitioners with just an
interface where they can freely express themselves by building trees
(this is the usual interface for encounter notes since it is fully non
deterministic).
Now, for many good reasons, we could want to guide the way (some/most)
trees are elaborated (to ease and speed up the process, to make certain
that the information we want to process will be "well put", etc).
In deterministic areas, we can use archetypes. In semi-deterministic
areas, we can use fils guides (a flexible way to guess and propose the
next "sons" depending on current path).

In my mind, fils guides and archetype are of different kind: an
archetype is a flexible information schema and nodes that were "build
using this mold" keep a link to it ; on the contrary, a fil guide is
nothing more than a UI helper that makes a one step deep proposal
(since, when validating a proposed son, you now are on a different path
(previous one + validated node) and the system will try to find a fil
guide for this path). Since the process is fully dynamic and local to
the user (depending on the set of fil guides he uses) the nodes don't
have to remember what fil guide they originate from.

To sum it up, you can have a journey walking in well known areas
(archetypes) and finding your way in the wild (tree filling interface).
When in the wild, you can sometimes be presented with a "step wide
carpet" (Fil guide) that helps you walk more comfortably (this process
being iterative, you can "follow the carpet as it unfolds", but can also
head on in another direction).

> well maybe 'structural terminology' is a bad term; what I am really
> talking about is /models of possible content/ (possible utterances).

I was mainly talking about the extra structural elements such as
"Entry", etc.

Besides, if "models of possible content" are very important inside the
deterministic area, it would be pretty limited to have the only
alternative "model of free text". If only because, if you provide users
with a structured language, you will also be able to detect that they
enter an area where you can present them with a model. When I wrote that
a fil guide only makes a "one step ahead" proposal, I forgot to mention
that it can also trigger an archetype (hey, since you are mentioning
blood pressure, why not simply fill this form?).

>
> yes, there is no  doubt that the way you engineered /fils guides/
> achieves this very well, and we have things to learn in terms of
> bridging the gap between linguistic expression and structural
> expression - for now, openEHR has no 'system' to do the former, it is
> just done /ad hoc/ by those who want it.

Fils guides are fit in a semi-deterministic environment and only when
there is a reference ontology available (because it compares user's
current path with semantically similar expert designed paths). I really
hope we can cooperate in this direction.

Philippe

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

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

[Thomas Beale]

On 02/04/2018 18:38, Philippe Ameline wrote:


Actually, I don't think that I use grammar in an unusual way. If I do 
it technically, lets assume for the sake of the discussion that I am 
really talking about a grammar, ie a set of rules that allows you to 
interpret an arrangement of concepts as a discourse. Typically, a 
dependency grammar is not just a tree representation, but a tree 
representation where you take as a rule that the sons of an element 
qualify this element. Since every natural language sentence can be 
represented as a dependency grammar tree and vice versa, it is 
possible to assert that a dependency grammar is a sufficient grammar.


Right - but the normal sense of 'grammar' is something that controls / 
validates sentences made up of words so at least they have acceptable 
structural forms, even if they say semantically nonsensical things. The 
fils guides 'grammar' is supplying both levels - correct form (by 
implication, due to /ordering/ of tree elements as you pass through 
them) and valid semantics (due to the /content /of the tree elements, 
thus preventing 'colon of stenosis' but allowing the reverse).


OpenEHR does this job using templated archetypes, and in more or less 
the same way,. But I wouldn't call this a grammar - it is the underlying 
Reference Model that provides the 'hard' rules of the statement form.


In both cases the 'trees' could be considered models of 'possible things 
to say' - they thus represent models of epistemic knowledge, which is to 
say knowledge about individual instances, obtained or created in the 
clinical process.


In both cases, ontology (or terminology) provides the meaning of any 
mentioned element.




My point is that you have an ontology (say a terminology with terms 
grouped as concepts and concepts interrelated in a semantic network) 
and a true grammar, then there is no need for a "structural 
terminology"... one of the reason being that (part of) this 
terminology can find its place in the ontology.


well maybe 'structural terminology' is a bad term; what I am really 
talking about is /models of possible content/ (possible utterances).




The first advantage is that practitioners can freely "tell whatever 
they want" in a structured way. For example using a tree interface 
with, for example, only the first elements already in place (say 
"encounter" as tree root and SOAP entries as sons). But it doesn't 
seem as the best interface for fully deterministic cases and 
archetypes (in their most basic meaning, ie flexible information 
schemas) are fit. Fil guides are used "in-between", as a way to help 
users fill trees with proposals of the kind "from the path you are 
currently located, you may benefit from this set of sons to carry your 
description one step further". I may elaborate on this.


yes, there is no  doubt that the way you engineered /fils guides/ 
achieves this very well, and we have things to learn in terms of 
bridging the gap between linguistic expression and structural expression 
- for now, openEHR has no 'system' to do the former, it is just done /ad 
hoc/ by those who want it.


- thomas

--
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

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

I will have to digest it.
I’ll be back.

GF

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 11:08, Thomas Beale  wrote:
> 
>  Some theory along these lines 
> 
>  is needed...
> 
> On 03/04/2018 08:35, A Verhees wrote:
>> 
>> GF :"There are NO agreed standardised archetypes/patterns we all use to 
>> define the meta-data in order to document the full eppistemology
>> so data can be interpreted fully and safely. "
>> 
>> 
>> So what do you suggest as a solution?
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

 Some theory along these lines 
 
is needed...



On 03/04/2018 08:35, A Verhees wrote:


GF :"There are NO agreed standardised archetypes/patterns we all use 
to define the meta-data in order to document the full eppistemology


so data can be interpreted fully and safely. "



So what do you suggest as a solution?


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

Re: [Troll] Terminology bindings ... again

[GF]

It is a generic problem that impacts OpenEHR also.

Present systems need a lot of implicit human knowledge in order to interpret 
the data safely and fully.
SNOMED pre-corodination is one way to make this implicit knowledge explicit. It 
possibly is a solution.
My point is that it is not the best solution.
Not only do we need to make more of the implicit knowledge explicit but use 
archetype structures/patterns to define the full context/epistemology in a 
Standardised, shared way.

Existing systems use a myriad number of ways to store health and administrative 
data.
This demands specific requirements to be met.
Systems of the future have other additional requirements that impact archetype 
patterns and the standard way of using coding systems.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 10:06, Pablo Pazos  wrote:
> 
> Check the initial messages on the thread.
> 
> Basically how to use SNOMED in openEHR, and in a specific area: data 
> querying. AQL support for SNOMED codes and expressions was an initial part of 
> the topic.
> 
> We are trying to solve a basic problem: how to get data out the systems in a 
> smart way. This is because archetypes are good but don't have context that 
> terminologies have, and AQL is good but only queries what is defined by 
> models. So we need something to query over terminologies in combination with 
> querying over models. Reasoning, interpretation and modeling approaches are 
> other orthogonal problems.
> 
> This is a very specific problem for the openEHR specs and ITS, is not a 
> general problem to solve.



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Check the initial messages on the thread.

Basically how to use SNOMED in openEHR, and in a specific area: data
querying. AQL support for SNOMED codes and expressions was an initial part
of the topic.

We are trying to solve a basic problem: how to get data out the systems in
a smart way. This is because archetypes are good but don't have context
that terminologies have, and AQL is good but only queries what is defined
by models. So we need something to query over terminologies in combination
with querying over models. Reasoning, interpretation and modeling
approaches are other orthogonal problems.

This is a very specific problem for the openEHR specs and ITS, is not a
general problem to solve.

On Tue, Apr 3, 2018 at 4:31 AM, A Verhees  wrote:

> Can we specific define in about ten words which problem is talked about in
> this discussion?
>
> Maybe we can then use that definition as a guideline to keep the
> discussion focussed.
>
> Best regards
> Bert Verhees
>
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos :
>
>> Please see below,
>>
>> On Mon, Apr 2, 2018 at 6:17 PM, GF  wrote:
>>
>>> Is that so?
>>>
>>> There will be systems that allow pre-coordinated codes. There will be
>>> systems that use as many pre-coordinated codes. And several in between
>>> solutions.
>>>
>>
>> I agree, there will be systems that allow and use pre and post
>> coordinated codes, that is a fairly normal requirement in clinical
>> information systems and openEHR specs supports that.
>>
>>
>>> This means that reasoners will be used to create transformations.
>>>
>>
>> It doesn't mean that, I don't see where that is implied.
>>
>> Some systems might use reasoners using ontologies, rules, codes and other
>> content, to infer some "facts", and the results should be interpreted in
>> the same context as the ontologies, rules, clinical records and codes are
>> created, managed and used. Inferred facts are context dependent.
>>
>> Some other systems might not use any reasoners or ontologies at all, and
>> define programmatic rules that use SNOMED codes and expressions (pre and
>> post coordinated), and other contextual clinical / demographic /
>> administrative information to evaluate those rules and get some result (an
>> alert, a recommendation, a reminder, etc.)
>>
>> And other systems might not have rules at all and just use codes,
>> expressions and contextual data to create some visual representation of the
>> patient's status, to be presented to a clinician and make him/her evaluate
>> the data and make a decision. This is the most basic area we should cover,
>> and what originally generated this discussion: how to use SNOMED in openEHR
>> queries.
>>
>> Use cases are many, we can't focus on just one area and generalize from
>> there.
>>
>>
>>> It is likely that ontological servoces will be used, And then we will
>>> have a potential problem.
>>>
>>
>> That will really depend on specific implementations. I don't think
>> proposing a combination of standards with a lot of potential will cause any
>> issues per se.
>>
>>
>>
>>> But perhaps solvable with the correct precautions.
>>> One being that ontological servoces are NOT used and that ad hoc rules
>>> do the transform.
>>>
>>
>> That is exactly my point from above, automatic conclusions from a
>> reasoner or any AI can be interpreted as a general truth on any context.
>> Those conclusions should be interpreted in the same context as data and
>> knowledge was created. And semantics should be given by humans on a
>> per-context basis.
>>
>>
>>
>>> What possible solution is the canonical one? which is the ‘golden truth’.
>>>
>>
>> Since all that ^ is context-dependent, I don't think there is any
>> canonical form or golden truth.
>>
>>
>>>
>>> When we add to all this that only part of the epistemology can be
>>> pre-coordinated it means that part of the temporal aspects for instance can
>>> NOT be dealt with in SNOMED, then we have the situation that part of the
>>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>>
>>
>> I agree and that is a good example of what I call "context" (how and
>> where knowledge and information is defined, managed and used, very related
>> to epistemology :)
>>
>>
>>>
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>>>
>>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>>> there is no terminology world separated from the content modeling and data
>>> recording world. We will use SNOMED inside the openEHR context, so the
>>> SNOMED meaning will be constrained by the openEHR meaning when recording
>>> clinical information. We should be constraint to that context.
>>>
>>> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>>>
 Pablo,

 It is as Thomas 

Re: [Troll] Terminology bindings ... again

[A Verhees]

That is the problem. There is no focus. This discussion will not solve
anything.



Op di 3 apr. 2018 09:48 schreef GF :

> It is Obvious:
>
> - We need to take the next step in Semantic Interoperability: Semantic
> interpretability.
> - And think about what is missing, so far
> - How to use codes from Terminologies and Classifications
> - How to deal with the full Context/Epistemology
> - How to deal with modifiers for presence/absence, certainty and other
> state info
> - What other models we need to deal with clinical, administration, and
> collaboration, processes
>
> In order to have systems that allow the full, safe, interpretation by
> humans, services, reasoners now and in the future.
> Systems with the minimal amount of implicit information needed to
> interpret safely and fully.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 3 Apr 2018, at 09:35, A Verhees  wrote:
>
>
> GF :"There are NO agreed standardised archetypes/patterns we all use to
> define the meta-data in order to document the full eppistemology
>
>> so data can be interpreted fully and safely. "
>>
>
>
> So what do you suggest as a solution?
>
>
>
>
>>
>>
>>
>>
>>>
>>> Gerard   Freriks
>>> +31 620347088
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[GF]

It is Obvious:

- We need to take the next step in Semantic Interoperability: Semantic 
interpretability.
- And think about what is missing, so far
- How to use codes from Terminologies and Classifications
- How to deal with the full Context/Epistemology
- How to deal with modifiers for presence/absence, certainty and other state 
info
- What other models we need to deal with clinical, administration, and 
collaboration, processes

In order to have systems that allow the full, safe, interpretation by humans, 
services, reasoners now and in the future.
Systems with the minimal amount of implicit information needed to interpret 
safely and fully.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 09:35, A Verhees  wrote:
> 
> 
> GF :"There are NO agreed standardised archetypes/patterns we all use to 
> define the meta-data in order to document the full eppistemology
> so data can be interpreted fully and safely. "
> 
> 
> So what do you suggest as a solution?
> 
> 
> 
> 
> 
> 
>> 
>> 
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl 
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>  
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[A Verhees]

Op di 3 apr. 2018 09:43 schreef GF :

> Archetype modelling and the use of SNOMED pre- and/or post-coordination
>

You too have a nice day

>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 3 Apr 2018, at 09:31, A Verhees  wrote:
>
> Can we specific define in about ten words which problem is talked about in
> this discussion?
>
> Maybe we can then use that definition as a guideline to keep the
> discussion focussed.
>
> Best regards
> Bert Verhees
>
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos :
>
>> Please see below,
>>
>> On Mon, Apr 2, 2018 at 6:17 PM, GF  wrote:
>>
>>> Is that so?
>>>
>>> There will be systems that allow pre-coordinated codes. There will be
>>> systems that use as many pre-coordinated codes. And several in between
>>> solutions.
>>>
>>
>> I agree, there will be systems that allow and use pre and post
>> coordinated codes, that is a fairly normal requirement in clinical
>> information systems and openEHR specs supports that.
>>
>>
>>> This means that reasoners will be used to create transformations.
>>>
>>
>> It doesn't mean that, I don't see where that is implied.
>>
>> Some systems might use reasoners using ontologies, rules, codes and other
>> content, to infer some "facts", and the results should be interpreted in
>> the same context as the ontologies, rules, clinical records and codes are
>> created, managed and used. Inferred facts are context dependent.
>>
>> Some other systems might not use any reasoners or ontologies at all, and
>> define programmatic rules that use SNOMED codes and expressions (pre and
>> post coordinated), and other contextual clinical / demographic /
>> administrative information to evaluate those rules and get some result (an
>> alert, a recommendation, a reminder, etc.)
>>
>> And other systems might not have rules at all and just use codes,
>> expressions and contextual data to create some visual representation of the
>> patient's status, to be presented to a clinician and make him/her evaluate
>> the data and make a decision. This is the most basic area we should cover,
>> and what originally generated this discussion: how to use SNOMED in openEHR
>> queries.
>>
>> Use cases are many, we can't focus on just one area and generalize from
>> there.
>>
>>
>>> It is likely that ontological servoces will be used, And then we will
>>> have a potential problem.
>>>
>>
>> That will really depend on specific implementations. I don't think
>> proposing a combination of standards with a lot of potential will cause any
>> issues per se.
>>
>>
>>
>>> But perhaps solvable with the correct precautions.
>>> One being that ontological servoces are NOT used and that ad hoc rules
>>> do the transform.
>>>
>>
>> That is exactly my point from above, automatic conclusions from a
>> reasoner or any AI can be interpreted as a general truth on any context.
>> Those conclusions should be interpreted in the same context as data and
>> knowledge was created. And semantics should be given by humans on a
>> per-context basis.
>>
>>
>>
>>> What possible solution is the canonical one? which is the ‘golden truth’.
>>>
>>
>> Since all that ^ is context-dependent, I don't think there is any
>> canonical form or golden truth.
>>
>>
>>>
>>> When we add to all this that only part of the epistemology can be
>>> pre-coordinated it means that part of the temporal aspects for instance can
>>> NOT be dealt with in SNOMED, then we have the situation that part of the
>>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>>
>>
>> I agree and that is a good example of what I call "context" (how and
>> where knowledge and information is defined, managed and used, very related
>> to epistemology :)
>>
>>
>>>
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>>>
>>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>>> there is no terminology world separated from the content modeling and data
>>> recording world. We will use SNOMED inside the openEHR context, so the
>>> SNOMED meaning will be constrained by the openEHR meaning when recording
>>> clinical information. We should be constraint to that context.
>>>
>>> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>>>
 Pablo,

 It is as Thomas and I wrote.

 *Open world Assumption:* Ontologies declare absolute truths
 irrespective of geographical location and point in time.

 *Closed World Assumption*: Archetypes help express what an author
 wants to document. These are very subjective truths at a point in time.

 This subtle but important distinction is only one of the reasons to
 refrain from the use of pre-coorodinated SNOMED terms. Things 

Re: [Troll] Terminology bindings ... again

[GF]

Archetype modelling and the use of SNOMED pre- and/or post-coordination

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 09:31, A Verhees  wrote:
> 
> Can we specific define in about ten words which problem is talked about in 
> this discussion?
> 
> Maybe we can then use that definition as a guideline to keep the discussion 
> focussed.
> 
> Best regards
> Bert Verhees
> 
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos  >:
> Please see below,
> 
> On Mon, Apr 2, 2018 at 6:17 PM, GF > 
> wrote:
> Is that so?
> 
> There will be systems that allow pre-coordinated codes. There will be systems 
> that use as many pre-coordinated codes. And several in between solutions.
> 
> I agree, there will be systems that allow and use pre and post coordinated 
> codes, that is a fairly normal requirement in clinical information systems 
> and openEHR specs supports that.
> 
> This means that reasoners will be used to create transformations.
> 
> It doesn't mean that, I don't see where that is implied.
> 
> Some systems might use reasoners using ontologies, rules, codes and other 
> content, to infer some "facts", and the results should be interpreted in the 
> same context as the ontologies, rules, clinical records and codes are 
> created, managed and used. Inferred facts are context dependent.
> 
> Some other systems might not use any reasoners or ontologies at all, and 
> define programmatic rules that use SNOMED codes and expressions (pre and post 
> coordinated), and other contextual clinical / demographic / administrative 
> information to evaluate those rules and get some result (an alert, a 
> recommendation, a reminder, etc.)
> 
> And other systems might not have rules at all and just use codes, expressions 
> and contextual data to create some visual representation of the patient's 
> status, to be presented to a clinician and make him/her evaluate the data and 
> make a decision. This is the most basic area we should cover, and what 
> originally generated this discussion: how to use SNOMED in openEHR queries.
> 
> Use cases are many, we can't focus on just one area and generalize from there.
> 
> It is likely that ontological servoces will be used, And then we will have a 
> potential problem.
> 
> That will really depend on specific implementations. I don't think proposing 
> a combination of standards with a lot of potential will cause any issues per 
> se.
> 
> 
> But perhaps solvable with the correct precautions.
> One being that ontological servoces are NOT used and that ad hoc rules do the 
> transform.
> 
> That is exactly my point from above, automatic conclusions from a reasoner or 
> any AI can be interpreted as a general truth on any context. Those 
> conclusions should be interpreted in the same context as data and knowledge 
> was created. And semantics should be given by humans on a per-context basis.
> 
> 
> What possible solution is the canonical one? which is the ‘golden truth’.
> 
> Since all that ^ is context-dependent, I don't think there is any canonical 
> form or golden truth.
> 
> 
> When we add to all this that only part of the epistemology can be 
> pre-coordinated it means that part of the temporal aspects for instance can 
> NOT be dealt with in SNOMED, then we have the situation that part of the 
> epistemology is in SNOMED and part defined in the Archetype/Template.
> 
> I agree and that is a good example of what I call "context" (how and where 
> knowledge and information is defined, managed and used, very related to 
> epistemology :)
> 
> 
> 
> Gerard   Freriks
> +31 620347088 
>   gf...@luna.nl 
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 2 Apr 2018, at 20:02, Pablo Pazos > > wrote:
>> 
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so there 
>> is no terminology world separated from the content modeling and data 
>> recording world. We will use SNOMED inside the openEHR context, so the 
>> SNOMED meaning will be constrained by the openEHR meaning when recording 
>> clinical information. We should be constraint to that context.
>> 
>> On Mon, Apr 2, 2018 at 6:01 AM, GF > 
>> wrote:
>> Pablo,
>> 
>> It is as Thomas and I wrote.
>> 
>> Open world Assumption: Ontologies declare absolute truths irrespective of 
>> geographical location and point in time.
>> 
>> Closed World Assumption: Archetypes help express what an author wants to 
>> document. These are very subjective truths at a point in time.
>> 
>> This subtle but important distinction is only one of the reasons to refrain 
>> from the use of pre-coorodinated SNOMED terms. Things like these matter when 
>> we start to reason about the documented patient 

Re: [Troll] Terminology bindings ... again

[A Verhees]

GF :"There are NO agreed standardised archetypes/patterns we all use to
define the meta-data in order to document the full eppistemology

> so data can be interpreted fully and safely. "
>


So what do you suggest as a solution?




>
>
>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[GF]

I agree
> The message is simple:  don't allow items with complex meanings in leafnodes, 
> but use archetypes to represent complexity.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Apr 2018, at 00:04, A Verhees  wrote:
> 
> In addition to this, OpenEhr tends to the use of simple precoordinated 
> concepts, that is because the archetypes explain the details.
> 
> It is, for example, rare in OpenEhr to use the concept for "bloodpressure 
> sitting". Normally one would create two leafnodes, one with the concept for 
> "bloodpressure", the other for "sitting". This level of expressing detail in 
> archetypes is historically grown in the years from before SNOMED, and it 
> seems like a blessing now, because it makes the discussion about concepts 
> with complex meaning a bit superfluous.
> 
> Avoid complex meanings in leaf nodes and express complexity in archetype 
> structure, and the number of different concepts to be used will be reduced 
> and the chance of availability of needed concepts rises.
> 
> The message is simple:  don't allow items with complex meanings in leafnodes, 
> but use archetypes to represent complexity.
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[A Verhees]

Can we specific define in about ten words which problem is talked about in
this discussion?

Maybe we can then use that definition as a guideline to keep the discussion
focussed.

Best regards
Bert Verhees

Op di 3 apr. 2018 01:19 schreef Pablo Pazos :

> Please see below,
>
> On Mon, Apr 2, 2018 at 6:17 PM, GF  wrote:
>
>> Is that so?
>>
>> There will be systems that allow pre-coordinated codes. There will be
>> systems that use as many pre-coordinated codes. And several in between
>> solutions.
>>
>
> I agree, there will be systems that allow and use pre and post coordinated
> codes, that is a fairly normal requirement in clinical information systems
> and openEHR specs supports that.
>
>
>> This means that reasoners will be used to create transformations.
>>
>
> It doesn't mean that, I don't see where that is implied.
>
> Some systems might use reasoners using ontologies, rules, codes and other
> content, to infer some "facts", and the results should be interpreted in
> the same context as the ontologies, rules, clinical records and codes are
> created, managed and used. Inferred facts are context dependent.
>
> Some other systems might not use any reasoners or ontologies at all, and
> define programmatic rules that use SNOMED codes and expressions (pre and
> post coordinated), and other contextual clinical / demographic /
> administrative information to evaluate those rules and get some result (an
> alert, a recommendation, a reminder, etc.)
>
> And other systems might not have rules at all and just use codes,
> expressions and contextual data to create some visual representation of the
> patient's status, to be presented to a clinician and make him/her evaluate
> the data and make a decision. This is the most basic area we should cover,
> and what originally generated this discussion: how to use SNOMED in openEHR
> queries.
>
> Use cases are many, we can't focus on just one area and generalize from
> there.
>
>
>> It is likely that ontological servoces will be used, And then we will
>> have a potential problem.
>>
>
> That will really depend on specific implementations. I don't think
> proposing a combination of standards with a lot of potential will cause any
> issues per se.
>
>
>
>> But perhaps solvable with the correct precautions.
>> One being that ontological servoces are NOT used and that ad hoc rules do
>> the transform.
>>
>
> That is exactly my point from above, automatic conclusions from a reasoner
> or any AI can be interpreted as a general truth on any context. Those
> conclusions should be interpreted in the same context as data and knowledge
> was created. And semantics should be given by humans on a per-context basis.
>
>
>
>> What possible solution is the canonical one? which is the ‘golden truth’.
>>
>
> Since all that ^ is context-dependent, I don't think there is any
> canonical form or golden truth.
>
>
>>
>> When we add to all this that only part of the epistemology can be
>> pre-coordinated it means that part of the temporal aspects for instance can
>> NOT be dealt with in SNOMED, then we have the situation that part of the
>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>
>
> I agree and that is a good example of what I call "context" (how and where
> knowledge and information is defined, managed and used, very related to
> epistemology :)
>
>
>>
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>>
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>> there is no terminology world separated from the content modeling and data
>> recording world. We will use SNOMED inside the openEHR context, so the
>> SNOMED meaning will be constrained by the openEHR meaning when recording
>> clinical information. We should be constraint to that context.
>>
>> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>>
>>> Pablo,
>>>
>>> It is as Thomas and I wrote.
>>>
>>> *Open world Assumption:* Ontologies declare absolute truths
>>> irrespective of geographical location and point in time.
>>>
>>> *Closed World Assumption*: Archetypes help express what an author wants
>>> to document. These are very subjective truths at a point in time.
>>>
>>> This subtle but important distinction is only one of the reasons to
>>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>>> matter when we start to reason about the documented patient data.
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
>>>
>>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>>> make sense. No system can record what can or can't happen in the future,
>>> and 

Re: [Troll] Terminology bindings ... again

[GF]

see below

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 23:35, A Verhees  wrote:
> 
> GF: "When we add to all this that only part of the epistemology can be 
> pre-coordinated it means that part of the temporal aspects for instance can 
> NOT be dealt with in SNOMED, then we have the situation that part of the 
> epistemology is in SNOMED and part defined in the Archetype/Template."
> ---
> Using SNOMED does not block using other terminologies or even local 
> terminologies.

13606 and OpenEHR do not block anything.
There are too many degrees of freedom.
All creating problems interpreting the data fully and safely.




> 
> In OpenEhr is always a part of the epistemology in the context of the 
> archetype, that is its power. Terminologies serve to undoubtable define the 
> presented data-item or act as a data-item. This is also the case in CEN13606

In most systems the full epistemology is not recorded.
It is there because of implicit or explicit agreements between users.
There are NO agreed standardised archetypes/patterns we all use to define the 
meta-data in order to document the full eppistemology
so data can be interpreted fully and safely.



> 
> 
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl 
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Please see below,

On Mon, Apr 2, 2018 at 6:17 PM, GF  wrote:

> Is that so?
>
> There will be systems that allow pre-coordinated codes. There will be
> systems that use as many pre-coordinated codes. And several in between
> solutions.
>

I agree, there will be systems that allow and use pre and post coordinated
codes, that is a fairly normal requirement in clinical information systems
and openEHR specs supports that.


> This means that reasoners will be used to create transformations.
>

It doesn't mean that, I don't see where that is implied.

Some systems might use reasoners using ontologies, rules, codes and other
content, to infer some "facts", and the results should be interpreted in
the same context as the ontologies, rules, clinical records and codes are
created, managed and used. Inferred facts are context dependent.

Some other systems might not use any reasoners or ontologies at all, and
define programmatic rules that use SNOMED codes and expressions (pre and
post coordinated), and other contextual clinical / demographic /
administrative information to evaluate those rules and get some result (an
alert, a recommendation, a reminder, etc.)

And other systems might not have rules at all and just use codes,
expressions and contextual data to create some visual representation of the
patient's status, to be presented to a clinician and make him/her evaluate
the data and make a decision. This is the most basic area we should cover,
and what originally generated this discussion: how to use SNOMED in openEHR
queries.

Use cases are many, we can't focus on just one area and generalize from
there.


> It is likely that ontological servoces will be used, And then we will have
> a potential problem.
>

That will really depend on specific implementations. I don't think
proposing a combination of standards with a lot of potential will cause any
issues per se.



> But perhaps solvable with the correct precautions.
> One being that ontological servoces are NOT used and that ad hoc rules do
> the transform.
>

That is exactly my point from above, automatic conclusions from a reasoner
or any AI can be interpreted as a general truth on any context. Those
conclusions should be interpreted in the same context as data and knowledge
was created. And semantics should be given by humans on a per-context basis.



> What possible solution is the canonical one? which is the ‘golden truth’.
>

Since all that ^ is context-dependent, I don't think there is any canonical
form or golden truth.


>
> When we add to all this that only part of the epistemology can be
> pre-coordinated it means that part of the temporal aspects for instance can
> NOT be dealt with in SNOMED, then we have the situation that part of the
> epistemology is in SNOMED and part defined in the Archetype/Template.
>

I agree and that is a good example of what I call "context" (how and where
knowledge and information is defined, managed and used, very related to
epistemology :)


>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>
> Yes, but the main topic here is the use of SNOMED inside openEHR, so there
> is no terminology world separated from the content modeling and data
> recording world. We will use SNOMED inside the openEHR context, so the
> SNOMED meaning will be constrained by the openEHR meaning when recording
> clinical information. We should be constraint to that context.
>
> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>
>> Pablo,
>>
>> It is as Thomas and I wrote.
>>
>> *Open world Assumption:* Ontologies declare absolute truths irrespective
>> of geographical location and point in time.
>>
>> *Closed World Assumption*: Archetypes help express what an author wants
>> to document. These are very subjective truths at a point in time.
>>
>> This subtle but important distinction is only one of the reasons to
>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>> matter when we start to reason about the documented patient data.
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
>>
>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>> make sense. No system can record what can or can't happen in the future,
>> and that concept is not part of any terminology AFAIK.
>>
>> On Sun, Apr 1, 2018 at 7:35 PM, GF  wrote:
>>
>>> Thomas,
>>>
>>> OpenEHR and 13606 deal with Closed World Assumption systems.
>>> And therefor both mean in the case of 'No Cancer' that Cancer was not
>>> found in the database or that No Cancer was the documented result of an
>>> evaluation.
>>> Both statements are documented things in a Template that according to
>>> the 

Re: [Troll] Terminology bindings ... again

[A Verhees]

In addition to this, OpenEhr tends to the use of simple precoordinated
concepts, that is because the archetypes explain the details.

It is, for example, rare in OpenEhr to use the concept for "bloodpressure
sitting". Normally one would create two leafnodes, one with the concept for
"bloodpressure", the other for "sitting". This level of expressing detail
in archetypes is historically grown in the years from before SNOMED, and it
seems like a blessing now, because it makes the discussion about concepts
with complex meaning a bit superfluous.

Avoid complex meanings in leaf nodes and express complexity in archetype
structure, and the number of different concepts to be used will be reduced
and the chance of availability of needed concepts rises.

The message is simple:  don't allow items with complex meanings in
leafnodes, but use archetypes to represent complexity.

Op ma 2 apr. 2018 23:35 schreef A Verhees :

> GF: "When we add to all this that only part of the epistemology can be
> pre-coordinated it means that part of the temporal aspects for instance can
> NOT be dealt with in SNOMED, then we have the situation that part of the
> epistemology is in SNOMED and part defined in the Archetype/Template."
> ---
> Using SNOMED does not block using other terminologies or even local
> terminologies.
>
> In OpenEhr is always a part of the epistemology in the context of the
> archetype, that is its power. Terminologies serve to undoubtable define the
> presented data-item or act as a data-item. This is also the case in CEN13606
>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>>
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>> there is no terminology world separated from the content modeling and data
>> recording world. We will use SNOMED inside the openEHR context, so the
>> SNOMED meaning will be constrained by the openEHR meaning when recording
>> clinical information. We should be constraint to that context.
>>
>> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>>
>>> Pablo,
>>>
>>> It is as Thomas and I wrote.
>>>
>>> *Open world Assumption:* Ontologies declare absolute truths
>>> irrespective of geographical location and point in time.
>>>
>>> *Closed World Assumption*: Archetypes help express what an author wants
>>> to document. These are very subjective truths at a point in time.
>>>
>>> This subtle but important distinction is only one of the reasons to
>>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>>> matter when we start to reason about the documented patient data.
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
>>>
>>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>>> make sense. No system can record what can or can't happen in the future,
>>> and that concept is not part of any terminology AFAIK.
>>>
>>> On Sun, Apr 1, 2018 at 7:35 PM, GF  wrote:
>>>
 Thomas,

 OpenEHR and 13606 deal with Closed World Assumption systems.
 And therefor both mean in the case of 'No Cancer' that Cancer was not
 found in the database or that No Cancer was the documented result of an
 evaluation.
 Both statements are documented things in a Template that according to
 the author cancer is not found.
 But any time in the future it might.

 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
 cancer was, is, or will be present.

 Gerard   Freriks
 +31 620347088 <+31%206%2020347088>
   gf...@luna.nl

 Kattensingel  20
 2801 CA Gouda
 the Netherlands

 On 1 Apr 2018, at 14:41, Thomas Beale  wrote:


 On 01/04/2018 13:16, GF wrote:

 Pre-coordinated SNOMED codes are like classifications, in that they are
 used at the user level, the User Interface,
 The Ontology behind SNOMED allows the pre-ordinated codes to be
 decomposed in its constituents.
 These decomposed primitive codes can be used in structures like
 archetypes at the proper places.
 In this way the pre-coorodinated SNOMED codes are iso-semantic.

 But we keep the semantic differences codes expressed  using the SNOMED
 ontology and the Archetype and its codes.
 Ontologies have the Open World Assumption. A pre-corodinated code like:
 No-Cancer means never there was, is or will be cancer. Ontologies describe
 reality.
 In archetypes that use the Closed World Assumption Diagnosis=cancer,
 PresenceModifier=No means No Cancer found but perhaps they are. It just was
 not found. Presence of absence in a database are 

Re: [Troll] Terminology bindings ... again

[A Verhees]

GF: "When we add to all this that only part of the epistemology can be
pre-coordinated it means that part of the temporal aspects for instance can
NOT be dealt with in SNOMED, then we have the situation that part of the
epistemology is in SNOMED and part defined in the Archetype/Template."
---
Using SNOMED does not block using other terminologies or even local
terminologies.

In OpenEhr is always a part of the epistemology in the context of the
archetype, that is its power. Terminologies serve to undoubtable define the
presented data-item or act as a data-item. This is also the case in CEN13606


>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>
> Yes, but the main topic here is the use of SNOMED inside openEHR, so there
> is no terminology world separated from the content modeling and data
> recording world. We will use SNOMED inside the openEHR context, so the
> SNOMED meaning will be constrained by the openEHR meaning when recording
> clinical information. We should be constraint to that context.
>
> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>
>> Pablo,
>>
>> It is as Thomas and I wrote.
>>
>> *Open world Assumption:* Ontologies declare absolute truths irrespective
>> of geographical location and point in time.
>>
>> *Closed World Assumption*: Archetypes help express what an author wants
>> to document. These are very subjective truths at a point in time.
>>
>> This subtle but important distinction is only one of the reasons to
>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>> matter when we start to reason about the documented patient data.
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
>>
>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>> make sense. No system can record what can or can't happen in the future,
>> and that concept is not part of any terminology AFAIK.
>>
>> On Sun, Apr 1, 2018 at 7:35 PM, GF  wrote:
>>
>>> Thomas,
>>>
>>> OpenEHR and 13606 deal with Closed World Assumption systems.
>>> And therefor both mean in the case of 'No Cancer' that Cancer was not
>>> found in the database or that No Cancer was the documented result of an
>>> evaluation.
>>> Both statements are documented things in a Template that according to
>>> the author cancer is not found.
>>> But any time in the future it might.
>>>
>>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
>>> cancer was, is, or will be present.
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 1 Apr 2018, at 14:41, Thomas Beale  wrote:
>>>
>>>
>>> On 01/04/2018 13:16, GF wrote:
>>>
>>> Pre-coordinated SNOMED codes are like classifications, in that they are
>>> used at the user level, the User Interface,
>>> The Ontology behind SNOMED allows the pre-ordinated codes to be
>>> decomposed in its constituents.
>>> These decomposed primitive codes can be used in structures like
>>> archetypes at the proper places.
>>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>>>
>>> But we keep the semantic differences codes expressed  using the SNOMED
>>> ontology and the Archetype and its codes.
>>> Ontologies have the Open World Assumption. A pre-corodinated code like:
>>> No-Cancer means never there was, is or will be cancer. Ontologies describe
>>> reality.
>>> In archetypes that use the Closed World Assumption Diagnosis=cancer,
>>> PresenceModifier=No means No Cancer found but perhaps they are. It just was
>>> not found. Presence of absence in a database are described.
>>>
>>>
>>> I'm unclear why you call this a use of the closed world assumption: the
>>> entire openEHR framework is for building HISs that enable reporting of
>>> reality as it is known to those working in it. So if they put 'No cancer'
>>> that just means that the current clinical thinking for some patient, *with
>>> respect to some investigation*, is that the original presenting problem
>>> is not cancer.
>>>
>>> That never means that the patient doesn't have cancer in their body
>>> somewhere, it just means that the currently investigated signs and symptoms
>>> don't relate to cancer, according to the the investigation carried out.
>>> Even that can be overturned later. But everyone assumes this - the EHR is
>>> always understood as an 'open world' system, where absence of X doesn't
>>> mean negation of X, it just means that no-one has investigated X.
>>>
>>> - thomas
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> 

Re: [Troll] Terminology bindings ... again

[GF]

Philippe.

1- documentation in health and care, as you wrote, can have two points of focus:
- focus: the healthcare provider: as author documenting in his EHR about the 
patient what this HcP has done
- focus the patient: as subject of care allowing other HcProviders as authors 
to document what has been done
The problem is to have these two focus points not only to co-exist, but be 
integrated.

My French is good enough to read 2 medical textbooks in French when I was 
training to become a GP.
If possible share that article with me, I’m curious.

2-In my view ContSYS is one of the ingredients needed to integrate these two 
focus points.
We need more than ContSys:
- a model for the epistemology
- archetypes designed using re-occuring standardised phrases
- terminology providing primitive terms
- a generic standardised solution for modifiers: (non-)presence, states, 
certainty
- standardised services/interfaces for database, user screen/keyboard, 
messages, clinical reasoner
- supporting terminology services (i.e converter into/from user friendly terms, 
…)
- all based on orthogonal shared standardised models.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 21:15, Philippe Ameline  wrote:
> 
> Le 02/04/2018 à 19:45, GF a écrit :
>> 1- What stands AP)SA(A'P’) for?
> 
> I guess that you know the SOAP as the 4 main "chapters" of a clinical 
> encounter (https://en.wikipedia.org/wiki/SOAP_note 
> ).
> From  Lawrence Weed's concepts, a patient encounter should be recorded as a 
> "grid" with problems as columns and SOAP elements as line.
> 
> This concept is theoretically sound for acute care since it starts with 
> patient's verbatim of the reasons for encounter (S standing for Subjective - 
> which is truly dated!).
> 
> In the current "state of the medical art", always more chronic care oriented, 
> a patient often comes with an ongoing list of problems and treatments, hence 
> (AP)SO... and leaves with the same or a different list of A and P, hence 
> (AP)SO(A'P').
> 
> 14 years ago, I worked with a knowledge management research team on 
> establishing both the theoretical aspect and the user interface of such 
> concept, by the name "virtual staff".
> To make it short, imagine the Ligne de vie, with the vertical "now" 
> separator... then spread this separator as a curtain in order to open the 
> patient encounter as a cognitive map located between the past (AP) and 
> the future (A'P').
> 
>> 
>> Here below some missing topics we need to have agreement about
>> 
>> 2- Thinking about the health and care provission documentation process there 
>> are:
>> - Observation process
>> - Evaluation process (including, and restricted to, diagnosis, diff 
>> diagnosis, problem kist, episode list, etc
>> - Planning process
>> - Ordering process
>> - Execution process of acts
> 
> I am currently writing a paper (in French) telling a story of "boxes" and 
> "bubbles". Boxes are care places (say organizations at large) with roles 
> within a domain. Bubbles are the patients (say persons at large) with a 
> "polar reference frame vision" about "who is around and among them, who is 
> close or not so close".
> 
> In the usual system, only boxes operate an information system... and they are 
> pretty bad when it comes to "continuity of X" (replace X with care, 
> education, employment, etc).
> 
> Now, let's suppose that the reference information system is in the bubble. 
> And that service providers are just considered as contributors that can join 
> the current team that surround the person.
> 
> In the ongoing paper, I am trying to describe what happens when "a bubble 
> steps through a box"... and it is an amazing model to make many things clear!
> 
>> 
>> 3- We need to recognise that some data is de novo, other data is repeated 
>> after a querry
>> 
>> 4- Systems need to be aware that some data is directly health care care 
>> related, other is administrativem process oriented
>> 
>> 5- When that what is documented is used in shared working processes we need 
>> a common vocabulary: i.e. System of Concepts for Continuity of Care
> 
> Thanks to François Mennerat, a glorious CISP Club founder, we have been aware 
> of Consys for many years... but "so many years" is also the problem!
> 
> Philippe
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 02/04/2018 à 19:45, GF a écrit :

> 1- What stands AP)SA(A'P’) for?

I guess that you know the SOAP as the 4 main "chapters" of a clinical
encounter (https://en.wikipedia.org/wiki/SOAP_note).
From  Lawrence Weed's concepts, a patient encounter should be recorded
as a "grid" with problems as columns and SOAP elements as line.

This concept is theoretically sound for acute care since it starts with
patient's verbatim of the reasons for encounter (S standing for
Subjective - which is truly dated!).

In the current "state of the medical art", always more chronic care
oriented, a patient often comes with an ongoing list of problems and
treatments, hence (AP)SO... and leaves with the same or a different list
of A and P, hence (AP)SO(A'P').

14 years ago, I worked with a knowledge management research team on
establishing both the theoretical aspect and the user interface of such
concept, by the name "virtual staff".
To make it short, imagine the Ligne de vie, with the vertical "now"
separator... then spread this separator as a curtain in order to open
the patient encounter as a cognitive map located between the past (AP)
and the future (A'P').

>
> Here below some missing topics we need to have agreement about
>
> 2- Thinking about the health and care provission documentation process
> there are:
> - Observation process
> - Evaluation process (including, and restricted to, diagnosis, diff
> diagnosis, problem kist, episode list, etc
> - Planning process
> - Ordering process
> - Execution process of acts

I am currently writing a paper (in French) telling a story of "boxes"
and "bubbles". Boxes are care places (say organizations at large) with
roles within a domain. Bubbles are the patients (say persons at large)
with a "polar reference frame vision" about "who is around and among
them, who is close or not so close".

In the usual system, only boxes operate an information system... and
they are pretty bad when it comes to "continuity of X" (replace X with
care, education, employment, etc).

Now, let's suppose that the reference information system is in the
bubble. And that service providers are just considered as contributors
that can join the current team that surround the person.

In the ongoing paper, I am trying to describe what happens when "a
bubble steps through a box"... and it is an amazing model to make many
things clear!

>
> 3- We need to recognise that some data is de novo, other data is
> repeated after a querry
>
> 4- Systems need to be aware that some data is directly health care
> care related, other is administrativem process oriented
>
> 5- When that what is documented is used in shared working processes we
> need a common vocabulary: i.e. System of Concepts for Continuity of Care

Thanks to François Mennerat, a glorious CISP Club founder, we have been
aware of Consys for many years... but "so many years" is also the problem!

Philippe


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

Re: [Troll] Terminology bindings ... again

[GF]

1- What stands AP)SA(A'P’) for?

Here below some missing topics we need to have agreement about

2- Thinking about the health and care provission documentation process there 
are:
- Observation process
- Evaluation process (including, and restricted to, diagnosis, diff diagnosis, 
problem kist, episode list, etc
- Planning process
- Ordering process
- Execution process of acts

3- We need to recognise that some data is de novo, other data is repeated after 
a querry

4- Systems need to be aware that some data is directly health care care 
related, other is administrativem process oriented

5- When that what is documented is used in shared working processes we need a 
common vocabulary: i.e. System of Concepts for Continuity of Care



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 14:06, Philippe Ameline  wrote:
> 
> Le 02/04/2018 à 12:54, A Verhees a écrit :
> 
>> > The "good all" SOAP is dead ; nowadays, the encounter stream is switching 
>> > to (AP)SO(A'P'):
>> > people now come with an existing set of Assessments and Procedures,
>> > not "just" with "Subjective" issues.
>> 
>> Wasn't that always the case?
> 
> We are currently switching from "mainly acute" to "mainly chronic" care. 
> Reason why I claim that the "encounter information stream" must switch from 
> SOAP to (AP)SA(A'P')
> 
> In my understanding, the concept of episodes of care came long after Weed 
> coined the SOAP approach; but I may be wrong.
> 
> However, the main concept here is to consider an encounter as part of a 
> global process and no longer as an isolated event. This is, unfortunately, 
> still a disruptive concept ;-)
> 
> Philippe



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[A Verhees]

Sorry, this was a reply to Philippe on his message on 14:07

Op ma 2 apr. 2018 15:16 schreef A Verhees :

> Mostly a patients history is regarded in a consultation. Mostly this is
> history from after the start of the electronical era and being treated in
> the Netherlands . At least it is common practice in the Netherlands for
> most patients.
>
> Op ma 2 apr. 2018 14:30 schreef Thomas Beale :
>
>>
>>
>> On 02/04/2018 10:59, Philippe Ameline wrote:
>>
>> Le 01/04/2018 à 14:13, Thomas Beale a écrit :
>>
>>
>> just by means of clarification for some readers, since I happen to know
>> how both openEHR and Philippe's system works, here's the way to understand
>> how openEHR would perform the same function as Ligne-de-vie (which it can):
>>
>>- build a lot of CLUSTER archetypes, and probably more OBSERVATION
>>ones; each CLUSTER archetype would be one of the 'trees' Philippe talks
>>about
>>- each of those CLUSTER archetypes has slot nodes that indicate where
>>subordinate CLUSTER archetypes join, and which ones are allowed, in the
>>usual openEHR fashion;
>>- remember, a slot can allow multiple possible substitutions
>>- at run time, a form containing a top level Entry, usually an
>>OBSERVATION will be deployed on the screen, and by a process of user 
>> choice
>>/ UI movements etc, the data will get filled in, and subordinate CLUSTER
>>archetypes will be chosen on the way, and filled in along the way.
>>
>> This mode of operation is known by us in openEHR-land as 'dynamic
>> slot-filling' or 'runtime templating', as opposed to the more typical
>> design-time templating used in a lot of systems, where most of the choices
>> are made prior to runtime. But openEHR systems do use runtime slot-filling
>> as well, e.g. for writing discharge summaries and referrals, where the data
>> items are only knowable in the encounter or report-writing session.
>>
>>
>> This trend allows me to discover that openEHR already became a rich
>> ecosystem. Isn't this technique close from Gerard's vision of archetypes as
>> "context for concepts" in a kind of ontology?
>>
>> However, I probably wrongly expressed what I wanted to say, and is more
>> theoretical than comparing implementations, such as openEHR and Ligne de
>> vie.
>>
>> When we talk to one another using a natural language, we just need a
>> vocabulary and a grammar. The grammar is simply a set of rules, but not a
>> physical pattern. We say "John sees the green house" and not "John as the
>> subject sees as the verb the green as an adjective house as a noon in a
>> position of direct object complement".
>>
>> In the same way, it is possible to express a structured discourse just
>> using an ontology and a grammatical structure (say trees) without the need
>> of any structure description.
>>
>>
>> you are I think using 'grammar' in an unusual way - normally it means the
>> set of production rules that define legal utterances in some language; this
>> is an intensional definition, i.e. it can be used computationally to parse
>> actual utterances (including garbage) and generate structures only for the
>> utterances obeying the rules of the grammar.
>>
>> In your usage, 'grammar' is what you call the trees, which are
>> extensional maps of legal utterances, or fragments of utterances, which can
>> only be connected together according to their rules, which ensure
>> correctness of larger utterances, e.g. a colonoscopy report.
>>
>> Structurally and computationally then, the fils guides (the trees in
>> Ligne de Vie) and archetypes are the same; they differ only in
>> representational details. However, there are two semantic differences.
>>
>> Firstly, the fils guides depend completely on the ontology (which is an
>> ontological terminology, to give it a more correct name, I think), and the
>> two things are built as a combined representational system. Whereas
>> elements in archetypes can have bindings made to ontologies and/or
>> terminologies, but don't rely on them, since they can rely on their
>> internal terminology to a reasonable extent (but not for value sets like
>> procedure or diagnoses etc). In theory, we should do what fils guides are
>> doing, and the reason we have not is only practical, not theoretical: the
>> development of bio-medical ontologies is still young, and was almost
>> non-existent 18 years ago when we started on this.
>>
>> The consequence has been that it is possible to construct archetypes that
>> say questionable or even wrong things with respect to ontologies of those
>> same things, say anatomical relationships. This rarely happens in reality
>> simply because archetypes are built by clinical professionals and reviewed
>> by many others, and mistakes tend to be avoided, or if made, caught in
>> review. But clearly it's not a completely reliable strategy, and future
>> versions of archetype tooling should force live checking against suitable
>> 

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

[Philippe Ameline]

Le 02/04/2018 à 12:54, A Verhees a écrit :

> > The "good all" SOAP is dead ; nowadays, the encounter stream is switching to
> (AP)SO(A'P'): 
> > people now come with an existing set of Assessments and Procedures, 
> > not "just" with "Subjective" issues.
>
> Wasn't that always the case?

We are currently switching from "mainly acute" to "mainly chronic" care.
Reason why I claim that the "encounter information stream" must switch
from SOAP to (AP)SA(A'P')

In my understanding, the concept of episodes of care came long after
Weed coined the SOAP approach; but I may be wrong.

However, the main concept here is to consider an encounter as part of a
global process and no longer as an isolated event. This is,
unfortunately, still a disruptive concept ;-)

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

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

[A Verhees]

> The "good all" SOAP is dead ; nowadays, the encounter stream is switching
to (AP)SO(A'P'):
> people now come with an existing set of Assessments and Procedures,
> not "just" with "Subjective" issues.

>
Wasn't that always the case?
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Philippe Ameline]

Le 01/04/2018 à 14:13, Thomas Beale a écrit :

> On 31/03/2018 10:38, Philippe Ameline wrote:
>> ...
>>
>> When I try to explain all this to lesser tech-savvy people (means,
>> who don't belong to this list ;-) ), I usually explain that:
>> - usual systems (with an information schema tied to a database
>> schema) are like a printed form. The day after you received the 5000
>> printed sheet you ordered, you will realize that there are several
>> design flaws that you will have to endure while the stock is not empty,
>> - openEHR is a flexible schema, similar to a set of stamps that lets
>> you build forms dynamically from blank paper. If your design has to
>> evolve, you just have to adapt one of the stamps.
>> - in my system, based on an ontology and a dependency grammar, you
>> can use stamps (archetypes like) and/or "write" freely.
>>
>
> just by means of clarification for some readers, since I happen to
> know how both openEHR and Philippe's system works, here's the way to
> understand how openEHR would perform the same function as Ligne-de-vie
> (which it can):
>
>   * build a lot of CLUSTER archetypes, and probably more OBSERVATION
> ones; each CLUSTER archetype would be one of the 'trees' Philippe
> talks about
>   * each of those CLUSTER archetypes has slot nodes that indicate
> where subordinate CLUSTER archetypes join, and which ones are
> allowed, in the usual openEHR fashion;
>   o remember, a slot can allow multiple possible substitutions
>   * at run time, a form containing a top level Entry, usually an
> OBSERVATION will be deployed on the screen, and by a process of
> user choice / UI movements etc, the data will get filled in, and
> subordinate CLUSTER archetypes will be chosen on the way, and
> filled in along the way.
>
> This mode of operation is known by us in openEHR-land as 'dynamic
> slot-filling' or 'runtime templating', as opposed to the more typical
> design-time templating used in a lot of systems, where most of the
> choices are made prior to runtime. But openEHR systems do use runtime
> slot-filling as well, e.g. for writing discharge summaries and
> referrals, where the data items are only knowable in the encounter or
> report-writing session.
>

This trend allows me to discover that openEHR already became a rich
ecosystem. Isn't this technique close from Gerard's vision of archetypes
as "context for concepts" in a kind of ontology?

However, I probably wrongly expressed what I wanted to say, and is more
theoretical than comparing implementations, such as openEHR and Ligne de
vie.

When we talk to one another using a natural language, we just need a
vocabulary and a grammar. The grammar is simply a set of rules, but not
a physical pattern. We say "John sees the green house" and not "John as
the subject sees as the verb the green as an adjective house as a noon
in a position of direct object complement".

In the same way, it is possible to express a structured discourse just
using an ontology and a grammatical structure (say trees) without the
need of any structure description.

So, to make my point more accurate, I see the evolution as:
- all possible discourse structures "hard coded" into a database schema:
legacy systems
- all possible discourse structures locally expressed as a set of
archetypes that are flexibly expandable: ENV-13606, openEHR
- discourse simply limited in complexity by what can be expressed using
the current state of ontology and the grammar

> I mostly agree here, with one major exception: entering a diagnosis.
> In that case, you do want subsets that are meaningful to your work
> context. If it is paediatric oncology, you may have a form with a
> field that can only be some kind of cancer or related Dx that that
> department deals with - then you want reference terminology terms in a
> subset that cuts out everything else. You also want your subset to be
> structured, i.e. with the IS-A links intact, so that you can navigate
> it to choose.

Agreed ; subset can be useful for user interface purposes. But it
remains a design purpose ; since, for example, the oncologist diagnose
becomes a health problem that all other patient's team members have to
cope with afterward.

The "good all" SOAP is dead ; nowadays, the encounter stream is
switching to (AP)SO(A'P'): people now come with an existing set of
Assessments and Procedures, not "just" with "Subjective" issues.

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

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

[Philippe Ameline]

Thomas,

If I had to sum up the debate, I would write something like:

- pre-coordination is necessary for legacy systems that stick to coding
systems and didn't make the move to more elaborated representation of
information,
- pre-coordination's drawback is that expressing sentences as concepts
will mechanically lead to an explosion of the list of concept unless the
scope/audience remains small enough so that it ends up reaching an
asymptote that can be dealt with,
- considering SNOMED's ambitions (worldwide, large scope), we can
reasonably doubt that such asymptote exists.

Philippe


Le 01/04/2018 à 14:33, Thomas Beale a écrit :
>
>
> One thing I have noticed in recent systems in Brazil I looked at is
> that the codes are locally defined (e.g. SIGTAP, a Brazilian
> vocabulary for procedures) and almost all pre-coordinations of the
> most unscientific kind (with terms of the form 'cholecystectomy
> performed at private or military clinic'). Initially, it looks like a
> lost cause, but in fact SIGTAP only has (from memory) < 5000 terms,
> and there are ways of dealing with it. The Read codes in the UK were
> more scientific, but still contained many weird pre-coordinations (the
> famous example being 'hit by falling space junk while riding a
> bicycle'), but was also only O(10k) in size.
>
> So the 'size of the problem' is often inversely proportional to its
> awfulness, when talking about legacy terminology use, and this is what
> makes it possible to do something about it.
>
> The fact is, many old systems just couldn't express that many things.
>
> - thomas
>
> On 31/03/2018 22:24, Diego Boscá wrote:
>> What I say is that legacy applications or current systems usually
>> offer limited options with the knowledge available when they were
>> created. These options were decided back in the day and usually fit
>> with precoordinated terms. And defining this subsets helps on going
>> forward 
>>
>> El sáb., 31 mar. 2018 22:14, Philippe Ameline
>> > escribió:
>>
>> Some people (count me in) strictly ban what you call
>> precoordination (that I call "aglutinating language") because
>> they believe that there is a nearly infinite set of them and such
>> a system is born to "explode" as the frog that wanted to mimic
>> the ox.
>>
>> To put it differently: you cannot express all possible discourses
>> as predetermined concepts.
>>
>> Do I interpret your answer correctly if I say that you have an
>> optimist vision in the form "there is a limited number of
>> clinically sound precoordinations so that SNOMED expansion will
>> reach an asymptote that keep being manageable"?
>>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: [Troll] Terminology bindings ... again

[GF]

Pablo,

It is as Thomas and I wrote.

Open world Assumption: Ontologies declare absolute truths irrespective of 
geographical location and point in time.

Closed World Assumption: Archetypes help express what an author wants to 
document. These are very subjective truths at a point in time.

This subtle but important distinction is only one of the reasons to refrain 
from the use of pre-coorodinated SNOMED terms. Things like these matter when we 
start to reason about the documented patient data.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
> 
> I'm sorry but "...no cancer was, is, or will be present." doesn't even make 
> sense. No system can record what can or can't happen in the future, and that 
> concept is not part of any terminology AFAIK.
> 
> On Sun, Apr 1, 2018 at 7:35 PM, GF > 
> wrote:
> Thomas,
> 
> OpenEHR and 13606 deal with Closed World Assumption systems.
> And therefor both mean in the case of 'No Cancer' that Cancer was not found 
> in the database or that No Cancer was the documented result of an evaluation.
> Both statements are documented things in a Template that according to the 
> author cancer is not found.
> But any time in the future it might.
> 
> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no 
> cancer was, is, or will be present.
> 
> Gerard   Freriks
> +31 620347088 
>   gf...@luna.nl 
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 1 Apr 2018, at 14:41, Thomas Beale > > wrote:
>> 
>> 
>> On 01/04/2018 13:16, GF wrote:
>>> Pre-coordinated SNOMED codes are like classifications, in that they are 
>>> used at the user level, the User Interface,
>>> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed 
>>> in its constituents.
>>> These decomposed primitive codes can be used in structures like archetypes 
>>> at the proper places.
>>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>>> 
>>> But we keep the semantic differences codes expressed  using the SNOMED 
>>> ontology and the Archetype and its codes.
>>> Ontologies have the Open World Assumption. A pre-corodinated code like: 
>>> No-Cancer means never there was, is or will be cancer. Ontologies describe 
>>> reality.
>>> In archetypes that use the Closed World Assumption Diagnosis=cancer, 
>>> PresenceModifier=No means No Cancer found but perhaps they are. It just was 
>>> not found. Presence of absence in a database are described.
>> 
>> I'm unclear why you call this a use of the closed world assumption: the 
>> entire openEHR framework is for building HISs that enable reporting of 
>> reality as it is known to those working in it. So if they put 'No cancer' 
>> that just means that the current clinical thinking for some patient, with 
>> respect to some investigation, is that the original presenting problem is 
>> not cancer.
>> 
>> That never means that the patient doesn't have cancer in their body 
>> somewhere, it just means that the currently investigated signs and symptoms 
>> don't relate to cancer, according to the the investigation carried out. Even 
>> that can be overturned later. But everyone assumes this - the EHR is always 
>> understood as an 'open world' system, where absence of X doesn't mean 
>> negation of X, it just means that no-one has investigated X.
>> 
>> - thomas
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> 
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> 
> 
> 
> 
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com 
> +598 99 043 145
> skype: cabolabs
>  
> http://www.cabolabs.com 
> https://cloudehrserver.com 
> Subscribe to our newsletter 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

Re: [Troll] Terminology bindings ... again

[GF]

I think, we happen to be in full agreement.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 01:06, Thomas Beale  wrote:
> 
> 
> In a so-called closed-world system, everything that is stated constitutes the 
> totality of the truths about the world it relates to. In particular, absence 
> of an assertion (such as 'patient X has cancer') means negation, i.e. that 
> patient X doesn't have cancer. But openEHR and 13606 don't work like that; 
> absence of some particular statement about X just means nothing has been said 
> about the relevant issue so far.
> 
> - thomas
> 
> On 01/04/2018 23:35, GF wrote:
>> Thomas,
>> 
>> OpenEHR and 13606 deal with Closed World Assumption systems.
>> And therefor both mean in the case of 'No Cancer' that Cancer was not found 
>> in the database or that No Cancer was the documented result of an evaluation.
>> Both statements are documented things in a Template that according to the 
>> author cancer is not found.
>> But any time in the future it might.
>> 
>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no 
>> cancer was, is, or will be present.
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

I'm sorry but "...no cancer was, is, or will be present." doesn't even make
sense. No system can record what can or can't happen in the future, and
that concept is not part of any terminology AFAIK.

On Sun, Apr 1, 2018 at 7:35 PM, GF  wrote:

> Thomas,
>
> OpenEHR and 13606 deal with Closed World Assumption systems.
> And therefor both mean in the case of 'No Cancer' that Cancer was not
> found in the database or that No Cancer was the documented result of an
> evaluation.
> Both statements are documented things in a Template that according to the
> author cancer is not found.
> But any time in the future it might.
>
> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
> cancer was, is, or will be present.
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 1 Apr 2018, at 14:41, Thomas Beale  wrote:
>
>
> On 01/04/2018 13:16, GF wrote:
>
> Pre-coordinated SNOMED codes are like classifications, in that they are
> used at the user level, the User Interface,
> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed
> in its constituents.
> These decomposed primitive codes can be used in structures like archetypes
> at the proper places.
> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>
> But we keep the semantic differences codes expressed  using the SNOMED
> ontology and the Archetype and its codes.
> Ontologies have the Open World Assumption. A pre-corodinated code like:
> No-Cancer means never there was, is or will be cancer. Ontologies describe
> reality.
> In archetypes that use the Closed World Assumption Diagnosis=cancer,
> PresenceModifier=No means No Cancer found but perhaps they are. It just was
> not found. Presence of absence in a database are described.
>
>
> I'm unclear why you call this a use of the closed world assumption: the
> entire openEHR framework is for building HISs that enable reporting of
> reality as it is known to those working in it. So if they put 'No cancer'
> that just means that the current clinical thinking for some patient, *with
> respect to some investigation*, is that the original presenting problem
> is not cancer.
>
> That never means that the patient doesn't have cancer in their body
> somewhere, it just means that the currently investigated signs and symptoms
> don't relate to cancer, according to the the investigation carried out.
> Even that can be overturned later. But everyone assumes this - the EHR is
> always understood as an 'open world' system, where absence of X doesn't
> mean negation of X, it just means that no-one has investigated X.
>
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

In a so-called closed-world system, everything that is stated 
constitutes the totality of the truths about the world it relates to. In 
particular, /absence/ of an assertion (such as 'patient X has cancer') 
means negation, i.e. that patient X doesn't have cancer. But openEHR and 
13606 don't work like that; absence of some particular statement about X 
just means nothing has been said about the relevant issue so far.


- thomas


On 01/04/2018 23:35, GF wrote:

Thomas,

OpenEHR and 13606 deal with Closed World Assumption systems.
And therefor both mean in the case of 'No Cancer' that Cancer was not 
found in the database or that No Cancer was the documented result of 
an evaluation.
Both statements are documented things in a Template that according to 
the author cancer is not found.

But any time in the future it might.

'No Cancer' as pre-coordinated term in the case of SNOMED means that 
no cancer was, is, or will be present.



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

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

OpenEHR and 13606 deal with Closed World Assumption systems.
And therefor both mean in the case of 'No Cancer' that Cancer was not found in 
the database or that No Cancer was the documented result of an evaluation.
Both statements are documented things in a Template that according to the 
author cancer is not found.
But any time in the future it might.

'No Cancer' as pre-coordinated term in the case of SNOMED means that no cancer 
was, is, or will be present.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Apr 2018, at 14:41, Thomas Beale  wrote:
> 
> 
> On 01/04/2018 13:16, GF wrote:
>> Pre-coordinated SNOMED codes are like classifications, in that they are used 
>> at the user level, the User Interface,
>> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed 
>> in its constituents.
>> These decomposed primitive codes can be used in structures like archetypes 
>> at the proper places.
>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>> 
>> But we keep the semantic differences codes expressed  using the SNOMED 
>> ontology and the Archetype and its codes.
>> Ontologies have the Open World Assumption. A pre-corodinated code like: 
>> No-Cancer means never there was, is or will be cancer. Ontologies describe 
>> reality.
>> In archetypes that use the Closed World Assumption Diagnosis=cancer, 
>> PresenceModifier=No means No Cancer found but perhaps they are. It just was 
>> not found. Presence of absence in a database are described.
> 
> I'm unclear why you call this a use of the closed world assumption: the 
> entire openEHR framework is for building HISs that enable reporting of 
> reality as it is known to those working in it. So if they put 'No cancer' 
> that just means that the current clinical thinking for some patient, with 
> respect to some investigation, is that the original presenting problem is not 
> cancer.
> 
> That never means that the patient doesn't have cancer in their body 
> somewhere, it just means that the currently investigated signs and symptoms 
> don't relate to cancer, according to the the investigation carried out. Even 
> that can be overturned later. But everyone assumes this - the EHR is always 
> understood as an 'open world' system, where absence of X doesn't mean 
> negation of X, it just means that no-one has investigated X.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

On 01/04/2018 13:16, GF wrote:
Pre-coordinated SNOMED codes are like classifications, in that they 
are used at the user level, the User Interface,
The Ontology behind SNOMED allows the pre-ordinated codes to be 
decomposed in its constituents.
These decomposed primitive codes can be used in structures like 
archetypes at the proper places.

In this way the pre-coorodinated SNOMED codes are iso-semantic.

But we keep the semantic differences codes expressed  using the SNOMED 
ontology and the Archetype and its codes.
Ontologies have the Open World Assumption. A pre-corodinated code 
like: No-Cancer means never there was, is or will be cancer. 
Ontologies describe reality.
In archetypes that use the Closed World Assumption Diagnosis=cancer, 
PresenceModifier=No means No Cancer found but perhaps they are. It 
just was not found. Presence of absence in a database are described.


I'm unclear why you call this a use of the closed world assumption: the 
entire openEHR framework is for building HISs that enable reporting of 
reality as it is known to those working in it. So if they put 'No 
cancer' that just means that the current clinical thinking for some 
patient, /with respect to some investigation/, is that the original 
presenting problem is not cancer.


That never means that the patient doesn't have cancer in their body 
somewhere, it just means that the currently investigated signs and 
symptoms don't relate to cancer, according to the the investigation 
carried out. Even that can be overturned later. But everyone assumes 
this - the EHR is always understood as an 'open world' system, where 
absence of X doesn't mean negation of X, it just means that no-one has 
investigated X.


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

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

[Thomas Beale]

One thing I have noticed in recent systems in Brazil I looked at is that 
the codes are locally defined (e.g. SIGTAP, a Brazilian vocabulary for 
procedures) and almost all pre-coordinations of the most unscientific 
kind (with terms of the form 'cholecystectomy performed at private or 
military clinic'). Initially, it looks like a lost cause, but in fact 
SIGTAP only has (from memory) < 5000 terms, and there are ways of 
dealing with it. The Read codes in the UK were more scientific, but 
still contained many weird pre-coordinations (the famous example being 
'hit by falling space junk while riding a bicycle'), but was also only 
O(10k) in size.


So the 'size of the problem' is often inversely proportional to its 
awfulness, when talking about legacy terminology use, and this is what 
makes it possible to do something about it.


The fact is, many old systems just couldn't express that many things.

- thomas

On 31/03/2018 22:24, Diego Boscá wrote:
What I say is that legacy applications or current systems usually 
offer limited options with the knowledge available when they were 
created. These options were decided back in the day and usually fit 
with precoordinated terms. And defining this subsets helps on going 
forward


El sáb., 31 mar. 2018 22:14, Philippe Ameline 
> escribió:


Some people (count me in) strictly ban what you call
precoordination (that I call "aglutinating language") because they
believe that there is a nearly infinite set of them and such a
system is born to "explode" as the frog that wanted to mimic the ox.

To put it differently: you cannot express all possible discourses
as predetermined concepts.

Do I interpret your answer correctly if I say that you have an
optimist vision in the form "there is a limited number of
clinically sound precoordinations so that SNOMED expansion will
reach an asymptote that keep being manageable"?



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

Re: [Troll] Terminology bindings ... again

[GF]

In system interfaces we must not use pre-coordinted SNOMED terms.
In User Interfaces we can to use them.

In extremo one pre-co-ordinated code can describe the whole oeuvre of 
Shakespeare which makes sense in very specific circumstances for very specific 
purposes

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 22:13, Philippe Ameline  wrote:
> 
> Some people (count me in) strictly ban what you call precoordination (that I 
> call "aglutinating language") because they believe that there is a nearly 
> infinite set of them and such a system is born to "explode" as the frog that 
> wanted to mimic the ox.
> 
> To put it differently: you cannot express all possible discourses as 
> predetermined concepts.
> 
> Do I interpret your answer correctly if I say that you have an optimist 
> vision in the form "there is a limited number of clinically sound 
> precoordinations so that SNOMED expansion will reach an asymptote that keep 
> being manageable"?
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[GF]

Pre-coordinated SNOMED codes are like classifications, in that they are used at 
the user level, the User Interface,
The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed in 
its constituents.
These decomposed primitive codes can be used in structures like archetypes at 
the proper places.
In this way the pre-coorodinated SNOMED codes are iso-semantic.

But we keep the semantic differences codes expressed  using the SNOMED ontology 
and the Archetype and its codes.
Ontologies have the Open World Assumption. A pre-corodinated code like: 
No-Cancer means never there was, is or will be cancer. Ontologies describe 
reality.
In archetypes that use the Closed World Assumption Diagnosis=cancer, 
PresenceModifier=No means No Cancer found but perhaps they are. It just was not 
found. Presence of absence in a database are described.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 20:55, Diego Boscá  wrote:
> 
> What I was referencing was one way in which current systems (or more exactly, 
> their developers) could use codes already available in Snomed to create 
> subsets of their forms, regardless their input forms have precoordinated 
> options or use some kind of postcoordination mechanism. By defining these 
> subsets, you are making this form comparable with other similar forms (that 
> use other approaches to store similar information). It isn't about making 
> doctors in the same organization being able to have *new* ways of encoding 
> things, is about taking the forms they currently use and encode them in order 
> to be comparable with data in other organizations (and in principle, they 
> don't even need to be aware of this codification). With this, we can make 
> data have a meaning outside their original systems.
> 
> This is why I say that precoordination in snomed is a good thing. They are 
> terms that have been put in a form somewhere, and having them as is, and at 
> the same time having their undelying equivalent postcoordinated expression 
> helps in softening the boundary problem IMHO.
> I'm always up to go into the future inventing new cool things, but at least 
> in healthcare we are not allowed to lose data already available in current 
> systems.
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Thomas Beale]

On 31/03/2018 10:38, Philippe Ameline wrote:

...

When I try to explain all this to lesser tech-savvy people (means, who 
don't belong to this list ;-) ), I usually explain that:
- usual systems (with an information schema tied to a database schema) 
are like a printed form. The day after you received the 5000 printed 
sheet you ordered, you will realize that there are several design 
flaws that you will have to endure while the stock is not empty,
- openEHR is a flexible schema, similar to a set of stamps that lets 
you build forms dynamically from blank paper. If your design has to 
evolve, you just have to adapt one of the stamps.
- in my system, based on an ontology and a dependency grammar, you can 
use stamps (archetypes like) and/or "write" freely.




just by means of clarification for some readers, since I happen to know 
how both openEHR and Philippe's system works, here's the way to 
understand how openEHR would perform the same function as Ligne-de-vie 
(which it can):


 * build a lot of CLUSTER archetypes, and probably more OBSERVATION
   ones; each CLUSTER archetype would be one of the 'trees' Philippe
   talks about
 * each of those CLUSTER archetypes has slot nodes that indicate where
   subordinate CLUSTER archetypes join, and which ones are allowed, in
   the usual openEHR fashion;
 o remember, a slot can allow multiple possible substitutions
 * at run time, a form containing a top level Entry, usually an
   OBSERVATION will be deployed on the screen, and by a process of user
   choice / UI movements etc, the data will get filled in, and
   subordinate CLUSTER archetypes will be chosen on the way, and filled
   in along the way.

This mode of operation is known by us in openEHR-land as 'dynamic 
slot-filling' or 'runtime templating', as opposed to the more typical 
design-time templating used in a lot of systems, where most of the 
choices are made prior to runtime. But openEHR systems do use runtime 
slot-filling as well, e.g. for writing discharge summaries and 
referrals, where the data items are only knowable in the encounter or 
report-writing session.




I have always understood openEHR as a link, a step, between the "good 
old way" (discourse range hard coded into a database schema) and a 
modern approach where you can really "tell a patient story" using a 
genuine (structured, processable) language. 15 years ago, Thomas and I 
spent hours discussing the opportunity for openEHR to include a 
reference ontology in its kernel ; this decision was not made for very 
good reasons, but I guess that it still remains a necessary evolution.




see above - in the last 5+ years, much greater use has been made of 
smaller CLUSTER archetypes, which perform the function of the fils 
guides trees, but not as well, because the modellers don't use the LdV 
modelling discipline at that fine-grained level. We should do that in 
openEHR; it would require somewhat better features in some of the 
modelling tools.


I actually think we should consider how to map the fils guides into 
OBSERVATION and CLUSTER archetypes in openEHR, and also export out 
archetypes into fils guides format.


Thomas very accurately explained why SNOMED is a deceptive candidate 
for such a reference ontology. And, unfortunately, it is deep rooted 
in its origins as a coding system. I can hear all the arguments about 
"legacy system" and even "legacy medicine" (the one still fully 
organized for siloed acute care at a time our society already entered 
the information age and suffers from chronic diseases). The question 
remains to guess if SNOMED is a component that lets you stuck in the 
past or helps you disrupt the legacy craps.


Now, let's imagine a modern system that would allow you to "tell a 
patient medical story" from the various viewpoints of a 
multidisciplinary patient centered team. What would be the point about 
having "local vocabulary subsets"? Do you think that a GP shouldn't 
use the word "mitral leak" or any other "specialized" word in the 
medical vocabulary?


My feeling is that selected subset is a solution when using SNOMED as 
a coding system. The subset being the global list of values that are 
legal for the fields in the existing schema, in the same way you will 
select subsets in a billing system. But when it comes to "telling a 
story" using a language, in my opinion subsets are a non-sense. We 
don't use "vocabulary subsets" when we talk, and each contributor in a 
patient's team would mechanically get exposed to a super-set; subset 
is actually only fit for silos... and at a time when medicine is 
already becoming a narrow silo in health, I really don't see it as a 
sound strategy.




I mostly agree here, with one major exception: entering a diagnosis. In 
that case, you do want subsets that are meaningful to your work context. 
If it is paediatric oncology, you may have a form with a field that can 
only be some kind of cancer or related Dx that that department deals 
with - then you 

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

[Diego Boscá]

y entered the information age
>> and suffers from chronic diseases). The question remains to guess if SNOMED
>> is a component that lets you stuck in the past or helps you disrupt the
>> legacy craps.
>>
>> Now, let's imagine a modern system that would allow you to "tell a
>> patient medical story" from the various viewpoints of a multidisciplinary
>> patient centered team. What would be the point about having "local
>> vocabulary subsets"? Do you think that a GP shouldn't use the word "mitral
>> leak" or any other "specialized" word in the medical vocabulary?
>>
>> My feeling is that selected subset is a solution when using SNOMED as a
>> coding system. The subset being the global list of values that are legal
>> for the fields in the existing schema, in the same way you will select
>> subsets in a billing system. But when it comes to "telling a story" using a
>> language, in my opinion subsets are a non-sense. We don't use "vocabulary
>> subsets" when we talk, and each contributor in a patient's team would
>> mechanically get exposed to a super-set; subset is actually only fit for
>> silos... and at a time when medicine is already becoming a narrow silo in
>> health, I really don't see it as a sound strategy.
>>
>> Best,
>>
>> Philippe
>>
>> Le 23/03/2018 à 10:49, Diego Boscá a écrit :
>>
>> 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 <
>> silje.ljosland.ba...@nasjonalikt.no>:
>>
>>> 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-boun...@lists.openehr.org> *On
>>> Behalf Of *Mikael Nyström
>>> *Sent:* Friday, March 23, 2018 10:06 AM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@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 la

Re: [Troll] Terminology bindings ... again

[A Verhees]

Style can be explained, please do.
Documentation ontology can be useful. Please send that too.

Thanks
Bert

Op za 31 mrt. 2018 13:27 schreef GF :

> What do you expect from a technical description when it comes to styles?
> Under the hood one sees no striking differences.
> Archetype nodes are archetype nodes, leafnodes are leafnodes.
> What is different is the way one uses ADL to constrain the RM.
>
> Or do you mean to see the documentation Ontology?
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 31 Mar 2018, at 13:04, A Verhees  wrote:
>
> Okay. Do you have a technical description of what you are talking about?
>
> Thanks
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[GF]

What do you expect from a technical description when it comes to styles?
Under the hood one sees no striking differences.
Archetype nodes are archetype nodes, leafnodes are leafnodes.
What is different is the way one uses ADL to constrain the RM.

Or do you mean to see the documentation Ontology?

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 13:04, A Verhees  wrote:
> 
> Okay. Do you have a technical description of what you are talking about?
> 
> Thanks
> Bert



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[A Verhees]

for
>> silos... and at a time when medicine is already becoming a narrow silo in
>> health, I really don't see it as a sound strategy.
>>
>> Best,
>>
>> Philippe
>>
>> Le 23/03/2018 à 10:49, Diego Boscá a écrit :
>>
>> 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 <
>> silje.ljosland.ba...@nasjonalikt.no>:
>>
>> 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-boun...@lists.openehr.org> *On
>>> Behalf Of *Mikael Nyström
>>> *Sent:* Friday, March 23, 2018 10:06 AM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@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-boun...@lists.openehr.org
>>> <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
>>> j

Re: [Troll] Terminology bindings ... again

[A Verhees]

d 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 <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> 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-boun...@lists.openehr.org> *On
>> Behalf Of *Mikael Nyström
>> *Sent:* Friday, March 23, 2018 10:06 AM
>> *To:* For openEHR technical discussions <
>> openehr-technical@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-boun...@lists.openehr.org
>> <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 (wh

Re: [Troll] Terminology bindings ... again

[GF]

 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 
>> <silje.ljosland.ba...@nasjonalikt.no 
>> <mailto:silje.ljosland.ba...@nasjonalikt.no>>:
>> 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-boun...@lists.openehr.org 
>> <mailto:openehr-technical-boun...@lists.openehr.org>> On Behalf Of Mikael 
>> Nyström
>> Sent: Friday, March 23, 2018 10:06 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 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 
>> <mailto:openehr-technical-boun...@lists.openehr.org>] För Thomas Beale
>> Skickat: den 23 mars 2018 01:06
>> Till: openehr-technical@lists.openehr.org 
>> <mailto: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. L

Re: [Troll] Terminology bindings ... again

[GF]

The specialisation in the OpenEHR RM itself is an anomaly, that can be 
circumvented.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 12:14, Bert Verhees  wrote:
> 
> On 31-03-18 12:11, GF wrote:
>> Both styles are possible with any RM.
>> It is a choice.
> Do you mean, inside OpenEhr by using the GenericEntry?
> Or are there other entry-types possible also?
> 
>> 
>> Most archetype modellers use the Class-Attribute / Archetype Node style.
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl 
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 31 Mar 2018, at 11:04, Bert Verhees >> > wrote:
>>> 
>>> Maybe we should relate this thinking to CEN13606 because that Reference 
>>> Model allows more generic thinking.
>>> (Thinking this because GF was the convenor of this CEN standard)
>>> 
>>> But even then some more explanation would be welcome.
>>> 
>>> Bert
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> 
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Bert Verhees]

On 31-03-18 12:11, GF wrote:

Both styles are possible with any RM.
It is a choice.

Do you mean, inside OpenEhr by using the GenericEntry?
Or are there other entry-types possible also?



Most archetype modellers use the Class-Attribute / Archetype Node style.

Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 31 Mar 2018, at 11:04, Bert Verhees > wrote:


Maybe we should relate this thinking to CEN13606 because that 
Reference Model allows more generic thinking.

(Thinking this because GF was the convenor of this CEN standard)

But even then some more explanation would be welcome.

Bert




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



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

Re: [Troll] Terminology bindings ... again

[GF]

Both styles are possible with any RM.
It is a choice.

Most archetype modellers use the Class-Attribute / Archetype Node style.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 11:04, Bert Verhees  wrote:
> 
> Maybe we should relate this thinking to CEN13606 because that Reference Model 
> allows more generic thinking.
> (Thinking this because GF was the convenor of this CEN standard)
> 
> But even then some more explanation would be welcome.
> 
> Bert



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Philippe Ameline]

ke 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-boun...@lists.openehr.org
> <mailto:openehr-technical-boun...@lists.openehr.org>> *On Behalf
> Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 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 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
> <mailto:openehr-technical-boun...@lists.openehr.org>] *För *Thomas
> Beale
> *Skickat:* den 23 mars 2018 01:06
> *Till:* openehr-technical@lists.openehr.org
> <mailto: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 pati

Re: [Troll] Terminology bindings ... again

[Bert Verhees]

Maybe we should relate this thinking to CEN13606 because that Reference 
Model allows more generic thinking.

(Thinking this because GF was the convenor of this CEN standard)

But even then some more explanation would be welcome.

Bert

On 31-03-18 10:37, GF wrote:

Dear Thomas,

There are two possible Modelling styles:
*- Archetype Leafnode style (Element-Data style)*
Specialisation by changing the Element Data field
Each archetype is a fixed, standardised, pattern, a mini-ontology
The fixed path to the leaf-node defines the full meaning of that leaf-node

*- Archetype Node style (Class-Attribute style)*
Specialisation by changing node names in the archetype
Each archetype makes use of  non-standard patterns.
The meaning is changed by changing node names.

Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 30 Mar 2018, at 18:07, Thomas Beale > wrote:


Gerard,

I don't know that your modelling approach is that far from openEHR - 
you are from memory using CLUSTER in a way we are not, but I don't 
recall the details. In any case, is there a recent reference page on 
the web where a technical summary of your modelling style can be seen?


thanks

- thomas


On 30/03/2018 16:49, GF wrote:

Philippe,

Fist of all: My ideas about modelling and using archetype, etc is 
not shared by OpenEhr


I agree that the tree is important.
My tree starts at Composition contaiining one of more Sections, 
and/or Entries.
The Entry models a process of one of these: data observation, data 
evaluation, data planning, data ordering and data about events/actions.
Each of these models deal with the full epistemology of that topic 
using standardised patterns/Clusters/Archetypes
That what is observed is a Cluster archetype that models the datum 
plus its context/epistemology.


What is important is the Modelling Style.
In OpenEhr the nodes of the Archetype are changed.
In my style, since I make use of predefined patterns I will not 
change the nodes but change the data in the Elements.
In my style of modelling querying the leaves is that what is done. 
The unique path defines its meaning.
In my way of modelling the collection of paths is a kind of ontology 
for data in healthcare records.





--
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




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



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

Re: [Troll] Terminology bindings ... again

[GF]

Dear Thomas,

There are two possible Modelling styles:
- Archetype Leafnode style (Element-Data style)
Specialisation by changing the Element Data field
Each archetype is a fixed, standardised, pattern, a mini-ontology
The fixed path to the leaf-node defines the full meaning of that leaf-node

- Archetype Node style (Class-Attribute style)
Specialisation by changing node names in the archetype
Each archetype makes use of  non-standard patterns.
The meaning is changed by changing node names.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 18:07, Thomas Beale  wrote:
> 
> Gerard,
> 
> I don't know that your modelling approach is that far from openEHR - you are 
> from memory using CLUSTER in a way we are not, but I don't recall the 
> details. In any case, is there a recent reference page on the web where a 
> technical summary of your modelling style can be seen?
> 
> thanks
> 
> - thomas
> 
> On 30/03/2018 16:49, GF wrote:
>> Philippe,
>> 
>> Fist of all: My ideas about modelling and using archetype, etc is not shared 
>> by OpenEhr
>> 
>> I agree that the tree is important.
>> My tree starts at Composition contaiining one of more Sections, and/or 
>> Entries.
>> The Entry models a process of one of these: data observation, data 
>> evaluation, data planning, data ordering and data about events/actions.
>> Each of these models deal with the full epistemology of that topic using 
>> standardised patterns/Clusters/Archetypes
>> That what is observed is a Cluster archetype that models the datum plus its 
>> context/epistemology.
>> 
>> What is important is the Modelling Style.
>> In OpenEhr the nodes of the Archetype are changed.
>> In my style, since I make use of predefined patterns I will not change the 
>> nodes but change the data in the Elements.
>> In my style of modelling querying the leaves is that what is done. The 
>> unique path defines its meaning.
>> In my way of modelling the collection of paths is a kind of ontology for 
>> data in healthcare records.
>> 
>> 
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 30/03/2018 à 17:38, Thomas Beale a écrit :

>
> Paths is also how openEHR querying works, and in pretty much the same
> way, except for the technical fact of using archetype codes rather
> than literal strings.
>
> - thomas
>

I wrote literal strings for clarity ; actually it is a path of codes
from the ontology.

To be accurate, if the ontology contains:
GECHN1  Echocardiography  (means label 1 for concept GECHN ; it could
exist a "true synonym" GECHN2 = Cardiac echography)
0FIND1    Findings
AMITV1   Mitral valve

Then the query for "Echocardiography/Findings/Mitral valve" would be
expressed as the path of concepts GECHN/0FIND/AMITV

In openEHR, each Archetype is a "local semantic reference frame" while I
work with a global one.

Philippe




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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

Gerard,

I don't know that your modelling approach is that far from openEHR - you 
are from memory using CLUSTER in a way we are not, but I don't recall 
the details. In any case, is there a recent reference page on the web 
where a technical summary of your modelling style can be seen?


thanks

- thomas


On 30/03/2018 16:49, GF wrote:

Philippe,

Fist of all: My ideas about modelling and using archetype, etc is not 
shared by OpenEhr


I agree that the tree is important.
My tree starts at Composition contaiining one of more Sections, and/or 
Entries.
The Entry models a process of one of these: data observation, data 
evaluation, data planning, data ordering and data about events/actions.
Each of these models deal with the full epistemology of that topic 
using standardised patterns/Clusters/Archetypes
That what is observed is a Cluster archetype that models the datum 
plus its context/epistemology.


What is important is the Modelling Style.
In OpenEhr the nodes of the Archetype are changed.
In my style, since I make use of predefined patterns I will not change 
the nodes but change the data in the Elements.
In my style of modelling querying the leaves is that what is done. The 
unique path defines its meaning.
In my way of modelling the collection of paths is a kind of ontology 
for data in healthcare records.





--
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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

Fist of all: My ideas about modelling and using archetype, etc is not shared by 
OpenEhr

I agree that the tree is important.
My tree starts at Composition contaiining one of more Sections, and/or Entries.
The Entry models a process of one of these: data observation, data evaluation, 
data planning, data ordering and data about events/actions.
Each of these models deal with the full epistemology of that topic using 
standardised patterns/Clusters/Archetypes
That what is observed is a Cluster archetype that models the datum plus its 
context/epistemology.

What is important is the Modelling Style.
In OpenEhr the nodes of the Archetype are changed.
In my style, since I make use of predefined patterns I will not change the 
nodes but change the data in the Elements.
In my style of modelling querying the leaves is that what is done. The unique 
path defines its meaning.
In my way of modelling the collection of paths is a kind of ontology for data 
in healthcare records.




Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 17:25, Philippe Ameline  wrote:
> 
> Le 30/03/2018 à 16:49, GF a écrit :
>> Philippe,
>> 
>> I understand Archetypes are discourse models and form a sentences
>> A collection of sentences (Entry Archetypes) form one 
>> story/session/Composition and define the content of a system-interface 
>> connected to a database, or screen, or other service like a messaging system.
>> In my terms: A Template consists of Entry Archetypes and is the content of a 
>> system-interface.
>> The Composition, Template, the system-interface are equivalent, but need the 
>> story, system-interface, Template must contain the data and its full 
>> context/ epistemology.
>> The Archetypes in my thinking are standardised patterns with which to 
>> construct an Entry archetype.
>> 
>> My hierargy becomes:
>> 
>> Ontology - Encyclopedia
>> Terminology  - Dictionary
>> Cluster Archetype- Standardised phrases/patterns
>> Entry Archetype  - Clinical sentence including epistemology/context 
>> (collection of patterns)
>> Composition  - Clinical story a Template with a collection of 
>> sentences/Entry archetypes
>> 
>> Queries can be for leave nodes to find in a Patient Record the datum. In 
>> order to interpret the datum fully and safely one must inspect the whole 
>> associated Entry and/or Composition, (depending on specifics)
> 
> Gerard,
> 
> I think that I get your point, though not being proficient enough in openEHR 
> details.
> 
> In my own universe, the basic information unit (as stored on disk) is a tree. 
> Each node of this tree being an element from the ontology, the tree is fully 
> autonomous and doesn't need external interpretation material.
> 
> For example:
> 
> Echocardiography
> Indication
> 
> Findings
> Mitral valve
> Doppler
> Mitral leak
> 
> 
> Hence, the "basic query unit" is not for leave nodes, but rather for a path ; 
> for example a query for "Echocardiography/Findings/Mitral valve" would return 
> a sub-tree.
> 
> But maybe you were saying this already.
> 
> Best,
> 
> Philippe
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

Paths is also how openEHR querying works, and in pretty much the same 
way, except for the technical fact of using archetype codes rather than 
literal strings.


- thomas


On 30/03/2018 16:25, Philippe Ameline wrote:


For example:

Echocardiography
    Indication
        
    Findings
        Mitral valve
            Doppler
                Mitral leak
        

Hence, the "basic query unit" is not for leave nodes, but rather for a 
path ; for example a query for "Echocardiography/Findings/Mitral 
valve" would return a sub-tree.




--
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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 30/03/2018 à 16:49, GF a écrit :

> Philippe,
>
> I understand Archetypes are discourse models and form a sentences
> A collection of sentences (Entry Archetypes) form one
> story/session/Composition and define the content of a system-interface
> connected to a database, or screen, or other service like a messaging
> system.
> In my terms: A Template consists of Entry Archetypes and is the
> content of a system-interface.
> The Composition, Template, the system-interface are equivalent, but
> need the story, system-interface, Template must contain the data and
> its full context/ epistemology.
> The Archetypes in my thinking are standardised patterns with which to
> construct an Entry archetype.
>
> My hierargy becomes:
>
> Ontology- Encyclopedia
> Terminology- Dictionary
> Cluster Archetype- Standardised phrases/patterns
> Entry Archetype- Clinical sentence including epistemology/context
> (collection of patterns)
> Composition- Clinical story a Template with a collection of
> sentences/Entry archetypes
>
> Queries can be for leave nodes to find in a Patient Record the datum.
> In order to interpret the datum fully and safely one must inspect the
> whole associated Entry and/or Composition, (depending on specifics)

Gerard,

I think that I get your point, though not being proficient enough in
openEHR details.

In my own universe, the basic information unit (as stored on disk) is a
tree. Each node of this tree being an element from the ontology, the
tree is fully autonomous and doesn't need external interpretation material.

For example:

Echocardiography
    Indication
        
    Findings
        Mitral valve
            Doppler
                Mitral leak
        

Hence, the "basic query unit" is not for leave nodes, but rather for a
path ; for example a query for "Echocardiography/Findings/Mitral valve"
would return a sub-tree.

But maybe you were saying this already.

Best,

Philippe

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

Re: [Troll] Terminology bindings ... again

[GF]

Philippe,

I understand Archetypes are discourse models and form a sentences
A collection of sentences (Entry Archetypes) form one story/session/Composition 
and define the content of a system-interface connected to a database, or 
screen, or other service like a messaging system.
In my terms: A Template consists of Entry Archetypes and is the content of a 
system-interface.
The Composition, Template, the system-interface are equivalent, but need the 
story, system-interface, Template must contain the data and its full context/ 
epistemology.
The Archetypes in my thinking are standardised patterns with which to construct 
an Entry archetype.

My hierargy becomes:

Ontology- Encyclopedia
Terminology - Dictionary
Cluster Archetype   - Standardised phrases/patterns
Entry Archetype - Clinical sentence including epistemology/context (collection 
of patterns)
Composition - Clinical story a Template with a collection of 
sentences/Entry archetypes

Queries can be for leave nodes to find in a Patient Record the datum. In order 
to interpret the datum fully and safely one must inspect the whole associated 
Entry and/or Composition, (depending on specifics)

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 30 Mar 2018, at 14:38, Philippe Ameline  wrote:
> 
> Le 28/03/2018 à 23:42, GF a écrit :
>> I see the analogies:
>> - Ontology   = Encyclopedia
>> - Terminology= Dictionary
>> - Archetype  = Phrase
> 
> Hi Gerard,
> 
> I would rather see Archetypes as "discourse models" that form a mold for 
> sentences or groups of sentences. The Phrase, in you enumeration, would 
> rather be the instantiated information (stored in database).
> 
> If you are curious about the way a tree of concept can be homogeneous to a 
> sentence, Google "dependency grammar".
> 
> This has been my main topic for 30 years in the report generation domain, and 
> I can say that "simply ordering information on a form" and "trying to tell 
> something using a structured vocabulary" are much different tasks. Typically, 
> the first approach concentrates on the leaves while the other makes certain 
> that branches give the proper meaning to the leaves.
> 
> Best,
> 
> Philippe
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Seref Arikan]

Hi Philippe,
See inline please

On Friday, March 30, 2018, Philippe Ameline 
wrote:

> Le 28/03/2018 à 23:42, GF a écrit :
>
> I see the analogies:
> - Ontology = Encyclopedia
> - Terminology = Dictionary
> - Archetype = Phrase
>
>
> Hi Gerard,
>
> I would rather see Archetypes as "discourse models" that form a mold for
> sentences or groups of sentences. The Phrase, in you enumeration, would
> rather be the instantiated information (stored in database).
>
> If you are curious about the way a tree of concept can be homogeneous to a
> sentence, Google "dependency grammar".
>
> This has been my main topic for 30 years in the report generation domain,
> and I can say that "simply ordering information on a form" and "trying to
> tell something using a structured vocabulary" are much different tasks.
> Typically, the first approach concentrates on the leaves while the other
> makes certain that branches give the proper meaning to the leaves.
>
You nailed it here. My approach to openEhr based data warehouse design has
been taking the leaf nodes of compositions as facts and paths to them as
dimensions.
The design of RM fits this view really well.

It is a bit of an irony that strongest focus on openEhr adoption is on the
data creation step, i.e. clinical care and its potential for secondary use
rarely gets attention

>
>
> Best,
>
> Philippe
>
> Y
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 28/03/2018 à 23:42, GF a écrit :

> I see the analogies:
> - Ontology= Encyclopedia
> - Terminology = Dictionary
> - Archetype = Phrase

Hi Gerard,

I would rather see Archetypes as "discourse models" that form a mold for
sentences or groups of sentences. The Phrase, in you enumeration, would
rather be the instantiated information (stored in database).

If you are curious about the way a tree of concept can be homogeneous to
a sentence, Google "dependency grammar".

This has been my main topic for 30 years in the report generation
domain, and I can say that "simply ordering information on a form" and
"trying to tell something using a structured vocabulary" are much
different tasks. Typically, the first approach concentrates on the
leaves while the other makes certain that branches give the proper
meaning to the leaves.

Best,

Philippe

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

Re: [Troll] Terminology bindings ... again

[GF]

Dear Philippe,

On purpose I provided these examples.

I agree that anatomic structures can be pre-coordinated.
They are the exception to the rule.

And perhaps in the domain of medical devices we could have exceptions.

I see the analogies:
- Ontology  = Encyclopedia
- Terminology   = Dictionary
- Archetype = Phrase

Under specific circumstances we need aggregated concepts for use in the User 
screen, or during data entry, or data export (for statistics)
SNOMED has the capability to create those complex codes for these very specific 
purposes.
When we need to store and retrieve in a database or when a Clinical Reasoner 
processes data the Rules apply.
Archetypes help define the datum but also its full context/epistomology so the 
data can be interpreted safely.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 28 Mar 2018, at 18:14, Philippe Ameline  wrote:
> 
> Gerard, I like your rule (build a grammar that coordinates a vocabulary of 
> "atomic concepts" instead of agglutinating meta-concepts in the vocabulary), 
> but not your "left eye" example ;-)
> 
> In my own "universe", the "left eye" is a true physical object (when "eye" is 
> a concept).
> I would say the same thing about the "left common carotid artery" which is 
> something you can actually "touch". Representing this concept as an artery 
> which belongs to the carotid network on the left part of the body is not 
> pre-coordination but rather what could be expressed by a semantic network.
> 
> I agree with your "blue eye" example since it is simply "an eye which color 
> is blue".
> 
> To answer Mikael Nyström in the same message, I would be OK with his 
> conclusion about "the simple solution is to not use what you don't need" if :
> - this task had not been unsuccessfully tested by Belgian GPs, who literally 
> spent years trying to select a subset with no avail,
> - this "language" was not advertised as a communication system... which 
> actually keeps you exposed to the full set unless everyone agrees to a common 
> subset (using Tom's proposals and Gerard's rule, for example).
> 
> Mikael is right when he says that it would be unfair to say that Snomed "is 
> bad because it isn’t optimized for [one's] narrow use case"... unless there 
> are lots of narrows use cases needed and unless one of these narrow use cases 
> is key to the next mainstream use case. If innovators (typically the ones 
> with weird use cases) consider Snomed as a millstone around their necks, it 
> is actually an issue worth considering.
> As pointed before in this thread, this conversation is closely related to HL7 
> V3 and its RIM before it was "fhired".
> 
> Best,
> 
> Philippe



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Gerard, I like your rule (build a grammar that coordinates a vocabulary
of "atomic concepts" instead of agglutinating meta-concepts in the
vocabulary), but not your "left eye" example ;-)

In my own "universe", the "left eye" is a true physical object (when
"eye" is a concept).
I would say the same thing about the "left common carotid artery" which
is something you can actually "touch". Representing this concept as an
artery which belongs to the carotid network on the left part of the body
is not pre-coordination but rather what could be expressed by a semantic
network.

I agree with your "blue eye" example since it is simply "an eye which
color is blue".

To answer Mikael Nyström in the same message, I would be OK with his
conclusion about "the simple solution is to not use what you don't need"
if :
- this task had not been unsuccessfully tested by Belgian GPs, who
literally spent years trying to select a subset with no avail,
- this "language" was not advertised as a communication system... which
actually keeps you exposed to the full set unless everyone agrees to a
common subset (using Tom's proposals and Gerard's rule, for example).

Mikael is right when he says that it would be unfair to say that Snomed
"is bad because it isn’t optimized for [one's] narrow use case"...
unless there are lots of narrows use cases needed and unless one of
these narrow use cases is key to the next mainstream use case. If
innovators (typically the ones with weird use cases) consider Snomed as
a millstone around their necks, it is actually an issue worth considering.
As pointed before in this thread, this conversation is closely related
to HL7 V3 and its RIM before it was "fhired".

Best,

Philippe

Le 22/03/2018 à 14:26, GF a écrit :
> One simple rule solves the boundary problem.
>
> In my words.
> In principle models we use in the Semantic Stack are autonomous and
> orthogonal to each other. Meaning that at _precisely_ defines points
> the intersect,
> SNOMED is an ontology defining terms for concepts.
> Concept can be primitive or compound.
> Primitive concept examples are: Left and Right and Eye, White, Red and
> Blue. All terms one expects in a dictionary.
> Compound concepts are pre-co-ordinated concepts: Left Eye, Right Eye.
> Eye White coloured Red, ‘Blue eye’. All terms one expects in a
> pattern/standard phrase using words from a dictionary in a syntax.
>
> The rule is:
> Pre-coordination is done via Archetype/Patterns using Primitive concepts.
> Pre-coordination is not done via an ontology/terminology.
>
> Off course clinicians on their screens or doing statistics need
> Compound concepts and therefor need pre-coorodinated terms.
> These pre-coordinated terms must never be used to store, retrieve,
> interpret raw health data inside Health IT-systems.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl <mailto:gf...@luna.nl>
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
>> On 22 Mar 2018, at 00:46, Heather Leslie
>> <heather.les...@atomicainformatics.com
>> <mailto:heather.les...@atomicainformatics.com>> wrote:
>>
>> 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 agreemen

Re: [Troll] Terminology bindings ... again

[Bert Verhees]

Thanks, William, I know art-decor, very inspiring, and very usable models.
It helped me in the past a lot with designing archetypes and other 
information models


But as far as I could see subsets in it they were very much bounded to 
an item in a model, so not very easy to use or to find if one would want 
to create another model.


So I am not sure if they can be compared with the NHS where they have 
more generic listings of subjects: "SNOMED CT human-readable subset - 
Gastroenterology" or "SNOMED CT human-readable subset - Gynaecology", so 
not bounded to a specific model but rather to a sub-domain of clinical 
knowledge/practice


Do we have that kind of subsets in the Netherlands?

Bert


On 26-03-18 09:31, wgoos...@results4care.nl wrote:


Creating subsets is the case in the Netherlands.

However they are published in different fashions:

  * As national extensions in SnomedCT online
  * On Nictiz art decor for projects as perinatology (varied sets for
data and for valuesets)
  * On zorginformatiebouwstenen
  * On the FHIR publication sites
  * On project sites
  * On github Detailed Clinical Models in individual DCMs
  * And probably more.

Dr William Goossen
Directeur
Results 4 Care bv
Tel +31654614458

*Van: *openehr-technical-requ...@lists.openehr.org 
<mailto:openehr-technical-requ...@lists.openehr.org>

*Verzonden: *maandag 26 maart 2018 08:26
*Aan: *openehr-technical@lists.openehr.org 
<mailto:openehr-technical@lists.openehr.org>

*Onderwerp: *openEHR-technical Digest, Vol 73, Issue 86

Send openEHR-technical mailing list submissions to

 openehr-technical@lists.openehr.org

To subscribe or unsubscribe via the World Wide Web, visit

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

or, via email, send a message with subject or body 'help' to

openehr-technical-requ...@lists.openehr.org

You can reach the person managing the list at

openehr-technical-ow...@lists.openehr.org

When replying, please edit your Subject line so it is more specific

than "Re: Contents of openEHR-technical digest..."

Today's Topics:

   1. Re: SV: [Troll] Terminology bindings ... again (A Verhees)

--

Message: 1

Date: Mon, 26 Mar 2018 06:25:19 +

From: A Verhees <bert.verh...@rosa.nl>

To: For openEHR technical discussions

<openehr-technical@lists.openehr.org>

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

Message-ID:

<cafl--x9otb+k-zef1lvzbjp8j6bge6d3dtq_pnc0hclkp92...@mail.gmail.com>

Content-Type: text/plain; charset="utf-8"

Thanks Mikael, very interesting. I will check if they do that in the

Netherlands too.

Bert

Op ma 26 mrt. 2018 08:10 schreef Mikael Nystr?m <mikael.nyst...@liu.se>:

> Hi Bert,

>

>

>

> Most countries (or big organizations) that start to use SNOMED CT 
creates


> those kinds of subsets of SNOMED CT to make it more manageable. See for

> example NHS in England

> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .

>

>

>

>  Regards

>

>  Mikael

>

>

>

>

>

> *Fr?n:* openEHR-technical [mailto:

> openehr-technical-boun...@lists.openehr.org] *F?r *Bert Verhees

> *Skickat:* den 23 mars 2018 20:01

>

>

> *Till:* openehr-technical@lists.openehr.org

> *?mne:* Re: SV: [Troll] Terminology bindings ... again

>

>

>

> Diego, this is a wise thought!!!

> It seems logical, but that is often in good ideas, they seem like: 
why did


> no one ever think about this.

>

> No clinician handles the complete medical science/SNOMED repository 
in his


> profession. Some even use a very small sub-part, think about a 
dentist, a


> physiotherapist, a midwife

> For some is it also the case that not only the subjects are 
different, but


> also how deep the details must go. For some professions it is not

> interesting to know if blood-pressure was measured lying or sitting.

>

> It looks like a good idea if the SNOMED repository will be split up for

> professions, maybe that needs to be done on national level, because the

> clinical profession-structure can differ in countries.

> The rest of the database should be there for second searches, for

> interpreting codes which come from other professions.

>

> I hope someone will pick up this idea, because it is hardly to be 
done for


> individuals. It needs to be done by national SNOMED maintenance teams.

>

> Bert

>

>

> On 23-03-18 10:49, Diego Bosc? wrote:

>

> 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

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

[A Verhees]

Thanks Mikael, very interesting. I will check if they do that in the
Netherlands too.

Bert

Op ma 26 mrt. 2018 08:10 schreef Mikael Nyström <mikael.nyst...@liu.se>:

> Hi Bert,
>
>
>
> Most countries (or big organizations) that start to use SNOMED CT creates
> those kinds of subsets of SNOMED CT to make it more manageable. See for
> example NHS in England
> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *För *Bert Verhees
> *Skickat:* den 23 mars 2018 20:01
>
>
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> Diego, this is a wise thought!!!
> It seems logical, but that is often in good ideas, they seem like: why did
> no one ever think about this.
>
> No clinician handles the complete medical science/SNOMED repository in his
> profession. Some even use a very small sub-part, think about a dentist, a
> physiotherapist, a midwife
> For some is it also the case that not only the subjects are different, but
> also how deep the details must go. For some professions it is not
> interesting to know if blood-pressure was measured lying or sitting.
>
> It looks like a good idea if the SNOMED repository will be split up for
> professions, maybe that needs to be done on national level, because the
> clinical profession-structure can differ in countries.
> The rest of the database should be there for second searches, for
> interpreting codes which come from other professions.
>
> I hope someone will pick up this idea, because it is hardly to be done for
> individuals. It needs to be done by national SNOMED maintenance teams.
>
> Bert
>
>
> On 23-03-18 10:49, Diego Boscá wrote:
>
> 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 <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> 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-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@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 

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

[Jussara Macedo Rötzsch]

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.les...@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-boun...@lists.openehr.org> *On
> Behalf Of *Bakke, Silje Ljosland
> *Sent:* Friday, 23 March 2018 8:35 PM
>
>
> *To:* For openEHR technical discussions <
> openehr-technical@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-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@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:*

Re: [Troll] Terminology bindings ... again

[GF]

Yes.

The simple rules that solve the Boundary Problem need some exceptions.
- anatomical structure
- possibly some aspects of devices

To investigate it properly is a possibility.
The problem I see is the How question.
For me there is only one solution and that is by analysing the problem and 
thinking about it.

Ingredients that we could take in consideration are notions like:
- Models in the Interoperability Stack must be autonomous and orthogonal
- The Models we need in the Stack
- Closed world assumption of Archetypes versus Open world assumption of the 
ontology behind SNOMED
- Requirements for data exposed to users via statistics, screens, forms, and 
documents
- Requirements for data stored, retrieved from databases
- Requirements for data to be interpreted by clinical reasoners
- Modelling methods

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 24 Mar 2018, at 08:41, Heather Leslie 
>  wrote:
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Heather Leslie]

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-boun...@lists.openehr.org> On Behalf 
Of Bakke, Silje Ljosland
Sent: Friday, 23 March 2018 8:35 PM
To: For openEHR technical discussions <openehr-technical@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-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Mikael Nyström
Sent: Friday, March 23, 2018 10:06 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 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<mailto: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 (obser

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

[Bert Verhees]

Diego, this is a wise thought!!!
It seems logical, but that is often in good ideas, they seem like: why 
did no one ever think about this.


No clinician handles the complete medical science/SNOMED repository in 
his profession. Some even use a very small sub-part, think about a 
dentist, a physiotherapist, a midwife
For some is it also the case that not only the subjects are different, 
but also how deep the details must go. For some professions it is not 
interesting to know if blood-pressure was measured lying or sitting.


It looks like a good idea if the SNOMED repository will be split up for 
professions, maybe that needs to be done on national level, because the 
clinical profession-structure can differ in countries.
The rest of the database should be there for second searches, for 
interpreting codes which come from other professions.


I hope someone will pick up this idea, because it is hardly to be done 
for individuals. It needs to be done by national SNOMED maintenance teams.


Bert


On 23-03-18 10:49, Diego Boscá wrote:
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 
<silje.ljosland.ba...@nasjonalikt.no 
<mailto:silje.ljosland.ba...@nasjonalikt.no>>:


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-boun...@lists.openehr.org
<mailto:openehr-technical-boun...@lists.openehr.org>> *On Behalf
Of *Mikael Nyström
*Sent:* Friday, March 23, 2018 10:06 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 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
<mailto:openehr-technical-boun...@lists.openehr.org>] *För *Thomas
Beale
*Skickat:* den 23 mars 2018 01:06
*Till:* openehr-technical@lists.openehr.org
<mailto: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. 

Re: [Troll] Terminology bindings ... again

[GF]

Dear Silje,

I think we agree.

In my view it is not wise to use pre-coorinated codes that include contextual 
information. The reason is that the complete why, when, who and how result in 
too many permutations in order to be tractable.
One must make the distinction between how data is expressed in a generic system 
interface connected to other services such as: database, clinical reasoner, 
import/export, etc. and between a specific interface that users connect with 
for data inspection, data entry, statistical data analysis.
The former must NOT use pre-coordinated terms; the latter depending on user 
requirements will use pre-coordinated terms that can be constructed using the 
raw data in the generic system interface.



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 23 Mar 2018, at 10:35, Bakke, Silje Ljosland 
>  wrote:
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Diego Boscá]

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 <
silje.ljosland.ba...@nasjonalikt.no>:

> 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-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <openehr-technical@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-
> boun...@lists.openehr.org <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

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

[A Verhees]

Maybe a match-table which matches pre coordinated expressions to all
possible post coordinated expressions which have the same meaning will be
necessary.

How can you else find data-entries of a specific meaning by filtering on
SNOMED?

Bert

Op 23 mrt. 2018 10:35 schreef "Bakke, Silje Ljosland" <
silje.ljosland.ba...@nasjonalikt.no>:

> 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-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <openehr-technical@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-
> boun...@lists.openehr.org <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

Re: [Troll] Terminology bindings ... again

[GF]

Thomas,

I agree with your opinions.

In summary:
Model 1- Ontological models define primitive concepts in Terminologies. 
Concepts that one can expect to see in a dictionary.
Model 2- Archetypes define compound concepts using primitive concepts from 
terminologies. Archetypes are models that model a concept and its 
epistemology/context. Archetypes are agreed re-usable patterns and are like 
sentences constructed using syntax and words from a dictionary. This is the 
level where post-coordination takes place.
Model 3- Templates are specific models composed of Archetypes defining the 
content of an interface (database, screen, clinical reasoner, etc) Templates 
are temporal, locally defined, chapters and paragraphs defining/documenting 
patient data obtained in the healthcare process.
Model 4- For specific reasons users might want to see pre-coordinated terms on 
screens, or statistical reporting demand it. This means that raw data obtained 
using Model 3 can be converted to pre-coordinated terms from a Terminology. It 
is a User Interface issue.

All models are orthogonal to each other and intersect at well defined places. 
Models can not be mixed and overlap.
When they do, the problem is intractable.

Next to these 4 models we need additional models:
- Healthcare Process (ContSys)
- Documentation process (Observation Process, Evaluation Process, Planning 
Process, Ordering process, Execution Process, Administrative processes)
- …

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 23 Mar 2018, at 01:06, Thomas Beale  wrote:
> 
> 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, 

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

[Bakke, Silje Ljosland]

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

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

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

[Thomas Beale]

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.


- 

Re: [Troll] Terminology bindings ... again

[GF]

One simple rule solves the boundary problem.

In my words.
In principle models we use in the Semantic Stack are autonomous and orthogonal 
to each other. Meaning that at precisely defines points the intersect,
SNOMED is an ontology defining terms for concepts.
Concept can be primitive or compound.
Primitive concept examples are: Left and Right and Eye, White, Red and Blue. 
All terms one expects in a dictionary.
Compound concepts are pre-co-ordinated concepts: Left Eye, Right Eye. Eye White 
coloured Red, ‘Blue eye’. All terms one expects in a pattern/standard phrase 
using words from a dictionary in a syntax.

The rule is:
Pre-coordination is done via Archetype/Patterns using Primitive concepts.
Pre-coordination is not done via an ontology/terminology.

Off course clinicians on their screens or doing statistics need Compound 
concepts and therefor need pre-coorodinated terms.
These pre-coordinated terms must never be used to store, retrieve, interpret 
raw health data inside Health IT-systems.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 22 Mar 2018, at 00:46, Heather Leslie 
> <heather.les...@atomicainformatics.com> wrote:
> 
> 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 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 
> <mailto:openehr-technical-boun...@lists.openehr.org>] För Thomas Beale
> Skickat: den 21 mars 2018 14:17
> Till: openehr-technical@lists.openehr.org 
> <mailto: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 hav

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

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

[Heather Leslie]

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> On Behalf 
Of michael.law...@csiro.au
Sent: Thursday, 22 March 2018 11:26 AM
To: 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 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<mailto: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 s

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

[Michael.Lawley]

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> on behalf 
of Heather Leslie <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> On Behalf 
Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions <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 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<mailto: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 p

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

[Heather Leslie]

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> On Behalf 
Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions <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 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<mailto: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

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 

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

[Thomas Beale]

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 possible to express 
using a single concept from SNOMED CT, but if it had been possible it had been possible to 
automatically transform that concept to the expression below, which seems like to be what you argue 
for in your "modern approach" use case.

64572001 | Disease (disorder) | :
{  363698007 |Finding site| =
  {33696004 |Bone structure of ankle (body structure)| : 272741003 
|Laterality| = 7771000 |Left (qualifier value)|},
   116676008 |Associated morphology| = 72704001 |Fracture (morphologic 
abnormality)|
}

I therefore find your arguments against SNOMED CT equally relevant as arguments 
of the type

"SNOMED CT is useless, because it contains the concepts 285336007 | Background 
radiation (physical force) |, 60638008 | Planetary surface craft, device (physical 
object) | and 242250006 | Crash landing of spacecraft (event) | and I don't need that 
kind of concepts at my clinic."

because the simple solution is to not use what you don't need.

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

SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

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 possible to express using a single concept from SNOMED 
CT, but if it had been possible it had been possible to automatically transform 
that concept to the expression below, which seems like to be what you argue for 
in your "modern approach" use case.

64572001 | Disease (disorder) | :
   {  363698007 |Finding site| = 
 {33696004 |Bone structure of ankle (body structure)| : 272741003 
|Laterality| = 7771000 |Left (qualifier value)|}, 
  116676008 |Associated morphology| = 72704001 |Fracture (morphologic 
abnormality)| 
   }

I therefore find your arguments against SNOMED CT equally relevant as arguments 
of the type

"SNOMED CT is useless, because it contains the concepts 285336007 | Background 
radiation (physical force) |, 60638008 | Planetary surface craft, device 
(physical object) | and 242250006 | Crash landing of spacecraft (event) | and I 
don't need that kind of concepts at my clinic."

because the simple solution is to not use what you don't need.

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 15 mars 2018 16:18
Till: openehr-technical@lists.openehr.org
Ämne: Re: [Troll] Terminology bindings ... again

Le 15/03/2018 à 00:34, Mikael Nyström a écrit :

> Hi Philippe
>
> It seems like you are making a big deal of that SNOMED CT is an ancient 
> product, but I would like to see your explicit arguments about that instead 
> of only negative generalizations. From my point of view it is quite modern 
> with an OWL based ontology with additional features for terminology and 
> versioning, which basically is what SNOMED CT are.
>
>   Regards
>   Mikael

Hi Mikael,

The question will always remain "what component do you need at a given 
technological moment?"

If what you want to do is what has been done since 1980, that's to say fill 
forms inside a care place and exchange it with other care places, I guess that 
Snomed CT is the proper component.
Since it was born a coding system, you can create complicated meta-concepts in 
a single code (of course, it means you will have to find your own subset inside 
an always expanding universe, but ease comes with a price) and it is very 
convenient to fill the good old set of attribute–value pairs.

On the contrary, if you estimate that a modern approach would be to tell and 
organize a patient's journey, you have to exhibit more modern structures 
because in order to "tell something", you need not only a terminology (say a 
vocabulary) but also a grammar. A proper grammar (at least the one I use) can 
be a "dependency grammar" in the form of a graph or trees.
Now that you can tell elaborated things using a vocabulary (the
ontology) and a grammar (the graph of trees), the "agglutinating"
structure of Snomed rapidly sucks. Because now that "fracture of the left 
ankle" can be expressed as the branch "fracture" "located at" "left ankle", 
there is no longer a need for the hundred of thousand (and
counting) "codes" that where convenient for ancient systems but are now a 
genuine problem.

Do you imagine a natural language that would be so massively agglutinating that 
it would contain words like "FractureOfTheLeftAnkleThatWasTreatedButStillHurts"?
I guess that, due to a terrible learning curve, the children would speak at six 
;-)

To sum it up, Snomed is probably convenient for application with a structure 
schema that can only handle a coding system (hey, it also comes with a semantic 
network) but is not fit as a formal language vocabulary.

Best,

Philippe



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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 16/03/2018 à 13:11, Thomas Beale a écrit :

> Ad hoc negation, in German ;)
>
> But that's not really the fault of ICD10; it's a misuse of it. One
> might argue that it occurs because ICD10 doesn't provide a proper way
> of representing exclusions, only positive identifications. And that's
> an old, long debate...
>

Not certain to get your point here.

"Geometrically", a classification is a pavement of a domain (for ICD10,
the diseases), each sector being delimited by inclusion and exclusion
rules (in the same way frontiers are defined for countries). "Rag bags"
(of the kind "other X") are used to fill existing interstices.

Hence, every code is by construction exclusive from any other code...
and using a classification to "describe" can only come from confusing a
point of the domain (say "type 2 diabetes") with the delimited sector
that comes with the same name (say, depending on inclusion and exclusion
criteria, all hyperglycemia that cannot be qualified as type 1 diabetes).

Of course, is it possible to forget all this and use a classification as
a lexicon... but that would be plainly evil ;-)

Philippe


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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

Ad hoc negation, in German ;)

But that's not really the fault of ICD10; it's a misuse of it. One might 
argue that it occurs because ICD10 doesn't provide a proper way of 
representing exclusions, only positive identifications. And that's an 
old, long debate...


- thomas


On 16/03/2018 07:41, Karsten Hilbert wrote:

On Wed, Mar 14, 2018 at 11:56:07PM +, Mikael Nyström wrote:


Yes, of cause it is! My main point was that a statistical
classification is a simpler product than a clinical ontology
and it is therefore also easier to implement a statistical
classification than a clinical ontology.

And it is also dangerous to your health if used for clinical
care (never mind that that's mandatory in Germany):

If I rule out AIDS in a patient I can - in Germany - attach
to the EHR the relevant ICD-10 appended with an "A" for
"Ausschluß" (as in "ruled out"). When said patient travels to
the United States many people will understandably ignore the
"A" (as it has no meaning to them and it does not belong to
the core definition of ICD-10), et voila, we've got a
manufactured HIV infection.

Even more dangerous situations could be construed.

Karsten


--
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

Re: [Troll] Terminology bindings ... again

[Karsten Hilbert]

On Wed, Mar 14, 2018 at 11:56:07PM +, Mikael Nyström wrote:

> Yes, of cause it is! My main point was that a statistical
> classification is a simpler product than a clinical ontology
> and it is therefore also easier to implement a statistical
> classification than a clinical ontology.

And it is also dangerous to your health if used for clinical
care (never mind that that's mandatory in Germany):

If I rule out AIDS in a patient I can - in Germany - attach
to the EHR the relevant ICD-10 appended with an "A" for
"Ausschluß" (as in "ruled out"). When said patient travels to
the United States many people will understandably ignore the
"A" (as it has no meaning to them and it does not belong to
the core definition of ICD-10), et voila, we've got a
manufactured HIV infection.

Even more dangerous situations could be construed.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

Re: [Troll] Terminology bindings ... again

[Diego Boscá]

As Ricardo already said, "Pathological fracture of ankle due to secondary
osteoporosis" is less a "word" and more a "phrase" that computers can
easily understand, because it is equivalent to:
64572001 |Disease (disorder)| :
42752001 |Due to| = 703264005 |Secondary osteoporosis (disorder)|
{ 363698007 |Finding site| = 33696004 |Bone structure of ankle
(body structure)|,
  116676008 |Associated morphology| = 22640007 |Pathologic
fracture (morphologic abnormality)| }

I don't know what is 'ancient' about being able to ask things like "give me
all the patients with a diagnosis of a disease due to osteoporosis" or "all
patients with fractures in the lower body"



2018-03-15 21:20 GMT+01:00 Philippe Ameline :

> Le 15/03/2018 à 20:30, Ricardo Gonçalves a écrit :
>
>
> I too want to look at the the future and picture a state of art component
> and hopefully a [health] technological utopia, but a lot of work led us to
> what is currently available. Are we taking that to try/improve things and
> get somewhere? Are we holding back until something more mature, more
> usable, more future-alike comes up? Which path is more likely to bring us
> closer to the goal?
>
>
> Hi Ricardo,
>
> The question of settling in a local optimum or to go find a better place
> has probably been the most ancient question that sapiens has been facing ;-)
> Should we keep working hard in this place where harvesting is so hard, or
> should we try to climb this mountain and see if it is not easier on the
> other side?
>
> My opinion is that there is a good reason not to get stuck (trying hard
> forever) with Snomed.
>
> As you said, thinks started with classifications, then some people came up
> with coding systems and later on with ontology. The ability to tell things
> improved step by step and led to an evolution of information structures.
> Meanwhile, the whole society was transformed by ambient information
> systems to the point that we entered the post-industrial era, and, as you
> know it well, the chronic turn demands for a deep reinvention of the
> medical domain.
>
> My opinion is that you cannot cope with such challenges using a "language"
> that, due to its roots as a coding system, includes "words" like
> "Pathological fracture of ankle due to secondary osteoporosis" (concept
> 704293000).
>
> Time will tell if the settlers were more wise than the explorers... and we
> all have to keep in mind, as you nailed it, that we may have different
> goals.
>
> Best,
>
> Philippe
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
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 verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 15/03/2018 à 20:30, Ricardo Gonçalves a écrit :

>
> I too want to look at the the future and picture a state of art
> component and hopefully a [health] technological utopia, but a lot of
> work led us to what is currently available. Are we taking that to
> try/improve things and get somewhere? Are we holding back until
> something more mature, more usable, more future-alike comes up? Which
> path is more likely to bring us closer to the goal?

Hi Ricardo,

The question of settling in a local optimum or to go find a better place
has probably been the most ancient question that sapiens has been facing ;-)
Should we keep working hard in this place where harvesting is so hard,
or should we try to climb this mountain and see if it is not easier on
the other side?

My opinion is that there is a good reason not to get stuck (trying hard
forever) with Snomed.

As you said, thinks started with classifications, then some people came
up with coding systems and later on with ontology. The ability to tell
things improved step by step and led to an evolution of information
structures.
Meanwhile, the whole society was transformed by ambient information
systems to the point that we entered the post-industrial era, and, as
you know it well, the chronic turn demands for a deep reinvention of the
medical domain.

My opinion is that you cannot cope with such challenges using a
"language" that, due to its roots as a coding system, includes "words"
like "Pathological fracture of ankle due to secondary osteoporosis"
(concept 704293000).

Time will tell if the settlers were more wise than the explorers... and
we all have to keep in mind, as you nailed it, that we may have
different goals.

Best,

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

Re: [Troll] Terminology bindings ... again

[Ricardo Gonçalves]

Hi everyone,

After following this thread for a few days, I decided to jump in with my two 
cents because either things got too rethorical while looking for a state of art 
solution matching particular experiences or I'm missing the point more than I 
should.

Historically, statistical classifications such as ICD10 and ICPC2 have been 
used in health [informatics] (even on handwritten forms, for ranking purposes). 
They are as easy to understand/use as their taxonomy allows them to be, but the 
added value is limited to such scope. They are also pretty close to the way 
generic binding is currently handled (matching and validating code/term pairs).

SNOMED CT is not perfect and is not simple, but we cannot demand to 
oversimplify such a complex matter. It encompasses a lot of work to achieve a 
formal ontology that allows both people and machines to understand | fracture | 
: | finding site | = | ankle | in multiple idioms. I think it's quite effective 
as a "language" (yet not trivial, but again, to get the mass to accelerate, 
some force must be applied). In spite of the meaning on it's own, that 
expression can also be easily computed to a preecoordinated concept (if one 
exists and is required, e.g. | fracture of ankle |) or to a set of concepts 
that match the described meaning (even if you don't know all of them 
beforehand, but just some basic/critical defining attributes/relationships) so 
the professional can get filtered suggestions (supported by a capable health 
application/system, just like they already do with statistical 
classifciations/coding systems). It also allows you to query/retrieve the same 
data point despite being coded as (| fracture | : | finding site | = | ankle |) 
or | fracture of ankle |. Actually, it allows even more due to customization 
and localization.

I too want to look at the the future and picture a state of art component and 
hopefully a [health] technological utopia, but a lot of work led us to what is 
currently available. Are we taking that to try/improve things and get 
somewhere? Are we holding back until something more mature, more usable, more 
future-alike comes up? Which path is more likely to bring us closer to the goal?

Best regards,
Ricardo Gonçalves.
On 15/03/2018 13:00:06, openehr-technical-requ...@lists.openehr.org 
<openehr-technical-requ...@lists.openehr.org> wrote:
Send openEHR-technical mailing list submissions to
openehr-technical@lists.openehr.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

or, via email, send a message with subject or body 'help' to
openehr-technical-requ...@lists.openehr.org

You can reach the person managing the list at
openehr-technical-ow...@lists.openehr.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openEHR-technical digest..."


Today's Topics:

1. Re: [Troll] Terminology bindings ... again (Philippe Ameline)


--

Message: 1
Date: Thu, 15 Mar 2018 16:17:51 +0100
From: Philippe Ameline
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again
Message-ID:
Content-Type: text/plain; charset=utf-8

Le 15/03/2018 ? 00:34, Mikael Nystr?m a ?crit?:

> Hi Philippe
>
> It seems like you are making a big deal of that SNOMED?CT is an ancient 
> product, but I would like to see your explicit arguments about that instead 
> of only negative generalizations. From my point of view it is quite modern 
> with an OWL based ontology with additional features for terminology and 
> versioning, which basically is what SNOMED CT are.
>
> Regards
> Mikael

Hi Mikael,

The question will always remain "what component do you need at a given
technological moment?"

If what you want to do is what has been done since 1980, that's to say
fill forms inside a care place and exchange it with other care places, I
guess that Snomed CT is the proper component.
Since it was born a coding system, you can create complicated
meta-concepts in a single code (of course, it means you will have to
find your own subset inside an always expanding universe, but ease comes
with a price) and it is very convenient to fill the good old set of
attribute?value pairs.

On the contrary, if you estimate that a modern approach would be to tell
and organize a patient's journey, you have to exhibit more modern
structures because in order to "tell something", you need not only a
terminology (say a vocabulary) but also a grammar. A proper grammar (at
least the one I use) can be a "dependency grammar" in the form of a
graph or trees.
Now that you can tell elaborated things using a vocabulary (the
ontology) and a grammar (the graph of trees), the "agglutinating"
structure of Snomed rapidly sucks. Because now that "fracture of the
left 

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

+1 but for the focus of this conversation I think we are trying to solve
(find a relatively good enough solution) the clinical side and use detailed
terminologies for that.

On Wed, Mar 14, 2018 at 8:56 PM, Mikael Nyström <mikael.nyst...@liu.se>
wrote:

> Hi Pablo,
>
>
>
> Yes, of cause it is! My main point was that a statistical classification
> is a simpler product than a clinical ontology and it is therefore also
> easier to implement a statistical classification than a clinical ontology.
> But if your use case require a clinical ontology instead of a statistical
> classification, you need to accept that it is more difficult to implement a
> clinical ontology than a statistical classification.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* den 14 mars 2018 23:58
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* RE: [Troll] Terminology bindings ... again
>
>
>
> But ICD is a statistical not a clinical tool.
>
>
>
> On Mar 14, 2018 7:10 PM, "Mikael Nyström" <mikael.nyst...@liu.se> wrote:
>
> Hi,
>
>
>
> Of cause it is possible to create something that is easier to use. ICD-10
> is a good example of something that have similarities with SNOMED CT and is
> both (for some use cases) easier to implement and more widespread. But I if
> you want something that is based on logic, because you want to use logic
> functions when you use the system, it comes with the complexity of logic.
> And it is not that complex to implement SNOMED CT. The problem is probably
> that we have fewer trained people in health informatics (including in for
> example SNOMED CT and openEHR) that in other informatics areas.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Philippe Ameline
> *Sent:* den 13 mars 2018 13:32
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: [Troll] Terminology bindings ... again
>
>
>
> Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :
>
>
>
> I am get the impression that SNOMED CT is hard to implement, and therefore
> wondered if we are at some kind of tipping point, like where HL7v3 was a
> few years ago, and some bright spark came along, and now we have FHIR that
> is gaining great traction in the health community due to the ease at which
> it can be implemented.
>
>
> Hi John,
>
> The tipping point will only get reached when a sufficient amount of Snomed
> users will state that it is uselessly hard to implement... and when someone
> will invent a smart way to simplify it... not there yet ;-)
>
> But I really insist on the two orthogonal issues at stake:
> 1) a component should ease your job and not kill your project (detect
> "dead horses" early),
> 2) a component should not keep you stuck in the wrong (ancient) reference
> frame.
>
> No need to say that FHIR is easier to put at work than the plain RIM, but
> it still keeps its community in a system where "boxes that saw the patient
> passing by can exchange information" when we should (due to both the
> chronic turn and the information society era) be dedicated to organize
> multidisciplinary teamwork around patients.
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

Of course we should contribute missing concepts - that's a given (and 
the mechanisms for doing so are always improving), but read my post 
again, that is not really the main problem with where we are now - I'm 
talking about strategic directions.


- thomas


On 14/03/2018 23:19, Mikael Nyström wrote:


Hi Pablo,

I totally agree with you.

   Regards

   Mikael

*From:*openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of 
*Pablo Pazos

*Sent:* den 13 mars 2018 19:01
*To:* For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org>
*Cc:* For openEHR technical discussions 
<openehr-technical@lists.openehr.org>

*Subject:* Re: [Troll] Terminology bindings ... again

" but in some cases, /it is missing concepts/"

Shouldn't we contribute?

Is the same as openEHR, there are missing archetypes and we need the 
community, users, clinical modelers and engineers to contribute.




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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe

It seems like you are making a big deal of that SNOMED CT is an ancient 
product, but I would like to see your explicit arguments about that instead of 
only negative generalizations. From my point of view it is quite modern with an 
OWL based ontology with additional features for terminology and versioning, 
which basically is what SNOMED CT are.

Regards
Mikael


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 21:54
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again

Le 13/03/2018 à 18:01, Bert Verhees a écrit :

> On 13-03-18 17:45, Philippe Ameline wrote:
>> in my own terms, it means that it is not the proper component for 
>> modern applications.
>
> Wasn't it Voltaire who said that the best is the enemy of the good?

Bert, I get your point and I can perfectly understand that if Snomed can get 
used to do what you need done, you are plainly entitled to use it, even if "not 
perfect".

But the issue could be stated differently: we are living a very specific moment 
since, at the same time, we become part of a genuine information society AND 
are engaged in a turn from acute to chronic care.
It means that we should all be trashing the "good old systems" and dedicate 
ourselves to building risk management systems that allow multidisciplinary 
teams to manage patients' health journeys over time.

Do you think that HL7 and Snomed are the proper components for this kind of 
innovation or that they are stuck in the ancient world?
Do you think that using endemic technologies (components that only exist in the 
medical domain) can be of any use when it comes to health...
that's to say operating in person's "bio-psycho-social bubble", a place where 
education, employment, social issues are as important as medical information, 
and are all plain contributors to risk management?

It is not about "good" versus "perfect", but about having a whole domain (and 
its practitioners) get stuck in a dead arm of the information society.

Best,

Philippe


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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe,

If you only would like to use some of the basic concepts as building blocks in 
post-coordinated expressions using for example the SNOMED CT Compositional 
Grammar Specification and Guide (http://snomed.org/scg) and skip the more 
complex/combined concepts you are more than welcome to do so. It is very easy 
to automatically translate between the post-coordinated expressions and the 
more complex concepts if we need to transfer information between information 
systems that uses the two different approaches.

One of the main reasons why the complex concepts are there is that is gives the 
possibility to easily associate the complex concepts with two or more terms 
that describe the concepts, which many implementers and users appreciate very 
much.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 17:45
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again


Thomas,

Since, in that domain (terminologies, classification, ontologies...), it is not 
that easy to understand someone else's explanation without a sketching tool 
available, do you think I betray your thoughts if I sum it up as "Snomed should 
not be licensed as a "one size fits all" package but should be mainly usable as 
a set of tools and services in support of localized adaptations by national 
organizations"?

It is certainly a good thing to be discussed in order to have Meriterm fill the 
gap.

Besides, as you probably remember, the main reason I don't like Snomed is 
because it is structured like a coding system and not a "narration ontology".

As an example, I would say that a narration ontology should contain atomic 
concepts, like "fracture", "location", "right ankle", but should let "fracture 
of the right ankle" be built as a description structure (say a small tree that 
express that the fracture is located at the right ankle). Snomed inherited the 
incorporation of meta-concepts from its history as a coding system (the kind of 
component that is to be used in systems where information are stored in simple 
value-pair slots that don't allow for elaborated description structures), as 
would be the vocabulary of a massively agglutinating language... Since our 
languages are not massively agglutinating ones (we built sentences), each group 
has to invest a very long time selecting the subset that fits their "local 
language" (for example the subset for GPs).

I have always seen Snomed as a system that could be fit to "fill slots in 
forms" but not as a proper vocabulary to tell a patient's health story... in my 
own terms, it means that it is not the proper component for modern applications.

Philippe

Le 13/03/2018 à 15:21, Thomas Beale a écrit :



The killer move would be to do something I advocated for years unsuccessfully: 
separate SNOMED technology from content and allow them to be independently 
licensable and used. Here, technology means representation (RF2 for example), 
open source programming libraries for working with ref-sets, specs and implems 
for e..g the constraint language, URIs and so on.

It should be possible for a country (the one I am most familiar with w.r.t. to 
terminology today is Brazil) to create an empty 'SNOMED container' of its own, 
and put its existing terminologies in there - typically procedure lists, drug 
codes, lab codes, devices & prosthesis codes, packages (chargeable 
coarse-grained packages like childbirth that you get on a health plan) and so 
on. There are usually < 20k or even 10k such codes for most countries (UK and 
US would an exception), not counting lab analyte codes (but even there, 2000 or 
so codes would take care of most results). But the common situation is that 
nearly every country has its own version of these things, and they are far 
smaller than SNOMED. Now, SNOMED's version of things is usually better for some 
of that content, but in some cases, it is missing concepts.

The ability to easily create an empty SNOMED repo, fill it with national 
vocabularies, have it automatically generate non-clashing (i.e. with other 
countries, or the core) concept codes and mappings, and then serve it from a 
standard CTS2 (or other decent standard) terminology service would have 
revolutionised things in my view. This pathway has not been obviously available 
however, and has been a real blockage. The error was not understanding that the 
starting point for most countries isn't the international core, it's their own 
vocabularies.

The second killer feature would have been to make creating and managing 
ref-sets for data/form fields much easier, based on a subsetting language that 
can be applied to the core, and tools that implement that. Ways are needed to 
make the local / legacy vocabulari

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Pablo,

I totally agree with you.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: den 13 mars 2018 19:01
To: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Cc: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: [Troll] Terminology bindings ... again

" but in some cases, it is missing concepts"
Shouldn't we contribute?
Is the same as openEHR, there are missing archetypes and we need the community, 
users, clinical modelers and engineers to contribute.

LOINC also misses concepts, and when I asked them how can I contribute, they 
sent me the process and some templates for requesting a new concept to be 
added, pretty simple, formal and open!
IMO we can't expect perfection, is a bad strategy and a move towards isolation. 
I think pragmatism is better and go with "this is the best we can expect for". 
We are the ones that should push towards the ideal, but as a guide not as a 
goal (getting a little philosophical here...).
The same idea applies to tooling, anyone can create tools to manage the 
terminology better. In our own backyard we have tools that need improvement, 
but we accept them because there is no better alternative.


On Tue, Mar 13, 2018 at 11:21 AM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:



The killer move would be to do something I advocated for years unsuccessfully: 
separate SNOMED technology from content and allow them to be independently 
licensable and used. Here, technology means representation (RF2 for example), 
open source programming libraries for working with ref-sets, specs and implems 
for e..g the constraint language, URIs and so on.

It should be possible for a country (the one I am most familiar with w.r.t. to 
terminology today is Brazil) to create an empty 'SNOMED container' of its own, 
and put its existing terminologies in there - typically procedure lists, drug 
codes, lab codes, devices & prosthesis codes, packages (chargeable 
coarse-grained packages like childbirth that you get on a health plan) and so 
on. There are usually < 20k or even 10k such codes for most countries (UK and 
US would an exception), not counting lab analyte codes (but even there, 2000 or 
so codes would take care of most results). But the common situation is that 
nearly every country has its own version of these things, and they are far 
smaller than SNOMED. Now, SNOMED's version of things is usually better for some 
of that content, but in some cases, it is missing concepts.

The ability to easily create an empty SNOMED repo, fill it with national 
vocabularies, have it automatically generate non-clashing (i.e. with other 
countries, or the core) concept codes and mappings, and then serve it from a 
standard CTS2 (or other decent standard) terminology service would have 
revolutionised things in my view. This pathway has not been obviously available 
however, and has been a real blockage. The error was not understanding that the 
starting point for most countries isn't the international core, it's their own 
vocabularies.

The second killer feature would have been to make creating and managing 
ref-sets for data/form fields much easier, based on a subsetting language that 
can be applied to the core, and tools that implement that. Ways are needed to 
make the local / legacy vocabularies that have been imported, to look like a 
regular ref-set.

The third killer feature would have been to make translation tools work on the 
basis of legacy vocabulary and new ref-sets, not on the basis of the huge (but 
mostly unused) international core.

I think IHTSDO's / SNOMED International's emphasis has historically been on 
curating the core content, and making/buying tools to do that (the IHTSDO 
workbench, a tool that comes with its own PhD course), rather than promulgating 
SNOMED technology and tooling to enable the mess of real world content in each 
country to be rehoused in a standard way, and incrementally joined up by 
mapping or other means to the core. I think the latter would have been more 
helpful.

There is additionally an elephant in the room: IHTSDO (now SNOMED 
International) has been tied to a single terminology - SNOMED CT, but it would 
have been better to have had a terminology standards org that was independent 
of any particular terminology, and worked to create a truly 
terminology-independent technology ecosystem, along with technical means of 
connecting terminologies to each other, without particularly favouring any one 
of them. It's just a fact that the world has LOINC, ICDx, ICPC, ICF and 
hundreds of other terminologies that are not going anywhere. What would be 
useful would be to:

  *   classify them according to meta-model type - e.g. multi-hierarchy 
(Snomed); single hierarchy (ICDx, ICPC, 

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Tom,

I don’t see that your “first killer move” by separating SNOMED CT technology 
from content would make that much sense. The specification and technology you 
are describing in quite many sentences in your e-mail seems to be quite much 
like the EN 14463 Classification Markup Language (ClaML) specification and the 
ecosystem around that specification. However, that specification and the 
associated tools are not that well known or well used, so why would it be a 
“first killer move” to separate SNOMED CT technology from content? If it was a 
killer move someone had already created EN 14463 Association and competed out 
SNOMED CT and SNOMED International …

Instead it seems to be the collaboration and pooling of resources to create, 
extend and improve the common content in SNOMED CT that is possible to share 
among different countries that is the driving force for countries to join 
SNOMED International. The members would like to move away of the situation 
where each country spend large resources to create similar terminology products 
covering the same kind of clinical findings, anatomy, substances and much more. 
Instead they would like to focus on the things that are truly specific for each 
country. However, spending large resources to create similar things in each 
country doesn’t seem to be a problem in your argumentation, Tom?

Your “second killer feature” seems to be the existing SNOMED CT Expression 
Constraint Language - Specification and Guide (http://snomed.org/ecl) and the 
supporting tooling, or do you mean something else?

In your “third killer feature” I don’t really understand what you mean by that 
the translation tools should work on “the basis of legacy vocabulary”. But your 
second claim seems to be that it should be possible to use the tools to only 
translate parts of SNOMED CT and that is a function in all SNOMED CT 
translation tools I have heard of.

I don’t think that anyone would say that IHTSDO Workbench was a success, but 
more as a result of a few quite wrecked IT-projects made under various external 
less than optimal circumstances. To judge an organization’s will from the 
functions of the final IHTSDO Workbench, which you seem to do, is therefore 
quite unfair. (The IHTSDO Workbench was replaced with better adapted software 
quite quickly, so I think nowadays quite few people in the SNOMED International 
community remember the IHTSDO Workbench .)

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 13 mars 2018 15:21
To: openehr-technical@lists.openehr.org; For openEHR clinical discussions 
<openehr-clini...@lists.openehr.org>
Subject: Re: [Troll] Terminology bindings ... again




The killer move would be to do something I advocated for years unsuccessfully: 
separate SNOMED technology from content and allow them to be independently 
licensable and used. Here, technology means representation (RF2 for example), 
open source programming libraries for working with ref-sets, specs and implems 
for e..g the constraint language, URIs and so on.

It should be possible for a country (the one I am most familiar with w.r.t. to 
terminology today is Brazil) to create an empty 'SNOMED container' of its own, 
and put its existing terminologies in there - typically procedure lists, drug 
codes, lab codes, devices & prosthesis codes, packages (chargeable 
coarse-grained packages like childbirth that you get on a health plan) and so 
on. There are usually < 20k or even 10k such codes for most countries (UK and 
US would an exception), not counting lab analyte codes (but even there, 2000 or 
so codes would take care of most results). But the common situation is that 
nearly every country has its own version of these things, and they are far 
smaller than SNOMED. Now, SNOMED's version of things is usually better for some 
of that content, but in some cases, it is missing concepts.

The ability to easily create an empty SNOMED repo, fill it with national 
vocabularies, have it automatically generate non-clashing (i.e. with other 
countries, or the core) concept codes and mappings, and then serve it from a 
standard CTS2 (or other decent standard) terminology service would have 
revolutionised things in my view. This pathway has not been obviously available 
however, and has been a real blockage. The error was not understanding that the 
starting point for most countries isn't the international core, it's their own 
vocabularies.

The second killer feature would have been to make creating and managing 
ref-sets for data/form fields much easier, based on a subsetting language that 
can be applied to the core, and tools that implement that. Ways are needed to 
make the local / legacy vocabularies that have been imported, to look like a 
regular ref-set.

The third killer feature would have been to make translation tools work on the 
ba

RE: [Troll] Terminology bindings ... again

[Pablo Pazos]

But ICD is a statistical not a clinical tool.

On Mar 14, 2018 7:10 PM, "Mikael Nyström" <mikael.nyst...@liu.se> wrote:

> Hi,
>
>
>
> Of cause it is possible to create something that is easier to use. ICD-10
> is a good example of something that have similarities with SNOMED CT and is
> both (for some use cases) easier to implement and more widespread. But I if
> you want something that is based on logic, because you want to use logic
> functions when you use the system, it comes with the complexity of logic.
> And it is not that complex to implement SNOMED CT. The problem is probably
> that we have fewer trained people in health informatics (including in for
> example SNOMED CT and openEHR) that in other informatics areas.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Philippe Ameline
> *Sent:* den 13 mars 2018 13:32
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: [Troll] Terminology bindings ... again
>
>
>
> Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :
>
>
>
> I am get the impression that SNOMED CT is hard to implement, and therefore
> wondered if we are at some kind of tipping point, like where HL7v3 was a
> few years ago, and some bright spark came along, and now we have FHIR that
> is gaining great traction in the health community due to the ease at which
> it can be implemented.
>
>
> Hi John,
>
> The tipping point will only get reached when a sufficient amount of Snomed
> users will state that it is uselessly hard to implement... and when someone
> will invent a smart way to simplify it... not there yet ;-)
>
> But I really insist on the two orthogonal issues at stake:
> 1) a component should ease your job and not kill your project (detect
> "dead horses" early),
> 2) a component should not keep you stuck in the wrong (ancient) reference
> frame.
>
> No need to say that FHIR is easier to put at work than the plain RIM, but
> it still keeps its community in a system where "boxes that saw the patient
> passing by can exchange information" when we should (due to both the
> chronic turn and the information society era) be dedicated to organize
> multidisciplinary teamwork around patients.
>
> Best,
>
> Philippe
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi,

Of cause it is possible to create something that is easier to use. ICD-10 is a 
good example of something that have similarities with SNOMED CT and is both 
(for some use cases) easier to implement and more widespread. But I if you want 
something that is based on logic, because you want to use logic functions when 
you use the system, it comes with the complexity of logic. And it is not that 
complex to implement SNOMED CT. The problem is probably that we have fewer 
trained people in health informatics (including in for example SNOMED CT and 
openEHR) that in other informatics areas.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Philippe Ameline
Sent: den 13 mars 2018 13:32
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again


Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :

I am get the impression that SNOMED CT is hard to implement, and therefore 
wondered if we are at some kind of tipping point, like where HL7v3 was a few 
years ago, and some bright spark came along, and now we have FHIR that is 
gaining great traction in the health community due to the ease at which it can 
be implemented.

Hi John,

The tipping point will only get reached when a sufficient amount of Snomed 
users will state that it is uselessly hard to implement... and when someone 
will invent a smart way to simplify it... not there yet ;-)

But I really insist on the two orthogonal issues at stake:
1) a component should ease your job and not kill your project (detect "dead 
horses" early),
2) a component should not keep you stuck in the wrong (ancient) reference frame.

No need to say that FHIR is easier to put at work than the plain RIM, but it 
still keeps its community in a system where "boxes that saw the patient passing 
by can exchange information" when we should (due to both the chronic turn and 
the information society era) be dedicated to organize multidisciplinary 
teamwork around patients.

Best,

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

On 14/03/2018 14:57, Philippe Ameline wrote:

Le 14/03/2018 à 12:41, Thomas Beale a écrit :


so the long term solution is healthcare data and major services
(workflow / process) must eventually be part of a back-end system that
isn't owned by any product vendor or care delivery location, but
instead managed on behalf of the patient by a trusted third party.

Why do you believe that a third party is necessary/useful?

In my opinion, your (health) information is yours and you can manage it
yourself in a personal cloud or with a Ligne de vie.


well, IT-savvy people can do that. But realistically, everyone will pay 
a company to do that, and then you have to start thinking about what 
your contract with the company looks like. Do they respect GDPR? Do the 
implement privacy and security? Do they guarantee permanence? 
Performance? Availability? Record transfer to other countries, cloud 
storage etc? And so on. At the very least, the cloud-side data manger 
has to provide a running instance of openEHR, or Ligne-de-Vie or 
whatever. Will they keep it up to date? Whose implementation? Etc.


Some of these requirements can be provided by generic cloud storage 
companies, but many will require a dedicated e-health data manager kind 
of organisation. Now, if this is commercial and profit-oriented, with no 
proper governance or regulation, there are serious dangers (data being 
onsold to pharma and insurance companies, data loss and so on).


Then we have to consider the need for convenience. IN large socialised 
health systems - UK NHS, most EU countries, and any large US HMO (Kaiser 
Permanente etc) does it really make sense for each person to have to go 
shopping for a place to put your lifelong health record? So when you put 
all this together, a relatively small number of organisations that 
provide this service, in an ultra-reliable way will be needed. Doing it 
with cheap personal cloud will seem ok, until it is discovered that 
people are losing their passwords, forgot to pay the cloud provider 
bill, changed cloud provider but forgot to transfer their data and so 
on. Medical errors will result from that, so I don't see it as a viable 
path.

I would say: the term 'patient' just gets demoted to meaning a
client/supplier relationship that sporadically occurs between a person
in a health system, and the health system's healthcare provider
organisations.

OK. And the pivotal term here is "sporadically".

When switching from the (health) organization reference frame (still
cameras fixed on the walls) to the person's reference frame (head
mounted real time camera), you switch from a set of specialized sporadic
encounters to a life long holistic management (that includes sporadic
health related encounters). This is the reason why the term "patient" is
not consistent here.


theoretically that's true, but I don't think it's an important point 
because I think everyone knows that 'patient' stands for 'person, when 
obtaining healthcare'. I don't think the word 'patient' is going to 
disappear from the healthcare lexicon anytime soon...


- thomas

--
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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 14/03/2018 à 12:41, Thomas Beale a écrit :

> so the long term solution is healthcare data and major services
> (workflow / process) must eventually be part of a back-end system that
> isn't owned by any product vendor or care delivery location, but
> instead managed on behalf of the patient by a trusted third party.

Why do you believe that a third party is necessary/useful?

In my opinion, your (health) information is yours and you can manage it
yourself in a personal cloud or with a Ligne de vie.

>
> I would say: the term 'patient' just gets demoted to meaning a
> client/supplier relationship that sporadically occurs between a person
> in a health system, and the health system's healthcare provider
> organisations.

OK. And the pivotal term here is "sporadically".

When switching from the (health) organization reference frame (still
cameras fixed on the walls) to the person's reference frame (head
mounted real time camera), you switch from a set of specialized sporadic
encounters to a life long holistic management (that includes sporadic
health related encounters). This is the reason why the term "patient" is
not consistent here.

I always wonder what people have in mind when they write "patient
centered system". Maybe a head mounted camera that just capture still
images and operates inside care places only ;-)

Maybe just words, but when properly analyzed, they tell a lot about
cognitive dissonances.

Philippe


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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Le 14/03/2018 à 12:41, Thomas Beale a écrit :

> Translated in technological concepts, my own take is that is means
> switching:
>>
>> - from a record oriented vision to a project management vision (a
>> record is the place where you optimize your own decision support
>> ability through keeping the signal/noise ratio as high as possible ;
>> a project manager is the place where people build/feed/contribute to
>> a set of shared processes).
>>
>
> I don't quite agree here: because the 'record' (properly conceived) is
> the only thing that exists to chart the long-term situation of the
> patient, as doctors retire, nurses go on holidays, patients themselves
> move to new cities or countries. What can you trust to tell the story
> from your childhood asthma to your 2 pregnancies and births, to your
> hypertension and type 2 diabetes? Or even just your 10 year battle
> with one of the lesser cancers (very common) or lifelong management of
> a single disease. There is only the longitudinal health record.
>
> I agree though with the project management notion of course. Our
> recent work on Task Planning
> is
> trying to get up to this next level and join 'model' care pathways
> with real patient care plans and team-based care processes. It's going
> to take some years to get it really sorted out, but I think we are on
> the right path. I have seen the latest increment of the Activity-Based
> Design work at Intermountain Healthcare last week - we are converging.
>
> So when I say the 'EHR' I also include informational artefacts from
> long-running Planning and work processes, not just what we have today,
> which is observations, decisions, orders, and a record of actions done.

Tom, this question is pivotal and deserves a dedicated conference ;-)

When you ask "What can you trust to tell the story from your childhood
asthma to your 2 pregnancies and births, to your hypertension and type 2
diabetes?" what can of "record" are you thinking about?

Namely, in the practitioner reference frame, a record is the place where
you mention the smallest quantity of information that are "food for
thoughts". What I summed up as "optimizing the signal/noise ratio".
Hence a GP record doesn't look like a cardiologist record and is much
different from a nurse record.

In many countries (France included), governments made the assumption
that a "record of records" can be a "continuity of care record". I have
always claimed that it is a terrible idea since a record of records is a
place where the signal/noise ratio plummets. In France, the DMP
(initially Personal Health Record, now Shared Health Record since the
"P" switched from Personnel to Partagé) already failed several times
since its announcement in 2004. A new attempt will start in October.
From 10 years of interaction with practitioner about this "record of
records", I noticed that what they expect from it (for those who expect
something!) is always in the form "other will provide their information
sorted as I expect it"... no need to say that it is not what the word
"sharing" means ;-)
Pretty everywhere, the answer relies on magical thinking, à la
"automatic specialized views"... but the core issue is not addressed
(and even not really understood).

So far, we ends up with
- many siloed specialized records that only consist in instant
"viewpoint oriented" pictures (in the words of Koray "As a result the
patient information is all over the place in various formats"),
- the conclusion that pilling them up in the same "meta-record" will
deliver a mess of heterogeneous pictures and not the movie that could
tells your story.

The real issue is twofold:
- how to select information that "historically matter"? (you may
remember the words of Ed Hammond in Berlin (Eurorec 2002) saying that
"hospitals produce lots of information, a small part of it being of
historical matter, while family doctors produce little information that
are nearly 100% of historical matter"),
- how to have them "tell your (health) story"?

As an engineer, the proper attitude when a problem cannot be (smartly)
solved in a given reference frame is to try to find a different
reference frame where "things become simple(r)".

My take is that what is very hardly achievable in the organizations'
reference frame (typically Cartesian, with access rights as matrix, for
example - what I call "the boxes") becomes much more "natural" when
addressed in the person's reference frame (typically Polar with the team
"around" and access rights as Roses - what I call "the bubble").

Since I have been exploring this "reference frame shift" for nearly
twenty years (and will only launch the Ligne de vie this year), I can
say that what is at stake in the bubble is actually not a record, but
plainly a project manager (means the dual concept project + team) and
that "your history" is by far more accurately told this way than it
would be in any record.

As 

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

On 14/03/2018 11:10, Philippe Ameline wrote:


because the structures take care of all data points, not just coded 
ones. But your /fils guides/ are rather special - they do the same 
thing, unlike an ordinary grammar, so it's not really an argument. In 
fact I would say that today we could derive a computable 
transformation from the trees <=> ADL2 archetypes.


Yes... it just means adding the ADL concepts inside the ontology.


we have some concepts inside the archetypes themselves, and bindings to 
terminology. This is not as clean as your system, which has a very nice 
vocabulary included, whereas we chose (rightly or wrongly) to try to 
connect to Snomed, LOINC and all the other published terminologies out 
there.


- thomas

--
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