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/igfhir/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-releasedfhir/ig/StructureDefinition-ehealth-communication-request.html ).

Adding Control of Message Creation

...

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.

...

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

Info
For now, doNotPerform set to true shall be accompanied by setting status = on-hold.

...

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

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

• Reminder about appointment

How to set remaining elements of the CommunicationRequest vary with situation, see below.

Info

The Communication.category is set depending on the intended use and involved recipients. See the section Introduction on https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-message.html for details. When a Communication with category=message is created to do human-human communication, it can be controlled whether to also send a mobile text message (NemSMS) to a Patient recipient as described on https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-message.html#automatic-nemsms-notifications. This requires opt-in as it is not the default behavior.

Controlling Message Creation

...

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.

...

• recipient = Patient reference

• category = <depending on situation>

• reasonCode = <depending on situation>

• episodeOfCare = <depending on situation>

• basedOn = <depending on situation>

• priority = <depending on situation>

Controlling Message Creation 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>

Scope for the control

...

Scope of the Message Creation Control

Search Algorithms for CommunicationRequest applied in the Infrastructure

In general, the different micro services of the Infrastructure perform a single search for CommunicationRequest using the following search parameters:

• CommunicationRequest.occurencePeriod covers current datetime at time of search

• CommunicationRequest.status = active

• CommunicationRequest.recipient matches Communication.recipient or would-be recipient (for opt-in)

In addition, search parameters are added depending on the situation as described in the sections below. For some situations, the search algorithm includes multiple searches.

Search algorithm for situation “Reminder about appointment”

Additional search parameters:

• CommunicationRequest.meta.tag matches Communication.meta.tag (compared for co-existence tags only)

The algorithm entails multiple searches in the following order:

1. Search for CommunicationRequest resources where both CommunicationRequest.episodeOfCare and CommunicationRequest.reasonCode match that of the Communication. If no results are found continue with next step.

2. Search for CommunicationRequest resources where no CommunicationRequest.episodeOfCare is present and CommunicationRequest.reasonCode matches that of the Communication. If no results are found continue with next step.

Search algorithm for situation “Automated creation of medium nemsms Communication when Communication with category message and Patient as recipient created”

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. that is, 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 CommunicationResource 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):

...

Additional search parameters:

• CommunicationRequest.meta.tag matches Communication.meta.tag (compared for co-existence tags only)

The algorithm entails multiple searches in the following order:

1. Search for CommunicationRequest resources where both CommunicationRequest.episodeOfCare and CommunicationRequest.reasonCode match that of the Communication. If no results are found continue with next stepLook up matching episodeOfCare and no reasonCode.

2. Search for CommunicationRequest resources where CommunicationRequest.episodeOfCare matches that of the Communication and no CommunicationRequest.reasonCode is present. If no results are found continue with next stepLook up matching reasonCode and no episodeOfCare.

3. Search for CommunicationRequest resources where no CommunicationRequest.episodeOfCare is present and CommunicationRequest.reasonCode matches that of the Communication. If no results are found continue with next stepFind results based on no reasonCode and no episodeOfCare.

4. Search for CommunicationRequest resources where no CommunicationRequest.episodeOfCare and no CommunicationRequest.reasonCode are present. If no results are found, default behavior applies

...

Search algorithm for situation EpisodeOfCare created

Additional search parameters:

• CommunicationRequest.meta.tag matches Communication.meta.tag (compared for co-existence tags only)

• The same additional search parameters as for the remaining situations (see below)

Search algorithm for remaining situations

Additional search parameters:

• CommunicationRequest.reasonCode matches Communication.reasonCode

• CommunicationRequest.category matches Communication.category

Conditional search parameters depending on the situation (see the tables above):

• CommunicationRequest.episodeOfCare matches Communication.episodeOfCare

• CommunicationRequest.basedOn matches Communication.basedOn

Selection algorithm

When the results of searching by the algorithms described above results in more than one CommunicationRequest, selection of a single CommunicationRequest is performed as follows (stopping whenever a single CommunicationRequest is left):

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

2. If multiple results exist choose those with doNotPerform = true (preference for message suppression)

3. If multiple results exist choose a random one

...

Controlling Creation of Message with CareTeam as Recipient

...

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>

...

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

...

EpisodeOfCare reference

...

Reminder about appointment

...

No

...

Yes

...

No

...

Only payload

...

advice

...

AppointmentNotification or VideoAppointmentNotificationdepending on appointment type

...

EpisodeOfCare reference

Scope for the control

<Description of search and selection algorithm>

<Description of searches performed for Automated creation…>

Overriding the Payload and/or Medium

...

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

...

Message Creation

...

Control

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.