Move choice/open-choice out of Questionnaire.item.type, and add Coding

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Questionnaire
    • Hide

      We will drop "choice" and "open-choice" (and adjust all wording in descriptions and elsewhere to reflect that). We will add Coding in place of those two.

      We will add an additional element called choiceConstraint that has the following values:

      optionsOnly: The answer must be one of the provided options

      optionOrType: The answer must be one of the provided options or another custom-entered value that matches the type of the question

      optionOrString: The answer must be one of the provided options or a free-text string value (populated into answer.valueString)

      Add an invariant prohibiting this element unless either answerValueSet or at least one answerOption is listed.

      Show
      We will drop "choice" and "open-choice" (and adjust all wording in descriptions and elsewhere to reflect that). We will add Coding in place of those two. We will add an additional element called choiceConstraint that has the following values: optionsOnly: The answer must be one of the provided options optionOrType: The answer must be one of the provided options or another custom-entered value that matches the type of the question optionOrString: The answer must be one of the provided options or a free-text string value (populated into answer.valueString) Add an invariant prohibiting this element unless either answerValueSet or at least one answerOption is listed.
    • Rick Geimer/Brian Postlethwaite: 20-0-3
    • Enhancement
    • Non-compatible

      The sub-types for Questionnaire.item.type in https://www.hl7.org/fhir/valueset-item-type.html under code "quesiton" are mostly about data types. The exceptions are "choice" and "open-choice", which are restricted to type "Coding" or "string", and which control whether the user is allowed to enter something not on the list.

      I think it would be a cleaner design to keep item.type about data types (for those under the "question" type) and move the choice about off-list answers to a new field on Qustionnaire.item (e.g., nonListAnswersAllowed, as a boolean). What data type a question is, and whether off-list answers are allowed, are two separate concerns.

      The advantage, other that a more logical design, would be the possible future allowance of off-list answers for non-Coding answer lists. Currently, answerOption can permit several other types, but off-list answers are not allowed for non-Coding lists. I understand that no one actually has a use case currently that needs that capability, but with the change I am suggesting it would be easily supported, and it is better to make the change now while Questionnaire is still in a "Trial Use" stage. Until such a use case arises, if necessary a constraint could be added to disallow off-list answers for non-Coding lists.

            Assignee:
            Lloyd McKenzie
            Reporter:
            Paul Lynch
            Paul Lynch
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: