Example of active overlap for ServiceRequest.occurrenceTiming with repeat.period: 6 and repeat.periodUnit: h (and repeat.duration: 3 and repeat.durationUnit: h).

As described in a row “Time Criteria” for occurrenceTiming, Timing.repeat.periodUnit h (hours) will result in a lookup period starting from Midnight 1 day ago till the current time represented as nearest past Midnight.
The resolved timing will be every 6 hours with a duration of 3 hours starting from Timing.repeat.boundsPeriod.start. With boundsPeriod.start at midnight, then the first resolved timing will be between 00 and 03, and the next will be between 06 and 09 and so on.

• When time passes 03 the first resolved timing with period 00-03 will be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest at that time all have status active.

• When time passes 09 the second resolved timing with period 06-09 will NOT be checked as the ServiceRequest has status on-hold at that time.

• When time passes 15 the third resolved timing with period 12-15 will NOT be checked as both ServiceRequest and the Careplan have status on-hold at that time.

• When time passes 21 the fourth resolved timing with period 16-19 will be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest at that time all have status active.

• etc.

See the diagram below.

When a measurement is found to be missing, the following resources are prepared for creation:

Each Communication resource prepared for creation (with the content above), is subjected to the handling of recipients described in Taking applicable CommunicationRequest into account.

Periodic Creation of Reminder on Pending Measurement Activity

To provide reminders to citizens on pending measurement activities, the eHealth Infrastructure performs periodic lookup. Currently, the periodic lookup is configured to be performed every second hour on the hour.

The periodic lookup for pending measurements considers two lookup time windows:

• The current time window:

  • Start datetime: calculated as the datetime of the next periodic lookup, reduced by the duration between lookups.

  • End datetime: calculated as the datetime of the next periodic lookup.

• The previous time window:

  • start datetime: calculated as datetime of the current periodic lookup, reduced by the duration between lookups.

  • End datetime: calculated as datetime of current periodic lookup.

For an activity to be considered pending, the ServiceRequest.occurrence[x] must be within the ServiceRequest's effective active periods. The effective active periods for a ServiceRequest are the periods where it has the status set to active at the same time as the EpisodeOfCare and CarePlan both have the status set to active, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2524872705/Using+EpisodeOfCare+CarePlan+s+and+ServiceRequest+s#Determining-the-ServiceRequest-Effective-Status. In this particular case, the effective active periods are considered for historic & current status and future status changes, that is, the effective active periods are evaluated based on the statusHistory and statusSchedule elements of EpisodeOfCare, CarePlan and ServiceRequest. This is elaborated in the criteria table below.

The criteria for a ServiceRequest to have a pending measurement within the lookup time window depends on the ServiceRequest.occurrence[x] alternative used and are as given in the table below. The table’s Time Criteria and Effect Status Criteria, respectively, are elaborated and exemplified in similarly named subsections below.

Time Criteria

The following three diagrams show 8 examples of ServiceRequest that use different variants of occurrenceDateTime/occurrencePeriod/occurrenceTiming as the periodic lookup progresses along a timeline. This helps visualize when the above-mentioned criteria are satisfied and thus, when a reminder will be automatically generated for the pending activities.

• O - Annotates a dayOfWeek/timeOfDay-combination

• X - Annotates the dateTime in an occurrenceDateTime

• Red - Annotates that the occurrence will not result in a reminder being generated in the current lookup time window.

• Green - Annotates that the occurrence will result in a reminder being generated in the current lookup time window.

Image Modified

Current Time Window = t0

• In the first diagram, the 1. ServiceRequest example is the only one to result in reminder generation

  • This is due to it being an occurrencePeriod with the start of the period being inside the previous time window.

• Some things to note about the examples that will not result in reminder generation this lookup:

  • The 2. ServiceRequest example will not result in a reminder during this lookup time window as its start is after the beginning of the current time window. However, in the next lookup, its situation should be the same as for the 1. ServiceRequest example above.

  • While 6. ServiceRequest has a boundsPeriod that starts before the current window, it is an occurrenceTiming and therefore also needs a dayOfWeek/timeOfDay-combination within the current or previous time windows to result in reminder generation. This is not the case for the current lookup time window. However, in a later lookup, it should result in a reminder when a dayOfWeek/timeOfDay-combination coincides with a "current" time window.

  • Additionally, while 7. ServiceRequest example has a dayOfWeek/timeOfDay-combination within the current time window, the boundsPeriod did not start before the current window, as is required.

Image Modified

Current Time Window = t+1

The periodic lookup has now progressed by one time frame and what was in the last lookup considered the “next” time window is now the current one.

• In this lookup, multiple occurrences result in the generation of reminders.

  • 2. ServiceRequest example is an occurrencePeriod and from the perspective of the current time window the start of the period is now in the previous time window

  • 3. ServiceRequest example is an occurrenceTiming. The boundsPeriod of the timing starts before the beginning of the current window, and additionally, there is a dayOfWeek/timeOfDay-combination within the boundsPeriod and current time window.

  • 7. The ServiceRequest example is very much like 3. ServiceRequest example, however, the dayOfWeek/timeOfDay-combination is within the previous time window.

    • When a boundsPeriod of a Timing starts in the previous time window, the dayOfWeek/timeOfDay-combinations from the previous time window will also result in reminder generation.

  • 8. The ServiceRequest example will also result in reminder generation during this lookup as it is now within the previous time window.

Image Modified

Current Time Window = t+2

The periodic lookup has now progressed by two-time frames since the lookup shown in the first diagram.

• In this lookup, multiple occurrences result in the generation of reminders.

  • 4. The ServiceRequest example will result in a reminder. When an occurrencePeriod starts and ends in the previous time window it will generate a reminder.

  • 5. The ServiceRequest example is now in the same situation as 1. ServiceRequest example and 2. ServiceRequest examples were earlier (the period starts in the previous time window and ends after the beginning of the current time window).

  • 6. The ServiceRequest example will now result in a reminder as there is a dayOfWeek/timeOfDay-combination in the current time window.

Effective Status Criteria

The following three diagrams visualize how ServiceRequest effective periods of status set to active are found and evaluated. The ServiceRequest, CarePlan and EpisodeOfCare all maintain a status history and schedule, which is used to find the active periods where all three related resources had/have status value active at the same time.

• The diagram below is an example of how the active periods are found for a resource, based on the statusHistory and a statusSchedule.

  • Marked with a vertical starting line and a following horizontal line is the period of a status (The colour depends on status: yellow=draft, green=active, orange=on-hold)

    • The dotted line represents an open-ended period (in statusHistory this means that the status is the one currently held by the resource)

  • Marked with X is the statusSchedule of the resource, marking the intended change to a given status at that time (The colour scheme is the same as for the periods).

  • The vertical grey dotted lines show the bounds of the found active periods of the resource.

Image Modified

For the above example, the active periods for the resource are found by:

• The first one is started by the ongoing active period and ended by the first scheduled on-hold status.

• The second one is entirely outlined by the statusSchedule as it starts when the status is scheduled to become active and ends at the time of the next scheduled status change, in this case to on-hold.

When the active periods for the individual related resources have been found, one can find the effective active periods of the ServiceRequest, which are the active periods that it has in common with its related CarePlan and EpisodeOfCare. This is visualized in the diagram below.

• Periods 6 and 7 are the effective active periods of the ServiceRequest - The other periods represent individual resources active periods.

  • The grey vertical dotted lines show which resource’s active period is the bounding factor for the effective active period.

    • For example: For Period 6 one can see that Period 4, the ServiceRequest active period, is much bigger than the effective active period. This is because of the late start of Period 3 in the CarePlan and the early end of Period 1 in the EpisodeOfCare, which becomes the bounding factor for the effective active period.

Image Modified

In the diagram below are 6 examples of ServiceRequest that use different variants of occurrenceDateTime/occurrencePeriod/occurrenceTiming. This helps visualize when the earlier-mentioned criteria are satisfied for both the time windows and the active periods, and thus, when a reminder will be automatically generated for the pending activities.

• The two active periods shown at the top of the time windows represent the periods where the ServiceRequest, CarePlan and EpisodeOfCare are all active and thus the time that the ServiceRequest.occurrence[x] should to some degree overlap.

Image Modified

• The ServiceRequest.occurrence[x] examples marked green are the ones that will result in reminder generation. (Note: All examples adhere to the given time window criteria for reminder generation)

  • The occurrenceDateTime in example 1 will NOT result in a reminder as it is not within an active period, even though it is in the previous time window.

  • In example 2 on the other hand the occurrenceDateTime upholds both being within an active period and being in the previous time window and will therefore result in a reminder.

  • The occurrencePeriod in example 3 will NOT result in reminder generation as it does not overlap any active period.

  • The occurrencePeriod in example 4 overlaps with an active period. Therefore, even though the active period is after the current lookup time window, it results in a reminder being generated.

  • For occurrenceTiming it is the dayOfWeek/timeOfDay-combinations that should be in an active period. For that reason, example 5 will NOT result in reminder generation.

  • Lastly, in example 6 the occurrenceTiming has a dayOfWeek/timeOfDay-combination within an active period, which results in reminder generation.

Having identified a pending measurement, the infrastructure creates an ehealth-message type Communication with the Patient as the recipient, unless such creation has been suppressed (see Controlling Creation of Messages).

When possible, the created Communication leads to a NemSMS text notification to the Citizen. A prerequisite to this is that the citizen has subscribed to NemSMS and that the citizen has not suppressed the generation of such messages (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-Patient-as-Recipient).

Validation of SSL orders when activating a CarePlan

When a CarePlan changes status to active, the infrastructure checks if any related SSL orders are still undelivered. If this is the case, then the Patient may still be missing the necessary equipment. The infrastructure creates a task with the category: OpenSSLOrder for the CareTeam to check if any equipment is missing and if necessary delay the activation of the CarePlan or adjust the measurement regime for specific measurements.

Scheduled Automated Application of Planned Changes (EpisodeOfCare, CarePlan and ServiceRequest)

Scheduled changes in EpisodeOfCare, CarePlan and ServiceRequest are applied during an automatic job which runs at regular intervals.

• Upon job execution, the job finds all ServiceRequest, CarePlan and EpisodesOfCare that have unhandled statusSchedule or teamSchedule entries planned for a timestamp between this execution and the previous one.

• The scheduled changes are then applied to the resources so that they are up to date with their latest scheduled change.

Scheduled Import of Organization Data from SOR and FK Organisation

The eHealth Infrastructure runs scheduled jobs that Import Organization Data from SOR and FK Organisation.

The import of Organization data is described in Importing and updating Organization information from SOR and FK-Organisation into eHealth Infrastructure.

Scheduled Check for Calibration of Equipment

Some equipment needs to be periodically calibrated to ensure precise measurements.
The eHealth Infrastructure runs a periodic job that checks if any devices require calibration. If that is the case then the Infrastructure created a Task with a category set to CalibrationNeeded. The Task is assigned to the CareTeam(s) for the CarePlan that currently uses the Device.

Handling of EpisodeOfCare and CarePlan Created

When an EpisodeOfCare is created with $create-episode-of-care, two ehealth-message types of Communication are automatically created. These correspond to the Communication created for the change of EpisodeOfCare status and team, respectively.

When a CarePlan is created with $apply performed on a PlanDefinition, two ehealth-message types of Communication are automatically created. These correspond to the Communication created for the change of CarePlan status and team, respectively. Such a pair of Communication is created for each sub-CarePlan.

Handling of Change of EpisodeOfCare and CarePlan Status, CareTeam, Scheduled Status and/or Scheduled CareTeam

The EpisodeOfCare and CarePlan have two elements ehealth-episodeofcare-statusscheduleand ehealth-teamschedule which capture:

• planned changes in EpisodeOfCare.status and EpisodeOfCare.team

• planned changes in CarePlan.status and CarePlan.careTeam

When one of the following elements in CarePlan/EpisodeOfCare is changed, then an ehealth-message type Communication is automatically created.

• status

• team

• ehealth-episodeofcare-statusschedule

• health-teamschedule

Communication created with the Patient as the recipient

Communication created with CareTeam as the recipient

Reminder for Participation in Appointment

Communication with the Patient as the recipient

Also see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-Patient-as-Recipient.

Communication with CareTeam as the recipient

Also see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-CareTeam-as-Recipient.

Handling of Automatic NemSMS Notification on Creation of Communication of Type message

Communication with the Patient as the recipient

Also see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-Patient-as-Recipient.

Resources Created by Automated Processing in the Infrastructure

The Infrastructure automatically creates Task resources for profile ehealth-task and Communication resources for profile ehealth-message in different situations. An overview is provided for each resource type in the following.

Overview of Task Created by the Infrastructure

The following table provides an overview of Tasks produced by the Infrastructure. For more detailed information follow the link in the reference column.

Overview of Communication Created by the Infrastructure

The following table provides an overview of Communication (of profile ehealth-message) produced by the Infrastructure and how creation and suppression of creation can be controlled with CommunicationRequest.

The table does not provide all elements of either Communication or CommunicationRequest. Please consult particular sections corresponding to the situations for details. Element <some element name> describes what values are used in Communication in a specific situation.