...
| Excerpt |
|---|
This page and subpages describe the behavior of services in the infrastructure which are not directly invoked by a client. What is described here is what happens when a user performs login, how submitted measurements are processed in automated processing, and how citizens' adherence to care plans are monitored and handled. Also described is the periodic importing of organizations. |
Sub-pages
| Child pages (Children Display) | ||
|---|---|---|
|
Content
| Table of Contents-zone | ||||||
|---|---|---|---|---|---|---|
| ||||||
Handling at LoginWhen a user performs login at the eHealth Infrastructure, various checks are performed and security artifacts (such as the security token) are produced. In addition, certain resources are read, created, or possibly updated. The following applies to users of the Practitioner type. The external security token contains one to many organizational scopes in which the user can have:
For the recognized user roles bound to a recognized and pre-existing CareTeam, it is ensured that:
For all the organizational scopes where the organization identification can be resolved to an Organization in the eHealth Infrastructure, it is ensured that:
|
...
Automated Processing of Submitted Measurement
The Clinical Administrator can define a PlanDefinition, its activities in referenced ActivityDefinition, possible Questionnaire to be answered, and add zero, one or more Library resources each containing a rule. The Library of interest here are those of automated processing type that is attached to a plan for which a measurement has been successfully submitted.
In the following, a measurement resource denotes an Observation, QuestionnaireResponse or Media which has been submitted either by itself or along with other measurement resources in a call of the submit-measurement operation. All the measurement resource(s) submitted together are denoted a measurement.
Overall, the automated processing of a submitted measurement is asynchronous and constitutes the following handling as a response to a submitted measurement event (which contains a reference to a Provenance resource referencing the measurement resources):
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
For each measurement resource, automated processing resolves the ServiceRequest referenced by the measurement resource. The measurement submission time is then compared to the scheduled timing constructs in ServiceRequest.Timing.repeat. The measurement submission time is either of:
Observation.meta.lastUpdatedQuestionnaireResponse.meta.lastUpdatedMedia.meta.lastUpdated
A measurement has been submitted at an unexpected time when:
the scheduled timing is specified as
(Timing.repeat).dayOfWeekand the day of week code is not identical to that corresponding to the measurement submission time, orthe scheduled timing is specified with
(Timing.repeat).timeOfDayand(Timing.repeat).boundsDurationand the measurement submission time is not within the period (start and end included):start of period:
(Timing.repeat).timeOfDayend of period:
(Timing.repeat).boundsDurationadded to(Timing.repeat).timeOfDay
In case the ServiceRequest has ServiceRequest.Period or ServiceRequest.occurenceDateTime then it is not checked.
In case a measurement has been submitted at an unexpected time, automated processing produces:
A Task with
.statusset torequested.episodeOfCareset to the same reference to EpisodeOfCare as used in the measurement resource’s.episodeOfCare.categoryset toUnexpectedMeasurementResolving.focus.referencereferencing the measurement resource (Observation, QuestionnaireResponse, or Media).ehealth-task-responsibleset to same one or more CareTeam as theCarePlan.team(CarePlan found through reverse association from measurement resource’s.basedOnreference to ServiceRequest referred fromCarePlan.activity.reference).descriptionset to “Uventet måling” which is Danish for unexpected measurement
A Communication (of ehealth-message profile) with
.statusset tocompleted.subjectset to the same reference to Patient as used in the measurement resource’s.subject.episodeOfCareset to the same reference to EpisodeOfCare as used in the measurement resource’s.episodeOfCare.categoryset tomessage.reasonCodeset toUnexpectedMeasurementResolving.topic.referencereferencing the Task above.payload.episodeOfCareset to “Uventet måling” which is Danish for unexpected measurement.titleset to “Uventet måling”.senderreferencing a special Device designating the automated processing service
Note that most of the above details do not constitute guaranteed content that can be used for searching for or determining whether unexpected measurement(s) has been submitted for a particular Patient. The guaranteed elements are Task.category (withTask.episodeOfCare) and Communication.reasonCode (with Communication.subject and Communication.episodeOfCare).
Processing of Automated Processing Rules
When a measurement is submitted to the infrastructure, it triggers the automated processing of rules described in the following. Each submitted measurement is related to an activity in a citizen plan represented as a CarePlan where each activity is a ServiceRequest. Which rule or rules are involved depends on the PlanDefinition and its comprised ActivityDefinition resources referenced from the CarePlan and ServiceRequest resources, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Applying-a-PlanDefinition-to-create-CarePlan(s).
An automated processing rule is a Library where Library.type is automated-processing. The existing Library is listed in Library Resources. The automated processing rule Library eligible for a particular ServiceRequest are those zero, one, or more Library related to the ActivityDefinition referenced by the ServiceRequest.
| Info |
|---|
In the Plan editor of the Clinical Administration Application (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2063892483/eHealth+Applications#Clinical-Administration-Application-(Danish%3A-KAM-for-Klinisk-administrativ-modul)), it is possible to select which automated processing rule Library resources if any that shall be related to a plan template activity (ActivityDefinition). |
...
Situation
...
Overrides Eligible Library?
...
Automated Processing Rules
...
Processing
...
Submitted measurement is an Observation with no value (.dataAbsentReason is present)
ServiceRequest references ActivityDefinition with no reference to Library or reference to any other than Null-rule Library
...
Yes
...
All Library are ignored and processing is performed as described
...
A Task is created with Task.category set to Coding MeasurementForAssessmentAbsentValue
...
Submitted measurement is an Observation with no value (.dataAbsentReason is present)
ServiceRequest references ActivityDefinition with reference to Null-rule Library
...
No
...
Null-rule Library is evaluated and processing is performed as described
...
No Task is created.
...
ServiceRequest references ActivityDefinition with reference to 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 Task.category set to Coding MeasurementForAssessment
...
ServiceRequest references ActivityDefinition with reference to Fallback Library
...
No
...
ServiceRequest references ActivityDefinition with reference to 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 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
...
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 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 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 actived if currently suspended.
ClinicalImpressionDTO
...
Property
...
Type
...
Description
...
Code
...
CodingDTO
...
Used for ClinicalImpression.code in created resource.
...
Description
...
String
...
Used for ClinicalImpression.description in created resource.
...
CodeableConceptFindings
...
List of CodingDTO
...
Used for ClinicalImpression.finding.itemCodeableConcept in created resource.
...
ObservationFindings
...
List of ObservationDTO
...
Used for Observation.code of contained Observation in ClinicalImpression.finding.itemReference in 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 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 created resource.
...
Description
...
String
...
Used for Task.description in created resource.
...
Priority
...
String
...
Used for Task.priority in 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 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 created resource.
...
Finding
...
CodingDTO
...
Used for ehealth-questionnaireresponse-finding-basis.findingin created resource.
...
ValueString
...
String
...
One of the value elements are populated and used for ClinicalImpression.ehealth-questionnaireresponse-finding-basis.value in 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 created resource.
...
AnswerConditions
...
List of AnswerConditionDTO
...
Used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition in created resource.
Must be list of size 1 or 2.
AnswerConditionDTO
...
Property
...
Type
...
Description
...
Operator
...
String
...
Used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition.operator in created resource.
...
ValueString
...
String
...
One of the value elements are populated and used for ehealth-questionnaire-answerSignificance.ehealth-answer-Condition.value in created resource.
...
ValueDecimal
...
Double
...
ValueInteger
...
Integer
...
ValueBoolean
...
Boolean
...
ValueCoding
...
CodingDTO
CommunicationDTO
...
Property
...
Type
...
Description
...
Categories
...
List of CodingDTO
...
Used for Communication.reasonCode in created resource.
...
Text
...
String
...
Used for Communication.payload.content in created resource.
...
RestrictionCategories
...
List of CodingDTO
...
Used for Communication.ehealth-restriction-category in 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 furthermore, that the concept is part of the expanded ValueSet for which there is a binding to the particular resource element where it is used.
ObservationDTO
...
Property
...
Type
...
Description
...
Status
...
String
...
Used for Observation.status in created resource.
...
Code
...
CodingDTO
...
Used for Observation.code in created resource.
...
ValueString
...
String
...
One of the value elements are populated and used for Observation.value in 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.Decscription
...
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:
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 same as subject of measurement)
...
episodeOfCare
...
Same as GuidanceResponse.episodeOfCare (which is 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 tofactvalueset to a reference to the parameter.value (from GuidanceResponse.outputParameters)
...
ehealth-questionnaireresponse-finding-basis
...
For each QuestionnaireResponseFindingBasisDTO in ClinicalImpressionDTO.FindingBasis, a 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 the one or more CareTeam designated as CarePlan.careTeam on the involved CarePlan. As Communication can have at most a single CareTeam as recipient (through Communication.ehealth-communication-recipientCareTeam), this involves duplication of the original Communication where the duplicates vary by recipient.
The recipient(s) and duplication made for Communication created by automated processing is influenced by CommunicationRequest. By creating appropriately crafted CommunicationRequest, a Practitioner can control whether:
to suppress automated processing’s default creation of a Communication for a particular CareTeam
to duplicate a Communication with the Patient as recipient
The handling is shown in the sequence diagram Automated Processing of Measurements - Create Communications.
| 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 automated processing of a submitted measurement, the infrastructure examines whether the measurement constitutes fulfillment of trigger conditions that may be defined as action trigger for one or more of its sibling ServiceRequest. In each case where trigger conditions are met, the defined action trigger reaction is performed.
Trigger evaluation is skipped if the submitted measurement is an Observation with .dataAbsentReason. This means that an Observation with .dataAbsentReason will not fire any action triggers.
In the example below, the PlanDefinition contains an action trigger where activity “action[2]” has dependencies to “action[0]” and “action[1]”. Compared to the same setup at time of PlanDefinition$apply (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Trigger-Actions-and-Trigger-Conditions), the CarePlan and triggering ServiceRequest (SR0 and SR1 in the figure below) now have status set to active, presumably because all necessary adjustments and delivering of device etc. have been performed and an employee has changed the status.
...
When a measurement, here QuestionnaireResponse QR0, is submitted and subjected to automated processing, it is determined whether it plays any role in action triggers. In this case, the corresponding ServiceRequest SR0 is a triggering ServiceRequest, that is, its related ActivityDefinition has a trigger condition defined in the corresponding PlanDefinition. To optimize determining this, the triggering ServiceRequest SR0 (and similarly SR1) has ServiceRequest.meta.tag set to trigger automatically as part of PlanDefinition$apply.
The automated processing follows this pseudo-algorithm:
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 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, otherwise continue to next depending 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 by defined for this depending ServiceRequestDetermine whether all
ehealth-triggerConditionhave been met (searching for measurements and comparing withtriggerCoundition.count)Optimized by continuing to next depending ServiceRequest on 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 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 in order to keep the original duration.
...
Timing
...
If the Timing.repeat.bounds is a Period, then bounds period is set as for occurrence of type Period.
Automated Processing of Missing Measurements
The infrastructure has a periodic check whether measurements are being submitted timely according to their CarePlan. The overall approach is to do missing measurements checks covering a time window from last check to ‘now’ and do bookkeeping of when the missing measurements check was last performed. By relying on that missing measurements found during the previous time window would have been handled as part of that check, any current check can consider the period between last check and now only.
| Info |
|---|
The following paragraph applies to eHealth Infrastructure prior to Release 16 This missing measurements check is performed:
|
| Info |
|---|
With eHealth Infrastructure Release 16 The missing measurements check is performed:
|
Whether a particular ServiceRequest shall be subjected to the missing measurements check described below, depends on the activity type (copied from ActivityDefinition.code to ServiceRequest.code on $apply). This is controlled by the infrastructure automated processing by lookup in the ConceptMap https://docs.ehealth.sundhed.dk/latest-released/ig/ConceptMap-activitydefinition-code-to-do-missing-measurement.html. In case an activity type is not found in the ConceptMap, the fallback is to subject the ServiceRequest to missing measurements check.
| Info |
|---|
The following section applies to eHealth Infrastructure prior to Release 16 |
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
...
Criteria
...
occurrenceDateTime
...
Measurement not missing when occurrenceDateTime was before last check.
Measurement missing when occurrenceDateTime is before current check datetime and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
occurrencePeriod
...
Measurement not missing when occurrencePeriod.end was before last check.
Measurement missing when occurrencePeriod.end is before current check datetime and no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
occurrenceTiming
...
Measurement not missing when the determined lookup period (see infobox below) has occurrenceTiming.repeat.boundsPeriod.end that was before last check
Measurement missing when the found number of measurements (Observation, QuestionnaireResponse or Media) is less than the expected number of times (see infobox below) within the lookup period determined (see infobox below).
| Info |
|---|
This applies for With Timing, it is possible to specify that an event (such as the activity described in a ServiceRequest) must be performed or happen a number of times within a certain period.
|
| Info |
|---|
This applies for A lookup period (of time) for measurements is determined as follows:
|
| Info |
|---|
The following section applies to eHealth Infrastructure Release 16 |
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:
.repeat.boundsPeriod: contains a Period.repeat.boundsPeriod.starthas a value
.repeat.frequencyhas a value.repeat.periodhas a value.repeat.periodUnithas a valueand if
.repeat.durationhas a value then.repeat.durationUnitmost also have a value
...
Time Criteria
...
occurrenceDateTimeis before current check datetime and after last check was performedand no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
occurrencePeriod.endis before current check datetime and after last check was performedand no Observation, QuestionnaireResponse or Media referring to the ServiceRequest exist.
...
the resolved occurrence end is before current check datetime and within the lookup period (see row below).
and the found number of measurements (Observation, QuestionnaireResponse or Media) is less than the expected number of occurrences within the lookup period determined (see row below).
A lookup period (of time) for measurements is determined as follows:
Period starting Midnight
Timing.repeat.perioddays ago till current time represented as nearest past Midnight whenTiming.repeat.periodUnitisd(day)Period starting Midnight 1 day ago till current time represented as nearest past Midnight when
Timing.repeat.periodUnitish(hours) orm(minutes)Period starting Monday
Timing.repeat.periodweeks ago and endingTiming.repeat.periodweeks later whenTiming.repeat.periodUnitiswk(week)
...
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 has partial or full overlap with
statusHistoryactive for the resolved occurrence.
| Info |
|---|
The following section applies to eHealth Infrastructure Release 16 |
Example of active overlap for ServiceRequest.occurrenceTiming with repeat.period: 6 and repeat.periodUnit: h (and repeat.duration: 3 and repeat.durationUnit: h).
As described in row “Time Criteria” for occurrenceTiming, Timing.repeat.periodUnit h (hours) will result in a lookup period starting from Midnight 1 day ago till current time represented as nearest past Midnight.
The resolved occurrences will be every 6 hours with a duration of 3 hours starting from Timing.repeat.boundsPeriod.start. As the time component of boundsPeriod.start is 10 AM that means the next resolved occurrence is 16 PM and the next 22 PM.
The first occurrence in the lookup period is 22-01 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest all had status
active.The second occurrence in the lookup period is 04-07 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest had status
activein a partial overlap during the resolved occurrence.The third occurrence in the lookup period is 10-13 shall not be checked for missing measurement as ServiceRequest had status
on-holdfor the whole occurrence.The fourth occurrence in the lookup period is 16-19 which shall be checked for missing measurement as EpisodeOfCare, CarePlan and ServiceRequest had status
activehas partial active overlap during the resolved occurrence.The fifth occurrence in the lookup period is 22-01 which shall not be checked for missing measurement as the end of the occurrence is outside the lookup period, that is, the citizen still has one hour past Midnight to submit measurement(s).
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...
authoredOn
...
current date/time
...
Communication (of profile ehealth-message)
...
category
...
Coding for message
...
status
...
completed
...
reasonCode
...
Coding for MissingMeasurementResolving
...
payload.content
...
Need resolving of 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
...
Reference to Task above
...
sent
...
current date/time
Each Communication resource prepared for creation (with the content above), is subjected to handling of recipients described in Taking applicable CommunicationRequest into account.
Automated Creation of Reminder on Pending Measurement Activity
| Info |
|---|
In the following, pending measurement activity is used broadly as a term for measuring and answering questionnaires that are supposed to happen. |
In order to provide reminders to citizens on pending measurement activities, the eHealth Infrastructure performs periodic lookup. Currently, the periodic lookup is configured to be performed every second hour on the hour.
The periodic lookup for pending measurements considers two lookup time windows:
The current time window:
start datetime: calculated as datetime of next periodic lookup, reduced by the duration between lookups.
end datetime: calculated as datetime of next periodic lookup.
The previous time window:
start datetime: calculated as datetime of current periodic lookup, reduced by the duration between lookups.
end datetime: calculated as datetime of current periodic lookup.
| Info |
|---|
For example: The periodic lookup runs at 08:00. It has a current (lookup) time window of 08:10 to 10:10. It has a previous (lookup) time window of 06:10 to 08:10. |
For an activity to be considered pending, the ServiceRequest.occurrence[x] must be within the ServiceRequest's effective active periods. The effective active periods for a ServiceRequest are the periods of time where it has status set to active at the same time as the EpisodeOfCare and CarePlan both have status set to active, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2524872705/Using+EpisodeOfCare+CarePlan+s+and+ServiceRequest+s#Determining-the-ServiceRequest-Effective-Status. In this particular case, the effective active periods are considered for historic & current status and future status changes, that is, the effective active periods are evaluated based on the statusHistory and statusSchedule elements of EpisodeOfCare, CarePlan and ServiceRequest. This is elaborated in the criteria table below.
The criteria for a ServiceRequest to have a pending measurement within the lookup time window depends on ServiceRequest.occurrence[x] alternative used and are as given in the table below. The table’s Time Criteria and Effect Status Criteria, respectively, are elaborated and exemplified in similarly named subsections below.
...
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:
.repeat.boundsPeriod: contains a Period.repeat.dayOfWeekvalue.
repeat.timeOfDayvalue
...
Time Criteria
...
occurrenceDateTimemust be within the previous time windowAfter the start datetime and before or equal to the end datetime of the previous time window
...
The
occurrencePeriod.startmust be within the previous time windowThe
occurrencePeriod.endmust, if defined, be equal to or after the start of the current time window, orIf both
occurrencePeriod.startandoccurrencePeriod.endare within the previous time window, the ServiceRequest is still considered as having a pending measurement.This ensures that reminders for activities with short periods that lie entirely within a time window are not missed.
...
The
occurrenceTiming.repeat.boundsPeriod.startmust be equal to or before the start of the current time window.The
occurrenceTiming.repeat.boundsPeriod.endmust, if defined, be equal to or after the start of the current time windowAt least one of possibly multiple
occurrenceTiming.repeat.dayOfWeek/occurrenceTiming.repeat.timeOfDaycombinations must be within the the current time window and within theoccurrenceTiming.repeat.boundsPeriod.If the
occurrenceTiming.repeat.boundsPeriod.startis within the previous time window,dayOfWeek/timeOfDaycombinations within the previous time window are also accepted (They must still be within theboundsPeriod).This ensures that while they might be late, they are not missed entirely.
The
dayOfWeek/timeOfDay-combinations are expressed relatively while the current time windows is expressed absolutely in time, by datetime start and end, respectively. In order to determine whether a particulardayOfWeek/timeOfDay-combination is within the time window, thedayOfWeek/timeOfDay-combination needs to determined as an absolute datetime. The current window start datetime is used as a base as follows: ThedayOfWeekfrom the current-time-window start is compared to that of thedayOfWeek/timeOfDay-combination. If they are the same, the current-time-window start date can be used as the date for thedayOfWeek/timeOfDay-combination. Otherwise, the date can be derived from the current-time-window start date anddayOfWeek.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 thedayOfWeekare different, the date of the current window start cannot be used directly. However, based on the the current-time-window start being <Wednesday, Apr 12th> it is derived that the next occurrence of thedayOfWeek/timeOfDay-combination <Thursday at 10:30:00> is <Thursday, Apr 13th, 10:30:00>.
...
Effective Status Criteria
...
occurrenceDateTimemust be within a period of time where the ServiceRequest, CarePlan and EpisodeOfCare are all active
...
The
occurrencePeriodmust to some degree overlap with a period of time 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
dayOfWeek/timeOfDay-combinations must be within a period of time where the ServiceRequest, CarePlan and EpisodeOfCare are all active.
Time Criteria
The following three diagrams show 8 examples of ServiceRequest that use different variants of occurrenceDateTime/occurrencePeriod/occurrenceTiming as the periodic lookup progresses along a timeline. This helps visualize when the above-mentioned criteria are satisfied and thus, when a reminder will be automatically generated for the pending activities.
O - Annotates a
dayOfWeek/timeOfDay-combinationX - Annotates the dateTime in an
occurrenceDateTimeRed - 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.
| Gliffy | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Current Time Window = t0
In the first diagram, the 1. ServiceRequest example is the only one to result in reminder generation
This is due to it being an
occurrencePeriodwith the start of the period being inside the previous time window.
Some things to note about the examples that will not result in reminder generation this lookup:
The 2. ServiceRequest example will not result in a reminder during this lookup time window as its start is after the beginning of the current time window. However, in the next lookup its situation should be the same as for the 1. ServiceRequest example above.
While 6. ServiceRequest has a
boundsPeriodthat starts before the current window, it is anoccurrenceTimingand therefore also needs adayOfWeek/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 adayOfWeek/timeOfDay-combination coincides with a "current" time window.Additionally, while 7. ServiceRequest example has a
dayOfWeek/timeOfDay-combination within the current time window, theboundsPerioddid not start before the current window, as is required.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Current Time Window = t+1
The periodic lookup has now progressed by one time frame and what was in the last lookup considered the “next” time window is now the current one.
In this lookup multiple of the occurrences result in the generation of reminders
2. ServiceRequest example is an
occurrencePeriodand from the perspective of the current time window the start of the period is now in the previous time window3. ServiceRequest example is an
occurrenceTiming. TheboundsPeriodof the timing starts before the beginning of the current window, and additionally there is adayOfWeek/timeOfDay-combination within theboundsPeriodand current time window.7. ServiceRequest example is very much like 3. ServiceRequest example, however, the
dayOfWeek/timeOfDay-combination is within the previous time window.When a
boundsPeriodof a Timing starts in the previous time window, thedayOfWeek/timeOfDay-combinations from the previous time window will also result in reminder generation.
8. ServiceRequest example will also result in reminder generation during this lookup as it is now within the previous time window.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Current Time Window = t+2
The periodic lookup has now progressed by two time frames since the lookup shown in the first diagram.
In this lookup multiple of the occurrences result in the generation of reminders
4. ServiceRequest example will result in a reminder. When an
occurrencePeriodstarts and ends in the previous time window it will generate a reminder.5. ServiceRequest example is now in the same situation as 1. ServiceRequest example and 2. ServiceRequest example were earlier (period start in the previous time window and end after the beginning of the current time window).
6. ServiceRequest example will now result in a reminder as there is a
dayOfWeek/timeOfDay-combination in the current time window.
Effective Status Criteria
The following three diagrams visualize how ServiceRequest effective periods of status set to active are found and evaluated. The ServiceRequest, CarePlan and EpisodeOfCare all maintain a status history and schedule, which is used to find the active periods where all three related resources had/have status value active at the same time.
In the diagram below is an example of how the active periods are found for a resource, based on the
statusHistoryand astatusSchedule.Marked with a vertical starting line and a following horizontal line are the period of a
status(The color depends on status: yellow=draft, green=active, orange=on-hold)Dotted line represents an open ended period (in
statusHistorythis means that the status is the one currently held by the resource)
Marked with X are the
statusScheduleof the resource, marking the intended change to a given status at that time (The color scheme is the same as for the periods).The vertical grey dotted lines show the bounds of the found active periods of the resource.
| 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 precedent over the old status. |
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
For the above example the active periods for the resource are found by:
First one is the started by the ongoing active period and ended by the first scheduled
on-holdstatus.The second one is entirely outlined by the
statusScheduleas it starts when the status is scheduled to becomeactiveand ends at the time of the next scheduled status change, in this case toon-hold.
When the active periods for the individual related resources have been found, one can find the effective active periods of the ServiceRequest, which is the active periods that it has in common with its related CarePlan and EpisodeOfCare. This is visualized in the diagram below.
Periods 6 and 7 are the found effective active periods of the ServiceRequest - The other periods represent individual resources active periods.
The grey vertical dotted lines show which resource’s active period is the bounding factor for the effective active period.
For example: For Period 6 one can see that Period 4, the ServiceRequest active period, is much bigger than the effective active period. This is because of the late start of Period 3 in the CarePlan and the early end of Period 1 in the EpisodeOfCare, which becomes the bounding factor for the effective active period.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In the diagram below are 6 examples of ServiceRequest that use different variants of occurrenceDateTime/occurrencePeriod/occurrenceTiming. This helps visualize when the earlier-mentioned criteria are satisfied for both the time windows and the active periods, and thus, when a reminder will be automatically generated for the pending activities.
The two active periods shown at the top of the time windows represent the periods of time where the ServiceRequest, CarePlan and EpisodeOfCare are all active and thus the time that the
ServiceRequest.occurrence[x]should to some degree overlap.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The
ServiceRequest.occurrence[x]examples marked green are the ones that will result in reminder generation. (Note: All examples adhere to the given time window criteria for reminder generation)The
occurrenceDateTimein example 1 will NOT result in a reminder as it is not within an active period, even though it is in the previous time window.In example 2 on the other hand the
occurrenceDateTimeuphold both being within an active period and being in the previous time window and will therefore result in a reminder.The
occurrencePeriodin example 3 will NOT result in reminder generation as it does not overlap any active period.The
occurrencePeriodin example 4 overlaps with an active period. Therefore, even though the active period is after the current lookup time window, it results in a reminder being generated.For
occurrenceTimingthe it is the thedayOfWeek/timeOfDay-combinations that should be in an active period. For that reason example 5 will NOT result in reminder generation.Lastly, in example 6 the
occurrenceTiminghas adayOfWeek/timeOfDay-combination within an active period, which results in reminder generation.
Having identified a pending measurement, the infrastructure creates an ehealth-message type Communication with the Patient as recipient, unless such creation has been suppressed (see Controlling Creation of Messages).
...
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
...
|
...
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. Prerequisite to this is that the citizen has subscribed to NemSMS and that the citizen has not suppressed generation of such message (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2415034369/Controlling+Creation+of+Messages#Controlling-Message-Creation-with-Patient-as-Recipient).
Validation of SSL orders when activating a CarePlan
When a CarePlan changes status to active, the infrastructure checks if any related SSL orders are still undelivered. If this is the case, then the Patient may still be missing necessary equipment. The infrastructure creates a task with category: OpenSSLOrder for the CareTeam to check if any equipment is missing and if necessary delay the activation of the CarePlan or adjust the measurement regime for specific measurement.
Automated Application of Planned Changes (EpisodeOfCare, CarePlan and ServiceRequest)
Scheduled changes in EpisodeOfCare, CarePlan and ServiceRequest are applied during an automatic job which runs at a regular interval.
...
|
...
The scheduled changes are then applied to the resources, so that they are up to date with their latest scheduled change.
Task Created by the Infrastructure
The Infrastructure automatically creates Task resources of profile ehealth-task in different situations.
Overview of Task created by the Infrastructure
The following table provides an overview of Tasks produced by the Infrastructure. For more detailed information follow the link in the reference column.
...
Situation/trigger
...
Task.category
...
Reference
...
Measurement submitted at unexpected time
...
UnexpectedMeasurementResolving
...
...
Missing measurement
...
MissingMeasurementResolving
...
...
Measurement submitted with Data Absent Reason
...
MeasurementForAssessmentAbsentValue
...
...
Automated processing rule: FallbackRule
...
MeasurementForAssessment
...
...
Automated processing rule: Assessment of Absolute Reference Ranges
Based on the highest alert level found
...
MeasurementForAssessment
...
...
Automated processing rule: Assessment of Absolute Reference Ranges
Error: No absolute reference range found
...
MeasurementForAssessment
...
...
Automated processing rule: Assessment of Absolute Reference Ranges
Error: Unit mismatch between reference range and observation value
...
Creates two tasks:
MeasurementForAssessmentFailureInAutoProcessing
RefRangeFixingNeeded
...
...
Automated processing rule: Assessment of Absolute Reference Ranges
Error: Missing observation value
...
Creates two tasks:
MeasurementForAssessmentFailureInAutoProcessing
LibraryUseMismatchFixingNeeded
...
...
Automated processing rule: Assessment of Relative Reference Ranges
Based on the highest alert level found
...
MeasurementForAssessment
...
...
Automated processing rule: Assessment of Relative Reference Ranges
Error: Neither reference base nor relative reference range(s) found
...
MeasurementForAssessmentNotTriaged
...
...
Automated processing rule: Assessment of Relative Reference Ranges
Error: No reference base found
...
Creates two tasks:
MeasurementForAssessmentNotTriaged
RefBaseNeeded
...
...
Automated processing rule: Assessment of Relative Reference Ranges
Error: No relative reference range found
...
Creates two tasks:
MeasurementForAssessmentNotTriaged
RefRangeNeeded
...
...
Automated processing rule: Assessment of Questionnaire Response
...
MeasurementForAssessment
...
...
Automated processing rule: Assessment of Questionnaire Response
no-effective-answer-significance or no-answer-significance-defined
...
MeasurementForAssessmentNotTriaged
...
...
Automated processing rule: Assessment of TeleCare Nord COPD Questionnaire
...
MeasurementForAssessment
...
...
When a CarePlan has been activated and there is an open SSL Order
...
OpenSSLOrder
...
...
When expiration date for device calibration has exceeded
...
CalibrationNeeded
...
Task Created for Calibration of Equipment
Some equipment needs to be periodically calibrated to ensure precise measurements. The Device service runs a nightly job that checks if any devices are in need of calibration. If that is the case then a Task is created with category set to CalibrationNeeded. The Task is assigned to the CareTeam(s) for the CarePlan that currently uses the Device.
Communication Created by the Infrastructure
The Infrastructure automatically creates Communication resources of profile ehealth-message in different situations.
Overview of Communication created by the Infrastructure
The following table provides an overview of Communication (of profile ehealth-message) produced by the Infrastructure and how creation and suppression of creation can be controlled with CommunicationRequest.
| Info |
|---|
For information regarding how to control creation and content of Communcations see Controlling Creation of Messages . |
The table does not provide all elements of neither Communication nor CommunicationRequest. Please consult particular sections corresponding to the situations for details. Element <some element name> describes what values are used in a Communication in the specific situation.
...
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 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 exection 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
...
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 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 have an agreedDateFrom – reminder days = current day
...
Yes
...
No
...
No
...
advice
...
ExpectedDelivery
...
measuring-support
...
nemsms when Nem SMS is enabled for the Patient at time of sending the Communication, otherwise no medium is set.
...
Patient
| Info |
|---|
Currently, there are no automated processing rules - neither ready for production or slated for production - that specifies or requests creation of Communication. |
Communication Created on Creation of EpisodeOfCare and CarePlan
When an EpisodeOfCare is created with $create-episode-of-care, two ehealth-message type Communication are automatically created. These correspond to the Communication created for change of EpisodeOfCare status and team, respectively.
When a CarePlan is created with $apply performed on a PlanDefinition, two ehealth-message type Communication are automatically created. These correspond to the Communication created for change of CarePlan status and team, respectively. Such a pair of Communication is created for each sub-CarePlan.
Communication Created on Change of EpisodeOfCare and CarePlan Status, CareTeam, Scheduled Status and/or Scheduled CareTeam
The EpisodeOfCare and CarePlan have been extended with elements ehealth-episodeofcare-statusscheduleand ehealth-teamschedule which capture:
planned changes in
EpisodeOfCare.statusandEpisodeOfCare.teamplanned changes in
CarePlan.statusandCarePlan.careTeam
When one of the following elements in CarePlan/EpisodeOfCare is changed, then an ehealth-message type Communication is automatically created.
status
team
ehealth-episodeofcare-statusschedulehealth-teamschedule
Communication created with Patient as recipient
...
Resource
...
Element
...
Value
...
Communication (of profile ehealth-message)
...
category
...
Coding for message
...
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 situation
...
sent
...
current date/time
...
recipient
...
The Patient
...
sender
...
Device reference for eHealth Infrastructure Device
Communication created with CareTeam as recipient
...
Resource
...
Element
...
Value
...
Communication (of profile ehealth-message)
...
category
...
Coding for message
...
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 situation
...
sent
...
current date/time
...
ehealth-communication-recipientCareTeam
...
The CareTeam
...
sender
...
Device reference for eHealth Infrastructure Device
Communication Created as Reminder for Participation in Appointment
Communication with Patient as recipient
...
Resource
...
Element
...
Value
...
Communication (of profile ehealth-message)
...
category
...
Coding for message
...
status
...
completed
...
payload.content
...
One of:
“Husk din aftale den %. Se den i din telemedicinske løsning.“
“Husk din videoaftale den %. Åbn din telemedicinske løsning for at deltage i videomødet.“
(Unless otherwise stated by matching CommunicationRequest)
...
sent
...
current date/time
...
medium
...
Coding for NemSMS (unless otherwise stated by matching CommunicationRequest)
...
recipient
...
The Patient
...
sender
...
Device reference for eHealth Infrastructure Device
Communication with CareTeam as recipient
...
Resource
...
Element
...
Value
...
Communication (of profile ehealth-message)
...
category
...
Coding for message
...
status
...
completed
...
payload.content
...
One of:
“Husk din aftale den %. Se den i din telemedicinske løsning.“
“Husk din videoaftale den %. Åbn din telemedicinske løsning for at deltage i videomødet.“
(Unless otherwise stated by matching CommunicationRequest)
...
sent
...
current date/time
...
medium
...
Coding for NemSMS (unless otherwise stated by matching CommunicationRequest)
...
recipient
...
The CareTeam
...
sender
...
Device reference for eHealth Infrastructure Device
Communication Created as NemSMS Notification on Message Type Communication
Communication 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
Sharing through Registering Documents in National Document Sharing Infrastructure
Some FHIR resources in the eHealth Infrastructure are assembled to volatile FHIR Compositions (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Preparing-Transformations-by-Assembling-Required-FHIR-Resources), transformed to Danish profiles of Clinical Document Architecture (CDA) documents (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Transformation-Details), and registered in the national health document sharing archives. This way, the health data registered can be accessed by the patient and other healthcare professionals through other health systems whilst subjected to various access controls and audit logging.
This description focuses on the criteria for this registering to take place.
Document Registering of Measurements
Submitted measurements, whether in the form Observation, QuestionnaireResponse or Media, are each associated with a ServiceRequest. As part of being evaluated by a Practitioner, each measurement can be approved for sharing in the form of a ClinicalImpression with element ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing.
The criteria for registering a measurement as document are:
The
ServiceRequest.ehealth-sharingPolicymust specify sharing allowed and, currently, that this is sharing with a national health archive as destinationThere must exist a ClinicalImpression referring to the measurement with
ClinicalImpression.ehealth-clinicalimpression-decisionset to a Coding forapproved-for-sharingThe measurement must be an Observation or QuestionnaireResponse
For a QuestionnaireResponse it must be a response to a Questionnaire:
for which a representation as Danish profile of CDA Questionnaire Form Definition Document (QFDD) exists
for which the location of the QFDD is known in the infrastructure.
For an Observation, it must not specify a data absent reason (
.dataAbsentReason). Observations without a value can't be document shared with CDA Personal Health Monitoring Report (PHMR).
An Observation is registered as a Danish profile of the CDA Personal Health Monitoring Report (PHMR) document and a QuestionnaireResponse as a Danish profile of the CDA Questionnaire Response Document (QRD) document.
| Info |
|---|
How must the location of externally accessible QFDD be known to the infrastructure? There shall be a:
|
Document Registering of Appointments
A created or updated Appointment (whether of profile ehealth-appointment or ehealth-videoappointment) are registered as the Danish profile of the CDA Appointment Document (APD), provided that criteria are met.
The criteria for registering an Appointment resource are:
The
Appointment.ehealth-legalBasismust be present and designate a legal basis for which national document sharing infrastructure has been established - currently this is the case for Healthcare Act only.The
Appointment.ehealth-releasebleResourcemust, if present, be set to true.The Appointment has exactly one Patient as participant
...
|
...