DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

5.21 Resource Communication - Content

Patient Care Work GroupMaturity Level: 1Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson

An occurrence of information being transmitted; e.g. an alert that was sent to a responsible provider, a public health agency was notified about a reportable condition.

5.21.1 Scope and Usage

This resource is a record of a communication. A communication is a 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 that a patient's temperature exceeds a value
  • A notification to a public health agency of a patient presenting with a communicable disease reportable to the public health agency
  • Patient educational material sent by a provider to a patient

Non-patient specific communication use cases may include:

  • A nurse call from a hall bathroom
  • Advisory for battery service from a pump

5.21.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 may not be known. As well, 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.

Communication and Encounter

The Communication is about the transfer of information (which may or may 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.

5.21.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Communication ΣDomainResourceA record of information transmitted from a sender to a receiver
... identifier Σ0..*IdentifierUnique identifier
... category Σ0..1CodeableConceptMessage category
... sender Σ0..1Reference(Device | Organization | Patient | Practitioner | RelatedPerson)Message sender
... recipient Σ0..*Reference(Device | Organization | Patient | Practitioner | RelatedPerson | Group)Message recipient
... payload Σ0..*BackboneElementMessage payload
.... content[x] Σ1..1Message part content
..... contentStringstring
..... contentAttachmentAttachment
..... contentReferenceReference(Any)
... medium Σ0..*CodeableConceptA channel of communication
v3 Code System ParticipationMode (Example)
... status ?! Σ0..1codein-progress | completed | suspended | rejected | failed
CommunicationStatus (Required)
... encounter Σ0..1Reference(Encounter)Encounter leading to message
... sent Σ0..1dateTimeWhen sent
... received Σ0..1dateTimeWhen received
... reason Σ0..*CodeableConceptIndication for message
... subject Σ0..1Reference(Patient)Focus of message
... requestDetail Σ0..1Reference(CommunicationRequest)CommunicationRequest producing this message

doco Documentation for this format

UML Diagram

Communication (DomainResource)Identifiers associated with this Communication that are defined by business processes and/ or used to refer to it when a direct URL reference to the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation)identifier : Identifier [0..*]The type of message conveyed such as alert, notification, reminder, instruction, etccategory : CodeableConcept [0..1]The entity (e.g. person, organization, clinical information system, or device) which was the source of the communicationsender : Reference [0..1] « Device|Organization|Patient|Practitioner| RelatedPerson »The entity (e.g. person, organization, clinical information system, or device) which was the target of the communication. If receipts need to be tracked by individual, a separate resource instance will need to be created for each recipient.  Multiple recipient communications are intended where either a receipt(s) is not tracked (e.g. a mass mail-out) or is captured in aggregate (all emails confirmed received by a particular time)recipient : Reference [0..*] « Device|Organization|Patient| Practitioner|RelatedPerson|Group »A channel that was used for this communication (e.g. email, fax)medium : CodeableConcept [0..*] « Codes for communication mediums such as phone, fax, email, in person, etc. (Strength=Example)v3 Code System ParticipationM...?? »The status of the transmission (this element modifies the meaning of other elements)status : code [0..1] « The status of the communication. (Strength=Required)CommunicationStatus! »The encounter within which the communication was sentencounter : Reference [0..1] « Encounter »The time when this communication was sentsent : dateTime [0..1]The time when this communication arrived at the destinationreceived : dateTime [0..1]The reason or justification for the communicationreason : CodeableConcept [0..*]The patient who was the focus of this communicationsubject : Reference [0..1] « Patient »The communication request that was responsible for producing this communicationrequestDetail : Reference [0..1] « CommunicationRequest »PayloadA communicated content (or for multi-part communications, one portion of the communication)content[x] : Type [1..1] « string|Attachment|Reference(Any) »Text, attachment(s), or resource(s) that was communicated to the recipientpayload[0..*]

XML Template

<Communication xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Unique identifier --></identifier>
 <category><!-- 0..1 CodeableConcept Message category --></category>
 <sender><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Message sender --></sender>
 <recipient><!-- 0..* Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson|Group) Message recipient --></recipient>
 <payload>  <!-- 0..* Message payload -->
  <content[x]><!-- 1..1 string|Attachment|Reference(Any) Message part content --></content[x]>
 </payload>
 <medium><!-- 0..* CodeableConcept A channel of communication --></medium>
 <status value="[code]"/><!-- 0..1 in-progress | completed | suspended | rejected | failed -->
 <encounter><!-- 0..1 Reference(Encounter) Encounter leading to message --></encounter>
 <sent value="[dateTime]"/><!-- 0..1 When sent -->
 <received value="[dateTime]"/><!-- 0..1 When received -->
 <reason><!-- 0..* CodeableConcept Indication for message --></reason>
 <subject><!-- 0..1 Reference(Patient) Focus of message --></subject>
 <requestDetail><!-- 0..1 Reference(CommunicationRequest) CommunicationRequest producing this message --></requestDetail>
</Communication>

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Communication ΣDomainResourceA record of information transmitted from a sender to a receiver
... identifier Σ0..*IdentifierUnique identifier
... category Σ0..1CodeableConceptMessage category
... sender Σ0..1Reference(Device | Organization | Patient | Practitioner | RelatedPerson)Message sender
... recipient Σ0..*Reference(Device | Organization | Patient | Practitioner | RelatedPerson | Group)Message recipient
... payload Σ0..*BackboneElementMessage payload
.... content[x] Σ1..1Message part content
..... contentStringstring
..... contentAttachmentAttachment
..... contentReferenceReference(Any)
... medium Σ0..*CodeableConceptA channel of communication
v3 Code System ParticipationMode (Example)
... status ?! Σ0..1codein-progress | completed | suspended | rejected | failed
CommunicationStatus (Required)
... encounter Σ0..1Reference(Encounter)Encounter leading to message
... sent Σ0..1dateTimeWhen sent
... received Σ0..1dateTimeWhen received
... reason Σ0..*CodeableConceptIndication for message
... subject Σ0..1Reference(Patient)Focus of message
... requestDetail Σ0..1Reference(CommunicationRequest)CommunicationRequest producing this message

doco Documentation for this format

UML Diagram

Communication (DomainResource)Identifiers associated with this Communication that are defined by business processes and/ or used to refer to it when a direct URL reference to the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation)identifier : Identifier [0..*]The type of message conveyed such as alert, notification, reminder, instruction, etccategory : CodeableConcept [0..1]The entity (e.g. person, organization, clinical information system, or device) which was the source of the communicationsender : Reference [0..1] « Device|Organization|Patient|Practitioner| RelatedPerson »The entity (e.g. person, organization, clinical information system, or device) which was the target of the communication. If receipts need to be tracked by individual, a separate resource instance will need to be created for each recipient.  Multiple recipient communications are intended where either a receipt(s) is not tracked (e.g. a mass mail-out) or is captured in aggregate (all emails confirmed received by a particular time)recipient : Reference [0..*] « Device|Organization|Patient| Practitioner|RelatedPerson|Group »A channel that was used for this communication (e.g. email, fax)medium : CodeableConcept [0..*] « Codes for communication mediums such as phone, fax, email, in person, etc. (Strength=Example)v3 Code System ParticipationM...?? »The status of the transmission (this element modifies the meaning of other elements)status : code [0..1] « The status of the communication. (Strength=Required)CommunicationStatus! »The encounter within which the communication was sentencounter : Reference [0..1] « Encounter »The time when this communication was sentsent : dateTime [0..1]The time when this communication arrived at the destinationreceived : dateTime [0..1]The reason or justification for the communicationreason : CodeableConcept [0..*]The patient who was the focus of this communicationsubject : Reference [0..1] « Patient »The communication request that was responsible for producing this communicationrequestDetail : Reference [0..1] « CommunicationRequest »PayloadA communicated content (or for multi-part communications, one portion of the communication)content[x] : Type [1..1] « string|Attachment|Reference(Any) »Text, attachment(s), or resource(s) that was communicated to the recipientpayload[0..*]

XML Template

<Communication xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Unique identifier --></identifier>
 <category><!-- 0..1 CodeableConcept Message category --></category>
 <sender><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Message sender --></sender>
 <recipient><!-- 0..* Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson|Group) Message recipient --></recipient>
 <payload>  <!-- 0..* Message payload -->
  <content[x]><!-- 1..1 string|Attachment|Reference(Any) Message part content --></content[x]>
 </payload>
 <medium><!-- 0..* CodeableConcept A channel of communication --></medium>
 <status value="[code]"/><!-- 0..1 in-progress | completed | suspended | rejected | failed -->
 <encounter><!-- 0..1 Reference(Encounter) Encounter leading to message --></encounter>
 <sent value="[dateTime]"/><!-- 0..1 When sent -->
 <received value="[dateTime]"/><!-- 0..1 When received -->
 <reason><!-- 0..* CodeableConcept Indication for message --></reason>
 <subject><!-- 0..1 Reference(Patient) Focus of message --></subject>
 <requestDetail><!-- 0..1 Reference(CommunicationRequest) CommunicationRequest producing this message --></requestDetail>
</Communication>

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

5.21.3.1 Terminology Bindings

PathDefinitionTypeReference
Communication.category Codes for general categories of communications such as alerts, instruction, etc.UnknownNo details provided yet
Communication.medium Codes for communication mediums such as phone, fax, email, in person, etc.Examplev3 Code System ParticipationMode
Communication.status The status of the communication.RequiredCommunicationStatus
Communication.reason Codes for describing reasons for the occurrence of a communication.UnknownNo details provided yet

Notes to reviewers:

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

5.21.3.2 Communication.sender and Communication.recepient

Communication.sender and Communication.recipient allow Patient|Practitioner|RelatedPerson - 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.

5.21.4 Search Parameters

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

NameTypeDescriptionPaths
categorytokenMessage categoryCommunication.category
encounterreferenceEncounter leading to messageCommunication.encounter
(Encounter)
identifiertokenUnique identifierCommunication.identifier
mediumtokenA channel of communicationCommunication.medium
patientreferenceFocus of messageCommunication.subject
(Patient)
receiveddateWhen receivedCommunication.received
recipientreferenceMessage recipientCommunication.recipient
(Device, Patient, Organization, Practitioner, Group, RelatedPerson)
requestreferenceCommunicationRequest producing this messageCommunication.requestDetail
(CommunicationRequest)
senderreferenceMessage senderCommunication.sender
(Device, Patient, Organization, Practitioner, RelatedPerson)
sentdateWhen sentCommunication.sent
statustokenin-progress | completed | suspended | rejected | failedCommunication.status
subjectreferenceFocus of messageCommunication.subject
(Patient)