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.
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.
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.