FHIR Chat · Adding concept to QuestionnaireResponse · questionnaire

Stream: questionnaire

Topic: Adding concept to QuestionnaireResponse


view this post on Zulip Keith Boone (Jan 13 2020 at 19:28):

One of the challenges we are having in using Questionnaire and QuestionnaireResponse in SDC is that the QuestionnaireResponse object does not fully represent the information content with regard to the codes associated with the questions. For some use cases, the need to request the referenced Questionnaire would cause an extra server interaction, and that's not entirely desirable. There's also the case that the Questionnaire at time the QuestionnaireResponse was used could be a different version with different codes.

So, our thought was to request that item.code be added to QuestionnaireResponse so that lookup is not needed. Has anyone thought about this?

view this post on Zulip Paul Lynch (Jan 13 2020 at 19:43):

There are also other things missing from QuestionnaireResponse, like the score for answers that have the ordinalValue extension (which I was asked for in https://jira.hl7.org/browse/FHIR-19615, and would still like, but I conceded I could do without it). I think QuestionnaireResponse is meant to be minimal amount of data needed to capture answers, and that in general having the Questionnaire will be necessary to process those answers.

view this post on Zulip Lloyd McKenzie (Jan 13 2020 at 19:45):

We've talked about it. The reality is that when you're looking at a QuestionnaireResponse for any purpose other than rendering, you're always going to need the Questionnaire. The 'code' isn't necessarily unique to a single question. If I ask for your weight and I ask for the weight of each of your parents, the 'code' for that question might well be the same. As well, the answers available can also vary even though the code is the same. Finally, the 'shared computable meaning' associated with a given question might be conveyed by item.code or it might be conveyed by item.definition. If we expose one in the QuestionnaireResponse, we'd need to expose the other. And then someone might want to see what the answer choices were too. (Or scores as Paul says). It becomes a slippery slope.

The only reason we echo the text of the item is so that a system can render (and a human can understand) a completed QuestionnaireResponse even if they can't access the Questionnaire. However, if you want to edit, the response, populate it, extract from it or do anything else computable, the system needs to have a copy of the Questionnaire.

view this post on Zulip Keith Boone (Jan 13 2020 at 22:59):

Yeah, sorry, that's the kind of answer I was expecting. But the reality is, for MOST QuestionnaireResponses, you wouldn't need the Questionnaire. I was expecting that I would probably have to add an extension for this. To date there are multiple HL7 implementation guides for CDA and HL7 V2 for which a populated item contains both the code for the question as well as the answer, and ideally, the same tools which process the extracted results could also extract from a populated QuestionnaireResponse without having to perform an additional fetch. What I'm hearing though is that this isn't the case. And there are numerous assessment instruments for which every question has a distinct code for the question already established in LOINC panels, and the code for "parent weight" in those kinds of instruments would be different from the code for "your weight".

view this post on Zulip Paul Lynch (Jan 13 2020 at 23:04):

..., and the code for "parent weight" in those kinds of instruments would be different from the code for "your weight".

An example of Keith's last point: https://loinc.org/54127-6/

view this post on Zulip Lloyd McKenzie (Jan 13 2020 at 23:06):

I believe our resolution to your change request, we agreed to add extensions for this purpose as a convenience. My example might not have been a great one, but the point is that 'code' isn't necessarily expected to carry the full context of the entire questionnaire. It is legitimate to have a code whose meaning is impacted by where in the instance it appears.

view this post on Zulip Brian Postlethwaite (Jan 30 2020 at 10:39):

The other way to resolve that @Keith Boone is to contain the questionnaire definition in the QR.

view this post on Zulip Brian Postlethwaite (Jan 30 2020 at 10:40):

If you're retrieving the QR, then you can ask with an _include to get the Q with it.
And even better if you're getting multiple, you only get 1 copy of the form.

view this post on Zulip Brian Postlethwaite (Jan 30 2020 at 10:40):

As for versioning, in our QRs we put in a versionId reference to the questionnaire definition.

view this post on Zulip Keith Boone (Feb 01 2020 at 21:45):

Been there, did that, it's not satisfying, but it does work.


Last updated: Apr 12 2022 at 19:14 UTC