/
Controlling Creation of Messages

Controlling Creation of Messages

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.

Content

Introduction

The eHealth Infrastructure automatically creates FHIR Communication of profile ehealth-message in various situations. See Behind the Scenes | Overview of Communication produced by the Infrastructure 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)

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.

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

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>

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)

 

 

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 VideoAppointmentNotificationdepending on appointment type

No value

(If created, this will be the default for the solution)

 

 

<co-exisitence tag of creating solution>

EpisodeOfCare reference

(This overrides the default for the solution if any for any FHIR Appointment referencing this specific EpisodeOfCare)

 

 

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>

EpisodeOfCare reference

(This overrides the default for the solution if any for this specific EpisodeOfCare)

 

 

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

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>

 

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

category

reasonCode

episodeOfCare

basedOn

priority

meta.tag

(Co-exisitence tag)

Unexpected measurement submitted

No

Yes

No

No

notification

UnexpectedMeasuringResolving

 

ServiceRequest reference

 

 

Missing measurement determined

Yes

No

Yes

No

notification

MissingMeasurementResolving

 

ServiceRequest reference

 

 

Communication created by triage (or other infrastructure rules)

Yes

No

Yes

No

depends on rule

depends on rule

 

ServiceRequest reference

depends on rule

 

EpisodeOfCare created

Yes

No

Yes

No

notification

EpisodeOfCareCreated

 

 

 

 

EpisodeOfCare changed (in team, status, scheduledStatus or scheduledTeam)

Yes

No

Yes

No

notification

EpisodeOfCareCareTeamChange , EpisodeOfCareScheduledCareTeamChange , EpisodeOfCareStatusChange or EpisodeOfCareScheduledStatusChange

EpisodeOfCare reference

 

 

 

CarePlan created/changed (in careTeam, status, scheduledStatus or scheduledTeam)

Yes

No

Yes

No

notification

CarePlanCreated,CarePlanCareTeamChange , CarePlanScheduledCareTeamChange , CarePlanStatusChange or CarePlanScheduledStatusChange

EpisodeOfCare reference

 

 

 

Reminder about appointment

No

Yes

No

Only payload

advice

AppointmentNotification or VideoAppointmentNotificationdepending on appointment type

No value

(If created, this will be the default for the solution)

 

 

<co-exisitence tag of creating solution>

EpisodeOfCare reference

(This overrides the default for the solution if any for any FHIR Appointment referencing this specific EpisodeOfCare)

 

 

Scope of the Message Creation Control

Search Algorithms for CommunicationRequest applied in the Infrastructure

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

  • CommunicationRequest.occurencePeriod covers current datetime at the time of the 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.

The search algorithm for the situation “Reminder about the 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 the 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 the next step.

The search algorithm for the 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 is 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, 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 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).

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 the next step.

  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 the next step.

  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 the next step.

  4. Search for CommunicationRequest resources where no CommunicationRequest.episodeOfCare and no CommunicationRequest.reasonCode are present. If no results are found, default behaviour 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 situation Reminder to submit measurement

Additional search parameters:

  • CommunicationRequest.episodeOfCare

  • CommunicationRequest.meta.tag

The algorithm entails multiple searches in the following order:

  1. Search for CommunicationRequest resources matching the CommunicationRequest.episodeOfCare specified as search parameter. If no results are found, continue with next step.