Stream: questionnaire
Topic: questionnaire-choiceColumn
Paul Lynch (Aug 27 2020 at 17:36):
If I want to use questionnaire-choiceColumn to indicate additional columns to show for an item's answerValueSet, it looks like I first need to do an $expand (maybe with filter) to get a list of N items, and then do an additional N CodeSystem $lookup queries to get the properties requested by the questionnaire-choiceColumn instances for each item. The $lookup queries could be done in a batch, but with at least HAPI FHIR the queries within a batch seem to be processed in series, so that might not help much. Is there a better approach?
Paul Lynch (Aug 28 2020 at 15:12):
It looks like the better approach is waiting for this two-year old ticket to be addressed: J#17324
Lloyd McKenzie (Aug 28 2020 at 16:13):
@Grahame Grieve - thoughts on how to nudge this one forward?
Grahame Grieve (Aug 28 2020 at 22:14):
bring it up on #terminology but I think it's moved forward...
Paul Lynch (Aug 31 2020 at 21:40):
The relevant thread on #terminology appears to be https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Extensions.20vs.20properties, which seems to have stalled.
Brian Postlethwaite (Aug 31 2020 at 22:07):
That's covered with R5, so is a "how to express it with R4" that's not obvious.
I've done something here for some more custom prepop work, but forgot about this extension, and would be really useful.
The issue with backporting I was confused what to to with the name of the backbone element and child props.
Brian Postlethwaite (Aug 31 2020 at 22:08):
Happy to add this to the fhir connectathon if you want?
Paul Lynch (Aug 31 2020 at 23:58):
I had not realized it was covered in R5, but I can see on build.fhir.org that ValueSet expansions now can contain properties which were requested by a $expand operation. That is a big step forward. (It is not everything I would like, but it is the most important part.) I am not sure how it could be backported to R4 except as something non-standard. For R4, I will plan to try the N $lookup queries and see how bad it is.
Paul Lynch (Oct 01 2020 at 23:03):
If one is using the choiceColumn extension to show, in a list, both the coding display strings and their associated property values, then when the user makes a selection, what happens to the property values for the coding the user selected?
Lloyd McKenzie (Oct 02 2020 at 01:35):
Nothing. They're not captured as part of the Coding in the answer, certainly.
Paul Lynch (Oct 02 2020 at 11:58):
Sometimes one might want to fill in other form fields with same data that was showing in the list columns for the selected item. It would be nice not to have to fetch the data a second time. Perhaps it can be cached internally somehow.
Lloyd McKenzie (Oct 02 2020 at 13:06):
You can hold onto that information in memory, but you can't persist it.
Brian Postlethwaite (Oct 20 2020 at 00:03):
I think that's what Paul was looking for. So we had a consistent behaviour.
Paul Lynch (May 20 2021 at 20:26):
Brian and I were discussing whether the data from the choiceColumn columns could be stored as a variable on the item, or the parent's item, so that other fields in the form (e.g. the same row of a table, or child items) could access it via FHIRPath.
Brian Postlethwaite (May 20 2021 at 22:27):
I'm going to experiment with this to see if it works.
Last updated: Apr 12 2022 at 19:14 UTC
