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.


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.



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:

Also, some brief documentation and click-through examples here


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 
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 
 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 
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 
but it doesn't address URIs for expressions either.

(All the SNOMED language specs appear to be 
 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 



openEHR-technical mailing list


[VeraTech for Health SL]<https://htmlsig.com/t/000001C268PZ>

[Twitter] <https://htmlsig.com/t/000001C47QQH>  [LinkedIn]  
<https://htmlsig.com/t/000001C4DPJG>  [Maps]  

Diego Boscá Tomás / Senior developer

VeraTech for Health SL
+34 961071863<tel:+34%20961%2007%2018%2063> / +34 

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 
openEHR-technical mailing list
openEHR-technical mailing list

Reply via email to