As described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Overview-of-Communication-produced-by-the-Infrastructure, the eHealth Infrastructure automatically creates FHIR Communication (of profile https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-message.html) in various situations.
It is possible to control if and how these FHIR Communication are created through use of FHIR CommunicationRequest (https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-communication-request.html ).
In the descriptions below, the terms opt-in and opt-out are used with the following meaning:
Opt-in: Use of CommunicationRequest by a Patient or CareTeam to get a copy of a Communication (profile ehealth-message) where the Patient or CareTeam is not recipient of the default Communication.
Opt-out: Use of CommunicationRequest by a Patient or CareTeam to suppress creation of the default Communication to the said Patient or CareTeam.
A CareTeam must be involved in an EpisodeOfCare or CarePlan in order to opt-in for Communication referring the EpisodeOfCare and/or CarePlan and/or ServiceRequest.
Adding Control of Creation of Message
To control automatic creation of FHIR Communication, create a CommunicationRequest. In addition to the CommunicationRequest elements described below, certain elements must have specific values depending on the situation in which the Infrastructure automatically creates the Communication. See the subsections below.
CommunicationRequest:
subject
= Patient referenceoccurrencePeriod.start
= start of period for which the control appliesoccurrencePeriod.end
= end of period for which the control applies, if known. Otherwise it can be left empty.status
=active
when control is in effect. Can be set to other values as appropriate (one ofdraft | active | on-hold | revoked | completed
).doNotPerform
=false
(or unset) for opt-in or override of medium/payload,true
in order to opt-out (that is, to suppress creation)
For now, doNotPerform
set to true
shall be accompanied by setting status
= on-hold
.
Controlling Creation of Message with Patient as Recipient
The table below describes the various situations in which automatic creation of FHIR Communication (ehealth-message) takes place. In the table, the columns following the naming pattern Element <some element name> describe what values must be used in a corresponding CommunicationRequest in order to control creation.
To apply for FHIR Communication with the Patient as recipient, add the following to the CommunicationRequest:
recipient
= Patient referencecategory
= <depending on situation>reasonCode
= <depending on situation>episodeOfCare
= <depending on situation>basedOn
= <depending on situation>priority
= <depending on situation>
Situation | Created by Default | Opt-in Supported | Opt-out Supported | Payload and Medium Overridable | Element category | Element reasonCode | Element episodeOfCare | Element basedOn | Element priority |
---|---|---|---|---|---|---|---|---|---|
Unexpected measurement submitted | No | Yes | No | Yes |
|
| ServiceRequest reference | routine | |
Missing measurement determined | No | Yes | No | Yes |
|
| ServiceRequest reference | routine | |
Reminder to submit measurement (about to be created) | Yes | No | Yes | No |
| EpisodeOfCare reference | |||
Communication created by triage (or other infrastructure rules) | No | Yes | No | Yes | depends on rule | depends on rule | ServiceRequest reference | depends on rule | |
EpisodeOfCare created/changed (in team, status, scheduledStatus or scheduledTeam) | Yes | No | Yes | No |
| EpisodeOfCare reference | |||
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam) | Yes | No | Yes | No |
| EpisodeOfCare reference |
The table below reflects future behavior. A change is under way that will change the FHIR Communication created and correspondingly, the CommunicationRequest required to control the creation.
Situation | Created by Default | Opt-in Supported | Opt-out Supported | Payload and Medium Overridable | Element category | Element reasonCode | Element episodeOfCare | Element basedOn | Element priority |
---|---|---|---|---|---|---|---|---|---|
Unexpected measurement submitted | No | Yes | Yes |
|
| ServiceRequest reference | |||
Missing measurement determined | No | Yes | Yes |
|
| ServiceRequest reference | |||
Reminder to submit measurement (about to be created) | Yes | Yes | Yes |
|
| EpisodeOfCare reference | |||
Communication created by triage (or other infrastructure rules) | No | Yes | Yes | depends on rule | depends on rule | ServiceRequest reference | depends on rule | ||
EpisodeOfCare created/changed (in team, status, scheduledStatus or scheduledTeam) | No | Yes | Yes |
|
| EpisodeOfCare reference | |||
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam) | No | Yes | Yes |
|
| EpisodeOfCare reference |
Currently, no infrastructure rules (see Library Resources) cause creation of Communication. Neither with Patient or CareTeam as recipient.
Controlling Creation of Message with CareTeam as Recipient
The table below describes the various situations in which automatic creation of FHIR Communication (ehealth-message) takes place. In the table, the columns following the naming pattern Element <some element name> describe what values must be used in a corresponding CommunicationRequest in order to control creation.
To apply for FHIR Communication with a CareTeam as recipient, add the following to the CommunicationRequest:
recipient
= CareTeam referencecategory
= <depending on situation>reasonCode
= <depending on situation>episodeOfCare
= <depending on situation>basedOn
= <depending on situation>priority
= <depending on situation>
The table below reflects future behavior. A change is under way that will change the FHIR Communication created and correspondingly, the CommunicationRequest required to control the creation.
Situation | Created by Default | Opt-in Supported | Opt-out Supported | Payload and Medium Overridable | Element category | Element reasonCode | Element episodeOfCare | Element basedOn | Element priority |
---|---|---|---|---|---|---|---|---|---|
Unexpected measurement submitted | No | Yes | No |
|
| ServiceRequest reference | |||
Missing measurement determined | Yes | Yes | No |
|
| ServiceRequest reference | |||
Communication created by triage (or other infrastructure rules) | Yes | Yes | No | depends on rule | depends on rule | ServiceRequest reference | depends on rule | ||
EpisodeOfCare created/changed (in team, status, scheduledStatus or scheduledTeam) | Yes | Yes | No |
|
| EpisodeOfCare reference | |||
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam) | Yes | Yes | No |
|
| EpisodeOfCare reference |
Overriding the Payload and/or Medium
Example of CommunicationRequest for overriding payload and medium (adding NemSMS). For overriding default NemSMS medium, simply leave medium in CommunicationRequest empty.
Ending a Control of Message Creation
The following reflects a change under way.
To remove the effect of a CommunicationRequest, perform a CommunicationRequest Update and set the status
to completed
. If the CommunicationRequest uses occurrencePeriod
and has no occurrencePeriod.end
, it would be consistent to set it to time of completing the CommunicationRequest.