These pages describe the behavior of services in the infrastructure which are not directly invoked by a client.

What is described here is what happens when a user performs login, how submitted measurements are processed in automated processing, and how citizens' adherence to care plans are monitored and handled. Also described is the periodic importing of organizations.

Handling at Login

When a user performs login at the eHealth Infrastructure, various checks are performed and security artifacts (such as the security token) are produced. In addition, certain resources are read, created, or possibly updated. The following applies to users of the Practitioner type.

The external security token contains one to many organizational scopes in which the user can have:

• Zero, one or many different careteams in which the user can have one or many user roles

• Zero, one or many user roles in the organizational scope

For the recognized user roles bound to a recognized and pre-existing CareTeam, it is ensured that:

• a CareTeam.participantexists where the CareTeam.participant.member references the Practitioner. A participant can have multiple roles in a CareTeam.

  • If such an entry is not present, or does not contain the current role then the CareTeam is updated.

    • When a CareTeam.participantis added, the CareTeam.participant.period is set with a Period.start of date/time at update. The Period.end is left without value to form an open-ended period.

For all the organizational scopes where the organization identification can be resolved to an Organization in the eHealth Infrastructure, it is ensured that:

• a PractitionerRole exists where the PractitionerRole.practitioner references the Practitioner and the PractitionerRole.organization references the Organization

Automated Processing of Submitted Measurement

The Clinical Administrator can define a PlanDefinition, its activities in referenced ActivityDefinition, possible Questionnaire to be answered, and add zero, one or more Library resources each containing a rule. The Library of interest here are those of automated processing type that is attached to a plan for which a measurement has been successfully submitted.

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 a 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):

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 Processing of Automated Processing Rules

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

Automated Processing of Measurements Submitted at Unexpected Time

For each measurement resource, automated processing resolves the ServiceRequest referenced by the measurement resource. The measurement submission time is then compared to the scheduled timing constructs in ServiceRequest.Timing.repeat. The measurement submission time is either of:

• Observation.meta.lastUpdated

• QuestionnaireResponse.meta.lastUpdated

• Media.meta.lastUpdated

A measurement has been submitted at an unexpected time when:

• the scheduled timing is specified as (Timing.repeat).dayOfWeek and the day of week code is not identical to that corresponding to the measurement submission time, or

• the scheduled timing is specified with (Timing.repeat).timeOfDay and (Timing.repeat).boundsDurationand the measurement submission time is not within the period (start and end included):

  • start of period: (Timing.repeat).timeOfDay

  • end of period: (Timing.repeat).boundsDurationadded to (Timing.repeat).timeOfDay

In case the ServiceRequest has ServiceRequest.Period or ServiceRequest.occurenceDateTime then it is not checked.

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 same one or more CareTeam as the CarePlan.team (CarePlan found through reverse association from measurement resource’s .basedOn reference to ServiceRequest referred from CarePlan.activity.reference)

  • .description set to “Uventet måling” which is Danish for unexpected measurement

• A Communication (of 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 message

  • .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 Task.category (withTask.episodeOfCare) and Communication.reasonCode (with Communication.subject and Communication.episodeOfCare).

Processing of Automated Processing 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).

An automated processing rule is a Library where Library.type is automated-processing. The existing Library is listed in Library Resources. The automated processing rule Library eligible for a particular ServiceRequest are those zero, one, or more Library related to the ActivityDefinition referenced by the ServiceRequest.

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.

Library Rule Evaluation

Input

The Library.parameter element specifies what resources are to be made available to the Library’s rule execution as input and what is returned as output. Typically, a measurement resource - be that an Observation, QuestionnaireResponse, or Media - is provided as input as part of the evaluate operation.

It is possible to state further input for both calculation-type Library (where Library.type is logic-library) and automated processing-type Library (where Library.type is automated-processing). For the calculation-type, all input resources must be provided as part of the evaluate operation.

For automated processing type, the following can be specified as input but are not provided as they are resolved by the Library service as part of establishing facts:

Establishing of Facts

If specified as input parameter, the following resources are fetched and made available to an automated processing type Library rule by the Library service. In the rule, the resources can be accessed by adding the variable declaration to the when part.

Execution of rule and output

For automated processing rules, there is a structure, AutomatedProcessingDTO, which lets the rule control aspects of the outcome of evaluating the rule. By adding to the structure, the rule controls if and in what number ClinicalImpression, Task, and Communication resources are created. A special case is the property activateSelfTreatment which controls whether a check on certain ServiceRequest resources should be made, possibly leading to an update of the status of eligible ServiceRequest resources (see further details in Activation of suspended Self-treatment type ServiceRequest ).

AutomatedProcessingDTO

ClinicalImpressionDTO

TaskDTO

QuestionnaireResponseFindingBasisDTO

AnswerSignificanceDTO

AnswerConditionDTO

CommunicationDTO

CodingDTO

It is the responsibility of the rule writer to ensure that a CodingDTO reflects a valid concept in a CodeSystem existing in the eHealth infrastructure and furthermore, that the concept is part of the expanded ValueSet for which there is a binding to the particular resource element where it is used.

ObservationDTO

Output from automated processing

For each automated processing type Library evaluated, the returned GuidanceResponse typically contains an AutomatedProcessingDTO with instructions for further processing.

The handling is shown in the sequence diagram Automated Processing of Measurements - Handling.

Resources created

When populated by the Library in the AutomatedProcessingDTO, it results in the following resources being created. Please note that Communication resources described below are subjected to the handling described in Taking applicable CommunicationRequest into account, which further influences the number of Communication resources created and their recipient.

For every ClinicalImpressionDTO in AutomatedProcessingDTO.ClinicalImpressions:

For every TaskDTO in AutomatedProcessingDTO.Tasks:

Taking applicable CommunicationRequest into account

When Communication resources (of ehealth-message profile) are created by automated processing, the intended receivers would typically be the one or more CareTeam designated as CarePlan.careTeam on the involved CarePlan. As Communication can have at most a single CareTeam as recipient (through Communication.ehealth-communication-recipientCareTeam), this involves duplication of the original Communication where the duplicates vary by recipient.

The recipient(s) and duplication made for Communication created by automated processing is influenced by CommunicationRequest. By creating appropriately crafted CommunicationRequest, a Practitioner can control whether:

• to suppress automated processing’s default creation of a Communication for a particular CareTeam

• to duplicate a Communication with the Patient as recipient

The handling is shown in the sequence diagram Automated Processing of Measurements - Create Communications.

Activation of suspended Self-treatment type ServiceRequest

When the AutomatedProcessingDTO specifies activation through the element activateSelfTreatmentset to true, automated processing performs a lookup for all sibling ServiceRequest resources which have:

1. ServiceRequest.status set to suspended

2. ServiceRequest.definition referencing an ActivityDefinition where ActivityDefinition.topic has value self-treatment.

The sibling ServiceRequest resources are those referenced fromCarePlan.activity.reference for the same CarePlan that references the ServiceRequest referenced from the measurement (be that Observation, QuestionnaireResponse or Media).

For those ServiceRequest meeting the criteria above, the ServiceRequest.status is updated to active.

Automated Processing of Action Triggers and Trigger Conditions

Each submitted measurement references a ServiceRequest. As part of automated processing of a submitted measurement, the infrastructure examines whether the measurement constitutes fulfillment 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 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.

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:

1. 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 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, otherwise continue to next depending 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 by defined for this depending ServiceRequest

            1. Determine whether all ehealth-triggerCondition have been met (searching for measurements and comparing with triggerCoundition.count)

               1. Optimized by continuing to next depending ServiceRequest on 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:

Automated Processing of Missing Measurements

The infrastructure has a periodic check whether measurements are being submitted timely according to their CarePlan. The overall approach is to do missing measurements checks covering a time window from last check to ‘now’ and do bookkeeping of when the missing measurements check was last performed. By relying on that missing measurements found during the previous time window would have been handled as part of that check, any current check can consider the period between last check and now only.

Whether a particular ServiceRequest shall be subjected to the missing measurements check described below, depends on the activity type (copied from ActivityDefinition.code to ServiceRequest.code on $apply). This is controlled by the infrastructure automated processing by lookup in the ConceptMap https://docs.ehealth.sundhed.dk/latest-released/ig/ConceptMap-activitydefinition-code-to-do-missing-measurement.html. In case an activity type is not found in the ConceptMap, the fallback is to subject the ServiceRequest to missing measurements check.

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

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

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 row “Time Criteria” for occurrenceTiming, Timing.repeat.periodUnit h (hours) will result in a lookup period starting from Midnight 1 day ago till current time represented as nearest past Midnight.
The resolved occurrences will be every 6 hours with a duration of 3 hours starting from Timing.repeat.boundsPeriod.start. As the time component of boundsPeriod.start is 10 AM that means the next resolved occurrence is 16 PM and the next 22 PM.

• The first occurrence in the lookup period is 22-01 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest all had status active.

• The second occurrence in the lookup period is 04-07 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest had status active in a partial overlap during the resolved occurrence.

• The third occurrence in the lookup period is 10-13 shall not be checked for missing measurement as ServiceRequest had status on-hold for the whole occurrence.

• The fourth occurrence in the lookup period is 16-19 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest had status active has partial active overlap during the resolved occurrence.

• The fifth occurrence in the lookup period is 22-01 which shall not be checked for missing measurement as the end of the occurrence is outside the lookup period, that is, the citizen still has one hour past Midnight to submit measurement(s).

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 handling of recipients described in Taking applicable CommunicationRequest into account.

Automated Creation of Reminder on Pending Measurement Activity

In order 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 datetime of next periodic lookup, reduced by the duration between lookups.

  • end datetime: calculated as datetime of next periodic lookup.

• The previous time window:

  • start datetime: calculated as datetime of 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 of time 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 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.

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 of the 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. 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. 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 of the occurrences result in the generation of reminders

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

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

  • 6. 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.

• In 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 are the period of a status (The color depends on status: yellow=draft, green=active, orange=on-hold)

    • 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 are the statusSchedule of the resource, marking the intended change to a given status at that time (The color 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 above example the active periods for the resource are found by:

• First one is the 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 is 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 of time 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 uphold 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 the it is the 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 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. Prerequisite to this is that the citizen has subscribed to NemSMS and that the citizen has not suppressed generation of such message (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 necessary equipment. The infrastructure creates a task with 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 measurement.

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 a regular interval.

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

Task Created by the Infrastructure

The Infrastructure automatically creates Task resources of profile ehealth-task in different situations.

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.

Task Created for Calibration of Equipment

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

Communication Created by the Infrastructure

The Infrastructure automatically creates Communication resources of profile ehealth-message in different situations.

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 neither Communication nor CommunicationRequest. Please consult particular sections corresponding to the situations for details. Element <some element name> describes what values are used in a Communication in the specific situation.

Communication Created on Creation of EpisodeOfCare and CarePlan

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

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

Communication Created on Change of EpisodeOfCare and CarePlan Status, CareTeam, Scheduled Status and/or Scheduled CareTeam

The EpisodeOfCare and CarePlan have been extended with 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 Patient as recipient

Communication created with CareTeam as recipient

Communication Created as Reminder for Participation in Appointment

Communication with Patient as 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 recipient

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

Communication Created as NemSMS Notification on Message Type Communication

Communication with Patient as recipient

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

Sharing through Registering Documents in National Document Sharing Infrastructure

Some FHIR resources in the eHealth Infrastructure are assembled to volatile FHIR Compositions (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Preparing-Transformations-by-Assembling-Required-FHIR-Resources), transformed to Danish profiles of Clinical Document Architecture (CDA) documents (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Transformation-Details), and registered in the national health document sharing archives. This way, the health data registered can be accessed by the patient and other healthcare professionals through other health systems whilst subjected to various access controls and audit logging.

This description focuses on the criteria for this registering to take place.

Document Registering of Measurements

Submitted measurements, whether in the form Observation, QuestionnaireResponse or Media, are each associated with a ServiceRequest. As part of being evaluated by a Practitioner, each measurement can be approved for sharing in the form of a ClinicalImpression with element ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing.

The criteria for registering a measurement as document are:

1. The ServiceRequest.ehealth-sharingPolicy must specify sharing allowed and, currently, that this is sharing with a national health archive as destination

2. There must exist a ClinicalImpression referring to the measurement with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing

3. The measurement must be an Observation or QuestionnaireResponse

4. For a QuestionnaireResponse it must be a response to a Questionnaire:

   1. for which a representation as Danish profile of CDA Questionnaire Form Definition Document (QFDD) exists

   2. for which the location of the QFDD is known in the infrastructure.

5. For an Observation, it must not specify a data absent reason (.dataAbsentReason). Observations without a value can't be document shared with CDA Personal Health Monitoring Report (PHMR).

An Observation is registered as a Danish profile of the CDA Personal Health Monitoring Report (PHMR) document and a QuestionnaireResponse as a Danish profile of the CDA Questionnaire Response Document (QRD) document.

Document Registering of Appointments

A created or updated Appointment (whether of profile ehealth-appointment or ehealth-videoappointment) are registered as the Danish profile of the CDA Appointment Document (APD), provided that criteria are met.

The criteria for registering an Appointment resource are:

1. The Appointment.ehealth-legalBasis must be present and designate a legal basis for which national document sharing infrastructure has been established - currently this is the case for Healthcare Act only.

2. The Appointment.ehealth-releasebleResource must, if present, be set to true.

3. The Appointment has exactly one Patient as participant

Importing of Organization Data

The periodic importing of Organization data is described in Organization import and synchronization .