Stream: workflow
Topic: Questionnaire Task
milton mitjans (Jun 15 2021 at 15:41):
Is there an example how a Task generated for a user to take a Questionnaire? For example how would a Questionnaire ID would be reference.
We were thinking something along the lines of:
{
"resourceType": "Task",
"status": "ready",
"intent": "proposal",
"priority": "routine",
"description": "free text here - could use for actual UI display, e.g.: Start your assessment",
"input": [{
"type": {
"text": "questionnaireId"
},
"valueString": "asdf-1234-fdsa"
}
]
}
Eric Haas (Jun 15 2021 at 18:00):
here is an example based on how we did this in Da Vinci CDEX CI build
resourceType: Task
status: ready
intent: proposal
code:
text: Tasks for Patient X
for:
reference: 'http://example.org/fhir/Patient/cdex-example-patient'
authoredOn: '2020-10-26T02:58:55.179Z'
lastModified: '2020-10-26T02:58:55.179Z'
requester:
reference: 'http://example.org/fhir/Organization/cdex-example-payer'
owner:
reference: 'http://example.org/fhir/Organization/cdex-example-provider'
reasonCode:
text: My Reason Here ...
input: # <<<<<<< Use input to reference the Questionnaire
- type:
coding:
- system: 'http://example.org/fhir/CodeSystem/input-type'
code: patient-inputs
valuereference:
reference: 'http://example.org/fhir/Questionnaire/my-q' # <<<<<<< Questionnaire referenced here
Lloyd McKenzie (Jun 24 2021 at 01:42):
The CDex approach aligns with the profile defined in the SDC IG for how to do this: http://build.fhir.org/ig/HL7/sdc/StructureDefinition-sdc-task.html
Josh Mandel (Jun 24 2021 at 14:16):
Note that this example is provider-centric, in that it's a task owned by the provider. The original question in this thread was a task for a user to take the questionnaire, rather than for a user to get their patient to fill out a questionnaire.
It would be good to have a code at some level indicating "I want somebody to fill out this questionnaire"; in the example above, I think this is implicit. It's clear there is some task for the patient and it involves a questionnaire but you could imagine things like "please review this questionnaire and make sure the questions are readable" or "please translate this questionnaire into your native language". It would be nice for the semantics of "please complete" to surface either at the task code or the input type level.
Lloyd McKenzie (Jun 24 2021 at 17:50):
Isn't a Task.code of "complete-questionnaire" (with appropriate definition) sufficient?
Lloyd McKenzie (Jun 24 2021 at 17:51):
@Eric Haas The example should be updated to align with the SDC profile
Josh Mandel (Jun 24 2021 at 20:51):
complete-questionnaire is fine; I was responding to the example of "Tasks for Patient X" and "patient-inputs"
Eric Haas (Jun 24 2021 at 21:07):
those valueset are unbound, I just threw this example together to give an example how to use task. I was not even aware there was an SDC Task profile
milton mitjans (Jun 25 2021 at 16:31):
If an Observation was generated by the result of a QuestionnaireResponse; could we include the observation data within the task response?
The Use Case is like this:
The user answers the questionnaire
The user gets a Recommendation that is mapped to an observation
When user logs into a Web Portal the UI Client calls the Task Endpoint. The Task would contain the completed questionnaire and Possibly the Observation Data. This way the UI Client doesn't need to call 2 endpoints to show the "Recommendation".
Maybe an $expand or $populate operation?
Lloyd McKenzie (Jun 25 2021 at 22:30):
It sort of depends on the scope of the Task. If the creation of the Observations was part of the scope of the Task, then yes I'd expect them to be listed as Outputs. Key question to ask yourself is "when in the process would the Task be marked as 'complete'?" - generally you wouldn't add outputs after that.
Last updated: Apr 12 2022 at 19:14 UTC
