8.20 Resource Communication - Content

A clinical or business level record of information being transmitted or shared; e.g. an alert that was sent to a responsible provider, a public health agency communication to a provider/reporter in response to a case report for a reportable condition.

8.20.1 Scope and Usage

The purpose of a Communication resource is to surface that data was shared to track adherence to guidelines or protocols or to provide business documentation of actions taken. Communication can also be used as part of an information exchange to provide context about the information sharing occurring.

Communication is one of the event resources in the FHIR workflow specification.

This resource is a record of a communication even if it is planned or has failed. A communication is a record of the conveyance of information from one entity, a sender, to another entity, a receiver. The sender and receivers may be patients, practitioners, related persons, organizations, or devices. Communication use cases include:

A reminder or alert delivered to a responsible provider

A recorded notification from the nurse to the on-call physician (or any other specified person) that a patient's temperature exceeds a value

A response from a public health agency to a provider caring for a patient presenting with a communicable disease reportable to the public health agency

Patient educational material sent by a provider to a patient

Unable to deliver lab results to ordering physician

Submission of supplementary health information to a payer in support of a claim

Non-patient specific communication use cases may include:

A nurse call from a hall bathroom

Advisory for battery service from a pump

8.20.2 Boundaries and Relationships

This resource is a record of a communication that has occurred. It does not represent the actual flow of communication.
While AuditEvent can track electronic disclosures of information, it cannot track conversations,
phone calls, letters and other interactions that are not system-to-system. And even for system-to-system communications, the
specific end recipients might not be known. Furthermore, AuditEvents are not considered to be "part"
of the patient record, while Communication instances are. The Communication resource is not used as a general
audit mechanism to track every disclosure of every record. Rather, it is used when a clinician or other user wants to ensure
a record of a particular communication is itself maintained as part of the reviewable health record.

Flag resources represent a continuous ongoing "communication" alerting anyone dealing with the patient
of certain precautions to take or issues to be aware of. The flags are continuously present as an ongoing reminder. This is
distinct from Communication where there is a specific intended sender and receiver and the information is delivered only
once.

When there is a need to organize clinical and administrative content into sections, the Composition resource should be used instead. For example, an initial case report to a public health agency may include organized sections for vital signs, immunizations, social history, etc.

Communication and Encounter

The Communication is about the transfer of information (which might or might not occur as part of an encounter), while Encounter
is about the coming together (in person or virtually) of a Patient with a Practitioner. Communication does not deal with
the duration of a call, it represents the fact that information was transferred at a particular point in time.

The phone calls involving the Patient should be handled using Encounter. Phone calls not involving the patient
(e.g. between practitioners or practitioner to relative) that are tracked for billing or other purposes can use Communication
to represent the information transferred but are not ideal to represent the call itself.
A better mechanism for handling such calls will be explored in a future release.

At this time, the code bindings are placeholders to be fleshed out upon further review by the community.

8.20.4.2 Communication.sender and Communication.recipient

Communication.sender allows Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService and Communication.recipient allows Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam | HealthcareService - but it is not unusual to have a communication target - even a defined one - where it is unknown what kind of role the person is playing.

If the communication is to or from an individual whose role is not known (practitioner, patient or related person) -
for example, only email address is captured in the system - then RelatedPerson should be used by default.

8.20.4.3 Using Communication to wrap or accompany data

In FHIR, data is typically shared between systems without any need for the Communication resource to accompany or contain the data being shared, i.e. all FHIR exchanges are communications of some form, but that doesn't mean they need the Communication resource. However, in some cases, when data is shared there is a need to provide context about why the data is being conveyed and Communication is one of the mechanisms that FHIR provides that can share this context. Specifically, Communication allows conveying information about reasons for sharing, encounter that provides context for sharing, order or protocol that drove the need to share, etc. Note that some contextual information is expected to be captured by most FHIR systems even in absence of Communication, such as where did the data come from and when was the data received. This metadata is generally captured in Provenance. In addition to Communication, MessageHeader can capture similar metadata and Composition in FHIR documents can also serve a similar purpose. If mixing multiple mechanisms to convey communication metadata, care should be taken to ensure that each mechanism is necessary and the information conveyed in each layer is appropriately consistent.

8.20.4.4 Communication and CommunicationRequest

There is no requirement that Communication and CommunicationRequest always go together. Communication can exist without there having been a CommunicationRequest. For example, a practitioner might capture that they have provided a smoking cessation pamphlet to a patient that would be a Communication instance, but there would have been no "request" that led to the action (unsolicited). As well, a CommunicationRequest can be fulfilled in many ways, e.g. by phone call, email, system to system data sharing and there might not be a requirement to surface this data sharing at the clinical / business level, i.e. no need for a Communication instance.

Where there is a need to explicitly track fulfillment of a CommunicationRequest, Communication is the most natural resource to establish this linkage. The event can be tied to the request using Communication.basedOn.

8.20.5 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.