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 with:
- subject = Patient reference
- recipient = Patient reference
- occurrencePeriod.start = start of period for which the control applies
- occurrencePeriod.end = end of period for which the control applies, if known
- status = active when control is in effect. Can be set to other values as appropriate (one of draft | 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.

In addition, elements of the CommunicationRequest must have specific values depending on the situation in which the Infrastructure automatically creates the Communication.

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.

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	`message`	`UnexpectedMeasuringResolving`		ServiceRequest reference	routine
Missing measurement determined	No	Yes		Yes	`message`	`MissingMeasurementResolving`		ServiceRequest reference	routine
Reminder to submit measurement (about to be created)	Yes		Yes	Yes	`advice`		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)	Yes		Yes	No	`message`		EpisodeOfCare reference
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam)	Yes		Yes	No	`message`		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	`notification`	`UnexpectedMeasuringResolving`		ServiceRequest reference
Missing measurement determined	No	Yes		Yes	`notification`	`MissingMeasurementResolving`		ServiceRequest reference
Reminder to submit measurement (about to be created)	Yes		Yes	Yes	`advice`	`ReminderSubmitMeasurement`	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	`notification`	`EpisodeOfCareCreated` ,`EpisodeOfCareCareTeamChange` , `EpisodeOfCareScheduledCareTeamChange` , `EpisodeOfCareStatusChange` or `EpisodeOfCareScheduledStatusChange`	EpisodeOfCare reference
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam)	No	Yes		Yes	`notification`	`CarePlanCreated`,`CarePlanCareTeamChange` , `CarePlanScheduledCareTeamChange` , `CarePlanStatusChange` or `CarePlanScheduledStatusChange`	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.

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	`notification`	`UnexpectedMeasuringResolving`		ServiceRequest reference
Missing measurement determined	Yes		Yes	No	`notification`	`MissingMeasurementResolving`		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	`notification`	`EpisodeOfCareCreated` ,`EpisodeOfCareCareTeamChange` , `EpisodeOfCareScheduledCareTeamChange` , `EpisodeOfCareStatusChange` or `EpisodeOfCareScheduledStatusChange`	EpisodeOfCare reference
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam)	Yes		Yes	No	`notification`	`CarePlanCreated`,`CarePlanCareTeamChange` , `CarePlanScheduledCareTeamChange` , `CarePlanStatusChange` or `CarePlanScheduledStatusChange`	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.

Click here to expand...

{
	"resourceType": "CommunicationRequest",
	"meta": {
		"profile": [
			"http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-communication-request"
		]
	},
	"extension": [
		{
			"url": "http://hl7.org/fhir/StructureDefinition/workflow-episodeOfCare",
			"valueReference": {
				"reference": "https://careplan.local.ehealth.sundhed.dk/fhir/EpisodeOfCare/12992"
			}
		}
	],
	"basedOn": [
		{
			"reference": "https://careplan.local.ehealth.sundhed.dk/fhir/ServiceRequest/67410"
		}
	],
	"status": "active",
	"doNotPerform": false,
	"medium": [
		{
			"coding": [
				{
					"system": "http://ehealth.sundhed.dk/cs/message-medium",
					"code": "nemsms",
					"display": "NemSMS"
				}
			]
		}
	],
	"payload": [
		{
			"contentString": "Payload override"
		}
	],
	"subject": {
		"reference": "https://patient.local.ehealth.sundhed.dk/fhir/Patient/4093"
	},
	"occurrencePeriod": {
		"start": "2023-01-04T13:02:55+01:00"
	},
	"recipient": [
		{
			"reference": "https://organization.local.ehealth.sundhed.dk/fhir/CareTeam/40365"
		}
	],
	"reasonCode": [
		{
			"coding": [
				{
					"system": "http://ehealth.sundhed.dk/cs/task-category",
					"code": "UnexpectedMeasurementResolving",
					"display": "Need resolving of why unexpected measurement was submitted"
				}
			]
		}
	]
}

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.

Controlling Creation of Messages

Adding Control of Creation of Message

Controlling Creation of Message with Patient as Recipient

Controlling Creation of Message with CareTeam as Recipient

Overriding the Payload and/or Medium

Ending a Control of Message Creation