Stream: workflow
Topic: Multiple Task.inputs and an update
Virginia Lorenzi (Jan 24 2021 at 03:37):
Task allows for multiple inputs and multiple outputs. You can have multiple inputs of the same type or different types and multiple outputs of the same type or different types. This is fine as long as you never update the task to change the inputs or the outputs.
Imagine I Create a Task with Inputs A, B, and C. Then later I Update the Task and change the Inputs to C, D, and E.
Should the receiver of the task interpret this to mean that A and B are no longer valid and should be deleted (full "snapsshot" replace)? or should it assume A and B are still valid and update C and add D and E? @Lloyd McKenzie @Vassil Peytchev @Natasha Kreisle @Debi Willis
Lloyd McKenzie (Jan 24 2021 at 03:53):
Changing inputs would be uncommon. A Task.input is "information needed to allow execution of the Task". Removing inputs would be saying "this information wasn't actually needed/was erroneous". Adding new ones would be saying "This additional information is also needed in order to execute the Task". It's certainly possible in some cases - e.g. someone submits a Task asking for fulfillment of a referral and provides some supporting information needed to evaluate the request and the respondent points out that one of the records attached belongs to the wrong patient and also indicates they need a few more pieces of information. Once the inputs were corrected, the respondent could then adjust the status to reflect acceptance or in-progress. It would be very unusual to change the Task.inputs once the Task was underway.
Outputs could also be changed, either in event of error or to replace an early result with a final one. But outputs shouldn't be changed after the Task is marked as 'complete'.
Vassil Peytchev (Jan 24 2021 at 04:19):
Also, please note that a Profile on Task can introduce requirements on whether and how inputs may be changed. It is also up to the server to decide whether a task created with inputs A,B,C, and then updated with inputs C,D,E will result in the task only having inputs C,D,E, or inputs A,B,C,D,E, or only A, and E - just because that is what the server can support (see http://build.fhir.org/updates.html). Ant there is also PATCH
I think that in an Implementation Guide, the Profile of Task should clarify issues like this.
Virginia Lorenzi (Jan 24 2021 at 04:37):
Imagine I am baking. As the process progresses I add new ingredients. Knowing which one I put in first and when might be useful - each could be an input. Order might matter. In the patient request for corrections use case "adding" who to notify after the request has been accepted might be appropriate.
Lloyd McKenzie (Jan 24 2021 at 20:38):
There are lots of "mights". I have trouble imagining more than one or two inputs to a correction Task, I can't think of why inputs would need to be added late in the game and I can't fathom why order would matter. In short: lets not add theoretical complexity, let's focus on our explicit requirements. (Email messages from patients or providers would not be 'inputs'...)
Last updated: Apr 12 2022 at 19:14 UTC
