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> 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-clinical@lists. > openehr.org> > *Kopia:* Openehr-Technical <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/). IMO we > should focus on SNOMED. > > > > On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale <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> *-- 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 > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > > > > -- > > Ing. Pablo Pazos Gutiérrez > pablo.pa...@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-clini...@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://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org