FHIR Chat · Different SNOMED relationships

Stream: terminology

Topic: Different SNOMED relationships

Jean Duteau (Apr 29 2020 at 22:09):

I am trying to define a value set on SNOMED CT where the codes are a direct child of a concept, so not is-a but child. I'm trying to find a reference that lists all of the filter properties that I can use with SNOMED and am drawing a blank. i.e. is-a, child, parent, etc. Does such a page exist either in the FHIR spec or on the SNOMED site?

Grahame Grieve (Apr 29 2020 at 22:10):

http://hl7.org/fhir/snomedct.html

Grahame Grieve (Apr 29 2020 at 22:11):

we should add descendent-of to that page

Jean Duteau (Apr 29 2020 at 22:13):

so right in front of me with the big title "SNOMED CT Filters". I'll go have a liedown now. :)

Grahame Grieve (Apr 29 2020 at 22:15):

we all need one of those

Michael Lawley (Apr 29 2020 at 22:24):

Doesn't need anything snomed-specific, just filter: parent = 12345
parent and child should be defined for all code systems (or all that have hierarchy)

Grahame Grieve (Apr 29 2020 at 22:25):

that is immediate children?

Michael Lawley (Apr 29 2020 at 22:26):

yes, with ancestor = 12345 as all descendants (Ontoserver supports this property by default)

Jean Duteau (Apr 29 2020 at 22:55):

so how do I represent that with the FHIR filter syntax? I get "This value set could not be expanded by the publication tooling: Error from server: The filter "parent = 255620007" was not understood in the context of http://snomed.info/sct" so maybe my filter is correct but the FHIR terminology server doesn't handle that?

Grahame Grieve (Apr 29 2020 at 22:59):

tx.fhir.org only supports the filters

concept is-a [id]
concept descendent-of [id]
concept in [list]

It doesn't support other filters. Adding others is on my todo list.

Michael Lawley (Apr 29 2020 at 23:03):

does tx.fhir.org support ECL-based implicit ValueSets? eg http://snomed.info/sct?fhir_vs=<!255620007

Grahame Grieve (Apr 29 2020 at 23:06):

no. ECL is on my todo list

Michael Lawley (Apr 30 2020 at 00:59):

Can't wait for HAPI's new RemoteTerminologyServiceValidationSupport to drop :-)

Grahame Grieve (Apr 30 2020 at 01:11):

oh?

Michael Lawley (Apr 30 2020 at 04:35):

I'm working on the assumption that IG tooling will be able to "fail over" to an alternate terminology service when the default one has limitations. (I may be leaping to unfounded conclusions)