Applying a PlanDefinition to create CarePlan(s)

CarePlan resources are not created directly. Instead, they are constructed by applying a 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).

...

• a reference to its corresponding PlanDefinition through CarePlan.instantiatesCanonical.

• status set to draft

Each resulting ServiceRequest resource has:

• a reference to its corresponding ActivityDefinition

• status set to draft, with the following exception:

  • status is set to on-hold when 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.is a depending ServiceRequest (see below)

• a copy of the corresponding ActivityDefinition reuse criteria, if any

• a copy of the corresponding ActivityDefinition reuse criteriasharing policy, if any

• a copy of the corresponding ActivityDefinition sharing 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 in PlanDefinition.action.timing[x] takes precedence over ActivityDefinition.timing[x] for ActivityDefinition referenced in PlanDefinition.action.definition.

• a copy of the includeAsExtra extension for the corresponding PlanDefinition.action . If the PlanDefinition.action does not contain the extension, and extension with value false is 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.

...

Trigger Actions and Trigger Conditions

Action Triggers and Trigger Conditions

A PlanDefinition can contain one or more action trigger where each action trigger identifies the depending action/ActivityDefinition and the triggering action/ActivityDefinition (one or more) that it depends on. 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 to define an action trigger, including how to specify trigger conditions, trigger behavior and reaction to perform when conditions are met.

In the PlanDefinition.action[i].actionTrigger (see https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-plandefinition-definitions.html#PlanDefinition.action.extension:ehealth-actionTrigger )

• a depending action is the action for which the actionTrigger is 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.

When the PlanDefinition is applied to CarePlan and ServiceRequest resources, the action trigger and its trigger conditions manifest themselves in the ServiceRequest resources as follows:

• A depending ServiceRequest (related to an ActivityDefinition which is a depending action) has

  • trigger-enablement set to TRIGGER_ENABLED.

• A triggering ServiceRequest (related to an ActivityDefinition which is a triggering action) has

  • trigger-enablement set to NO_TRIGGER

  • meta.tag set to a Coding corresponding to trigger (see https://ehealth.sundhed.dk/fhir/CodeSystem-ehealth-action-type.html ).

In the example below, the a PlanDefinition contains containing an action trigger conditions where activity “action[2]” has an actionTrigger with dependencies to “action[0]” and “action[1]” . When has been applied to a CarePlan and ServiceRequest , these triggering conditions manifest themselves in the ServiceRequest resources as follows (and shown in the figure below):

• A The depending ServiceRequest SR2 (related to an ActivityDefinition , here AD2, with has action trigger conditions set) depending on trigger conditions to be met in other ServiceRequest has trigger-enablement set to TRIGGER_ENABLED.

  • In this case, the action trigger condition 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 status set to on-hold.

• A The triggering ServiceRequest (related to an ActivityDefinition, here this applies to AD0 and AD1, which another ActivityDefinition is depending on in its action resources SR0 and SR1 have:

  • trigger-enablement set to NO_TRIGGER (because they themselves are not depending on others)

  • meta.tag set to trigger

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: