Re: [Troll] Terminology bindings ... again

[Thomas Beale]

On 13/03/2018 16:45, Philippe Ameline wrote:


Thomas,

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




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


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


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


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


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




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


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

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


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



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




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


- thomas

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

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

[Diego Boscá]

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

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

>
>
> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert 
> wrote:
>
>> > just imagine standardizing every diagnosis
>>
>> That typically leads to either bad statistics or disimproved care.
>>
>
> Can I ask why?
>
>
>>
>> Karsten
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Pablo Pazos]

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

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

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

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


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

> I assume the reason is that asking clinicians to do coding without any
> help provides great variability and leads to coding errors. What Thomas
> said about presenting clinicians with addecuated subsets is key to avoid
> that. There are also mechanisms to check coding quality/errors, but usually
> need high domain & terminology knowledge (but creating systems that 'learn'
> from documentalists' knowledge is feasible)
>
> El mar., 13 mar. 2018 19:03, Pablo Pazos 
> escribió:
>
>>
>>
>> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert > > wrote:
>>
>>> > just imagine standardizing every diagnosis
>>>
>>> That typically leads to either bad statistics or disimproved care.
>>>
>>
>> Can I ask why?
>>
>>
>>>
>>> Karsten
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> technical_lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pa...@cabolabs.com
>> +598 99 043 145 <099%20043%20145>
>> skype: cabolabs
>> 
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>> Subscribe to our newsletter 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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


No flat lists ;)

- thomas


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

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

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


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


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


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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

RE: [Troll] Terminology bindings ... again

[GEORGE, John (NHS DIGITAL)]

Hi Phillipe and Graham,

This may help your discussion:

https://www.snomedinaction.org

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

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


Regards
John

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


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

NHS Digital provides information and technology for better health and care.
Find out more about us: www.digital.nhs.uk | 
@nhsdigital












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


Grahame,

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

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

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

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

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

Time will tell... but interesting times ahead!

Philippe

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

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

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

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

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

Grahame



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

Pablo, I wish you sincerely all the best.

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

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

Re: Templates for application form development

[Bert Verhees]

Hi contributors on this,

I am sorry not contributing so much, it is not my piece of cake to work 
on defining standards, I like better using them.


So I like to express that I am very grateful for the work which is being 
done in this context and the way it is being done.

I think that it will be a big step forwards for OpenEhr.

Best regards
Bert Verhees


On 13-03-18 00:04, Erik Sundvall wrote:

Hi!

I have also updated the 
https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets 
wikipage to include


  * references to some previous GUI discussions and
  * Region Östergötlands current use case and initial
Ethercis-OPT-introspector+Angular-based design plans (See heading
"OPT form renderer needed for pilot testing of surgery process
supporting system" near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
 (previously lio.se 
) http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se 
, http://www.imt.liu.se/~erisu/ 



On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos 
> wrote:


Thanks Thomas, I added a paragraph about the UI generation modes
at the end, I forgot to mention that yesterday.

On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale
> wrote:

Pablo,

Good work - I've included a reference to this doc in the
original wiki page

,
and added a few ideas about how to use it. It is very close to
what I was thinking of.

- thomas


On 12/03/2018 07:31, Pablo Pazos wrote:

Hi all,

I manage to translate / update part of the work we did some
years ago in terms of UI definition and generation for the
openEHR stack.

Here is the doc, feedback is very welcome!


https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing






-- 
Thomas Beale

Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare

Management Board, Specifications Program Lead, openEHR
Foundation 
Chartered IT Professional Fellow, BCS, British Computer
Society 
Health IT blog  | Culture blog


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


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






-- 
Ing. Pablo Pazos Gutiérrez

pablo.pa...@cabolabs.com 
+598 99 043 145 
skype: cabolabs

http://www.cabolabs.com 
https://cloudehrserver.com 
Subscribe to our newsletter 


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


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






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



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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

On 13/03/2018 10:56, Philippe Ameline wrote:


Grahame,

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


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




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

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Pablo, I wish you sincerely all the best.

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

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

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

Philippe


Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
> In Latin America is all the contrary, more countries are becoming
> SNOMED members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline
> > wrote:
>
> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current
> mood in
> France), of from practitioners who, after having been asked by
> their gov
> to "sort out their Snomed subset" came to the conclusion that it
> doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components
> is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> 
>
>
>
>
> -- 
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com 
> +598 99 043 145
> skype: cabolabs
>   
> http://www.cabolabs.com 
> https://cloudehrserver.com 
> Subscribe to our newsletter 
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

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

[Grahame Grieve]

hi Philippe

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

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

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

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

Grahame



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

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



-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Grahame,

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

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

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

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

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

Time will tell... but interesting times ahead!

Philippe


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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Hi,

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

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

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

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

best,
Pablo

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

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

Re: [Troll] Terminology bindings ... again

[Grahame Grieve]

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

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

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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


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


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


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


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


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


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


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

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


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


- thomas

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


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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

Hi John,

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

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

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

Best,

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

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

[Karsten Hilbert]

> just imagine standardizing every diagnosis

That typically leads to either bad statistics or disimproved care.

Karsten

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

Re: [Troll] Terminology bindings ... again

[Bert Verhees]

On 13-03-18 17:45, Philippe Ameline wrote:
in my own terms, it means that it is not the proper component for 
modern applications.


Wasn't it Voltaire who said that the best is the enemy of the good?




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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Thomas,

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

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

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

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

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

Philippe


Le 13/03/2018 à 15:21, Thomas Beale a écrit :
>
>
> The killer move would be to do something I advocated for years
> unsuccessfully: *separate SNOMED technology from content *and allow
> them to be independently licensable and used. Here, technology means
> representation (RF2 for example), open source programming libraries
> for working with ref-sets, specs and implems for e..g the constraint
> language, URIs and so on.
>
> It should be possible for a country (the one I am most familiar with
> w.r.t. to terminology today is Brazil) to create an empty 'SNOMED
> container' of its own, and put its existing terminologies in there -
> typically procedure lists, drug codes, lab codes, devices & prosthesis
> codes, packages (chargeable coarse-grained packages like childbirth
> that you get on a health plan) and so on. There are usually < 20k or
> even 10k such codes for most countries (UK and US would an exception),
> not counting lab analyte codes (but even there, 2000 or so codes would
> take care of most results). But the common situation is that nearly
> every country has its own version of these things, and they are far
> smaller than SNOMED. Now, SNOMED's version of things is usually better
> for /some /of that content, but in some cases, /it is missing concepts/.
>
> The ability to easily create an empty SNOMED repo, fill it with
> national vocabularies, have it automatically generate non-clashing
> (i.e. with other countries, or the core) concept codes and mappings,
> and then serve it from a standard CTS2 (or other decent standard)
> terminology service would have revolutionised things in my view. This
> pathway has not been obviously available however, and has been a real
> blockage. The error was not understanding that the starting point for
> most countries isn't the international core, it's their own vocabularies.
>
> The second killer feature would have been to *make creating and
> managing ref-sets for data/form fields much easier*, based on a
> subsetting language that can be applied to the core, and tools that
> implement that. Ways are needed to make the local / legacy
> vocabularies that have been imported, to look like a regular ref-set.
>
> The third killer feature would have been to *make translation tools
> work *on the basis of legacy vocabulary and new ref-sets, not on the
> basis of the huge (but mostly unused) international core.
>
> I think IHTSDO's / SNOMED International's emphasis has historically
> been on curating the core content, and making/buying tools to do that
> (the IHTSDO workbench, a tool that comes with its own PhD course),
> rather than promulgating SNOMED technology and tooling to enable the
> mess of real world content in each country to be rehoused in a
> standard way, and incrementally joined up by mapping or other means to
> the core. I think the latter would have been more helpful.
>
> There is additionally an elephant in the room: *IHTSDO (now SNOMED
> International) has been tied to a single terminology - SNOMED CT*, but
> it would have been better to have had a terminology standards org that
> was independent of any particular terminology, and worked to create a
> truly terminology-independent technology ecosystem, along with
> technical means of connecting 

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

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

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

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

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

Best,

Philippe


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

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

[Karsten Hilbert]

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

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

It is a problem of up-/downcoding.

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

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

Karsten

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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

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

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

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

[Karsten Hilbert]

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




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

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

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

[Pablo Pazos]

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

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

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

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

>  There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>  But I'm not sure if Karsten was talking about this, let's wait :)
>
>
>
>
> I was mainly talking about the first, which is standard in German
> ambulatory care.
>
> Karsten
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

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

In assisted coding what you mention is one way.

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

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

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

> I would put it the other way around: it can only be done with structured,
> controlled subsets, that retain hierarchy from the original terminology,
> remove unneeded codes, and do a few other tricks (adding non-coding 'group'
> concepts to help guide the user). This has to be done using smart tree
> controls, or anything that logically works as a tree-based choosing tool.
>
> No flat lists ;)
>
> - thomas
>
> On 13/03/2018 18:33, Pablo Pazos wrote:
>
> It is a very very very bad practice to ask clinicians to code!
>
> Standardizing diagnosis is a very different thing than asking clinicians
> to code, the first is the strategy, the second is one possible, and bad,
> implementation.
>
> There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>
> But I'm not sure if Karsten was talking about this, let's wait :)
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



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

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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

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

Shouldn't we contribute?

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


LOINC also misses concepts, and when I asked them how can I contribute,
they sent me the process and some templates for requesting a new concept to
be added, pretty simple, formal and open!

IMO we can't expect perfection, is a bad strategy and a move towards
isolation. I think pragmatism is better and go with "this is the best we
can expect for". We are the ones that should push towards the ideal, but as
a guide not as a goal (getting a little philosophical here...).

The same idea applies to tooling, anyone can create tools to manage the
terminology better. In our own backyard we have tools that need
improvement, but we accept them because there is no better alternative.



On Tue, Mar 13, 2018 at 11:21 AM, Thomas Beale 
wrote:

>
> The killer move would be to do something I advocated for years
> unsuccessfully: *separate SNOMED technology from content *and allow them
> to be independently licensable and used. Here, technology means
> representation (RF2 for example), open source programming libraries for
> working with ref-sets, specs and implems for e..g the constraint language,
> URIs and so on.
>
> It should be possible for a country (the one I am most familiar with
> w.r.t. to terminology today is Brazil) to create an empty 'SNOMED
> container' of its own, and put its existing terminologies in there -
> typically procedure lists, drug codes, lab codes, devices & prosthesis
> codes, packages (chargeable coarse-grained packages like childbirth that
> you get on a health plan) and so on. There are usually < 20k or even 10k
> such codes for most countries (UK and US would an exception), not counting
> lab analyte codes (but even there, 2000 or so codes would take care of most
> results). But the common situation is that nearly every country has its own
> version of these things, and they are far smaller than SNOMED. Now,
> SNOMED's version of things is usually better for *some *of that content,
> but in some cases, *it is missing concepts*.
>
> The ability to easily create an empty SNOMED repo, fill it with national
> vocabularies, have it automatically generate non-clashing (i.e. with other
> countries, or the core) concept codes and mappings, and then serve it from
> a standard CTS2 (or other decent standard) terminology service would have
> revolutionised things in my view. This pathway has not been obviously
> available however, and has been a real blockage. The error was not
> understanding that the starting point for most countries isn't the
> international core, it's their own vocabularies.
>
> The second killer feature would have been to *make creating and managing
> ref-sets for data/form fields much easier*, based on a subsetting
> language that can be applied to the core, and tools that implement that.
> Ways are needed to make the local / legacy vocabularies that have been
> imported, to look like a regular ref-set.
>
> The third killer feature would have been to *make translation tools work *on
> the basis of legacy vocabulary and new ref-sets, not on the basis of the
> huge (but mostly unused) international core.
>
> I think IHTSDO's / SNOMED International's emphasis has historically been
> on curating the core content, and making/buying tools to do that (the
> IHTSDO workbench, a tool that comes with its own PhD course), rather than
> promulgating SNOMED technology and tooling to enable the mess of real world
> content in each country to be rehoused in a standard way, and incrementally
> joined up by mapping or other means to the core. I think the latter would
> have been more helpful.
>
> There is additionally an elephant in the room: *IHTSDO (now SNOMED
> International) has been tied to a single terminology - SNOMED CT*, but it
> would have been better to have had a terminology standards org that was
> independent of any particular terminology, and worked to create a truly
> terminology-independent technology ecosystem, along with technical means of
> connecting terminologies to each other, without particularly favouring any
> one of them. It's just a fact that the world has LOINC, ICDx, ICPC, ICF and
> hundreds of other terminologies that are not going anywhere. What would be
> useful would be to:
>
>- classify them according to meta-model type - e.g. multi-hierarchy
>(Snomed); single hierarchy (ICDx, ICPC, ... ); multi-axial (LOINC); units
>(UCUM, ...), etc
>- build / integrate technology for each major category - I would guess
>< 10
>- help the owning orgs slowly migrate their terminologies to the
>appropriate representation and tools
>- embark on an exercise to graft in appropriate upper level
>ontology/ies, i.e. BFO2, RO, and related ontologies (this is where the <10
>comes from by the way)
>- specify 

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

[Pablo Pazos]

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

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

Can I ask why?


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



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

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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



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




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


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




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


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


- thomas

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

Re: [Troll] Terminology bindings ... again

[A Verhees]

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

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

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

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

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

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

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

Best regards
Bert

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

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

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

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

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

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

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

Best,

Philippe


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