Hi Koray,
The implicit FHIR ValueSets for SNOMED do not need to be explicitly defined and cover the finite set (with respect to a specific release) of ValueSets that correspond one-to-one with SNOMED reference sets. They also cover the unbounded set of ValueSets that can be defined as "descendants and self of XXX" where XXX is any SNOMED code OR and SNOMED post coordinated expression (FHIR does not impose an arbitrary distinction between a single code and a multi-code expression). This gets you a very long way. Currently, FHIR does not define any implicit ValueSets that correspond to a single ECL expression, but we could propose this and it would be straightforward for terminology services to support. ValueSets in general go beyond this because they allow additional filtering operations beyond those supported by ECL, as well as UNION and EXCLUDE operations between ValueSets (good for re-use), and mixing of code from multiple code systems (hopefully a rare case). Binding to define meaning is a slightly different use-case; you're binding to a single concept (possibly post coordinated) rather than defining the range of a property via a set of possible values. michael -- Dr Michael Lawley Research Group Leader, Senior Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ work: +61 7 3253 3609; mob: +61 427 456 260 ________________________________ From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf of Koray Atalag <k.ata...@auckland.ac.nz> Sent: Saturday, 6 May 2017 11:25 PM To: For openEHR technical discussions Subject: RE: SNOMEDCT - correct representation Hi Michael, You can only define and manage so many ECL valuesets and assign URIs – which is fine. Trouble is the combinations are endless. Therefore IMHO we definitely need ways to embed post-coordinated terms (for defining meaning) and ECL (for valuesets) in terminology bindings. Tom I like your suggestion for a terminology referencing way to include all of the above. I would also argue that we should be able to mix terms from different terminology and ontology systems as well. In computational physiology, where they don’t have an uber-ontology like SNOMED, when defining semantic annotations (our terminology bindings) they can use kind of post-coordination (all URIs): [term1:ontologyA] [relation-may_be_defined_in ontology B] [term2:ontology C] etc. you’ll get the idea. Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of michael.law...@csiro.au Sent: Thursday, 4 May 2017 1:05 a.m. To: openehr-technical@lists.openehr.org Subject: [FORGED] Re: SNOMEDCT - correct representation I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just as descendants of a single concept, or members of a reference set. For an enumeration of concepts and/or a snomed ECL expression, then you can use a Fhir ValueSet and give it a URI. ValueSets also generalise beyond just SNOMED (LOINC for example). Furthermore, there are existing tools to expand them to the set of member concepts, you can include metadata, manage versions etc. This is much more than you get just by encoding ECL in a URI. In case anyone wants to play with ECL expressions and their evaluation you can go here for an interactive page: https://ontoserver.csiro.au/shrimp/ecl.html Also, some brief documentation and click-through examples here https://ontoserver.csiro.au/shrimp/ecl_help.html Regards Michael Sent from my iPhone On 3 May 2017, at 9:08 pm, Diego Boscá <yamp...@gmail.com<mailto:yamp...@gmail.com>> wrote: Seems like the only way right now is creating refsets and referencing them with standard URIs... 2017-05-03 13:02 GMT+02:00 Bert Verhees <bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>>: On 03-05-17 12:53, Thomas Beale wrote: On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar<https://confluence.ihtsdotools.org/display/DOCSCG> and Expression Constraint Language<https://confluence.ihtsdotools.org/display/DOCECL> specs, is how to create a URI (which is the type of a term binding in ADL2<http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>) from a post-coordinated expression or constraint expression. This should be trivial, but I don't see where SNOMED has specified it. True, I was looking for that also, a few days ago. I don't have time to read much now, but there is a document on the SNOMED site on URI's, maybe it is in there? I can take a look later or look in my documentation, I have course materials. I come back to this tomorrow if not someone else already has. The URI spec is here<https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>, but it doesn't address URIs for expressions either. (All the SNOMED language specs appear to be here<https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages> these days - nice and convenient, and also nicely published. We probably should go back to linking to them somewhere on the openEHR site). I checked my course materials from last year, lucky I found it quickly, there is not any mentioning of URI's for expressions, so I guess it does not yet exist. Stupid. Bert _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [VeraTech for Health SL]<https://htmlsig.com/t/000001C268PZ> [Twitter] <https://htmlsig.com/t/000001C47QQH> [LinkedIn] <https://htmlsig.com/t/000001C4DPJG> [Maps] <https://htmlsig.com/t/000001BZTWS7> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif] Diego Boscá Tomás / Senior developer diebo...@veratech.es<mailto:diebo...@veratech.es> yamp...@gmail.com<mailto:yamp...@gmail.com> VeraTech for Health SL +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023<tel:+34%20627%2001%2050%2023> www.veratech.es<http://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<mailto:verat...@veratech.es>. _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto: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
