This page is part of the FHIR Specification (v4.4.0: R5 Preview #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
Patient Care Work Group | Maturity Level: 2 | Trial Use | Security Category: Patient | Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson |
Detailed Descriptions for the elements in the CommunicationRequest resource.
CommunicationRequest | |
Element Id | CommunicationRequest |
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. |
Cardinality | 0..* |
Type | DomainResource |
CommunicationRequest.identifier | |
Element Id | CommunicationRequest.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. |
Note | This is a business identifier, not a resource identifier (see discussion) |
Cardinality | 0..* |
Type | Identifier |
Requirements | Allows identification of the communication request as it is known by various participating systems and in a way that remains consistent across servers. |
Summary | true |
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 Id | CommunicationRequest.basedOn |
Definition | A plan or proposal that is fulfilled in whole or in part by this request. |
Cardinality | 0..* |
Type | Reference(Any) |
Requirements | Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon. |
Alternate Names | fulfills |
Summary | true |
CommunicationRequest.replaces | |
Element Id | CommunicationRequest.replaces |
Definition | Completed or terminated request(s) whose function is taken by this new request. |
Cardinality | 0..* |
Type | Reference(CommunicationRequest) |
Requirements | Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests. |
Alternate Names | supersedes; prior |
Summary | true |
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 Id | CommunicationRequest.groupIdentifier |
Definition | A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar form. |
Cardinality | 0..1 |
Type | Identifier |
Alternate Names | grouperId |
Summary | true |
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 Id | CommunicationRequest.status |
Definition | The status of the proposal or order. |
Cardinality | 1..1 |
Terminology Binding | RequestStatus (Required) |
Type | code |
Is Modifier | true (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.) |
Summary | true |
CommunicationRequest.statusReason | |
Element Id | CommunicationRequest.statusReason |
Definition | Captures the reason for the current state of the CommunicationRequest. |
Cardinality | 0..1 |
Terminology Binding | CommunicationRequest Status Reason (Example) |
Type | CodeableConcept |
Alternate Names | Suspended Reason; Cancelled Reason |
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.category | |
Element Id | CommunicationRequest.category |
Definition | The type of message to be sent such as alert, notification, reminder, instruction, etc. |
Cardinality | 0..* |
Terminology Binding | CommunicationCategory (Example) |
Type | CodeableConcept |
Comments | There may be multiple axes of categorization and one communication request may serve multiple purposes. |
CommunicationRequest.priority | |
Element Id | CommunicationRequest.priority |
Definition | Characterizes how quickly the proposed act must be initiated. Includes concepts such as stat, urgent, routine. |
Cardinality | 0..1 |
Terminology Binding | Request priority (Required) |
Type | code |
Meaning if Missing | If missing, this task should be performed with normal priority |
Summary | true |
CommunicationRequest.doNotPerform | |
Element Id | CommunicationRequest.doNotPerform |
Definition | If true indicates that the CommunicationRequest is asking for the specified action to not occur. |
Cardinality | 0..1 |
Type | boolean |
Is Modifier | true (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 Missing | If do not perform is not specified, the request is a positive request e.g. "do perform" |
Alternate Names | prohibited |
Summary | true |
Comments | The attributes provided with the request qualify what is not to be done. |
CommunicationRequest.medium | |
Element Id | CommunicationRequest.medium |
Definition | A channel that was used for this communication (e.g. email, fax). |
Cardinality | 0..* |
Terminology Binding | v3 Code System ParticipationMode (Example) |
Type | CodeableConcept |
CommunicationRequest.subject | |
Element Id | CommunicationRequest.subject |
Definition | The patient or group that is the focus of this communication request. |
Cardinality | 0..1 |
Type | Reference(Patient | Group) |
Patterns | Reference(Patient,Group): Common patterns = Participant |
Alternate Names | patient |
CommunicationRequest.about | |
Element Id | CommunicationRequest.about |
Definition | Other resources that pertain to this communication request and to which this communication request should be associated. |
Cardinality | 0..* |
Type | Reference(Any) |
Comments | Don't use CommunicationRequest.about element when a more specific element exists, such as basedOn, reasonReference, or replaces. |
CommunicationRequest.encounter | |
Element Id | CommunicationRequest.encounter |
Definition | The Encounter during which this CommunicationRequest was created or to which the creation of this record is tightly associated. |
Cardinality | 0..1 |
Type | Reference(Encounter) |
Summary | true |
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 Id | CommunicationRequest.payload |
Definition | Text, attachment(s), or resource(s) to be communicated to the recipient. |
Cardinality | 0..* |
CommunicationRequest.payload.content[x] | |
Element Id | CommunicationRequest.payload.content[x] |
Definition | The communicated content (or for multi-part communications, one portion of the communication). |
Cardinality | 1..1 |
Type | Attachment|Reference(Any)|CodeableConcept |
[x] Note | See Choice of Data Types for further information about how to use [x] |
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 Id | CommunicationRequest.occurrence[x] |
Definition | The time when this communication is to occur. |
Cardinality | 0..1 |
Type | dateTime|Period |
[x] Note | See Choice of Data Types for further information about how to use [x] |
Alternate Names | timing |
Summary | true |
CommunicationRequest.authoredOn | |
Element Id | CommunicationRequest.authoredOn |
Definition | For draft requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activation. |
Cardinality | 0..1 |
Type | dateTime |
Alternate Names | createdOn |
Summary | true |
CommunicationRequest.requester | |
Element Id | CommunicationRequest.requester |
Definition | The device, individual, or organization who asks for the information to be shared. |
Cardinality | 0..1 |
Type | Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device) |
Patterns | Reference(Practitioner,PractitionerRole,Organization,Patient,RelatedPerson,Device): Common patterns = Participant |
Alternate Names | author |
Summary | true |
CommunicationRequest.recipient | |
Element Id | CommunicationRequest.recipient |
Definition | The entity (e.g. person, organization, clinical information system, device, group, or care team) which is the intended target of the communication. |
Cardinality | 0..* |
Type | Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam | HealthcareService | Endpoint) |
Patterns | Reference(Device,Organization,Patient,Practitioner,PractitionerRole,RelatedPerson,Group,CareTeam,HealthcareService,Endpoint): No common pattern |
CommunicationRequest.informationProvider | |
Element Id | CommunicationRequest.informationProvider |
Definition | The entity (e.g. person, organization, clinical information system, or device) which is to be the source of the communication. |
Cardinality | 0..* |
Type | Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService | Endpoint) |
Patterns | Reference(Device,Organization,Patient,Practitioner,PractitionerRole,RelatedPerson,HealthcareService,Endpoint): No common pattern |
Summary | true |
CommunicationRequest.reason | |
Element Id | CommunicationRequest.reason |
Definition | Describes why the request is being made in coded or textual form. |
Cardinality | 0..* |
Terminology Binding | v3 Code System ActReason (Example) |
Type | CodeableReference(Any) |
Summary | true |
Comments | Textual reasons can be captured using reasonCode.text. |
CommunicationRequest.note | |
Element Id | CommunicationRequest.note |
Definition | Comments made about the request by the requester, sender, recipient, subject or other participants. |
Cardinality | 0..* |
Type | Annotation |