Stream: terminology
Topic: revisit ExpansionProfile resource
Rob Hausam (Jul 11 2016 at 19:54):
Creating this topic to continue the discussion originally begun on the HAPI stream at
https://chat.fhir.org/#narrow/stream/hapi/topic/codeSystem.20.26.20valueSet.20
and continued on the Vocab WG conference call on Thursday (July 7).
Notes from the Vocab call minutes include:
#10277 - Discussion/revisit expansion profile resource
This item is about the flags at the bottom of the expansion profile. Michael Lawley feels that leaving these in the expansion profile will lead to an explosion of permutations of the profiles. Rob McClure spoke about his seeing the need and sense of breaking these out of the expansion profile, but it is not clear if they should be in the definition, or a separate set of arguments to the service. Ted spoke about how he sees the issue, and what is controlling and what is persisted as something the documents the expansion resource. We had an robust discussion about this resource and the kinds of operations needed to expand value sets, and what has to be in the expansion and how it may and maybe should differ from what is in the VSD. Jim, Rob M, and Ted all agree that it should be absolutely forbidden that anything that is not explicitly in the expansion as per the VSD be included as some kind of addition. There seemed to be agreement that the parameters used to subset the expansion from what would 'normally' be in it from the VSD be documented in the metadata of the expansion itself. Rob H is in agreement with all the concerns expressed. It needs to be explicit that adding to the set of codes in the expansion is neither the intent nor should it be permitted in any way. This is probably solved with improved documentation.
The tracker for this is GF#10277.
Grahame Grieve (Jul 11 2016 at 20:17):
" all agree that it should be absolutely forbidden that anything that is not explicitly in the expansion as per the VSD be included as some kind of addition" - this seems off-topic to me - none of the flags proposed do this, and I don't know why it was brought up?
Grahame Grieve (Jul 11 2016 at 20:43):
I think we should say that the last 7 elements in ExpansionDefinition can also be passed as parameters to an expansion operation, and if they are, they override the value specified in the ExpansionProfile, if one is nominated
Rob Hausam (Jul 11 2016 at 20:53):
I agree that the additions isn't really an issue, as you're right, nothing in the resource as proposed does this. But there was concern expressed that, unless it was clearly enough stated, and even better specifically prohibited, that somebody might still try to do that. So that's why it was brought up (my take on that, anyway).
The sense on the vocab call was that there is a need and we ageed with your second point regarding the last 7 elements as parameters on $expand, and that they would override the values in ExpansionProfile (if EP is present).
Michael Lawley (Jul 13 2016 at 01:17):
I would add that any expansion parameters supplied in the $expand like this should be reflected in the list of parameters in the expansion result.
Rob Hausam (Jul 13 2016 at 01:41):
Agree, @Michael Lawley
Grahame Grieve (Jul 13 2016 at 01:45):
ok, so eVote on this:
- take the ExpansionProfile elements includeDefinition, includeInactive, excludeNested, excludeNotForUI, excludePostCoordinated, displayLanguage, limitedExpansion, and make them allowable as parameters on $expand
- if present, they override whatever some from the explicit or implicit profile
- if present, they SHALL be in the .expansion.parameters
- review the documentation on each to be clear that mau operate to exclude codes from the expansion, not inject them
Grahame Grieve (Jul 13 2016 at 01:45):
Rob, you want to open that on the vocab list?
Rob Hausam (Jul 13 2016 at 01:48):
yes, I think that works
I need to refresh my recollection of what we said our procedures need to be for it
the issue that I can think of might be the minimum vote period was that we specified (it's probably a week)
Grahame Grieve (Jul 13 2016 at 01:49):
that's still quicker than waiting for the call
Rob Hausam (Jul 13 2016 at 01:52):
yes, but only by a couple of days - if that's enough, then great
Grahame Grieve (Jul 20 2016 at 01:39):
@Michael Lawley will be amused to know that I am now dependent on having heirachy as a flag on the $expand operation inside the build tool
Last updated: Apr 12 2022 at 19:14 UTC
