Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Applying a PlanDefinition to create CarePlan(s)

CarePlan resources are not created directly. Instead, they are constructed by applying a PlanDefinition.

The non Patient specific 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.

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

  • useContext

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

Each resulting ServiceRequest resource has:

  • a reference to its corresponding ActivityDefinition

  • status set to draft unless the corresponding ActivityDefinition is depending on one or more other ActivityDefinition (in which case status is set to on-hold).

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

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.

  • No labels