| Excerpt |
|---|
The eHealth Infrastructure has several automated processing processes that are performed either scheduled or as a result of an event |
...
. This page describes the automated processing performed by the eHealth Infrastructure. |
| Table of Content Zone | ||||||
|---|---|---|---|---|---|---|
| ||||||
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. |
...
Automated processing is either triggered by some event or actions in the |
...
infrastructure, |
...
which is timer-based, meaning the processing takes place at certain intervals. Scheduled processing
|
...
1.30 every night in all environments
...
...
*) When there is a timezone change (to daylight saving time, DST), the execution is still at local Danish time. Event-based processing
|
...
|
...
...
Validation of SSL orders
...
CarePlan activated
|
...
...
|
...
|
...
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
Automated Processing of Submitted Measurement
...
Automated Processing of Submitted MeasurementThe Clinical Administrator can set up a PlanDefinition, which includes activities defined in an ActivityDefinition. They can also include a Questionnaire to be answered, and add one or more Library resources, each containing a rule. Their Libraries are specifically for automated processing and are linked to a plan that has received a measurement. In the following, a measurement resource denotes an Observation, QuestionnaireResponse or Media which has been submitted either by itself or along with other measurement resources in a call of the Overall, the automated processing of a submitted measurement is asynchronous and constitutes the following handling as a response to a submitted measurement event (which contains a reference to a Provenance resource referencing the measurement resources): |
...
Before release 2024.1
|
...
| Info |
|---|
With release 2024.1
|
...
The automated processing of submitted measurements is shown in the sequence diagram Automated Processing of Measurements. Automated Approval of Measurement for Document Sharing |
Each measurement is evaluated separately using the ServiceRequest referenced by the measurement.
...
Approval of document sharing a measurement, that is, registering a measurement in the national document sharing infrastructure, is considered an assessment of the measurement and comes in the form of a ClinicalImpression resource. |
...
Whether a measurement is eligible for automated approval is evaluated by using the ServiceRequest referenced by the measurement. If the |
...
|
...
|
...
|
...
|
...
Automated Processing of Measurements Submitted at Unexpected TimeThe 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 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 Automated Processing of |
...
Library 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). |
...
The Library rules eligible for automated processing |
...
for a particular ServiceRequest are:
|
...
|
...
|
...
|
...
|
...
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
| Info |
|---|
For further details and to assist in understanding intended use and capabilities, please consult Example Library Resources. For guidance in rule and Library governance and management, please consult Rule and Library Management. |
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:
...
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 Facts
If 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 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 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 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:
...
Resource
...
Element
...
Value
...
ClinicalImpression
...
code
...
ClinicalImpressionDTO.Code
...
status
...
completed
...
description
...
ClinicalImpressionDTO.Description
...
investigation.code
...
Coding with:
codeset to271336007systemset tohttp://snomed.info/sct(SNOMED CT)displayset toExamination/signs
...
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.codeset to one corresponding toObservationDTO.CodeObservation.statusset toObservationDTO.StatusObservation.valueset to the one populated ofObservationDTO.ValueString,ObservationDTO.ValueBooleanorObservation.ValueQuantity.ObservationDTO.episodeOfCareset toGuidanceResponse.episodeOfCareObservationDTO.subjectset toGuidanceResponse.subjectObservationDTO.performerset toGuidanceResponse.subjectObservationDTO.effectiveset to current date/timeObservationDTO.deviceset to a reference to a Device representing the automated processing systemObservationDTO.basedOnset 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:
An added
parameterwith:nameset tolibraryvaluereferring to the Library fromGuidanceResponse.module.relatedArtifact.resource
An added
parameterfor each parameter named fact in GuidanceResponse.outputParameters with:nameset tofactthe valueset to a reference to the parameter.value (from GuidanceResponse.outputParameters)
...
ehealth-questionnaireresponse-finding-basis
...
For each QuestionnaireResponseFindingBasisDTO in ClinicalImpressionDTO.FindingBasis, an ehealth-questionnaireresponse-finding-basis is added with:
ehealth-questionnaireresponse-finding-basis.linkIdset toQuestionnaireResponseFindingBasisDTO.LinkIdehealth-questionnaireresponse-finding-basis.valueset to the one populated ofQuestionnaireResponseFindingBasisDTO.ValueString,QuestionnaireResponseFindingBasisDTO.ValueBoolean,QuestionnaireResponseFindingBasisDTO.ValueInteger,QuestionnaireResponseFindingBasisDTO.ValueDecimcalorQuestionnaireResponseFindingBasisDTO.ValueCodingehealth-questionnaireresponse-finding-basis.findingset toQuestionnaireResponseFindingBasisDTO.Findingehealth-questionnaireresponse-finding-basis.ehealth-questionnaire-answerSignificanceset toQuestionnaireResponseFindingBasisDTO.AnswerSignificanceDTOehealth-questionnaire-answerSignificance.significanceset toAnswerSignificanceDTO.Significanceehealth-questionnaire-answerSignificance.ehealth-answer-Conditionset toAnswerSignificanceDTO.AnswerConditionsDTOehealth-answer-Condition.operatorset toAnswerConditionsDTO.Operatorehealth-answer-Condition.valueset to the one populated ofAnswerConditionsDTO.ValueBoolean,AnswerConditionsDTO.ValueCoding,AnswerConditionsDTO.ValueDecimal,AnswerConditionsDTO.ValueIntegerorAnswerConditionsDTO.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 account
When 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:
to suppress automated processing’s default creation of a Communication for a particular CareTeam
to duplicate Communication with the Patient as the recipient
The handling is shown in the sequence diagram Automated Processing of Measurements - Create Communications.
| Info |
|---|
See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/edit-v2/2415034369 on what values to use when creating CommunicationRequest. |
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:
ServiceRequest.statusset tosuspendedServiceRequest.definitionreferencing an ActivityDefinition whereActivityDefinition.topichas valueself-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 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.
...
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.tagis set totrigger) 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].idDetermine which depending ServiceRequest (one or more) is depending on the triggering ServiceRequest as follows:
For each
PlanDefinition.action[x].ehealth-actionTriggerreferring intriggerCondition.actionIdthe triggeringPlanDefinition.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-enablementis other thanTRIGGER_ENABLEDthen continue to next depending ServiceRequest, otherwise perform as follows:If the
ServiceRequest.statusison-holdcontinue, continue to next depending on ServiceRequestIf the
PlanDefinition.action[x].ehealth-actionTriggerhastriggerBehaviorset toone-or-moreDetermine whether the
ehealth-triggerConditionhas been met (searching for measurements and comparing withtriggerCoundition.count)
If the
PlanDefinition.action[x].ehealth-actionTriggerhastriggerBehaviorset toallor other triggering ServiceRequest may be defined for this depending on ServiceRequestDetermine whether all
ehealth-triggerConditionhave been met (searching for measurements and comparing withtriggerCoundition.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.actionThis is changing
ServiceRequest.statustoactive.The
ServiceRequest.occurrencestarting 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.offsetIf 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-enablementtoTRIGGER_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 Measurements
The 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
statusHistoryset toactive).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.codeand copied toServiceRequest.codeduring 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
...
...
...
Timing constraints:
The Timing should be structured as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#When-an-Activity-is-Supposed-to-Happen---The-Notion-of-Resolved-Timing.
When the infrastructure resolves a Timing, it classifies it as one of four types as described by
TimingTypein https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#How-to-interpret-output-from-get-patient-procedures.Only Timing classified as type
Resolvedare eligible to produce missing measurement.
...
Time Criteria
...
occurrenceDateTimeis before the current check datetime and after the last check was performedand no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
occurrencePeriod.endis before the current check datetime and after the last check was performedand no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
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
...
ServiceRequest, CarePlan and EpisodeOfCare have
statusHistoryactive atoccurrenceDateTime
...
ServiceRequest, CarePlan and EpisodeOfCare have partial or full overlap with
statusHistoryactive foroccurrencePeriod
...
ServiceRequest, CarePlan and EpisodeOfCare have partial or full overlap with
statusHistoryactive for the resolved timing.
...
Measurement Match Criteria
A measurement (Observation, QuestionnaireResponse and Media) is matched based on the following:
...
The measurement.basedOn on references the ServiceRequest
...
The measurement.resolvedTiming.start is the same as the start of the resolved-timing in question.
...
The measurement.resolvedTiming.end is the same as the end of the resolved-timing in question.
...
The evaluation of automated-processing type Library resources is described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2727247913/Managing+and+Using+Library+Rules#Library-Rule-Evaluation-in-Automated-Processing-in-the-Infrastructure . Automated Processing of Action Triggers and Trigger 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 triggers 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 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 .png?version=1&modificationDate=1687351747762&cacheVersion=1&api=v2&width=1043) 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 The automated processing follows this pseudo-algorithm:
The evaluation of starting time is tabulated below for the different types of
Automated Processing can reject tasks created for Missing MeasurementsIf a measurement is submitted later than the timing specified by the ServiceRequest, then the automated processing will check, if a “missing measurement” task exists (created by Automated Processing of Missing Measurements). If the task has status, requested, and has not been assigned, then the automated processing will change the status to rejected. Automated Processing of Missing MeasurementsThe eHealth Infrastructure continuously monitors, if measurements are being submitted on time, based on their associated CarePlan. Here's how it works:
The criteria for deciding that a measurement is missing depends on how the measurement regime is specified, that is, what
Example of active overlap for As described in a row “Time Criteria” for | ||||||||||||||||||||||||||||||
...
With |
...
at midnight, then the first resolved timing will be between 00 and 03, and the next will be between 06 and 09 and so on.
|
...
|
...
|
...
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 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).
...
See the diagram below.
When a measurement is found to be missing, the following resources are prepared for creation:
|
...
|
...
Each Communication resource prepared for creation (with the content above), is subjected to the handling of recipients described in Taking applicable CommunicationRequest into account. Periodic Creation of Reminder on Pending Measurement Activity
To provide reminders to citizens on pending measurement activities, the eHealth Infrastructure performs periodic lookup. Currently, the periodic lookup is configured to be performed every second hour on the hour. The periodic lookup for pending measurements considers two lookup time windows:
|
...
|
...
|
...
For an activity to be considered pending, the The criteria for a ServiceRequest to have a pending measurement within the lookup time window depends on the
|
...
|
...
This ensures that reminders for activities with short periods that lie entirely within a time window are not missed.
...
The occurrenceTiming.repeat.boundsPeriod.start must be equal to or before the start of the current time window.
...
|
...
If the occurrenceTiming.repeat.boundsPeriod.start is within the previous time window, resolved-timing started before the current window is also accepted (They must still overlap with the boundsPeriod).
This ensures that while they might be late, they are not missed entirely.
...
At least one of possibly multiple resolved-timing must start within the current time window and the occurrenceTiming.repeat.boundsPeriod.
...
Effective Status Criteria
...
occurrenceDateTimemust be within a period where the ServiceRequest, CarePlan and EpisodeOfCare are all active
...
The
occurrencePeriodmust to some degree overlap with a period where the ServiceRequest, CarePlan and EpisodeOfCare are all activeThe overlapping part of the periods does not have to be within the current or previous time windows (see example 4 in the table below)
...
At least one of possibly multiple
resolved-timingmust be within a period where the ServiceRequest, CarePlan and EpisodeOfCare are all active.
...
Activity Type Criteria
...
The
ServiceRequestmust have an activity type that warrants a reminder http://ehealth-documentation.s3-website-eu-west-1.amazonaws.com/latest/ig/ConceptMap-activitydefinition-code-to-do-reminder.html.
...
Measurement Submission Criteria
A check is performed to see if any measurements have already been submitted - If all expected measurements have been submitted for a given ServiceRequest, no reminder will be generated.
For a measurement to be seen as a submission for a given resolved-timing of a ServiceRequest it should meet the following criteria:
...
The measurement.basedOn on references the ServiceRequest
...
The measurement.resolvedTiming.start is the same as the start of the resolved-timing in question.
...
Time CriteriaThe following three diagrams show 8 examples of ServiceRequest that use different variants of
| |||||||||||||||
...
 Current Time Window = t0
|
...
 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
|
...
For the above example, the active periods for the resource are found by:
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
|
...
Having identified a pending measurement, the infrastructure creates an ehealth-message type Communication with the Patient as the recipient, unless such creation has been suppressed (see Controlling Creation of Messages).
When possible, the created Communication leads to a NemSMS text notification to the Citizen. A prerequisite to this is that the citizen has subscribed to NemSMS and that the citizen has not suppressed the generation of such messages (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-Patient-as-Recipient). Validation of SSL orders when activating a CarePlanWhen a CarePlan changes 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.
Scheduled Import of Organization Data from SOR and FK OrganisationThe eHealth Infrastructure |
...
runs scheduled jobs that Import |
...
Organization Data from SOR and FK Organisation. The import of Organization data is described in Importing and updating Organization information from SOR and FK-Organisation into eHealth Infrastructure. Scheduled Check for Calibration of EquipmentSome equipment needs to be periodically calibrated to ensure precise measurements. Handling of EpisodeOfCare and CarePlan CreatedWhen an EpisodeOfCare is created with When a CarePlan is created with Handling of Change of EpisodeOfCare and CarePlan Status, CareTeam, Scheduled Status and/or Scheduled CareTeamThe EpisodeOfCare and CarePlan have two elements
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 recipient
|
...
Communication created with CareTeam as the recipient
Reminder for Participation in AppointmentCommunication with the Patient as the recipient
Communication with CareTeam as the recipient
Handling of Automatic NemSMS Notification on Creation of Communication of Type |
Resource | Element | Value |
|---|---|---|
Communication (of profile ehealth-message) | category | Coding for |
status |
| |
payload.content | “Du har modtaget en ny besked. Se den i din telemedicinske løsning.” | |
about | The Communication resource that caused this notification | |
sent | current date/time | |
recipient | The Patient | |
sender | Device reference for eHealth Infrastructure Patient |
Resources Created by Automated Processing in the Infrastructure
The Infrastructure automatically creates Task resources for profile ehealth-task and Communication resources for profile ehealth-message in different situations. An overview is provided for each resource type in the following.
Overview of Task Created by the Infrastructure
The following table provides an overview of Tasks produced by the Infrastructure. For more detailed information follow the link in the reference column.
Situation/Trigger | Task.category | Reference |
|---|---|---|
Measurement submitted at an unexpected time | UnexpectedMeasurementResolving | |
Missing measurement | MissingMeasurementResolving | |
Measurement submitted with Data Absent Reason. | MeasurementForAssessmentAbsentValue |
...
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.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
...
|
...
|
...
|