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:

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

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)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": 3,
        "periodUnit": "d",
        "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": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "

timeOfDay

boundsPeriod":

[ "10:00:00" ],

{
          "start": "

boundsDuration": {

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

"unit":

"mo",

value

end": "

2

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

...

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 42

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

Page Comparison

Versions Compared

Old Version 42

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

For periodUnit `wk` (weekly)

For periodUnit other than `wk` (weekly)