Overview of Automated Processing in the InfrastructureThis 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*) When there is a timezone change (to daylight saving time, DST), the execution is still at local Danish time. Event-based processingAutomated Processing of Submitted MeasurementThe Clinical Administrator can set u 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): For each measurement resource in the order Observation, QuestionnaireResponse and Media resources in the measurement: 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. 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| Info |
|---|
Before release FUT-I 2023.5 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: 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):
In case the ServiceRequest has ServiceRequest.Period or ServiceRequest.occurenceDateTime then it is not checked. |
| Info |
|---|
With the release of FUT-I 2023.5 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: |
In case a measurement has been submitted at an unexpected time, automated processing produces: 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). Processing of Automated Processing RulesWhen 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 the 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. 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 | 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. Library Rule EvaluationThe 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: Resource Type | Description |
|---|
Patient | The patient for which the measurement was applied. | EpisodeOfCare | EpisodeOfCare to which the measurement is related. | CarePlan | CarePlan to which the measurement is related. | ServiceRequest | ServiceRequest referred from measurement (Observation|QuestionnaireResponse|Media) | PlanDefinition | PlanDefinition to which the measurement is related. | ActivityDefinition | ActivityDefinition to which the measurement is related. | Questionnaire | Questionnaire to which a measurement of type QuestionnaireResponse is a response to. |
Establishing of FactsIf specified as an 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. Resource Type | Resolved As | Variable Declaration |
|---|
Patient | Fetched as Patient referenced in .subject on measurement resource | $patient : Patient()
| EpisodeOfCare | Fetched as EpisodeOfCare referenced in .episodeOfCare on measurement resource | $episodeofcare : EpisodeOfCare()
| CarePlan | Fetched as CarePlan where CarePlan.activity.reference refers to the ServiceRequest (see resolve of ServiceRequest below) | $careplan : CarePlan()
| ServiceRequest | Fetched as ServiceRequest referenced in .basedOn on measurement resource | $ServiceRequest : ServiceRequest()
| PlanDefinition | Fetched as PlanDefinition referenced in CarePlan.definition (see resolve of CarePlan above) | $plandefinition : PlanDefinition()
| ActivityDefinition | Fetched as ActivityDefinition referenced in ServiceRequest.definition (see resolve of ServiceRequest above) | $activitydefinition : ActivityDefinition()
| Questionnaire | Fetched as Questionnaire referenced in .questionnaire on measurement resource of type QuestionnaireResponse. | $questionnaire : Questionnaire()
|
Execution of rule and outputFor 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 of 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
Property | Type | Description |
|---|
ClinicalImpressions | List of ClinicalImpressionDTO | Each entry is an instruction to create a resource, and each entry specifies certain details. | Tasks | List of TaskDTO | Each entry is an instruction to create a resource, and each entry specifies certain details. | activateSelfTreatment | boolean | Set to true instructs that sibling ServiceRequests of self-treatment kind should be activated if currently suspended. |
ClinicalImpressionDTO
Property | Type | Description |
|---|
Code | CodingDTO
| Used for ClinicalImpression.code in the created resource. | Description | String | Used for ClinicalImpression.description in the created resource. | CodeableConceptFindings | List of CodingDTO | Used for ClinicalImpression.finding.itemCodeableConcept in the created resource. | ObservationFindings | List of ObservationDTO | Used for Observation.code of contained Observation in ClinicalImpression.finding.itemReference in the created resource. | Tasks | List of TaskDTO | Each entry is an instruction to create a Task resource, and each entry specifies certain details. Each created Task refers to the ClinicalImpression through Task.focus. | FindingBasis | List of QuestionnaireResponseFindingBasisDTO | Used for ClinicalImpression.ehealth-questionnaireresponse-finding-basis in the created resource. The list contains information regarding the basis for the overall clinical impression. |
TaskDTO
Property | Type | Description |
|---|
Category | CodingDTO
| Used for Task.category in the created resource. | Description | String | Used for Task.description in the created resource. | Priority | String | Used for Task.priority in the created resource. It must be ensured that the priority is entered in lower-case as defined for Task.priority. | RestrictionCategories | List of CodingDTO | Used for Task.ehealth-restriction-category in the created resource. | Communications | List of CommunicationDTO | Each entry is an instruction to create a Communication resource, and each entry specifies certain details. By default, the Commnunication.topic refers to the created Task but this may vary depending on the receiver. |
QuestionnaireResponseFindingBasisDTO
Property | Type | Description |
|---|
LinkId | String | Used for ehealth-questionnaireresponse-finding-basis.linkId in the created resource. | Finding | CodingDTO
| Used for ehealth-questionnaireresponse-finding-basis.findingin created resource. | ValueString | String | One of the value elements is populated and used for ClinicalImpression.ehealth-questionnaireresponse-finding-basis.value in the created resource. | ValueDecimal | Double | ValueInteger | Integer | ValueBoolean | Boolean | ValueCoding | CodingDTO
| AnswerSignificance | AnswerSignificanceDTO
| Used for ehealth-questionnaireresponse-finding-basis.ehealth-questionnaire-answerSignificance in created resource. |
AnswerSignificanceDTO
Property | Type | Description |
|---|
Significance | CodingDTO
| Used for ehealth-questionnaire-answerSignificance.significance in the created resource. | AnswerConditions | List of AnswerConditionDTO | Used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition in the created resource. Must be a list of size 1 or 2. |
AnswerConditionDTO
Property | Type | Description |
|---|
Operator | String | Used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition.operator in the created resource. | ValueString | String | One of the value elements is populated and used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition.value in the created resource. | ValueDecimal | Double | ValueInteger | Integer | ValueBoolean | Boolean | ValueCoding | CodingDTO
|
CommunicationDTO
Property | Type | Description |
|---|
Categories | List of CodingDTO | Used for Communication.reasonCode in the created resource. | Text | String | Used for Communication.payload.content in the created resource. | RestrictionCategories | List of CodingDTO | Used for Communication.ehealth-restriction-category in the created resource. |
CodingDTO
Property | Type | Description |
|---|
system | String | Corresponds to Coding.system in FHIR Coding. | code | String | Corresponds to Coding.code in FHIR Coding. | display | String | Corresponds to Coding.display in FHIR Coding. |
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 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
Property | Type | Description |
|---|
Status | String | Used for Observation.status in the created resource. | Code | CodingDTO
| Used for Observation.code in the created resource. | ValueString | String | One of the value elements is populated and used for Observation.value in the created resource. | ValueBoolean | Boolean | ValueQuantity | QuantityDTO
|
Output from automated processingFor 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 createdWhen 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: Resource | Element | Value |
|---|
ClinicalImpression | code | ClinicalImpressionDTO.Code
| | status | completed
| | description | ClinicalImpressionDTO.Description
| | investigation.code | Coding with: | | investigation.item | One version-less reference to the measurement, one versioned referenced to the measurement | | finding.itemCodeableConcept | Coding added for each CodingDTO in ClinicalImpressionDTO.CodeableConceptFindings | | finding.itemReference | For each ObservationDTO in ClinicalImpressionDTO.ObservationFindings, a reference to a contained Observation is added with the: Observation.code set to one corresponding to ObservationDTO.Code
Observation.status set to ObservationDTO.Status
Observation.value set to the one populated of ObservationDTO.ValueString, ObservationDTO.ValueBoolean or Observation.ValueQuantity.
ObservationDTO.episodeOfCareset to GuidanceResponse.episodeOfCare
ObservationDTO.subject set to GuidanceResponse.subject
ObservationDTO.performer set to GuidanceResponse.subject
ObservationDTO.effective set to current date/time
ObservationDTO.device set to a reference to a Device representing the automated processing system
ObservationDTO.basedOn set to reference the ServiceRequest of the measurement
| | date | current date/time | | subject | Same as GuidanceResponse.subject (which is the same as the subject of measurement) | | episodeOfCare | Same as GuidanceResponse.episodeOfCare (which is the same as episodeOfCare of measurement) | | effective | Same as measurement effective (which is Observation.effective or QuestionnaireResponse.authored) | | ehealth-clinicalimpression-decisionContext | A reference to a contained Parameters with: | | ehealth-questionnaireresponse-finding-basis | For each QuestionnaireResponseFindingBasisDTO in ClinicalImpressionDTO.FindingBasis, an ehealth-questionnaireresponse-finding-basis is added with: ehealth-questionnaireresponse-finding-basis.linkId set to QuestionnaireResponseFindingBasisDTO.LinkId
ehealth-questionnaireresponse-finding-basis.value set to the one populated of QuestionnaireResponseFindingBasisDTO.ValueString, QuestionnaireResponseFindingBasisDTO.ValueBoolean, QuestionnaireResponseFindingBasisDTO.ValueInteger, QuestionnaireResponseFindingBasisDTO.ValueDecimcal or QuestionnaireResponseFindingBasisDTO.ValueCoding
ehealth-questionnaireresponse-finding-basis.finding set to QuestionnaireResponseFindingBasisDTO.Finding
ehealth-questionnaireresponse-finding-basis.ehealth-questionnaire-answerSignificance set to QuestionnaireResponseFindingBasisDTO.AnswerSignificanceDTO
ehealth-questionnaire-answerSignificance.significance set to AnswerSignificanceDTO.Significance
ehealth-questionnaire-answerSignificance.ehealth-answer-Condition set to AnswerSignificanceDTO.AnswerConditionsDTO
ehealth-answer-Condition.operator set to AnswerConditionsDTO.Operator
ehealth-answer-Condition.value set to the one populated of AnswerConditionsDTO.ValueBoolean , AnswerConditionsDTO.ValueCoding, AnswerConditionsDTO.ValueDecimal, AnswerConditionsDTO.ValueInteger or AnswerConditionsDTO.ValueString
| For every TaskDTO in the ClinicalImpressionDTO.Tasks | Task | ehealth-task-responsible | List of CareTeam from the CarePlan | | ehealth-restriction-category | TaskDTO.RestrictionCategories
| | category | TaskDTO.Category
| | status | requested
| | intent | plan
| | priority | TaskDTO.Priority
| | description | TaskDTO.Description
| | focus | The ClinicalImpression created for the current ClinicalImpressionDTO | | episodeOfCare | Same as GuidanceResponse.episodeOfCare (and CarePlan.episodeOfCare) | | authoredOn | current date/time | For every CommunicationDTO in ClinicalImpressionDTO.Tasks.Communications | Communication (of profile ehealth-message) | category | Coding for message | | status | completed
| | reasonCode | Coding for each CodingDTO in CommunicationDTO.Categories | | payload.content | CommunicationDTO.Text
| | ehealth-title | CodingDTO.Display of first CodingDTO in CommunicationDTO.Categories
| | ehealth-restriction-category | Coding for each CodingDTO in CommunicationDTO.RestrictionCategories | | subject | Same as GuidanceResponse (and CarePlan) | | episodeOfCare | Same as GuidanceResponse (and CarePlan) | | topic | Reference to Task created for current TaskDTO | | sent | current date/time |
For every TaskDTO in AutomatedProcessingDTO.Tasks: Resource | Element | Value |
|---|
Task | ehealth-task-responsible | List of CareTeam from the CarePlan | | ehealth-restriction-category | TaskDTO.RestrictionCategories
| | category | TaskDTO.Category
| | status | requested
| | intent | plan
| | priority | TaskDTO.Priority
| | description | TaskDTO.Description
| | focus | Reference to the measurement | | episodeOfCare | Same as GuidanceResponse.episodeOfCare (and CarePlan.episodeOfCare) | | authoredOn | current date/time | For every CommunicationDTO in TaskDTO.Communications | Communication (of profile ehealth-message) | category | Coding for message | | status | completed
| | reasonCode | Coding for each CodingDTO in CommunicationDTO.Categories | | payload.content | CommunicationDTO.Text
| | ehealth-title | CodingDTO.Display of first CodingDTO in CommunicationDTO.Categories
| | ehealth-restriction-category | Coding for each CodingDTO in CommunicationDTO.RestrictionCategories | | subject | Same as GuidanceResponse (and CarePlan) | | episodeOfCare | Same as GuidanceResponse (and CarePlan) | | topic | Reference to Task created for current TaskDTO | | sent | current date/time |
Taking applicable CommunicationRequest into accountWhen Communication resources (of ehealth-message profile) are created by automated processing, the intended receivers would typically be one or more CareTeam designated as CarePlan.careTeam on the involved CarePlan. As Communication can have at most a single CareTeam as the recipient (through Communication.ehealth-communication-recipientCareTeam), this involves duplication of the original Communication where the duplicates vary by the recipient. The recipient(s) and duplication made for Communication created by automated processing are influenced by CommunicationRequest. By creating appropriately crafted CommunicationRequest, a Practitioner can control whether: The handling is shown in the sequence diagram Automated Processing of Measurements - Create Communications. Activation of suspended Self-treatment type ServiceRequestWhen the AutomatedProcessingDTO specifies activation through the element activateSelfTreatmentset to true, automated processing performs a lookup for all sibling ServiceRequest resources which have: ServiceRequest.status set to suspended
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 ConditionsEach 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. .png?version=1&modificationDate=1687351747762&cacheVersion=1&api=v2) 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: If the measurement references a triggering ServiceRequest (if ServiceRequest.meta.tag is set to trigger) continue, otherwise the check for action triggers is done. Resolve the CarePlan referencing the triggering ServiceRequest Resolve the PlanDefinition referenced by the CarePlan Resolve the triggering ActivityDefinition (referenced from triggering ServiceRequest) and its id in PlanDefinition.action[y].id Determine which depending ServiceRequest (one or more) is depending on the triggering ServiceRequest as follows: For each PlanDefinition.action[x].ehealth-actionTrigger referring in triggerCondition.actionId the triggering PlanDefinition.action[y].id: Resolve the depending ServiceRequest by comparing its reference to the depending ActivityDefintion which must be referenced in the depending PlanDefinition.action[x].definition.
For each depending ServiceRequest, determine whether conditions have been met: If the ServiceRequest.ehealth-trigger-enablement is other than TRIGGER_ENABLED then continue to next depending ServiceRequest, otherwise perform as follows: If the ServiceRequest.status is on-hold continue, continue to next depending on ServiceRequest If the PlanDefinition.action[x].ehealth-actionTrigger has triggerBehavior set to one-or-more Determine whether the ehealth-triggerCondition has been met (searching for measurements and comparing with triggerCoundition.count)
If the PlanDefinition.action[x].ehealth-actionTrigger has triggerBehavior set to all or other triggering ServiceRequest may be defined for this depending on ServiceRequest 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
For each depending ServiceRequest where conditions have been met, perform the actionTrigger’s reaction in actionTrigger.action This is changing ServiceRequest.status to active. The ServiceRequest.occurrence starting time is evaluated: 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 If the occurrence starting time is in the future, the starting time is kept with possible adjustment as specified by actionTrigger.offset
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. |
Scheduled Processing of Missing MeasurementsThe eHealth Infrastructure regularly checks if measurements are being submitted on time based on their associated CarePlan. Here's how it works: It looks at the time since the last check and focuses on the missing measurements during that period. It performs missing measurement checks for the following: All CarePlans that have been active at some point during that period (had statusHistory set to active). All EpisodeOfCare linked to these CarePlans. All ServiceRequests linked to these CarePlans.
Among the ServiceRequests, it narrows down to those with active, historic, or current effective statuses (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2524872705/Using+EpisodeOfCare+CarePlan+s+and+ServiceRequest+s#Determining-the-ServiceRequest-Effective-Status) that overlap with the occurrence of the ServiceRequest ( ServiceRequest.occurrence[x]) within the missing measurement check period. 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 the ConceptMap. If the activity type isn't found in the ConceptMap https://docs.ehealth.sundhed.dk/latest-released/ig/ConceptMap-activitydefinition-code-to-do-missing-measurement.html, the ServiceRequest is subject to the missing measurements check by default.
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: ServiceRequest.occurrence[x] Variant | occurrenceDateTime
| occurrencePeriod
| occurrenceTiming
|
|---|
Data Type | DateTime | Period | | Info |
|---|
Before release FUT-I 2023.5 |
Timing Timing constraints: .repeat.boundsPeriod: contains a Period
.repeat.frequency has a value
.repeat.period has a value
.repeat.periodUnit has a value
and if .repeat.duration has a value then .repeat.durationUnit must also have a value
| Info |
|---|
With the release of FUT-I 2023.5 |
Timing Timing constraints: | Time Criteria | occurrenceDateTime is before the current check datetime and after the last check was performed
and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
| occurrencePeriod.end is before the current check datetime and after the last check was performed
and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
| | Info |
|---|
Before release FUT-I 2023.5 |
The resolved timing end is before the current check datetime and within the lookup period (see lookup period below). The found number of measurements (Observation, QuestionnaireResponse or Media) is less than the expected number of resolved timing(s) within the lookup period determined (see lookup period below).
A lookup period (of time) for measurements is determined as follows: The period starts at Midnight Timing.repeat.period days ago till current time represented as nearest past Midnight when Timing.repeat.periodUnit is d (day) The period starting Midnight 1 day ago till the current time is represented as the nearest past Midnight when Timing.repeat.periodUnit is h (hours) or m (minutes) The period starting Monday Timing.repeat.period weeks ago and ending Timing.repeat.period weeks later when Timing.repeat.periodUnit is wk (week)
| Info |
|---|
With the release of FUT-I 2023.5 |
The resolved timing(s) end within the period between the last job execution and the current job execution. The found number of measurements (Observation, QuestionnaireResponse or Media) is less than the expected number of resolved timing(s) within the period.
| Effective Status Criteria | | | | Measurement Match Criteria | | Info |
|---|
With the release of FUT-I 2023.5 |
|
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. As the time component of boundsPeriod.start is 10 AM that means the next resolved timing is 4 PM and the next 10 PM. The first resolved timing 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 resolved timing 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 timing. The third resolved timing in the lookup period is 10-13 and shall not be checked for missing measurement as ServiceRequest had status on-hold for the whole resolved timing. The fourth resolved timing 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 timing. The fifth resolved timing in the lookup period is 22-01 which shall not be checked for missing measurement as the end of the resolved timing is outside the lookup period, that is, the citizen still has one hour past Midnight to submit measurement(s).
 | Info |
|---|
With Release FUT-I 2023.5 See the diagram below. Going forward all the resolved timing (based on supported timing) ending within the window since the last job execution will be considered. This means no longer based on a fixed range eg. the last day if periodUnit: hour. |
| Gliffy |
|---|
| baseUrl | https://ehealth-dk.atlassian.net/wiki |
|---|
| name | Missing measurement - status check - example with occurrenceTiming FUT-I 2023.5 |
|---|
| pageid | 2562293761 |
|---|
| timestamp | 1691588983731 |
|---|
|
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 1 målinger, men fandt 0 (which is Danish for ‘Expected 1 measurement found 0’)
| | ehealth-task-responsible
| List of CareTeam from the CarePlan | | ehealth-restriction-category
| Coding for measurement-monitoring | | focus
| The ServiceRequest | | 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. Automated Periodic Creation of Reminder on Pending Measurement Activity| Info |
|---|
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: | Info |
|---|
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. | Info |
|---|
Before release FUT-I 2023.5 |
ServiceRequest.occurrence[x] alternative
| ServiceRequest.occurrenceDateTime
| ServiceRequest.occurrencePeriod
| ServiceRequest.occurrenceTiming
|
|---|
Data type | occurrenceDateTime has type DateTime
| occurrencePeriod has type Period
| occurrenceTiming has type Timing with:
| Time Criteria | | 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
| 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 At least one of possibly multiple occurrenceTiming.repeat.dayOfWeek/occurrenceTiming.repeat.timeOfDay combinations must be within the current time window and the occurrenceTiming.repeat.boundsPeriod. If the occurrenceTiming.repeat.boundsPeriod.start is within the previous time window, dayOfWeek/timeOfDay combinations within the previous time window are also accepted (They must still be within the boundsPeriod). The dayOfWeek/timeOfDay-combinations are expressed relatively while the current time windows are expressed absolutely in time, by datetime start and end, respectively. To determine whether a particular dayOfWeek/timeOfDay-combination is within the time window, the dayOfWeek/timeOfDay-combination needs to be determined as an absolute datetime. The current window start datetime is used as a base as follows: The dayOfWeek from the current-time-window start is compared to that of the dayOfWeek/timeOfDay-combination. If they are the same, the current-time-window start date can be used as the date for the dayOfWeek/timeOfDay-combination. Otherwise, the date can be derived from the current-time-window start date and dayOfWeek. As an example, consider the current-time-window start datetime is <Wednesday, Apr 12th, 10:10:00> and the dayOfWeek/timeOfDay-combination to determine is <Thursday at 10:30:00>. In this case, as the dayOfWeek is different, the date of the current window start cannot be used directly. However, based on the current-time-window start being <Wednesday, Apr 12th> it is derived that the next occurrence of the dayOfWeek/timeOfDay-combination <Thursday at 10:30:00> is <Thursday, Apr 13th, 10:30:00>.
| Effective Status Criteria | | | |
| Info |
|---|
With release of FUT-I 2023.5 |
ServiceRequest.occurrence[x] alternative
| ServiceRequest.occurrenceDateTime
| ServiceRequest.occurrencePeriod
| ServiceRequest.occurrenceTiming
|
|---|
Data type | DateTime | Period | Timing Timing constraints: 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 | | 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
| 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). At least one of possibly multiple resolved-timing must start within the current time window and the occurrenceTiming.repeat.boundsPeriod.
| Effective Status Criteria | | | | Activity Type Criteria | | Measurement Submission Criteria | |
Time CriteriaThe 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 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.  Current Time Window = t+2 The periodic lookup has now progressed by two-time frames since the lookup shown in the first diagram. Effective Status CriteriaThe 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. | Info |
|---|
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.  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.  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 CarePlanWhen 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 OrganisationThe 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 EquipmentSome 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 CreatedWhen 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 CareTeamThe EpisodeOfCare and CarePlan have two elements ehealth-episodeofcare-statusscheduleand ehealth-teamschedule which capture: When one of the following elements in CarePlan/EpisodeOfCare is changed, then an ehealth-message type Communication is automatically created. Communication created with the Patient as the recipientResource | 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 recipientResource | 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 AppointmentCommunication with the Patient as the recipientAlso 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: (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 recipientAlso 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: (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 messageCommunication with the Patient as the recipientAlso 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 InfrastructureThe 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 InfrastructureThe following table provides an overview of Tasks produced by the Infrastructure. For more detailed information follow the link in the reference column. Overview of Communication Created by the InfrastructureThe following table provides an overview of Communication (of profile ehealth-message) produced by the Infrastructure and how creation and suppression of creation can be controlled with CommunicationRequest. The table does not provide all elements of either Communication or CommunicationRequest. Please consult particular sections corresponding to the situations for details. Element <some element name> describes what values are used in Communication in a specific situation. 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. | No | Yes | No | 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 | 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. | No | Yes | No | 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. | No | Yes | No | 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. | No | Yes | No | 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 orCarePlanScheduledStatusChange
| No value assigned | | | One Communication for each CareTeam associated with the CarePlan which has not opted out. | No | Yes | No | 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 | 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 | |
| Info |
|---|
Currently, there are no automated processing rules - neither ready for production nor slated for production - that specify or request the creation of Communication. |
|