DFT - The specification is currently in development and subject to change. For a full list of available versions, see the Directory of published versions

L3: Communications

Secure communications between health care providers related to eReferral or eConsult are supported by messages that focus on the Communication resource.

The messaging supports both "general communications" and "requests for information" (RFI). In practice, they are usually the latter and therefore should be treated as consequence events.

Trigger Events & Interactions

Party	Action / Trigger	Sending System	Focus of Message	State Change	Event Code	Receiving System	Expected action upon receipt of message
Performer HCP	Sends a communication related to a received Service Request	Target System	Communication (CA:eReC)	n/a	send-communication-from-provider (L3)	Source System	Notify Requester HCP that a communication has been received that may require a response
Requester HCP	Sends a communication from Source System	Source System	Communication (CA:eReC)	n/a	send-communication-from-requester (L3)	Target System	Notify Performer HCP that there is a communication that may be a response

Requests for Information (RFI)

A request for information or RFI is to communicate that a service request received is not complete. In many cases, the Performer HCP will either have not accepted the request or will have placed it on hold pending a response.

Note: Although the Communication resource has the ability to carry attachments through .payload.contentResource, it SHALL NOT be used to attach .supportingInfo to a ServiceRequest. (See L1 + L2: Attaching Supporting Information for information about how to attach additional supporting information to a referral.)

General Communications

A general communication is used to pass information to the performer or requester, there is no requirement to respond or to place the referral on hold.

Single Entry Models

Where referrals are routed or split, Central Systems may be required to transmit Requests for Information received from Target Systems back to the Source System / Requester HCP.

Party	Action / Trigger	Sending System	Focus of Message	State Change	Event Code	Receiving System	Expected action upon receipt of message
Central System	Receives a communication from a Target System	Central System	Communication (CA:eReC)	n/a	send-communication-from-provider (L3)	Source System	Notify Requester HCP
Central System	Receives a communication from a Source System	Central System	Communication (CA:eReC)	n/a	send-communication-from-requester (L3)	Target System	Notify Performer HCP

Note: Secure communications are an L3 level capability with implications for patient care. Central Systems that integrate with less mature Source Systems must have appropriate processes in place to either restrict or support electronic communications with Target Systems.

Bi-directional Communication Messaging on Child Referrals

When referral communications involve a child ServiceRequest (for example, as part of a route or split workflow), the central system may be required to match the Communication to both the original and child ServiceRequest records.

Examples:

1. Route Scenario: A requester sends a Communication to the performer. The Central System would receive the send-communication-from-requester (SR1 focus) from the requester and then forward the Communication to the performer on the updated ServiceRequest (SR2 in focus).
   
2. Split Scenario: A requester sends a Communication to the performer. The Central System would receive the send-communication-from-requester (SR1 focus) from the requester and then forward the Communication to the performer on the updated ServiceRequest (SR1.1 in focus).

Central Systems can use inResponseTo to determine which ServiceRequest to match the Communication with, when sending it to the intended recipient.

---