Release 5

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

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

Detailed Descriptions for the elements in the CommunicationRequest resource.

CommunicationRequest
Element IdCommunicationRequest
Definition

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

Short DisplayA request for information to be sent to a receiver
Cardinality0..*
TypeDomainResource
Summaryfalse
CommunicationRequest.identifier
Element IdCommunicationRequest.identifier
Definition

Business identifiers assigned to this communication request by the performer or other systems which remain constant as the resource is updated and propagates from server to server.

Short DisplayUnique identifier
NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality0..*
TypeIdentifier
Requirements

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

Summarytrue
Comments

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.

CommunicationRequest.basedOn
Element IdCommunicationRequest.basedOn
Definition

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

Short DisplayFulfills plan or proposal
Cardinality0..*
TypeReference(Any)
Requirements

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

Alternate Namesfulfills
Summarytrue
CommunicationRequest.replaces
Element IdCommunicationRequest.replaces
Definition

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

Short DisplayRequest(s) replaced by this request
Cardinality0..*
TypeReference(CommunicationRequest)
Requirements

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

Alternate Namessupersedes; prior
Summarytrue
Comments

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.

CommunicationRequest.groupIdentifier
Element IdCommunicationRequest.groupIdentifier
Definition

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

Short DisplayComposite request this is part of
Cardinality0..1
TypeIdentifier
Alternate NamesgrouperId
Summarytrue
Comments

Requests are linked either by a "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.

CommunicationRequest.status
Element IdCommunicationRequest.status
Definition

The status of the proposal or order.

Short Displaydraft | active | on-hold | revoked | completed | entered-in-error | unknown
Cardinality1..1
Terminology BindingRequestStatus (Required)
Typecode
Is Modifiertrue (Reason: This element is labelled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid.)
Summarytrue
CommunicationRequest.statusReason
Element IdCommunicationRequest.statusReason
Definition

Captures the reason for the current state of the CommunicationRequest.

Short DisplayReason for current status
Cardinality0..1
Terminology BindingCommunicationRequest Status Reason (Example)
TypeCodeableConcept
Alternate NamesSuspended Reason; Cancelled Reason
Summaryfalse
Comments

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.

CommunicationRequest.intent
Element IdCommunicationRequest.intent
Definition

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

Short Displayproposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
Cardinality1..1
Terminology BindingRequestIntent (Required)
Typecode
Is Modifiertrue (Reason: This element changes the interpretation of all descriptive attributes. For example "the time the request is recommended to occur" vs. "the time the request is authorized to occur" or "who is recommended to perform the request" vs. "who is authorized to perform the request)
Requirements

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

Summarytrue
Comments

This element is expected to be immutable. E.g. A "proposal" instance should never change to be a "plan" instance or "order" instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value.

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

CommunicationRequest.category
Element IdCommunicationRequest.category
Definition

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

Short DisplayMessage category
Cardinality0..*
Terminology BindingCommunication Category (Example)
TypeCodeableConcept
Summaryfalse
Comments

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

CommunicationRequest.priority
Element IdCommunicationRequest.priority
Definition

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

Short Displayroutine | urgent | asap | stat
Cardinality0..1
Terminology BindingRequestPriority (Required)
Typecode
Meaning if MissingIf missing, this task should be performed with normal priority
Summarytrue
CommunicationRequest.doNotPerform
Element IdCommunicationRequest.doNotPerform
Definition

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

Short DisplayTrue if request is prohibiting action
Cardinality0..1
Typeboolean
Is Modifiertrue (Reason: If true this element negates the specified action. For Example, instead of a request for a communication, it is a request for the communication to not occur.)
Meaning if MissingIf do not perform is not specified, the request is a positive request e.g. "do perform"
Alternate Namesprohibited
Summarytrue
Comments

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

CommunicationRequest.medium
Element IdCommunicationRequest.medium
Definition

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

Short DisplayA channel of communication
Cardinality0..*
Terminology BindingParticipationMode icon (Example)
TypeCodeableConcept
Summaryfalse
CommunicationRequest.subject
Element IdCommunicationRequest.subject
Definition

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

Short DisplayFocus of message
Cardinality0..1
TypeReference(Patient | Group)
Alternate Namespatient
Summaryfalse
CommunicationRequest.about
Element IdCommunicationRequest.about
Definition

Other resources that pertain to this communication request and to which this communication request should be associated.

Short DisplayResources that pertain to this communication request
Cardinality0..*
TypeReference(Any)
Summaryfalse
Comments

Don't use CommunicationRequest.about element when a more specific element exists, such as basedOn, reasonReference, or replaces.

CommunicationRequest.encounter
Element IdCommunicationRequest.encounter
Definition

The Encounter during which this CommunicationRequest was created or to which the creation of this record is tightly associated.

Short DisplayThe Encounter during which this CommunicationRequest was created
Cardinality0..1
TypeReference(Encounter)
Summarytrue
Comments

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.

CommunicationRequest.payload
Element IdCommunicationRequest.payload
Definition

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

Short DisplayMessage payload
Cardinality0..*
Summaryfalse
CommunicationRequest.payload.content[x]
Element IdCommunicationRequest.payload.content[x]
Definition

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

Short DisplayMessage part content
Cardinality1..1
TypeAttachment|Reference(Any)|CodeableConcept
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Summaryfalse
Comments

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.

CommunicationRequest.occurrence[x]
Element IdCommunicationRequest.occurrence[x]
Definition

The time when this communication is to occur.

Short DisplayWhen scheduled
Cardinality0..1
TypedateTime|Period
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Alternate Namestiming
Summarytrue
CommunicationRequest.authoredOn
Element IdCommunicationRequest.authoredOn
Definition

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

Short DisplayWhen request transitioned to being actionable
Cardinality0..1
TypedateTime
Alternate NamescreatedOn
Summarytrue
CommunicationRequest.requester
Element IdCommunicationRequest.requester
Definition

The device, individual, or organization who asks for the information to be shared.

Short DisplayWho asks for the information to be shared
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)
Alternate Namesauthor
Summarytrue
CommunicationRequest.recipient
Element IdCommunicationRequest.recipient
Definition

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

Short DisplayWho to share the information with
Cardinality0..*
TypeReference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam | HealthcareService | Endpoint)
Summaryfalse
CommunicationRequest.informationProvider
Element IdCommunicationRequest.informationProvider
Definition

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

Short DisplayWho should share the information
Cardinality0..*
TypeReference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService | Endpoint)
Summarytrue
CommunicationRequest.reason
Element IdCommunicationRequest.reason
Definition

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

Short DisplayWhy is communication needed?
Cardinality0..*
Terminology Bindingv3 Code System ActReason icon (Example)
TypeCodeableReference(Any)
Summarytrue
Comments

Textual reasons can be captured using reasonCode.text.

CommunicationRequest.note
Element IdCommunicationRequest.note
Definition

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

Short DisplayComments made about communication request
Cardinality0..*
TypeAnnotation
Summaryfalse