Maintaining a CarePlan

Maintaining of a CarePlan involves or might involve:

• setting the appropriate status

• adjusting of involved CareTeam(s)

Maintaining the CarePlan Status

Over the lifecycle of a CarePlan, its status might change. Adjustment of CarePlan.status can be performed through CarePlan Update by:

• Setting the CarePlan.status

• Setting the scheduled status changes in CarePlan.ehealth-statusschedule

  • scheduled changes are applied when the ApplyPlannedChangesJob is run.

Allowed status changes:

• From draft to active, entered-in-error, revoked

• From active to onhold, completed, revoked

• From onhold to active, completed, revoked

Maintaining the set of CareTeam(s) involved in a CarePlan

Over the lifecycle of a CarePlan, the set of CareTeam involved might change. Adjustment of CareTeam involved can be performed in several ways:

• Through CarePlan Update

  • Setting the CarePlan.careTeam

  • Setting the scheduled team changes in CarePlan.ehealth-teamschedule

  • Through CarePlan$update-care-teams

• Through EpisodeOfCare$update-care-teams (which also updates all CarePlan related to the EpisodeOfCare)

Maintaining a ServiceRequest

When maintaining a ServiceRequest, an employee must perform adjustment of:

• ServiceRequest.occurrence[x] which must contain a measurement regime with a defined starting date/time.

• ServiceRequest.status which must be set according to the situation, see below.

An employee should possibly consider (typically one-off) adjustment of:

• Sharing policy in ServiceRequest.ehealth-sharingPolicy

• Reuse criteria in ServiceRequest.ehealth-reuseCriteria

An employee should possibly consider continuous adjustment of:

• The CareTeam(s) involved in daily monitoring etc. in ServiceRequest.careTeam

• Measurement ranges in ServiceRequest.ehealth-referenceRange

• Any reference value needed for triaging based on relative measurement range(s)

Setting the ServiceRequest Measurement Regime

The measurement regime of a ServiceRequest expresses when the activity described in the ServiceRequest is supposed to take place. The measurement regime is defined in ServiceRequest.occurrence[x] by use of one of the alternatives:

• occurrenceDateTime - used when the activity should be performed at a specific point in time, that is date and time.

• occurrencePeriod - used when the activity should be performed once during a period. The period may be open, that is, without the period end being specified.

• occurrenceTiming - used when the activity should be performed in a recurring manner, for instance, each week or at specific days or times of day.

The initial measurement regime in ServiceRequest.occurrence[x] is a copy from the PlanDefinition/ActivityDefintion made at the time of creation (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Applying-the-PlanDefinition) and typically, it contains no starting date/time.

A starting date/time is required when ServiceRequest.status is all but draft, revoked, or entered-in-error. The starting date/time can be provided as:

• ServiceRequest.occurrenceDateTime - here the starting date/time is also the ending date/time.

• ServiceRequest.occurrencePeriod.start

• ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

If recurring timing expression is copied from PlanDefinition/ActivityDefinition created in KAM the following transformation is needed for the infrastructure to resolve the timing:

For periodUnit: WK and period greater than 1.

If PlanDefinition.action[].timingTiming.repeat.periodUnit is “WK” (Week) and PlanDefinition.action[].timingTiming.repeat.period is greater than 1. The following changes are needed for the expression to be resolvable in the infrastructure:

• dayOfWeek

  • dayOfWeek should used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start.

  • The value in dayOfWeek must be removed from ServiceRequest.occurrenceTiming.repeat.dayOfWeek.

• timeOfDay

  • timeOfDay is ignored for frequency-based timing but should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

  • For clarity, it is advised to remove the value in timeOfDay as it is not used for frequency-based timing.

• boundsDuration

  • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

  • boundsDuration must be removed

Example

Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every second Monday at 10 AM, for 2 months)

"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "dayOfWeek": [ "mon" ],
  "timeOfDay": [ "10:00:00" ],
  "boundsDuration": {
    "unit": "mo",
    "value": "2"
  }
}

Must be transformed to:

"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "boundsPeriod": {
    "start": "2023-09-04T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM
    "end": "2023-11-04T10:00:00.000+02:00" <-- ending after 2 months
  }
}

For periodUnit: other than WK(weekly)

• timeOfDay

  • timeOfDay is ignored for frequency-based timing but should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

  • For clarity, it is advised to remove the value in timeOfDay as it is not used for frequency-based timing.

• boundsDuration

  • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

  • boundsDuration must be removed

Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every third day at 10 AM, for 2 months)

"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "timeOfDay": [ "10:00:00" ],
        "boundsDuration": {
          "unit": "mo",
          "value": "2"
        }
      }

Must be transformed to:

"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "boundsPeriod": {
          "start": "2023-08-28T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM
          "end": "2023-10-28T10:00:00.000+02:00" <-- ending after 2 months
        }
}

Maintaining ServiceRequest Status

Over the lifecycle of a ServiceRequest, its status might change. Adjustment of ServiceRequest.status can be performed through ServiceRequest Update by:

• Setting the ServiceRequest.status

• Setting the scheduled status changes in ServiceRequest.ehealth-statusschedule

  • scheduled changes are applied when the ApplyPlannedChangesJob is run.

{
  "resourceType": "ServiceRequest",
  "id": "2297",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2023-05-16T07:50:59.790+00:00",
    "profile": [
      "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest"
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/workflow-episodeOfCare",
      "valueReference": {
        "reference": "https://careplan.cit-careplan-2467.local/fhir/EpisodeOfCare/2296"
      }
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-sharingPolicy",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://ehealth.sundhed.dk/cs/measurement-sharing-policies",
            "code": "noSharing"
          }
        ]
      }
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest-statusSchedule",
      "extension": [
        {
          "url": "status",
          "valueCode": "on-hold"
        },
        {
          "url": "scheduledTime",
          "valueDateTime": "2023-05-16T07:50:59+00:00"
        }
      ]
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest-statusSchedule",
      "extension": [
        {
          "url": "status",
          "valueCode": "revoked"
        },
        {
          "url": "scheduledTime",
          "valueDateTime": "2023-06-14T07:50:59+00:00"
        }
      ]
    }
  ],
  "instantiatesCanonical": [
    "https://plan.cit-careplan-2467.local/fhir/ActivityDefinition/94941"
  ],
  "status": "active",
  "intent": "filler-order",
  "code": {
    "coding": [
      {
        "system": "http://ehealth.sundhed.dk/cs/activitydefinition-code",
        "code": "445988008"
      }
    ],
    "text": "12254d24-58c3-480a-946f-ca72cdfa54d3"
  },
  "subject": {
    "reference": "https://patient.cit-careplan-2467.local/fhir/Patient/87825"
  }
}

{
  "resourceType": "ServiceRequest",
  "id": "2297",
  "meta": {
    "versionId": "2",
    "lastUpdated": "2023-05-16T07:51:00.889+00:00",
    "profile": [
      "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest"
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/workflow-episodeOfCare",
      "valueReference": {
        "reference": "https://careplan.cit-careplan-2467.local/fhir/EpisodeOfCare/2296"
      }
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-sharingPolicy",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://ehealth.sundhed.dk/cs/measurement-sharing-policies",
            "code": "noSharing"
          }
        ]
      }
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest-statusSchedule",
      "extension": [
        {
          "url": "status",
          "valueCode": "on-hold"
        },
        {
          "url": "scheduledTime",
          "valueDateTime": "2023-05-16T07:50:59+00:00"
        }
      ]
    },
    {
      "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest-statusSchedule",
      "extension": [
        {
          "url": "status",
          "valueCode": "revoked"
        },
        {
          "url": "scheduledTime",
          "valueDateTime": "2023-06-14T07:50:59+00:00"
        }
      ]
    }
  ],
  "instantiatesCanonical": [
    "https://plan.cit-careplan-2467.local/fhir/ActivityDefinition/94941"
  ],
  "status": "active",
  "intent": "filler-order",
  "code": {
    "coding": [
      {
        "system": "http://ehealth.sundhed.dk/cs/activitydefinition-code",
        "code": "445988008"
      }
    ],
    "text": "12254d24-58c3-480a-946f-ca72cdfa54d3"
  },
  "subject": {
    "reference": "https://patient.cit-careplan-2467.local/fhir/Patient/87825"
  }
}

The status should be set according to the situation:

• revoked when not to be performed for the particular Patient

• on-hold when depending on one or more submissions on another activity in the plan - this is the initial state when this is the case.

• active when any required device has been provided to the citizen and the measurement regime has been adjusted to contain the starting date/time

• completed when fully or adequately performed

Allowed status changes:

• From draft to active, entered-in-error, revoked

• From active to onhold, completed, revoked

• From onhold to active, completed, revoked

• From revoked to active, onhold

Setting Measurement Ranges and possibly Reference Base

See Creating and Maintaining Measurement Ranges.

Controlling the Trigger Enablement

In a PlanDefinition, action triggers can be added for the comprised activities as described in 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. When the PlanDefinition is $apply'ed to a CarePlan, it is reflected in each of the resulting ServiceRequest whether it is depending on trigger conditions to be met, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Action-Triggers-and-Trigger-Conditions. It is reflected in the ServiceRequest element triggerEnablement whether it is dependent or not. By default (at the time of $apply):

• ServiceRequest.triggerEnablement is set to NO_TRIGGER when the ServiceRequest is not depending on trigger conditions. It may trigger other ServiceRequest, though.

• ServiceRequest.triggerEnablement is set to TRIGGER_ENABLED if it depends on trigger conditions. The ServiceRequest.status is set to on-hold.

When trigger conditions are fulfilled, a triggerEnablement of TRIGGER_ENABLED changes to TRIGGER_DONE automatically as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Automated-Processing-of-Action-Triggers-and-Trigger-Conditions. At this point, even if the trigger conditions are fulfilled again, there will be no change.

It is possible to control, per ServiceRequest, whether it shall react to action triggers. The following manual changes of triggerEnablement are possible by ServiceRequest Update:

• TRIGGER_ENABLED change to TRIGGER_DISABLED - to disable triggering of the depending ServiceRequest, for instance, if the citizen is on vacation.

• TRIGGER_DISABLED change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest, for instance, if the citizen has returned from vacation.

• TRIGGER_DONE change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest even though it has been triggered already.

When re-enabling, it should be considered what is the appropriate status of the ServiceRequest. For a triggering behaviour such as activation, the ServiceRequest status should manually be set to on-hold.