Stream: implementers
Topic: RequestGroup.action status
Travis Stenerson (Aug 21 2017 at 15:59):
I'm submitting a tracker that I'd like opinions on. We have a use case for RequestGroup.action.status, and currently actions don't have a status. I realize there is some amount of redundancy with this (as the referenced action.resource request has a status), but I think it has a valid use case, and there is already some redundancy with the timing and code fields. If there is any previous discussion on RG.action status, I would appreciate if someone could point me to it, but I was unable to find any here.
As a CDS service we care about the status of a group of actions within the RequestGroup. Specifically for this use case, we care about the neoadjuvant portion of a chemotherapy regimen, the portion of a regimen that is done prior to surgery. I am intending to extend RG.action to add a field that will designate its child actions as pre-operative or neoadjuvant. To determine this section's status, a system would have to dig into the tree and determine the status of each request and write rules to add them together. If the action itself had a status, this would be much simpler. This status would also make it simpler to determine the number of cycles a patient has completed.
We considered embedding a referenced RequestGroup into the action.resource, but this adds another layer of complexity, and another FHIR resource that would have to be create on a server, and kind of fragments what could otherwise be considered a single regimen.
Thanks
Tracker #13758
Lloyd McKenzie (Aug 21 2017 at 20:46):
We don't track execution status in any of the Request resources. That's left to the Task resource. The reason being is that a given request may have multiple fulfillers each having different statuses. For example, you might ask one organization to do something and they refuse, then you ask someone else and they start and cancel, then you ask someone else and they're part-way through. From the Request perspective, the status has remained "active" throughout. Each of the separate "request fulfillment" tasks would reflect the states with each of the fulfillers. As well, requests may have digital signatures on them, making it problematic to update them as fulfillment proceeds. If you don't want to have to query all of the components, you might also look at defining an Operation.
Travis Stenerson (Aug 21 2017 at 23:16):
Ok I have to take a step back and ask a more basic question. Does this mean that a single request's progress and status lifecycle is tracked through a Task? Like a medication request. When the final administration is complete, is the MedicationRequest's status set to complete?
Lloyd McKenzie (Aug 21 2017 at 23:34):
The Request status reflects the status of the authorization. So once the author of the request deems it to be completed (and thus no longer executable), they can mark the Request as "completed". However, the nuances of how the execution of the request is progressing is managed by Task, not by the request. In some cases you might have multiple steps that need to be completed before the Request is deemed complete - so for example the dispensing Task might be complete, but the MedicationRequest wouldn't be marked as "complete" until the prescriber believes that administration of the medication is also complete.
Jose Costa Teixeira (Aug 22 2017 at 06:17):
Hi @Travis Stenerson
"Does this mean that a single request's progress and status lifecycle is tracked through a Task? "
Yes. When you say "a request's progress" you are implicitly saying "the progress of the actions triggered by the request", right? That is the workflow or series of events which is managed by the task.
Travis Stenerson (Aug 22 2017 at 13:39):
@Jose Costa Teixeira
Yes that's what I mean. The script writing, the pharm checking, the nurse administering, etc. I don't remember physicians ever verifying that all the medication was given for all the prescriptions they authored..
What is the proper way to group and track a set of related medication requests over their lifecycle? A task for every request?
Jose Costa Teixeira (Aug 22 2017 at 13:41):
they are grouped so I think you can have one task for the group itself, no?
Travis Stenerson (Aug 22 2017 at 13:44):
Focus has a max cardinality of 1 on a task. Is there a task group? These resources will be stuck in a request group, but this request group contains many more medication requests than those I need to track.
Travis Stenerson (Aug 22 2017 at 13:50):
And if they were grouped nicely, I would simply look at the status of the overall RequestGroup, since I only care about whether or not all the cytotoxic/neoadjuvant medications have been given. The problem is they won't be grouped very nicely except for all being down the same branch in the PlanDef/ReqGroup action tree.
Jose Costa Teixeira (Aug 22 2017 at 13:52):
task can be part of a task.
Jose Costa Teixeira (Aug 22 2017 at 13:57):
so, requestGroup is the protocol, right?
i am looking at it now, sorry. i am a bit confused if RequestGroup is just the "grouping" part or actually contains the several requests.
Jose Costa Teixeira (Aug 22 2017 at 13:59):
say you have a chemotherapy protocol. would you use one requestGroup and several medicationRequests "hanging"/derived from it, or the requestGroup is supposed to hold all the requests?
Jose Costa Teixeira (Aug 22 2017 at 14:00):
Also not clear if requestGroup is the protocol definition, or the instantiated protocol
Travis Stenerson (Aug 22 2017 at 14:03):
The regimens would be distributed as a PlanDefinition (per chemo-ig group) which are instantiated into RequestGroups containing a pile of medication requests with all the relationships between them. These groupings contain subgroupings containing sections. I want to track one specific section of that group. Here's an example:
Lloyd McKenzie (Aug 22 2017 at 14:04):
Clinicians may not verify that all medication was given, but automated systems may track that in an in-patient setting or infer it based on time in outpatient settings. If you've got RequestGroups that organize a bunch of MedicationRequests, you'd have a Tasks for each MedicationRequest that you could track.
Travis Stenerson (Aug 22 2017 at 14:04):
AC followed by T followed by H.
A & C every 21 days x 4. Then
T every week x 12. Then
H every week for 36 weeks.
I need to know when all of A, C and T are complete.
Lloyd McKenzie (Aug 22 2017 at 14:07):
The safest way to do that is to define a Task for A + C + T (possibly with subtasks for each). There's nothing that stops you from throwing an extension on the RequestGroup, but that's not going to work well in an environment that uses digital signatures.
Jose Costa Teixeira (Aug 22 2017 at 14:07):
when instantiating (creating the requestGroup and the requests) you can create one task for those that you want to track.
So you can have one task for each of AC, T, H, A, C,
And/Or you can have one task for A, C and T
Jose Costa Teixeira (Aug 22 2017 at 14:07):
Lloyd just wrote this on the "no topic": The safest way to do that is to define a Task for A + C + T (possibly with subtasks for each). There's nothing that stops you from throwing an extension on the RequestGroup, but that's not going to work well in an environment that uses digital signatures.
Lloyd McKenzie (Aug 22 2017 at 14:08):
Sorry. Fixed the topic heading.
Jose Costa Teixeira (Aug 22 2017 at 14:09):
so, one task for each-thing-you-want-to-track-separately
Travis Stenerson (Aug 22 2017 at 14:09):
If A and C are actually represented by 16 medication requests (because there are complex interrelationships between them and other supplemental drugs) how can I task represent them all? Task.focus can only reference a single medication request
Lloyd McKenzie (Aug 22 2017 at 14:09):
Tasks can be created at whateve granularity is useful for the workflow being exercised.
Lloyd McKenzie (Aug 22 2017 at 14:10):
We could look at increasing the cardinality of Task.focus, though I think in this case you'd probably have the focus be the RequestGroup and have the Task.code indicate that it's focused on "A, C and T"
Jose Costa Teixeira (Aug 22 2017 at 14:10):
i actually don't know how to handle "one task for 3 requests" if task.focus is 0..1.
Lloyd?
Travis Stenerson (Aug 22 2017 at 14:11):
If RequestGroup itself has a status, and all the requests have a status, shouldn't groupings within the group also have a status?
Jose Costa Teixeira (Aug 22 2017 at 14:11):
hmm that assumes that there is a code for "A, C and T", no?
Lloyd McKenzie (Aug 22 2017 at 14:11):
In this case there's a grouping Request that would make sense as the focus. So far, no one has provided a use-case for one Task with multiple requests where they wouldn't also have sub-tasks specific to each request.
Lloyd McKenzie (Aug 22 2017 at 14:13):
You can define a code for anything that's needed
Travis Stenerson (Aug 22 2017 at 14:15):
There are codes for combinations, codes that I will likely use to denote the branch of the RequestGroup(in action.code), one for AC, one for T. But reducing them all to tasks when all I care about is if the full life cycle of the request is completed seems like it wouldn't give much advantage over just looking at a request's status
Lloyd McKenzie (Aug 22 2017 at 14:15):
Status on a request reflects the status of the "authorization". So tracking status at the RequestGroup.action level only makes sense if there's deemed to be a distinct "authorization". (And in general, if that were the case, you'd break those out as separate resource instances.)
Lloyd McKenzie (Aug 22 2017 at 14:16):
Have you considered having a separate RequestGroup for the A+C+T bit?
Lloyd McKenzie (Aug 22 2017 at 14:16):
RequestGroups can point to other RequestGroups
Travis Stenerson (Aug 22 2017 at 14:18):
Yes, that was my first inclinication Lloyd. I was worried about making it too complicated and exactly how many RequestGroups I would need to break it down into, though really I only need the one subgrouping (to know when a patient will go to surgery). As well, I was afraid that the plan definition would not map nicely to nested request groups.
Lloyd McKenzie (Aug 22 2017 at 14:23):
Understand the concern about complexity. There's certainly a variety of ways to approach the problem. One thing to look at is "how do systems manage it now?" Do they create one structure for the execution or many (and how many)? From a design perspective, FHIR tries to separate "tracking the authorization" and "tracking the execution". And it tries to set the granularity of the authorization objects to "what can be independently manipulated". Adhering to those conventions in your solution will generally give you more interoperablity and less grief, but FHIR doesn't force adherence to those principles so there's technically nothing stopping you from just adding an extension.
Travis Stenerson (Aug 22 2017 at 14:27):
Yes I was afraid of an extension because it would require constant attention to maintain exactly what section of the request tree is completed. I think a nested group would probably be my best option at this point. Definitely more data on how it's done now would help. Sadly that isn't always easy to get a hold of.
Sadiq Saleh (Aug 22 2017 at 15:55):
Just to add to this discussion, addition of action.status would also make sense for the use of the relatedAction. Currently the only way to know if the status of an action should trigger a relatedAction is to recurse through action and all its children to the leaf level requests and determine their statuses.
I appreciate the solution to nest additional RequestGroups, but then what would be the reason for having a hierarchy of actions? Is this not just duplicating the way of organizing a RequestGroup?
Sadiq Saleh (Aug 22 2017 at 15:57):
Status on a request reflects the status of the "authorization".
Could you point me to where I can read more about this, as I was not able to find this link as I looked through the FHIR pages.
Jose Costa Teixeira (Aug 22 2017 at 16:24):
http://build.fhir.org/request.html#12.3.2:
The status of a request only reflects the status of the "authorization/intention"
Jose Costa Teixeira (Aug 22 2017 at 16:27):
Keep in mind that whatever you do on the request may or may not happen in the actions/events side.
One simple example (can't think of a more complicated at the moment): Prescription is for 60 units, patient goes to pharmacy and gets a box of 30. So, the system is expecting one dispense. What is the status of the actions? If you would just take the information from the request, it'd be complete. But it may be complete or not, depends on a lot of things.
Sadiq Saleh (Aug 22 2017 at 16:52):
Please correct me if I am wrong, but what this would mean is that the request's status is related to the Requester's intent or authorization, and the intent is tied to the outcome of the treatment rather than the treatment itself.
I apologize in advance for the following simplistic example: The intent is to bring a patient's temperature down so I prescribe them 30 pills of Aspirin. If they only take 10 and their temperature is reduced, would I set the status of my request to Complete?
Jose Costa Teixeira (Aug 22 2017 at 16:54):
It means that the status of the treatment or actions (not "the status of the request", we've discussed that) depends on the treatment itself but may end up influenced by other things that happen in real time.
Jose Costa Teixeira (Aug 22 2017 at 16:58):
The case you are showing is definitely possible: The physician says "treatment is for 30 tablets". But if the patient gets better after 10, then the physician can simply say :nevermind, this treatment is done so i can consider the request "stopped".
In a hospital setting, this implies that the nurse does not give aspirin the next days. If the system was calculated based only on the planned actions, the patient would still get the aspirins.
Jose Costa Teixeira (Aug 22 2017 at 16:59):
there is a difference, however, between the physician saying "the treatment is done so I mark the request as "stopped", because I say so", and some magic calculation to determine that the treatment is completed because the temperature is lowered.
Jose Costa Teixeira (Aug 22 2017 at 17:00):
Big difference: The status of the request is determined by the requester. The status of the treatment may be influenced by many things and change as the treatment evolves
Jose Costa Teixeira (Aug 22 2017 at 17:02):
so, to your question " would I set the status of my request to Complete?" No, the physician can set the status of the Request to "stopped". If there is some logic to determine that "if temperature is lower , then stop treatment", this is on the treatment status (task), not on the request.
Lloyd McKenzie (Aug 22 2017 at 17:03):
"completed" means that the request was satisfied as originally requested. If the original request was for 30 and the patient got better after 10, typically the prescriber would change the status to "stopped". I.e. The authorization has now been revoked and no further dispenses are permitted.
Jose Costa Teixeira (Aug 22 2017 at 17:03):
Sorry, forgot "stopped". Updated my response now it should be correct.
Lloyd McKenzie (Aug 22 2017 at 17:06):
The key thing is that any status on a request doesn't reflect "what was done", merely whether anything is authorized to be done. An action might have been complete for days or even weeks before the request is updated to "complete" - and there's no guarantee it will be. If you want to track the status of what's actually been done, you're going to want Task rather than the Request resource. The question with Task is at what granularity(ies) do you want to track execution.
Last updated: Apr 12 2022 at 19:14 UTC
