Stream: workflow
Topic: Task shared ownership worries me
Virginia Lorenzi (Jan 24 2021 at 04:52):
In my experience, it is better to design a system such that at any point in time, it has one owner. But for a Task instance, that is not the case. The fulfiller could be working on a Task which the Requestor could be working at updating the request and there could be a lost update problem. With the concept of placer order and filler order, this was never a problem. Or with databases, having a lock on a record while you are updating it. The fulfiller could change all sort of things set by the requestor like the focus the for the description, the date/time fields (and it seems to me that date/time could be something both may have different perspectives on. And wipe out notes by the other or not even see them. Like on the requestor side I could add a note based on what I see in my copy of the Task while the fulfiller is adding a note based on their active copy on Task. Like I update a document locally, you update the same document locally and whoever uploads the update wins and neither of us is using complete information (lost update problem).
Lloyd McKenzie (Jan 24 2021 at 20:43):
- Task was specifically designed to allow updates by multiple parties. Typically, once initiated, the types of changes that would be performed by the placer would be limited (correcting inputs if they're found to be invalid, adding new inputs if requested, suspending or cancelling the Task if necessary). Business rules would establish what sorts of changes are allowed in what situation.
- There's an equivalent in FHIR to a database lock. And most systems will force it's use. So there's zero risk of someone accidentally overwriting a change made by someone else if you decide you want to prevent that. I had provided the relevant link before, but I'll post it again: https://build.fhir.org/http.html#concurrency. Update collisions are not something you need to worry about
Virginia Lorenzi (Jan 24 2021 at 23:58):
This is so interesting! By most systems will force its use, do you mean this is currently used in any implementations today? I am interested if anyone else out there using Task is dealing with the update situation and would like to get them involved in the situation. Can you help me tag others who might have some insight?
Virginia Lorenzi (Jan 25 2021 at 00:00):
Also, I agree that a careful design of update would probably solve the problem. Such as:
- requestor can only update fields owned by requester
- updates not possible if Task has reached a certain status
- use of replace concept. Cancel and new Task created with link to old task saying it replaces the old.
Lloyd McKenzie (Jan 25 2021 at 03:17):
There are two questions to be handled in the update:
- Requiring that concurrency rules are used for this use-case (which is relatively easy). I don't know that there's a whole lot of support for external updates coming into EHRs right now. (And I wouldn't be surprised if most support for it ends up being routed through our IG, as external systems changing data in EHRs is something I'd expect would typically need human review.)
- Deciding what the rules are on what can be updated by whom, which will likely also be driven by status. Note that these rules apply to must objects that are updatable. For example, updating a prescription to mark it as suspended is generally fine. On the other hand, updating the patient, prescriber or drug is typically frowned upon - though doing that when the status is 'draft' might be just fine.
Last updated: Apr 12 2022 at 19:14 UTC
