Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

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

On Wed, Mar 14, 2018 at 8:56 PM, Mikael Nyström 
wrote:

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



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

http://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]

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


- thomas


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


Hi Pablo,

I totally agree with you.

   Regards

   Mikael

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

*Sent:* den 13 mars 2018 19:01
*To:* For openEHR clinical discussions 

*Cc:* For openEHR technical discussions 


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

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

Shouldn't we contribute?

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




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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Pablo,

Yes, of cause it is! My main point was that a statistical classification is a 
simpler product than a clinical ontology and it is therefore also easier to 
implement a statistical classification than a clinical ontology. But if your 
use case require a clinical ontology instead of a statistical classification, 
you need to accept that it is more difficult to implement a clinical ontology 
than a statistical classification.

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: den 14 mars 2018 23:58
To: For openEHR technical discussions 
Subject: RE: [Troll] Terminology bindings ... again

But ICD is a statistical not a clinical tool.

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

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

   Regards
   Mikael


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


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

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

Hi John,

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

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

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

Best,

Philippe

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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe

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

Regards
Mikael


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

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

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

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

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

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

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

Best,

Philippe


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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe,

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

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

   Regards
   Mikael


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


Thomas,

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

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

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

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

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

Philippe

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



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

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

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

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

The third killer feature would have be

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Pablo,

I totally agree with you.

   Regards
   Mikael


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

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

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


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



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

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

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

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

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

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

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

  *   classify them according to meta-model type - e.g. multi-hierarchy 
(Snomed); single hierarchy (ICDx, ICPC, ... ); multi-axial (LOINC); units 
(UCUM, ...), etc
  *   build / integrate technology for each major category - I would guess < 10
  *   help the owni

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Tom,

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

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

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

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

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

   Regards
   Mikael


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: den 13 mars 2018 15:21
To: openehr-technical@lists.openehr.org; For openEHR clinical discussions 

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




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

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

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

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

The third killer feature would have been to make translation tools work on the 
basis of legacy vocabulary and new ref-sets, not on the ba

RE: [Troll] Terminology bindings ... again

[Pablo Pazos]

But ICD is a statistical not a clinical tool.

On Mar 14, 2018 7:10 PM, "Mikael Nyström"  wrote:

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

RE: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi,

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

   Regards
   Mikael


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


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

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

Hi John,

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

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

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

Best,

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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

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


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

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

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


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


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


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

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

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

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


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


- thomas

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

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

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

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

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

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

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

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

Philippe


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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

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

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

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

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

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

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

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

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

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

As 

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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


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


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


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


- thomas

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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

Re: [Troll] Terminology bindings ... again

[Thomas Beale]

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


Bert,

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


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




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


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

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


Translated in technological concepts, my own take is that is means 
switching:
- from a record oriented vision to a project management vision (a 
record is the place where you optimize your own decision support 
ability through keeping the signal/noise ratio as high as possible ; a 
project manager is the place where people build/feed/contribute to a 
set of shared processes).




I don't quite agree here: because the 'record' (properly conceived) is 
the only thing that exists to chart the long-term situation of the 
patient, as doctors retire, nurses go on holidays, patients themselves 
move to new cities or countries. What can you trust to tell the story 
from your childhood asthma to your 2 pregnancies and births, to your 
hypertension and type 2 diabetes? Or even just your 10 year battle with 
one of the lesser cancers (very common) or lifelong management of a 
single disease. There is only the longitudinal health record.


I agree though with the project management notion of course. Our recent 
work on Task Planning 
is 
trying to get up to this next level and join 'model' care pathways with 
real patient care plans and team-based care processes. It's going to 
take some years to get it really sorted out, but I think we are on the 
right path. I have seen the latest increment of the Activity-Based 
Design work at Intermountain Healthcare last week - we are converging.


So when I say the 'EHR' I also include informational artefacts from 
long-running Planning and work processes, not just what we have today, 
which is observations, decisions, orders, and a record of actions done.


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




I think this revolution is starting. Now it is becoming clearer to the 
industry what has been obvious to us - that no single provider creates 
all the data that relate to the patient, so the long term solution is 
healthcare data and major services (workflow / process) must eventually 
be part of a back-end system that isn't owned by any product vendor or 
care delivery location, but instead managed on behalf of the patient by 
a trusted third party.


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


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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

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

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

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

I was fed at the proper source ;-)

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

Re: [Troll] Terminology bindings ... again

[Karsten Hilbert]

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

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

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

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

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

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

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

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

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

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

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

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

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

Karsten

(speaking from a German healthcare perspective only)
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

Re: [Troll] Terminology bindings ... again

[Philippe Ameline]

Bert,

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

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

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

Translated in technological concepts, my own take is that is means
switching:
- from a record oriented vision to a project management vision (a record
is the place where you optimize your own decision support ability
through keeping the signal/noise ratio as high as possible ; a project
manager is the place where people build/feed/contribute to a set of
shared processes).
- from a "care places centered" system (the patient moves from silo to
silo, from record to record) to a system "federated by the person"
environment. To put it simply, it is a genuine Copernican revolution
where individual, instead of having siloed information stored about
themselves in every "box" they cross, would own a system in support of
their life long holistic vision and ask their services providers to
contribute to it (means to join a team).

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

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

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

Best,

Philippe


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