FHIR Chat · Make item.type repeat? · questionnaire

Stream: questionnaire

Topic: Make item.type repeat?

Lloyd McKenzie (Mar 05 2021 at 17:33):

There were a few topics related to Questionnaire.item.type:

• there are some use-cases where there's a desire to have answers that can be a mixture of numbers + codes or possibly dates + codes. If we were to do this, then our notion of "open" vs. "closed" questions would change, and we'd instead have questions where multiple types were allowed and one of them was string. (Though we might still have the notion of open/closed in terms of whether the list of provided options is exhaustive.)
• if we were to allow this, we'd probably make Questionnaire.item.type have just 3 values - group, display, question and then we'd have a 0..* element called questionType which would list the possible data types. We could create a rule that would make questionType required if question was present (though perhaps allow it to be omitted if it's being inferred from the referenced code or definition?)

We have a few options here:

1. say that we'll never support this
2. support it in R5 (and test at connectathon in may?)
3. leave Questionnaire.item.type as STU to give us the ability to do this in the future

From a pure architecture perspective, I find the change attractive, but I don't know how justifiable the change is. I'm not a fan of option #3.

Ilya Beda (Mar 09 2021 at 10:37):

Could you please provide an example. It is not clear what is a use-case.

Lloyd McKenzie (Mar 09 2021 at 14:09):

Example: "How many people reside in your household?" - answer can be integer, max 50. Also supports the codes "unknown", "prefer not to answer"

Tilo Christ (Apr 03 2021 at 17:39):

I am not sure about whether questions would really be mixed type. To stick with your example, I really want to know the # of residents as a number, but if I am unlucky that number happens to be unknown. I am wondering though whether the HL7v3 concept of a "nullFlavor" should be added to responses in order to cover that? https://www.hl7.org/fhir/v3/NullFlavor/cs.html So maybe it should just be documented that a nullFlavor extension can be used for this purpose?

For me, a nullFlavor would also cover several other cases I am currently struggling with, related to "how can I save a half-finished response for later completion?". So being able to mark responses as INV, NAV, NASK, etc. would really help there.

Tilo Christ (Apr 03 2021 at 22:28):

I played with the idea a little, and here is what it might look like, if somebody didn't want to respond:

{
    "resourceType": "QuestionnaireResponse",
    "text": {
        "status": "generated",
        "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2>Enter your weight in kg</h2>***</div>"
    },
    "questionnaire": "http://build.fhir.org/ig/HL7/sdc/examples.html",
    "status": "unknown",
    "authored": "2021-04-04T00:22:08.098798",
    "item": [
        {
            "extension": [
                {
                    "url": "http://terminology.hl7.org/CodeSystem/v3-NullFlavor",
                    "valueCoding": {
                        "system": "http://terminology.hl7.org/CodeSystem/v3-NullFlavor",
                        "code": "MSK",
                        "display": "masked"
                    }
                }
            ],
            "linkId": "100000",
            "text": "Enter your weight in kg",
            "answer": []
        }
    ]
}

For "unknown", it would be "ASKU" instead of MSK.

Tilo Christ (Apr 04 2021 at 01:07):

This might even be more appropriate: https://www.hl7.org/fhir/extension-data-absent-reason.html So it would be "asked-declined" and "asked-unknown".

Brian Postlethwaite (Apr 05 2021 at 01:51):

I think examples like that are multiple questions, not the same one.
Nothing else tries do do this.

Brian Postlethwaite (Apr 05 2021 at 01:51):

Picturing the UI controls to do it...

Tilo Christ (Apr 05 2021 at 12:52):

Brian Postlethwaite said:

Picturing the UI controls to do it...

image.png

Another animated example can be seen here (the strike-out of question 3 happens because user chooses not to answer):

PRAPARE

I am also trying to picture the UI though if these were 3 questions (one for "How many people in the household", one for "unknown", one for "prefer not to answer"). How would that play with http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-entryMode of sequential or the "Get Next Question" for an adaptive questionnaire server?
With the data absent reason solution it would be relatively simple: I present the question incl. the possibility to decline and after the user has either answered or declined, I can move onwards to the next question that asks for some "real" information, such as household income.

If I split that up into 3 questions, would the sequence be:

• System presents question "How many people are in your household?"
• User enters 0, because they don't wish to answer
• System moves on to question "Do you know the number of people in your household?"

• User selects 'yes'
  System presents question "Do you wish to answer the question?"

• User selects 'no'

The other UI piece that I am currently building out is a progress indicator for how much of a questionnaire has already been filled. For that I can also see how keeping a question and the option to not answer the question as one indivisible unit would make my implementation a lot easier.

Lloyd McKenzie (Apr 05 2021 at 15:21):

Having answer be an empty array is not permitted. I don't think we'd want to introduce extensions here. Consuming systems are going to expect that all possible answers (and provided answers) are expressed using core elements.

Tilo Christ (Apr 05 2021 at 15:49):

Ok, maybe I have misread the spec. I took the cardinality of 0..* for answer in a QuestionnaireResponse as meaning "can be empty". But anyhow, if my idea is coming a little too late and will break a considerable amount of existing systems that would contradict the idea of interoperability.

Would data-absent-reason still be a good ValueSet for question#2 then? So to stick with your example, I would put a question about house hold residents as a question for an integer with an enableWhen for "householdDataAbsentReason" != asked-unknown and != asked-declined, and then have question#2 linkId "householdDataAbsentReason", type coding with ValueSet "http://hl7.org/fhir/ValueSet/data-absent-reason"?

Unless of course, somebody made "dataAbsentReason" a part of the core spec for QuestionnaireResponse, similar to how it is being specified on the Observation resource. Maybe that would also enable smooth extraction of questionnaires into observations?

Lloyd McKenzie (Apr 05 2021 at 15:53):

It can be empty - but if it's empty, you have to omit the element. Empty arrays aren't allowed in FHIR anywhere.

Lloyd McKenzie (Apr 05 2021 at 15:54):

dataAbsentReason is certainly a reasonable code system to draw from as possible answers. Whether Questionnaire authors will use it will vary

Tilo Christ (Apr 05 2021 at 16:08):

Lloyd McKenzie said:

It can be empty - but if it's empty, you have to omit the element. Empty arrays aren't allowed in FHIR anywhere.

Ahhh, ok, now I get what you mean, the answers: [] piece in my example above. That is something I should fix.

dataAbsentReason is certainly a reasonable code system to draw from as possible answers. Whether Questionnaire authors will use it will vary

As somebody who is trying to write a slick questionnaire filler I am of course always happy if the spec is somewhat prescriptive. That allows me to offer more consistent styling, more consistent UI elements, more functionalities etc. without resorting to heuristics and inference.

Lloyd McKenzie (Apr 05 2021 at 16:44):

Unfortunately the spec can't be more prescriptive than what existing data can tolerate - and existing forms (which we need to be able to express as FHIR Questionnaires) draw content from a wide variety of code systems and have minimal consistency. We can hope that as the need to map data from forms into FHIR data becomes more common that - in time - more forms will have FHIR-friendly codes. But it's far from guaranteed - and will certainly take a long time.

Tilo Christ (Apr 05 2021 at 16:57):

Lloyd McKenzie said:

Unfortunately the spec can't be more prescriptive than what existing data can tolerate - and existing forms (which we need to be able to express as FHIR Questionnaires) draw content from a wide variety of code systems and have minimal consistency. We can hope that as the need to map data from forms into FHIR data becomes more common that - in time - more forms will have FHIR-friendly codes. But it's far from guaranteed - and will certainly take a long time.

Fair enough, but one can dream and wish :smile: Are you aware of any group that tries to come up with authoring guidelines for "FHIR friendly" questionnaires? If we want to move there then we should eventually define what it is?

Lloyd McKenzie (Apr 05 2021 at 17:16):

None that I'm aware of - but there are all sorts of things I'm not aware of :)

Last updated: Apr 12 2022 at 19:14 UTC