Stream: questionnaire
Topic: Boolean questions
Paul Lynch (Jul 25 2019 at 20:46):
If an item is of type boolean, one could either render that as a checkbox, or as two radio buttons.
The problem with the checkbox is that it always in one state or other, and there is no "unanswered" state. If you render a Questionnaire with a checkbox, then when you export the QuestionnaireResponse, that answer will have to have a value regardless of whether the user made a selection or not.
If you render a boolean item as two radio buttons, those buttons need labels, which I guess would be "True" and "False", though there might be cases were a user would prefer "Yes" and "No". Should a form designer be able to specify those labels?
With only two radio buttons, there can be an initial "unanswered" state, but once the user makes a selection, there is no way to get back to the unanswered state. So, maybe three radio buttons are needed-- "True" , "False", and "No answer"?
Lloyd McKenzie (Jul 25 2019 at 22:42):
Some systems have 3-state check boxes that can differentiate and toggle through "no answer"
Eric Haas (Jul 26 2019 at 00:09):
I think and implement bool as a check box, if you want radiobutton bool magically turns into a coding.
Brian Postlethwaite (Jul 26 2019 at 01:16):
That's really a form design question, and same with a checkbox, it has a value of false until someone ticks it.
If you really want the 3 value logic, using a coding...
Paul Lynch (Jul 26 2019 at 15:18):
@Eric Haas & @Brian Postlethwaite So if you just use a 2-state checkbox, if the user does not touch the checkbox, do you include "false" as an answer in the QuestionnaireResponse?
Brian Postlethwaite (Jul 27 2019 at 00:49):
I'd have to look into my implementation, but probably.
Paul Lynch (Jul 29 2019 at 15:26):
Might there be an interoperability problem if some some systems use 3-state checkboxes and some 2-state?
Lloyd McKenzie (Jul 29 2019 at 15:34):
Generally speaking, systems should be able to differentiate between questions that have been answered vs. those that are filled in with a default answer. If there's no default answer specified, the answer should be omitted. And it should be possible to 'wipe' an answer previously submitted if a users so wishes.
Ye Wang (Jul 29 2019 at 15:34):
@Paul Lynch In LHC-Forms widget, for the Boolean type If the checkbox is not touched by the users, there would be no value captured in QuestionnaireResponse. Once it's touched, the value has to be ether true or false. There are probably use cases that need an "unanswered" state even after users have touched.
Lloyd McKenzie (Jul 29 2019 at 15:35):
We can't assume that booleans, numbers, etc. have default values not declared in the form.
Ye Wang (Jul 29 2019 at 15:37):
@Lloyd McKenzie I believe we handle that correctly in LHC-Forms widget. Just not sure if we need to give user an option to back to the "unanswered" state once he/she makes a selection.
Lloyd McKenzie (Jul 29 2019 at 15:43):
Ctrl-Z should at a minimum. And it's good practice to be able to go back to an 'unknown' state. Not sure we should make it a SHALL in the spec, but I'd be in favor of a change request that makes it a SHOULD
Eric Haas (Jul 29 2019 at 19:49):
which spec?
Lloyd McKenzie (Jul 29 2019 at 21:11):
SDC, probably. Though I could get talked into putting it into core
Richard Townley-O'Neill (Jul 30 2019 at 01:54):
Allowing check boxes to be reset to unknown should be good practice. It is sad that an exchange specification needs to go to that level of human interface design. :frown:
Lloyd McKenzie (Jul 30 2019 at 03:11):
It doesn't necessarily need to - but doing so will likely increase the quality of FHIR-based systems...
Paul Lynch (Jul 30 2019 at 15:59):
Last updated: Apr 12 2022 at 19:14 UTC
