SV: Terminology bindings ... again

2018-03-12 Thread Mikael Nyström
Hi,

It depends on what you mean by scope … There is an agreement between SNOMED 
International and Regenstrief Institute to not batch include concepts that 
directly match LOINC codes in SNOMED CT. However, in general SNOMED CT can have 
concepts that represent the same or similar ideas as LOINC codes.

 Regards
 Mikael



Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
GF
Skickat: den 12 mars 2018 08:54
Till: For openEHR clinical discussions 
Kopia: Thomas Beale 
Ämne: Re: Terminology bindings ... again

The scope of LOINC is NOT the same as the scope of SNOMED.

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

Kattensingel  20
2801 CA Gouda
the Netherlands


On 12 Mar 2018, at 08:39, Mikael Nyström 
> wrote:

Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 

SV: Terminology bindings ... again

2018-03-12 Thread Mikael Nyström
Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions 
Kopia: Openehr-Technical 
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need 

SV: Terminology bindings ... again

2018-03-12 Thread Mikael Nyström
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
Kopia: Openehr-Technical 
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:



term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?
I would like to get a better idea of the requirements.

- 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-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez