...
Over the lifecycle of a CarePlan it’s its status might change. Adjustment of CarePlan.status can be performed through CarePlan Update by:
...
ServiceRequest.occurrence[x]which must contain a measurement regime with a defined starting date/time.ServiceRequest.statuswhich must be set according to the situation, see below.
An employee should possibly consider (typically one-off) adjustment of:
...
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 of time. 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 time 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.
...
ServiceRequest.occurrenceDateTime- here the starting date/time is also the ending date/time.ServiceRequest.occurrencePeriod.startServiceRequest.occurrenceTiming.repeat.boundsPeriod.start
...
If recurring timing expression is copied from PlandefinitionPlanDefinition/ActivityDefinition created in KAM the following transformation is needed for the infrastructure to resolve the timing:
...
Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every second Monday at 10 AM, for 2 months)
| Code Block | ||
|---|---|---|
| ||
"repeat": {
"frequency": 1,
"period": 2,
"periodUnit": "wk",
"dayOfWeek": [ "mon" ],
"timeOfDay": [ "10:00:00" ],
"boundsDuration": {
"unit": "mo",
"value": "2"
}
} |
Must be transformed to:
| Code Block | ||
|---|---|---|
| ||
"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
}
} |
...
timeOfDay
timeOfDay is ignored for frequency-based timing but should be used to set
ServiceRequest.occurrenceTiming.repeat.boundsPeriod.startFor 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.endboundsDuration must be removed
Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every third day at 10 AM, for 2 months)
| Code Block | ||
|---|---|---|
| ||
"repeat": {
"duration": 2,
"durationUnit": "h",
"frequency": 1,
"period": 3,
"periodUnit": "d",
"timeOfDay": [ "10:00:00" ],
"boundsDuration": {
"unit": "mo",
"value": "2"
}
} |
Must be transformed to:
| Code Block | ||
|---|---|---|
| ||
"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
}
} |
...
Over the lifecycle of a ServiceRequest it’s its status might change. Adjustment of ServiceRequest.status can be performed through ServiceRequest Update by:
...
| Expand | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
The example is from the implementation guide: ServiceRequest example operations. An update is performed by performing a Example Request:
Example body:
Example Response:
|
...
revokedwhen not to be performed for the particular Patienton-holdwhen depending on one or more submissions on another activity in the plan - this is the initial state when this is the case.activewhen any required device has been provided to the citizen and the measurement regime has been adjusted to contain the starting date/timecompletedwhen fully or adequately performed
...
| Note |
|---|
A Telemedicine Solution intended for employees should warn the user in the scenarios below. |
Situation | FHIR ServiceRequest | FHIR ActivityDefinition (referenced by ServiceRequest) | FHIR Goal |
|---|---|---|---|
Absolute triaging rule used, no absolute measurement range defined in ServiceRequest | No 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 use of relative triaging rule/relative measurement range). |
Relative triaging rule used, no relative measurement range defined in ServiceRequest | No 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 row below. |
Relative triaging rule used, no reference base defined | At least one | 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 on or not. By default (at the time of $apply):
ServiceRequest.triggerEnablementis set toNO_TRIGGERwhen the ServiceRequest is not depending on trigger conditions. It may trigger other ServiceRequest, though.ServiceRequest.triggerEnablementis set toTRIGGER_ENABLEDif it is depending on trigger conditions. TheServiceRequest.statusis set toon-hold.
...
When re-enabling, it should be considered what is the appropriate status of the ServiceRequest. For a triggering behavior behaviour such as activation, the ServiceRequest status should manually be set to on-hold.
...