FHIR Chat · ValueSet with SNOMED CT Reference Set · terminology

Stream: terminology

Topic: ValueSet with SNOMED CT Reference Set

Alexander Henket (Sep 22 2020 at 01:04):

Just checking: What would a SNOMED CT reference set reference in a FHIR ValueSet look like? Suppose:

SNOMED CT: ^42931000146101| Dutch non-drug allergen simple reference set (foundation metadata concept)|

Would that look like this?

    <compose>
        <include>
            <system value="http://snomed.info/sct"/>
            <filter>
                <property value="concept"/>
                <op value="in"/>
                <value value="42931000146101"/>
            </filter>
        </include>
    </compose>

Liam Barnes (Sep 22 2020 at 01:15):

That looks good to me. Alternatively you could also do

   <compose>
        <include>
            <system value="http://snomed.info/sct"/>
            <filter>
                <property value="constraint"/>
                <op value="="/>
                <value value="^42931000146101| Dutch non-drug allergen simple reference set (foundation metadata concept)|"/>
            </filter>
        </include>
    </compose>

Alexander Henket (Sep 22 2020 at 02:32):

Thanks! The alternative looks too SNOMED-dy to me. Harder to parse for multi purpose parsers

Michael Lawley (Sep 22 2020 at 21:28):

Beware - the in operator for CodeSystems other than SNOMED treats the value as a comma-separated list of codes, so the semantics is different. Either way you need a SNOMED-aware Terminology Server

Robert McClure (Sep 23 2020 at 20:57):

@Alexander Henket, @Michael Lawley's concerns are actually understated if my understanding is correct. The REQUIRED binding in compose to the FilterOperator value set means that in is "In set" meaning The specified property of the code is in the set of codes or concepts specified in the provided value (comma separated list). So a comma separated list is expected. I think SNOMED has bent that if it uses "in" to mean something different, like "there are a set of codes in a refset identified by this ID." I suggest we make it more clear that whatever operator is best, it is clearly only understood in the context of SNOMED CT. Perhaps a better approach would be to reference the refset as a value set to be used as the source membership of the new value set. We'd do that by using the refset id in a url that identifies the refset directly. I'd assume there is already a standard SNOMED-defined way that constructs a refset url?

Alexander Henket (Sep 23 2020 at 22:06):

I really want one syntax to rule them all if possible so no syntax switching based on target codesystem. You are right that the use of "in" for SNOMED seems different than for other systems. That could/should be addressed. Preferably in a way that does not require supporting ECL or similar

Grahame Grieve (Sep 24 2020 at 00:14):

yes, well, the fault here is mine. The canonical definition of how to do this in Snomed CT is on this page: http://hl7.org/fhir/snomedct.html#implicit, and it is:

<ValueSet xmlns="http://hl7.org/fhir">
  ...
  <compose>
    <include>
      <system value="http://snomed.info/sct"/>
      <filter>
        <property value="concept"/>
        <op value="in"/>
        <value value="[sctid]"/>
      </filter>
    </include>
  </compose>
</ValueSet>

Grahame Grieve (Sep 24 2020 at 00:17):

However as @Robert McClure right points out, that you can do this isn't clear from the definition of in:

The specified property of the code is in the set of codes or concepts specified in the provided value (comma separated list).

What's not clear - but I certainly always intended to mean - is that 'in' is semantic, not syntactical. So a concept is "in" a the property if the property value is a reference to a reference set.

This is not SNOMED CT specific - at least the definition is not. The instantiation of it in SCT is SCT specific

Alexander Henket (Sep 24 2020 at 00:19):

So is this just about wordsmithing something, or is there more to it?

Grahame Grieve (Sep 24 2020 at 00:19):

I think it's about word smithing.

Alexander Henket (Sep 24 2020 at 00:20):

(good) ... I thought it was a nice and concise expression as it was. With a little word smithing it could be even better

Alexander Henket (Sep 24 2020 at 00:21):

Need a ticket? I'll create one after some sleep tomorrow if needed

Michael Lawley (Sep 24 2020 at 01:06):

So, it's really about how you interpret the provided value, and that is CodeSystem-specific?
I don't think this helps @Alexander Henket desire for a common semantic across code systems (if I'm understanding correctly)

Michael Lawley (Sep 24 2020 at 01:09):

Following @Robert McClure 's idea, there is a ValueSet URI for every Reference Set, so you could do compose.include.valueSet=[URI] where the URI is http://snomed.info/sct?fhir_vs=refset/42931000146101

Alexander Henket (Sep 24 2020 at 10:19):

Does that work for extension ref sets? We have a growing number of those in NL. Are those hosted centrally too?

Alexander Henket (Sep 24 2020 at 10:25):

So, it's really about how you interpret the provided value, and that is CodeSystem-specific?

Yes that remains unless the word smithing leads to a consistent picture again. For SNOMED the conceptId is a refset/valueset, for other systems it is just a code.

Why do you even need "in [code, code, code]" for anything when you could just include the codes separately? is

  <compose>
    <include>
      <system value="http://example.org"/>
      <filter>
        <property value="concept"/>
        <op value="in"/>
        <value value="1234,5678"/>
      </filter>
    </include>
  </compose>

Not equivalent to:

  <compose>
    <include>
      <system value="http://example.org"/>
      <concept>
        <code value="1234"/>
        <display value="display"/>
      </concept>
      <concept>
        <code value="5678"/>
        <display value="display"/>
      </concept>
    </include>
  </compose>

Grahame Grieve (Sep 24 2020 at 14:45):

for other systems it is just a code

That's not what I said

Grahame Grieve (Sep 24 2020 at 14:46):

yes, you could do in by repeating equals. sure. And when you have 2-3 codes, neither here nor there. It starts to be different on bulk

Grahame Grieve (Sep 24 2020 at 14:47):

btw, LOINC, "in" when pointing to a code in the multi-axial heirarchy has the same meaning as snomed

Alexander Henket (Sep 24 2020 at 16:14):

Happy to file the ticket still, but although I think we agreed that word smithing could be in order, I'm a little unsure of what to ask for exactly.

Grahame Grieve (Sep 24 2020 at 16:15):

ask for the wording to be improved and reference this thread in Zulip

Robert McClure (Sep 24 2020 at 16:28):

@Alexander Henket

Does that work for extension ref sets? We have a growing number of those in NL. Are those hosted centrally too?

@Michael Lawley Should answer that one too but I'd assume it does as long as you specify the correct version (the edition with the extension I'd assume) in the version element for that compose (or specific part of the compose.) Do others agree?

Grahame Grieve (Sep 24 2020 at 16:29):

yes. it works for extension refsets (though the server needs to know them)

Alexander Henket (Sep 24 2020 at 16:35):

Maybe my assumption was wrong: you don't actually go to http://snomed.info/sct?fhir_vs=refset/42931000146101, but rather disect that and lookup the refset in whatever way was implemented at that server?

Alexander Henket (Sep 24 2020 at 16:35):

In any case: http://snomed.info/sct?fhir_vs=refset/42931000146101 does not lead to anything by itself

Grahame Grieve (Sep 24 2020 at 16:40):

it's a canonical URL, not a literal web reference. All the value set URIs work like that

Alexander Henket (Sep 24 2020 at 16:56):

Right my mistake. It looked so very much like something that resolves... wishful thinking on my behalf.

In any case, looking at the spec it seems there almost always multiple of ways to do the same thing basically. Implicit value set versus filter on is-a is one of those too.

Were those specification alternatives born out of necessity?

Grahame Grieve (Sep 24 2020 at 17:05):

implicit value sets are extremely useful. Very very useful indeed.

Grahame Grieve (Sep 24 2020 at 17:06):

but they're not a different way to do the same thing - they are explicitly built on the same approach

Michael Lawley (Sep 26 2020 at 03:21):

In all cases, the url parameter to $expand is a URI (Identifier) and not an URL (Location) -- you do not resolve it as a URL to find a ValueSet definition.
For resolving SNOMED reference sets, it is of course up to the terminology server to support. Without an explicit reference to a version of SNOMED, servers will use a default version (often in combination with a default Edition, commonly the International Edition, but alternatively the local Edition - eg AU or NL or ...).
It is also valid to include the Edition or Version in the implicit ValueSet URI -- http://snomed.info/sct/11000146104?fhir_vs=refset/42931000146101 or http://snomed.info/sct/11000146104/version/20200331?fhir_vs=refset/42931000146101 for example

Michael Lawley (Sep 26 2020 at 03:24):

Implicit ValueSets have a number of core benefits:

• you don't need to pre-define a ValueSet to use it
• the URI is a very compact representation and you can easily generate the URIs dynamically
• you can use GET requests for the $expand, which are cacheable (the alternative of POSTing a dynamically generated explicit ValueSet is not)

Michael Lawley (Sep 26 2020 at 03:31):

@Grahame Grieve can you elaborate on the meaning of

  <compose>
    <include>
      <system value="http://loinc.org"/>
      <filter>
        <property value="concept"/>
        <op value="in"/>
        <value value="[partcode]"/>
      </filter>
    </include>
  </compose>

My reading of http://build.fhir.org/loinc.html#4.3.3.9.3 (even though it references only parent and ancestor) suggests that in should be used only when multiple comma-separated codes are provided and the semantics is "equals any". This seems far removed from the SNOMED reference set semantics where the semantics is (roughly) 'belongs to any of the indirectly referenced code sets identified by the supplied code'.

Grahame Grieve (Sep 28 2020 at 22:35):

My reading of http://build.fhir.org/loinc.html#4.3.3.9.3 (even though it references only parent and ancestor) suggests that in should be used only when multiple comma-separated codes are provided

I think you're reading it wrong. comma separated part codes. not comma separated codes.

Michael Lawley (Oct 05 2020 at 05:34):

Sure, part codes, but you haven't explained the meaning of the compose fragment above, and what I'm trying to establish is that for a filter like:

<filter>
        <property value="concept"/>
        <op value="in"/>
        <value value="[code]"/>
</filter>

has different interpretations depending on whether the system is http://snomed.info/sct or not

Last updated: Apr 12 2022 at 19:14 UTC