FHIR Chat · Snomed Constraint Expression Language

Stream: terminology

Topic: Snomed Constraint Expression Language

Grahame Grieve (Jul 11 2016 at 23:14):

I'm just looking at task GF#9580

Grahame Grieve (Jul 11 2016 at 23:15):

it proposes replaceing the old query language reference - which I'm doing. but there's QL definitions for the othe properties. can someone provide me with equivalents for them (see QL on page http://hl7-fhir.github.io/snomedct.html)

Rob Hausam (Jul 11 2016 at 23:41):

These are the "full syntax" SNOMED CT Expression Constraint Language representations that should be equivalent to the QL expressions that are currently in the SNOMED CT Filter Properties section.

By Subsumption:
descendantOrSelfOf [concept]

By Reference Set:
memberOf [concept]

These are the only two places on the page where I see the QL being referenced. If there are other places where the ECL is needed, happy to add them.

Grahame Grieve (Jul 11 2016 at 23:42):

yes those 2, correct. what is the ECL equivalent?

Rob Hausam (Jul 11 2016 at 23:42):

By Subsumption:
descendantOrSelfOf [concept]
By Reference Set:
memberOf [concept]

Rob Hausam (Jul 11 2016 at 23:43):

those are the ECL equivalents

Grahame Grieve (Jul 11 2016 at 23:43):

ah ok. they were so similar I didn't notice

Grahame Grieve (Jul 11 2016 at 23:44):

is there an ECL for 'no post-coordination'?

Rob Hausam (Jul 11 2016 at 23:45):

the "[concept]" isn't actually part of the ECL, of course
there is another language specification that we can use for that explicitly, if we need to

Grahame Grieve (Jul 11 2016 at 23:45):

what would it look like in an actual example?
descendantOrSelfOf234234234

Rob Hausam (Jul 11 2016 at 23:57):

a real example would be, in "full" syntax (informative):

descendantOrSelfOf 105590001 |Substance (substance)|

or, in "brief" syntax (normative):

<< 105590001 |Substance (substance)|

that's assuming that you want to include the descriptions
if you don't, it would just be:

descendantOrSelfOf 105590001
or
<< 105590001

Grahame Grieve (Jul 11 2016 at 23:59):

so sholdn't we use the brief format then? or both?

Grahame Grieve (Jul 12 2016 at 00:00):

and is there a brief form for memberOf?

Rob Hausam (Jul 12 2016 at 00:00):

regarding post-coordination, there's a sentence that states:

It is assumed that each particular usage of an expression constraint will clearly identify
whether or not postcoordinated expressions are part of the valid substrate.

But I see no reference in the spec as to how that "identification" is to be done (other than text?)
Maybe @Michael Lawley or @Linda Bird can shed more light on that, if there is some way to do it

Rob Hausam (Jul 12 2016 at 00:01):

yes, the brief format is preferred, as you say
the brief "memberOf" is '^'
we'll have to use legends to explain the symbols, of course, but that should be fine

Grahame Grieve (Jul 12 2016 at 00:04):

ok thx

Robert McClure (Jul 12 2016 at 14:54):

One point I'd like to make is that I'm not in favor of using the phrase "refset" instead of value set. IHTSDO refset is an artifact that includes a number of things, one of which we call a value set. Let's not confuse things by using that phrase.

Grahame Grieve (Jul 12 2016 at 19:13):

we only use it in one specific place:

Grahame Grieve (Jul 12 2016 at 19:13):

By Reference Set
Description Select a set of concepts based on their membership of a SNOMED CT reference set

Grahame Grieve (Jul 12 2016 at 19:13):

given that this is SCT specific, we need to use the correct SCT language, and that's reference set isn't it?

Rob Hausam (Jul 12 2016 at 20:28):

yes, "refset" is the SNOMED CT specific term, and is the one that we should use in this particular context
we shouldn't use it more broadly as an alternative to "value set", as Rob M. points out, but I don't think that is the intent

Michael Lawley (Jul 13 2016 at 01:22):

Note, the whitespace following the keywords in "full" syntax is mandatory (so descendantOrSelfOf12345456 would not be valid)

Grahame Grieve (Jul 13 2016 at 01:23):

thx. that was a copy/paste error out of the spec, not into the spec, fortunately

Michael Lawley (Jul 13 2016 at 01:27):

Whether post coordinated expressions are "part of the valid substrate" basically means it's a context question, not a language question. So, either the terminology server decides, or the context dictates, or the spec (eg FHIR) can say.
I would argue that unless there's an archive of actual expressions somewhere in-context, then it's not useful to attempt to produce a (possibly/probably infinite) expansion of matching expressions.
An ExpansionProfile parameter of "includePostcoordination" (so it defaults to false) might be useful for this?