Stream: implementers
Topic: fhir Task - focus vs. input
Astrid Corinna Wolff (Nov 20 2018 at 08:42):
I’m not sure when to use the focus and when to use the input element for several task use cases:
1) Task to fill-out/complete a questionnaire
- Should the reference to the QuestionnaireResponse be included into the focus element (= the resource being manipulated by this task)?
- Or should the reference to the QuestionnaireResponse be included as input element (= information that may or must be present in order for a task to complete)
2) Task to read a certain document
- For whatever is the correct answer for UC 1 (QuestionnaireResponse): If the task is about reading a referenced document should it be treated the same way?
- Or will the fact that the QuestionnaireResponse is in fact manipulated while the Document is just displayed and read by the user require a different task modelling?
Lloyd McKenzie (Nov 20 2018 at 15:52):
1. Typically you wouldn't have a QuestionnaireResponse yet. If the task was to update/revise an existing response, then it would be appropriate to have it as the focus. If you're wanting someone to create a new QuestionnaireResponse based on a specified Questionnaire, then no input or focus. Specify the Questionnaire as the "instantiates".
2. If you want to say "please read X", the X would be the focus.
Yunwei Wang (Nov 20 2018 at 16:00):
How about "create a report based on X"? Is X the input for this task?
Astrid Corinna Wolff (Nov 20 2018 at 16:14):
Ad 1.
If I want someone to create a new QuestionnaireResponse based on a specific Questionnaire and I want to allow them to save it as draft (and continue completing it later) would then the original Task have a reference to the Questionnaire and later (after the QuestionnaireResponse has been created) the Task would be updated with the QuestionnaireResponse as the focus?
And which element (in R3 and R4) holds the "instantiates" in this case? I only found basedOn with a reference to any resource but this does not seem to be the right place, does it?
Lloyd McKenzie (Nov 20 2018 at 18:22):
@Yunwei Wang Yes, that would be a use for input. And if you were asking someone to fill out a QuestionnaireResponse based on certain other information, that "other information" would be an input.
@Astrid Corinna Wolff Probably not. The QuestionnaireResponse would be listed as a Task.output and the Task status would indicate "in progress". The instantiates would be instantiatesCanonical in R4. It would be definitionReference in R3.
Astrid Corinna Wolff (Nov 21 2018 at 07:19):
I saw definitionReference and instantiatesCanonical but both have only ActivityDefinition listed as type. Is it allowed to also reference a Questionnaire within these two elements? Or do I need to create an ActivityDefinition that contains a reference to the Questionnaire (and if yes, where)?
In the use case I imagine there is no implemented workflow or protocol. A professional just wants to assign a patient the task to fill out a selected Questionnaire within a defined timeframe.
Lloyd McKenzie (Nov 21 2018 at 17:58):
Good point. That's a problem actually. And I'm concerned we may be too late to fix it in R4. @Grahame Grieve - is adding additional permitted types in a canonical reference going to break things at this stage?
Grahame Grieve (Nov 22 2018 at 04:18):
I think that would be procedurally ok
Lloyd McKenzie (Nov 22 2018 at 05:17):
@Eric Haas - is this something OO could approve next week?
Lloyd McKenzie (Nov 22 2018 at 05:20):
Astrid Corinna Wolff (Nov 22 2018 at 07:33):
That would be great!
So, in R4:
- if the Task includes a Questionnaire to be answered, then I would put it into instantiatesCanonical
- if the Task includes an existing QuestionnaireResponse (created by someone else) that needs to be included, then I would put it into focus
- if the Task has been completed, then the resulting QuestionnaireResponse (with status = completed) should be put into output of the Task
-
if the Task includes something I need to answer the Questionnaire, e.g. a Document, an Observation or some other resource, then I would put these into input
-
if the Task includes a Document that should be read, then I would put it into focus
Are my assumptions above correct?
In R3: Where should I put the Questionnaire to be answered since definitionReference only allows ActivityDefinition? We considered creating an empty QuestionnaireResponse when the Task is created and put it into focus. Would this be a suitable workaround or do you have any better idea?
Lloyd McKenzie (Nov 22 2018 at 15:38):
It matters what kind of task it is. A QuestionnaireResponse that's to be updated would be a "focus" of a Task asking for a QuestionnaireResponse to be updated. However, it could be an "input" for a Task saying "please generate a CarePlan based on the responses to one or more Questionnaires". The Task.focus is what the Task.code is asking to be manipulated or fulfilled. The inputs provide information needed to perform the task and the Task.output provide what resulted from the task.
Astrid Corinna Wolff (Nov 22 2018 at 15:51):
I think I got it. Thank you very much for your explanations!
I just imagine one more (a bit more complicated) use case:
How would I create a Task for a physician to notice a report and a some other documents that are needed to correctly understand a certain DICOM image?
Since focus could include only the reference to one of the Documents that should be read would I need to create several sub-tasks (one for each Document)? And would the DICOM image be the input (-> please read the documents that are relevant for understanding this DICOM image)?
Lloyd McKenzie (Nov 22 2018 at 16:02):
It depends how you want to phrase it. One possibility would be "Review this DICOM image" with a focus of the image and the reports as input to support the review. Another could be "Review reports" with subtasks for each report to review and the association to the DICOM image would be through the reports.
Astrid Corinna Wolff (Nov 22 2018 at 16:07):
I think for my use case I like "Review this DICOM image" best. We were looking for something to make sure that the reports are not overseen when reviewing the image and such a kind of Task could be used to display the image to the user with additional reports (to support the review, as you said) by the side.
Alexander Henket (Feb 20 2019 at 13:22):
@Lloyd McKenzie Reviewing this discussion, I'm still unsure on what to do.
Task: "Questionnaire should be retrieved by performer [patient]" Task is completed when Questionnaire has been retrieved. No assumption of Questionnaire completion is to be inferred from this Task.
Where we've landed:
Task.status "ready"
Task.intent "order"
Task.code "Please retrieve Questionnaire"
Task.focus "The Questionnaire"
Task.performerType "performer"
Task.owner "The patient"
Task.restriction.period.end "Before next week"
Although you are welcome to shoot at anything, the main question is "Given the Task definition, where does the Questionnaire go". I feel uncomfortable with Task.definition (this is STU3) as the Questionnaire is not the definition of the task, it is the object to retrieve.
Patrick Werner (Feb 20 2019 at 15:08):
@Astrid Corinna Wolff
great question. Was about to ask the same, and found this thread. We (MOLIT Institut) will also put the Questionnaire in instantiatesCanonical as soon this will be possible.
Lloyd McKenzie (Feb 20 2019 at 16:06):
@Alexander Henket - are you wanting the Questionnaire to be retrieved or a QuestionnaireResponse? If the former, then Task.focus is fine.
Alexander Henket (Feb 20 2019 at 16:13):
Just retrieval of the Questionnaire. Workflow around QuestionnaireResponse has been declared out-of-scope. Presumably when that comes into scope, then the current task about Questionnaire retrieval could be a subtask.
Thanks for the confirmation ( :thumbs_up: )
Alexander Henket (Feb 20 2019 at 16:21):
One more followup: where would you convey the Patient who's supposed to retrieve this Questionnaire? Both Task.for and Task.owner seem reasonable. Or could it be both for different reasons? The patient could be the (ultimate) beneficiary while he's the currently responsible owner of the Task at the same time?
Lloyd McKenzie (Feb 20 2019 at 16:33):
Task.owner is who is to do the action. Task.for is the beneficiary. Could be the same or different
Alexander Henket (Feb 20 2019 at 16:34):
So at minimum patient is owner, since he's supposed to retrieve the Q. Whether or not he benefits, may not even be relevant in this case.
Lloyd McKenzie (Feb 20 2019 at 16:40):
Task.for is importent for security/access control. It determines what patient record the request is tied to, so it should generally always be declared.
Last updated: Apr 12 2022 at 19:14 UTC
