Stream: questionnaire
Topic: choice, open-choice, and string values?
Paul Lynch (Feb 12 2019 at 23:38):
In the spec, "choice" and "open-choice" are limited to use for answers of type "Coding", but conceptually, they mirror CNE and CWE, which less about data type and more about whether the user is allowed to enter a value that is not on the list. For reasons I don't quite understand, answerOption is allowed to take other data types other than Coding. So, suppose one has a question with answerOptions containing valueString, instead. Is the item.type then set to "string"? How then does one indicate whether a value can be entered that is not on the list?
Lloyd McKenzie (Feb 13 2019 at 05:13):
CNE and CWE are definitely about coded data. I don't think you can send dates or numbers in either.
AnswerOption was allowed to take other data types because use-cases were presented where, for certain questions, the answer might be a constrained list of times, dates or numbers. If you'd like to propose we enforce a constraint that the option choices align with the item type, that's probably a good idea. I don't think anyone's ever presented a use-case to support an "open" choice for anything other than codes.
Paul Lynch (Feb 13 2019 at 16:34):
AnswerOption was allowed to take other data types because use-cases were presented where, for certain questions, the answer might be a constrained list of times, dates or numbers.
If someone has real-world examples of that that I could see, that would be helpful. Strings and numbers, at least, could be handled with a Coding, since the codes are optional.
I see Questionnaire is still "Trial-Use". Rather than having choice and open-choice in item.type, I think it would be better to allow item.type Coding, and then have "choice" and open-choice be set somewhere else. That way item.type could define the data type, and the specification of whether off-list answers were allowed (whatever the type) would be independent.
I don't think anyone's ever presented a use-case to support an "open" choice for anything other than codes.
LHC-Forms defines an optional form header field called "where done" which is basically a free text field but has a list of suggested entries like "Home", "Lab", etc. It is not a list for which codes are important, and the user can type whatever they want. As I said above, this could be handled with Coding, but it might be more natural to use item type "string". (I am not arguing for keeping these other non-Coding types of answerOption, but I am trying to make the point that if we have them, circumstances arise in which open-choice is a reasonable thing to want for those kinds of lists.)
Lloyd McKenzie (Feb 13 2019 at 16:45):
Picking a time-slot, Indicating a number of tickets where the number needs to be a number for math purposes but there are fixed quantity choices available. The need was for the result to be captured in the appropriate data type, but the set of choices available was finite. Agree it's not a common thing, but the use-cases seemed reasonable when presented and it was going to cause less grief to add them than to try to make it work with extensions.
Brian Postlethwaite (Feb 14 2019 at 11:00):
The open choice can have an answer of type string or coding. So it's not a selection of data type.
Brian Postlethwaite (Feb 14 2019 at 11:01):
Example: A set of predefined dates available to choose from (generated server side from key moments in an encounter)
Paul Lynch (Feb 14 2019 at 23:19):
The open choice can have an answer of type string or coding. So it's not a selection of data type.
You are right, but it is not necessary to handle the free text entry as a string (though the spec might currently require that). It could be stuffed into a Coding, since Coding.code is optional.
Lloyd McKenzie (Feb 14 2019 at 23:42):
That would be a misuse of the data type
Paul Lynch (Feb 15 2019 at 14:53):
If a code is not requried, how could a Coding without a code be a misuse?
Lloyd McKenzie (Feb 15 2019 at 15:42):
Display without a code would be a misuse if it's not a proper display from the code system - it's not for capturing free text.
Paul Lynch (Feb 15 2019 at 16:13):
Okay-- after reading https://www.hl7.org/fhir/datatypes.html#Coding, I guess that is clear enough.
Brian Postlethwaite (Feb 16 2019 at 03:35):
Where just text is used elsewhere is with the CodeableConcept filling only text, and no coded values.
Lloyd McKenzie (Feb 16 2019 at 04:40):
That's not an option for QuestionnaireResponse
Lloyd McKenzie (Feb 16 2019 at 04:40):
In QuestionnaireResponse the solution is to use answerString
Paul Lynch (Feb 21 2019 at 23:12):
I see Questionnaire is still "Trial-Use". Rather than having choice and open-choice in item.type, I think it would be better to allow item.type Coding, and then have "choice" and open-choice be set somewhere else. That way item.type could define the data type, and the specification of whether off-list answers were allowed (whatever the type) would be independent.
In case the above paragraph got lost in the surrounding discussion, I am re-posting. Also, there is a tracker item I created for it which explains the idea in more detail. In addition to feedback about the idea itself, I would like to hear how disruptive it would be to have a breaking change in Questionnaire (which is still "trial use").
Last updated: Apr 12 2022 at 19:14 UTC
