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 ).

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 reference

• occurrencePeriod.start = start of period for which the control applies

• occurrencePeriod.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 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)

CommunicationRequest subject shall not be set for control of messages regarding:

• Automated creation of medium nemsms Communication when Communication with category message and Patient as recipient created

• Reminder about appointment

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 reference

• category = <depending on situation>

• reasonCode = <depending on situation>

• episodeOfCare = <depending on situation>

• basedOn = <depending on situation>

• priority = <depending on situation>

Scope for the control

Search algorithm for “Reminder about appointment” and “Automated creation of medium nemsms…” communications

For most situations only a fixed set of reasonCodes are considered. However, a few remarks are in place for the situation “Automated creation of medium nemsms…”: When creating Communication/ehealth-message resources it is possible to specify a reasonCode, which provides the reason for the exchange of information. Using CommunicationRequest resources it is possible to opt-in for automatically created notifications about new messages. The set of reasonCodes is dynamic by nature when it comes to ehealth-message, ie. it may expand over time. Therefore it is meaningful to be able to create a CommunicationRequest, which is valid over time (for all or a specific EpisodeOfCare), and not sensitive to the introduction of new reasonCodes. Alternatively, it would be required to create new CommunicationRequest resources when introducing new reasonCodes, which would be rather cumbersome. Therefore, the semantics around CommunicationResources for ehealth-message notifications is slightly different than for other infrastructure events. For ehealth-message notifications (ie. the possibility for an automatically created ehealth-message with category=“notification”, medium=“nemsms”, and reasonCode copied from the original ehealth-message), it is possible to create a CommunicationRequest with no reasonCode provided, which will then logically match all possible ehealth-message reasonCodes (in contrast to other situations).

The infrastructure process of finding matching CommunicationRequests includes filtering on a valid “occurencePeriod”, status=“active”, matching co-existence tags (meta/tag), and recipient matching the Communication.recipient. Besides that, the logical infrastructure algorithm for deciding the proper CommunicationRequest resources is this (notice, though, that steps 2 and 4 only apply for “Automated creation of medium nemsms…” as explained above):

1. Look up CommunicationRequest resources that match both episodeOfCare and reasonCode. If no results are found continue with next step

2. Look up matching episodeOfCare and no reasonCode. If no results are found continue with next step

3. Look up matching reasonCode and no episodeOfCare. If no results are found continue with next step

4. Find results based on no reasonCode and no episodeOfCare. If no results are found, default behavior applies

Search algorithm otherwise

The infrastructure process of finding matching CommunicationRequests includes filtering the following:

• valid “occurencePeriod”

• status = “active”

• recipient matching Communication.recipient

• reasonCode matching Communication.reasonCode

• category matcing Communication.category

In certain situations the CommunicationRequest also includes filtering on EpisodeOfCare, CommunicationRequest.basedOn matching the relevant ServiceRequest which Communication creation was based on and lastly explicit filtering on co-existence tags (meta/tag). Consult the two tables for controlling creation of messages to see whether any of the extra filtering is in effect.

Selection algorithm

With one or more CommunicationRequest results from the above algorithm, the following filtering applies:

• If multiple results exist, choose the one with the most recent occurencePeriod.start

• If multiple results exist choose those with doNotPerform = true (message suppression)

• If multiple results exist choose a random one

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 reference

• category = <depending on situation>

• reasonCode = <depending on situation>

• episodeOfCare = <depending on situation>

• basedOn = <depending on situation>

• priority = <depending on situation>

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.

{
	"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

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.