Stream: Care Plan/Care Coordination
Topic: CarePlan and $apply operation
Katri Karhinoja (Jun 15 2020 at 06:05):
Hello,
I'm working with a care plan for people with diabetes and I'm quite new to FHIR . I'm wondering how to use the $apply operation to apply the plan definition to a specific patient and have a care plan as a result? Is there any material that I could watch or read to help me to understand how this works?
Bryn Rhodes (Jun 16 2020 at 03:59):
Hi @Katri Karhinoja , there is a walkthrough of the behavior in the PlanDefinition resource documentation here
Katri Karhinoja (Jun 16 2020 at 05:31):
Thank you! Do you know if I could test the operation somewhere?
Bryn Rhodes (Jun 16 2020 at 17:58):
There is an Anemia testing recommendation here: http://build.fhir.org/ig/who-int/anc-cds/branches/RecB2_4/anc-recommendation-b1-1.html
Bryn Rhodes (Jun 16 2020 at 17:58):
It's deployable to http://cds-sandbox.alphora.com/cqf-ruler-r4/fhir
Bryn Rhodes (Jun 16 2020 at 17:58):
It's not there now, but if you give us a bit we can get it loaded there
Bryn Rhodes (Jun 16 2020 at 17:59):
You should also be able to load it in the latest Logica sandboxes
Bryn Rhodes (Jun 16 2020 at 18:01):
There's a quick start here that shows how to load the content into a FHIR server
Rob Dingwell (Aug 26 2020 at 10:58):
How do you deal with actions that are dependent on the outcome of another action? For instance, let's say I have a PlanDefinition that is dealing with some condition and outlines a series of tests or procedures to be performed to make a determination of what line of therapy to prescribe the patient. In this case I can a series of actions that outline the tests/procedures required to make the determination, but when it comes to dealing with outcome of those tests the current process defined in PlanDefinition for the $apply operation is lacking.
As the process is currently described for $apply all of the information for whether or not an action is applicable is seemingly supposed to be known at the time the operation is being preformed. In the case outlined above, the applicability for the action would not be known until after the tests were performed so under the current definition of $apply those subsequent actions would not apply because the data required for them is currently unknown.
I can see dealing with this by stating that if an action is dependent on other related actions it may apply to the process and be carried over into the resulting CarePlan/RequestGroup. That way the applicability could be evaluated after the tests. This still leaves a gap when dealing with actions that are depending on the outcome of other actions if the action.definition[x] is a PlanDefinition.
According to the $apply process if the action you are evaluating has a definition[x] that is a PlanDefinition you are supposed to run the $apply operation on that PlanDefinition and add the result to the RequestGroup. If you simply run this operation on the embedded PlanDefinition this will more than likely result in an CarePlan/RequestGroup that contains no actions because the data required by the embedded PlanDefinition is not known at that time.
Going back to the example, I can see a PlanDefinition that contains a PlanDef for the series of tests and 1 or more PlanDefs that outline the line(s) of therapy for the patient based on the outcome of the tests. But how do you evaluate the lines of therapy actions when you don't have the required information in advance to apply the subsequent PlanDefinitions.
Bryn Rhodes (Aug 26 2020 at 15:37):
@Rob Dingwell , the actions have "input" and "output" elements that can be used to specify data flow between actions, but the behavior to create the actions conditionally in the CarePlan/RequestGroup is not specified. You could use the absence of data as the trigger to know to create the action conditionally, but that wouldn't be necessarily true in all cases. Seems like you would need a way to say that the applicability of the action could not be determined until the expected data is available, like an indicator on the input data element.
Rob Dingwell (Aug 27 2020 at 13:04):
What would actually be nice is a way in a CareP{lan/RequestGroup to say evaluate this other PlanDefinition once you reach a certain point. So an action within the RequestGroup would be to evaluate a PlanDefinition.
Another thought would be to provide an alternative means to generate a RequestGroup from a PlanDefinition for such cases that did not take the applicability of actions into account. This would for the most part copy all of the PlanDefinition actions into a RequestGroup. RequestGroup already contains the ability to determine what actions to take based on the same sort of applicability condition so why not allow for that to be the means to filter out what actions to take?
Yet another thought would be to allow action.definition[x] to be a RequestGroup as well. Archives the same notion as generating a RequestGroup from a PlanDefinition without the need to go through the $apply operation.
Bryn Rhodes (Sep 09 2020 at 23:35):
Apologies for the delay here, went on vacation and just getting caught up. What about a parameter to the $apply for whether to assess applicability as part of realizing a PlanDefinition? And the idea of referencing a PlanDefinition from a RequestGroup would work well, but the other direction, we wouldn't be able to do, since a RequestGroup is a subject-specific resource, there'd be no subject to point to (that's really the only difference between the resources). If you want to submit trackers for these, happy to try them out
Rob Dingwell (Sep 10 2020 at 21:02):
No worries, if I was smart I would go on vacation at some point.
As far as adding trackers, do you mean in Jira on the ig? I can certainly do that. Would you like a single tracker that explains the issue trying to be resolved or multiple trackers for each example.
Bryn Rhodes (Sep 11 2020 at 15:51):
Maybe start with a single tracker to support the discussion
Rob Dingwell (Sep 16 2020 at 20:18):
@Bryn Rhodes Looking at https://jira.hl7.org/browse/FHIR-25056 I see that the resolution for that was agreed that RequestGroup would be added as result for the $apply operation. Is there a plan to add it into the spec at some point? I don't see it in R4 or R5 at this time.
Bryn Rhodes (Sep 16 2020 at 23:30):
Yes, that's on the backlog to apply, just haven't gotten there yet
Last updated: Apr 12 2022 at 19:14 UTC
