/
Creating Care Plans

Creating Care Plans

Technical description of how to create CarePlans by applying a PlanDefinition.

Applying a PlanDefinition to create CarePlan(s)

CarePlan resources are created by applying a PlanDefinition.

PlanDefinion are non-Patient. 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.

Patient-specific CarePlan and ServiceRequest resources and their linking to PlanDefinition and ActivityDefinition resources.

 

Finding The Appropriate PlanDefinition

Filtering applied on finding appropriate PlanDefinition could involve the following elements of PlanDefinition:

  • code

  • status set to active

  • ehealth-recommendation

  • ehealth-intendedAudience

  • useContext

 

Element in PlanDefinition

Example Value(s)

Element in PlanDefinition

Example Value(s)

status

active

ehealth-recommendation

Recommended

ehealth-intendedAudience

PlanDefinition intended for use in, say, Esbjerg Municipality

reference to FHIR Organization for Esbjerg Kommune (Esbjerg Municipality)

useContext

PlanDefinition intended for COPD in Telemedicine Solution TELMA:

  • code = focus, value = DJ44 (see condition code ValueSet)

  • code = program, value = telma (see program ValueSet)

 

Possibly, the following elements (and others) could be used as well:

  • title

  • version

  • publisher

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 $apply operation has the two modes described below:

$apply operation mode

Description

Invocation Method

Returned

$apply operation mode

Description

Invocation Method

Returned

persisting mode

Created CarePlan and ServiceRequest resources are persisted in the database.

POST request method

The root CarePlan is returned.

transient mode

Created CarePlan and ServiceRequest resources are not persisted in the database.

GET request method

The returned transaction Bundle contains all CarePlan and ServiceRequest resources.

Typically, use of the $apply transient mode is followed by client-side modification of returned resources and use of the https://ehealth.sundhed.dk/fhir/transaction.html where the CarePlan and ServiceRequest resources are part of the transaction bundle.

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.

  • status set to draft

Choosing the Condition addressed by a CarePlan

The EpisodeOfCare passed as input to $apply is referenced from the CarePlan. The EpisodeOfCare can reference one or more Condition (through EpisodeOfCare.diagnosis.condition) while the CarePlan can reference one only (through CarePlan.addresses). Selection of which Condition referenced by the EpisodeOfCare to reference from the CarePlan is performed server-side at time of $apply as follows:

Before Infrastructure release 2026.2

  1. The one or more Condition referenced in EpisodeOfCare.diagnosis.condition are considered

    1. If only one Condition is referenced, it is selected.

    2. If multiple Condition are referenced, the one with highest EpisodeOfCare.diagnosis.rankis selected.

      1. If multiple entries have same highest rank, a random is chosen

After Infrastructure release 2026.2

  1. The one or more Condition referenced in EpisodeOfCare.diagnosis.condition and with Condition.verificationStatus other than entered-in-error and refuted are considered

    1. If a single Condition is referenced, it is selected.

    2. If multiple Condition are referenced, the one with highest EpisodeOfCare.diagnosis.rankis selected.

      1. If multiple entries have same highest rank, the one with Condition.verificationStatus set to confirmed is selected

        1. If multiple entries have same highest rank and are confirmed, a random is selected

      2. Otherwise, if multiple Condition have same highest rank where Condition.verificationStatus other than confirmed is set, a random is selected

  2. If no Condition could be selected, the $apply operation fails.

 

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.

Resulting ServiceRequest resources

The characteristics and values mentioned below are highlighting aspects of the created resources. It is not a complete description of all their values.

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

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 to ServiceRequest.occurrence[x] initially, if present)

  • PlanDefinition.action.relatedAction (actionId, relationship and possible offset[x])

  • ActivityDefinition.timing[x] in ActivityDefinition referenced from ServiceRequest.instantiatesCanonical - This timing could specify a duration.

It is expected that a Telemedicine Solution intended for employees guides the user in setting ServiceRequest starting date/time even when initially set with status on-hold as is the case for a depending ServiceRequest. A depending ServiceRequest with status set to on-hold (as described below) can have its status changed automatically to active when its trigger conditions are met. See Behind the Scenes for further details on this automatic change.

Action Triggers and Trigger Conditions

A PlanDefinition can contain zero, one or more action triggers where each action trigger identifies the depending action/ActivityDefinition and the triggering action/ActivityDefinition (one or more) that it depends on. See Managing Telemedicine Packages 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

 

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:

  • The depending ServiceRequest SR2 (related to ActivityDefinition AD2, with has action trigger set) has trigger-enablement set to TRIGGER_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 status set to on-hold.

  • The triggering ServiceRequest resources SR0 and SR1 have:

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

    • meta.tag set to trigger

 

CarePlan with trigger actions defined in the PlanDefinition. The ehealth-actionTrigger is a backbone element in PlanDefinition, not a resource on its own. The use of an action trigger is reflected in elements in the ServiceRequest resources.