Stream: implementers
Topic: Careplan questions
Jose Costa Teixeira (Aug 24 2019 at 06:10):
A few questions when looking at careplan for our implementation:
1. http://build.fhir.org/valueset-care-plan-category.html mentions an issue rendering the content. Normal, or I should enter a ticket?
Jose Costa Teixeira (Aug 24 2019 at 06:14):
2. CarePlan.activity: what does "outcome" mean? expected outcome (I'd think so) or actual outcome found during the execution of a plan (which I feel less comfortable because CarePlan is a plan -a request- and not an event). Should we clarify?
Jose Costa Teixeira (Aug 24 2019 at 06:35):
3. What is the difference / overlap between CarePlan.addresses and Careplan.goal?
Jose Costa Teixeira (Aug 24 2019 at 06:40):
Also, Goal seems to implement the Pattern definition, but it says it does not implement any patterns.
John Moehrke (Aug 26 2019 at 14:04):
also check with @Emma Jones as she is leading a joint project on CarePlan between IHE and HL7
Emma Jones (Aug 26 2019 at 17:31):
Per #2 - "outcome" can be both expected and actual.
Emma Jones (Aug 26 2019 at 17:31):
Please see http://build.fhir.org/careplan-definitions.html#CarePlan.activity.outcomeReference - activity.outReference . Actual outcomes, references "event" resource - actual result/outcome of the activity. Expected outcomes can reference a "request" resource.
Emma Jones (Aug 26 2019 at 17:38):
Or, activity.detail can be used.
Emma Jones (Aug 26 2019 at 17:40):
CarePlan.addresses - is the reason, need or what the carePlan is used for or why the carePlan came into existence.
Emma Jones (Aug 26 2019 at 17:42):
carePlan.goal is what the carePlan achieves.
Jose Costa Teixeira (Aug 26 2019 at 18:17):
I do not know how to handle the fact that careplan captures the planning and the execution.
Jose Costa Teixeira (Aug 26 2019 at 18:17):
(if i am understanding it right)
Jose Costa Teixeira (Aug 26 2019 at 18:31):
Wait, now I know. I will work on some examples and bring them forward
Stephen Chu (Sep 03 2019 at 23:49):
2. CarePlan.activity: what does "outcome" mean? expected outcome (I'd think so) or actual outcome found during the execution of a plan (which I feel less comfortable because CarePlan is a plan -a request- and not an event). Should we clarify?
CarePlan.activity.outcome = is intended to capture the result of execution of a care plan activity, which is measured/compared against the goal.target
While the care plan is intended to be a plan and request artefact, it also needs to capture what actually has/had been achieved against care activities to provide the evidences in support the reviews at care activity, goal and care plan levels
As such, it is not unreasonable for CarePlan.activity.outcome to support capturing of actual outcome
Stephen Chu (Sep 04 2019 at 01:18):
3. What is the difference / overlap between CarePlan.addresses and Careplan.goal?
CarePlan.addresses = intended to capture the health concerns (problems, conditions, issues) that the care plan is developed for/to address
CarePlan.goal = intended to capture one or more target outcome(s) to be achieved through execution or implementation of care plan activities
Example: CarePlan.addresses = Type 2 diabetes, failure to achieve normal-glycaemic control
CarePlan.goal = achieve pre-meal BSL range between 6-8mmol, 2-hours post meal BSL level =<10mmol
Jose Costa Teixeira (Sep 05 2019 at 14:34):
ok thanks.
Jose Costa Teixeira (Sep 05 2019 at 14:35):
I noticed that carePlan.partOf mentions
Each care plan is an independent request, such that having a care plan be part of another care plan can cause issues with cascading statuses. As such, this element is still being discussed.
Jose Costa Teixeira (Sep 05 2019 at 14:38):
4. Why "is being discussed" ? The way I interpret this, it seems straightforward.
My use case:
The institution makes a big umbrella plan. This plan contains nutrition and physiotherapy etc. This is Plan X1
The nutritionist then starts his own plan for which he is responsible. Plan X1N
The physiotherapist makes his own plan but he owns that. Plan X1P
Jose Costa Teixeira (Sep 05 2019 at 14:40):
What is the issue with cascading status? The status can and should be maintained independently, right?
Jose Costa Teixeira (Sep 05 2019 at 14:49):
5. shouldn't CarePlan.activity have a quantity? e.g. 5 sessions of physiotherapy
Lloyd McKenzie (Sep 05 2019 at 15:30):
The issue is "part of" vs. "fulfills". If the nutritionist makes their own plan that 'fulfills' the parent plan (i.e. basedOn), then if the parent plan is cancelled, it's totally fine for the nutritionist to carry on with their plan. (Cancelling the order doesn't necessarily stop work in progress.) However, with "part of", if the parent is cancelled, the components should automatically get cancelled too - and that's tricky.
Jose Costa Teixeira (Sep 05 2019 at 15:59):
ok, that makes sense as a potential issue. If CarePlan were a plan and not a plaecholder like task, I guess this problem would not exist, right?
Jose Costa Teixeira (Sep 05 2019 at 16:00):
I mean, we should have some guidance for the behaviour for Requests.PartOf. Do we need to extend or change that guidance as it applies to non-requests?
Lloyd McKenzie (Sep 05 2019 at 16:16):
I don't understand what you mean by "placeholder". The Request pattern doesn't support partOf - that's an Event thing. CarePlan is an exception in that it has it - and after the 'discussion' completes, it might well go away...
Jose Costa Teixeira (Sep 05 2019 at 16:45):
ah ok, my bad.
Jose Costa Teixeira (Sep 05 2019 at 16:45):
"placeholder" was a way to express "task-y" thing - can hold request and its evolution.
Jose Costa Teixeira (Sep 05 2019 at 16:46):
In our example we want to have sub-plans, so I hope we do it right. Will some real examples help in that discussion?
Last updated: Apr 12 2022 at 19:14 UTC
