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 author cancer is not found.
>>> But any time in the future it might.
>>>
>>> 'No Cancer' as pre-coor

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


 I'm unclear why you call this a use of the closed world assumption: the
 entire openEHR framework is 

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
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>>
>>>
>>> 

Re: [Troll] Terminology bindings ... again

[GF]

I will get back to you after having read it.

Do you deal with the cascade of Tasks and Subtasks as if it is a fractal?

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Apr 2018, at 20:10, Thomas Beale  wrote:
> 
> 



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]

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.
This means that reasoners will be used to create transformations. It is likely 
that ontological servoces will be used, And then we will have a potential 
problem.
But perhaps solvable with the correct precautions.
One being that ontological servoces are NOT used and that ad hoc rules do the 
transform.
What possible solution is the canonical one? which is the ‘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.


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 mailto:gf...@luna.nl>> 
> 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 
>   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 mailto:gf...@luna.nl>> 
>> 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 ne

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

[Thomas Beale]

On 02/04/2018 18:45, GF wrote:

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


you may want to have a look at the Task Planning specification 
 for this.




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




- 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

[Pablo Pazos]

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
>> 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 <099%20043%20145>
> 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
>
>
>
> ___
> 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
pab

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

[Philippe Ameline]

Le 02/04/2018 à 14:30, Thomas Beale a écrit :

>
>
> 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;
>>>   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.
>
> 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 ontologies to detect
> errors. Unfortunately, we still don't have such ontologies in anything
> like the necessary detail - despite the existence of OGMS, and
> numerous specialist OBO ontologies. SNOMED CT doesn't come close to
> what is needed here. We still lack a comprehensive ontology covering
> all of general medicine.
>
> Secondly, the 'utterances' represented by archetypes are not intended
>

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
>> ontologies to detect errors. Unfortunately, we still 

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

[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
> ontologies to detect errors. Unfortunately, we still don't have such
> ontologies in anything like the necessary detail - despite the existence of
> OGMS, and numerous specialist OBO ontologies. SNOMED CT doesn't come close
> to what is needed here. We still 

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

[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;
  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.


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 ontologies to detect errors. Unfortunately, we 
still don't have such ontologies in anything like the necessary detail - 
despite the existence of OGMS, and numerous specialist OBO ontologies. 
SNOMED CT doesn't come close to what is needed here. We still lack a 
comprehensive ontology covering all of general medicine.


Secondly, the 'utterances' represented by archetypes are not intended to 
be directly linguistic expressions, but rather constitute an underlying 
structural /reference/ 'terminology'. The fils guides on the other hand 
express natural language utterances, i.e. they are like a structural 
/interfac

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
>> mailto:philippe.amel...@free.fr>> 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 mailto:gf...@luna.nl>> 
> 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
http://lists.openehr.org/mailman/listinfo/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