Versions Compared

Old Version 13

changes.mady.by.user Erik Nielsen

Saved on

compared with

New Version Current

changes.mady.by.user malthe lange

Saved on

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:

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

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

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

Image Added

Info