View raw Markdown
type: resourceresource: CommunicationRequest

CommunicationRequest

Introduction

Scope and Usage

CommunicationRequest is one of the request resources in the FHIR workflow specification.

This resource is a record of a request for a communication to be performed. A communication is a conveyance of information from one entity, a sender, to another entity, a receiver. The requester requests the sender to send the payload to the recipient. The sender and receivers may be patients, practitioners, related persons, organizations, and devices. Some uses of communication request include:

Boundaries and Relationships

This resource is a record of a request. It does not represent the actual flow of communication.

The use of CommunicationRequest excludes requests for referrals and requests for therapy or counseling which would be handled by the ServiceRequest resource. The fulfillment of a CommunicationRequest may result in a Communication resource.

The CommunicationRequest resource represents an authorization for a service to be provided. Details about the fulfillment of the authorization are handled by the Task resource. For further information about this separation of responsibilities, refer to the Fulfillment/Execution section of the Request pattern.

Background and Context

Provides additional detail on exactly how the resource is to be used

Notes

Notes to reviewers:

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

CommunicationRequest.sender and CommunicationRequest.recepient

CommunicationRequest.sender allows Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService and CommunicationRequest.recipient allows Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | Group | CareTeam | HealthcareService - 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 request 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.

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-CommunicationRequest-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="CommunicationRequest-core"/>
  <version value="0.1"/>
  <name value="CommunicationRequestHL7Extensions"/>
  <title value="Communication Request  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2015-02-21T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - FHIR WG"/>
  <description value="Defines common extensions used with or related to the CommunicationRequest resource"/>
</ImplementationGuide>

Resource Packs

list-CommunicationRequest-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="CommunicationRequest-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/CommunicationRequest-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

communicationrequest-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

communicationrequest-request-mapping-exceptions.xml

Divergent Elements

Note: 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. | resource=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 status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds.

One exception to this is that the granularity of Request.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.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=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.

In some cases, the Request.code may pre-coordinate prohibition into the requested action. E.g. "NPO" (nothing by mouth), "DNR" (do not recussitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource shall not have double negation. (E.g. "Do not DNR"). | resource=The attributes provided with the request qualify what is not to be done.

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.

Unmapped Elements