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.pa...@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.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 <+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-clini...@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 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-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
