Stream: terminology
Topic: Clarification on CodeSearchSupport valeu set
Carol Macumber (Aug 16 2018 at 15:04):
As described in the Searching for codes in value sets (http://build.fhir.org/valueset.html#search) section, the CodeSearchSupport value set defines the codes that are required for use in TerminologyCapabilities.codeSearch
The value set contains two values
pasted image
The explicit code, with display "Explicit Codes" seems clear in that it includes codes that are either stated in the includes OR in the resulting expansion
The all code, with display "Implicit Codes", by above definition "only includes all codes based on the expansion of the value set".
Should we consider changing all to implicit so its consistent with the spirit of the definition? Though I know i have fallen victim to embedding meaning into the code itself, seeing all but getting back something that is actually more restrictive (expansion members only, compared to expansion members and codes included in the CLD) doesn't seem right, assuming i've understood the defintions correctly
@Rob Hausam @Robert McClure @Ted Klein Clarification on valueset-code-search-support
Rob Hausam (Aug 16 2018 at 15:46):
I think we need to understand better (from @Grahame Grieve) exactly how these codes are intended to behave. It may be that just clarifying the definition text (for 'all' or for both of the codes) will be sufficient? After where our recent discussion on 'descendent' has landed I doubt that we'll be considering changing the 'all' code itself (even if it's rather egregiously incorrect, which it probably isn't).
Carol Macumber (Aug 16 2018 at 17:18):
Agreed. Just read through that descendent thread...and as I admitted, i fell victim to giving meaning to the code :)
Robert McClure (Aug 16 2018 at 18:09):
I'd rather Explicit mean just the codes in the Includes and All mean just codes in the expansion. That way it's a clean difference. Yes, this means the code is not consistent with the meaning but it seems we're going to have to live with that. Boy I'm going to look for "breaking" changes in how the resources are crafted to make sure the community approaches everything as they are forcing terminology to accept. @Grahame Grieve @Carol Macumber @Rob Hausam
Rob Hausam (Aug 16 2018 at 18:25):
I still want to hear from @Grahame Grieve what he intended/expected for the behavior around the use of those codes. We can see how that matches with what you just said @Robert McClure. The ideal would be to just be able to clarify the definitions/documentation to make that understandable and consistent, but we can see.
Grahame Grieve (Aug 16 2018 at 19:05):
I think I made a copy/paste error - "only" should not be in the definition of "all"
Grahame Grieve (Aug 16 2018 at 19:06):
I'm open to argument that expansions should be excluded from "explicit" or that we should have 3 codes
Rob Hausam (Aug 16 2018 at 19:12):
Have you implemented this yet? Has anyone else?
Grahame Grieve (Aug 16 2018 at 19:14):
well, I've implemented the code parameter using explicit, if that's what you mean. I could implement all (used to) but I lost that code at some stage
Robert McClure (Aug 16 2018 at 19:50):
If we can, then I would have Explicit mean only codes in the Include, Expansion (or something like that) to mean only codes in the expansion, and All to mean the union of Explicit and Expansion
Grahame Grieve (Aug 16 2018 at 19:55):
I think I can make that change now
Grahame Grieve (Aug 16 2018 at 19:55):
but no
Grahame Grieve (Aug 16 2018 at 19:55):
the question is: does the server perform some expansion in the background, and then search on that. Ir does it only search on what's explicitly stated in the resource
Grahame Grieve (Aug 16 2018 at 19:56):
so your 3 codes are at cross purposes with that
Grahame Grieve (Aug 16 2018 at 19:56):
the definition of the actual parameter in question is
Grahame Grieve (Aug 16 2018 at 19:56):
ValueSet.expansion.contains.code | ValueSet.compose.include.concept.code
Grahame Grieve (Aug 16 2018 at 19:56):
which is wrong.... it should at a minimum be
Grahame Grieve (Aug 16 2018 at 19:59):
(ValueSet.expansion.contains | ValueSet.expansion.contains.descendants()).code | ValueSet.compose.include.concept.code
Grahame Grieve (Aug 16 2018 at 20:00):
so it's specified to at least include explicitly mentioned codes in both compose and expansion
Grahame Grieve (Aug 16 2018 at 20:00):
but subject to the proviso in http://build.fhir.org/valueset.html#search
Grahame Grieve (Aug 16 2018 at 20:14):
can I fix the FHIRPath statement as a technical correction?
Rob Hausam (Aug 16 2018 at 20:26):
Did you mean 'ValueSet.expansion.contains.code | ValueSet.expansion.contains.descendants()).code | ValueSet.compose.include.concept.code' (expecting the .code should be there on all of them)? I think this change probably is ok now as a technical correction - but I usually tend to be inclined toward fixing things.
Grahame Grieve (Aug 16 2018 at 20:29):
well, at the moment it says to select expansion codes or compose codes, but misses nested expansion codes. which is clearly at odds with the intent in the definition
Rob Hausam (Aug 16 2018 at 20:30):
yes, I agree - that's what ValueSet.expansion.contains.descendants()).code is doing
Rob Hausam (Aug 16 2018 at 20:31):
and I can't help but notice the spelling of 'descendants' :)
Grahame Grieve (Aug 16 2018 at 20:35):
yes, that's an external spec that matches xpath
Grahame Grieve (Aug 16 2018 at 20:36):
but the use is actually quite different - it's actually misnamed worse because it's all contained sub-elements
Rob Hausam (Aug 16 2018 at 20:36):
right - I get that
Rob Hausam (Aug 16 2018 at 20:37):
and I wasn't thinking about whether it is misnamed - just noticing that it uses the "correct" spelling of the word
Grahame Grieve (Aug 16 2018 at 20:38):
yes
Michael Lawley (Aug 17 2018 at 04:44):
Is there no use-case for wanting to search for ValueSets that mention a code in the compose.exclude ?
Michael Lawley (Aug 17 2018 at 04:45):
For example, I'm planning to retire a code and want to find all the ValueSet definitions that will be affected and need updating
Rob Hausam (Aug 17 2018 at 05:54):
good point - that's something to consider
I think the results could be quite confusing, though, unless you could specify explicitly that you were searching for excluded codes
Michael Lawley (Aug 17 2018 at 05:57):
When I originally thought about this functionality it fell into the cases of "you're searching across expansions" or "you're searching across the CLD", but I can see that the "best-effort search across include criteria" is also a reasonable desire.
Michael Lawley (Aug 17 2018 at 05:59):
Another issue is whether you also search across imported valuesets, and what happens when there is only a codesystem mentioned but no other criteria (ie. include the whole codesystem)
Robert McClure (Aug 17 2018 at 15:59):
@Michael Lawley You are right on all counts. Perhaps Explicit should be the entire Composebut yes - what do we do with an included value set or an entire code system? I'd say those would be excluded. As for Expansion - it should be the end-result expansion, how ever it was crafted.
Carol Macumber (Aug 21 2018 at 13:30):
Is there a tracker for this? happy to create one if necessary
Robert McClure (Aug 21 2018 at 17:06):
I have not made one. @Rob Hausam ?
Rob Hausam (Aug 21 2018 at 17:08):
I haven't added a tracker for this one.
Carol Macumber (Sep 04 2018 at 14:04):
Ticket 17992 opened
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17792&start=0
Last updated: Apr 12 2022 at 19:14 UTC
