Stream: questionnaire
Topic: Constraining quantity items
Elliot Silver (Dec 11 2020 at 21:59):
I see that there are minValue and maxValue extensions for Questionnaire items, but they are restricted to integer, decimal, and a couple of other types. Is there a way to restrict a #quantity?
I'm trying to restrict an age response to be a positive number, and less than, say, 150 years. The item allows years, months, or days as the unit of age. I don't need the enforcement to convert between the units -- I'd be fine restricting use of days or months < 150 too.
Elliot Silver (Dec 11 2020 at 22:15):
Ah, just found SDC's min/maxQuantity.
Although I don't need it for my use, it isn't clear whether the form-filler application is expected to be able to convert between units to enforce this max (is 1 year more or less than a limit of 24 months), or whether this extension should repeat for each set of units I want to put a limit on, and if so, do all repetitions need to express the same limit (in different units) or can there be unit-specific limits.
Lloyd McKenzie (Dec 11 2020 at 22:28):
You could submit a change request for us to clarify... :)
Elliot Silver (Dec 11 2020 at 22:28):
Will do.
Elliot Silver (Dec 11 2020 at 22:30):
While I'm at it, I'm trying to understand how to do exclusive vs non-exclusive choice elements. Am I correct that the choices are exclusive unless the item repeats?
Elliot Silver (Dec 11 2020 at 22:33):
Re: a change request -- apparently the answer to my question is there, just not on the pages I was looking at.
Lloyd McKenzie (Dec 11 2020 at 23:04):
Right. If the item doesn't repeat, they're exclusive. If the item repeats, there's an extension you can use to flag an item (e.g. "N/A") as exclusive.
Elliot Silver (Dec 11 2020 at 23:22):
The exclusive extension doesn't work when the options are drawn from a value set though.
Lloyd McKenzie (Dec 11 2020 at 23:23):
True
Elliot Silver (Dec 11 2020 at 23:30):
It would be helpful to be able to combine answerValueSet with answerOption for this use.
Lloyd McKenzie (Dec 11 2020 at 23:32):
We could explore that as a possibility for R5, though there'd be an ordering question - do the options come before or after the value set items, or do we sort them alphabetically? Nothing we can do in R4. If you think you have a workable proposal for an R5 change, feel free to submit a tracker item :)
Elliot Silver (Dec 12 2020 at 00:43):
Added further comments to FHIR-29935.
Paul Lynch (Dec 14 2020 at 13:30):
@Elliot Silver Regarding J#29935, do you have a case where it is important to specify the prompt for the "other" value? I think LForms just says, "Other:".
Also, have you considered multiple off-list values, when the item repeats? When rendered as a list rather than radio buttons, prompts are not necessary (e.g. https://jsfiddle.net/hm97ntLc/, where you can type something not on the list) but for radio buttons we just support one "other".
Elliot Silver (Dec 14 2020 at 15:17):
@Paul Lynch, yes, I had considered multiple off-list values as something that would need to be addressed :-)
I'm not sure that a list removes the need totally, but might change the desired display approach from an explicit prompt to in-field placeholder text.
As for what the prompt is, for the forms I've been working on, "Other:" or "Other (please specify):" should be sufficient. I suppose "Other condition:," "Other setting:" might be more explicit, but for me, not needed.
Brian Postlethwaite (Jan 11 2021 at 00:17):
For our use of open-choice, we typically have large valuesets, so just have a single textbox that behaves like a look-ahead.
If we want the "other" style usage, we have a specific code for that, and a separate control/question to capture it.
Lloyd McKenzie (Jan 11 2021 at 03:19):
@Brian Postlethwaite Does that mean you disagree with the resolution?
Brian Postlethwaite (Jan 11 2021 at 03:44):
Not sure if I completely disagree with it, but it doesn't make any mention of the type of user experience that we have for it, or the interactions with the item control extension.
Brian Postlethwaite (Jan 11 2021 at 03:46):
You could also have similar behaviour with enablewhens and disabling the other control if a value is selected, or disable the radios if the other is entered.
Lloyd McKenzie (Jan 11 2021 at 04:58):
Do you think we should re-open this item or do you want to add a new one for us to add clarification?
Elliot Silver (Jan 11 2021 at 18:19):
I'm not sure about the resolution either. It ends up requiring two items, and extraction complexities. If you add "Other" to the choice value set, then, on data entry, you need to check if the chosen value is other, and enable the "please specify" text field. Then on data extraction, you can put the choice value into a CodeableConcept.coding, unless the choice was Other, in which case you leave the coding blank and put the "please specify" text into the CodeableConcept.text. I recognize I'm not FHIR-path fluent, and still figuring out SDC extraction, but that extraction seems messy, especially for what will be a common pattern.
Lloyd McKenzie (Jan 11 2021 at 19:18):
I'm not following. We said that you could simply have a label of 'Other' for other text (via an extension) and not have that as part of your value set.
Elliot Silver (Jan 11 2021 at 19:28):
Sorry, I thought Brian was objecting to J#30082 which there was just an update to. And I misremembered the resolution for J#29935.
Elliot Silver (Jan 11 2021 at 19:44):
Actually, I am still confused. Is open-choice sticking around or being eliminated? An option to specify the other text doesn't make much sense if open-choice is going away, or if we're going to recommend using contained value sets with an "other" value.
Lloyd McKenzie (Jan 11 2021 at 22:51):
open-choice goes away in R5 and is replaced by a flag about whether choices outside the constrained options are allowed
Elliot Silver (Jan 11 2021 at 22:53):
OK. And, "other, please enter" is added to a contained value set? In that case what is the use of the "other value" extension?
Lloyd McKenzie (Jan 11 2021 at 22:55):
No. That's not in the value set. We defined an extension that allows you to specify the label for 'other' content if you're using a UI widget where some sort of label is needed. If not specified, then the rendering tool decides on the label.
Elliot Silver (Jan 11 2021 at 22:57):
"other, please specify" is not in the value set? I thought J#30082 agreed that contained value sets were the way to do it.
Lloyd McKenzie (Jan 11 2021 at 23:01):
What we said was that if you want to draw on a standard value set and add some extra codes, to do that by defining a contained value set. E.g. if you want to add "N/A" or "Unknown" or even "Other" (without 'please specify' or where 'please specify' is handled with a nested question). There's a separate tracker where we agreed to add an extension to allow you to define the label for the 'other' choice when using open-choice or the R5 equivalent.
Lloyd McKenzie (Jan 11 2021 at 23:03):
30082 is specifically saying that we won't allow you to mix both value set and options for a single question
Elliot Silver (Jan 11 2021 at 23:06):
Ah, ok. That makes sense now.
And if you're using an extension for the "other text" under J#29935, we expect the form filler application to show a text entry box (potentially repeating?) and will automatically populate the CodeableConcept.text with the value when preparing the QR?
Lloyd McKenzie (Jan 11 2021 at 23:19):
Right
Lloyd McKenzie (Jan 11 2021 at 23:20):
'other' isn't captured in CodeableConcept.text, it's captured as string. (And in R5 it could actually be something else - e.g. a date)
Brian Postlethwaite (Jan 12 2021 at 10:07):
2 parts I think are missing here, how fo you setup an auto complete style where can be coded or string in the same field?
Brian Postlethwaite (Jan 12 2021 at 10:07):
We can talk about it at the connectathon.
Last updated: Apr 12 2022 at 19:14 UTC
