Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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

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

The paragraph 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.

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>

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

Yes

message

UnexpectedMeasuringResolving

ServiceRequest reference

routine

Missing measurement determined

No

Yes

No

Yes

message

MissingMeasurementResolving

ServiceRequest reference

routine

Reminder to submit measurement (about to be created)

Yes

No

Yes

No

advice

EpisodeOfCare reference

Communication created by triage (or other infrastructure rules)

No

Yes

No

Yes

depends on rule

depends on rule

ServiceRequest reference

depends on rule

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

Yes

No

Yes

No

message

EpisodeOfCare reference

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

Yes

No

Yes

No

message

EpisodeOfCare reference

Reminder about appointment

Yes

No

No

No

Message category Communication with Patient as recipient created

Yes

No

No

No

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

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

EpisodeOfCare reference

Communication created by triage (or other infrastructure rules)

No

Yes

No

Yes

depends on rule

depends on rule

ServiceRequest reference

depends on rule

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

No

Yes

No

Yes

notification

EpisodeOfCareCreated ,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

TBD

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

No

Yes

No

No

message

depends on the Communication

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.

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>

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.

  • No labels