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.

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

The type of message conveyed such as alert, notification, reminder, instruction, etc. A protocol, guideline, or other definition that was adhered to in whole or in part by this communication event.

An order, proposal or plan fulfilled in whole or in part by this Communication.

This must point to some sort of a 'Request' resource, such as CarePlan, CommunicationRequest, ReferralRequest, MedicationRequest, etc.

The entity (e.g. person, organization, clinical information system, or device) which was the source Part of the communication. this action.

The entity (e.g. person, organization, clinical information system, or device) which was the target status 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). transmission.

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.

Text, attachment(s), or resource(s) If true, indicates that was communicated to the recipient. described communication event did not actually occur.

Creating a Communication where notDone is true is intended for situations where there's a need for a specific statement in the record about something not being done. If the need is merely to indicate that a request wasn't fulfilled, that should be handled using Task.

This element is labeled as a modifier because it marks the communication as a communication that did not occur. The more attributes are populated, the more constrained the negated statement is.

A communicated content (or for multi-part communications, one portion of Describes why the communication). communication event did not occur in coded and/or textual form.

The type of message conveyed such as alert, notification, reminder, instruction, etc.

There may be multiple axes of categorization and one communication may serve multiple purposes.

A channel that was used for this communication (e.g. email, fax).

The patient or group that was the focus of this communication.

The status entity (e.g. person, organization, clinical information system, or device) which was the target of the transmission. 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).

The resources which were responsible for or related to producing this communication.

The encounter within which the communication was sent.

The time when this communication was sent.

The time when this communication arrived at the destination.

The entity (e.g. person, organization, clinical information system, or device) which was the source of the communication.

The reason or justification for the communication.

Textual reasons can be caprued using reasonCode.text.

The patient who was the focus of Indicates another resource whose existence justifies this communication.

The communication request Text, attachment(s), or resource(s) that was responsible communicated to the recipient.

A communicated content (or for producing this communication. multi-part communications, one portion of the communication).

Additional notes or commentary about the communication by the sender, receiver or other interested parties.