Stream: implementers
Topic: CarePlan workflow, interaction PlanDefinition, CarePlan, ...
Martin Schubert (Oct 22 2021 at 09:16):
Hi. I'm working on a FHIR compliant "CarePlan-Workflow". The more I read the more questions pop up.
What I want to do:
We have a care program with different care sections (I would use resource PlanDefinition for each care section).
Then applying the PlanDefinition for the Patient.
An practitioner should see (e.g. in a workflow panel) which parts (ServiceRequests) of the CarePlan(?) are done and which are pending or cancelled.
In addition part of the ServiceRequests are grouped: e.g.
Request "record vital data"
|_SubRequest1 "pulse"
|_SubRequest2 "blood pressure"
Request "do basis assessments"
|_SubRequest1 "do Questionnaire 1"
|_SubRequest2 "do Questionnaire 5"
When a CarePlan is initialised there should be the possibility for the Practitioner to add additional custom ServiceRequests(?).
My approach:
Initialising a CarePlan from a PlanDefinition with ServiceRequests referenced in CarePlan.activity.reference.
The ServiceRequest hierarchy is represented by referencing the parent-Servicerequest in child-ServiceRequest.basedOn, because their status should be independent from parent Request and other child Requests (as statet in https://www.hl7.org/fhir/request.html#basedon and https://www.hl7.org/fhir/request.html#requestgroup).
When doing an Observation/Condition/Questionnaire (event object) in context of a ServiceRequest the events reference that in .basedOn.
For sake of simplicity I want to avoid using the Task resource.
The problems:
- "User-visible" information about an action is just present in the Resources PlanDefinition and RequestGroup (description, title, prefix...), so CarePlan seems not to be the right option to display the care program to the user, and it seems this is the same case for ServiceRequest (the only field that really describes it, is
.code.display) - CarePlan cannot represent the action hierarchy in contrast to PlanDefinition and RequestGroup. But RequestGroup seems not to be the right Resource to use, because it is stated that
"[RequestGroup] represent a group of optional activities" and "The RequestGroup and all of its referenced "option" Requests are treated as a single integrated Request whose status is the status of the RequestGroup. If there is a need to manage statuses of the different parts, separately, refer to the guidance https://www.hl7.org/fhir/request.html#compound."
- If it is necessary to get the user-visible information from the PlanDefinition I may have a problem if I add custom ServiceRequests to the CarePlan after applying the PlanDefinition
I'm a bit stuck at the moment modeling my use-case in the right way.
Lloyd McKenzie (Oct 22 2021 at 17:18):
When a CarePlan is initialised there should be the possibility for the Practitioner to add additional custom ServiceRequests(?).
Certainly that would be a capability providers & patients will want - protocols are rarely exhaustive and what you do in the real world will require modifications.
Not sure what you mean by issue #1
#2 - Care-plan is intended to be a relatively simple structure. If you want to establish a hierarchy among the different actions in a plan, you'll need to use extensions to link them that way. Same if you want to assert temporal or other dependencies
#3 - All information should be propagated to the generated resources. You should presume that people looking at a ServiceRequest might not have access to the PlanDefinition/ActivityDefinition.
Martin Schubert (Oct 25 2021 at 14:03):
Not sure what you mean by issue #1
Think that goes with #3.
PlanDefinition and RequestGroup establish a hierarchy and have fields like textequivalent, prefix, title described as e.g. "user-visible text". I don't have these information on a ServiceRequest when I want it to present to an user - as you said: All information should be propagated to the generated resources.
#2 - Care-plan is intended to be a relatively simple structure. If you want to establish a hierarchy among the different actions in a plan, you'll need to use extensions to link them that way. Same if you want to assert temporal or other dependencies
My intention was rather to get a hint if I'm on the wrong path. I don't want to violate the CarePlan resource if not necessary.
Is it a better way in this context to apply a PlanDefinition without creating a CarePlan, but rather only use RequestGroup ?
I'm working on a project in german healthcare. Are there reflections about depicting such workflows in the german context? @Simone Heckmann @Stefan Lang
Lloyd McKenzie (Oct 25 2021 at 14:17):
You can certainly use RequesatGroup - but a RequestGroup means that the collection has a single status and must be manipulated as a whole. I.e. you can't suspend or cancel a part without suspending/cancelling the whole thing.
Derek Ritz (Nov 04 2021 at 09:55):
@Martin Schubert I'm not sure if it applies 1:1, but there was a demo at the recent FHIR North conference of an open source stack that is operationalizing a guideline-based encounter using PlanDefinition / ActivityDefinition / CarePlan. The session video is here: https://www.youtube.com/watch?v=Z55ACEmLX0E. @Alex Goel
Martin Schubert (Nov 04 2021 at 14:07):
@Derek Ritz Thank you. I'll have a look on it.
Last updated: Apr 12 2022 at 19:14 UTC
