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.law...@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á <yamp...@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.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_l >>> ists.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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@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 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
