Applying a PlanDefinition to create CarePlan(s)
CarePlan resources are not created directly. Instead, they are constructed by applying a PlanDefinition.
The non Patient specific PlanDefinition likely references a number of ActivityDefinition defining what activities in what order constitute the plan, possibly with default measurement ranges. On applying a PlanDefinition, Patient specific counterparts to the PlanDefinition and ActivityDefinition resources are created as CarePlan and ServiceRequest resources, respectively.
.png?version=1&modificationDate=1649055568813&cacheVersion=1&api=v2&width=396&height=302)
Finding The Appropriate PlanDefinition
Filtering applied on finding appropriate PlanDefinition could involve the following elements of PlanDefinition:
codestatusset toactiveehealth-recommendationehealth-intentdedAudienceuseContext
Possibly, the following elements (and others) could be used as well:
titleversionpublisher
Applying the PlanDefinition
A PlanDefinition is applied through the PlanDefinition$apply operation. This creates a number of CarePlan resources (typically one) and a ServiceRequest resource for each non-group action in the PlanDefinition.action (please note that PlanDefinition.action enables a recursive construct through its PlanDefinition.action.action).
The characteristics and values mentioned below are highlighting aspects of the created resources. It is not a complete description of all their values.
The resulting CarePlan(s) has:
a reference to its corresponding PlanDefinition through
CarePlan.instantiatesCanonical.statusset todraft
Each resulting ServiceRequest resource has:
a reference to its corresponding ActivityDefinition
statusset todraft, with the following exception:statusis set toon-holdwhen the ServiceRequest references an ActivityDefinition which has a trigger dependency on trigger condition(s) for one or more other ActivityDefinition referenced in the same PlanDefinition. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1696137281/Managing+Telemedicine+Packages#Setting-up-one-or-more-actions-as-trigger-for-an-action-in-PlanDefinition for how dependencies on triggering is set up in the PlanDefinition. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2059763713/Maintaining+CarePlan+s+and+ServiceRequest+s#Controlling-the-trigger-enablement and https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Automated-Processing-of-Triggering-Conditions for how triggering can be controlled and how the infrastructure processes triggering, respectively.
a copy of the corresponding ActivityDefinition reuse criteria, if any
a copy of the corresponding ActivityDefinition sharing policy, if any
a copy of the corresponding ActivityDefinition measurement ranges, if any
an initial, relative measurement regime in
ServiceRequest.occurrence[x]which is a copy of the measurement regime appearing for the action, if any. Note that the measurement regime inPlanDefinition.action.timing[x]takes precedence overActivityDefinition.timing[x]for ActivityDefinition referenced inPlanDefinition.action.definition.
At some point before a ServiceRequest has status set to active, its measurement regime must be defined with a starting date/time.
Trigger Actions and Trigger Conditions
In the example below, the PlanDefinition contains trigger conditions where activity “action[2]” has an actionTrigger with dependencies to “action[0]” and “action[1]”. When applied to a CarePlan and ServiceRequest, these triggering conditions manifest themselves in the ServiceRequest resources as follows (and shown in the figure below):
A depending ServiceRequest (related to an ActivityDefinition, here AD2, with trigger conditions set) depending on trigger conditions to be met in other ServiceRequest has
trigger-enablementset toTRIGGER_ENABLED.In this case, the trigger condition for the ActivityDefinition AD2 has trigger reaction set to “activation from on-hold to active”, which is why the ServiceRequest SR2 is initially with
statusset toon-hold.
A triggering ServiceRequest (related to an ActivityDefinition, here this applies to AD0 and AD1, which another ActivityDefinition is depending on in its action trigger
It is expected that a Telemedicine Solution intended for employees guides the user in setting starting date/time for ServiceRequest even when initially set with status on-hold (as is the case for ServiceRequest referencing ActivityDefinition with trigger dependency expressed in PlanDefinition).
It is expected that a Telemedicine Solution in some form provides information about the intended time-wise layout of activities captured in the PlanDefinition and ActivityDefinition resources which the citizen’s plan is based on. This includes intention captured in:
PlanDefinition.action.timing[x](which is copied toServiceRequest.occurrence[x]initially, if present)PlanDefinition.action.relatedAction(actionId,relationshipand possibleoffset[x])ActivityDefinition.timing[x]in ActivityDefinition referenced fromServiceRequest.instantiatesCanonical- This timing could specify a duration.