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
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’
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 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 thePeriod.start
of the next have the same timestamp.
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)
CareTeam Handover and Unhandled Tasks
When adjusting the involved CareTeams, consideration should be made as to the handling of Task resources about the CarePlan, its measurements or other resources related to the CarePlan. For employees, being part of a CareTeam involved in the CarePlan (and/or EpisodeOfCare) is a prerequisite to accessing the CarePlan, related measurements and so forth. Access to Task on the other hand is governed by being identified in the Task explicitly. Therefore, handover from one set of CareTeam to another could entail:
A period where both sets of CareTeam are involved in the CarePlan. In this period, both sets of CareTeam will be able to access CarePlan, measurements and so on as well as the related Task resources. The set of CareTeam parting involvement should handle Task resources created before the period.
Adjusting the CareTeam(s) designated as Task.taskResponsible for existing Task resources to include the set of CareTeam joining the CarePlan.
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
Sharing Approval Policy in
ServiceRequest.ehealth-sharingApprovalPolicy
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 Sharing Approval Policy
The Sharing Approval Policy of a ServiceRequest expresses whether the approval for registering documents is automated or done manually. It is defined in ServiceRequest.ehealth-sharingApprovalPolicy
.
This extension is Optional. If set, it can have one of two values:
automatic
- used when the approval of registering documents is wanted to be done automatically.manual
- used when the approval of registering documents should be done manually.
The initial ServiceRequest.ehealth-sharingApprovalPolicy
is a copy from the ActivityDefinition, made at the time of creation.
The sharing Approval Policy is set using a conceptMap
The ConceptMap http://ehealth.sundhed.dk/ConceptMap/activitydefinition-code-to-perform-sharing
is used to determine if the Sharing Approval Policy should be set based on the ServiceRequests code: http://ehealth.sundhed.dk/vs/activitydefinition-code
The column “Activitydefinition-code-to-perform-sharing” is used to decide whether the Sharing Approval Policy should be set for the given activitydefinition code, by use of the ConceptMap.
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.
The initial measurement regime can express “at any time” also known as ad-hoc 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
.
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.
The status should be set according to the situation:
revoked
when not to be performed for the particular Patienton-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/timecompleted
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
Enforced constraints on the duration of scheduled status with the value ‘on-hold’ 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’
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 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 thePeriod.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 the 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 thedevice
(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/orActivityDefinition.participant.type
is set to thedevice
(found by traversingServiceRequest.instantiatesCanonical
)
Setting Measurement Ranges and possibly Reference Base
See Creating and Maintaining Measurement Ranges.
A Telemedicine Solution intended for employees should warn the user in the scenarios below.
Situation | FHIR ServiceRequest | FHIR ActivityDefinition (referenced by ServiceRequest) | FHIR Goal |
---|---|---|---|
The absolute triaging rule used, no absolute measurement range defined in ServiceRequest | No The user should define an absolute measurement range (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1706229761/Measurement+Ranges#Absolute-Measurement-Ranges). |
The
| Not used (but can co-exist with the use of relative triaging rule/relative measurement range). |
The relative triaging rule used, no relative measurement range defined in ServiceRequest | No The user should define a relative measurement range (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1662025748/Creating+and+Maintaining+Measurement+Ranges#Setting-up-Relative-Reference-Ranges-and-a-Reference-Base). |
The
| Possibly defined, otherwise see the row below. |
Relative triaging rule used, no reference base defined | At least one | The user should define a reference base (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1662025748/Creating+and+Maintaining+Measurement+Ranges#Setting-up-Relative-Reference-Ranges-and-a-Reference-Base) |
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 toNO_TRIGGER
when the ServiceRequest is not depending on trigger conditions. It may trigger other ServiceRequest, though.ServiceRequest.triggerEnablement
is set toTRIGGER_ENABLED
if it depends on trigger conditions. TheServiceRequest.status
is set toon-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 toTRIGGER_DISABLED
- to disable triggering of the depending ServiceRequest, for instance, if the citizen is on vacation.TRIGGER_DISABLED
change toTRIGGER_ENABLED
- to re-enable triggering of a depending ServiceRequest, for instance, if the citizen has returned from vacation.TRIGGER_DONE
change toTRIGGER_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
.
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
changes to other values, e.g. completed
.
Setting the Document Sharing Approval Policy
The document registering approval policy of a ServiceRequest set in ServiceRequest.ehealth-sharingApprovalPolicy
expresses whether submitted measurement data (for instance measurements or questionnaire responses) for the activity shall be automatically approved for document sharing or whether manual approval is required.
When set, the value of ServiceRequest.ehealth-sharingApprovalPolicy
controls how approval for document registering is handled per submitted measurement:
manual
, a clinician must manually approve each submitted measurement for document registeringautomatic
, the eHealth Infrastructure automatically creates the approval for document registering
If not set, the default behaviour is manual
.
The ActivityDefinition.ehealth-sharingApprovalPolicy
is copied to a ServiceRequest as the initial value upon $apply where it can subsequently be adjusted.
Approval for document registering is not the only prerequisite for document registering to happen. See Sharing through Registering Documents in National Document Sharing Infrastructure .