Stream: Care Plan/Care Coordination
Topic: Loss to follow up
Jose Costa Teixeira (Dec 28 2020 at 19:09):
In CarePlan, how do I capture loss to follow up? Patient was following a plan, but in July they somehow abandoned it.
Emma Jones (Dec 28 2020 at 20:58):
- Did the patient die (e.g. the plan was in progress and the patient died)? Once a patient dies and the date/time of death is documented, most users do not continue to document on-going aspects of the plan.
- Was the plan ever started (surgical plan but the patient changed their mind)? If so, in this case the status element can be used and if a different plan was decided on, the existing plan can be replaced by the new plan.
- Was the entire plan started and then patient decided to abandon the plan? There has to be a follow-up plan where negotiation occurs or it's documented that the patient is refusing specific care (activities) or transition to other care modalities (which can include self-care), etc.
What you're asking is situational, in which case, a lot of variances can occur. If a patient was following a plan and it somehow got abandoned without some sort of indication of what happened next can be a form of negligence.
Gay Dolin (Dec 28 2020 at 21:41):
I am unclear if you are asking about if the patient was 1)not followed up on, 2) couldn't be found or 3) patient chose to no longer follow a plan?
Jose Costa Teixeira (Dec 28 2020 at 21:55):
2) or 3) i guess. The relevant information is that the patient somehow stopped the treatment.
Jose Costa Teixeira (Dec 28 2020 at 21:56):
Presumably patient is still alive
Gay Dolin (Dec 28 2020 at 23:10):
I think it will be helpful for you to look at the FHIR Goal Resource (https://www.hl7.org/fhir/goal.html) Be sure to look at the extensions as well so you can fully see how "Goal" elements , attributes and extensions are really what can bring the FHIR Care Plan together (which does kinda replicate the Care Planning in the real world). In a project I was working on - in our goal profiles, we required or Must supported the following things:
Goal.measure (Required) Bound to it’s relevant goal target value set
Goal.expressedBy (Must Support)
Goal.addresses (Must Support)
Goal.outcomeReference (Must Support)
Goal.extension:goal-acceptance (Must Support)
Goal.extension:reasonRejected (Must Support)
Goal.extension:goal-relationship (Must Support)
In addition your resource instances should leverage the resource-pertainsToGoal extensionto relate a resource to its goal.
Jose Costa Teixeira (Dec 28 2020 at 23:31):
I don't see an application of Goal here. My use case is chronic disease treatment, so I need to track the plan.
Jose Costa Teixeira (Dec 28 2020 at 23:33):
this is a simple care plan for a chronic condition. there are goals there, but I don't want to know when the patient gve up on the goal, but when the patient stopped following the plan.
Jose Costa Teixeira (Dec 28 2020 at 23:34):
Workflow is never a simple thing, but in FHIR I think we have good mechanisms. But CarePlan is missing a few parts, I think.
Jose Costa Teixeira (Dec 28 2020 at 23:38):
so, assuming that CarePlan is a "task-y" resource in the sense that it can represent a request/plan as well as events from its execution, this could be a simple thing on the CarePlan - either some elements to say "Abandoned (+when/why)", or perhaps a special activity detail code..
But this goes to the other question - if CarePlan is able to follow requests and events, we should have a clear way to convey the events - planned or not.
Lloyd McKenzie (Dec 29 2020 at 16:41):
CarePlan.activity.plannedActivityDetail allows you to mark something as stopped or cancelled. The statusReason would allow you to capture 'why'. I don't think a CarePlan is intended to reflect all activities undertaken, only those that were planned. You can't query the CarePlan and expect to get the whole patient history.
Jose Costa Teixeira (Dec 29 2020 at 16:57):
not all activities, but what about those that become relevant like adrenalin administration, or abandoning treatment, or something else that is important? If not part of the plan, where would this be?
Emma Jones (Dec 29 2020 at 18:29):
@Lloyd McKenzie per " I don't think a CarePlan is intended to reflect all activities undertaken, only those that were planned. "
We should not have to limit to only activities that are planned. To Jose's point, we need to be able to track activities that were "done", "not yet done", "not going to get done".
Lloyd McKenzie (Dec 29 2020 at 19:47):
Sure. What I'm saying is that you wouldn't typically include activities 'done' if they had never been planned in the first place. I.e. A CarePlan isn't a record of everything that occurred, merely everything that was planned to occur (and whether it happened as planned or not). That doesn't mean you couldn't update a careplan to include unplanned activities, just that it wouldn't be typical/expected.
Jose Costa Teixeira (Dec 29 2020 at 20:15):
Ok so if I need to profile it to be expected (like in my "Abandoned treatment" example, CarePlan should be the place for it, right?
Lloyd McKenzie (Dec 29 2020 at 20:20):
If you want to say "they were supposed to do X, but ended up not doing it", that could be CarePlan or it could be a different Request resource.
Jose Costa Teixeira (Dec 29 2020 at 20:43):
I'll give it a try. I understand I'm extending CarePlan to mean also "CareTreatment"
René Spronk (Dec 30 2020 at 09:10):
Encounter, EpisodeOfcare, Condition are groupers of activities that have happened, or should have happened. So why use CarePlan, the intent of which is not to capture data about 'events' ?
Jose Costa Teixeira (Dec 30 2020 at 09:19):
A treatment - especially a continued / home care treatment will not be associated with one Encounter.
Jose Costa Teixeira (Dec 30 2020 at 09:20):
I think Condition is a condition, not a grouper of activities to address it
Jose Costa Teixeira (Dec 30 2020 at 09:23):
I think EpisodeOfCare might be a valid grouper, although from the description I don't know what to make of it:
"The EpisodeOfCare usually exists before the CarePlan." ,
"...each organization will have its own EpisodeOfCare resource instance that tracks its responsibility with the patient."
Jose Costa Teixeira (Dec 30 2020 at 09:26):
I need to use "Treatment" for
- chronic condition follow-up (with or without treatment, perhaps only monitoring),
- home care e.g. for elderly
- medication treatments (like the Swiss Medication Treatment Plan)
René Spronk (Dec 30 2020 at 09:26):
EpisodeOfCare is a 'clinical grouper' whereas Encounter is a 'administrative/logistical/financial' grouper. See http://build.fhir.org/episodeofcare.html#8.10.3.1 for use cases.
René Spronk (Dec 30 2020 at 09:27):
Chronic Disease Management Systems
Community Care Systems
Tracking progress of a specific condition
Tracking government funding
Problem based General Practice systems
Disability Support Systems
Aged Care Systems (Community and Residential)
Jose Costa Teixeira (Dec 30 2020 at 09:41):
yes, I noticed the use cases. The questions I have is around the workflow - this seems fuzzy still, with Goal, CarePlan, etc.
Jose Costa Teixeira (Dec 30 2020 at 09:43):
btw, my understanding is that CarePlan intends to somehow capture events (when we capture performance of planned activities , that's an event). This is why I expressed that careplan is "task'y"
Jose Costa Teixeira (Dec 30 2020 at 09:44):
If CarePlan is the equivalent to those white boards where you plan activities and then follow the progress, that starts with a "request" but ends up being updated more often than a request would
René Spronk (Dec 30 2020 at 10:04):
To me, CarePlan is 'I'm thinking of potentially issuing a request'. That's very, very, early in the 'task' workflow. as soon as you create a Request/Task in an executable status, they're no longer part of the CarePlan, they'd move over to EpisodeOfcare, and the 'I'm thinking of potentially issuing a request' part of the CarePlan would be deleted from it. That'd be my expectation.
Jose Costa Teixeira (Dec 30 2020 at 10:05):
This differs from my understanding - which I'm glad to change, but I think we need guidance on these resources
René Spronk (Dec 30 2020 at 10:10):
If we allow for 'event' resources to be part of CarePlan, then why would we have EpisodeOfcare ? EpisodeOfCare (IMHO) has a wider scope than CarePlan, EpisodeOfCare could 'include' CarePlan(s), not the other way around. If you're seeking guidance, you may have to phrase a couple of well considered questions which can then be addressed by this forum and the responsible HL7 committee..
Jose Costa Teixeira (Dec 30 2020 at 10:12):
that is what I am exploring here. This discussion started with CarePlan, then Goal..
Jose Costa Teixeira (Dec 30 2020 at 10:13):
René Spronk said:
If we allow for 'event' resources to be part of CarePlan, then why would we have EpisodeOfcare
Gay Dolin said:
I believe these all can be captured using FHIR Care Plan. It is not straightforward however. Some diagrams that might help:
CarePlanDiagramWithActivityFocus.png ExampleInstanciatedFHIR_CarePlan_Goal.png FHIR_MCC_Care_Plan_FinalForDraft.png
René Spronk (Dec 30 2020 at 10:26):
activity.performedActivity, used to capture the outcome of a planned activity, does indeed muddle the issue. That, and plannedActivityDetails.status does lead me to think that apparently scheduled activities aren't removed from a CarePlan, but are kept on record as being part of a CarePlan.
So we'll certainly need guidance around "If one records a care event, when would this be recorded to be part of a CarePlan, and when as part of an EpisodeOfCare ?"
Jose Costa Teixeira (Dec 30 2020 at 10:52):
...and whether/when as a part of something else..
Emma Jones (Dec 31 2020 at 22:12):
René Spronk said:
If we allow for 'event' resources to be part of CarePlan, then why would we have EpisodeOfcare ? EpisodeOfCare (IMHO) has a wider scope than CarePlan, EpisodeOfCare could 'include' CarePlan(s), not the other way around. If you're seeking guidance, you may have to phrase a couple of well considered questions which can then be addressed by this forum and the responsible HL7 committee..
I think of Episode of Care to be more limiting contextually than CarePlan - at least in the context of how "episodeOfCare" is typically used by EHRs (and for payment purposes). For example, an inpatient admission with follow-up home care services may make up one episode of care. A year later, if the patient is admitted for another inpatient stay and follow up homecare services that is a second completely different "episode of care". Even billing occurs based on this context. Whereas with care planning, the patient may have a chronic illness that may end up needing multiple episodes of care that can occur as long as the patient has the illness and planning occurs to deal with the illness. The main need for care plan is to collect and coordinate the various care processes (which contain "episodes of care").
René Spronk (Jan 01 2021 at 10:21):
I agree that one of the problems with Encounter and EpisodeOfCare is that its usage varies enormously given a particular context/country, and that it would be difficult to provide universal guidance. In some settings a Chronic Illness has exactly 1 EpisodeOfCare associated with it. CarePlans could be short term, or long terms, or could be comprised on multiple other (smaller) CarePlans.
The discussions is around the fundamental nature of these resources, when would one be used versus where another ? In general we should be able to provide (better) guidance around this.
Petter Wolff (May 31 2021 at 07:05):
Lloyd McKenzie said:
CarePlan.activity.plannedActivityDetail allows you to mark something as stopped or cancelled. The statusReason would allow you to capture 'why'. I don't think a CarePlan is intended to reflect all activities undertaken, only those that were planned. You can't query the CarePlan and expect to get the whole patient history.
René Spronk said:
I agree that one of the problems with Encounter and EpisodeOfCare is that its usage varies enormously given a particular context/country, and that it would be difficult to provide universal guidance. In some settings a Chronic Illness has exactly 1 EpisodeOfCare associated with it. CarePlans could be short term, or long terms, or could be comprised on multiple other (smaller) CarePlans.
The discussions is around the fundamental nature of these resources, when would one be used versus where another ? In general we should be able to provide (better) guidance around this.
I think what Lloyd said is important; "You can't query the CarePlan and expect to get the whole patient history" (same goes for EpisodeOfCare). But the CarePlan _can_ be used as a record, with more context than either EpisodeOfCare, Encounter or simpler resources (typically: Observation), as shown by the inclusion of e.g. activity.outcome[CodeableConcept/Reference]. And personally, I think this is potentially a useful richer context for the record - and I'm not too fond of putting that responsibility to EpisodeOfCare. But like you say, René, this could be made clearer, because at the moment CarePlan is described (in Scope and Usage) only as a request resource.
I would be happy to hear you expand on these thoughts @Jose Costa Teixeira (sorry if you have expressed most of it already, but here's possibly a new context :upside_down: for the same ideas).
Last updated: Apr 12 2022 at 19:14 UTC
