...
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 | ||
|---|---|---|
|
All recurring regimes should have a Timing.repeat.boundsPeriod specifying the period where the regime is active.
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 CETrepeat.duration:2repeat.durationUnit:hrepeat.frequency:1repeat.dayOfWeek:monrepeat.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.frequencyRecurring 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 betweenoccurrencePeriod.startand, if specified,occurrencePeriod.end.occurrenceTiming(when specifying ad-hoc): Once oroccurrenceTiming.repeat.countat some time betweenoccurrenceTiming.repeat.boundsPeriod.startand, 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 | ||
|---|---|---|
| ||
Week-based measurement regimesThis type of regime is recommended for any activity that happens at least once pr. week. Examples:
Week-based measurement regimes consist of a combination of
Frequency-based measurement regimesThis 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:
Frequency-based measurement regimes consist of:
Each resolved timing will match the pattern: There are some pitfalls to be aware of for the frequency-based measurement regime. Especially if the
|
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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
The infrastructure enforces what Timing expressions are accepted in 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 | ||||
|---|---|---|---|---|
| ||||
|
...
| Expand | ||||
|---|---|---|---|---|
| ||||
|
| Expand | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
Timing constraintsThe following table contains validations for Timing for recurring events:
|
...
| Expand | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
Timing constraintsThe following table contains validations for Timing for recurring events:
Unresolved timingsThe Infrastructure will not resolve Timing for recurring events containing the following elements:
|
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:2repeat.durationUnit:hrepeat.frequency:1repeat.dayOfWeek:monrepeat.timeOfDay:10:00:00repeat.period:1repeat.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 | ||
|---|---|---|
| ||
“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
The first resolved timing is not in the current week (March 29th - April 4th) because March 29th occurs before  |
| Expand | ||
|---|---|---|
| ||
“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
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  |
| Expand | ||
|---|---|---|
| ||
Overlapping resolved timingsTiming occurrences that overlap with the 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
Resolved timings are: Monday 5 April, 2021 11:00 (adjusted to
|
Getting an Overview with get-patient-procedures
With the operation get-patient-procedures, a user can retrieve an overview of what measurements a Patient has submitted, was supposed to submit, and is expected to submit for a given period of time.
| Info |
|---|
See get-patient-procedures for introduction to use, input parameters and output. |
...
The output contains rows (encoded in parameters) for each matching (see get-patient-procedures) and active ServiceRequest with resolved timings overlapping with the requested period.
...
| Expand | ||
|---|---|---|
| ||
Usage example of $get-patient-proceduresGet patient procedure is a POST request to the following URL where “base“ is the environment base-url:
Example: https://docs.ehealth.sundhed.dk/latest-released/igfhir/POST_get-patient-procedures.html |
Preparing and Submitting Measurements
...