Stream: implementers
Topic: QuestionnaireResponse
Angelo Kastroulis (Sep 13 2016 at 22:10):
2 Questions...
1) The spec says: "A QuestionnaireResponse may be stand-alone or may point to the form that defines the questions in Questionnaire. In this second case, the linkage between the questions and groups in the two resources is established using the linkId element.” How would one find a specific answer without a concept for the item (as there is in the Questionnaire)?
Is a reasonable method of identifying the answers to use an extension on item and using a code representing the question? Wouldn’t it be better to have a concept in that item as well?
2) What is best practice on these questionnairs and IGs? I see that we can have many items in the QuestionnaireResponse, but do we do communicate that by constraining items for each question in the IG, or do we create profiles for each question, then reference them in the IG?
Lloyd McKenzie (Sep 14 2016 at 00:57):
@Angelo Kastroulis If you don't have a linkage to a QuestionnaireResponse, then your ability to do much computation on the response beyond sharing it and rendering it is slim. And in general, QuestionnaireResponses aren't designed to support searching for particular answers - they're a data capture tool. If you want to do analysis, retrieval, decision support, etc., you'll probably want to migrate data from the QuestionnaireResponse into the appropriate other clinical/administrative resource.
Not really following your question about IGs. Can you explain further?
Aleksandra Pavlyshina (Sep 14 2016 at 16:19):
I'm wondering why the QuestionnaireResponse resource does not have an answer of type CodableConcept?
So that we could map the answer and keep the original answer at the same time.
E.g. there is the question on one of our forms "Does the patient wish to attempt resuscitation?" and the answers are Yes / No (DNR).
I wanted to represent the answer as
QuestionnaireResponse.item.text = "Does the patient wish to attempt resuscitation?"
QuestionnaireResponse.item.answer.valueCodeableConcept.coding.system = "http://hl7.org/fhir/ValueSet/v2-0136"
QuestionnaireResponse.item.answer.valueCodeableConcept.coding.code = "N"
QuestionnaireResponse.item.answer.valueCodeableConcept.coding.display = "No"
QuestionnaireResponse.item.answer.valueCodeableConcept.text = "No (DNR)"
but found that QuestionnaireResponse does not have an answer of type CodableConcept. Now I'm not sure how to capture this answer. Do I need to use answer.valueString here?
Lloyd McKenzie (Sep 14 2016 at 18:21):
If you want to capture both a code and a string, use a nested question for the string.
Pascal Pfiffner (Sep 15 2016 at 07:25):
@Aleksandra Pavlyshina I'm curious about your workflow to capture DNR, do you have a specific Questionnaire with a specific ID that patients fill out, then you're receiving a QuestionnaireResponse and that's it, or do you then proceed to create a Consent that captures that DNR?
Pascal Pfiffner (Sep 15 2016 at 07:26):
If you do the latter it seems to me that you could even simply use valueBoolean to capture the answer. If you don't process the responses I'm wondering how – via FHIR – you would discover the DNR.
Aleksandra Pavlyshina (Sep 21 2016 at 16:42):
Hi @Pascal Pfiffner. Thank you for your response.
In our application, there is a form with the question Does the patient wish to attempt resuscitation? with Yes/No answers. At the moment they are Yes/No, so I can map them to the value set http://hl7.org/fhir/v2/0136/index.html (v2 Yes/no Indicator). If 'No', then we will create the Flag resource and the Consent resource. I've suggested the mapping for the Consent resource to represent a DNR order in this Zulip conversation.
scr-21.09.2016_19-33-25.png
Brian Postlethwaite (Nov 15 2016 at 21:22):
There has been a change to QuesitonnaireResponse.Questionnaire to change the datatype from reference to Uri. This means that always need to know where the Questionnaire came from, vs explicitly knowing where the renderer grabbed it from, and which version. Could this be in addition to rather than replacing?
It would assist in diagnosing issues where a responses were coming in from an incorrect version of the Questionnaire.
Brian Postlethwaite (Nov 15 2016 at 21:22):
(not a fan of this change)
Brian Postlethwaite (Nov 15 2016 at 21:27):
The tracker number for this one is 10429 (I added my notes there too)
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10429
Brian Postlethwaite (Nov 15 2016 at 21:28):
@Eric Haas also noted that the reference to ValueSets also could have this pattern (and I pointed out that ElementDefinition already has a pattern of using a choice pair of either the canonicalURI or a direct reference - which I really like)
Pascal Pfiffner (Nov 16 2016 at 00:17):
Same thought here, in our (ResearchKit) use-case we don't care too much about a specific URI (because, technically, the Questionnaire can come from any of our Amazon instances) but the id of the Questionnaire is important. We (used to?) use a relative reference to the Questionnaire when returning the response.
wassim (Nov 16 2016 at 01:33):
hello, iam an IT engeneering student and iam new here with you ,my graduation's project topic is (conceiving and realising an IT systeme of healthcare ressources and administrative healthcare ressources , i was reading a little bit about the fhir hl7 and i want to use it but i didnt really understand so , please could you help me to know how its gonna work ( the database , the java developpement , the result.....etc) thank you
Lloyd McKenzie (Nov 16 2016 at 02:51):
@Brian Postlethwaite @Pascal Pfiffner - the intention is that we're moving to a canonical URL - so you can resolve the URL or you can look it up in whatever local/convenient Questionnaire repositories you wish - you don't have to resolve to a remote copy anymore. I'm not really understanding how the change makes things harder.
Lloyd McKenzie (Nov 16 2016 at 02:53):
@wassim I'd encourage you to start with the FHIR home page for the current draft. From there, read the executive summary and the developer's, clinicians and architect's introductions. As well, you can google "FHIR video" and find a number of presentations on FHIR to help get you up to speed.
Brian Postlethwaite (Nov 16 2016 at 03:00):
@Lloyd McKenzie , using the explicit reference, I know exactly what was used, and can even include the version number from the questionnaire. With the canonical URI I need to encode versioning in that too (which is not explicit).
(means if a form was generated on a draft of the form, then it can be identified more easily)
Alternately permit both (or I'll be adding an extension to include it in my uses)
Lloyd McKenzie (Nov 16 2016 at 03:10):
I think we need some improved documentation around how resource references are intended to work with "canonical" URLs. Maybe "reference" can satisfy both use-cases after all.
Lloyd McKenzie (Nov 16 2016 at 03:10):
@Grahame Grieve -thoughts?
Grahame Grieve (Nov 16 2016 at 03:12):
see task GF#10576
Lloyd McKenzie (Nov 16 2016 at 03:13):
The question is more about whether a "reference" can be resolved based on canonical URL to a local repository rather than its declared repository
Grahame Grieve (Nov 16 2016 at 03:14):
I'm not sure I understand that question. you seem to be mixing canonical URL and reference
Lloyd McKenzie (Nov 16 2016 at 03:16):
Questionnaire now has a canonical URL. The QuestionnaireResponse is intended to point to that canonical URL (so independent of where the Questionnaire is actually stored). The question is whether you can point to the canonical URL using "Reference" and expect systems to resolve it.
Grahame Grieve (Nov 16 2016 at 03:20):
from http://build.fhir.org/references.html#2.18.0.4:
Systems resolving references to resources that might have cannonical URLs SHOULD first try to resolve the reference using the cannonical URL, and then fall back to direct resolution using the URL as a literal reference if a local version of the canonical resource cannot be found
Grahame Grieve (Nov 16 2016 at 10:28):
It turns out I have a problem with this - I'm using contained Questionnaires in a few circumstances, and they have no canonical URL
Pascal Pfiffner (Nov 16 2016 at 10:38):
Similar to Brian, I would also assume that I can resolve the Questionnaire that was used with a standard reference; the reference will be absolute if I don't create the response on the same server I got the Questionnaire from, so I'll have a canonical URL after all.
Josh Mandel (Nov 16 2016 at 11:01):
Well, I think @Grahame Grieve is saying that Questionnaire doesn't have the equivalent of ValueSet.url
Josh Mandel (Nov 16 2016 at 11:01):
Which is true, and a pain I'm feeling, too
Grahame Grieve (Nov 16 2016 at 11:01):
it does, but I'm not using it in all cases
Josh Mandel (Nov 16 2016 at 11:01):
... but are you saying that *if it did, you could link directly to it through QuestionnaireResponse.questionnaire**?
Grahame Grieve (Nov 16 2016 at 11:02):
and I don't want to have to, just like I don't want to have to for ValueSet either
Josh Mandel (Nov 16 2016 at 11:04):
So to be clear, you'd be saying to remove the url property from ValueSet (and never add one to Questionnaire), and just use absolute URLs to link to things... and sometimes the absolute URL can be a canonical, if you want.
Grahame Grieve (Nov 16 2016 at 11:05):
no. I'm saying, leave the URL as 0..1, and leave references as choice (uri / Reference) like w do with ValueSet
Josh Mandel (Nov 16 2016 at 11:05):
But would canonical URLs need to resolve (i.e. to be de-referenceable)?
Grahame Grieve (Nov 16 2016 at 11:05):
they can. and should
Josh Mandel (Nov 16 2016 at 11:06):
so you'd be saying, rename QuestionnaireResponse.questionnaire to QuestionnaireResponse.questionnaire[x], which is either questionnaireReference or questionnaireUri?
Lloyd McKenzie (Nov 16 2016 at 11:18):
@Grahame Grieve If the Questionnaires are contained, you can't really reference them at all - there's no way to reference contained references from outside the containing resource. I don't understand why we would make url 0..1 for Questionnaire when it's 1..1 for StructureDefinition
Lloyd McKenzie (Nov 16 2016 at 11:19):
I think QuestionnaireResponse.questionnaire can go back to being Reference. The change to uri was intended to support canonical references, which is already supported by Reference.
Grahame Grieve (Nov 16 2016 at 11:19):
it is 0..1. Like value set. if the questionnaire is contained in a questionnaireResponse, you can referenced from the response. but you can reference contained resources from outside the contained resource
Lloyd McKenzie (Nov 16 2016 at 11:25):
How do you reference contained resources from outside the contained resource? I thought the whole point of containing was that you weren't *supposed* to reference them from outside the containing resource.
Lloyd McKenzie (Nov 16 2016 at 11:25):
Why is ValueSet 0..1 and StructureDefinition 1..1?
Grahame Grieve (Nov 16 2016 at 11:51):
http://hl7.org/fhir/Questionnaire/qs1#vs2
Grahame Grieve (Nov 16 2016 at 11:52):
I don't really know why they're different. I presume we've found use cases for embedded value sets but not for profiles
Lloyd McKenzie (Nov 16 2016 at 11:54):
I don't understand why we would want to allow referencing a contained resource. If it's sufficiently identifiable that we want to make it referencable, why isn't it stand-alone?
Lloyd McKenzie (Nov 16 2016 at 11:54):
And why can't we put a canonical URL on a contained resource?
Grahame Grieve (Nov 16 2016 at 12:01):
you can put a canonical URL on a contained resource, but now you have to make it unique. And also, you can't make it contained anymore, because there's no reference to it
Grahame Grieve (Nov 16 2016 at 12:02):
you might want to reference a contained resource for the same resource you reference a historical version of a resource. And I can reference a contained resource without being identifiable. that's a different problem
Michelle (Moseman) Miller (Nov 16 2016 at 18:20):
Have we landed the recommendation? GF#10429 is already applied, so we should probably log a new gForge to make another change (and PCWG meets tomorrow to squeeze in a quick vote.) Is the only change requested here that QuestionnaireResponse.questionnaire should be a choice of either reference or uri?
Lloyd McKenzie (Nov 16 2016 at 19:52):
I think we just change it back to reference. There's no need for URI. (URI is needed on value set because you want to be able to point to web pages for things like language codes and mime types, but it makes no sense to support that for Questionnaire.)
Michelle (Moseman) Miller (Nov 16 2016 at 20:33):
@Lloyd McKenzie , since you logged the original GF#10429, can you simply withdraw it -- or does PC need to vote on a new tracker item to revert back to reference only?
Lloyd McKenzie (Nov 16 2016 at 21:13):
I think once a change is approved, it's inappropriate to withdraw a request (though I'm not aware of a formal rule). I think it'd be best to have a change tracker to revisit the item.
Lloyd McKenzie (Nov 16 2016 at 21:13):
Or even just a revote on the existing one.
Michelle (Moseman) Miller (Nov 16 2016 at 21:23):
OK, I'll plan to revote on the existing one then.
wassim (Nov 17 2016 at 00:25):
@Lloyd McKenzie thank you for the encouragement , i have just a small question the access of users on the hapi Fhir will be from a browser or from an software that i have to develop , and secondly what is the smart on fhir ,, thanks again and sorry if my questions are dumm
Richard Townley-O'Neill (Nov 17 2016 at 01:51):
@Grahame Grieve The link http://hl7.org/fhir/Questionnaire/qs1#vs2 gives me a 404 - File not found
Grahame Grieve (Nov 17 2016 at 01:57):
.. in which we find that I still haven't resolved making the fhir specification an instance of itself in every regard
Richard Townley-O'Neill (Nov 17 2016 at 02:02):
What should this lead me to? I guess somewhere in http://hl7.org/fhir/questionnaire.html
Grahame Grieve (Nov 17 2016 at 02:04):
actually, I just got a resource that is not in the published version. This URL:
http://hl7.org/fhir/Questionnaire/gcs#motor
Richard Townley-O'Neill (Nov 17 2016 at 02:14):
Ta
Lloyd McKenzie (Nov 17 2016 at 04:37):
@wassim HAPI is a Java implementation of FHIR, so typically you would use it to construct a stand-alone application. You can find information about SMART on FHIR here: http://smarthealthit.org/smart-on-fhir/
Michelle (Moseman) Miller (Nov 18 2016 at 00:02):
FYI - Patient Care approved the change to revert back to having QuestionnaireResponse.questionnaire be a Reference (Questionnaire). The change (reverting back to prior state) has been applied.
Grahame Grieve (Nov 18 2016 at 06:16):
Thanks Michelle
Chris Wand (Nov 23 2016 at 16:46):
Is there a requirement or expectation that a QuestionnaireResponse have the same structure as the Questionnaire that it refers to? I'm thinking specifically of having a Questionnaire that has some structure (using item.type = group) but a QuestionnaireResponse that is a flat list of items and relies solely on the link-ids to handle connecting them.
Pascal Pfiffner (Nov 23 2016 at 17:02):
We had discussed this before, and while the expectation is indeed that the response mirrors the hierarchy of the questionnaire, some (including myself) only care about linkId and are using a somewhat flat representation. Lloyd is on vacation so he will only be able to retaliate in 2 weeks. ;)
Grahame Grieve (Nov 24 2016 at 07:50):
what I think we said is that in simple cases, a flat questionnaireresponse can be properly linked, but once you have nested repeating structures, it can't. So we recommended following the structure, knowing that in most cases, you'll have to
Brian Postlethwaite (Nov 27 2016 at 10:40):
@Michelle (Moseman) Miller a big thanks for that rollback
As for the flattening @Chris Wand , it makes things so much easier to parse an validate when the tree is complete.
Lloyd McKenzie (Dec 05 2016 at 18:34):
@Chris Wand @Pascal Pfiffner I'm back. And I think the expectation is that the response must exactly mirror the structure of the questionnaire - though of course you can omit optional elements. If that's not explicit, it should be. I've added GF#12430
Anna Lackerbauer (Oct 03 2017 at 14:06):
Hello! What is the appropriate answer-type in a QuestionnaireResponse if the Question of the Questionnaire is of type CHOICE with options set to a Reference(ValueSet)? Should it be of type Coding that is generated from the chosen system and code of the ValueSet? Thanks a lot, Anna
Lloyd McKenzie (Oct 03 2017 at 19:23):
Yes - as per http://hl7.org/fhir/questionnaire.html#2.38.5.5
Lucas Smithen (Jun 08 2018 at 16:45):
Trying to read through the documentation and getting a bit confused. Is there a FHIR rest call that allows me to query the list of available questionnaireresponse's for a given patientId.
Lloyd McKenzie (Jun 08 2018 at 18:04):
[base]/QuestionnaireResponse?patient.identifier=1234
Lloyd McKenzie (Jun 08 2018 at 18:05):
If you want to filter by Questionnaire as well:
[base]/QuestionnaireResponse?patient.identifier=1234&questionnaire.url=[escaped url]
Lucas Smithen (Jun 08 2018 at 19:30):
Now would that give me the actual the QuestionnaireResponses including the values/responses or just the meta data of which ones are available?
Grahame Grieve (Jun 08 2018 at 20:13):
that would give you actual responses. Try http://test.fhir.org/r3/QuestionnaireResponse?patient=example&_format=json
Eric Haas (Jun 08 2018 at 20:28):
what part is confusing in the docs?
Tim Berezny (Jul 30 2019 at 13:32):
I notice that QuestionaireResponse can be used INDEPENDENTLY of the Questionnaire resource, which is very interesting, as many systems have their own pre-existing approaches to generating questionnaires but may want to save the output in a common easily interpretable format before tackling building in Questionnaire resource functionality to their applications.
It looks to me like it essentially represents a set of key-value pairs between the "text" and "answer" elements. Is this a correct interpretation of its intention?
If I wanted to include a coded version of the question (i.e.g, the "text" element), would that be best done with an extension on the code value? (or, an extension on the display value... or some other option).
Geoff Ramsay (Jul 30 2019 at 13:44):
I believe 'item.text' can be used to record the textual label of the question.
QuestionnaireResponse seems to have a lot of value as a method of recording key/value pairings (linkId/answer) in data transmission use cases with a messaging paradigm.
My hope is that if designed well, there shouldn't be an obstacle to implementing the standardized questionnaire after the fact.
Tim Berezny (Jul 30 2019 at 14:44):
@Geoff Ramsay I think that linkID is reserved for the ID of a field in a Questionnaire resource, rather than putting an ID/code for the question in the response itself. It looks to me like the text (which i'm interpreting as the display text for the question) would have to be treated as the question ID.
Although, another option might be to use the "item.definition" (which is a url) as the question ID ...?
Geoff Ramsay (Jul 30 2019 at 14:58):
Hmm... all the examples seem to use linkId as a fairly deterministic value, based on it's position in the message... (i.e. "linkID": "1" / "linkId":"1.1" / "linkId":"2")
I suppose I took it for granted that I could define those Ids as whatever I wanted - maybe that's not he intent? But linkId is just a string... so why not! :big_smile:
If the linkIds are the actual field values of the data I want to transmit, it saves a mapping step.
{
"resource": {
"resourceType": "QuestionnaireResponse",
"id": "1",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>[example]</p></div>"
},
"status": "completed",
"subject": {
"reference": "Patient/1",
"type": "Patient"
},
"authored": "2019-07-19T14:15:00+10:00",
"author": {
"reference": "Practitioner/00000000001",
"type": "Practitioner"
},
"item": [
{
"linkId": "Question1",
"text": "Label for Question1",
"answer": [
{
"valueString": "3"
}
]
},
{
"linkId": "Question2",
"text": "Label for Question2",
"answer": [
{
"valueString": "2009-07-12"
}
]
},
{
"linkId": "Question3",
"text": "Label for Question3",
"answer": [
{
"valueString": "aasdaf"
}
]
},
] }
Lloyd McKenzie (Jul 30 2019 at 14:58):
A QuestionnaireResponse can sort of stand on its own. You do depend on meaningful linkId values to have a hope of doing anything computable with the results. And all of the "rules" about what's mandatory/optional/conditional, what the allowed values are, etc. only appears in the Questionnaire.
Lloyd McKenzie (Jul 30 2019 at 14:59):
linkIds can be whatever you like - they could be guids if you wished. The key thing is that every linkId corresponds to a single unique item within the Questionnaire.
Tim Berezny (Jul 30 2019 at 15:15):
@Lloyd McKenzie if a QuestionnaireRespons is being used in a standalone manner apart from a FHIR Questionnaire (for example, referencing back to a system's own internal approach to questionnaires) would it make sense to use the linkId to reference how that system identifies the item? Or must it be a linkID of a FHIR Questionnaire by definition?
Lloyd McKenzie (Jul 30 2019 at 15:18):
It should be whatever would make sense as the linkId if you were to ever expose the questionnaire definition as a Questionnaire.
Tim Berezny (Jul 30 2019 at 15:24):
Sounds like a good guiding principle, thanks @Lloyd McKenzie
Tim Berezny (Aug 09 2019 at 18:58):
If I'm using questionnaireResponse in a workflow without the use of Questionnaire, i notice that there are TWO options for providing nested answers.
1) questionnaireResponse.item.answer.item
2) questionnaireResponse.item.item
Is it fair to say that conceptually:
option 1) is can be used when you have sub-questions/items that are dependant on the answer to the parent question/item?
option 2) the questionnaireResponse.item.text can behave as a "header" to a group of questions contained in the questionResponse.item.item
?
Paul Lynch (Aug 12 2019 at 17:17):
@Tim Berezny See https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/QuestionnaireResponse.20item.2Eitem.20vs.20item.2Eanswer.2Eitem which might answer your question.
Tim Berezny (Aug 12 2019 at 17:28):
Yes that answers it thanks @Paul Lynch
Tim Berezny (Sep 10 2019 at 12:33):
We created a little web app for processing and displaying items in a QuestionnaireResponse (which is INDEPENDENT of a corresponding Questionnaire). You can put any QuestionnaireResponse into the box and it will give you a nice screen formatted human-readable version of the results. We've got a couple sample payloads in there to test out with, you can also put your own in here.
If you're interested in QuestionnaireResponse please give it a try and let me know how it works for you and any feedback you might have, I think it might be a useful tool for the community! Also, if you have some interesting sample payloads send them over and I can pre-load them into the set of sample payloads.
Give it a try here:
https://questionnaireresponse-parser.herokuapp.com/
Jens Villadsen (Sep 10 2019 at 12:38):
@Oliver Egger
Geoff Ramsay (Feb 18 2020 at 18:24):
We've been having a lot of fun with QuestionnaireResponse in the Canadian eReferral space!
But, the description of the qrs-1 business invariant has tripped a few of us up.
"Nested item can't be beneath both item and answer"
https://www.hl7.org/fhir/questionnaireresponse.html#invs
It's meant to indicate that an item cannot have both an 'item' and an 'answer ' as child nodes. [expression applying to item: '(answer.exists() and item.exists()).not()' ].
The current description doesn't convey that accurately.
Would the community support updating the description of qrs-1 to be something like:
'Item cannot contain both item and answer'
Some folks have also postulated a 'choice' here (https://www.hl7.org/fhir/formats.html#choice), but both 'item' and 'answer' are multi-cardinality fields, so I believe that won't be possible.
Lloyd McKenzie (Feb 18 2020 at 20:47):
By all means, feel free to submit a change request for us to improve the language. (And you're right, we can't have a choice - in addition to the cardinality issue, t's also not possible to have choices that include backbone elements.)
Tim Berezny (Feb 18 2020 at 23:25):
@Geoff Ramsay the change requests can be submitted here: https://gforge.hl7.org/gf/account/
Lloyd McKenzie (Feb 19 2020 at 00:48):
@Tim Berezny Change requests shouldn't go to gForge any longer - we now use Jira (http://jira.hl7.org)
Geoff Ramsay (Feb 19 2020 at 16:14):
Thanks gentlemen - I created it this morning:
https://jira.hl7.org/browse/FHIR-26356
Tim Berezny (Feb 19 2020 at 16:42):
I think I would like to validate which of the following is actually intended to be the correct restriction for the questionnaireResponse (i.e., is the description bad, or the constraint expression wrong).
https://www.hl7.org/fhir/questionnaireresponse.html#invs
- Description: "Nested item can't be beneath both item and answer"
- Expression: "[expression applying to item: '(answer.exists() and item.exists()).not()' ]."
Which means "Item cannot contain both item and an answer"
(note that 1 is actually still technically true... but it is an implied restriction sub-restriction of 2)
Is the INTENTION of this restriction to be #1 or #2?
Lloyd McKenzie (Feb 19 2020 at 16:46):
I think #2, though that has ramifications for 'display' items
Tim Berezny (Feb 19 2020 at 17:04):
By ramifications for "display" items, do you mean that technically a "display" item could technically have "grouping" functionality because it has no answer[x], thus you could put a sub item.item under a display text?
Lloyd McKenzie (Feb 19 2020 at 17:55):
If you have a question that has answers, that would preclude you from sending a nested display under the question as well
Tim Berezny (Feb 20 2020 at 16:18):
When a QuestionnaireResponse is used independently of a Questionnaire, it seems to me that there is no method in a QuestionnaireResponse to distinguish between a group header and display text (note: in the narrative for QuestionnaireResponse it says that display text can be included).
Here are the 4 ways that a QuestionnaireResponse renderer can iterpret the data for user display (from my understanding):
- Questions & Answers: Use item.text for question, and item.answer for the answer (no item.item allowed)
- Nested Questions: Use item.text/item.answer[] for the parent question/answer, and put the nested question into item.answer[].item (no item.item allowed)
- Group Headers Use item.text for the header text, with a item.item to group items under that header (no item.answer allowed)
- Display Text: Use item.text for the display text, with a item.item to group items under that header (no item.answer allowed)
The problem here is, "Group Headers" and "Display Text" have the exact SAME structure. How should we distinguish between header and display text in a QuestionnaireResponse (absent of a Questionnaire to reference?)
Lloyd McKenzie (Feb 20 2020 at 16:28):
A group header with no information beneath it doesn't functionally behave differently from display text.
Tim Berezny (Feb 20 2020 at 16:42):
Ah yes, of course, re-worded:
Group Headers Use item.text for the header text, with a item.item to group items under that header (no item.answer allowed)
Display Text: Use item.text for the display text (no item.item and no item.answer allowed)
Tim Berezny (Feb 20 2020 at 16:44):
And this means that display items can have sub-display items, which should be fine ... i can't think of a use case where you'd want to do that.
Paul Lynch (Feb 20 2020 at 18:06):
Tim Berezny said:
And this means that display items can have sub-display items, which should be fine ...
Actually, the definition of type "display" says: "Text for display that will not capture an answer or have child items." So, you can't have a display item that is a child of another display item. Also, since display items can't have either answers or child items, I would not expect those to appear in a QuestionnaireResponse.
Tim Berezny (Feb 21 2020 at 01:17):
Thanks, that's perfect @Paul Lynch
Tim Berezny (Feb 24 2020 at 15:55):
After looking deeper into some of the descriptive language on QuestionnaireResponse (and getting thoroughly confused on each of these points), I have a few more text change suggestions but would like to ensure that what I have written is in fact correct for the intention of these fields before posting a change request. See screenshot for suggested changes. (note: #1 is the item for which @Geoff Ramsay has already posted a change request, 2,3,4 are new proposals).
@Tyson Louth @Ion Moraru @Paul Lynch @Geoff Ramsay @Lloyd McKenzie
Lloyd McKenzie (Feb 24 2020 at 16:06):
I don't think we can do #4 - type isn't exposed in QuestionnaireResponse and rules need to be enforcable without looking outside the instance.
For #2, stuff nested within a question might be groups or questions. I think the proposed label would be misleading about that. Same issue with #3 - the grouped stuff could also be groups.
Paul Lynch (Feb 24 2020 at 16:24):
Also, regarding #4, items of type "display" would not be present, so it could be confusing to create a rule about what they can't contain. I think change #1 is good, though.
Tim Berezny (Feb 24 2020 at 16:28):
How about this:
#2. Nested questions and groups
#3. Grouped questions and groups
#4. I see your point. Would it be fair to include something to this effect in the narrative rather than the tree.
I think using a mirrored descriptive text for #2 item.answer.item #3 item.item helps clarify the difference between the two.
Tim Berezny (Feb 24 2020 at 16:31):
(deleted)
Paul Lynch (Feb 24 2020 at 16:41):
I think of "Grouped" as a kind of "Nested", so I am not sure that is as clear as it might be. How about:
#2: Sub-questions and groups under a question
#3: Questions and sub-groups within a group
Tim Berezny (Feb 24 2020 at 16:59):
Yes, i also think of them similarly too... which I think is the source of a lot of confusion because they are treated differently and distinct. A "Group" is a specific thing in that it has an item type of its own in the questionnaire, and has a "group label/header".
The concept of nested vs. grouped (or some other terminology) may need to be made explicitly in the questionnaire/questionnaireResponse narrative
Although, I see you've abandoned the language of "nested" questions entirely, and substituted it with the word "Sub", which may be naturally more distinct in people's minds than "nested". In fact, in our office we had actually naturally gravitated to that word too...
A slight modification to @Paul Lynch 's proposed wording
#2: Sub-questions and sub-groups under a question
#3: Questions and sub-groups within a group
Lloyd McKenzie (Feb 24 2020 at 17:22):
I'm happy with the revised proposal - can you submit a change request @Tim Berezny?
Tim Berezny (Feb 24 2020 at 20:55):
We've created a useful little QuestionnaireResponse formatter, with some sample payloads to try rendering QuestionnaireResponse resources (without a corresponding Questionnaire). If anybody has some QuestionnaireResponse resources you'd like to play with, please copy-paste them into the box at the top of the page and let me know if they show up the way you would expect them to. We've found this to be useful already in helping integrating parties to a) understand the QuestionnaireResponse resource and b) ensure both parties are interpreting it the same way.
Here is the app, would love to hear any feedback.
https://questionnaireresponse-parser.herokuapp.com/
Paul Lynch (Mar 05 2020 at 22:47):
Paul Lynch said:
Tim Berezny said:
And this means that display items can have sub-display items, which should be fine ...
Actually, the definition of type "display" says: "Text for display that will not capture an answer or have child items." So, you can't have a display item that is a child of another display item. Also, since display items can't have either answers or child items, I would not expect those to appear in a QuestionnaireResponse.
There was just a change to this in issue J#25949. Now display items can (but might not) appear in the QuestionnaireResponse, except that there is an extension somewhere which you will be able to use to require that they do.
Armin Griebler (May 11 2020 at 14:04):
Hello, I have got a question about the linkage between QuestionnaireResponse and Questionnaire. Therefore, I use the item "questionnaire" to make a reference to the resource Questionnaire. It looks something like this: "questionnaire" : "Questionnaire/1234". Although my fhir server considers both resources as valid it does not recognize the linkage between them. Is this an issue due to the server or could that be a structural issue within my resources, although they are valid?
René Spronk (May 11 2020 at 14:16):
That should be a canonical URL (and not a reference), with the same value as Questionniare.url
Lloyd McKenzie (May 11 2020 at 19:37):
Rene is correct - you can't use 'local' references in a Canonical
Armin Griebler (May 12 2020 at 09:37):
Thank you @René Spronk and @Lloyd McKenzie for your quick answers!
Last updated: Apr 12 2022 at 19:14 UTC
