Versions Compared

Old Version 43

changes.mady.by.user malthe lange

Saved on

compared with

New Version Current

changes.mady.by.user Erik Nielsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
languagejson
"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "dayOfWeek": [ "mon" ],
  "timeOfDay": [ "10:00:00" ],
  "boundsDuration": {
    "unit": "mo",
    "value": "2"
  }
}

Must be transformed to:

...

languagejson

...

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

TimeOfDayand 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
languagejson
"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
languagejson
"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
languagejson
"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

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

...

 "unit": "mo",
        "value": "2"
        }
      }

Must be transformed to:

Expand
title🛈 Expandable section for transformations prior release FUT-I 2024.4
Code Block
languagejson
"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "
timeOfDay
boundsPeriod":
[ "10
 {
          "start": "2023-08-28T10:00:00
" ], "boundsDuration": {
.000+02:00" <-- Starting from a Monday at 10 AM
          
"
unit
end": "
mo", 
2023-10-28T10:00:00.000+02:00" <-- ending after 2 months
"value":
"2"
  }
} }

...

}

...

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

...