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 <mikael.nyst...@liu.se> 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 <openehr-clini...@lists.openehr.org> > Kopia: Openehr-Technical <openehr-technical@lists.openehr.org> > Ä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 <mikael.nyst...@liu.se > <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 <openehr-clini...@lists.openehr.org > <mailto:openehr-clini...@lists.openehr.org>> > Kopia: Openehr-Technical <openehr-technical@lists.openehr.org > <mailto:openehr-technical@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 <thomas.be...@openehr.org > <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 = <"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-clini...@lists.openehr.org <mailto:openehr-clini...@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/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 <mailto:pablo.pa...@cabolabs.com> > +598 99 043 145 <tel:099%20043%20145> > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com <http://www.cabolabs.com/> > https://cloudehrserver.com <https://cloudehrserver.com/> > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > > > _______________________________________________ > openEHR-clinical mailing list > openehr-clini...@lists.openehr.org <mailto:openehr-clini...@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/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 <mailto:pablo.pa...@cabolabs.com> > +598 99 043 145 > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com <http://www.cabolabs.com/> > https://cloudehrserver.com <https://cloudehrserver.com/> > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > > _______________________________________________ > openEHR-clinical mailing list > openehr-clini...@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
