Page Comparison

Enforced constraints on the duration of scheduled status with value ‘on-hold’.

When setting scheduled status changes it is automatically enforced how long the CarePlan can be planned as paused. This is done to prevent patient plans from being forgotten in a paused state.

When setting CarePlan.ehealth-statusschedule:

• If no further status changes are planned by the user, then the infrastructure will automatically insert a planned change back to ‘active’ 7 days after the start of ‘on-hold’

• Maximum The maximum duration of a planned ‘on-hold’ status is 30 days.

CarePlan automatically maintains a status history CarePlan.statushistory:

• The status history is maintained as a list of ehealth-statusHistory objects each containing:

  • A status.

  • The Period of time period the status was set.

• The history is automatically updated when the status is (regardless of whether the status is set manually or is a scheduled change):

  • A new entry is added with the new status and an open-ended period that started at the time of the status change.

  • The Period.end in the entry for the previous status is updated to be the same as the start of the new entry.

    • One should consider the period to be exclusive-end to avoid confusion as the Period.end of one historic status and the Period.start of the next have the same timestamp.

The initial measurement regime can express “at any time” also known as ad-hoc by means of using a Timing. When no additional constraints are set (for instance elements count and possibly countMax), “at any time” can be an empty Timing construct. To prevent removal during persisting, Timing.id may contain a random value.

It is expected that a Telemedicine Solution sets the hours part of the measurement regime starting date/time to Timing.timeOfDay in case of a frequency-based Timing (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#When-an-Activity-is-Supposed-to-Happen---The-Notion-of-Resolved-Timing) that has Timing.timeOfDay.

Enforced constraints on the duration of scheduled status with the value ‘on-hold’ is are the same as for the CarePlan.status.

When setting scheduled status changes it is automatically enforced how long the ServiceRequest can be planned as paused. This is done to prevent patient plans from being forgotten in a paused state.

When setting ServiceRequest.ehealth-statusschedule:

• If no further status changes are planned by the user, then the infrastructure will automatically insert a planned change back to ‘active’ 7 days after the start of ‘on-hold’

• Maximum The maximum duration of a planned ‘on-hold’ status is 30 days.

ServiceRequest, like EpisodeOfCare and CarePlan, automatically maintains a status history ServiceRequest.statushistory:

• The status history is maintained as a list of ehealth-statusHistory objects each containing:

  • A status.

  • The Period of time period the status was set.

• The history is automatically updated when the status is (regardless of whether the status is set manually or is a scheduled change):

  • A new entry is added with the new status and an open-ended period that started at the time of the status change.

  • The Period.end in the entry for the previous status is updated to be the same as the start of the new entry.

    • One should consider the period to be exclusive-end to avoid confusion as the Period.end of one historic status and the Period.start of the next have the same timestamp.

It is expected that a Telemedicine Solution warns the user in case the status is set to revoked or completed for a triggering ServiceRequest which another (depending) ServiceRequest is relying on for trigger conditions (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) when the depending ServiceRequest has ServiceRequest.triggerEnablement set to TRIGGER_ENABLED. A triggering ServiceRequest can be recognized by having a ServiceRequest.meta.tag value trigger (see https://docs.ehealth.sundhed.dk/latest-released/ig/CodeSystem-ehealth-action-type.html).

It is expected that a Telemedicine Solution warns the user in case status is set to revoked or completed for a ServiceRequest where a submitted measurement is used as input for another ServiceRequest (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1717436538/Preparing+and+Submitting+Measurements#Preparing-an-Observation-for-a-Value-Entered-or-Calculated-in-a-QuestionnaireResponse).

The ways to determine whether a ServiceRequest needs a measurement from another ServiceRequest as input are:

• PlanDefinition.action.participant.type is set to the device (found by doing a ServiceRequest Search reverse include “CarePlan:activity-reference” (see https://docs.ehealth.sundhed.dk/latest-released/ig/CapabilityStatement-careplan.json.html) giving CarePlan which can be traversed through CarePlan.instantiatesCanonical to PlanDefinition), and/or

• ActivityDefinition.participant.type is set to the device (found by traversing ServiceRequest.instantiatesCanonical)

The current reaction (selected in PlanDefinition.action.ehealth-actionTrigger.action) to the action trigger's trigger conditions being met is to change the ServiceRequest status from on-hold to active. There is no reaction to cause ServiceRequest.status change changes to other values, e.g. completed.