Terminology bindings ... again

Pablo Pazos pablo.pazos at cabolabs.com
Mon Mar 12 03:27:57 EDT 2018


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 <mikael.nystrom at 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-
> bounces at lists.openehr.org] *För *Pablo Pazos
> *Skickat:* den 12 mars 2018 01:39
> *Till:* For openEHR clinical discussions <openehr-clinical at lists.
> openehr.org>
> *Kopia:* Openehr-Technical <openehr-technical at 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/). 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_lists.openehr.org
>
>
>
>
> --
>
> Ing. Pablo Pazos Gutiérrez
> pablo.pazos at cabolabs.com
> +598 99 043 145 <099%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
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pazos at cabolabs.com
+598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180312/964c3bb8/attachment-0001.html>


More information about the openEHR-clinical mailing list