Stream: questionnaire
Topic: Understanding SDC Workflows
Grey Faulkenberry (Dec 10 2021 at 16:35):
I've been working through SDC workflows for single and multiple Questionnaires. For a group of Questionnaires, I have been using a Task (or possibly a Task with multiple sub-tasks). I think this makes sense for both EHR launch or external EHR launch. I've been using the full workflow below:
- ServiceRequest (refers to PlanDefinition)
- Task (created from Resources in the PlanDefinition)
- Questionnaires/QuestionnaireResponses as inputs/outputs for the Task
- Measure/MeasureReport to calculate overall scores for multiple Questionnaires in one location
Grey Faulkenberry (Dec 10 2021 at 16:38):
What I'm not completely sure of is the workflow for a single Questionnaire. I'm assuming this is almost always going to be launched from within an EHR, and I could go through the above workflow, but it feels a little cumbersome if it's just for a single Questionnaire. Does anyone else have a suggestion on the workflow for a single Questionnaire?
Lloyd McKenzie (Dec 10 2021 at 19:25):
Each Questionnaire should have its own Task - because status around "will I complete" and "Is it completed" is on a per QuestionnaireResponse basis. There's only a need for a ServiceRequest if you need a formal order/authorization. Otherwise you can just use Task. Obviously Measure/MeasureReport utility depends on whether you need those too.
Grey Faulkenberry (Dec 10 2021 at 20:57):
What's the advantage of having a Task for each questionnaire? If I have a number of Questionnaires as the input for a single Task, and QuestionnaireResponses as the output. I can check which QuestionnaireResponse is completed vs in-process, what extra information would sub-tasks have in this situation?
Lloyd McKenzie (Dec 11 2021 at 05:21):
The user might refuse to fill out Questionnaire #1, have completed #2 and have #3 on-hold because they need to hear back from their mom before they can finish it - each would have a distinct Task.status (and possibly Task.reason).
Lloyd McKenzie (Dec 11 2021 at 05:22):
Tasks should be issued at the level such that acceptance/refusal and complete/cancel applies to the full request.
Grey Faulkenberry (Dec 12 2021 at 05:48):
So in that case, would the overall organization be something like this:
- Primary Task: inputs would include all Questionnaires, ValueSets, outputs would be subtasks
- Subtasks: inputs would include a single Questionnaire, outputs would be a single QuestionnaireResponse
Lloyd McKenzie (Dec 12 2021 at 22:43):
My expectation would be that primary Task wouldn't list any questionnaires, but might have a high-level description such as "complete admission forms". SubTasks would each point to the Questionnaire and QuestionnaireResponse. I don't see a whole lot of benefit to listing all of the Questionnaires and QRs multiple times
Grey Faulkenberry (Dec 12 2021 at 23:54):
So then would the overarching task have any inputs? I guess maybe just a planDefinition?
Lloyd McKenzie (Dec 13 2021 at 01:28):
It could be 'basedOn' a planDefinition. Do you need to track overall completeness of the collection of Questionnaires? I.e. Is there a need for an overarching Task?
Grey Faulkenberry (Dec 13 2021 at 15:06):
I think so. The assignment would be to complete a group of questionnaires (based on the PlanDefinition). So I think I'd need an overarching Task, and then multiple subtasks for each questionnaire. I was just trying to clarify what the input and output for each of those would be.
Lloyd McKenzie (Dec 13 2021 at 15:18):
You don't need to have the Task just because you're instantiating the PlanDefinition. The Task should have a business value in and of itself.
Grey Faulkenberry (Dec 13 2021 at 16:22):
Then I may be confused over the best way to represent the workflow. Say I have a doctor enter an order (ServiceRequest) for a patient to complete a group of screening Questionnaires (which Questionnaries are defined in a PlanDefinition). It is multiple Questionnaires that need to be completed, so they would each have their own Task. At the same time, it is a single order placed by the doctor, so I thought there would be some way to group them all together as a single unit (which I assumed was the overarching Task). Would I just keep track of each individual Task instead?
Lloyd McKenzie (Dec 13 2021 at 22:58):
Typically yes. The only time you'd need an overarching Task is if you're trying to get someone to say yes to something 'overall' and have that be meaningful and useful as distinct from their responses on the individual tasks.
Grey Faulkenberry (Dec 14 2021 at 14:32):
I think I was thinking about a way to group them together for more efficient searching, something like this scenario: If I have a patient, and the doctor has ordered the patient to complete 3 different sets of questionnaires, and each set contains 3 questionnaires. In this case, let's say it's 3 different procedures. Each procedure has a different insurance form, a different medical history form, and then a consent form.
- Colonoscopy - insurance form, history form, consent form
- Mole removal - insurance form, history form, consent form
- Mammogram - insurance form, history form, consent form
The patient has to complete all 3 questionnaires in a set before the doctor can act on them. The patient has a mobile application installed on their phone that lets them complete the questionnaires, and they would like to complete the 2nd set of questionnaires first because the mole removal appointment is going to happen soonest. How do I find those? Would I go back and look at the ServiceRequest? That feels a little inefficient (e.g. ServiceRequest -> PlanDefinition -> Questionnaires -> QuestionnaireResponses). The system that we're interacting with could just pass a list of the 3 Questionnaires along with 3 Tasks for each procedure, but that list would have to be stored in whatever system we're interacting with, it wouldn't be stored in FHIR, UNLESS there's an overarching task that groups each set of questionnaires together.
At least, this is how it happens in my head. Is there a better way to represent this?
Lloyd McKenzie (Dec 14 2021 at 16:14):
You'd have 3 ServiceRequests. Each of the Tasks would have a 'basedOn' link to their respective ServiceReqeust. So that might suffice. You certainly can create a parent Task if you need one. I just wanted it to be clear that it's not necessarily something that will be necessary.
Grey Faulkenberry (Dec 15 2021 at 16:30):
No, that makes sense. Not needed but allowed. So then, our workflow would look like this (not all pieces required, but allowed in the way we are using them):
---
resourceType: ServiceRequest
id: 1
instantiatesUri:
- PlanDefinition/1
intent: order
subject:
reference: Patient/1
requester:
reference: Provider/1
performer:
- reference: Patient/1
---
resourceType: PlanDefinition
id: 1
description: Colonoscopy, Pre-Procedure
name: pre_colonoscopy
title: Forms to be Completed Prior to Colonoscopy
action:
- definitionUri: Questionnaire/1
participant:
- type: patient
title: Insurance Form
- definitionUri: Questionnaire/2
participant:
- type: patient
title: History Form
- definitionUri: Questionnaire/3
participant:
- type: patient
title: Consent Form
---
resourceType: Task
id: overarching
intent: order
owner:
reference: Patient/1
requester:
reference: Provider/1
instantiatesUri: PlanDefinition/1
basedOn:
- reference: ServiceRequest/1
- reference: PlanDefinition/1
for:
reference: Patient/1
output:
- type:
coding:
- system: http://hl7.org/fhir/resource-types
code: Task
valueUri: Task/1
- type:
coding:
- system: http://hl7.org/fhir/resource-types
code: Task
valueUri: Task/2
- type:
coding:
- system: http://hl7.org/fhir/resource-types
code: Task
valueUri: Task/3
Should the PlanDefinition be in the instantiatesUri or basedOn field? And I assume the subtasks will be considered outputs?
---
resourceType: Task
id: 1
intent: order
owner:
reference: Patient/1
requester:
reference: Provider/1
for:
reference: Patient/1
partOf:
reference: Task/overarching
input:
- type:
coding:
- system: http://hl7.org/fhir/uv/sdc/CodeSystem/temp
code: questionnaire
valueUri: Questionnaire/1
output:
- type:
coding:
- code: collect-information
display: Collect Information
system: http://hl7.org/fhir/uv/cpg/CodeSystem/cpg-activity-type
valueUri: QuestionnaireResponse/1
Is there a preference, generally, between using valueUri, valueCanonical, and valueReference? It would be nice if valueReference was part of the _include=* search, but since it's not a Search Parameter it isn't (but it would make it much easier to pull all included Resources).
Lloyd McKenzie (Dec 15 2021 at 20:13):
You wouldn't have the sub-tasks as outputs. The sub-tasks would point to the parent via partOf. (We always try to avoid bidirectional references.) The parent Task wouldn't have any inputs or outputs, just an overall status. (Which is why I was questioning its value)
Grey Faulkenberry (Dec 16 2021 at 00:31):
It's value probably isn't huge, and in some cases it could probably be removed. I think I was trying to come up with a similar pattern for all of the workflows, but maybe that isn't possible.
If there's +/- ServiceRequest -> Task/Questionnaire/QuestionnaireResponse, that's pretty straight forward.
If there's a ServiceRequest with multiple Tasks/Questionnaires/QuestionnaireResponses without an overarching Task, then as you say, I have to reference the ServiceRequests from each Task in order to group them together.
But then I still run into the problem, what if there's a group of questionnaires that are supposed to be completed together, and there's no ServiceRequest (for instance, if I'm in clinic, completing multiple forms for a Patient). If there are 3 Questionnaires that need to be completed by me, but no ServiceRequest (because there's no order placed). So then I'm left with a Task/Questionnaire/QuestionnaireResponse x 3, but no way to group them together, unless I create that overarching Task (which really ONLY has the function of identifying that they belong together).
Lloyd McKenzie (Dec 16 2021 at 18:53):
You could use Task.groupIdentifier
Last updated: Apr 12 2022 at 19:14 UTC
