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: [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: [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: [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: [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]

Sorry, I am reading on my phone and it seems I missed an email. I read
further day after tomorrow when I have a descent email client.

Best regards
Bert

Op za 31 mrt. 2018 13:06 schreef A Verhees :

> Okay. Do you have a technical description of what you are talking about?
>
> Thanks
> Bert
>
> Op za 31 mrt. 2018 12:31 schreef GF :
>
>> In my opinion there is something essential missing, so far.
>>
> What is missing is a collection of standard Cluster archetypes/Patterns
>> that can be used to create any story, describing the
>> observation/evaluation/planning/ordering and action processes including all
>> the possible contexts.
>> All the Archetype Patterns create one Documentation ontology.
>>
>> That Documentation ontology as grammar combined with a terminology like
>> SNOMED and LOINC looks like Phillipe's system.
>>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 31 Mar 2018, at 11:38, Philippe Ameline 
>> wrote:
>>
>> Diego,
>>
>> IMHO your contribution is orthogonal to what Thomas very accurately
>> explained. Building subset is a symptom of the issue, not a solution.
>>
>> As I tried to explain in my initial post, we are currently facing two
>> generation of technologies in medicine:
>> - systems that record information as trees of atomic concepts, in the
>> same way we are all exchanging in "globish" by inserting English concepts
>> in a grammatical structure,
>> - systems that still rely on a fixed database schema and usually have a
>> "discourse system" limited to field/value pairs.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 

Re: [Troll] Terminology bindings ... again

[A Verhees]

Okay. Do you have a technical description of what you are talking about?

Thanks
Bert

Op za 31 mrt. 2018 12:31 schreef GF :

> In my opinion there is something essential missing, so far.
> What is missing is a collection of standard Cluster archetypes/Patterns
> that can be used to create any story, describing the
> observation/evaluation/planning/ordering and action processes including all
> the possible contexts.
> All the Archetype Patterns create one Documentation ontology.
>
> That Documentation ontology as grammar combined with a terminology like
> SNOMED and LOINC looks like Phillipe's system.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 31 Mar 2018, at 11:38, Philippe Ameline 
> wrote:
>
> Diego,
>
> IMHO your contribution is orthogonal to what Thomas very accurately
> explained. Building subset is a symptom of the issue, not a solution.
>
> As I tried to explain in my initial post, we are currently facing two
> generation of technologies in medicine:
> - systems that record information as trees of atomic concepts, in the same
> way we are all exchanging in "globish" by inserting English concepts in a
> grammatical structure,
> - systems that still rely on a fixed database schema and usually have a
> "discourse system" limited to field/value pairs.
>
> 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.
>
> 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.
>
> 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.
>
> 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 <

Re: [Troll] Terminology bindings ... again

[GF]

In my opinion there is something essential missing, so far.
What is missing is a collection of standard Cluster archetypes/Patterns that 
can be used to create any story, describing the 
observation/evaluation/planning/ordering and action processes including all the 
possible contexts.
All the Archetype Patterns create one Documentation ontology.

That Documentation ontology as grammar combined with a terminology like SNOMED 
and LOINC looks like Phillipe's system.


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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 31 Mar 2018, at 11:38, Philippe Ameline  wrote:
> 
> Diego,
> 
> IMHO your contribution is orthogonal to what Thomas very accurately 
> explained. Building subset is a symptom of the issue, not a solution.
> 
> As I tried to explain in my initial post, we are currently facing two 
> generation of technologies in medicine:
> - systems that record information as trees of atomic concepts, in the same 
> way we are all exchanging in "globish" by inserting English concepts in a 
> grammatical structure,
> - systems that still rely on a fixed database schema and usually have a 
> "discourse system" limited to field/value pairs.
> 
> 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.
> 
> 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.
> 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.
> 
> 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 
>> > >:
>> I read Thomas’ reply 

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: [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: [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 
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
>> On 22 Mar 2018, at 00:46, Heather Leslie
>> > > 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
>> > > *On Behalf
>> Of *Mikael Nyström
>> *Sent:* Thursday, 22 March 2018 1:00 AM
>> *To:* For openEHR technical discussions
>> > >
>> *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. 

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 


*Verzonden: *maandag 26 maart 2018 08:26
*Aan: *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 

To: For openEHR technical discussions



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

Message-ID:



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 :

> 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 

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

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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


Bert,

The main reason I mentioned the [Troll] hashtag was because I am 
really conscious that what I say is far from being mainstream. Hence I 
consider myself honored that some of the things I say can "rock the 
boat" a little bit and raise several questions.


To tell it roughly, I consider that practitioners are missing two 
crucial turns: they are disconnected from the information society (for 
several reasons, medical confidentiality of course, but also because 
MD keep seeing information systems as "back office" components, also 
because they are often individualists very at ease in silos (practice 
and specialty)) and they are still fully organized for acute care (to 
put it simply, the medical system is fully upside down and the GP 
should become an orchestra conductor (what she often dreams she 
already is) but is stuck in the one-man band role).




that is exactly right, and I think there is still a revolution that must 
come to get the GP out of the solo 'cabinet mental' and indeed be some 
sort of a) team player at the practice level and b) orchestrator of care 
- in terms of managing referrals and the outcomes, post-care etc. But 
that is not our business, the healthcare profession needs to work this 
one out.


It could make sense to consider that the first lock (the dead branch 
of the information society flow) controls the second lock (missing the 
chronic care turn). This for many reasons:

- chronic care means managing risk over a long span of time,
- chronic care means genuine team work around a given person (not the 
fixed team "inside the same box" but the dynamic team of the 
contributors around a given individual).


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.


- from a "care places centered" system (the patient moves from silo to 
silo, from record to record) to a system "federated by the person" 
environment. To put it simply, it is a genuine Copernican revolution 
where individual, instead of having siloed information stored about 
themselves in every "box" they cross, would own a system in support of 
their life long holistic vision and ask their services providers to 
contribute to it (means to join a team).




I think this revolution is starting. Now it is becoming clearer to the 
industry what has been obvious to us - that no single provider creates 
all the data that relate to the patient, 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.


A colleague many of you will know, Amnon Shvo, from Haifa, has been 
going on about the 'EHR Bank' for at least a decade now. I remember 
saying to him 10 or 12 years ago, this is the right idea, but the 
industry won't accept it. But now I think it's becoming clear that the 
industry is going to have to accept it, and those vendors who don't want 
to will be relegated to the outer reaches.


The most important point to consider here is that, when considering 
the person's bubble, it is really mandatory to be plainly holistic, 
that's to say to consider health as a project among many other 
projects (education, employment, social issues, ordinary 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

>
>>
>> Such concept is described in a (already) 10 years old document
>> (http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf).
>
> yes this is an excellent document - it even has the distinction
> between archetypes and (what we call) templates - the heading
> 'Federating heterogeneous information'.

I was fed at the proper source ;-)

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

[Karsten Hilbert]

On Wed, Mar 14, 2018 at 11:28:28AM +0100, Philippe Ameline wrote:

> because MD
> keep seeing information systems as "back office" components, also
> because they are often individualists very at ease in silos (practice
> and specialty))

Practitioners need to be able to control their space for, at
a minimum, liability concerns, which are brought about by the
amount of implicit trust that is put forword towards them
(and then happily withdrawn at the slightest chance of
litigation).  It is only natural that most MDs will resist
"change for no good reason" and be *very* conservative.

> and they are still fully organized for acute care (to
> put it simply, the medical system is fully upside down and the GP should
> become an orchestra conductor (what she often dreams she already is) but
> is stuck in the one-man band role).

~70% of _all_ reasons for encounter are fully solvable inside
the GP "domain". But that goes counter to what most patients
want and believe they need. Which is the biggest obstacle for
primary care based healthcare. At least in Germany.

"Chronic care" is nothing new, it has been the
mainstay of General Practice for, what, centuries ?

(not that any noticeable number of IT solutions had fostered
that approach so far)

> the dynamic team of the
> contributors around a given individual).

That, of course, is a vision in need of better application.

> The most important point to consider here is that, when considering the
> person's bubble, it is really mandatory to be plainly holistic, that's
> to say to consider health as a project among many other projects
> (education, employment, social issues, ordinary life projects, etc). It
> is a place where the term "patient" is prohibited.

If we remove the term "patient" we will remove the very last
trace of what it means to fall ill - to endure, with the
necessary patience. Only "clients" remain, believing that
healthcare can work like a business process, getting
themselves repaired as needed.

While I fully support the process of informed shared decision
making, and embrace it to the extent possible, 15 years of
daily face-to-face encounters with literally many thousands of
patients painfully teaches that the majority is not currently
able to take matters into their own hands AND live with the
consequences.

So, yes, let's build systems to be open and to enable
caretakers and caregivers, but let's not expect those systems
to be used that way by the great majority.

Karsten

(speaking from a German healthcare perspective only)
-- 
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

[Philippe Ameline]

Bert,

The main reason I mentioned the [Troll] hashtag was because I am really
conscious that what I say is far from being mainstream. Hence I consider
myself honored that some of the things I say can "rock the boat" a
little bit and raise several questions.

To tell it roughly, I consider that practitioners are missing two
crucial turns: they are disconnected from the information society (for
several reasons, medical confidentiality of course, but also because MD
keep seeing information systems as "back office" components, also
because they are often individualists very at ease in silos (practice
and specialty)) and they are still fully organized for acute care (to
put it simply, the medical system is fully upside down and the GP should
become an orchestra conductor (what she often dreams she already is) but
is stuck in the one-man band role).

It could make sense to consider that the first lock (the dead branch of
the information society flow) controls the second lock (missing the
chronic care turn). This for many reasons:
- chronic care means managing risk over a long span of time,
- chronic care means genuine team work around a given person (not the
fixed team "inside the same box" but the dynamic team of the
contributors around a given individual).

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).
- from a "care places centered" system (the patient moves from silo to
silo, from record to record) to a system "federated by the person"
environment. To put it simply, it is a genuine Copernican revolution
where individual, instead of having siloed information stored about
themselves in every "box" they cross, would own a system in support of
their life long holistic vision and ask their services providers to
contribute to it (means to join a team).

The most important point to consider here is that, when considering the
person's bubble, it is really mandatory to be plainly holistic, that's
to say to consider health as a project among many other projects
(education, employment, social issues, ordinary life projects, etc). It
is a place where the term "patient" is prohibited.

Finally, to answer your question about "HL7 and Snomed", I see these two
components as symptoms of the "medical information plague": they are
fully endemic, they are over-complex and prevent innovation (once you
have invested 5 years understanding it, your startup is already dead).
To make it short, as some claim that maize killed the Maya civilization
because it demanded too much energy to grow, I claim that these systems
are killing health systems because they keep them stuck in an ancient
vision of health.

Feel very free to consider this assertion as coming from the edge.
Besides, even if I know HL7 and Snomed rather well, I perfectly may miss
some points... however, I really hope that, contrary to what you wrote,
they are not "the technology for the coming decades" ;-)

Best,

Philippe


Le 14/03/2018 à 01:16, A Verhees a écrit :
> Philippe, I don't understand why you ask about HL7 and SNOMED in the
> same question, they have nothing in common and have a complete other
> purpose, nor are they depending on each other. I have no opinion about
> HL7, which version, which of the many substandards? It is a too large
> subject for a simple question.
>
> I do have opinions about SNOMED and I agree it does not offer a
> complete grammar like a natural language does, so to tell a story will
> be hard in SNOMED-terms. Do we need that? As far as I can see it can
> describe every medical condition, and if it cannot, there is room for
> several ways of extending it.
>
> I am sure we have not yet explored all that is possible with SNOMED.
> It is the technology for the coming decades. 
>
> Allthough it is hard to get traditional software-vendors to implement
> SNOMED, it cost money, especially in traditional software architecture
> this is expensive, allthough there are reasonable roadmaps described.
> But that is okay, let them sleep.
>
> In OpenEhr it is an easier start to adapt it in archetypes. Further
> steps, I think, are a SNOMED query-service against a SNOMED
> terminology service, combining queries in archetype-repositories, and
> in data and this way find data in a intelligent way.
>
> There are usability paradigm shifts coming, clinical software being
> used by non-medical educated people, software for small purposes like
> apps, software being used by machines, flexibility is needed, and
> storing and querying and understanding clinical data for the very long
> term.
>
> As far as I can see we have the most technologies/tools to support
> these new purposes. Now we need the developers to use it. I see a rich
> 

Re: [Troll] Terminology bindings ... again

[A Verhees]

Philippe, I don't understand why you ask about HL7 and SNOMED in the same
question, they have nothing in common and have a complete other purpose,
nor are they depending on each other. I have no opinion about HL7, which
version, which of the many substandards? It is a too large subject for a
simple question.

I do have opinions about SNOMED and I agree it does not offer a complete
grammar like a natural language does, so to tell a story will be hard in
SNOMED-terms. Do we need that? As far as I can see it can describe every
medical condition, and if it cannot, there is room for several ways of
extending it.

I am sure we have not yet explored all that is possible with SNOMED. It is
the technology for the coming decades.

Allthough it is hard to get traditional software-vendors to implement
SNOMED, it cost money, especially in traditional software architecture this
is expensive, allthough there are reasonable roadmaps described.
But that is okay, let them sleep.

In OpenEhr it is an easier start to adapt it in archetypes. Further steps,
I think, are a SNOMED query-service against a SNOMED terminology service,
combining queries in archetype-repositories, and in data and this way find
data in a intelligent way.

There are usability paradigm shifts coming, clinical software being used by
non-medical educated people, software for small purposes like apps,
software being used by machines, flexibility is needed, and storing and
querying and understanding clinical data for the very long term.

As far as I can see we have the most technologies/tools to support these
new purposes. Now we need the developers to use it. I see a rich future for
software development.

Best regards
Bert

Op 13 mrt. 2018 21:55 schreef "Philippe Ameline" :

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

[Thomas Beale]

On 13/03/2018 21:25, Philippe Ameline wrote:



  * So the question is: if we have formal models of the structured
form such as archetypes (maybe even FHIR profiles), why bother
with the grammar strings?




This is a pivotal question, but you may remember that I am used to 
putting it the other way around: if you can tell something using a 
vocabulary and a grammar, why bother having a formal model of 
structured forms? ;-)


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.




Such concept is described in a (already) 10 years old document 
(http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf).


yes this is an excellent document - it even has the distinction between 
archetypes and (what we call) templates - the heading 'Federating 
heterogeneous information'.


- thomas

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

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

[Pablo Pazos]

I got it, when I said standardizing diagnosis you might thought of your
specific implementation / experience. But I was talking about the strategy,
not the implementation.

The strategy can be good and implementations fail miserably, is not a
problem of the strategy :)

As I said, primary coding is the worst way of implementing this, should not
be recommended by any literature, and software vendors / organizations /
govt imposing that should be held responsible for bad implementations.

On Tue, Mar 13, 2018 at 6:45 PM, Karsten Hilbert 
wrote:

>  There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>  But I'm not sure if Karsten was talking about this, let's wait :)
>
>
>
>
> I was mainly talking about the first, which is standard in German
> ambulatory care.
>
> Karsten
>
> ___
> 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

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

[Karsten Hilbert]

 There are 3 ways of "coding" that I know of: 1. primary coding (ask clinicians 
and other clinical users to code directly), 2. secondary coding (users record 
information, a team of specialists do the coding later), 3. assisted coding 
(software helps users to code, and there are many ways of doing this, from NLP 
to GUI wizards).
 But I'm not sure if Karsten was talking about this, let's wait :)




I was mainly talking about the first, which is standard in German ambulatory 
care.
 
Karsten

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

>   * So the question is: if we have formal models of the structured
> form such as archetypes (maybe even FHIR profiles), why bother
> with the grammar strings?
>
>

This is a pivotal question, but you may remember that I am used to
putting it the other way around: if you can tell something using a
vocabulary and a grammar, why bother having a formal model of structured
forms? ;-)

Such concept is described in a (already) 10 years old document
(http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf).

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

[Pablo Pazos]

There are many implementation solutions for primary, assisted and secondary
coding.

In assisted coding what you mention is one way.

The best solution IMO that I saw implemented is free text search, matching
to an interface terminology that internally maps to SNOMED. The interface
terminology is controlled, and based on real terms gathered from users, so
this methodology adapts to the location and usage. And what the wizard
provides are alternative and suggested terms from the interface
terminology. Everything is a tree here but no tree is shown to the end
user, they just see free text suggestions for his/her input. A team of
experts maintains the interface terminology and mappings to SNOMED.
Mappings to other terminologies can be done, for instance with LOINC, or
even ICD for statistics.

This is the approach of a health provider in Argentina and is the way the
national EHR strategy is being implemented in Uruguay. I think Chile will
also follow those steps.

On Tue, Mar 13, 2018 at 3:55 PM, Thomas Beale 
wrote:

> I would put it the other way around: it can only be done with structured,
> controlled subsets, that retain hierarchy from the original terminology,
> remove unneeded codes, and do a few other tricks (adding non-coding 'group'
> concepts to help guide the user). This has to be done using smart tree
> controls, or anything that logically works as a tree-based choosing tool.
>
> No flat lists ;)
>
> - thomas
>
> On 13/03/2018 18:33, Pablo Pazos wrote:
>
> It is a very very very bad practice to ask clinicians to code!
>
> Standardizing diagnosis is a very different thing than asking clinicians
> to code, the first is the strategy, the second is one possible, and bad,
> implementation.
>
> There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>
> But I'm not sure if Karsten was talking about this, let's wait :)
>
>
> --
> 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
>



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

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

[Karsten Hilbert]

>>> just imagine standardizing every diagnosis
>> That typically leads to either bad statistics or disimproved care.
> Can I ask why?

It of course depends on the suitability of the standardization process (as in
the applicability of a coding system to the domain - medically and in purpose).

It is a problem of up-/downcoding.

Standardizing typically needs classifying, the classes of which are either to 
fine-grained (doctors will pick a
diagnoses which seems somewhat similar to what they think it might be, thereby 
falsifying the apparent accuracy
of statistics based on the coding system), or too coarse (the picked diagnosis 
will be overly broad, thusly not
reflecting reality "enough").

I guess what I am saying is that one cannot expect to "just standardize" 
diagnoses and
hope to meaningfully draw conclusions from that post hoc. The standardization 
process
needs to be tied to the question that is going to be asked of the standardized 
data.

Karsten

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

I would put it the other way around: it can only be done with 
structured, controlled subsets, that retain hierarchy from the original 
terminology, remove unneeded codes, and do a few other tricks (adding 
non-coding 'group' concepts to help guide the user). This has to be done 
using smart tree controls, or anything that logically works as a 
tree-based choosing tool.


No flat lists ;)

- thomas


On 13/03/2018 18:33, Pablo Pazos wrote:

It is a very very very bad practice to ask clinicians to code!

Standardizing diagnosis is a very different thing than asking 
clinicians to code, the first is the strategy, the second is one 
possible, and bad, implementation.


There are 3 ways of "coding" that I know of: 1. primary coding (ask 
clinicians and other clinical users to code directly), 2. secondary 
coding (users record information, a team of specialists do the coding 
later), 3. assisted coding (software helps users to code, and there 
are many ways of doing this, from NLP to GUI wizards).


But I'm not sure if Karsten was talking about this, let's wait :)


--
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: Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

It is a very very very bad practice to ask clinicians to code!

Standardizing diagnosis is a very different thing than asking clinicians to
code, the first is the strategy, the second is one possible, and bad,
implementation.

There are 3 ways of "coding" that I know of: 1. primary coding (ask
clinicians and other clinical users to code directly), 2. secondary coding
(users record information, a team of specialists do the coding later), 3.
assisted coding (software helps users to code, and there are many ways of
doing this, from NLP to GUI wizards).

But I'm not sure if Karsten was talking about this, let's wait :)


On Tue, Mar 13, 2018 at 3:25 PM, Diego Boscá  wrote:

> I assume the reason is that asking clinicians to do coding without any
> help provides great variability and leads to coding errors. What Thomas
> said about presenting clinicians with addecuated subsets is key to avoid
> that. There are also mechanisms to check coding quality/errors, but usually
> need high domain & terminology knowledge (but creating systems that 'learn'
> from documentalists' knowledge is feasible)
>
> El mar., 13 mar. 2018 19:03, Pablo Pazos 
> escribió:
>
>>
>>
>> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert > > wrote:
>>
>>> > just imagine standardizing every diagnosis
>>>
>>> That typically leads to either bad statistics or disimproved care.
>>>
>>
>> Can I ask why?
>>
>>
>>>
>>> Karsten
>>>
>>> ___
>>> 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
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: Re: [Troll] Terminology bindings ... again

[Diego Boscá]

I assume the reason is that asking clinicians to do coding without any help
provides great variability and leads to coding errors. What Thomas said
about presenting clinicians with addecuated subsets is key to avoid that.
There are also mechanisms to check coding quality/errors, but usually need
high domain & terminology knowledge (but creating systems that 'learn' from
documentalists' knowledge is feasible)

El mar., 13 mar. 2018 19:03, Pablo Pazos 
escribió:

>
>
> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert 
> wrote:
>
>> > just imagine standardizing every diagnosis
>>
>> That typically leads to either bad statistics or disimproved care.
>>
>
> Can I ask why?
>
>
>>
>> Karsten
>>
>> ___
>> 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
___
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 13/03/2018 16:45, Philippe Ameline wrote:


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




well, it would be very helpful if anyone had the right to use 'SNOMED 
technology', to create their own terminology content (mainly by 
importing legacy vocabularies). Now, that's not ideal of course, but in 
reality, that is the starting point for nearly all countries - outside 
of the UK and some locations in the US, I don't know of a country that 
makes any extensive use of the international core (I am talking 
operational, not research use of course). That can change in time, but 
it's not how it is today.


So the core SNOMED CT terminology needs to be licenced separately, as 
one thing that can co-exist in a SNOMED-technology container (now it 
starts being obvious why even the naming is problematic - it would be 
better to have an 'IHTSDO technology stack', which could accept SNOMED 
CT, ICDx, LOINC, UCUM, and anything else. With smart tricks to do with 
mapping and concept code generation to create partitions (which SNOMED 
codes already have - it's a good system), you can create order from the 
chaos. But the starting point is the chaos, not the order, as some 
people seem to think.


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




you can do the equivalent of agglutination these days - 
post-coordination - for which there is a grammar, but this brings its 
own challenges, and I have yet to see anything but the simplest 
post-coordinations (e.g. laterality) in real use (but to be fair, 5 or 
so simple post-coordinations would solve many, many real use case 
situations). Formally, the post-coordination idea is quite nice, but the 
real-world tension and main reason it may never work outside the basic 
cases (laterality etc) - actually there are two, as follows:


 * *data in a real data set is not all coded* - only some items are -
   these are mixed in with plain text, quantities, numbers, ordinals,
   dates, times, durations and various URI / multimedia like things
 * *data is conveniently collected and displayed in pieces* (i.e.
   'shredded' form), not as a grammar string; these pieces may be mixed
   up with other non-coded data types. So the question is: if we have
   formal models of the structured form such as archetypes (maybe even
   FHIR profiles), why bother with the grammar strings?

Inspection of any archetype, e.g. pregnancy summary will show this to be 
true, but in fact, you can just look at almost any screen form in almost 
any EMR product to see the same thing. The world just isn't all coded, 
often not even mainly coded.


LOINC comes with a 6-axis meta-model, so it is an automatically 
aggluinating terminology as well.



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.




well filling slots in forms is useful, especially for fields like 
'diagnosis'... but it can only fill some slots - the coded/codable ones. 
Its real promise would be to support a) high-quality structured ref-sets 
(not flat vocabularies) and b) reasoning-based inferencing. I think 
these things will eventually come to pass, but they really should be 
done in a meta-model that makes them work for ICDx, LOINC, RxNorm, ICF, 
ICPC, and anything else, not just SNOMED CT.


- thomas

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

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

[Pablo Pazos]

On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert 
wrote:

> > just imagine standardizing every diagnosis
>
> That typically leads to either bad statistics or disimproved care.
>

Can I ask why?


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

[Pablo Pazos]

" 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 
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, ... ); multi-axial (LOINC); units
>(UCUM, ...), etc
>- build / integrate technology for each major category - I would guess
>< 10
>- help the owning orgs slowly migrate their terminologies to the
>appropriate representation and tools
>- embark on an exercise to graft in appropriate upper level
>ontology/ies, i.e. BFO2, RO, and related ontologies (this is where the <10
>comes from by the way)
>- specify 

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

[Karsten Hilbert]

> just imagine standardizing every diagnosis

That typically leads to either bad statistics or disimproved care.

Karsten

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




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

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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, ... ); multi-axial (LOINC);
   units (UCUM, ...), etc
 * build / integrate technology for each major category - I would guess
   < 10
 * help the owning orgs slowly migrate their terminologies to the
   appropriate representation and tools
 * embark on an exercise to graft in appropriate upper level
   ontology/ies, i.e. BFO2, RO, and related ontologies (this is where
   the <10 comes from by the way)
 * specify standards for URIs, querying, ref-sets that /work across all
   terminologies/, not just SNOMED CT

A further program would look at integrating units (but not by the 
current method of importing to SNOMED, which is a complete error because 
of the different meta-models), drugs and substances (same story), lab 
result normal and other range data, and so on. None of this can be done 
without properly studying and developing the underlying ontologies, 
which are generally small, but subtle.


I'll stop there for now. I suspect I have kicked the hornet's nest, but 
since Grahame kicked it first, and I can run faster than him, I feel 
oddly safe. Probably an illusion.


- thomas

On 13/03/2018 12:12, Grahame Grieve wrote:


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.

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Hi,

IMO having s national terminology server like we have in Uruguay, is a
first step of delivering. jus imagine standardizing every diagnosis, every
procedure and every drug around the country? I can only see benefits for
clinical environments and public health, they will have data to actually
see what's happening in a complex system. also this is part of a state
strategy for health accessibility.

BTW, we don't have tons of money, so even if some tactical areas fail, is
the investment of learning. But we are learning from institutions that
already did this and using their experience, this  not an isolated journey
reinventing the wheel.

There are 3 questions to make when your are starting: 1. Is there any use
of SNOMED in my ehealth strategy? 2. Is there an alternative? 3. What's the
cost of SNOMED vs. the alternative?

I'm an engineer and just recently I was understood the real value of SNOMED
sheet using it for data querying. Without getting your hand dirty a little
bit is difficult to know for sure what are the pros and cons. Obviously
this is not a panacea and needs a lot of work to implement and maintain.
ROI is long term as in everything in ehealth (like implementing openEHR!)

best,
Pablo

On Mar 13, 2018 6:20 AM, "Philippe Ameline" 
wrote:

> Pablo, I wish you sincerely all the best.
>
> IMHO, the question is not really to enroll but to deliver... and
> considering the tremendous amount of money that was invested in HL7 and
> Snomed (both to elaborate and try to implement) and the actual societal
> return, there is such a discrepancy that the hypothesis that, due to
> missing the "information society" turn, health systems are entering
> terrible crisis times is to be considered seriously.
>
> In current "information society", you have two options when considering
> "health information systems":
> 1) You dedicate yourself to "medical information systems" instead, and can
> freely build for (inter-connected) silos,
> 2) You consider "health" in its genuine meaning and you have to realize
> that it is a complex domain fully opened to all other societal issues...
> hence should ban components that are endemic to medicine.
>
> Maybe (and I really mean it for Latin America), it should be high time to
> leapfrog, not to join the "dollars wasting club" ;-)
>
> Philippe
>
> Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
>
> In Latin America is all the contrary, more countries are becoming SNOMED
> members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline <
> philippe.amel...@free.fr> wrote:
>
>> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>>
>> > IMO we should focus on SNOMED.
>>
>> Hi,
>>
>> There is currently some kind of interesting momentum against Snomed.
>>
>> It can come from governments that refuse to pay for it (current mood in
>> France), of from practitioners who, after having been asked by their gov
>> to "sort out their Snomed subset" came to the conclusion that it doesn't
>> exist.
>>
>> Some also predict that the most certain result of keeping up
>> trying to build systems using such shitty fully endemic components is to
>> have medical doctors disappear from missing the "information society"
>> turn.
>>
>> Have some of you been aware of the Meriterm (European) project?
>>
>> Best,
>>
>> Philippe
>>
>>
>> ___
>> 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 
> listopenEHR-technical@lists.openehr.orghttp://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

[Philippe Ameline]

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

[Grahame Grieve]

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

this is very true, and I wish that someone would stick their neck out and
do this at scale with
a community behind them. Many of the parameters for how it could be done
are obvious around
free and crowd-support etc. But the big problem is that there is no
capacity for it to happen as a
palace revolution; it must be a full civil war first.

Grahame
___
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 13/03/2018 10:56, Philippe Ameline wrote:


Grahame,

What you state is plainly valid, and the "it exists" argument is not 
to be considered lightly.


However, as an engineer and a developer, I always try to measure the 
payload of a component when I consider using it. Where does it fit in 
the "pair of wings" to "dead horse" range?




I think you have just created the new technological utility scale!

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

[GEORGE, John (NHS DIGITAL)]

Hi Phillipe and Graham,

This may help your discussion:

https://www.snomedinaction.org

Unfortunately, it only gives a high level view of where SNOMED CT is used, for 
example, if you look at the map, it mentions, “Leeds Teaching Hospitals decided 
to embrace SNOMED CT in their Emergency Department”.   However, I wonder, why 
the many other departments in that hospital are not using SNOMED CT too?  I 
would really like to know where the true successful implementations of SNOMED 
CT are?  Where I mean an implementation, I don’t mean for example a just a 
mapping from one terminology to another, like mapping READ codes to SNOMED CT, 
but also using the post coordination functionality of SNOMED, and making full 
use of the hierarchical structure of SNOMED CT.

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.


Regards
John

John George
Technical Modeller
Interoperability and Architecture/ Paperless 2020
john.geo...@nhs.net<mailto:john.geo...@nhs.net>
0113 397 4193 | 07770 408306


[cid:image001.png@01D3BABF.007FED20]

NHS Digital provides information and technology for better health and care.
Find out more about us: www.digital.nhs.uk<http://www.digital.nhs.uk/> | 
@nhsdigital<https://twitter.com/nhsdigital>












From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> On Behalf 
Of Philippe Ameline
Sent: 13 March 2018 10:57
To: openehr-technical@lists.openehr.org
Subject: Re: [Troll] Terminology bindings ... again


Grahame,

What you state is plainly valid, and the "it exists" argument is not to be 
considered lightly.

However, as an engineer and a developer, I always try to measure the payload of 
a component when I consider using it. Where does it fit in the "pair of wings" 
to "dead horse" range?
IMHO, HL7 and Snomed are not on the right side and adopting such components is 
like drilling in concrete: it never becomes easier.

When it is about considering costs, I can argue that something that is "not 
well born" will cost considerably more than necessary during its entire life 
span. Any such technique is hard to build, hard to integrate and hard to 
maintain. As a guy that built and operate a self made 54000 atomic terms 
ontology, I can tell you that addressing this issue in the proper way can save 
considerable amount of money and (this is the most important part of it) free 
considerable energy that can be invested in reinventing health instead of 
plaguing practitioners with new burdens.

My aim with this "troll" was just to tell that this kind of questioning exists 
and also that some "fools" are currently joining to create what they think 
could be "well born components".

I have the feeling that it is high time we "leapfrog" in being able to 
"organize the journey" from the patient's "bio-psycho-social bubble" instead of 
getting dedicated to "siloed care center boxes"... and that HL7 and Snomed will 
keep their users in the wrong reference frame.

Time will tell... but interesting times ahead!

Philippe

Le 13/03/2018 à 11:05, Grahame Grieve a écrit :
hi Philippe

No one who's actually tried to use Snomed CT could think that in it's current 
form it's the answer to everything.
But anyone who's tried to work on real terminologies must also be aware of just 
how much work is involved in these things.

So there's very much a glass half full/empty thing here. I understand not being 
thrilled with Snomed CT as a choice, but as the french government, for 
instance, actually confronted how much more it will cost to do something else?

There's more than one kind of club to have that wastes money

I've had a quick look at Meriterm... like all good rdf, it's not easily 
penetrable. But it looks like the authors are not informed about Cimino's 
desiderata... which brings us back to the wasting money thing...

Grahame



On Tue, Mar 13, 2018 at 8:19 PM, Philippe Ameline 
<philippe.amel...@free.fr<mailto:philippe.amel...@free.fr>> wrote:

Pablo, I wish you sincerely all the best.

IMHO, the question is not really to enroll but to deliver... and considering 
the tremendous amount of money that was invested in HL7 and Snomed (both to 
elaborate and try to implement) and the actual societal return, there is such a 
discrepancy that the hypothesis that, due to missing the "information society" 
turn, health systems are entering terrible crisis times is to be considered 
seriously.

In current "information society", you have two options when considering "health 
information systems":
1) You dedicate yourself to "medical information s

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Grahame,

What you state is plainly valid, and the "it exists" argument is not to
be considered lightly.

However, as an engineer and a developer, I always try to measure the
payload of a component when I consider using it. Where does it fit in
the "pair of wings" to "dead horse" range?
IMHO, HL7 and Snomed are not on the right side and adopting such
components is like drilling in concrete: it never becomes easier.

When it is about considering costs, I can argue that something that is
"not well born" will cost considerably more than necessary during its
entire life span. Any such technique is hard to build, hard to integrate
and hard to maintain. As a guy that built and operate a self made 54000
atomic terms ontology, I can tell you that addressing this issue in the
proper way can save considerable amount of money and (this is the most
important part of it) free considerable energy that can be invested in
reinventing health instead of plaguing practitioners with new burdens.

My aim with this "troll" was just to tell that this kind of questioning
exists and also that some "fools" are currently joining to create what
they think could be "well born components".

I have the feeling that it is high time we "leapfrog" in being able to
"organize the journey" from the patient's "bio-psycho-social bubble"
instead of getting dedicated to "siloed care center boxes"... and that
HL7 and Snomed will keep their users in the wrong reference frame.

Time will tell... but interesting times ahead!

Philippe


Le 13/03/2018 à 11:05, Grahame Grieve a écrit :
> hi Philippe
>
> No one who's actually tried to use Snomed CT could think that in it's
> current form it's the answer to everything.
> But anyone who's tried to work on real terminologies must also be
> aware of just how much work is involved in these things.
>
> So there's very much a glass half full/empty thing here. I understand
> not being thrilled with Snomed CT as a choice, but as the french
> government, for instance, actually confronted how much more it will
> cost to do something else? 
>
> There's more than one kind of club to have that wastes money
>
> I've had a quick look at Meriterm... like all good rdf, it's not
> easily penetrable. But it looks like the authors are not informed
> about Cimino's desiderata... which brings us back to the wasting money
> thing...
>
> Grahame
>
>
>
> On Tue, Mar 13, 2018 at 8:19 PM, Philippe Ameline
> > wrote:
>
> Pablo, I wish you sincerely all the best.
>
> IMHO, the question is not really to enroll but to deliver... and
> considering the tremendous amount of money that was invested in
> HL7 and Snomed (both to elaborate and try to implement) and the
> actual societal return, there is such a discrepancy that the
> hypothesis that, due to missing the "information society" turn,
> health systems are entering terrible crisis times is to be
> considered seriously.
>
> In current "information society", you have two options when
> considering "health information systems":
> 1) You dedicate yourself to "medical information systems" instead,
> and can freely build for (inter-connected) silos,
> 2) You consider "health" in its genuine meaning and you have to
> realize that it is a complex domain fully opened to all other
> societal issues... hence should ban components that are endemic to
> medicine.
>
> Maybe (and I really mean it for Latin America), it should be high
> time to leapfrog, not to join the "dollars wasting club" ;-)
>
> Philippe
>
>
> Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
>> In Latin America is all the contrary, more countries are becoming
>> SNOMED members and adopting SNOMED at the govt level.
>>
>> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline
>> > wrote:
>>
>> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>>
>> > IMO we should focus on SNOMED.
>>
>> Hi,
>>
>> There is currently some kind of interesting momentum against
>> Snomed.
>>
>> It can come from governments that refuse to pay for it
>> (current mood in
>> France), of from practitioners who, after having been asked
>> by their gov
>> to "sort out their Snomed subset" came to the conclusion that
>> it doesn't
>> exist.
>>
>> Some also predict that the most certain result of
>> keeping up
>> trying to build systems using such shitty fully endemic
>> components is to
>> have medical doctors disappear from missing the "information
>> society"
>> turn.
>>
>> Have some of you been aware of the Meriterm (European) project?
>>
>> Best,
>>
>> Philippe
>>
>>
>> ___
>> openEHR-technical mailing list
>> 

Re: [Troll] Terminology bindings ... again

[Grahame Grieve]

hi Philippe

No one who's actually tried to use Snomed CT could think that in it's
current form it's the answer to everything.
But anyone who's tried to work on real terminologies must also be aware of
just how much work is involved in these things.

So there's very much a glass half full/empty thing here. I understand not
being thrilled with Snomed CT as a choice, but as the french government,
for instance, actually confronted how much more it will cost to do
something else?

There's more than one kind of club to have that wastes money

I've had a quick look at Meriterm... like all good rdf, it's not easily
penetrable. But it looks like the authors are not informed about Cimino's
desiderata... which brings us back to the wasting money thing...

Grahame



On Tue, Mar 13, 2018 at 8:19 PM, Philippe Ameline 
wrote:

> Pablo, I wish you sincerely all the best.
>
> IMHO, the question is not really to enroll but to deliver... and
> considering the tremendous amount of money that was invested in HL7 and
> Snomed (both to elaborate and try to implement) and the actual societal
> return, there is such a discrepancy that the hypothesis that, due to
> missing the "information society" turn, health systems are entering
> terrible crisis times is to be considered seriously.
>
> In current "information society", you have two options when considering
> "health information systems":
> 1) You dedicate yourself to "medical information systems" instead, and can
> freely build for (inter-connected) silos,
> 2) You consider "health" in its genuine meaning and you have to realize
> that it is a complex domain fully opened to all other societal issues...
> hence should ban components that are endemic to medicine.
>
> Maybe (and I really mean it for Latin America), it should be high time to
> leapfrog, not to join the "dollars wasting club" ;-)
>
> Philippe
>
> Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
>
> In Latin America is all the contrary, more countries are becoming SNOMED
> members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline <
> philippe.amel...@free.fr> wrote:
>
>> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>>
>> > IMO we should focus on SNOMED.
>>
>> Hi,
>>
>> There is currently some kind of interesting momentum against Snomed.
>>
>> It can come from governments that refuse to pay for it (current mood in
>> France), of from practitioners who, after having been asked by their gov
>> to "sort out their Snomed subset" came to the conclusion that it doesn't
>> exist.
>>
>> Some also predict that the most certain result of keeping up
>> trying to build systems using such shitty fully endemic components is to
>> have medical doctors disappear from missing the "information society"
>> turn.
>>
>> Have some of you been aware of the Meriterm (European) project?
>>
>> Best,
>>
>> Philippe
>>
>>
>> ___
>> 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 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://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
>



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
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]

Pablo, I wish you sincerely all the best.

IMHO, the question is not really to enroll but to deliver... and
considering the tremendous amount of money that was invested in HL7 and
Snomed (both to elaborate and try to implement) and the actual societal
return, there is such a discrepancy that the hypothesis that, due to
missing the "information society" turn, health systems are entering
terrible crisis times is to be considered seriously.

In current "information society", you have two options when considering
"health information systems":
1) You dedicate yourself to "medical information systems" instead, and
can freely build for (inter-connected) silos,
2) You consider "health" in its genuine meaning and you have to realize
that it is a complex domain fully opened to all other societal issues...
hence should ban components that are endemic to medicine.

Maybe (and I really mean it for Latin America), it should be high time
to leapfrog, not to join the "dollars wasting club" ;-)

Philippe


Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
> In Latin America is all the contrary, more countries are becoming
> SNOMED members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline
> > wrote:
>
> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current
> mood in
> France), of from practitioners who, after having been asked by
> their gov
> to "sort out their Snomed subset" came to the conclusion that it
> doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components
> is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> 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

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

In Latin America is all the contrary, more countries are becoming SNOMED
members and adopting SNOMED at the govt level.

On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline  wrote:

> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current mood in
> France), of from practitioners who, after having been asked by their gov
> to "sort out their Snomed subset" came to the conclusion that it doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> 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