Overview of Automated Processing in the Infrastructure

This section provides an overview of automated processing in the Infrastructure. The details of the automated processing are described below. The automated processing is either triggered by some event or actions in the Infrastructure, to timer based meaning the processing takes place at certain intervals.

Scheduled processing

Automated processing of …	*Schedule )**	More info …
Create reminders on pending measurement activity	Every other hour that is 0.00, 2.00, 4.00 … on all environments	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-AutomatedCreationofReminderonPendingMeasurementActivity
Apply planned changes	0.05 every night in all environments	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-AutomatedApplicationofPlannedChanges(EpisodeOfCare,CarePlanandServiceRequest)
Import organization information from Sundhedsvæsnets Organisationsregister (SOR)	22.00 every evening in all environments	Importing and updating Organization information from SOR and FK-Organisation into eHealth Infrastructure
Import organisation data from FK Organisation	0.00 every night in all environments	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-ImportingofOrganizationData
Check for calibration of equipment	0.30 every night all environments	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-CheckforCalibrationofEquipment
Creating reminders for Participation in Appointment	Every other hour that is 0.00, 2.00, 4.00 … on all environments	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-ReminderforParticipationinAppointment

note

*) When there is a timezone change (to daylight saving time, DST), the execution is still at local Danish time.

*) When there is a timezone change (to daylight saving time, DST), the execution is still at local Danish time.

Event-based processing

Automated processing of …	Triggering event	More info …
Library rule evaluation for submitted measurements	Measurement submitted	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-AutomatedProcessingofSubmittedMeasurement
Check if the measurement submitted at an unexpected time.
Check and handling of measurements to be automatically approved for document sharing		https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140/Automated+Processing#AutomatedProcessing-AutomatedApprovalofDocumentSharing
Validation of SSL orders	CarePlan activated	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-ValidationofSSLorderswhenactivatingaCarePlan
Handling of creation of EpisodeOfCare and CarePlan	EpisodeOfCare and CarePlan created	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-HandlingofEpisodeOfCareandCarePlanCreated
Handling of change of EpisodeOfCare status, CareTeam, scheduled status and/or scheduled CareTeam	EpisodeOfCare status, CareTeam, scheduled status and/or scheduled CareTeam changed	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-HandlingofChangeofEpisodeOfCareandCarePlanStatus,CareTeam,ScheduledStatusand/orScheduledCareTeam
Handling of Change of CarePlan status, CareTeam, scheduled status and/or scheduled CareTeam	CarePlan status, CareTeam, scheduled status and/or scheduled CareTeam changed
Handling of Automatic NemSMS Notification		https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-HandlingofAutomaticNemSMSNotificationonCreationofCommunicationofTypemessage
Create Tasks and Reminders when a citizen has not submitted measurement within time.	Resolved timings for effectively active ServiceRequests are continuously monitored. The event that triggers the creation of Tasks and Reminders are the passing of the end time of resolved timings.	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-AutomatedProcessingofMissingMeasurements

With release 2024.2, the check for missing measurements is changed to be event driven (passing end time of occurrences). Previously, the check was scheduled to check for missing measurements for a time interval. The event driven check will cause Tasks and Communications to be created immediately (or within a few minutes) after the end time of an occurrence timing has passed.

Automated Processing of Submitted Measurement

The Clinical Administrator can set up a PlanDefinition, which includes activities defined in an ActivityDefinition. They can also include a Questionnaire to be answered, and add one or more Library resources, each containing a rule. Their Libraries are specifically for automated processing and are linked to a plan that has received a measurement.

In the following, a measurement resource denotes an Observation, QuestionnaireResponse or Media which has been submitted either by itself or along with other measurement resources in a call of the submit-measurement operation. All the measurement resource(s) submitted together are denoted as measurement.

Overall, the automated processing of a submitted measurement is asynchronous and constitutes the following handling as a response to a submitted measurement event (which contains a reference to a Provenance resource referencing the measurement resources):

Before release 2024.1

For each measurement resource in the order Observation, QuestionnaireResponse and Media resources in the measurement:
1. The timing of the measurement resource is examined to see if was submitted timely, as described in Automated Processing of Measurements Submitted at Unexpected Time.
2. The automated processing rule(s) are evaluated, as described in Automated Processing of Library Rules

With release 2024.1

For each measurement resource in the order Observation, QuestionnaireResponse and Media resources in the measurement:
1. For Observations and QuestionnaireResponses an approval of document sharing is automatically generated if the ServiceRequest.sharingApprovalPolicy is set to automatic.
2. The timing of the measurement resource is examined to see if was submitted timely, as described in Automated Processing of Measurements Submitted at Unexpected Time.
3. The automated processing rule(s) are evaluated, as described in Automated Processing of Library Rules

The automated processing of submitted measurements is shown in the sequence diagram Automated Processing of Measurements.

Automated Approval of Measurement for Document Sharing

See Sharing through Registering Documents in National Document Sharing Infrastructure.

Approval of document sharing a measurement, that is, registering a measurement in national document sharing infrastructure, is considered an assessment of the measurement and comes in the form of a ClinicalImpression resource.

Whether a measurement is eligible for automated approval is evaluated by using the ServiceRequest referenced by the measurement. If the ServiceRequest.sharingApprovalPolicy is set to automatic at the time of processing, an approval for document sharing is automatically created by the infrastructure with contents as described in the table below.

ClinicalImpression Element	Value
`.decision`	Coding with `code`=`approved-for-sharing` and `system` = `http://ehealth.sundhed.dk/cs/clinicalimpression-decision-codes`
`.code`	Coding with `code`=`MeasurementAssessment` and `system` = `http://ehealth.sundhed.dk/cs/clinicalimpression-codes`
`.status`	`completed`
`.carePlan`	References the CarePlan that has the ServiceRequest as an action.
`.episodeOfCare`	References the EpisodeOfCare from `CarePlan.episodeOfCare`
`.assessor`	Not set. For manual approvals the assessor would be the practitioner performing the approval, however, for automatic approval, there is no assessor.
`.assessorOrganization`	The organization from `CarePlan.author` is used if present. Otherwise the `EpisodeOfCare.careManagerOrganization` is used.
`.investigation`	Is set to contain a versioned and a versionless reference for the measurement in question, as described in Assessing Measurements.

Automated Processing of Measurements Submitted at Unexpected Time

The Infrastructure validates the measurement time of a submitted measurement for compliance with the resolvedTiming period provided in the measurement.

An unexpected measurement is determined as a submitted measurement having either:

Measurement time outside of the resolvedTiming period.
Measurement time within the resolvedTiming period but, in case of the measurement being associated with a ServiceRequest defined with occurrenceTiming, the measurement time is not within the repeat.boundsPeriod of the occurrenceTiming.

Measurement time is captured in:

Observation.effectiveDateTime or Observation.effectiveInstant
Questionnaire.authored
Media.createdDateTime

In case a measurement has been submitted at an unexpected time, automated processing produces:

A Task with
- .status set to requested
- .episodeOfCare set to the same reference to EpisodeOfCare as used in the measurement resource’s .episodeOfCare
- .category set to UnexpectedMeasurementResolving
- .focus.reference referencing the measurement resource (Observation, QuestionnaireResponse, or Media)
- .ehealth-task-responsible set to the same one or more CareTeams as the CarePlan.team (CarePlan found through reverse association from measurement resources .basedOn reference to ServiceRequest referred from CarePlan.activity.reference)
- .description set to “Uventet måling” which is Danish for unexpected measurement
- .for set to the patient referenced in the EpisodeOfCare
Communication (of the ehealth-message profile) with
- .status set to completed
- .subject set to the same reference to Patient as used in the measurement resource’s .subject
- .episodeOfCare set to the same reference to EpisodeOfCare as used in the measurement resource’s .episodeOfCare
- .category set to notification
- .reasonCode set to UnexpectedMeasurementResolving
- .topic.reference referencing the Task above
- .payload.episodeOfCare set to “Uventet måling” which is Danish for unexpected measurement
- .title set to “Uventet måling”
- .sender referencing a special Device designating the automated processing service

Note that most of the above details do not constitute guaranteed content that can be used for searching for or determining whether unexpected measurement(s) has been submitted for a particular Patient. The guaranteed elements are Tasks.category (withTask.episodeOfCare) and Communication.reasonCode (with Communication.subject and Communication.episodeOfCare).

Automated Processing of Library Rules

When a measurement is submitted to the infrastructure, it triggers the automated processing of rules described in the following. Each submitted measurement is related to an activity in a citizen plan represented as a CarePlan where each activity is a ServiceRequest. Which rule or rules are involved depends on the PlanDefinition and its comprised ActivityDefinition resources referenced from the CarePlan and ServiceRequest resources, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Applying-a-PlanDefinition-to-create-CarePlan(s).

The Library rules eligible for automated processing for a particular ServiceRequest are:

Library resources where the Library.type is automated-processing.
Library resources (zero, one, or more) related to the ActivityDefinition referenced by the ServiceRequest

The existing Library resources are listed in Library Resources.

In the Plan editor of the Clinical Administration Application (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2063892483/eHealth+Applications#Clinical-Administration-Application-(Danish%3A-KAM-for-Klinisk-administrativ-modul)), it is possible to select which automated processing rule Library resources if any that shall be related to a plan template activity (ActivityDefinition).

Situation	Overrides Eligible Library?	Automated Processing Rules	Processing
Submitted measurement is an Observation with no value (`.dataAbsentReason` is present) ServiceRequest references ActivityDefinition with no reference to Library or reference to any other than Null-rule Library	Yes	All Library are ignored and processing is performed as described	A Task is created with the `Task.category` set to Coding `MeasurementForAssessmentAbsentValue`
Submitted measurement is an Observation with no value (`.dataAbsentReason` is present) ServiceRequest references ActivityDefinition concerning Null-rule Library	No	Null-rule Library is evaluated and processing is performed as described	No Task is created.
ServiceRequest references ActivityDefinition concerning Null-rule Library	No		No Task is created.
ServiceRequest references ActivityDefinition with no Library references	Yes	The Fallback Library is evaluated and processing is performed as described	A Task is created with the `Task.category` set to Coding `MeasurementForAssessment`
ServiceRequest references ActivityDefinition concerning Fallback Library	No
ServiceRequest references ActivityDefinition concerning one or more other Library	No	Each Library is evaluated	Depends on the Library.

One (or at least one) of the automated-processing type Library resources associated with an ActivityDefinition should create a Task that can draw adequate attention to a submitted and automatically processed measurement. The Null-rule Library is the one exception to this guideline/recommendation.

The evaluation of automated-processing type Library resources is described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2727247913/Managing+and+Using+Library+Rules#Library-Rule-Evaluation-in-Automated-Processing-in-the-Infrastructure .

Automated Processing of Action Triggers and Trigger Conditions

Each submitted measurement references a ServiceRequest. As part of the automated processing of a submitted measurement, the infrastructure examines whether the measurement constitutes fulfilment of trigger conditions that may be defined as action trigger for one or more of its sibling ServiceRequest. In each case where trigger conditions are met, the defined action trigger reaction is performed.

Trigger evaluation is skipped if the submitted measurement is an Observation with .dataAbsentReason. This means that an Observation with .dataAbsentReason will not fire any action triggers.

In the example below, the PlanDefinition contains an action trigger where activity “action[2]” has dependencies to “action[0]” and “action[1]”. Compared to the same setup at the time of PlanDefinition$apply (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Trigger-Actions-and-Trigger-Conditions), the CarePlan and triggering ServiceRequest (SR0 and SR1 in the figure below) now have status set to active, presumably because all necessary adjustments and delivering of device etc. have been performed and an employee has changed the status.

Measurement submitted for ServiceRequest resource playing a role in an action trigger. References from CarePlan and ServiceRequest resources to PlanDefinition and ActivityDefinition resources have been omitted for brevity. The naming of resources indicates the relation (for instance, SR0 is ServiceRequest related to ActivityDefinition AD0). The dotted references are logical.

When a measurement, here QuestionnaireResponse QR0, is submitted and subjected to automated processing, it is determined whether it plays any role in action triggers. In this case, the corresponding ServiceRequest SR0 is a triggering ServiceRequest, that is, its related ActivityDefinition has a trigger condition defined in the corresponding PlanDefinition. To optimize determining this, the triggering ServiceRequest SR0 (and similarly SR1) has ServiceRequest.meta.tag set to trigger automatically as part of PlanDefinition$apply.

The automated processing follows this pseudo-algorithm:

On receiving a measurement:
1. If the measurement references a triggering ServiceRequest (if ServiceRequest.meta.tag is set to trigger) continue, otherwise the check for action triggers is done.
2. Resolve the CarePlan referencing the triggering ServiceRequest
3. Resolve the PlanDefinition referenced by the CarePlan
4. Resolve the triggering ActivityDefinition (referenced from triggering ServiceRequest) and its id in PlanDefinition.action[y].id
5. Determine which depending ServiceRequest (one or more) is depending on the triggering ServiceRequest as follows:
  1. For each PlanDefinition.action[x].ehealth-actionTrigger referring in triggerCondition.actionId the triggering PlanDefinition.action[y].id:
    1. Resolve the depending ServiceRequest by comparing its reference to the depending ActivityDefintion which must be referenced in the depending PlanDefinition.action[x].definition.
6. For each depending ServiceRequest, determine whether conditions have been met:
  1. If the ServiceRequest.ehealth-trigger-enablement is other than TRIGGER_ENABLED then continue to next depending ServiceRequest, otherwise perform as follows:
    1. If the ServiceRequest.status is on-hold continue, continue to next depending on ServiceRequest
    2. If the PlanDefinition.action[x].ehealth-actionTrigger has triggerBehavior set to one-or-more
      1. Determine whether the ehealth-triggerCondition has been met (searching for measurements and comparing with triggerCoundition.count)
    3. If the PlanDefinition.action[x].ehealth-actionTrigger has triggerBehavior set to all or other triggering ServiceRequest may be defined for this depending on ServiceRequest
      1. Determine whether all ehealth-triggerCondition have been met (searching for measurements and comparing with triggerCoundition.count)
        Optimized by continuing to next depend ServiceRequest on the first unmet condition found
7. For each depending ServiceRequest where conditions have been met, perform the actionTrigger’s reaction in actionTrigger.action
  1. This is changing ServiceRequest.status to active.
  2. The ServiceRequest.occurrence starting time is evaluated:
    1. If the occurrence starting time is in the past, then the starting time is set to now with possible adjustment as specified by actionTrigger.offset
    2. If the occurrence starting time is in the future, the starting time is kept with possible adjustment as specified by actionTrigger.offset
  3. Change ServiceRequest.ehealth-trigger-enablement to TRIGGER_DONE

The evaluation of starting time is tabulated below for the different types of ServiceRequest.occurrence:

Type of ServiceRequest.occurrence

Criteria

dateTime

The dateTime is set to the starting time with possible actionTrigger.offset adjustment

Period

The duration of the Period is calculated, if it is not an open-ended period.

The Period.start is set to starting time with possible actionTrigger.offset adjustment.

Finally the Period.end is set to keep the original duration.

Timing

If the Timing.repeat.bounds is a Period, then the bounds period is set as for the occurrence of type Period.

Automated Processing can reject tasks created for Missing Measurements

If a measurement is submitted later than the timing specified by the ServiceRequest, then the automated processing will check, if a “missing measurement” task exists (created by Automated Processing of Missing Measurements). If the task has status, requested, and has not been assigned, then the automated processing will change the status to rejected.

Automated Processing of Missing Measurements

The eHealth Infrastructure continuously monitors, if measurements are being submitted on time, based on their associated CarePlan. Here's how it works:

All active ServiceRequests with a resolved timing (ie. where ServiceRequest.occurrence[x] can be resolved to a specific time period), and specifying an activity, where the patient is expected to submit measurements, are monitored continuously.
It performs missing measurement checks at the end time of resolved timing, if a ServiceRequest is effectively active at the end time. This is determined by the related CarePlan and EpisodeOfCare (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2524872705/Using+EpisodeOfCare+CarePlan+s+and+ServiceRequest+s#Determining-the-ServiceRequest-Effective-Status):
- The EpisodeOfCare must have status active at the resolved timing end time.
- The CarePlan must have status active at the resolved timing end time.
- The ServiceRequest must have status active at the resolved timing end time.
To decide whether a specific ServiceRequest undergoes the missing measurements check, it depends on the activity type, which is taken from ActivityDefinition.code and copied to ServiceRequest.code during processing. The decision is controlled by an automated lookup process using a ConceptMap https://docs.ehealth.sundhed.dk/latest-released/ig/ConceptMap-activitydefinition-code-to-do-missing-measurement.html:
1. If the activity type is found in the ConceptMap, then the map determines if the missing measurement check should be done (Y or N).
2. If the activity type isn't found in the ConceptMap , the ServiceRequest is subject to the missing measurements check by default.

The criteria for deciding that a measurement is missing depends on how the measurement regime is specified, that is, what ServiceRequest.occurrence[x] variant in use:

ServiceRequest.occurrence[x] Variant	`occurrenceDateTime`	`occurrencePeriod`	`occurrenceTiming`
Data Type	DateTime	Period	Timing Timing constraints: The Timing should be structured as described in 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. When the infrastructure resolves a Timing, it classifies it as one of four types as described by `TimingType` in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#How-to-interpret-output-from-get-patient-procedures. Only Timing classified as type `Resolved` are eligible to produce missing measurement.
Time Criteria	`occurrenceDateTime` is passed. and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist with a corresponding resolved timing.	`occurrencePeriod.end` is passed. and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist with a corresponding resolved timing.	The resolved timing end is passed. The number of measurements (Observation, QuestionnaireResponse or Media) that can be found is less than the expected frequency for the resolved timing.
Effective Status Criteria	ServiceRequest, CarePlan and EpisodeOfCare have status active at `occurrenceDateTime`.	ServiceRequest, CarePlan and EpisodeOfCare have status active at `occurrencePeriod.end`.	ServiceRequest, CarePlan and EpisodeOfCare have status active at `resolvedTiming.end`.
Measurement Match Criteria	A measurement (Observation, QuestionnaireResponse and Media) is matched based on the following: The `measurement.basedOn` on references the `ServiceRequest` The `measurement.resolvedTiming.start` is the same as the start of the `resolved-timing` in question. The `measurement.resolvedTiming.end` is the same as the end of the `resolved-timing` in question. If a QuestionnaireResponse then the `status` must be `completed`

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 has 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 has 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 has status active.
etc.

See the diagram below.

https://ehealth-dk.atlassian.net/wiki40a89422-146e-4e88-96d7-43def05f5317Missing measurement - status check - example with occurrenceTiming FUT-I 2023.525622937611691588983731

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

Resource	Element	Value
Task	`category`	Coding for `MissingMeasurementResolving`
	`status`	`requested`
	`intent`	`plan`
	`priority`	`routine`
	`description`	`Forventede at en aktivitet var udført, men fandt ingen den %s` (which is Danish for ‘Expected that an activity was done, but found none at %s’). Or if frequency is greater than 1: `Forventede at %d aktiviteter var udført, men fandt %d den %s` (which is Danish for ‘Expected that %d activities were done, but found %d at %s’)
	`ehealth-task-responsible`	List of CareTeam from the CarePlan
	`ehealth-restriction-category`	Coding for `measurement-monitoring`
	`focus`	The ServiceRequest
	`resolvedTiming`	Same as the resolved timing that was expected
	`episodeOfCare`	Same as `CarePlan.episodeOfCare`
	`for`	Same as episodeOfCare.patient
	`authoredOn`	current date/time
Communication (of profile ehealth-message)	`category`	Coding for `notification`
	`status`	`completed`
	`reasonCode`	Coding for `MissingMeasurementResolving`
	`payload.content`	`Need to resolve why scheduled measurement has not been submitted`
	`ehealth-title`	`Need resolving of why scheduled measurement has not been submitted`
	`ehealth-restriction-category`	Coding for `measurement-monitoring`
	`subject`	Same as CarePlan
	`episodeOfCare`	Same as CarePlan
	`topic`	About Task above
	`sent`	current date/time

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

In the following, pending measurement activity is used broadly as a term for measuring and answering questionnaires that are supposed to happen.

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 example:

The periodic lookup runs at 08:00.

It has a current (lookup) time window of 08:00 to 10:00.

It has a previous (lookup) time window of 06:00 to 08:00.

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 status set to active at the same time as the EpisodeOfCare and CarePlan both have 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.

`ServiceRequest.occurrence[x]` alternative	`ServiceRequest.occurrenceDateTime`	`ServiceRequest.occurrencePeriod`	`ServiceRequest.occurrenceTiming`
Data type	DateTime	Period	Timing Timing constraints: The Timing should be structured as described in 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. When the infrastructure resolves a Timing, it classifies it as one of four types as described by `TimingType` in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#How-to-interpret-output-from-get-patient-procedures. Only Timing classified as type `Resolved` are eligible to produce reminders. Note: If the Timing expresses a recurring timing regime, the individual times an activity should be performed are called a `resolved-timing` and are expressed as a start and an end time for the individual performance of the activity. If the Timing is not recurring the regime is resolved into a single `resolved-timing`.
Time Criteria	`occurrenceDateTime` must be within the previous time window After the start datetime and before or equal to the end datetime of the previous time window	The `occurrencePeriod.start` must be within the previous time window The `occurrencePeriod.end` must, if defined, be equal to or after the start of the current time window, or If both `occurrencePeriod.start` and `occurrencePeriod.end` is within the previous time window, the ServiceRequest is still considered as having a pending measurement. This ensures that reminders for activities with short periods that lie entirely within a time window are not missed.	The `occurrenceTiming.repeat.boundsPeriod.start` must be equal to or before the start of the current time window. The `occurrenceTiming.repeat.boundsPeriod.end` must, if defined, be equal to or after the start of the current time window If the `occurrenceTiming.repeat.boundsPeriod.start` is within the previous time window, `resolved-timing` started before the current window is also accepted (They must still overlap with the `boundsPeriod`). This ensures that while they might be late, they are not missed entirely. At least one of possibly multiple `resolved-timing` must start within the current time window and the `occurrenceTiming.repeat.boundsPeriod`.
Effective Status Criteria	`occurrenceDateTime` must be within a period where the ServiceRequest, CarePlan and EpisodeOfCare are all active	The `occurrencePeriod` must to some degree overlap with a period where the ServiceRequest, CarePlan and EpisodeOfCare are all active The overlapping part of the periods does not have to be within the current or previous time windows (see example 4 in the table below)	At least one of possibly multiple `resolved-timing` must be within a period where the ServiceRequest, CarePlan and EpisodeOfCare are all active.
Activity Type Criteria	The `ServiceRequest` must have an activity type that warrants a reminder http://ehealth-documentation.s3-website-eu-west-1.amazonaws.com/latest/ig/ConceptMap-activitydefinition-code-to-do-reminder.html.
Measurement Submission Criteria	A check is performed to see if any measurements have already been submitted - If all expected measurements have been submitted for a given `ServiceRequest`, no reminder will be generated. For a measurement to be seen as a submission for a given `resolved-timing` of a `ServiceRequest` it should meet the following criteria: The `measurement.basedOn` on references the `ServiceRequest` The `measurement.resolvedTiming.start` is the same as the start of the `resolved-timing` in question. The `measurement.resolvedTiming.end` is the same as the end of the `resolved-timing` in question.

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.

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.

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.

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 start 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.

For the reminder check, a status period is considered as exclusive-end. This is because the end time of a period is the same as the start time of a new status, which at that time then takes precedence over the old status.

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 found 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.

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.

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).

Communication Element	Value
`category`	Coding for `advice`
`status`	`completed`
`payload.content`	`"Du har en opgave. Se den i din telemedicinske løsning."`
`ehealth-title`	`"Påmindelse om målinger og besvarelse af spørgeskemaer"`
`about`	`ServiceRequest references`
`sent`	current date/time
`medium`	Coding for `NemSMS` (when the `Patient.telecom` has a `NemSMS` entry) No medium set when the `Patient.telecom` has no `NemSMS` entry.
`recipient`	The Patient
`sender`	Device reference for eHealth Infrastructure Device

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 run scheduled jobs that Import of 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

Resource	Element	Value
Communication (of profile ehealth-message)	category	Coding for `notification`
	status	`completed`
	payload.content	One of: “Der er oprettet nyt forløb den %s. Se det i din telemedicinske løsning.” “Der er oprettet ny plan den %s. Se den i din telemedicinske løsning.” “Der er sket ændringer i dit forløb den %s. Se i din telemedicinske løsning.“ “Der er sket ændringer i din plan den %s. Se i din telemedicinske løsning.”
	ehealth-title	One of: "Status er opdateret for det telemedicinske forløb den %s" "Status er opdateret for den telemedicinske pakke den %s" "Listen af ansvarlige for det telemedicinske forløb er opdateret den %s" "Listen af ansvarlige for den telemedicinske pakke er opdateret den %s" "Der er planlagt ændring af status for det telemedicinske forløb" "Der er planlagt ændring af status for den telemedicinske pakke" "Der er planlagt ændring af ansvarlige for det telemedicinske forløb" "Der er planlagt ændring af ansvarlige for den telemedicinske pakke"
	topic	Reference to EpisodeOfCare or CarePlan, depending on the situation
	sent	current date/time
	recipient	The Patient
	sender	Device reference for eHealth Infrastructure Device

Communication created with CareTeam as the recipient

Resource	Element	Value
Communication (of profile ehealth-message)	category	Coding for `notification`
	status	`completed`
	payload.content	One of: “Der er oprettet nyt forløb den %s. Se det i din telemedicinske løsning.” “Der er oprettet ny plan den %s. Se den i din telemedicinske løsning.” “Der er sket ændringer i dit forløb den %s. Se i din telemedicinske løsning.“ “Der er sket ændringer i din plan den %s. Se i din telemedicinske løsning.”
	ehealth-title	One of: "Status er opdateret for det telemedicinske forløb den %s" "Status er opdateret for den telemedicinske pakke den %s" "Listen af ansvarlige for det telemedicinske forløb er opdateret den %s" "Listen af ansvarlige for den telemedicinske pakke er opdateret den %s" "Der er planlagt ændring af status for det telemedicinske forløb" "Der er planlagt ændring af status for den telemedicinske pakke" "Der er planlagt ændring af ansvarlige for det telemedicinske forløb" "Der er planlagt ændring af ansvarlige for den telemedicinske pakke"
	topic	Reference to EpisodeOfCare or CarePlan, depending on the situation
	sent	current date/time
	ehealth-communication-recipientCareTeam	The CareTeam
	sender	Device reference for eHealth Infrastructure Device

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.

Resource	Element	Value
Communication (of profile ehealth-message)	category	Coding for `notification`
	status	`completed`
	payload.content	One of: “Husk din aftale den %. Se den i din telemedicinske løsning.“ “Husk din videoaftale den %. Åbn din telemedicinske løsning for at deltage i videomødet.“ (Unless otherwise stated by matching CommunicationRequest)
	sent	current date/time
	medium	Coding for `NemSMS` (unless otherwise stated by matching CommunicationRequest)
	recipient	The Patient
	sender	Device reference for eHealth Infrastructure Device

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.

Resource	Element	Value
Communication (of profile ehealth-message)	category	Coding for `notification`
	status	`completed`
	payload.content	One of: “Husk din aftale den %. Se den i din telemedicinske løsning.“ “Husk din videoaftale den %. Åbn din telemedicinske løsning for at deltage i videomødet.“ (Unless otherwise stated by matching CommunicationRequest)
	sent	current date/time
	medium	Coding for `NemSMS` (unless otherwise stated by matching CommunicationRequest)
	recipient	The CareTeam
	sender	Device reference for eHealth Infrastructure Device

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.

Resource	Element	Value
Communication (of profile ehealth-message)	category	Coding for `message`
	status	`completed`
	payload.content	“Du har modtaget en ny besked. Se den i din telemedicinske løsning.”
	about	The Communication resource that caused this notification
	sent	current date/time
	recipient	The Patient
	sender	Device reference for eHealth Infrastructure Patient

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.

Situation/Trigger	Task.category	Reference
Measurement submitted at an unexpected time	UnexpectedMeasurementResolving	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140/Automated+Processing#:~:text=Processing%20of%20Measurements.-,Automated%20Processing%20of%20Measurements%20Submitted%20at%20Unexpected%20Time,-Prior%20to%20release
Missing measurement	MissingMeasurementResolving	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140/Automated+Processing#:~:text=type%20Period.-,Automated%20Processing%20of%20Missing%20Measurements,-The%20infrastructure%20has
Measurement submitted with Data Absent Reason	MeasurementForAssessmentAbsentValue	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140/Automated+Processing#AutomatedProcessing-AutomatedProcessingofMissingMeasurements Task resource example - missing measurement
Automated processing rule: FallbackRule	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#The-Fallback-Library-and-Rule
Automated processing rule: Assessment of Absolute Reference Ranges Based on the highest alert level found	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Absolute-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Absolute Reference Ranges Error: No absolute reference range found	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Absolute-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Absolute Reference Ranges Error: Unit mismatch between reference range and observation value	Creates two tasks: MeasurementForAssessmentFailureInAutoProcessing RefRangeFixingNeeded	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Absolute-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Absolute Reference Ranges Error: Missing observation value	Creates two tasks: MeasurementForAssessmentFailureInAutoProcessing LibraryUseMismatchFixingNeeded	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Absolute-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Relative Reference Ranges Based on the highest alert level found	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Relative-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Relative Reference Ranges Error: Neither reference base nor relative reference range(s) found	MeasurementForAssessmentNotTriaged	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Relative-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Relative Reference Ranges Error: No reference base found	Creates two tasks: MeasurementForAssessmentNotTriaged RefBaseNeeded	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Relative-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Relative Reference Ranges Error: No relative reference range found	Creates two tasks: MeasurementForAssessmentNotTriaged RefRangeNeeded	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-Relative-Reference-Ranges-Library-and-Rule
Automated processing rule: Assessment of Questionnaire Response	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Library-for-Assessment-of-Questionnaire-Response
Automated processing rule: Assessment of Questionnaire Response no-effective-answer-significance or no-answer-significance-defined	MeasurementForAssessmentNotTriaged	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Library-for-Assessment-of-Questionnaire-Response
Automated processing rule: Assessment of TeleCare Nord COPD Questionnaire	MeasurementForAssessment	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1251409937/Library+Resources#Assessment-of-TeleCare-Nord-COPD-Questionnaire
When a CarePlan has been activated and there is an open SSL Order	OpenSSLOrder	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-ValidationofSSLorderswhenactivatingaCarePlan:~:text=as%2DRecipient).-,Validation%20of%20SSL%20orders%20when%20activating%20a%20CarePlan,-When%20a%20CarePlan
When the expiration date for device calibration has exceeded	CalibrationNeeded	https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2550661140#AutomatedProcessing-TaskCreatedforCalibrationofEquipment:~:text=calibration%2Dof%2Dequipment-,Task%20Created%20for%20Calibration%20of%20Equipment,-Some%20equipment%20needs

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.

For information regarding how to control the creation and content of Communcations see Controlling Creation of Messages.

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.

Situation/Trigger	Created by Default	Opt-in Supported	Opt-out Supported	Element category	Element reasonCode	Element restriction-category	Element medium	Element recipient	Element recipientCareteam
Measurement submitted at an unexpected time	No	Yes	No	`notification`	`UnexpectedMeasurementResolving`	`measurement-monitoring`			One Communication for each CareTeam associated with the CarePlan and have opted in.
Measurement submitted at an unexpected time	No	Yes	No	`notification`	`UnexpectedMeasurementResolving`	`measurement-monitoring`	Default: none Can be overridden with CommunicationRequest	Patient
Automated processing rule requests Communication(s) to be made.	Yes	No	Yes	`notification`	Can vary with the automated processing rule. See execution of rule and output in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Execution-of-rule-and-output .				One Communication for each CareTeam associated with the CarePlan which has not opted out.
	No	Yes	No	`notification`			Default: none Can be overridden with CommunicationRequest	Patient
Missing measurement	Yes	No	Yes	`notification`	`MissingMeasurementResolving`	`measurement-monitoring`			One Communication for each CareTeam associated with the CarePlan which has not opted out.
Missing measurement	No	Yes	No	`notification`	`MissingMeasurementResolving`	`measurement-monitoring`	Default: none Can be overridden with CommunicationRequest	Patient
Creation of EpisodeOfCare	Yes	No	Yes	`notification`	`EpisodeOfCareCreated`	No value assigned			One Communication for each CareTeam associated with the CarePlan which has not opted out.
Creation of EpisodeOfCare	No	Yes	No	`notification`	`EpisodeOfCareCreated`	No value assigned	Default: none Can be overridden with CommunicationRequest	Patient
Creation of CarePlan ($apply)	Yes	No	Yes	`notification`	`CarePlanCreated`	No value assigned			One Communication for each CareTeam associated with the CarePlan which has not opted out.
Creation of CarePlan ($apply)	No	Yes	No	`notification`	`CarePlanCreated`	No value assigned	Default: none Can be overridden with CommunicationRequest	Patient
Change in CarePlan of CareTeam, scheduled CareTeam, status or scheduled status	Yes	No	Yes	`notification`	`CarePlanCareTeamChange` , `CarePlanScheduledCareTeamChange` , `CarePlanStatusChange` or `CarePlanScheduledStatusChange`	No value assigned			One Communication for each CareTeam associated with the CarePlan which has not opted out.
	No	Yes	No	`notification`		No value assigned	Default: none Can be overridden with CommunicationRequest	Patient
Change in EpisodeOfCare of CareTeam, scheduled CareTeam, status or scheduled status	Yes	No	Yes	`notification`	`EpisodeOfCareCareTeamChange`, `EpisodeOfCareScheduledCareTeamChange`, `EpisodeOfCareStatusChange` or `EpisodeOfCareScheduledStatusChange`	No value assigned			One Communication for each CareTeam in EpisodeOfCare.team which has not opted out.
	No	Yes	No	`notification`		No value assigned	Default: none Can be overridden with CommunicationRequest	Patient
Reminder to submit measurement	Yes	No	Yes	`advice`	`ReminderSubmitMeasurement`	No value assigned	`nemsms` when Nem SMS is enabled for the Patient at the time of sending the Communication, otherwise no medium is set. Can be overridden with CommunicationRequest	Patient
If a contract has a reminder days setup and a matching order/orderline has an agreedDateFrom – reminder days = current day	Yes	No	No	`advice`	`ExpectedDelivery`	`measuring-support`	`nemsms` when Nem SMS is enabled for the Patient at the time of sending the Communication, otherwise no medium is set.	Patient

Currently, there are no automated processing rules - neither ready for production nor slated for production - that specify or request the creation of Communication.