Page Comparison

...

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)

...

Note
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`.

Expand

title	🛈 Expandable section for status change requirements prior release FUT-I 2024.4

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.

...

Expand

title	🛈 Expandable section for status change requirements after release FUT-I 2024.4

A valid occurrence, with 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.

...

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

...

- start

See validation requirements applied to ServiceRequest.occurrence[x] on https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-servicerequest.html

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` (weekly)

...

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

Code Block

language	json

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

Must be transformed to:

...

language	json

...

periodUnit is wk (Week), apart from ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start being mandatory, the following changes are required for the expression to be resolvable by the infrastructure:

Expand

title	🛈 Expandable section for changes of Timing prior release FUT-I 2024.4

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

...

Expand

title	🛈 Expandable section for changes of Timing after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

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

Info
`TimeOfDay`and `DayOfWeek` do not need to align with `BoundsPeriod.start`, as Infrastructure will handle the timing adjustments accordingly.

Example

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

Code Block

language	json

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

Must be transformed to:

Expand

title	🛈 Expandable section for transformations prior release FUT-I 2024.4

Code Block

language	json

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

...

Expand

title	🛈 Expandable section for transformations after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

Code Block

language	json

"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "dayOfWeek": [ "mon" ],
  "timeOfDay": [ "10:00:00" ],
  "boundsPeriod": {
    "start": "2023-09-01T08:00:00.000+02:00" <-- always required, can occur on any day of the week at any time of day
    "end": "2023-11-01T08:00:00.000+02:00" <-- ending after 2 months
  }
}

For periodUnit other than `wk` (weekly)

...

Expand

title	🛈 Expandable section for changes of Timing prior release FUT-I 2024.4

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

...

Expand

title	🛈 Expandable section for changes of Timing after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

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

Info
`TimeOfDay`and `DayOfWeek` do not need to align with `BoundsPeriod.start`, as Infrastructure will handle the timing adjustments accordingly.

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

Code Block

language	json

"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 2,3,
        "periodUnit": "wkd",
  "boundsPeriod": {     "starttimeOfDay": "2023-09-04T10[ "10:00:00.000+02:00" <-- Starting from a Monday at 10 AM" ],
        "boundsDuration": {
        "unit": "mo",
        "endvalue": "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

...

2"
        }
      }

Must be transformed to:

Expand

title	🛈 Expandable section for transformations prior release FUT-I 2024.4

Code Block

language	json

"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "

timeOfDay

boundsPeriod":

[ "10:00:00" ],

{
          "

boundsDuration

start":

{ "unit": "mo",

"2023-08-28T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM

"value": "2"

"end": "2023-10-28T10:00:00.000+02:00" <-- ending after 2 months

}

}
}

...

Expand

title	🛈 Expandable section for transformations after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

Code Block

language	json

"repeat": {

"duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "timeOfDay": [ "10:00:00" ],
        "boundsPeriod": {
          "start": "2023-08-

28T10

28T06:00:00.000+02:00" <--

Starting from a Monday at 10 AM

 always required, can occur on any day of the week at any time of day
          "end": "2023-10-

28T10

28T06:00:00.000+02:00" <-- ending after 2 months
        }
}

Managing offering ServiceRequest as extra activities

The extension includeAsExtra on ServiceRequest, is used to determine whether the ServiceRequest should be provided as an extra activity in the $get-patient-procedures result. The value for includeAsExtra is copied from the corresponding PlanDefinition.action during creation of the ServiceRequest ($apply operation), and the value can be updated on any individual ServiceRequest.

The value for includeAsExtra can be set through the TimingPicker. The default value for includeAsExtra is false when not scheduled or adhoc, and true when a schedule has been configured.

...

Maintaining ServiceRequest Status

...

Note

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-releasedfhir/ig/CodeSystem-ehealth-action-type.html ).

Note

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 the device (found by doing a ServiceRequest Search reverse include “CarePlan:activity-reference” (see https://docs.ehealth.sundhed.dk/latest-released/igfhir/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)

...

Versions Compared

Old Version 41

New Version Current

Key

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

For periodUnit: WK and period greater than 1.

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

For periodUnit `wk` (weekly)

For periodUnit other than `wk` (weekly)

For periodUnit: other than WK(weekly)

Managing offering ServiceRequest as extra activities

Maintaining ServiceRequest Status

Page Comparison

Versions Compared

Old Version 41

New Version Current

Key

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

For periodUnit: WK and period greater than 1.

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

For periodUnit wk (weekly)

For periodUnit other than wk (weekly)

For periodUnit: other than WK(weekly)

Managing offering ServiceRequest as extra activities

Maintaining ServiceRequest Status

For periodUnit `wk` (weekly)

For periodUnit other than `wk` (weekly)