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

[Philippe Ameline]

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

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

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

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

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

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

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

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

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

[Thomas Beale]

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


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


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


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


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


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


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


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

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


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


- thomas


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

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

[Philippe Ameline]

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

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

Let's imagine that there is no fils guide.

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

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

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

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

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

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

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

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

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

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

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

Philippe

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

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

[Thomas Beale]

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


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


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


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


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


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




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


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




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


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


- thomas

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

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

[Philippe Ameline]

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

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

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

[A Verhees]

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

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

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

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

[A Verhees]

Mostly a patients history is regarded in a consultation. Mostly this is
history from after the start of the electronical era and being treated in
the Netherlands . At least it is common practice in the Netherlands for
most patients.

Op ma 2 apr. 2018 14:30 schreef Thomas Beale :

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

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

[Thomas Beale]

On 02/04/2018 10:59, Philippe Ameline wrote:


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



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


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

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




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


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


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


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


you are I think using 'grammar' in an unusual way - normally it means 
the set of production rules that define legal utterances in some 
language; this is an intensional definition, i.e. it can be used 
computationally to parse actual utterances (including garbage) and 
generate structures only for the utterances obeying the rules of the 
grammar.


In your usage, 'grammar' is what you call the trees, which are 
extensional maps of legal utterances, or fragments of utterances, which 
can only be connected together according to their rules, which ensure 
correctness of larger utterances, e.g. a colonoscopy report.


Structurally and computationally then, the fils guides (the trees in 
Ligne de Vie) and archetypes are the same; they differ only in 
representational details. However, there are two semantic differences.


Firstly, the fils guides depend completely on the ontology (which is an 
ontological terminology, to give it a more correct name, I think), and 
the two things are built as a combined representational system. Whereas 
elements in archetypes can have bindings made to ontologies and/or 
terminologies, but don't rely on them, since they can rely on their 
internal terminology to a reasonable extent (but not for value sets like 
procedure or diagnoses etc). In theory, we should do what fils guides 
are doing, and the reason we have not is only practical, not 
theoretical: the development of bio-medical ontologies is still young, 
and was almost non-existent 18 years ago when we started on this.


The consequence has been that it is possible to construct archetypes 
that say questionable or even wrong things with respect to ontologies of 
those same things, say anatomical relationships. This rarely happens in 
reality simply because archetypes are built by clinical professionals 
and reviewed by many others, and mistakes tend to be avoided, or if 
made, caught in review. But clearly it's not a completely reliable 
strategy, and future versions of archetype tooling should force live 
checking against suitable ontologies to detect errors. Unfortunately, we 
still don't have such ontologies in anything like the necessary detail - 
despite the existence of OGMS, and numerous specialist OBO ontologies. 
SNOMED CT doesn't come close to what is needed here. We still lack a 
comprehensive ontology covering all of general medicine.


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

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

[Philippe Ameline]

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

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

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

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

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

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

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

[A Verhees]

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

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

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

[Philippe Ameline]

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

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

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

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

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

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

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

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

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

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

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

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

[Philippe Ameline]

Thomas,

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

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

Philippe


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

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

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

[Thomas Beale]

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


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


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

- thomas

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


El sáb., 31 mar. 2018 22:14, Philippe Ameline 
mailto:philippe.amel...@free.fr>> escribió:


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

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

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



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

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

[Thomas Beale]

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

...

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




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


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

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




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




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


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


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


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


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




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

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

[Diego Boscá]

and suffers from chronic diseases). The question remains to guess if SNOMED
>> is a component that lets you stuck in the past or helps you disrupt the
>> legacy craps.
>>
>> Now, let's imagine a modern system that would allow you to "tell a
>> patient medical story" from the various viewpoints of a multidisciplinary
>> patient centered team. What would be the point about having "local
>> vocabulary subsets"? Do you think that a GP shouldn't use the word "mitral
>> leak" or any other "specialized" word in the medical vocabulary?
>>
>> My feeling is that selected subset is a solution when using SNOMED as a
>> coding system. The subset being the global list of values that are legal
>> for the fields in the existing schema, in the same way you will select
>> subsets in a billing system. But when it comes to "telling a story" using a
>> language, in my opinion subsets are a non-sense. We don't use "vocabulary
>> subsets" when we talk, and each contributor in a patient's team would
>> mechanically get exposed to a super-set; subset is actually only fit for
>> silos... and at a time when medicine is already becoming a narrow silo in
>> health, I really don't see it as a sound strategy.
>>
>> Best,
>>
>> Philippe
>>
>> Le 23/03/2018 à 10:49, Diego Boscá a écrit :
>>
>> IMO having both representations (pre and postcordinated) is not bad per
>> se (in fact, knowing that they are equivalent is pretty good). The main
>> problem is that technical people (including myself) shouldn't just dump the
>> entire snomed ct into a data field and call it a day. To design better and
>> useful systems you need a first "curation" phase where you define your
>> relevant subsets that fit your system. The boundary problem is less of a
>> problem if even if different terms were used when the record was created we
>> can assess that they are in fact the same thing.
>> I think people are a little unaware of this step and causes problems as
>> the ones you and Thomas mentioned
>>
>> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <
>> silje.ljosland.ba...@nasjonalikt.no>:
>>
>>> I read Thomas’ reply with great interest, and I generally agree that
>>> with a well thought out information model, the very detailed precoordinated
>>> expressions are redundant. At the same time I understand Mikael’s point of
>>> view too. BUT, what I’m often met with is that because these precoordinated
>>> expressions exist (like for example “lying blood pressure” and “sitting
>>> blood pressure”), we should use them INSTEAD OF using our clever
>>> information models (that we do have) for recording new data.
>>>
>>>
>>>
>>> In my opinion this is wrong because it doesn’t take into account that
>>> healthcare is unpredictable, and this makes recording more difficult for
>>> the clinician. How many different variations would you have to select from?
>>> Take the made up example “sitting systolic blood pressure with a medium
>>> cuff on the left upper arm”; this will be a lot of possible permutations,
>>> especially if you take into account all the different permutations where
>>> one or more variable isn’t relevant.
>>>
>>>
>>>
>>> So while I don’t think the existence of these precoordinated terms in
>>> itself is a problem, it’s a potential problem that people get a bit
>>> overzealous with them.
>>>
>>>
>>>
>>> Regards,
>>>
>>> *Silje*
>>>
>>>
>>>
>>> *From:* openEHR-technical  *On
>>> Behalf Of *Mikael Nyström
>>> *Sent:* Friday, March 23, 2018 10:06 AM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@lists.openehr.org>
>>> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>>>
>>>
>>>
>>> Hi tom,
>>>
>>>
>>>
>>> I can agree with you that if SNOMED CT was created when all patients in
>>> the world already had all information in their health record recorded using
>>> cleverly built and structured information models (like archetypes,
>>> templates and similar), but that is not the case. Instead SNOMED CT also
>>> tries to help healthcare organizations to do something better also with
>>> their already recorded health record information, because that information
>>> to a large extent still belongs to living patients.
>>>
>>>
&

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

[Philippe Ameline]

account
> that healthcare is unpredictable, and this makes recording more
> difficult for the clinician. How many different variations would
> you have to select from? Take the made up example “sitting
> systolic blood pressure with a medium cuff on the left upper arm”;
> this will be a lot of possible permutations, especially if you
> take into account all the different permutations where one or more
> variable isn’t relevant.
>
>  
>
> So while I don’t think the existence of these precoordinated terms
> in itself is a problem, it’s a potential problem that people get a
> bit overzealous with them.
>
>  
>
> Regards,
>
> *Silje*
>
>  
>
> *From:*openEHR-technical
>  <mailto:openehr-technical-boun...@lists.openehr.org>> *On Behalf
> Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions
>  <mailto:openehr-technical@lists.openehr.org>>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>  
>
> Hi tom,
>
>  
>
> I can agree with you that if SNOMED CT was created when all
> patients in the world already had all information in their health
> record recorded using cleverly built and structured information
> models (like archetypes, templates and similar), but that is not
> the case. Instead SNOMED CT also tries to help healthcare
> organizations to do something better also with their already
> recorded health record information, because that information to a
> large extent still belongs to living patients.
>
>  
>
> It would be interesting to have your opinion about why it is a
> real problem with the “extra” pre-coordinated concepts in
> SNOMED CT in general and not only for the use case of creating
> archetypes or what would be nicest in theory.
>
>  
>
>              Regards
>
>  Mikael
>
>  
>
>  
>
> *Från:*openEHR-technical
> [mailto:openehr-technical-boun...@lists.openehr.org
> <mailto:openehr-technical-boun...@lists.openehr.org>] *För *Thomas
> Beale
> *Skickat:* den 23 mars 2018 01:06
> *Till:* openehr-technical@lists.openehr.org
> <mailto:openehr-technical@lists.openehr.org>
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>  
>
> I have made some attempts to study the problem in the past, not
> recently, so I don't know how much the content has changed in the
> last 5 years. Two points come to mind:
>
>  
>
> 1. the problem of a profusion of pre-coordinated and
> post-coordinatable concepts during a *lexically-based choosing
> process *(which is often just on a subset).
>  this can be simulated by the lexical search in any of the Snomed
> search engines, as shown in the screen shots below. Now, the
> returned list is just a bag of lexical matches, not a hierarchy.
> But - it is clear from just the size of the list that it would
> take time to even find the right one - usually there are several
> matches, e.g. 'blood pressure (obs entity)', 'systemic blood
> pressure', 'systolic blood pressure', 'sitting blood pressure',
> 'stable blood pressure' and many more.
>
> I would contend (and have for years) that things like 'sitting
> blood pressure', 'stable blood pressure', and 'blood pressure
> unrecordable' are just wrong as atomic concepts, each with a
> separate argument as to why. I won't go into any of them now.
> Let's assume instead that the lexical search was done on a subset,
> and that only observables and findings (why are there two?) show
> up, and that the user clicks through 'blood pressure (observable
> entity)', ignoring the 30 or more other concepts. Then the result
> is a part of the hierarchy, see the final screenshot. I would have
> a hard time building any ontology-based argument for even just
> this one sub-tree, which breaks basic terminology rules such as
> mutual exclusivity, collective exhaustiveness and so on. How would
> the user choose from this? If they are recording systolic systemic
> arterial BP, lying, do they choose 'systemic blood pressure',
> 'arterial blood pressure', 'systolic blood pressure', 'lying blood
> pressure', or something else.
>
> Most of these terms are pre-coordinated, and the problem would be
> solved by 

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

[Seref Arikan]

Hi Philippe,
See inline please

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

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

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

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

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

[A Verhees]

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

Bert

Op ma 26 mrt. 2018 08:10 schreef Mikael Nyström :

> Hi Bert,
>
>
>
> Most countries (or big organizations) that start to use SNOMED CT creates
> those kinds of subsets of SNOMED CT to make it more manageable. See for
> example NHS in England
> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *För *Bert Verhees
> *Skickat:* den 23 mars 2018 20:01
>
>
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> Diego, this is a wise thought!!!
> It seems logical, but that is often in good ideas, they seem like: why did
> no one ever think about this.
>
> No clinician handles the complete medical science/SNOMED repository in his
> profession. Some even use a very small sub-part, think about a dentist, a
> physiotherapist, a midwife
> For some is it also the case that not only the subjects are different, but
> also how deep the details must go. For some professions it is not
> interesting to know if blood-pressure was measured lying or sitting.
>
> It looks like a good idea if the SNOMED repository will be split up for
> professions, maybe that needs to be done on national level, because the
> clinical profession-structure can differ in countries.
> The rest of the database should be there for second searches, for
> interpreting codes which come from other professions.
>
> I hope someone will pick up this idea, because it is hardly to be done for
> individuals. It needs to be done by national SNOMED maintenance teams.
>
> Bert
>
>
> On 23-03-18 10:49, Diego Boscá wrote:
>
> IMO having both representations (pre and postcordinated) is not bad per se
> (in fact, knowing that they are equivalent is pretty good). The main
> problem is that technical people (including myself) shouldn't just dump the
> entire snomed ct into a data field and call it a day. To design better and
> useful systems you need a first "curation" phase where you define your
> relevant subsets that fit your system. The boundary problem is less of a
> problem if even if different terms were used when the record was created we
> can assess that they are in fact the same thing.
>
> I think people are a little unaware of this step and causes problems as
> the ones you and Thomas mentioned
>
> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that information
> to a large extent still belongs to living patients.
>
>

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

[Jussara Macedo Rötzsch]

Heather,

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

Em sáb, 24 de mar de 2018 às 04:42, Heather Leslie <
heather.les...@atomicainformatics.com> escreveu:

> Totally agreed, Silje. I think preordination for anatomical location is
> invaluable, but it’s the only use case that I have identified as one we
> absolutely can’t do without.
>
>
>
> But I would love the opportunity to really investigate this properly, and
> with others who understand SNOMED better than I. That will help with the
> boundary issue/semantically grey area.
>
>
>
> I’d prefer that we could use and reuse simpler, really high quality value
> sets from in multiple archetypes for different contexts eg a list of
> diagnoses in the Problem/diagnosis archetype as well as the Family History
> archetype. The archetype context is invaluable here. And the terminology
> community focussing on high value terms that would provide great impact.
>
>
>
> Regards
>
>
>
> Heather
>
>
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Bakke, Silje Ljosland
> *Sent:* Friday, 23 March 2018 8:35 PM
>
>
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
>
> *Subject:* RE: SV: [Troll] Terminology bindings ... again
>
>
>
> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that information
> to a large extent still belongs to living patients.
>
>
>
> It would be interesting to have your opinion about why it is a real
> problem with the “extra” pre-coordinated concepts in SNOMED CT in general
> and not only for the use case of creating archetypes or what would be
> nicest in theory.
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [
> mailto:openehr-technical-boun...@lists.openehr.org
> ] *För *Thomas Bea

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

[Heather Leslie]

Totally agreed, Silje. I think preordination for anatomical location is 
invaluable, but it's the only use case that I have identified as one we 
absolutely can't do without.

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

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

Regards

Heather


From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: Friday, 23 March 2018 8:35 PM
To: For openEHR technical discussions 
Subject: RE: SV: [Troll] Terminology bindings ... again

I read Thomas' reply with great interest, and I generally agree that with a 
well thought out information model, the very detailed precoordinated 
expressions are redundant. At the same time I understand Mikael's point of view 
too. BUT, what I'm often met with is that because these precoordinated 
expressions exist (like for example "lying blood pressure" and "sitting blood 
pressure"), we should use them INSTEAD OF using our clever information models 
(that we do have) for recording new data.

In my opinion this is wrong because it doesn't take into account that 
healthcare is unpredictable, and this makes recording more difficult for the 
clinician. How many different variations would you have to select from? Take 
the made up example "sitting systolic blood pressure with a medium cuff on the 
left upper arm"; this will be a lot of possible permutations, especially if you 
take into account all the different permutations where one or more variable 
isn't relevant.

So while I don't think the existence of these precoordinated terms in itself is 
a problem, it's a potential problem that people get a bit overzealous with them.

Regards,
Silje

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

Hi tom,

I can agree with you that if SNOMED CT was created when all patients in the 
world already had all information in their health record recorded using 
cleverly built and structured information models (like archetypes, templates 
and similar), but that is not the case. Instead SNOMED CT also tries to help 
healthcare organizations to do something better also with their already 
recorded health record information, because that information to a large extent 
still belongs to living patients.

It would be interesting to have your opinion about why it is a real problem 
with the "extra" pre-coordinated concepts in SNOMED CT in general and not only 
for the use case of creating archetypes or what would be nicest in theory.

 Regards
 Mikael


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


I have made some attempts to study the problem in the past, not recently, so I 
don't know how much the content has changed in the last 5 years. Two points 
come to mind:


1. the problem of a profusion of pre-coordinated and post-coordinatable 
concepts during a lexically-based choosing process (which is often just on a 
subset).
 this can be simulated by the lexical search in any of the Snomed search 
engines, as shown in the screen shots below. Now, the returned list is just a 
bag of lexical matches, not a hierarchy. But - it is clear from just the size 
of the list that it would take time to even find the right one - usually there 
are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood 
pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood 
pressure' and many more.

I would contend (and have for years) that things like 'sitting blood pressure', 
'stable blood pressure', and 'blood pressure unrecordable' are just wrong as 
atomic concepts, each with a separate argument as to why. I won't go into any 
of them now. Let's assume instead that the lexical search was done on a subset, 
and that only observables and findings (why are there two?) show up, and that 
the user clicks through 'blood pressure (observable entity)', ignoring the 30 
or more 

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

[Bert Verhees]

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


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


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


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


Bert


On 23-03-18 10:49, Diego Boscá wrote:
IMO having both representations (pre and postcordinated) is not bad 
per se (in fact, knowing that they are equivalent is pretty good). The 
main problem is that technical people (including myself) shouldn't 
just dump the entire snomed ct into a data field and call it a day. To 
design better and useful systems you need a first "curation" phase 
where you define your relevant subsets that fit your system. The 
boundary problem is less of a problem if even if different terms were 
used when the record was created we can assess that they are in fact 
the same thing.
I think people are a little unaware of this step and causes problems 
as the ones you and Thomas mentioned


2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland 
<mailto:silje.ljosland.ba...@nasjonalikt.no>>:


I read Thomas’ reply with great interest, and I generally agree
that with a well thought out information model, the very detailed
precoordinated expressions are redundant. At the same time I
understand Mikael’s point of view too. BUT, what I’m often met
with is that because these precoordinated expressions exist (like
for example “lying blood pressure” and “sitting blood pressure”),
we should use them INSTEAD OF using our clever information models
(that we do have) for recording new data.

In my opinion this is wrong because it doesn’t take into account
that healthcare is unpredictable, and this makes recording more
difficult for the clinician. How many different variations would
you have to select from? Take the made up example “sitting
systolic blood pressure with a medium cuff on the left upper arm”;
this will be a lot of possible permutations, especially if you
take into account all the different permutations where one or more
variable isn’t relevant.

So while I don’t think the existence of these precoordinated terms
in itself is a problem, it’s a potential problem that people get a
bit overzealous with them.

Regards,

*Silje*

*From:*openEHR-technical
mailto:openehr-technical-boun...@lists.openehr.org>> *On Behalf
Of *Mikael Nyström
*Sent:* Friday, March 23, 2018 10:06 AM
*To:* For openEHR technical discussions
mailto:openehr-technical@lists.openehr.org>>
*Subject:* SV: SV: [Troll] Terminology bindings ... again

Hi tom,

I can agree with you that if SNOMED CT was created when all
patients in the world already had all information in their health
record recorded using cleverly built and structured information
models (like archetypes, templates and similar), but that is not
the case. Instead SNOMED CT also tries to help healthcare
organizations to do something better also with their already
recorded health record information, because that information to a
large extent still belongs to living patients.

It would be interesting to have your opinion about why it is a
real problem with the “extra” pre-coordinated concepts in
SNOMED CT in general and not only for the use case of creating
archetypes or what would be nicest in theory.

 Regards

 Mikael

*Från:*openEHR-technical
[mailto:openehr-technical-boun...@lists.openehr.org
<mailto:openehr-technical-boun...@lists.openehr.org>] *För *Thomas
Beale
*Skickat:* den 23 mars 2018 01:06
*Till:* openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.org>
*Ämne:* Re: SV: [Troll] Terminology bindings ... again

I have made some attempts to study the problem in the past, not
recently, so I don't know how much the content has changed in the
last 5 years. Two points come to mind:

1. the problem of a profusion of pre-coordinated and
post-coordinatable concepts during a *lexically-based choosing
process *(which is o

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

[Diego Boscá]

IMO having both representations (pre and postcordinated) is not bad per se
(in fact, knowing that they are equivalent is pretty good). The main
problem is that technical people (including myself) shouldn't just dump the
entire snomed ct into a data field and call it a day. To design better and
useful systems you need a first "curation" phase where you define your
relevant subsets that fit your system. The boundary problem is less of a
problem if even if different terms were used when the record was created we
can assess that they are in fact the same thing.
I think people are a little unaware of this step and causes problems as the
ones you and Thomas mentioned

2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no>:

> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that information
> to a large extent still belongs to living patients.
>
>
>
> It would be interesting to have your opinion about why it is a real
> problem with the “extra” pre-coordinated concepts in SNOMED CT in general
> and not only for the use case of creating archetypes or what would be
> nicest in theory.
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *För
> *Thomas Beale
> *Skickat:* den 23 mars 2018 01:06
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> I have made some attempts to study the problem in the past, not recently,
> so I don't know how much the content has changed in the last 5 years. Two
> points come to mind:
>
>
>
> 1. the problem of a profusion of pre-coordinated and post-coordinatable
> concepts during a *lexically-based choosing process *(which is often just
> on a subset).
>  this can be simulated by the lexical search in any of the Snomed search
> engines, as shown in the screen shots below. Now, the returned list is just
> a bag of lexical matches, not a hierarchy. But - it is clear from just the
> size of the list that it would take time to even find the right one -
> usually there are several matches, e.g. 'blood pressure (obs entity)',
> 'systemic blood pressure', 'systolic blood pressure', 'sitting blood
> pressure', 'stable blood pressure' and many more.
>
> I would contend (and have for years) that things like 'sitting blood
> pressure', 'stable blood pressure', and 'blood pressure unrecordable' are
> just wrong as atomic concepts, each with a separate argument as to why. I
> won't go into any of them now. Let's assume instead that the lexical search
> was done on a subset, and that only observables and findings (why are there
> two?) show up, and that the user clicks t

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

[A Verhees]

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

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

Bert

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

> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that information
> to a large extent still belongs to living patients.
>
>
>
> It would be interesting to have your opinion about why it is a real
> problem with the “extra” pre-coordinated concepts in SNOMED CT in general
> and not only for the use case of creating archetypes or what would be
> nicest in theory.
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *För
> *Thomas Beale
> *Skickat:* den 23 mars 2018 01:06
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> I have made some attempts to study the problem in the past, not recently,
> so I don't know how much the content has changed in the last 5 years. Two
> points come to mind:
>
>
>
> 1. the problem of a profusion of pre-coordinated and post-coordinatable
> concepts during a *lexically-based choosing process *(which is often just
> on a subset).
>  this can be simulated by the lexical search in any of the Snomed search
> engines, as shown in the screen shots below. Now, the returned list is just
> a bag of lexical matches, not a hierarchy. But - it is clear from just the
> size of the list that it would take time to even find the right one -
> usually there are several matches, e.g. 'blood pressure (obs entity)',
> 'systemic blood pressure', 'systolic blood pressure', 'sitting blood
> pressure', 'stable blood pressure' and many more.
>
> I would contend (and have for years) that things like 'sitting blood
> pressure', 'stable blood pressure', and 'blood pressure unrecordable' are
> just wrong as atomic concepts, each with a separate argument as to why. I
> won't go into any of them now. Let's assume instead that the lexical search
> was done on a subset, and that only observables and findings (why are there
> two?) show up, and that the user clicks through 'blood pressure (observable
> entity)', ignoring the 30 or more other concepts. Then the result is a part
> of the hierarchy, see the final screenshot. I would have a hard time
> building any ontology-based argument for even just this one sub-tree, which
> breaks basic terminology rules such as mutual exclusivity, collective
> exhaustiveness and so on. How would the user choose from this? If t

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

[Bakke, Silje Ljosland]

I read Thomas' reply with great interest, and I generally agree that with a 
well thought out information model, the very detailed precoordinated 
expressions are redundant. At the same time I understand Mikael's point of view 
too. BUT, what I'm often met with is that because these precoordinated 
expressions exist (like for example "lying blood pressure" and "sitting blood 
pressure"), we should use them INSTEAD OF using our clever information models 
(that we do have) for recording new data.

In my opinion this is wrong because it doesn't take into account that 
healthcare is unpredictable, and this makes recording more difficult for the 
clinician. How many different variations would you have to select from? Take 
the made up example "sitting systolic blood pressure with a medium cuff on the 
left upper arm"; this will be a lot of possible permutations, especially if you 
take into account all the different permutations where one or more variable 
isn't relevant.

So while I don't think the existence of these precoordinated terms in itself is 
a problem, it's a potential problem that people get a bit overzealous with them.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Mikael Nyström
Sent: Friday, March 23, 2018 10:06 AM
To: For openEHR technical discussions 
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi tom,

I can agree with you that if SNOMED CT was created when all patients in the 
world already had all information in their health record recorded using 
cleverly built and structured information models (like archetypes, templates 
and similar), but that is not the case. Instead SNOMED CT also tries to help 
healthcare organizations to do something better also with their already 
recorded health record information, because that information to a large extent 
still belongs to living patients.

It would be interesting to have your opinion about why it is a real problem 
with the "extra" pre-coordinated concepts in SNOMED CT in general and not only 
for the use case of creating archetypes or what would be nicest in theory.

 Regards
 Mikael


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


I have made some attempts to study the problem in the past, not recently, so I 
don't know how much the content has changed in the last 5 years. Two points 
come to mind:


1. the problem of a profusion of pre-coordinated and post-coordinatable 
concepts during a lexically-based choosing process (which is often just on a 
subset).
 this can be simulated by the lexical search in any of the Snomed search 
engines, as shown in the screen shots below. Now, the returned list is just a 
bag of lexical matches, not a hierarchy. But - it is clear from just the size 
of the list that it would take time to even find the right one - usually there 
are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood 
pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood 
pressure' and many more.

I would contend (and have for years) that things like 'sitting blood pressure', 
'stable blood pressure', and 'blood pressure unrecordable' are just wrong as 
atomic concepts, each with a separate argument as to why. I won't go into any 
of them now. Let's assume instead that the lexical search was done on a subset, 
and that only observables and findings (why are there two?) show up, and that 
the user clicks through 'blood pressure (observable entity)', ignoring the 30 
or more other concepts. Then the result is a part of the hierarchy, see the 
final screenshot. I would have a hard time building any ontology-based argument 
for even just this one sub-tree, which breaks basic terminology rules such as 
mutual exclusivity, collective exhaustiveness and so on. How would the user 
choose from this? If they are recording systolic systemic arterial BP, lying, 
do they choose 'systemic blood pressure', 'arterial blood pressure', 'systolic 
blood pressure', 'lying blood pressure', or something else.

Most of these terms are pre-coordinated, and the problem would be solved by 
treating the various factors such as patient position, timing, mathematical 
function (instant, mean, etc), measurement datum type (systolic, pulse, MAP 
etc), subsystem (systemic, central venous etc) and so on as post-coordinatable 
elements that can be attached in specific ways according to the ontological 
description of measuring blood pressure on a body. This is what the blood 
pressure archetype does, and we might a

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

[Thomas Beale]

I have made some attempts to study the problem in the past, not 
recently, so I don't know how much the content has changed in the last 5 
years. Two points come to mind:



1. the problem of a profusion of pre-coordinated and post-coordinatable 
concepts during a *lexically-based choosing process *(which is often 
just on a subset).
 this can be simulated by the lexical search in any of the Snomed 
search engines, as shown in the screen shots below. Now, the returned 
list is just a bag of lexical matches, not a hierarchy. But - it is 
clear from just the size of the list that it would take time to even 
find the right one - usually there are several matches, e.g. 'blood 
pressure (obs entity)', 'systemic blood pressure', 'systolic blood 
pressure', 'sitting blood pressure', 'stable blood pressure' and many more.


I would contend (and have for years) that things like 'sitting blood 
pressure', 'stable blood pressure', and 'blood pressure unrecordable' 
are just wrong as atomic concepts, each with a separate argument as to 
why. I won't go into any of them now. Let's assume instead that the 
lexical search was done on a subset, and that only observables and 
findings (why are there two?) show up, and that the user clicks through 
'blood pressure (observable entity)', ignoring the 30 or more other 
concepts. Then the result is a part of the hierarchy, see the final 
screenshot. I would have a hard time building any ontology-based 
argument for even just this one sub-tree, which breaks basic terminology 
rules such as mutual exclusivity, collective exhaustiveness and so on. 
How would the user choose from this? If they are recording systolic 
systemic arterial BP, lying, do they choose 'systemic blood pressure', 
'arterial blood pressure', 'systolic blood pressure', 'lying blood 
pressure', or something else.


Most of these terms are pre-coordinated, and the problem would be solved 
by treating the various factors such as patient position, timing, 
mathematical function (instant, mean, etc), measurement datum type 
(systolic, pulse, MAP etc), subsystem (systemic, central venous etc) and 
so on as post-coordinatable elements that can be attached in specific 
ways according to the ontological description of measuring blood 
pressure on a body. This is what the blood pressure archetype does, and 
we might argue that since that is the model of capturing BP measurements 
(not an ontological description of course), it is the starting point, 
and in fact the user won't ever have to do the lexical choosing above. 
Now, to achieve the coding that some people say they want, the archetype 
authors would have the job of choosing the appropriate codes to bind to 
the elements of the archetype. In theory it would be possible to 
construct paths and/or expressions in the archetype and bind one of the 
concepts from the list below to each one. To do so we would need to add 
40-50 bindings to that archetype. But why? To what end? I am unclear 
just who would ever use any of these terms.


The terms that matter are: systemic, systolic/diastolic, terms for body 
location, terms for body position, terms for exertion, terms for 
mathematical function, and so on. These should all be available 
separately, and be usable in combination, preferably via information 
models like archetypes that put them together in the appropriate way to 
express BP measurement. Actually creating post-coordinated terms is not 
generally useful, beyond something like 'systemic arterial systolic BP', 
or just 'systolic BP' for short, because you are always going to treat 
things like exertion and position separately (which is why these are 
consider 'patient state' in openEHR), and you are usually going to 
ignore things like cuff size and measurement location (things considered 
as non-meaning modifying 'protocol' in openEHR).


2. similar *problems in the authoring phase*, i.e. addition of concepts 
to the terminology in the first place.  If more or less any manner of 
pre-coordinated terms is allowed, with the precoordinations 
cross-cutting numerous ontological aspects (i.e. concept model attribute 
types), what rules can even be established as to whether the next 
proposed concept goes in or not? It is very easy to examine the BP 
hierarchy, and suggest dozens of new pre-coordinated terms that would 
fit perfectly alongside the arbitrary and incomprehensible set already 
there...


(another 3x)


I've picked just the most obvious possible example. We can go and look 
at 'substances' or 'reason for discharge' or hundreds of other things, 
and find similar problems. I don't mind that all these pre-coordinated 
concepts exist somewhere, but they should not be in the primary 
hierarchies, which really, in my view should look much more like an 
ontology, i.e. a description of reality which provides a model of what 
it is possible to say. If that were the case, the core would be much 
smaller, and the concept model much larger than it is today.


- tho

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

[Heather Leslie]

HI Michael,

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

Heather

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




Hi Heather,



In general, anyone is welcome to participate in the work; you don't need to be 
one of the small number of Advisory Group members.  That helps with travel 
costs, but most of the real work is done on teleconferences, not so much at the 
face to face meetings.



I would be very interested to hear people's articulations of where they think 
the boundary should be for this boundary line.  I'd also be interested to 
understand better what people think the problem is with having "extra" / 
unnecessary pre-coordinated concepts; what advantage is to be gained from 
removing them, and what is the perceived scale of the problem.



michael


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

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

Hi Mikael,

What efforts are being made to resolve the boundary problem?

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

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

Regards

Heather

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

Hi Tom,

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

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

 Regards
 Mikael

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




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

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

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

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model 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

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

[Michael.Lawley]

Hi Heather,


In general, anyone is welcome to participate in the work; you don't need to be 
one of the small number of Advisory Group members.  That helps with travel 
costs, but most of the real work is done on teleconferences, not so much at the 
face to face meetings.


I would be very interested to hear people's articulations of where they think 
the boundary should be for this boundary line.  I'd also be interested to 
understand better what people think the problem is with having "extra" / 
unnecessary pre-coordinated concepts; what advantage is to be gained from 
removing them, and what is the perceived scale of the problem.


michael


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

From: openEHR-technical  on behalf 
of Heather Leslie 
Sent: Thursday, 22 March 2018 9:46 AM
To: For openEHR technical discussions
Subject: RE: SV: [Troll] Terminology bindings ... again

Hi Mikael,

What efforts are being made to resolve the boundary problem?

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

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

Regards

Heather

From: openEHR-technical  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<mailto:openehr-technical@lists.openehr.org>
Ämne: Re: SV: [Troll] Terminology bindings ... again




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

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

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

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

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to critique SNOMED, as long as that critique is collegial, and 
above all intelligent. (BTW m

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

[Heather Leslie]

Hi Mikael,

What efforts are being made to resolve the boundary problem?

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

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

Regards

Heather

From: openEHR-technical  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<mailto:openehr-technical@lists.openehr.org>
Ämne: Re: SV: [Troll] Terminology bindings ... again




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

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

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

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

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

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

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

- thomas

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

Hi Philippe,



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



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

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

[Thomas Beale]

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


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


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


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


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


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


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

- thomas


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

Hi Philippe,

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

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

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

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

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

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

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

Regards
Mikael



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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical

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

[Philippe Ameline]

Interesting times indeed :-)

Le 12/03/2018 à 18:06, Birger Haarbrandt a écrit :

> Please never underestimate the Germans...
>
> Am 12.03.2018 um 14:54 schrieb Mikael Nyström:
>> Will France as usual be the last country that adopt something that originate 
>> from Great Britain? :-)
>>
>>  Regards
>>  Mikael
>>
>>


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

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

[Birger Haarbrandt]

Please never underestimate the Germans...

Am 12.03.2018 um 14:54 schrieb Mikael Nyström:

Hi,

Have anybody ever heard about  a health-it-project that hadn't a smaller or 
larger group of sceptic people that try to build momentum against the project? 
:-)

For SNOMED CT the trend at least seems to be that fewer and fewer people 
belongs to the sceptic group, and about half of the European Union member 
countries seems to be member in SNOMED International 
(https://www.snomed.org/members).

Will France as usual be the last country that adopt something that originate 
from Great Britain? :-)

Regards
Mikael


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

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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Birger Haarbrandt, M. Sc.
Peter L. Reichertz Institut for Medical Informatics (PLRI)
Technical University Braunschweig and Hannover Medical School
Software Architect HiGHmed Project *
Tel: +49 176 640 94 640, Fax: +49 531/391-9502
birger.haarbra...@plri.de
www.plri.de
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org