| Excerpt | ||
|---|---|---|
| ||
Technical description of how to create CarePlans by applying a PlanDefinition. |
| Child pages (Children Display) | ||||
|---|---|---|---|---|
|
Applying a PlanDefinition to create CarePlan(s)
CarePlan resources are not created directly. Instead, they are constructed by applying a PlanDefinition.
| Info |
|---|
The PlanDefinion are non-Patient specific . A 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. |
...
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).
...
a reference to its corresponding PlanDefinition through
CarePlan.instantiatesCanonical.statusset todraft
| Note |
|---|
The EpisodeOfCare passed as input to $apply is referenced from the CarePlan. The EpisodeOfCare can reference one or more Condition (through It is the responsibility of the user invoking $apply to ensure that the proper Condition is referenced from the CarePlan, and if needed, to replace the current through a CarePlan Update operation. |
Each resulting ServiceRequest resource has:
a reference to its corresponding ActivityDefinition
statusset todraft, with the following exception:statusis set toon-holdwhen the ServiceRequest is a depending ServiceRequest (see below)
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 document registering approval 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.a copy of the
includeAsExtraextension for the correspondingPlanDefinition.action. If thePlanDefinition.actiondoes not contain the extension, and extension with valuefalseis added to the ServiceRequest
At some point before a ServiceRequest has status set to active, its measurement regime must be defined with a starting date/time.
| Note |
|---|
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:
|
| Note |
|---|
It is expected that a Telemedicine Solution intended for employees guides the user in setting ServiceRequest starting date/time even when initially set with |
Action Triggers and Trigger Conditions
...
In the PlanDefinition.action[i].actionTrigger (see https://docs.ehealth.sundhed.dk/latest-released/igfhir/StructureDefinition-ehealth-plandefinition-definitions.html#PlanDefinition.action.extension:ehealth-actionTrigger )
a depending action is the action for which the
actionTriggeris defined.one or more triggering actions are those that the depending action is depending on and for which trigger conditions and behavior is defined in the trigger action.
...
A depending ServiceRequest (related to an ActivityDefinition which is a depending action) has
trigger-enablementset toTRIGGER_ENABLED.
A triggering ServiceRequest (related to an ActivityDefinition which is a triggering action) has
trigger-enablementset toNO_TRIGGERmeta.tagset to a Coding corresponding totrigger(see https://docs.ehealth.sundhed.dk/latest-releasedfhir/ig/CodeSystem-ehealth-action-type.html ).
In the example below, the a PlanDefinition contains containing an action trigger where activity “action[2]” has dependencies to “action[0]” and “action[1]” . As a result of applying it to has been applied to a CarePlan and ServiceRequest resources, the action trigger and its trigger conditions manifest themselves in the ServiceRequest resources as follows (and shown in the figure below):
The depending ServiceRequest SR2 (related to ActivityDefinition AD2, with has action trigger set) has
trigger-enablementset toTRIGGER_ENABLED.In this case, the action trigger for the action[2] (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.
The triggering ServiceRequest resources SR0 and SR1 have:
trigger-enablementset toNO_TRIGGER(because they themselves are not depending on others)meta.tagset totrigger
| Info |
|---|
|
| Note |
|---|
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 |
| Note |
|---|
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:
|