Terminology bindings ... again

Diego Boscá yampeku at gmail.com
Mon Mar 12 06:36:51 EDT 2018


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 <Michael.Lawley at csiro.au>:

> 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á <yampeku at gmail.com> 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 <pablo.pazos at cabolabs.com>:
>
>> 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 <thomas.beale at 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> -- 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 <http://www.arssemantica.com>
>>> Consultant, ABD Team, Intermountain Healthcare
>>> <https://intermountainhealthcare.org/>
>>> Management Board, Specifications Program Lead, openEHR Foundation
>>> <http://www.openehr.org>
>>> Chartered IT Professional Fellow, BCS, British Computer Society
>>> <http://www.bcs.org/category/6044>
>>> Health IT blog <http://wolandscat.net/> | Culture blog
>>> <http://wolandsothercat.net/>
>>>
>>> _______________________________________________
>>> openEHR-clinical mailing list
>>> openEHR-clinical at lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_l
>>> ists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pazos at cabolabs.com
>> +598 99 043 145 <+598%2099%20043%20145>
>> skype: cabolabs
>> <http://cabolabs.com/>
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/000001C4DPJG> [image: Maps]
> <https://htmlsig.com/t/000001BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebosto at veratech.es
> yampeku at 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 veratech at veratech.es.
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [image: Maps]
<https://htmlsig.com/t/000001BZTWS7>

Diego Boscá Tomás / Senior developer
diebosto at veratech.es
yampeku at 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 veratech at veratech.es.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180312/9ef2bdbc/attachment-0001.html>


More information about the openEHR-clinical mailing list