A request to convey information; e.g. the CDS system proposes that an alert be sent to information from a responsible provider, the CDS system proposes that the public health agency be notified about sender to a reportable condition. recipient.

A unique ID of Business identifiers assigned to this communication request for reference purposes. It must be provided if user wants it returned as part of any output, otherwise it will be autogenerated, if needed, by CDS system. Does not need to be the actual ID of performer or other systems which remain constant as the source system. resource is updated and propagates from server to server.

Allows identification of the communication request as it is known by various participating systems and in a way that remains consistent across servers.

This is a business identifier, not a resource identifier (see discussion ). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

A plan or proposal that is fulfilled in whole or in part by this request.

Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.

Completed or terminated request(s) whose function is taken by this new request.

Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.

The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.

A shared identifier common to all requests multiple independent Request instances that were authorized activated/authorized more or less simultaneously by a single author, representing author. The presence of the same identifier on each request ties those requests together and may have business ramifications in terms of the requisition, prescription reporting of results, billing, etc. E.g. a requisition number shared by a set of lab tests ordered together, or similar form. a prescription number shared by all meds ordered at one time.

Requests are linked either by a "basedOn" "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

The status of the proposal or order.

Captures the reason for the current state of the CommunicationRequest.

This is generally only used for "exception" statuses such as "on-hold" or "revoked". The reason why the CommunicationRequest was created at all is captured in reasonCode, not here.

Indicates the level of authority/intentionality associated with the CommunicationRequest and where the request fits into the workflow chain.

Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.

This element is labeled as expected to be immutable. E.g. A "proposal" instance should never change to be a modifier because "plan" instance or "order" instance. Instead, a new instance 'basedOn' the status contains prior instance should be created with the codes cancelled and entered-in-error new 'intent' value.

One exception to this is that mark the request granularity of CommunicationRequest.intent is allowed to change. For example, a Request identified as not currently valid. an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

The type of message to be sent such as alert, notification, reminder, instruction, etc.

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

Characterizes how quickly the proposed act must be initiated. Includes concepts such as stat, urgent, routine.

If true indicates that the CommunicationRequest is asking for the specified action to not occur.

The attributes provided with the request qualify what is not to be done.

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

The patient or group that is the focus of this communication request.

The entity (e.g. person, organization, clinical information system, device, group, or care team) Other resources that pertain to this communication request and to which is the intended target of the communication. this communication request should be associated.

The resources which were related to producing this communication request. Don't use CommunicationRequest.about element when a more specific element exists, such as basedOn, reasonReference, or replaces.

The encounter Encounter during which this CommunicationRequest was created or episode of care within to which the communication request was created. creation of this record is tightly associated.

This will typically be the encounter the event occurred within, but some activities may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter.

Text, attachment(s), or resource(s) to be communicated to the recipient.

The communicated content (or for multi-part communications, one portion of the communication). communication) to be communicated.

The content can be codified or textual. As an example of codified content, when working with machine generated communications, the payload may be drawn from a finite, terminology defined set of communications, especially for short, status update kinds of communications where more of a natural language approach isn't appropriate.

If the content isn't codified, contentCodeableConcept.text can be used.

When using contentCodeableConcept, the CodeableConcept is what is being communicated and is not a categorization of the content.

The time when this communication is to occur.

For draft requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activation.

The entity (e.g. person, organization, clinical information system, device, individual, or device) which is organization who asks for the information to be the source of the communication. shared.

Using Group is Device) or onBehalfOf.exists().not(), xpath: contains(f:agent/f:reference/@value, '/Practitioner/') or contains(f:agent/f:reference/@value, '/Device/') only allowed when the group represents a family or not(exists(f:onBehalfOf))) a household and does not represent groups of Practitioners.

The entity (e.g. person, organization, clinical information system, device, practitioner, etc. who initiated group, or care team) which is the request. intended target of the communication.

The organization the device entity (e.g. person, organization, clinical information system, or practitioner was acting on behalf of. device) which is to be the source of the communication.

Entities being requested to provide the information. Using Group is Device) or onBehalfOf.exists().not(), xpath: contains(f:agent/f:reference/@value, '/Practitioner/') or contains(f:agent/f:reference/@value, '/Device/') only allowed when the group represents a family or not(exists(f:onBehalfOf))) a household and does not represent groups of Practitioners.

Describes why the request is being made in coded or textual form.

Textual reasons can be caprued captured using reasonCode.text.

Comments made about the request by the requester, sender, recipient, subject or other participants.