Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt
nameTechnical

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

Child pages (Children Display)
styleh6
excerptTypesimple

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.

  • status set to draft

Note

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). At time of $apply, the infrastructure picks one Condition at random in case the EpisodeOfCare references more than one.

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

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

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:

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

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 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 https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Automated-Processing-of-Triggering-Conditions for further details on this automatic change.

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

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:

...

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 status on-hold (as is the case for ServiceRequest referencing ActivityDefinition with trigger dependency expressed in PlanDefinition).

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:

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