Stream: implementers
Topic: Status of Requests referenced by a RequestGroups
Kyle Thompson (Jan 07 2022 at 17:44):
I have read multiple times throughout the documentation that the status of a RequestGroup must "cascade" to any Request resource that is referenced by it (e.g. http://hl7.org/fhir/2020Sep/request.html#requestgroup). It makes sense that if a RequestGroup is cancelled or suspended that all referenced Requests must be cancelled or suspended as well. It also makes senses sense that if a RequestGroup is completed this means all the referenced Requests are also completed.
Does it work the other way? Can a referenced Request, for example, be completed, suspended, etc.. whilst the RequestGroup remains active or does completing one of these option Requests necessarily mean that the parent RequestGroup was completed?
Lloyd McKenzie (Jan 07 2022 at 18:08):
The expectation is that if you're using a RequestGroup, then there's really only "one" order. It's just a complicated one with a bunch of parts. In most cases, the children of the the RequestGroup should be contained - because they shouldn't ever be modified without understanding the impact on the whole. We haven't really talked about the possibility of the statuses of requests within a RequestGroup not all transitioning together. In theory it's possible that one part of the overall order might be complete when the whole thing isn't yet complete. But, in general, most transitions can't happen without affecting everything. If you put anything on hold, you have to put everything on hold. If one thing is cancelled, then the whole thing must be cancelled.
Kyle Thompson (Jan 07 2022 at 18:23):
The example I'm thinking of (I should have included it in the original question, my mistake) is the following:
1) Do A
2) After A, do B
3) After B, do C,
where A, B, and C are all Tasks. The RequestGroup would capture this ordering (and if need be any more complicated timing offsets between the Tasks. For this example, the RequestGroup is in an active state.
My thinking is that B and C exist in some received or accepted state while A is in an in-progress state (the owner is acting on it). Now, if Task A is completed (or maybe even failed, depending on the situation), we would want to move on to Task B. Task A being complete does not mean the whole RequestGroup is complete, just that one component.
It makes sense that the Tasks A, B, and C have a context (the RequestGroup) and that operations on the RequestGroup would cascade down to the referenced Tasks. When timing/ordering is involved between the Tasks, though, I was thinking that the referenced Tasks might transition on its own, but based on what I've been reading this might be unorthodox?
Lloyd McKenzie (Jan 07 2022 at 20:05):
My general leaning is that, if in a RequestGroup, there should be no use of Accepted/Received for the Tasks. They're behaving purely as 'orders' in that circumstance. Any acceptance/refusal should be of a separate Task seeking fulfillment of the RequestGroup as a whole.
Kyle Thompson (Jan 07 2022 at 20:17):
What status would be reasonable for Tasks that are waiting for some other Task to be completed? For concreteness, let's say Task A is currently be actioned (is in-progress). What status would Task B be in? Also in-progress?
Lloyd McKenzie (Jan 07 2022 at 20:32):
RequestGroup isn't really supposed to track "in progress". It tracks active and completed or cancelled. I'd recommend going the same route with Task (so requested, cancelled, failed, on-hold and completed) - mirroring the active/on-hold/revoked/completed of RequestGroup. Any tracking of acceptance or completion should be managed by other tasks or sub-tasks that aren't directly referenced from the RequestGroup. All of this said, there's obviously a need for more guidance in the spec about how all of this should work, so feel free to submit a change request asking for some...
Kyle Thompson (Jan 07 2022 at 21:00):
Just to be clear, this sounds like it is acceptable (and maybe even likely) that Request statuses referenced by RequestGroups can be different from the RequestGroup with the caveat that there are some restrictions on what the status of the referenced Tasks can take on (as discussed above). Is that right?
Yeah, I'll figure out the process asking for a change request and submit a ticket. Thanks for all your help!
Lloyd McKenzie (Jan 07 2022 at 21:13):
The language here is pretty clear. The status of the parent cascades to the children and the children aren't allowed to have 'distinct' statuses, though of course the specific status values may differ. (Task doesn't have 'active' but it does have 'requested', for example.) If you want to track the activity against specific parts, you'll need to use sub-tasks with a 'basedOn' relationship.
Last updated: Apr 12 2022 at 19:14 UTC
