View raw Markdown
type: resourceresource: Communication

Communication

Introduction

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. Please see below for guidance on when this is appropriate.

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:

Non-patient specific communication use cases may include:

Boundaries and Relationships

This resource represents a communication that has been or will be presented to a human being or where the communication process has at least initiated. It does not have to represent the actual flow of communication, but in some use cases could represent the actual flow of communication (for example secure messaging between provider and patient). If your use case does not require presenting information to a recipient, consider a more structured and automated exchange protocol (see Approaches to Exchanging FHIR Data). 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, AuditEvent resources 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.

DeviceAlert resources are not necessarily (or even usually) targeted at a specific intended receiver, and they are often continuous and ongoing. In Communication there is a specific intended sender and receiver, and the information is delivered only once. Another difference is that DeviceAlert is not sent with the purpose of “adherence to guidelines or protocols or to provide business documentation of actions taken.”

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.

Background and Context

Provides additional detail on exactly how the resource is to be used

Notes

Notes to reviewers:

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

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.

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. Refer to the decision tree in Approaches to Exchanging FHIR Data for guidance on which data sharing mechanism is appropriate in which circumstances. 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.

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.

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-Communication-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="Communication-core"/>
  <version value="0.1"/>
  <name value="CommunicationHL7Extensions"/>
  <title value="Communication  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2015-02-21T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - FHIR WG"/>
  <description value="Defines common extensions used with or related to the Communication resource"/>
</ImplementationGuide>

Resource Packs

list-Communication-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="Communication-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/Communication-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

communication-event-mapping-exceptions.xml

Divergent Elements

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=This element is labeled as a modifier because the status contains the codes aborted and entered-in-error that mark the communication as not currently valid.

Unmapped Elements

communication-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements