Page Comparison

...

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

...

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

...

• 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://docs.ehealth.sundhed.dk/latest-released/igfhir/CodeSystem-ehealth-action-type.html ).

In the example below, a PlanDefinition containing an action trigger where activity “action[2]” has dependencies to “action[0]” and “action[1]” has been applied to a CarePlan and ServiceRequest resources:

...