Stream: ihe
Topic: DCP - Dynamic Care Planning
René Spronk (Oct 15 2019 at 13:54):
If we interpret a Care Plan to be a thing which reflects the current thinking (intent) of a care team, (a) are updates to the care plan in any way limited to the 'options' it contains, or is it envisioned that one could add new activities to a care plan as well ? (b) it is recommended that one used contained 'request' resources resources as long as those have intent=option. As soon as one selects an option as something that will now have to be done, one would create a corresponding resource (or set thereof, if multiple workflow resources are used to capture the details of one requested activity) which is not contained any more. Correct ? (c) what do you envision to be the most commonly used query parameters for the Care Plan resource? and (d) let's assume (for the sake of this question) we're not using CarePlanDefinition and $apply in order to create a CarePlan, there is some 'different' way of creating a CarePlan resource. If all activities are referenced (and not defined using the detail option), when would one reference RequestGroup (which contains various requests) versus when would one reference the individual requests ? What would the guidance be ?
René Spronk (Oct 20 2019 at 11:54):
In request.intent, should the concept of 'option' be a specialization of the concept 'proposal' (currently they're sibling concepts)
René Spronk (Oct 23 2019 at 06:55):
@Emma Jones ?
Emma Jones (Oct 30 2019 at 21:33):
(a) are updates to the care plan in any way limited to the 'options' it contains, or is it envisioned that one could add new activities to a care plan as well ? If working with an dynamic care plan (vs CarePlan resource that is part of a document at a point in time) new activities can be added to a Care Plan.
Emma Jones (Oct 30 2019 at 21:44):
(b) it is recommended that one used contained 'request' resources resources as long as those have intent=option. As soon as one selects an option as something that will now have to be done, one would create a corresponding resource (or set thereof, if multiple workflow resources are used to capture the details of one requested activity) which is not contained any more. Correct ? Response: I'm not sure I understand the question. Would the "one requested activity" have references to the multiple worflow resources? If yes, why is it not contained anymore? It's linked (like Chaining). Wouldn't FHIR support the traversing of the linkages? If not, couldn't Resource Linkage be used?
Emma Jones (Oct 30 2019 at 22:00):
(c) what do you envision to be the most commonly used query parameters for the Care Plan resource? IHE DCP Care Plan CapabilityStatement is here - https://github.com/IHE/fhir/blob/master/CapabilityStatement/capabilitystatement-IHE_DCP_CarePlanContributor.xml See <!--CarePlan search parameters-->
Emma Jones (Oct 30 2019 at 22:05):
(d) let's assume (for the sake of this question) we're not using CarePlanDefinition and $apply in order to create a CarePlan, there is some 'different' way of creating a CarePlan resource. If all activities are referenced (and not defined using the detail option), when would one reference RequestGroup (which contains various requests) versus when would one reference the individual requests ? What would the guidance be ? Response: Suggest using Resource Linkage?
Emma Jones (Nov 20 2019 at 21:28):
The only issue with the use of reference linkage, is that the aspects of care planning relates to each other - DynamicCarePlanningLinkages.pdf
Last updated: Apr 12 2022 at 19:14 UTC
