Stream: implementers
Topic: CarePlan - performed activities
Jose Costa Teixeira (Dec 23 2020 at 08:57):
I need to track the date a patient abandoned treatment, and the date the patient was transferred and initiated another careplan.
Jose Costa Teixeira (Dec 23 2020 at 08:59):
- Why does CarePlan only mention planned activities? I'd expect it to support unplanned / past activities
René Spronk (Dec 23 2020 at 09:09):
By definition it's about future (planned) activities. A planned activity may result in a resource which captures the 'event'. That can be assigned an aborted status. Referrals is a ServiceRequest, which has a date. A new CarePlan also has a date.
Jose Costa Teixeira (Dec 23 2020 at 09:33):
A CarePlan is not only for future, but also to follow up (at least, it was, until R4)
Jose Costa Teixeira (Dec 23 2020 at 09:34):
(this is why the CarePlan is somewhat similar to Taskl in terms of workflow).
If something unplanned is added to a patient's care activities, I'd expect the CarePlan to capture that.
Jose Costa Teixeira (Dec 23 2020 at 09:40):
in R5 I see a performedActivity where I can indeed put the other activities, but this feels strange and I think i will require several extensions.
Jose Costa Teixeira (Dec 23 2020 at 09:44):
- Do we still need CarePlan.activity.plannedActivityDetail.product? If the careplan is to give a medication, or a device, or a nutrition, we should have that covered by now. I don't think we need to repeat that. If I want to order a medication then I'd most likely need a MedRequest anyway, because I need to put dosage etc in there.
Jose Costa Teixeira (Dec 23 2020 at 09:46):
(I wouldn't have thought of these issues until I had to implement - it's now my 3rd projects where I see gaps in CarePlan and I want to help make this more mature. We need a good CarePlan)
Jose Costa Teixeira (Dec 23 2020 at 11:56):
(unless i'm missing something obvious)
Lloyd McKenzie (Dec 23 2020 at 14:51):
plannedActivityDetail is for when you don't want to break out details into a separate resource.
Lloyd McKenzie (Dec 23 2020 at 14:52):
@Michelle (Moseman) Miller for the question on unplanned activities
Gay Dolin (Dec 23 2020 at 16:29):
By "unplanned activities" do you mean "Interventions Performed"? Unplanned activities would not exist on a care plan except if it was contraindicated interventions, or goals to not do something. Performed Activities - The PerformedActivity you see in R5 is a more appropriately renamed "outcomeActivityObervation (I think - need to check JIRA ) can be supported. I recommend NOT using activity detail, as you will ultimately be creating the need of double documentation inside some Care Plan app or module. Bringing things into the Care Plan by reference providing a holistic view if Care Planning activities else where described is better. Otherwise it is an additional burden. However, it is quite opaque just how FHIR Care Plan CAN do everything a real Care Plan does. I will attach a diagram that should help you
Gay Dolin (Dec 23 2020 at 16:37):
ExampleInstanciatedFHIR_CarePlan_Goal.png
Gay Dolin (Dec 23 2020 at 16:39):
Let me know if you would like to chat. I am curious as to what you are working on. will you be participating in the Care Coordination track @ the upcoming FHIR Connectathon?
Gay Dolin (Dec 23 2020 at 16:40):
BTW - this conversation seem like it would be better in the Care Plan zulip stream: https://chat.fhir.org/#narrow/stream/220328-Care-Plan.2FCare.20Coordination
Jose Costa Teixeira (Dec 23 2020 at 19:26):
Gay Dolin said:
Unplanned activities would not exist on a care plan except if it was contraindicated interventions, or goals to not do something.
That is what is puzzling. CarePlan could be a request (just for planned activities and follow up), or a "mixed (request/event)" workflow resource that tracks the evolution. What it feels is that CarePlan is a mixed workflow resource but only for those tasks that were planned. Care Coordination is not only about planned stuff, I think.
Jose Costa Teixeira (Dec 23 2020 at 19:26):
ok I will follow up on the other stream
Michelle (Moseman) Miller (Jan 06 2021 at 18:16):
The PerformedActivity you see in R5 is a more appropriately renamed "outcomeActivityObervation (I think - need to check JIRA ) can be supported
It's just the opposite. R4's CarePlan.activity.outcomeCodeableConcept and outcomeReference was renamed/merged in R5 to CodeableReference CarePlan.activity.performedActivity as part of a broader change (J#26064) related to the clarification of the planned activities (requests) vs performed activities (events). Additionally, the rename also helps separate the evaluation of what activities were done vs actual outcomes. Per J#28546, we discussed:
- Evaluation - CarePlan.activity.performedActivity
- Actual Outcome - Goal.outcome
For example, the requested/planned activities might be diet and exercise. The evaluation of completed activities might be specific to caloric intake or minutes of exercise. The outcome (for a goal of losing weight) would be the patient's weight observation. It's possible to complete the activities, but not achieve the desired outcome (or vice versa).
CC: @Gay Dolin @Jose Costa Teixeira
Jose Costa Teixeira (Jan 06 2021 at 18:27):
Thanks for tracing this back, Michelle. I like the existence of performedActivity.
My point #1 is that while plannedActivityDetail has many details, performedActivity has none....
Jose Costa Teixeira (Jan 06 2021 at 18:28):
Point #2 is a discussion about removing plannedActivityDetail.product, and use a reference to any of the product requests (medication, device, nutrition).
Michelle (Moseman) Miller (Jan 06 2021 at 19:11):
My point #1 is that while plannedActivityDetail has many details, performedActivity has none....
There is an invariant that says you either have CarePlan.activity.plannedActivityReference (reference to a request resource) OR CarePlan.activity.plannedActivityDetail (inline activity definition). When using the reference to a request resource, it has full detail of the request. Likewise, when using the CarePlan.activity.performedActivity, it references an event resource with full detail about that event. What is missing or what don't you think you can convey with the CarePlan.activity.performedActivity reference?
Michelle (Moseman) Miller (Jan 06 2021 at 19:14):
Point #2 is a discussion about removing plannedActivityDetail.product, and use a reference to any of the product requests (medication, device, nutrition).
You don't have to use the inline plannedActivityDetail - instead, you can use CarePlan.activity.plannedActivityReference and reference the MedicationRequest, DeviceRequest, or NutritionOrder.
Jose Costa Teixeira (Jan 06 2021 at 19:27):
#1: Just looking at the resource: for performedActivity we don't have goal, reason, performer, possibly others
Jose Costa Teixeira (Jan 06 2021 at 19:29):
#2: I understand we have 2 ways of doing it, which actually summarizes my challenge: If i want to see what drugs is the patient planned to take, I need to look in 2 places. Is there a reason for that ambiguity?
Michelle (Moseman) Miller (Jan 06 2021 at 21:51):
Regarding #1, performedActivity is a reference to any resource....most will be events that follow the event pattern, which usually do support reason and performer. There is an extension http://build.fhir.org/extension-resource-pertainstogoal.html for relating goals to event resources.
Michelle (Moseman) Miller (Jan 06 2021 at 21:52):
Regarding #2, that is correct -- think of it like a choice of data types -- that happens many places throughout FHIR and isn't unique to CarePlan
Jose Costa Teixeira (Jan 06 2021 at 23:57):
on #2 I don't see it as a choice of data types. The meaning is rather different - it is an actionable item
Jose Costa Teixeira (Jan 07 2021 at 00:02):
I think (my opinion after yet another attempt at understanding and pointing out issues) that the CarePlan resource is unnecessarily ambiguous.
Jose Costa Teixeira (Jan 07 2021 at 00:04):
The planned activity has a lot of information, duplicating information that can be provided by other resources (ambiguity can harm interoperability). OTOH, the performed activity, given its position in the resource, seems a new stub for which not sufficient use cases hae been found - which is what I was trying to stimulate.
Jose Costa Teixeira (Jan 07 2021 at 00:06):
I tried to use CarePlan and provided feedback to make it simpler for a few cases:
- CarePlan representing a Medication Treatment item
- CarePlan representing a long-term care with new and unexpected activities
Jose Costa Teixeira (Jan 07 2021 at 00:08):
I could just make extensions, but I think that now is the time to provide feedback and I hope that is found somehow useful - even if it is corrective feedback.
Jose Costa Teixeira (Jan 07 2021 at 00:09):
Generally, I am of the opinion that we should have richer examples for how our resources work in broader scenarios and workflows - considering dynamic changes, evaluating overlap with other resources. The CarePlan resource really needs that IMO.
Michelle (Moseman) Miller (Jan 07 2021 at 20:47):
cpl-3 invariant does act like a choice of data types since you can have one or the other, but not both
Provide a plannedActivityReference or plannedActivityDetail, not both plannedActivityDetail.empty() or plannedActivityReference.empty()
Michelle (Moseman) Miller (Jan 07 2021 at 21:02):
Your initial comments for #2 seemed focused on the plannedActivity (choice of reference vs detail) vs your most recent comments might be switching topics to a discussion about plannedActivity* vs performedActivity?
I agree that planned activities are different from performed activities.... and yes, there is a choice of planned activities being references or inline detail.
Regardless, I don't think we have found any examples of attributes that are missing or not supported. What are the specific extensions you are needing?
I hear you saying that there is complexity with the choice of how to represent a planned activity (as a reference to another resource vs inline detail). If you want to log a change request to force all CarePlan implementers to use plannedActivityReference (thereby removing plannedActivityDetail), then feel free to log a change request and Patient Care can discuss further.
Jose Costa Teixeira (Jan 07 2021 at 21:37):
If this were a less complex resource, I could more easily indicate some changes or extensions.
Jose Costa Teixeira (Jan 07 2021 at 21:39):
#2 is about ordering a product. What are the requirements for having 2 ways of doing it?
Michelle (Moseman) Miller (Jan 07 2021 at 21:43):
Lloyd answered that above (and I agree):
plannedActivityDetail is for when you don't want to break out details into a separate resource.
Jose Costa Teixeira (Jan 07 2021 at 21:44):
perhaps i'm on a different topic. What is the reason to have plannedActivityDetail.product[x]?
Michelle (Moseman) Miller (Jan 07 2021 at 22:01):
To describe what is being requested or prescribed (the equivalent to request.code per https://www.hl7.org/fhir/careplan-mappings.html#workflow)
Jose Costa Teixeira (Jan 07 2021 at 22:02):
So, why 2 ways of doing that?
Why can I have a reference to a MedicationRequest OR a product code?
Jose Costa Teixeira (Jan 07 2021 at 22:03):
( and if I can have a product code, why not a service code, replacing a ServiceRequest? )
Lloyd McKenzie (Jan 08 2021 at 01:19):
There are two levels of complexities of systems. Simple planning systems want a data structure that describes (in some degree of discrete detail, but not a lot) every kind of thing they might want to do. Other planning systems allow you to bring to bear the full complexity of the interfaces for different types of interventions. The model is intended to support both. Even a system that supports complex details may allow for 'simple' things without invoking the complex interface. But you absolutely can't define an activity using both at once. That would be nearly impossible to render and build an interface for and would allow all sorts of confusing/contradictory statements.
Lloyd McKenzie (Jan 08 2021 at 01:20):
plannedActivityDetail.code would allow you to send a service code. But if you do that, then you can't have a ServiceRequest.
Jose Costa Teixeira (Jan 08 2021 at 06:53):
My point #2 is that product[x] is a good candidate for removal
Lloyd McKenzie (Jan 08 2021 at 06:55):
If you just want to say "I plan to prescribe drug x", then you need to capture that. You also need code, because you might want to say "I plan to stop drug X". So there's a need for an element to capture both the action and the product.
Jose Costa Teixeira (Jan 08 2021 at 06:57):
Is product[x] semantically any different from medicationRequest?
Jose Costa Teixeira (Jan 08 2021 at 06:57):
(or DeviceRequest?)
Jose Costa Teixeira (Jan 08 2021 at 07:00):
My point #1 is that this resource could use some cleanup and a good amount of documentation. we could make planned activity and performed activity a bit more consistent in terms of structure and level of detail.
Lloyd McKenzie (Jan 08 2021 at 14:11):
I wouldn't expect 'performed' to have near as much detail as 'planned'. The 'performed bit' is primarily about how to keep track of progress with the plan, not to convey the details of everything that's happened. For that, the expectation is very much that you'll point to the individual event records.
Lloyd McKenzie (Jan 08 2021 at 14:12):
On the performed side, you either reference what's done or convey a code or text to give some kind of indication about what's been done or how much as been done.
Lloyd McKenzie (Jan 08 2021 at 14:12):
CarePlan is, fundamentally a description of "what's planned" and allows participants to 'manage the plan'. It's not a grouper.
John Moehrke (Jan 08 2021 at 14:18):
given the principle of newer instances pointing at older instances... would the tracking of performed activities be more properly (RESTfully) have a way of pointing at the careplan that they are to be considered helping? Rather than always updating the careplan just to update an element pointing at these new (performed activities) resources.
Lloyd McKenzie (Jan 08 2021 at 14:35):
The workflow would be that the CarePlan gets created, then a bunch of stuff happens, then someone comes along to update the CarePlan to reflect status. There's a need to indicate which specific activities have progressed. Merely linking an Event to the CarePlan (which can be done using Event.basedOn) wouldn't provide that.
Olga Vovk (Jun 02 2021 at 13:31):
HI Lloyd, Jose and John,
I am following your discussion with a great interest and I hope you don't mind if I do that and if I ask a question.
Lloyd you wrote: "CarePlan is, fundamentally a description of "what's planned" and allows participants to 'manage the plan'. It's not a grouper."
My question is, if the actual sequence of events, e.g. administering of a given medication is not in-line with the defined CarePlan, how one should capture that? E.g. if in a given day the medication was given off-schedule. And one needs to reflect this, what would be the best way to do that?
Thank you!
Olga
Lloyd McKenzie (Jun 02 2021 at 13:49):
The simplest is just to link the event resources and convey when they each happened within the resources themselves. If you need to specifically highlight the deviation and provide a reason for the deviation (as distinct from the reason for the event itself), we're probably talking extension space, though it might be a candidate for a 'standard' extension.
Olga Vovk (Jun 02 2021 at 14:00):
Hi Lloyd,
Thank you!
Yes, I need to highlight the deviation from the schedule and need to capture the reason for that deviation.
I will go ahead and create a JIRA ticket for a "standard" extension.
Thank you!
Olga
Olga Vovk (Jun 02 2021 at 15:55):
Created JIRA https://jira.hl7.org/browse/FHIR-32830
Del D (Jun 02 2021 at 16:13):
@olgavovk,
Olga, what about also checking to ensure the correct medication was given (checking the medication name) and ensuring the correct does was given ? also that the correct route was administered (oral, IV, intramuscular, etc) . The time isn't the only check.
Another check would be to ensure that the medication should be given (or shouldn't be given ) prior to a procedure - for instance an antibiotic prior to a procedure that should be given or a blood thinner prior to a procedure which shouldn't be given . But this adds a layer of complexity.
Olga Vovk (Jun 02 2021 at 16:16):
Hi Del,
Good points, Thank you!
I will updated the JIRA ticket,
Best,
Olga
Last updated: Apr 12 2022 at 19:14 UTC
