FHIR Chat · Encode Questionnaire answerOption in QuestionnaireResponse · implementers

Stream: implementers

Topic: Encode Questionnaire answerOption in QuestionnaireResponse


view this post on Zulip Pieter Edelman (Feb 27 2020 at 15:49):

The Questionnaire resource defines the "choice" item type, which allows the user of a questionnaire to choose from a list of predefined answers. What these possible answers may be, can be defined using the Questionnaire.item.answerOption.value[x] element, where can be of type Integer, Date, Time, String, Coding and Reference (at least in STU3).
However, it is unclear how to communicate the answer to these choice questions using the QuestionnaireResponse resource. One would expect the type of the QuestionnaireResponse.item.value[x] to simply match the type of the _selected_ answer in the Questionnaire. Thus if the answer the user selected was an .answerOption.valueString, one would expect to see a QuestionnaireResponse.item.valueString for the matching question.
However, the documentation on the "choice" type in the item-type valueset (https://www.hl7.org/fhir/stu3/valueset-item-type.html), states: "Question with a Coding drawn from a list of options (specified in either the option property, or via the valueset referenced in the options property) as an answer (valueCoding)". This suggests that the answer to a "choice" item in a Questionnaire should always result in a QuestionnaireResponse.item.valueCoding.
Which one of these interpretations is correct, the former or the latter? And if the latter interpretation is correct, how would one capture e.g. a Questionnaire.item.answerOption.valueString or .valueDate in a QuestionnaireResponse.item.valueCoding?

view this post on Zulip Michele Mottini (Feb 27 2020 at 16:20):

I think the answer is that if the Questionnaire item type is choice then Questionnaire.item.answerOption.value[x] must be Coding

view this post on Zulip Michele Mottini (Feb 27 2020 at 16:22):

yes, that's it: 'Question with a Coding drawn from a list of options (specified in either the option property, or via the valueset referenced in the options property) as an answer (valueCoding)' (from http://hl7.org/fhir/STU3/valueset-item-type.html#expansion)

view this post on Zulip Lloyd McKenzie (Feb 27 2020 at 16:45):

Choice type means 'coding'. You can have a question of type 'date' where there are answer options defined. However, agree this needs to be made more clear. Can you submit a change request @Pieter Edelman ?

view this post on Zulip Pieter Edelman (Feb 28 2020 at 09:46):

Well, that kind of makes sense. I would be glad to submit a change request if I understand what needs to be done. However, I now have several new questions about the expected behavior:

First, the documentation on Questionnaire.item.option states:

  • definition: "One of the permitted answers for a "choice" or "open-choice" question."
  • comment: "This element can be used when the value set machinery of options is deemed too cumbersome or when there's a need to capture options that are not codes."
    If I understand correctly, both statements are incorrect. item.option isn't only used for choice or open-choice type items, but also for integer, date, time, etc. And it cannot be used at all to extend value sets with other option types - it's either coding OR one of the other types.

Second, the behavior in the presence of the an .option.value[x] is unclear for item.type other than choice/open-choice. Does it mean that the answer MUST come from the defined .option's ("choice"), or that it MAY come from them ("open-choice")?

And last, shouldn't there be a constraint that in all instances of item.option.value[x], [x] MUST match item.type?

Thanks for your help.

view this post on Zulip Lloyd McKenzie (Feb 28 2020 at 14:24):

The documentation for item.option is incorrect. item.option can now be used for types other than choice and open-choice.

I'm not sure what you mean by "extend value sets with other option types" - the FHIR machinery doesn't allow value sets of dates, integers, etc.

We have an unapplied change request that will shift the open/closed question into a separate element so you can have open/closed regardless of type.

And yes, that sounds like a good constraint to introduce

view this post on Zulip Pieter Edelman (Feb 28 2020 at 15:52):

Thanks for the clarification @Lloyd McKenzie. I've applied for a Jira account to submit a change request.


Last updated: Apr 12 2022 at 19:14 UTC