Support item.answerOption for item.type = string and item.type = integer

[JohannesOehm]

Is your feature request related to a problem? Please describe.
I'm not sure if this is only a feature request or if this rather qualifies as a bug. The issue is, that the FHIR specification for item.type = "choice" says:
Question with a Coding drawn from a list of possible answers (specified in either the answerOption property, or via the valueset referenced in the answerValueSet property) as an answer (valueCoding). (https://www.hl7.org/fhir/valueset-item-type.html),
which is also consistent with the mapping table outlined in https://www.hl7.org/fhir/questionnaire.html#question-types

At the same time, the documentation for the item.anwerOption element says:
One of the permitted answers for a "choice" or "open-choice" question. (https://www.hl7.org/fhir/questionnaire-definitions.html#Questionnaire.item.answerOption), with leads to the question, why item.answerOption.value[x] should be a union type at all.

A inquiry in the zulip-Chat answered by Llyod McKenzie clarified, that the answerOption-list is meant to be used with other types:
https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/type.3Dchoice.20and.20answerOption.2EvalueInteger.3F

Describe the solution you'd like
I would like, that the app checks for items of type string or integer, if there is a answerOption list. In that case, a list should be rendered rather than a radio list or a combobox than the text field.

Describe alternatives you've considered

• The alternative would be also to drop support for Questionnaires with item.type = choice and answerOptions of type string or integer. However, to stay somewhat downwards compatible, I would'nt recommend that.
• Another alternative would be to use this different behaviour as a compass-internal convention. However, this would be not good because other FHIR-Questionnaire-Tools might not be able to handle Questionnaires, which do not conform to the FHIR specification.