Stream: questionnaire
Topic: Adding usage data to QResponses
Matthew Steer (Sep 27 2019 at 12:57):
Hi. Sorry, asked this in #implementers before I realised there was a dedicated stream for #questionnaire. Can't see how to delete...? Anyway, this seems like the better place to ask my question:
We provide digital forms for patients to fill in at home, then we add the responses into a FHIR API as QuestionnaireResponses for our healthcare provider clients to ingest. We want to enrich the data with information about the usage of our forms. For example: when was the form sent to the patient, when was the due date for responding, when did the patient respond, did they complete their response or give up, etc.
I am trying to decide whether it is reasonable to treat the process of sending a digital form to a patient and getting their response as a special kind of "Encounter" (and so capturing these data points in that resource, with the QuestionnaireResponse linked), or whether it is more sensible to just add Extensions to QuestionnaireResponse to capture these extra data points.
I'd really appreciate any other views on this, thanks.
Brian Postlethwaite (Sep 27 2019 at 13:25):
For this kind of workflow take a look at Task. There are probably others, I'll will think about them.
If you have the set of properties available would be helpful to choose.
Matthew Steer (Sep 27 2019 at 13:38):
Thanks Brian, Task does look perfect. I simply wasn't aware of it - new to FHIR and there's nothing in QuestionnaireResponse that suggests it. I guess that might be the only drawback - there's no obvious way to navigate from the QResponse to the Task (i.e. I can't see anywhere to reference a Task from a QResponse resource). Would the normal approach be to say that the Task is "contained" in the QResponse?
Lloyd McKenzie (Sep 27 2019 at 16:54):
Generally, the Task would point to the QuestionnaireResponse as an 'output'. The Task would indicate if the patient agreed to do it (if they even have the option) and could capture that they refused (and why) when a QuestionnaireResponse wouldn't even exist
Lloyd McKenzie (Sep 27 2019 at 16:54):
I.e. the Task exists before the QuestionnaireResponse and might be the only thing that exists.
Lloyd McKenzie (Sep 27 2019 at 16:55):
'contained' is never to be used as a convenient packaging mechanism, but only when a referenced resource can't stand alone. If you want to convey both the Task and QR, you can use a Batch or Transaction Bundle.
Matthew Steer (Sep 27 2019 at 17:00):
Got it. Thanks for the help @Lloyd McKenzie!
Brian Postlethwaite (Sep 27 2019 at 21:52):
@Lloyd McKenzie was servicerequest the other resource that could be used for the planning stage?
Lloyd McKenzie (Sep 28 2019 at 01:48):
ServiceRequest can be used to define an authorization or indicate that the questionnaire should be filled out on a repeated basis. CarePlan is another option
Matthew Steer (Sep 30 2019 at 09:34):
ServiceRequest feels like a better fit, if only because QResponse natively supports referring to a ServiceRequest that triggered it. That feels a little more coherent than having to bundle a QResponse and a Task in order to keep the two linked.
Lloyd McKenzie (Sep 30 2019 at 15:23):
ServiceRequest lets you identify what 'authorized/ordered' the completion. CarePlan is in that list too. Task is what lets you actually trigger the fulfillment and track the 'to do' item.
Last updated: Apr 12 2022 at 19:14 UTC
