This page describes how solutions can to control the eHealth Infrastructure automatic creation of FHIR Communication / ehealth-messages through CommunicationRequest and configurations of solution-specific default messages managed through the helpdesk.

NOTE: application-event functionality is part of release-2026.3

Content

1 Content
2 Introduction
3 Adding Control of Message Creation
4 Scope of the Message Creation Control
- 4.1 Search Algorithms for CommunicationRequest applied in the Infrastructure
- 4.2 Selection algorithm
5 Overriding the Payload and/or Medium
- 5.1 Application-event push notifications
6 Solution-specific text in the message payload
7 Ending a Message Creation Control

Introduction

The eHealth Infrastructure automatically creates FHIR Communication of profile ehealth-message in various situations. See Behind the Scenes for an overview.

The solutions can control if and how these FHIR Communication are created through the use of the Infrastructure profile of FHIR CommunicationRequest.

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 the recipient of the default Communication.
Opt-out: Use of CommunicationRequest by a Patient or CareTeam to suppress the creation of the default Communication to the said Patient or CareTeam.

A CareTeam must be involved in an EpisodeOfCare or CarePlan to opt-in for Communication referring to the EpisodeOfCare and/or CarePlan and/or ServiceRequest.

Adding Control of Message Creation

To control the automatic creation of FHIR Communication, create a FHIR 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 the period for which the control applies
occurrencePeriod.end = end of the 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 to opt-out (that is, to suppress creation)
medium = "application-event" — required when opting into push notifications. Unlike nemsms, this medium cannot be overridden: the CR's medium must stay application-event for the application-event lookup to match.

CommunicationRequest subject shall not be set for control of 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 the remaining elements of the CommunicationRequest varies with the situation as described in the following subsection.

The Communication.category is set depending on the intended use and involved recipients. See the section Introduction on ehealth-message 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 Automatic NemSMS Notifications. This requires opt-in as it is not the default behavior.

In addition to NemSMS, the infrastructure publishes an EHealthApplicationEvent on topic ehealth-application-event when a citizen has opted in via a CommunicationRequest with medium=application-event and doNotPerform=false. The application-event flow runs independently of the NemSMS flow — each can be enabled and disabled on its own.

Controlling Message Creation with the Patient as Recipient

The table below describes the various situations in which the 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 to control the creation.

To apply for FHIR Communication with the Patient as the 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>

In the table there is mentioning of defaults and overriding specifics. For further information, please see the section on scope of message creation control below.

Situation (where FHIR Communication might be created)	Created by Default	Opt-in Supported	Opt-out Supported	Payload and Medium Overridable	Element in controlling FHIR CommunicationRequest
Situation (where FHIR Communication might be created)	Created by Default	Opt-in Supported	Opt-out Supported	Payload and Medium Overridable	category	reasonCode	episodeOfCare	basedOn	priority	meta.tag (Co-exisitence tag)
Unexpected measurement submitted	No	Yes	No	Yes	`notification`	`UnexpectedMeasuringResolving`		ServiceRequest reference
Missing measurement determined	No	Yes	No	Yes	`notification`	`MissingMeasurementResolving`		ServiceRequest reference
Reminder to submit measurement (about to be created)	Yes	No	Yes	Yes	`advice`	`ReminderSubmitMeasurement`	To establish a default* control for the solution using the co-existence tag (see column to the right), specify:* no reference to EpisodeOfCare			<co-existence tag of creating solution>
Reminder to submit measurement (about to be created)	Yes	No	Yes	Yes	`advice`	`ReminderSubmitMeasurement`	To establish a control for the solution using the co-existence tag (see column to the right) for a specific episode of care, specify: a reference to the EpisodeOfCare (This overrides the default for the solution, see above)			<co-existence tag of creating solution>
Communication created by triage (or other infrastructure rules)	No	Yes	No	Yes	`notification`	Depends on rule		ServiceRequest reference	Depends on rule
EpisodeOfCare created	No	Yes	No	Yes	`notification`	`EpisodeOfCareCreated`
EpisodeOfCare changed (in team, status, scheduledStatus or scheduledTeam)	No	Yes	No	Yes	`notification`	`EpisodeOfCareCareTeamChange` , `EpisodeOfCareScheduledCareTeamChange` , `EpisodeOfCareStatusChange` or `EpisodeOfCareScheduledStatusChange`	EpisodeOfCare reference
CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam)	No	Yes	No	Yes	`notification`	`CarePlanCreated`,`CarePlanCareTeamChange` , `CarePlanScheduledCareTeamChange` , `CarePlanStatusChange` or `CarePlanScheduledStatusChange`	EpisodeOfCare reference
Reminder about appointment	Yes	No	Yes	Yes	`advice`	`AppointmentNotification` or `VideoAppointmentNotification`depending on appointment type	To establish a default* control for the solution using the co-existence tag (see column to the right), specify:* no reference to EpisodeOfCare			<co-exisitence tag of creating solution>
Reminder about appointment	Yes	No	Yes	Yes	`advice`		To establish a control for the solution using the co-existence tag (see column to the right) for a specific episode of care, specify: a reference to the EpisodeOfCare (This overrides the default for the solution, see above)			<co-exisitence tag of creating solution>
Automated creation of `medium` `nemsms` Communication when Communication with category `message` and Patient as `recipient` created	No	Yes	No	Only `medium=nemsms` possible	`message`	Same as ehealth-message (optional) When omitted, it corresponds to a match on all ehealth-message reasonCodes. See the section on the scope of message creation control below.	No value (If created, this will be the default for the solution. This setting refers to communication contents, not whether a communication is created)			<co-exisitence tag of creating solution>
	No	Yes	No	Only `medium=nemsms` possible	`message`		EpisodeOfCare reference (This overrides the default for the solution if any for this specific EpisodeOfCare)			<co-exisitence tag of creating solution>

Currently, no infrastructure rules (see Library Resources) cause the creation of Communication. Neither with the Patient or CareTeam as a recipient.

Controlling push-notification (application-event) creation per eventType

Push notifications delivered via EHealthApplicationEvent are opted in/out per eventType using separate CommunicationRequests, one per eventType. CommunicationRequest.reasonCode is the filter that selects which eventType a CR applies to.

Situation	Communication.category	Communication.reasonCode	Communication.medium	Obligatory resource.label

Situation	Communication.category	Communication.reasonCode	Communication.medium	Obligatory resource.label
Appointment reminder (push)	advice	AppointmentReminder	application-event	Appointment
Video appointment reminder (push)	advice	VideoAppointmentReminder	application-event	Appointment
Reminder to submit measurements (push)	advice	ReminderSubmitMeasurements	application-event	ServiceRequest
New Health message notification (push)	message	NewEHealthMessage	application-event	EhealthMessage
Missing measurement notification (push)	advice	MissingMeassurement	application-event	ServiceRequest

A CR with no reasonCode is only considered when eventforwarding.application-event.fallback-to-unspecified-reasoncode=true. By default the infrastructure requires an exact reasonCode match, so each eventType is opted in independently.

Controlling Message Creation with CareTeam as Recipient

The table below describes the various situations in which the 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 to control creation.

To apply for FHIR Communication with a CareTeam as the 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>