subject:"Re\: Terminology bindings ... again"

Re: Terminology bindings ... again

2018-03-12 Thread Bert Verhees


On 12-03-18 08:51, GF wrote:

Nodes in an archetype coded in LOINC and data coded in SNOMED.


LOINC defines a way to asks clinical questions which coded answers may 
be represented by SNOMED-CT. LOINC has the worldwide integration and 
SNOMED-CT has the  detailed semantics, and is the leading global 
clinical terminology.  So the both are well matched partners, and as a 
consequence the owners of both coding systems, IHTSDO and the 
Regenstrief Institute agreed to a plan to integrate both coding systems 
to one coding system. This plan defines a cooperative work, which 
started in 2014, and according to this plan, all LOINC-concepts will 
have SNOMED-CT concepts somewhere in 2018.


Bert

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

2018-03-12 Thread GF

Hi,

As far as I remember this separation was the result of agreements between LOINC 
and SNOMED.

When I was looking for codes that could be attached to nodes in the archetype I 
was referred to LOINC.
SNOMED made it clear that they were not the party that could help me.

In a way it can make sense.
SNOMED has a real ontology behind it. And is using the Open World assumption.
LOINC is NOT an terminology but as I see it a Classification with rules and a 
syntax.

LOINC and Archetypes are really Closed World artefacts.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 12 Mar 2018, at 09:12, Birger Haarbrandt  wrote:
> 
> Hi Gerard,
> 
> are you able to provide more information on the reasoning that led to this 
> decision? Maybe links to documents or any other insights? This would be quite 
> interesting for our acitivities in Germany.
> 
> Best,

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

2018-03-12 Thread Diego Boscá

Interesting to know, although I don't see that as an option in latest FHIR
spec
https://www.hl7.org/fhir/snomedct.html#implicit

2018-03-12 11:15 GMT+01:00 :

> FHIR also supports the expression language in the URL with, for example,
> http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484
>
> But note that these URIs (the above and your isa/ one below) are defined
> by HL7 FHIR, not SNOMED International. Technically they identify FHIR
> ValueSets that expand to the set of codes you want.
>
> You could do a lot worse than adopting the FHIR ValueSet mechanism for
> binding. There are some excellent terminology servers out there (full
> disclosure, one of them, Ontoserver, is mine).
>
> Michael
>
>
> Sent from my iPhone
>
> On 12 Mar 2018, at 7:00 pm, Diego Boscá  wrote:
>
> Probably we should have a look at https://confluence.
> ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
> FHIR also uses the same base uri, but builds the URI using a custom syntax
> such as http://snomed.info/sct?fhir_vs=isa/138875005
> But looking at the Snomed URI standard I assume they will just go with
> that in the future
>
> 2018-03-12 1:38 GMT+01:00 Pablo Pazos :
>
>> 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
>>>

Re: Terminology bindings ... again

2018-03-12 Thread Diego Boscá

Probably we should have a look at
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax
such as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that
in the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos :

> 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)  
>> -- Apgar score at 1 minute notes = <"some notes">
>>  min_version = <"2017-02-01">
>>  etc = <"etc">
>>  >
>> ["id26"] = (CONSTRAINT_BINDING) > <"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-clinical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> 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-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr

Re: Terminology bindings ... again

2018-03-12 Thread Diego Boscá

Without knowing the internal decision process, I would say that has
something to do with the fact that HL7 guys in CIMI already used Loinc for
describing document and section codes in CDA (not being uncommon that they
just define new Loinc codes to new kinds of documents and sections).
Same can be achieved with Snomed BTW, Spanish Snomed Extension includes
codes for the Compositions, Sections and Entries defined in the national
archetypes

2018-03-12 9:12 GMT+01:00 Birger Haarbrandt :

> Hi Gerard,
>
> are you able to provide more information on the reasoning that led to this
> decision? Maybe links to documents or any other insights? This would be
> quite interesting for our acitivities in Germany.
>
> Best,
>
> --
>
>
>
> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical
> Informatics (PLRI) Technical University Braunschweig and Hannover Medical
> School Software Architect HiGHmed Project *
> Tel: +49 176 640 94 640 <+49%20176%2064094640>, Fax: +49 531/391-9502
> <+49%20531%203919502>
> birger.haarbra...@plri.de
> www.plri.de
>
>
>
>
> Am 12.03.2018 um 08:51 schrieb GF:
>
> CIMI made the decision to use LOINC for the ‘question' part of the
> statement.
> And SNOMED for the ‘answer’ part.
> Leading to: Question = Answer, or something coded in LOINC is something
> coded in SNOMED.
> Nodes in an archetype coded in LOINC and data coded in SNOMED.
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 12 Mar 2018, at 01:38, Pablo Pazos  wrote:
>
> 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.
>
>
>
>
> ___
> openEHR-clinical mailing 
> listopenEHR-clinical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

2018-03-12 Thread Birger Haarbrandt


Hi Gerard,

are you able to provide more information on the reasoning that led to 
this decision? Maybe links to documents or any other insights? This 
would be quite interesting for our acitivities in Germany.


Best,

--
*Birger Haarbrandt, M. Sc.
Peter L. Reichertz Institut for Medical Informatics (PLRI)
Technical University Braunschweig and Hannover Medical School
Software Architect HiGHmed Project *
Tel: +49 176 640 94 640, Fax: +49 531/391-9502
birger.haarbra...@plri.de
www.plri.de



Am 12.03.2018 um 08:51 schrieb GF:
CIMI made the decision to use LOINC for the ‘question' part of the 
statement.

And SNOMED for the ‘answer’ part.
Leading to: Question = Answer, or something coded in LOINC is 
something coded in SNOMED.

Nodes in an archetype coded in LOINC and data coded in SNOMED.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 12 Mar 2018, at 01:38, Pablo Pazos > wrote:


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.




___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org




___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

2018-03-12 Thread GF

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 
> <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  <mailto:mikael.nyst...@liu.se>> 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 
> <mailto:openehr-clinical-boun...@lists.openehr.org>] För Pablo Pazos
> Skickat: den 12 mars 2018 01:39
> Till: For openEHR clinical discussions  <mailto:openehr-clinical@lists.openehr.org>>
> Kopia: Openehr-Technical  <mailto:openehr-techni...@lists.openehr.org>>
> Ä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/ 
> <https://loinc.org/collaboration/snomed-international/>). IMO we should focus 
> on SNOMED.
>  
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale  <mailto:thomas.be...@openehr.org>> 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 = <http://snomedct.info/id/169895004 
> <http://snomedct.info/id/169895004>> -- 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 =

Re: Terminology bindings ... again

2018-03-12 Thread GF

CIMI made the decision to use LOINC for the ‘question' part of the statement.
And SNOMED for the ‘answer’ part.
Leading to: Question = Answer, or something coded in LOINC is something coded 
in SNOMED.
Nodes in an archetype coded in LOINC and data coded in SNOMED.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 12 Mar 2018, at 01:38, Pablo Pazos  wrote:
> 
> 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.

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

2018-03-12 Thread Pablo Pazos

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  openehr.org>
> *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 = <http://snomedct.info/id/169895004> *-- 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
>- somet

Re: Terminology bindings ... again

2018-03-11 Thread Pablo Pazos

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

RE: Terminology bindings ... again

2017-07-19 Thread Koray Atalag

Hi Tom,

I think min_version can be problematic as certain terms can be deprecated in 
future versions and then this naming could be misleading. That said for SNOMED 
it’ll still be present in future releases just marked as inactive. For other 
terminologies this cannot be guaranteed. BTW SNOMED uses term Effective Time

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Tuesday, 18 July 2017 2:19 a.m.
To: Openehr-Technical; For openEHR clinical discussions
Subject: Terminology bindings ... again

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

Re: Terminology bindings ... again

2017-07-18 Thread Bert Verhees

When you add the descriptions in SNOMED, language of the SNOMED-database 
would be important, version is already there, I would say "version" 
instead of min_version, it makes it more generic usable.


Bert


On 17-07-17 16:19, 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-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

Re: Terminology bindings ... again

RE: Terminology bindings ... again

Re: Terminology bindings ... again

12 matches

Site Navigation

Mail list logo

Footer information