Stream: workflow
Topic: Who can update inputs and outputs on Task?
Virginia Lorenzi (Jan 24 2021 at 03:51):
Can the fulfiller of a Task update/overwrite inputs? Can the requester of a task update/overwrite outputs? who gets to add notes - requester or fulfiller?
History seems especially important - should the fulfiller be required to keep history and implement history searches?
Lloyd McKenzie (Jan 24 2021 at 03:55):
Who can update a resource and what they're allowed to change is driven by business rules and not dictated by the FHIR spec. In general, inputs are the responsibility of the requester and outputs are the responsibility of the filler. Status could theoretically be updated by either, though there may be rules about what changes are allowed when. Notes might be added by either - and possibly even by other parties. Whether history matters depends on the use-case.
Virginia Lorenzi (Jan 24 2021 at 04:37):
If you are not careful one side could wipe out the other sides's notes.
Lloyd McKenzie (Jan 24 2021 at 20:39):
Not without doing it deliberately. In FHIR, you can enforce that people can't perform an update unless they've queried the most recent version of the record - meaning they know exactly what they're adding, changing and deleting.
Virginia Lorenzi (Jan 25 2021 at 00:04):
Ah and they then have the latest version ID by doing that and can use the update lock?
Lloyd McKenzie (Jan 25 2021 at 03:18):
It's not really a 'lock' - you're not grabbing a lock and holding it, you're just tracking what version you saw and making sure that nothing's changed since then when you're modifying the record. If anything has changed, then you need to grab the most recent and try again.
Virginia Lorenzi (Jan 25 2021 at 07:47):
So I am the client and I want to update task. I query and get the latest version and then start updating it. But meanwhile, on the server, the Task is being updated a different way. Then I go to post it. Didn't I need a way to tell the server don't touch it right now I am working on it?
René Spronk (Jan 25 2021 at 08:14):
No, in principle it's up to you as the client to detect if the Task has been updated in the mean time (using E-Tag or _lastUpdated) before PUTing your update. In general the server can't know that you're about to update something when it receives a GET, nor can it know that sometimes you purposefully may wish to override data created/updated by someone else.
Lloyd McKenzie (Jan 25 2021 at 15:55):
No ability to say "don't touch". If someone else touches it before you get your changes in, then you need to merge their changes into your version. In some cases, your software may be able to do that behind the scenes (if it's smart). In other cases, your software will tell you that the record has been changed and seek your guidance on integrating or make you start from scratch.
Lloyd McKenzie (Jan 25 2021 at 15:56):
In practice, that's only going to cause problems very rarely. Allowing locking would cause much more problems. (Because someone locks and then goes on vacation... :>)
Virginia Lorenzi (Jan 26 2021 at 05:21):
Client posts Task to server - V1
Server updates Task - V2
Client queries and gets latest Task - V2
Client and Server both modify their version of the Task - V3
Client sends update to Server and Server detects Version collision?
Lloyd McKenzie (Jan 26 2021 at 14:53):
There's only one 'persisted' copy of the Task. So when the client updates its copy in memory, it doesn't have a 'version' yet. It gets a version assigned once the client transmits the PUT to the server and the server responds. So if the server has already stored a V3 and the client submits an update saying that it was based on V2, the server will reject the update.
Last updated: Apr 12 2022 at 19:14 UTC
