FHIR Chat · Expansion Question · terminology

Stream: terminology

Topic: Expansion Question

Grahame Grieve (Nov 02 2016 at 18:49):

What should be the result of expanding this?

Grahame Grieve (Nov 02 2016 at 18:49):

<ValueSet>
  <compose>
    <include>
      <system value="http://snomed.info/sct"/>
      <concept>
        <code value="41672002"/>
        <display value="Respiratory disease specialist"/>
      </concept>
      <concept>
        <code value="41672002"/>
        <display value="Respiratory physician"/>
      </concept>
    </include>
  </compose>
</ValueSet>

Grahame Grieve (Nov 02 2016 at 20:06):

my server returns this:

Grahame Grieve (Nov 02 2016 at 20:07):

<ValueSet xmlns="http://hl7.org/fhir">
    <expansion>
        <contains>
            <system value="http://snomed.info/sct"/>
            <code value="41672002"/>
            <display value="Respiratory disease specialist"/>
        </contains>
    </expansion>
</ValueSet>

Rob Hausam (Nov 02 2016 at 21:30):

I think that's a correct response (but not necessarily the only correct response). I think it should be a single 'contains' element with code = 41672002. The 'contains.display' element, if returned, I think is up to the discretion of the server (typically that would be the "preferred term" from the code system - not sure if we say anywhere in this context that it must be from the code system?). I've re-read the description of the expansion process, and I don't see anywhere that we address the issue of duplicate codes in the expansion - there may be something about it in VSD, but I'd have to check. The behavior with all of this seems to be somewhat underspecified, so we may need to address that.

Grahame Grieve (Nov 02 2016 at 21:33):

we say that the display must be a correct display for the code system. And then we also say that the display can be overridden in the value set compose like the one above. (we have a note about the risks of that)

Grahame Grieve (Nov 02 2016 at 21:34):

the question here is: both those displays are defined by snomed, so both are relevant. Can you have an expansion that includes the same concept with more than one display? and I think that if the display is for the user to pick, then that makes perfect sense to do that

Rob Hausam (Nov 02 2016 at 22:38):

OK, I think you're right. I don't find anyting in VSD or elsewhere that says that multiple instances of a particular code can't (or shouldn't) be returned in a value set expansion. And there are clearly use cases where it makes sense to do so, including if abstract or other navigational codes are returned and the output is intended to be grouped/ordered in hierarchical or other ways. Since we do say that ValueSet.compose.include.concept.display is "The text to display to the user for this concept in the context of this valueset", if ValueSet.compose includes two (or more) instances of the code with different display strings, then the obvious intention would be that all of those code/display pairs should be returned in the expansion. So, contrary to my earlier suggestion, I think that we should interepret the specification that way, as it covers all of the use cases without unnecessary restrictions. I don't know if we need to, but if we think that it may be desirable to filter out duplicates in some situations, we could consider adding a 'removeDuplicateCodes' parameter to ExpansionProfile and $expand, either as core or extension.

Grahame Grieve (Nov 02 2016 at 22:43):

so we should clarify this in the spec, because you wouldn't return duplicates if they arose through an union of filters. But you would if they were listed explicitly in a single compose.... y?

Grahame Grieve (Nov 02 2016 at 22:44):

and wouldn't the duplicate or not be directly linked to forUI? when would it be different?

Rob Hausam (Nov 02 2016 at 22:59):

I agree that removing duplicates is typical practice with union (at least in the db world - union vs. union all)
but since it can be done both ways, we should be clear about which one it is
I'm actually thinking that for consistency maybe including the duplicates across the board would be best? - no confusion if we are consistent about it
if the end use doesn't want them, they can be filtered (either if we add a parameter or otherwise)

Grahame Grieve (Nov 02 2016 at 23:01):

duplicates codes with different displays...? I hope that's what you mean.

Grahame Grieve (Nov 02 2016 at 23:03):

well, let's say we did that.... can we have opinions please @Reuben Daniels @Dion McMurtrie @Michael Lawley @John Gresh @Alexander Henket @Russ Hamm @Yunwei Wang @Peter Jordan @Linda Bird @Robert McClure @Ted Klein

Rob Hausam (Nov 02 2016 at 23:04):

that's generally what I mean
but there is a case where even having the same code and same display might be needed, and that's if you introduce navigation or other hierarchy and you have the same code (and display) showing up in two (or more) branches

Robert McClure (Nov 02 2016 at 23:39):

Actually the VSD does have something to say about this in that an expansion code set is only the concept representations (codes here) that are requested in the CLD. But remember the VSD is only informative - speculative actually - about what should be in a fully formed expansion file noting that it is expected to include the required parts (in the expansion code set.). We've had further discussions that this might best be modified to say that the required set of concept information to be included in an expansion code set would be the concept representation, the code system ID and version, and "a default description." It was our expectation that any other information to be included in the "expansion file” (the returned expansion content based on an expansion definition) would be based on a concomitant query to the code system based on an expansion specification that defined what concept elements are also needed in the file. That would include multiple descriptions plus all sorts of other things basd on the fact that you have the concept ID an can get info based on that.

Now you all are combining the "pure" expansion process to get the code list AND the expansion file creation process to yield one final set of code information. We think that can be problematic and this conundrum of "Lets rmove duplicates here but not here" is because you are trying to do two functions in one process. I'd rather see a way that the specific cncept information that you want that is not the required set is defined someplace. I don't think it should be (or is easly made to be) a part of the COMPOSE function.
And BTW I am very much against having duplicates in the expansion. If you want to show multiple, or specific descriptions in the expansion I would like to see some sort of expansion definition that dictates that and I would like to see one concept ID with all the other parts in that same concept element, not multiple “concepts” in the expansion.

Michael Lawley (Nov 03 2016 at 04:22):

I too am very much opposed to expansion returning duplicate codes (except if distinguished by code system version).
Do we really need to provide a mechanism for suppoting this use case? The purist in me shudders; the code system itself can be interrogated to determine a set of "acceptable" synonyms, and the ValueSet allows you to specify a preferred one. This looks like a scenario where the ValueSet is trying to narrow the acceptable ones down further (but not to just one) - is this an 80% ??

Grahame Grieve (Nov 03 2016 at 06:01):

well, remember that 80% is about requirements disagreements, and punting things to extensions. Strictly, that doesn't apply here

Grahame Grieve (Nov 03 2016 at 06:02):

I do think that for UI usage, there's several different reasons to list a concept more than once, whether for different displays, or for different points in a classified list.... those seem reasonable to me, even if it is by extension

Grahame Grieve (Nov 03 2016 at 21:01):

Brief discussion on Vocab call:
- We believe that this is a valid use case - there are circumstances where the same concept may be found more than once in an expansion
- we are concerned about finding the right balance between complexity and effectiveness for specifying how to build value sets to manage this
- we don't want to add any more complexity to the expansion structure because of this

further discussion tabled due to time constraints, and referred back to this thread

Grahame Grieve (Nov 03 2016 at 21:04):

one way to suppor this but cap the complexity this is to say:
- if a value set enumerates concepts in ValueSet.compose.include, explicitly explicitly specifies the same concept more than once with different displays, then the expansion contains the concept as specified
- if there is a ValueSet.compose.include.valueSet, or a ValueSet.compose.include.filter, then the expansion does not contain the same concept more than once

Peter Jordan (Nov 04 2016 at 03:31):

What about implicit value sets returned as a result of a querying via a text filter parameter? Should the server return only one description for each concept - if not, how does it prioritise...say between 2 SCT synonyms that aren't preferred terms.

Grahame Grieve (Nov 04 2016 at 03:32):

server decision how to prioritise

Rob Hausam (Nov 04 2016 at 03:33):

I would add that if the value set expansion contains categorization or hierarchy, then the same concept (with the same or different display) may appear in different sections or branches as appropriate (but there shouldn't be duplicated concepts as siblings)

Grahame Grieve (Nov 04 2016 at 03:34):

yes. also, a present, server discretion, since there's no way to specify such value sets other than by building the expansions directly - but that doesn't mean servers can't define their own ways to do it

Michael Lawley (Nov 04 2016 at 03:42):

@Peter Jordan For SNOMED, every code should have a single preferred term. That is what your server should return regardless of what it matched on. The optional list of designations would be the place to return an indicator of which ones actually matched, either by only including the match ones, or by annotating them with an extension element that says "this one matched"
Of course, then we get into questions of what constitutes a "match" - if your server does acronym expansion, spelling correction, or other fuzzy / sloppy matching, then "match" becomes a nebulous concept.

Peter Jordan (Nov 04 2016 at 04:01):

Thanks @Michael Lawley. There will be some presentation layer challenges with that approach as (naïve?) end users will expect to see responses that directly match their requests - rather than, to use an example, filtering on 'nebulous urine' and receiving 'cloudy urine'. Spelling corrections are a live issue in NZ as we're discovering that there are still some US English spellings in the UK English Language Reference Set (e.g. 'behavior').

Michael Lawley (Nov 04 2016 at 04:04):

I've yet to experience that in practice. Ontoserver has always operated in this way (only display the preferred term regardless of how the match occurred), and we've not had a complaint except where the preferred term itself was considered inappropriate (eg spelling, antiquated language, etc).

Rob Hausam (Nov 04 2016 at 04:10):

It's actually a single preferred term per Language reference set - along the lines of what Peter said, this will likely complicate things when we're working with multiple (combined) editions as we've been discussing (e.g. having both the US and UK English preferred terms)

Michael Lawley (Nov 04 2016 at 04:13):

Yes, you need to choose which language refset you're operating with at the time of expansion, otherwise you're going to end up with a vrey large number of cross-language preferred terms.

Peter Jordan (Nov 04 2016 at 04:13):

Some of our 'industry partners' (NZ Preferred Term for vendors) are highly particular on such things and actively looking for these issues in SCT as the mandated replacement for Read Codes. This I view as a good thing...and we've agreed to use only the UK English Terms in the Language Reference Set that comes with the International Edition.

Michael Lawley (Nov 04 2016 at 04:14):

And they are pursuing this at the SCT end with a language refset rather than at the FHIR end?

Grahame Grieve (Nov 04 2016 at 04:14):

if you want to see SCT with multiple language ref sets, see here: http://fhir3.healthintersections.com.au/snomed/11000201108

Grahame Grieve (Nov 04 2016 at 04:15):

and what you'll see is that having multiple language refsets has broken my PN choosing algorithm, and I have to give it some love

Peter Jordan (Nov 04 2016 at 04:17):

At last week's SNAPP event, we found mapping from NZ Medicinal Product to SCT Pharmaceutical Product quite challenging with both UK and US terms in the Language Refset!!

Rob Hausam (Nov 04 2016 at 04:20):

So, did we get to the point of deciding how to handle that for international servers that may respond to requests by clients from varying jurisdictions and languages?
presumably the server will declare its default edition/language and will use that unless the request explicitly specifies otherwise
that seems like a good use of the (future) Terminology Capability Statement that we discussed on the Vocab call today

Grahame Grieve (Nov 04 2016 at 04:22):

i am presently performing operations in the combined SCT edition unless the version parameter or version in the expansion profile says otherwise

Last updated: Apr 12 2022 at 19:14 UTC