Stream: questionnaire
Topic: que-11 workaround
Diane (Feb 27 2022 at 20:56):
For our project's questionnaires, we have many, many questions where the initial value for Yes/No questions is preset to "No" in order to save time for the users using item.initial.value[x]. These work fine with the LHC Forms rendering.
But, our IG is producing this error message:
que-11: 'If one or more answerOption is present, initial[x] must be missing'
So, I changed out the item.initial.value[x] in the questionnaires to option.initialSelected.
Now, I am finding out that LHC-Forms does not support option.initialSelected per https://github.com/lhncbc/lforms/blob/master/r4-support.md#not-yet-supported
The workaround is
answerOption.initialSelected: For now you need to use item.initial.value[x] instead, despite the contraint that says, "answerOption.empty() or initial.empty()".
but that doesn't validate in the IG because of que-11.
At this point, I think the best solution for my project is:
-
Leave item.initial.value[x] for the questions in the questionnaires that need to default to "No" on our website since they work fine
-
For the IG, replace initial[x] with option.initialSelected for the questions that need to default to "No"
Any other suggestions?
Is it permissible to set a default value of "No" via calculatedExpression since we can now treat calculatedExpression items as editable by the user? I want the coding of "No", not a string.
Lloyd McKenzie (Feb 28 2022 at 15:39):
I think the solution is for LHCForms to add support for "initialSelected".
Diane (Feb 28 2022 at 16:14):
Thanks, Lloyd. I am going to convert the questionnaires in the IG to option.initialSelected.
@Paul Lynch Heads up that if we have a next phase of our project, we will request support in LHC-Forms for option.initialSelected.
Paul Lynch (Feb 28 2022 at 16:17):
Lloyd McKenzie said:
I think the solution is for LHCForms to add support for "initialSelected".
I suppose, but why not allow initial.value[x] as long as it is present in the answerOptions?
Lloyd McKenzie (Feb 28 2022 at 16:19):
Because we didn't want two ways to say the same thing
Brian Postlethwaite (Feb 28 2022 at 19:30):
Then wouldn't that have been better to remove the option.initialSelected?
Paul Lynch (Feb 28 2022 at 19:32):
The advantage of answerOption.initialSelected is that you can just mark an answer in the list; you don't have to repeat the Coding (or whatever type) in initialCoding.
Brian Postlethwaite (Feb 28 2022 at 19:35):
At the cost of having 2 ways to do defaults, and this invariant
Paul Lynch (Feb 28 2022 at 19:37):
Without initialSelected you would still need an invariant to require that initial[x] be in answerOption.
Brian Postlethwaite (Feb 28 2022 at 20:24):
I prefer using initial[x] always (which is what your current implementation does if I'm not mistaken)
Otherwise there are 2 ways to specify a coded initial value depending on if using answeroption, answer valueset or answerexpression
Lloyd McKenzie (Feb 28 2022 at 21:42):
Well, you could ask for us to revisit the original tracker on one of our calls
Diane (Feb 28 2022 at 23:45):
https://jira.hl7.org/browse/FHIR-22686 is the original Jira item, which was reopened once before. Didn't know that I was (re)opening a can of worms. :fear:
I have updated our Questionnaire definitions to initial[x] for our website and answerOption.initialSelected for our IG. To me, initial[x] and answerOption.initialSelected are both equally nice to use. initial[x] is more intuitive because it is similar in syntax to initial value for other item types. But, answerOption.initialSelected is more concise.
Maybe the que-11 invariant should say that you can't use both initial[x] and answerOption.initialSelected on the same item, but either one is acceptable.
Lloyd McKenzie (Feb 28 2022 at 23:56):
Two solutions to the same problem helps no-one. We should land on one mechanism and mandate it. (Which is what we had done.) We can choose to switch the answer, but we definitely shouldn't allow both.
Paul Lynch (Mar 01 2022 at 00:15):
I don't think changing the resolution will make a difference to form fillers that have implemented initial[x] support. initialSelected is in R4 Questionnaire, so it needs to be supported. (We haven't yet, but we should.) If we revise the tracker item and remove initialSelected for R5, we will still need to support it for R4, and we'll need to continue to support initial[x] for R5. So, from an implementation point of view, there are two ways of doing the same thing. On the other hand, if we don't change the resolution and keep initialSelected, then support for that will still need to be added to LHC-Forms, but we are unlikely to remove support for initial[x] (on import -- we would not export it way). However, for newly written form fillers, which only support initialSelected when answerOption is present, and not initial[x], there will be an advantage if the resolution stays as it is.
Last updated: Apr 12 2022 at 19:14 UTC
