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.

...

  • occurrenceDateTime: An activity that takes place once on a specified date and time.

  • occurencePeriodoccurrencePeriod: An activity that takes place once in a specified period.

  • occurenceTimingoccurrenceTiming: This is for ad-hoc and recurring activities . For example, a measurement should be performed each Monday at 10:00.

Apart from constraints in place for Timing (see https://hl7.org/fhir/R4/datatypes.html#timing ), the eHealth Infrastructure does not enforce how elements of Timing can be used and combined. However, there is a recommended subset that the infrastructure understands and can help Patients and Clinicians to follow with reminders, alarms and an overview of expected and received measurements.

This spreadsheet contains examples of the timing subset that is supported by the infrastructure.

View file
nameTiming Examples.xlsx

All recurring regimes must have a Timing.repeat.boundsPeriod specifying the period where the regime is active, if the eHealth Infrastructure should be able to assist with compliance to the Timing.

A recurring regime can be resolved to several specific times when the activity should be performed. Each of these is referred to as a resolved timing.

Week-based measurement regimes

This type of regime is recommended for any activity that happens at least once pr. week.

Examples:

  • Every day between 08:00 - 10:00

  • Each Monday and Thursday at 08:00 and 17:00

Week-based measurement regimes consist of a combination of dayOfWeek, timeOfDay, duration, and frequency:

  • timeOfDay is optional. If it is not specified then the time component of boundPeriod.start is used instead.

  • duration is optional. If not specified then the regime expects activities to be performed at a specific time. 

  • frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.

Frequency-based measurement regimes

This type of regime is recommended for activities that happen less frequently than once per week. It can be used to specify more frequent activities, but it is recommended to use the week-based regimes instead in these cases.

Examples:

  • Once every 2 weeks

  • Once every 10 days

Frequency-based measurement regimes consist of: frequency, period, periodUnit, boundsperiod.start, duration.

  • period, periodUnit is mandatory and specifies the period between each resolved timing.

  • frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.

Each resolved timing will match the pattern: boundsperiod.start + n * period * periodUnit

There are some pitfalls to be aware of for the frequency-based measurement regime. Especially if the periodUnit is specified in days or hours.

  • The boundsPeriod.start determines the starting point. This can make it complex to calculate the exact resolved timing. Example: “Every 10 days counting from January 1st 2020” Should I do this activity on April 27th 2021?

  • If the periodUnit is specified in days, each resolved timing will fall on different week-days unless the period is a multiple of 7

  • If the periodUnit is specified in hours, each resolved timing will fall on different times unless the period is a divisor or multiple of 24

  • If the periodUnit is specified in hours, then timezone and/or summertime may affect the resolved timings.

Example Timing and Resolved Timing

“Once every Monday between 10-12 starting January 1st 2020” can be expressed with the following values in a Timing structure in occurenceTiming:

  • repeat.boundsPeriod.start: 1 January 2020, 08:30:00 CET

  • repeat.duration:2

  • repeat.durationUnit:h

  • repeat.frequency:1

  • repeat.dayOfWeek:mon

  • repeat.timeOfDay:10:00:00

In a given time period, this recurring regime will result in several resolved timings. For example, looking at April 2021 this will result in four resolved timings

...

  • , respectively.

    • Ad-hoc -with accepted elements: Timing.repeat.count,Timing.repeat.countMax, Timing.repeat.frequency

    • Recurring event - with accepted elements: Timing.repeat.period, Timing.repeat.periodUnit, Timing.repeat.duration, Timing.repeat.durationUnit,Timing.repeat.dayOfWeek, Timing.repeat.timeOfDay

When an activity is supposed to happen varies also:

  • occurrenceDateTime: Once, on the specified date and time.

  • occurrencePeriod: Once, at some time between occurrencePeriod.start and, if specified, occurrencePeriod.end.

  • occurrenceTiming (when specifying ad-hoc): Once or occurrenceTiming.repeat.count at some time between occurrenceTiming.repeat.boundsPeriod.start and, if specified, occurrenceTiming.repeat.boundsPeriod.end.

  • occurrenceTiming (when specifying an recurring event): This depends on the Timing construct and is the scope for the description below.

Resolved timing in a recurring event Timing construct

The Timing construct can be resolved to several specific times, each referred to as a resolved timing.

The elements of Timing can be combined to represent activities that occur more frequently (such as every n minutes, every n hours, every n days or weekly) or less frequently (every n weeks, every n months, or every n years). For example:

  • Every 45 minutes

  • Every 8 hours

  • Every day between 08:00 - 10:00

  • Every day at 08:00, for a month

  • Each Monday and Thursday at 08:00 and 17:00

  • Every other Tuesday between 10:00-18:00

  • Every three weeks Monday and Tuesday at 00:00

  • Every 10 days

  • Each month, over the course of a year

Expand
title🛈 Expandable section with Timing categories (Week-based and Frequency-based) prior release FUT-I 2024.4

Week-based measurement regimes

This type of regime is recommended for any activity that happens at least once pr. week.

Examples:

  • Every day between 08:00 - 10:00

  • Each Monday and Thursday at 08:00 and 17:00

Week-based measurement regimes consist of a combination of dayOfWeek, timeOfDay, duration, and frequency:

  • timeOfDay is optional. If it is not specified then the time component of boundsPeriod.start is used instead.

  • duration is optional. If not specified then the regime expects activities to be performed at a specific time. 

  • frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.

Frequency-based measurement regimes

This type of regime is recommended for activities that happen less frequently than once per week. It can be used to specify more frequent activities, but it is recommended to use the week-based regimes instead in these cases.

Examples:

  • Once every 2 weeks

  • Once every 10 days

Frequency-based measurement regimes consist of: frequency, period, periodUnit, boundsperiod.start, duration.

  • period, periodUnit is mandatory and specifies the period between each resolved timing.

  • frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.

Each resolved timing will match the pattern: boundsPeriod.start + n * period * periodUnit

There are some pitfalls to be aware of for the frequency-based measurement regime. Especially if the periodUnit is specified in days or hours.

  • The boundsPeriod.start determines the starting point. This can make it complex to calculate the exact resolved timing. Example: “Every 10 days counting from January 1st 2020” Should I do this activity on April 27th 2021?

  • If the periodUnit is specified in days, each resolved timing will fall on different week-days unless the period is a multiple of 7

  • If the periodUnit is specified in hours, each resolved timing will fall on different times unless the period is a divisor or multiple of 24

  • If the periodUnit is specified in hours, then timezone and/or summertime may affect the resolved timings.

Timing expressions supported by the eHealth Infrastructure

The Timing construct allows for a number of complex expressions. In order to simplify, the eHealth infrastructure supports a subset described in the following. This subset is handled in the infrastructures ability to help Patients and Clinicians to follow measurement regimes with reminders, tasks on missing measurements, and when providing an overview of expected and received measurements (see get-patient-procedures further below).

Expand
title🛈 Expandable with intro prior to release FUT-I 2024.4

Apart from constraints in place for Timing (see https://hl7.org/fhir/R4/datatypes.html#timing ) and table below (see Timing constraints ), the eHealth Infrastructure does not enforce how elements of Timing can be used and combined.

Expand
title🛈 Expandable with intro after release FUT-I 2024.4

The infrastructure enforces what Timing expressions are accepted in ServiceRequest.occurrenceTiming, when a ServiceRequest and its CarePlan are in certain states.

See https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-servicerequest.html for details.

The spreadsheet shown below contains examples of the Timing subset that is supported by the infrastructure.

Expand
title🛈 Expandable section with spreadsheet of Timing expressions prior release FUT-I 2024.4

View file
nameTiming Examples prior release 2024.4.xlsx

...

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

View file
nameTiming Examples.xlsx

Expand
title🛈 Expandable section with Timing constraints prior release FUT-I 2024.4

Timing constraints

The following table contains validations for Timing for recurring events:

Timing.repeat Element

Validation

Is mandatory

boundsPeriod.start

(tick)

boundsPeriod.end

frequency

(tick)

dayOfWeek

  • One or multiple day of weeks are allowed (mon|tue|wed|thu|fri|sat|sun)

  • Can be combined only with period1 d or no period specified

  • For period greater than 2 wk, dayOfWeek should be left empty and boundPeriod.start aligned to the specific dayOfWeek

  • If it is not specified, the day of week ofboundPeriod.startis used instead

timeOfDay

  • One or multiple timeOfDayare allowed

  • Can be combined with period 1 d or no period specified, for other types of period, timeOfDayshould boundPeriod.start aligned to the specific timeOfDay

  • If no timeOfDayis specified, the time fromboundsPeriod.startwill be used by default.

duration

  • When both are left empty, then the regime expects activities to be performed at a specific time

  • The allowed values for durationUnitare: s (seconds), min (minutes), h (hours), d (days), wk (weeks), mo (months), and a (years)

durationUnit

period

  • When both are left empty, the the activity is assumed to occur daily (1 d) and is filtered by the specified dayOfWeek, if provided

  • The periodUnitcan be specified in s (Seconds), min (minutes), h (hours), d (days), wk (weeks), mo (months), and a (years)

  • If timeOfDaypresent, period and periodUnit can be left empty or set to 1 d

  • If dayOfWeekpresent, periodand periodUnitcan be left empty or set to 1 d

periodUnit

...

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

Timing constraints

The following table contains validations for Timing for recurring events:

Timing.repeat Element

Validation

Is mandatory

boundsPeriod.start

(tick)

boundsPeriod.end

  • If present, must be equal to or afterboundsPeriod.start.

frequency

(tick)

dayOfWeek

  • One or multiple day of weeks are allowed (mon|tue|wed|thu|fri|sat|sun)

  • If multiple days of the week are specified, it is recommended that theboundsPeriod.start occurs on a day and time earlier than all the provided dayOfWeekand timeOfDayvalues. Otherwise, the calculated timings may end up in different weeks in some cases (depending on the period, such as every 2 weeks).

  • Can be combined with period such as 1 d, n wk (where n is a positive integer ) or no period specified

  • If it is not specified, then the day of week ofboundPeriod.startis used instead

timeOfDay

  • One or multiple timeOfDayare allowed

  • If multiple times of day are provided, it is recommended that the time part of boundsPeriod.startoccurs earlier than all the specified timeOfDayvalues. Otherwise, the resolved timings may fall on different days in certain cases (depending on the period, such as every 2 days).

  • Can be combined with period such as 1 d, n wk, n mo, n a (where n is a positive integer) or no period specified

  • If no timeOfDay is specified, the time fromboundsPeriod.startwill be used by default.

duration

  • If present, durationmust be a positive integer

  • When both are left empty, then the regime expects activities to be performed at a specific time

  • Both should be set, or neither should be

  • The allowed values for durationUnitare: s (seconds), min (minutes), h (hours), d (days), wk (weeks), mo (months), and a (years)

durationUnit

period

  • If present, period must be a positive integer integer

  • Both should be set, or neither should be

  • When both are left empty, the action is assumed to occur daily (1 d) and is filtered by the specified dayOfWeek, if provided

  • The periodUnitcannot be specified in seconds; the allowed values are: min (minutes), h (hours), d (days), wk (weeks), mo (months), and a (years)

  • If timeOfDayispresent, periodand periodUnitcan be left empty or set to n d, n wk, n mo, n a (where n is a positive integer)

  • If dayOfWeek ispresent, periodand periodUnit can be: left empty or set to 1 d or n wk (where n is a positive integer)

periodUnit

Unresolved timings

The Infrastructure will not resolve Timing for recurring events containing the following elements:

  • frequencyMax

  • count (except for Ad-Hoc timings)

  • countMax (except for Ad-Hoc timings)

  • durationMax

  • periodMax

  • when

  • offset

Example Timing and Resolved Timing

“Once every Monday between 10-12 starting April 1st 2021” can be expressed with the following values in a Timing structure in occurenceTiming:

  • repeat.boundsPeriod.start: 1 April 2021, 08:30:00 CET (Thursday)

  • repeat.duration: 2

  • repeat.durationUnit: h

  • repeat.frequency: 1

  • repeat.dayOfWeek: mon

  • repeat.timeOfDay: 10:00:00

  • repeat.period: 1

  • repeat.periodUnit: d

In a given time period, this recurring regime will result in several resolved timings. For example, looking at April 2021 this will result in four resolved timings

...

Expand
title🛈 Expandable section with resolved timings for Timing having timeOfDay, dayOfWeek, boundsPeriod.end and period 2 W, introduced after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

“Once every Monday between 10-12 starting April 1st 2021, ending on May 6th 2021” can be expressed with the following values in a Timing structure in occurenceTiming:

  • repeat.boundsPeriod.start: 1 April 2021, 08:30:00 CET (Thursday)

  • repeat.boundsPeriod.end: 6 May 2021, 08:30:00 CET

  • repeat.duration: 2

  • repeat.durationUnit: h

  • repeat.frequency: 1

  • repeat.dayOfWeek: mon

  • repeat.timeOfDay: 10:00:00

  • repeat.period: 2

  • repeat.periodUnit: wk

The first resolved timing is not in the current week (March 29th - April 4th) because March 29th occurs before boundsPeriod.start. Therefore, the next Monday falls within boundsPeriod.

image-20241021-143944.pngImage Added

Expand
title🛈 Expandable section with resolved timings for Timing having multiple day of weeks, introduced after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

“Once every Monday and Thursday between 10-12 starting April 5th 2021, until April 25th 2021” can be expressed with the following values in a Timing structure in occurenceTiming:

  • repeat.boundsPeriod.start: 5 April 2021, 18:00:00 CET (Monday)

  • repeat.boundsPeriod.end: 25 April 2021, 11:00:00 CET (Sunday)

  • repeat.duration: 2

  • repeat.durationUnit: h

  • repeat.frequency: 1

  • repeat.dayOfWeek: mon, thu

  • repeat.timeOfDay: 10:00:00

  • repeat.period: 1

  • repeat.periodUnit: d

If multiple days of the week are specified, the first resolved timing will occur on any day from those specified that falls within or overlaps with the boundsPeriod. In this case, the first resolved timing is on a Thursday and not on a Monday.

image-20241021-144538.pngImage Added

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

Overlapping resolved timings

Timing occurrences that overlap with the boundsPeriod, such as those starting before boundsPeriod.start and ending within the boundsPeriod, or starting within the boundsPeriod, but ending after boundsPeriod.end, are included after being adjusted to fit within the boundsPeriod.

For example:

“Once every Monday between 10-12 starting April 5th 2021, until April 26th 2021” can be expressed with the following values in a Timing structure in occurenceTiming:

  • repeat.boundsPeriod.start: 5 April 2021, 11:00:00 CET

  • repeat.boundsPeriod.end: 26 April 2021, 11:00:00 CET

  • repeat.duration:2

  • repeat.durationUnit:h

  • repeat.frequency:1

  • repeat.dayOfWeek:mon

  • repeat.timeOfDay:10:00:00

Resolved timings are:

Monday 5 April, 2021 11:00 (adjusted toTiming.repeat.boundsPeriod.start) – Monday 5 April, 2021 12:00 CEST
Monday 12 April, 2021 10:00 – Monday 12 April, 2021 12:00 CEST
Monday 19 April, 2021 10:00 – Monday 19 April, 2021 12:00 CEST
Monday 26 April, 2021 10:00 – Monday 26 April 2021 11:00 CEST (adjusted to Timing.repeat.boundsPeriod.end)

image-20241021-144634.pngImage Added

Getting an Overview with get-patient-procedures

...