FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

8.23 Resource Communication - Content

Patient Care icon Work GroupMaturity Level: 2 Trial UseSecurity Category: Patient Compartments: Device, Encounter, Group, Patient, Practitioner, RelatedPerson

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.23.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. 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:

  • A record or receipt of the reminder or alert delivered to a responsible provider
  • A record or receipt of notification from the nurse to the on-call physician (or any other specified person) that a patient's temperature exceeds a value
  • A record or receipt of response from a public health agency to a provider caring for a patient presenting with a communicable disease reportable to the public health agency
  • A record or receipt of patient educational material sent by a provider to a patient
  • Notification of inability to deliver lab results to ordering physician
  • A record or receipt of submission of supplementary health information to a payer in support of a claim

Non-patient specific communication use cases may include:

  • A record or receipt of nurse call from a hall bathroom
  • A record or receipt of advisory for battery service from a pump

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

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.

8.23.3 References to this Resource

8.23.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Communication TU DomainResource A clinical or business level record of information being transmitted or shared

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Unique identifier

... basedOn Σ 0..* Reference(CarePlan | CommunicationRequest | DeviceRequest | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest | Task | VisionPrescription) Request fulfilled by this communication

... partOf Σ 0..* Reference(Any) Part of referenced event (e.g. Communication, Procedure)

... status ?!Σ 1..1 code preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Binding: EventStatus (Required)
... statusReason Σ 0..1 CodeableConcept Reason for current status
Binding: Communication Not Done Reason (Example)
... category 0..* CodeableConcept Message category
Binding: Communication Category (Example)

... priority Σ 0..1 code routine | urgent | asap | stat
Binding: RequestPriority (Required)
... medium 0..* CodeableConcept A channel of communication
Binding: ParticipationMode icon (Example)

... subject Σ 0..1 Reference(Patient | Group) Focus of message
... topic 0..1 CodeableConcept Description of the purpose/content
Binding: Communication Topic (Example)
... about 0..* Reference(Any) Resources that pertain to this communication

... encounter Σ 0..1 Reference(Encounter) The Encounter during which this Communication was created
... sent 0..1 dateTime When sent
... received 0..1 dateTime When received
... recipient 0..* Reference(CareTeam | Device | Group | HealthcareService | Location | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Endpoint) Who the information is shared with

... sender 0..1 Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService | Endpoint | CareTeam) Who shares the information
... reason Σ 0..* CodeableReference(Any) Indication for message
Binding: SNOMED CT Clinical Findings (Example)

... payload 0..* BackboneElement Message payload

.... content[x] 1..1 Message part content
..... contentAttachment Attachment
..... contentReference Reference(Any)
..... contentCodeableConcept CodeableConcept
... note 0..* Annotation Comments made about the communication


doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

8.23.4.1 Terminology Bindings

Path ValueSet Type Documentation
Communication.status EventStatus Required

Codes identifying the lifecycle stage of an event.
Communication.statusReason CommunicationNotDoneReason Example

Codes for the reason why a communication did not happen.
Communication.category CommunicationCategory Example

Codes for general categories of communications such as alerts, instructions, etc.
Communication.priority RequestPriority Required

Identifies the level of importance to be assigned to actioning the request.
Communication.medium ParticipationMode icon Example

Identifies the primary means by which an Entity participates in an Act.
Communication.topic CommunicationTopic Example

Codes describing the purpose or content of the communication.
Communication.reason SNOMEDCTClinicalFindings Example

This value set includes all the "Clinical finding" SNOMED CT icon codes - concepts where concept is-a 404684003 (Clinical finding (finding)).

Notes to reviewers:

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

8.23.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.23.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. 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.

8.23.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.23.5 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
based-on reference Request fulfilled by this communication Communication.basedOn
(CarePlan, MedicationRequest, Task, NutritionOrder, VisionPrescription, DeviceRequest, ServiceRequest, CommunicationRequest, ImmunizationRecommendation)
category token Message category Communication.category
encounter reference The Encounter during which this Communication was created Communication.encounter
(Encounter)		 29 Resources
identifier token Unique identifier Communication.identifier 65 Resources
in-response-to reference Reply to Communication.inResponseTo
(Communication)
medium token A channel of communication Communication.medium
part-of reference Part of referenced event (e.g. Communication, Procedure) Communication.partOf
(Any)
patient reference Focus of message Communication.subject.where(resolve() is Patient)
(Patient)		 65 Resources
reason-code token Indication for the message Communication.reason.concept
reason-reference reference Indication for the message Communication.reason.reference
received date When received Communication.received
recipient reference Who the information is shared with Communication.recipient
(Practitioner, Group, Organization, CareTeam, Endpoint, Device, Patient, HealthcareService, PractitionerRole, RelatedPerson, Location)
sender reference Who shares the information Communication.sender
(Practitioner, Organization, Endpoint, CareTeam, Device, Patient, HealthcareService, PractitionerRole, RelatedPerson)
sent date When sent Communication.sent
status token preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown Communication.status
subject reference Focus of message Communication.subject
(Group, Patient)
topic token Description of the purpose/content Communication.topic