---
type: "resource"
title: "DeviceRequest"
resource: "DeviceRequest"
---
# DeviceRequest


## Introduction


> **Note to Balloters:** To ensure the DeviceRequest resource is ready for Normative status, we are seeking ballot comments on the substantive content. The key changes made since R5 include:
> 
> -   DeviceRequest.instantiatesCanonical and DeviceRequest.instantiatesUri have been removed and are replaced with the workflow instantiation [extensions](workflow-extensions).
> -   DeviceRequest.code was renamed DeviceRequest.product to follow the request workflow pattern.
> -   Added DeviceRequest.location.
> -   Updates to search parameters to address the changes.

## Scope and Usage

This resource describes the request for the use of a device by a patient. The device may be any pertinent device specified in the Device resource. Examples of devices that may be requested include wheelchair, hearing aids, or an insulin pump. The request may lead to the delivery of the device to the patient directly, or to, e.g., a surgery suite for an implantation procedure.

The device use request may represent an order or a prescription entered by a practitioner in a CPOE system or a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care.

## Boundaries and Relationships

This resource deals with the allocation of a device to a patient and while it may contain instructions on how to use the device, the data about getting the device to the patient is addressed in other resources. For example, when requesting an oxygen pump for home use instructions on how to use it may be included. For devices that must be implanted via a surgical or other procedure the implantation is represented in the Procedure resource.

The DeviceRequest resource represents an authorization for a device 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](https://www.hl7.org/fhir/request.html#fulfillment) section of the Request pattern.

[VisionPrescription](visionprescription) may appear to overlap with DeviceRequest, but not completely as there are specific vision lens specification details that are present in VisionPrescription. To illustrate this, the [devicerequest-left-lens](devicerequest-left-lens) and [devicerequest-right-lens](devicerequest-right-lens) examples are based on the [general glasses example](visionprescription-example).

To determine the purchase date, a search of DeviceRequest, SupplyRequest, DeviceDispense, or SupplyDelivery as defined in an implementation guide can be done, as the context of the use case actually determines which date of either resource is considered the purchase date.

## Background and Context

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

## StructureDefinition

### Elements (Simplified)

- **[DeviceRequest](/devicerequest-definitions#DeviceRequest)** [0..*]: - Medical device request
- **[DeviceRequest.identifier](/devicerequest-definitions#DeviceRequest.identifier)** [0..*]: [Identifier](/Identifier) External Request identifier
- **[DeviceRequest.basedOn](/devicerequest-definitions#DeviceRequest.basedOn)** [0..*]: Reference([Resource](/Resource)) What request fulfills
- **[DeviceRequest.replaces](/devicerequest-definitions#DeviceRequest.replaces)** [0..*]: Reference([DeviceRequest](/DeviceRequest)) What request replaces
- **[DeviceRequest.groupIdentifier](/devicerequest-definitions#DeviceRequest.groupIdentifier)** [0..1]: [Identifier](/Identifier) Identifier of composite request
- **[DeviceRequest.status](/devicerequest-definitions#DeviceRequest.status)** [0..1]: [code](/code) required:[request-status](/valueset-request-status) draft | active | on-hold | entered-in-error | ended | completed | revoked | unknown
- **[DeviceRequest.intent](/devicerequest-definitions#DeviceRequest.intent)** [1..1]: [code](/code) required:[request-intent](/valueset-request-intent) proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
- **[DeviceRequest.priority](/devicerequest-definitions#DeviceRequest.priority)** [0..1]: [code](/code) required:[request-priority](/valueset-request-priority) routine | urgent | asap | stat
- **[DeviceRequest.doNotPerform](/devicerequest-definitions#DeviceRequest.doNotPerform)** [0..1]: [boolean](/boolean) True if the request is to stop or not to start using the device
- **[DeviceRequest.product[x]](/devicerequest-definitions#DeviceRequest.product%5Bx%5D)** [1..1]: [CodeableConcept](/CodeableConcept), Reference([Device](/Device)), [canonical](/canonical) example:[device-type](/valueset-device-type) Device requested
- **[DeviceRequest.quantity](/devicerequest-definitions#DeviceRequest.quantity)** [0..1]: [integer](/integer) Quantity of devices to supply
- **[DeviceRequest.parameter](/devicerequest-definitions#DeviceRequest.parameter)** [0..*]: [BackboneElement](/BackboneElement) Device details
- **[DeviceRequest.parameter.code](/devicerequest-definitions#DeviceRequest.parameter.code)** [0..1]: [CodeableConcept](/CodeableConcept) example:[request-orderdetail-parameter-code](/valueset-request-orderdetail-parameter-code) Device detail
- **[DeviceRequest.parameter.value[x]](/devicerequest-definitions#DeviceRequest.parameter.value%5Bx%5D)** [0..1]: [CodeableConcept](/CodeableConcept), [Quantity](/Quantity), [Range](/Range), [boolean](/boolean) Value of detail
- **[DeviceRequest.subject](/devicerequest-definitions#DeviceRequest.subject)** [1..1]: [Reference(Patient](/Reference(Patient), [Group](/Group), [Location](/Location), [Device)](/Device)) Focus of request
- **[DeviceRequest.encounter](/devicerequest-definitions#DeviceRequest.encounter)** [0..1]: Reference([Encounter](/Encounter)) Encounter motivating request
- **[DeviceRequest.occurrence[x]](/devicerequest-definitions#DeviceRequest.occurrence%5Bx%5D)** [0..1]: [dateTime](/dateTime), [Period](/Period), [Timing](/Timing) Desired time or schedule for use
- **[DeviceRequest.authoredOn](/devicerequest-definitions#DeviceRequest.authoredOn)** [0..1]: [dateTime](/dateTime) When recorded
- **[DeviceRequest.requester](/devicerequest-definitions#DeviceRequest.requester)** [0..1]: [Reference(Device](/Reference(Device), [Practitioner](/Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [CareTeam](/CareTeam), [Group](/Group), [Patient](/Patient), [RelatedPerson)](/RelatedPerson)) Who/what submitted the device request
- **[DeviceRequest.performer](/devicerequest-definitions#DeviceRequest.performer)** [0..1]: [CodeableReference](/CodeableReference) Requested Filler
- **[DeviceRequest.location](/devicerequest-definitions#DeviceRequest.location)** [0..*]: [CodeableReference](/CodeableReference) example:[v3-ServiceDeliveryLocationRoleType](/valueset-v3-ServiceDeliveryLocationRoleType) Requested location
- **[DeviceRequest.reason](/devicerequest-definitions#DeviceRequest.reason)** [0..*]: [CodeableReference](/CodeableReference) example:[condition-code](/valueset-condition-code) Coded/Linked Reason for request
- **[DeviceRequest.asNeeded](/devicerequest-definitions#DeviceRequest.asNeeded)** [0..1]: [boolean](/boolean) PRN status of request
- **[DeviceRequest.asNeededFor](/devicerequest-definitions#DeviceRequest.asNeededFor)** [0..1]: [CodeableConcept](/CodeableConcept) Device usage reason
- **[DeviceRequest.insurance](/devicerequest-definitions#DeviceRequest.insurance)** [0..*]: [Reference(Coverage](/Reference(Coverage), [ClaimResponse)](/ClaimResponse)) Associated insurance coverage
- **[DeviceRequest.supportingInfo](/devicerequest-definitions#DeviceRequest.supportingInfo)** [0..*]: Reference([Resource](/Resource)) Additional clinical information
- **[DeviceRequest.note](/devicerequest-definitions#DeviceRequest.note)** [0..*]: [Annotation](/Annotation) Notes or comments
- **[DeviceRequest.relevantHistory](/devicerequest-definitions#DeviceRequest.relevantHistory)** [0..*]: Reference([Provenance](/Provenance)) Request provenance

## Mappings

- [DeviceRequest Mappings](/devicerequest-mappings) — 99 mapping entries

## Implementation Guide


### implementationguide-DeviceRequest-core.xml



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

<ImplementationGuide xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/ImplementationGuide.xsd">
  <id value="DeviceRequest-core"/>
  <version value="0.1"/>
  <name value="DeviceRequestHL7Extensions"/>
  <title value="Device 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 DeviceRequest resource"/>
</ImplementationGuide>
```


## Resource Packs


### list-DeviceRequest-packs.xml



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

<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
  <id value="DeviceRequest-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/DeviceRequest-core"/>
    </item>
  </entry>
</List>
```


## Search Parameters

- [authored-on](/devicerequest-search#authored-on) — **date** — When the request transitioned to being actionable — `DeviceRequest.authoredOn`
- [based-on](/devicerequest-search#based-on) — **reference** — Plan/proposal/order fulfilled by this request — `DeviceRequest.basedOn`
- [product](/devicerequest-search#product) — **token** — Code for what is being requested/ordered — `DeviceRequest.product.ofType(CodeableConcept)`
- [device](/devicerequest-search#device) — **reference** — Reference to resource that is being requested/ordered — `DeviceRequest.product.ofType(Reference)`
- [encounter](/devicerequest-search#encounter) — **reference** — Encounter during which request was created — `DeviceRequest.encounter`
- [event-date](/devicerequest-search#event-date) — **date** — When service should occur — `(DeviceRequest.occurrence.ofType(dateTime)) | (DeviceRequest.occurrence.ofType(Period))`
- [group-identifier](/devicerequest-search#group-identifier) — **token** — Composite request this is part of — `DeviceRequest.groupIdentifier`
- [identifier](/devicerequest-search#identifier) — **token** — Business identifier for request/order — `DeviceRequest.identifier`
- [insurance](/devicerequest-search#insurance) — **reference** — Associated insurance coverage — `DeviceRequest.insurance`
- [intent](/devicerequest-search#intent) — **token** — proposal | plan | original-order |reflex-order — `DeviceRequest.intent`
- [patient](/devicerequest-search#patient) — **reference** — Individual the service is ordered for — `DeviceRequest.subject.where(resolve() is Patient)`
- [performer](/devicerequest-search#performer) — **reference** — Desired performer for service — `DeviceRequest.performer.reference`
- [performer-code](/devicerequest-search#performer-code) — **token** — Desired performer for service — `DeviceRequest.performer.concept`
- [prior-request](/devicerequest-search#prior-request) — **reference** — Request takes the place of referenced completed or terminated requests — `DeviceRequest.replaces`
- [requester](/devicerequest-search#requester) — **reference** — Who/what is requesting service — `DeviceRequest.requester`
- [status](/devicerequest-search#status) — **token** — entered-in-error | draft | active |suspended | completed — `DeviceRequest.status`
- [subject](/devicerequest-search#subject) — **reference** — Individual the service is ordered for — `DeviceRequest.subject`
- [location-code](/devicerequest-search#location-code) — **token** — The preferred location specified in the DeviceRequest (coded) — `DeviceRequest.location.concept`

[Full Search Parameters](/devicerequest-search)

## Examples

- [devicerequest-example](/devicerequest-example-devicerequest-example) — devicerequest-example
- [devicerequest-example-insulinpump](/devicerequest-example-devicerequest-example-insulinpump) — devicerequest-example-insulinpump
- [devicerequest-examples-header](/devicerequest-example-devicerequest-examples-header) — devicerequest-examples-header
- [example](/devicerequest-example-example) — devicerequest-example — Wheelchair assignment
- [insulinpump](/devicerequest-example-insulinpump) — devicerequest-example-insulinpump — Insulin Pump request
- [left-lens](/devicerequest-example-left-lens) — devicerequest-left-lens — Left Lens prescription using the parameters element
- [right-lens](/devicerequest-example-right-lens) — devicerequest-right-lens — Right Lens prescription using the parameters element
- [wheelchair-request](/devicerequest-example-wheelchair-request) — devicerequest-wheelchair-request — Standard wheelchair request

[Full Examples](/devicerequest-examples)

## Mapping Exceptions


### devicerequest-fivews-mapping-exceptions.xml

### Divergent Elements
- **FiveWs.class** → **DeviceRequest.intent**
- **FiveWs.what[x]** → **DeviceRequest.parameter**

### Unmapped Elements
- **FiveWs.cause** — Unknown
- **FiveWs.version** — Unknown
- **FiveWs.witness** — Unknown
- **FiveWs.where** — Unknown
- **FiveWs.init** — Unknown
- **FiveWs.source** — Unknown
- **FiveWs.who** — Unknown
- **FiveWs.done** — Unknown

### devicerequest-request-mapping-exceptions.xml

### Divergent Elements
- **Request.identifier** → **DeviceRequest.identifier**
  - shortUnmatched | reason=Unknown | pattern=Business Identifier for device request | resource=External Request identifier
  - definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this device request by the author and/or other systems.  These identifiers remain constant as the resource is updated and propagates from server to server. | resource=Identifiers assigned to this order by the orderer or by the receiver.
  - commentsUnmatched | reason=Unknown | pattern=The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler.

Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)).  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.
  - requirementsUnmatched | reason=Unknown | pattern=Allows identification of the device request as it is known by various participating systems and in a way that remains consistent across servers.
- **Request.basedOn** → **DeviceRequest.basedOn**
  - missingTypes | reason=Unknown | pattern=Reference(Request)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=What request fulfills
  - definitionUnmatched | reason=Unknown | pattern=A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this device request.  Authorization from the 'basedOn' request flows through to the referencing device request. | resource=Plan/proposal/order fulfilled by this request.
  - commentsUnmatched | reason=Unknown | pattern=basedOn represents the 'authorization' chain for an action, not the 'reason for action'.  For example, an order might be placed on hold under the authorization for a surgery.  However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications"
.
  - requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.
- **Request.replaces** → **DeviceRequest.replaces**
  - missingTypes | reason=Unknown | pattern=Reference(Request)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Request(s) replaced by this device request | resource=What request replaces
  - definitionUnmatched | reason=Unknown | pattern=Completed or terminated request(s) whose function is taken by this new device request. | resource=The request takes the place of the referenced completed or terminated request(s).
  - commentsUnmatched | reason=Unknown | pattern=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.
  - requirementsUnmatched | reason=Unknown | pattern=Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.
- **Request.groupIdentifier** → **DeviceRequest.groupIdentifier**
  - shortUnmatched | reason=Unknown | pattern=Composite request this is part of | resource=Identifier of composite request
  - definitionUnmatched | reason=Unknown | pattern=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. | resource=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.
  - commentsUnmatched | reason=Unknown | pattern=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.
  - requirementsUnmatched | reason=Unknown | pattern=Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes.
- **Request.status** → **DeviceRequest.status**
  - shortUnmatched | reason=Unknown | pattern=draft | active | on-hold | revoked | completed | entered-in-error | unknown | resource=draft | active | on-hold | entered-in-error | ended | completed | revoked | unknown
  - definitionUnmatched | reason=Unknown | pattern=The current state of the device request. | resource=The status of the request.
  - commentsUnmatched | reason=Unknown | pattern=The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding]](s) or using the]] resource.  A nominal state-transition diagram can be found in the] documentation  Unknown does not represent "other" - one of the defined statuses must apply.  Unknown is used when the authoring system is not sure what the current status is.  A status of 'active' when doNotPerform is true means that the request to not perform is currently in force.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=This element is labeled as a modifier because the status contains the codes revoked and entered-in-error that mark the request as not currently valid.
- **Request.intent** → **DeviceRequest.intent**
  - shortUnmatched | reason=Unknown | pattern=proposal | plan | order (immutable) | resource=proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
  - definitionUnmatched | reason=Unknown | pattern=Indicates the level of authority/intentionality associated with the device request and where the request fits into the workflow chain. | resource=Whether the request is a proposal, plan, an original order or a reflex order.
  - commentsUnmatched | reason=Unknown | pattern=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 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 immutable. It cannot be changed for the same resource instance.
  - requirementsUnmatched | reason=Unknown | pattern=Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.
- **Request.priority** → **DeviceRequest.priority**
  - definitionUnmatched | reason=Unknown | pattern=Indicates how quickly the device request should be addressed with respect to other requests. | resource=Indicates how quickly the request should be addressed with respect to other requests.
- **Request.doNotPerform** → **DeviceRequest.doNotPerform**
  - shortUnmatched | reason=Unknown | pattern=true if request is prohibiting action | resource=True if the request is to stop or not to start using the device
  - definitionUnmatched | reason=Unknown | pattern=If true indicates that the device request is asking for the specified action to *not* occur. | resource=If true, indicates that the provider is asking for the patient to either stop using or to not start using the specified device or category of devices. For example, the patient has undergone surgery and the provider is indicating that the patient should not wear contact lenses.
  - commentsUnmatched | reason=Unknown | pattern=The attributes provided with the request qualify what is not to be done.  For example, if an effectiveTime is provided, the "do not" request only applies within the specified time.  If a performerType is specified then the "do not" request only applies to performers of that type.  Qualifiers include: code, subject, occurrence, performerType and performer.

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=If do not perform is not specified, the request is a positive request e.g. "do perform". DeviceRequest.reason includes the reason for marking the DeviceRequest as 'do not perform'.
  - requirementsUnmatched | reason=Unknown | pattern=Supports things like Do Not Recussitate, Nothing by mouth, etc.
- **Request.product** → **DeviceRequest.product[x]**
  - missingTypes | reason=Unknown | pattern=CodeableReference(BiologicallyDerivedProduct, Device, DeviceDefinition, Medication, NutritionProduct, Substance)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Product requested/ordered | resource=Device requested
  - definitionUnmatched | reason=Unknown | pattern=Indicates the product whose supply or manipulation is authorized by this device request. | resource=The details of the device to be used.
- **Request.subject** → **DeviceRequest.subject**
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Individual the service is ordered/prohibited for | resource=Focus of request
  - definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is to be performed/not performed on or for. | resource=The patient who will use the device.
  - requirementsUnmatched | reason=Unknown | pattern=Links the request to the Patient context.
- **Request.encounter** → **DeviceRequest.encounter**
  - shortUnmatched | reason=Unknown | pattern=Encounter the device request is tied to | resource=Encounter motivating request
  - definitionUnmatched | reason=Unknown | pattern=The Encounter during which this device request was created or to which the creation of this record is tightly associated. | resource=An encounter that provides additional context in which this request is made.
  - commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter during which the device request was created.  However, some {{title}s may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission activities).
  - requirementsUnmatched | reason=Unknown | pattern=Links the device request to the Encounter context.
- **Request.occurrence[x]** → **DeviceRequest.occurrence[x]**
  - shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=Desired time or schedule for use
  - definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=The timing schedule for the use of the device. The Schedule data type allows many different expressions, for example. "Every 8 hours"; "Three times a day"; "1/2 an hour before breakfast for 10 days from 23-Dec 2011:"; "15 Oct 2013, 17 Oct 2013 and 1 Nov 2013".
- **Request.authoredOn** → **DeviceRequest.authoredOn**
  - shortUnmatched | reason=Unknown | pattern=When request was created/transitioned to active | resource=When recorded
  - definitionUnmatched | reason=Unknown | pattern=For draft device requests, indicates the date of initial creation.  For requests with other statuses, indicates the date of activation. | resource=When the request transitioned to being actionable.
- **Request.requester** → **DeviceRequest.requester**
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Who/what is requesting service | resource=Who/what submitted the device request
  - definitionUnmatched | reason=Unknown | pattern=Who initiated the {{request}} and has responsibility for its activation. | resource=The individual or entity who initiated the request and has responsibility for its activation.
- **Request.performer** → **DeviceRequest.performer**
  - missingTypes | reason=Unknown | pattern=Reference(Practitioner, PractitionerRole, Organization, CareTeam, HealthcareService, Patient, Device, RelatedPerson)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Specific desired (non)performer | resource=Requested Filler
  - definitionUnmatched | reason=Unknown | pattern=Indicates who or what is being asked to perform (or not perform) the {{request}}. | resource=The desired individual or entity to provide the device to the subject of the request (e.g., patient, location).
- **Request.reason** → **DeviceRequest.reason**
  - shortUnmatched | reason=Unknown | pattern=Why is service (not) needed? | resource=Coded/Linked Reason for request
  - definitionUnmatched | reason=Unknown | pattern=Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this request. | resource=Reason or justification for the use of this device.
  - commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text.  If doNoPerform is true, this will be the reason why the request is being made to not act. | resource=When doNotPerform is true, this is the reason for requesting not to provide the device.
- **Request.insurance** → **DeviceRequest.insurance**
  - definitionUnmatched | reason=Unknown | pattern=Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested service. | resource=Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be required for delivering the requested service.
- **Request.supportingInfo** → **DeviceRequest.supportingInfo**
  - missingTypes | reason=Unknown | pattern=Reference(Any)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Extra information to use in performing request | resource=Additional clinical information
  - definitionUnmatched | reason=Unknown | pattern=Information that may be needed by/relevant to the performer in their execution of this device request. | resource=Additional clinical information about the patient that may influence the request fulfilment.  For example, this may include where on the subject's body the device will be used (i.e. the target site).
  - commentsUnmatched | reason=Unknown | pattern=See guidance on [notes vs. supportingInfo](request.html#notes).
- **Request.note** → **DeviceRequest.note**
  - shortUnmatched | reason=Unknown | pattern=Comments made about device request | resource=Notes or comments
  - definitionUnmatched | reason=Unknown | pattern=Comments made about the device request by the requester, performer, subject or other participants. | resource=Details about this request that were not represented at all or sufficiently in one of the attributes provided in a class. These may include for example a comment, an instruction, or a note associated with the statement.
  - commentsUnmatched | reason=Unknown | pattern=See guidance on [notes vs. supportingInfo](request.html#notes).
- **Request.relevantHistory** → **DeviceRequest.relevantHistory**
  - missingTypes | reason=Unknown | pattern=Reference(ProvenanceRelevantHistory)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Key events in history of device request | resource=Request provenance
  - definitionUnmatched | reason=Unknown | pattern=Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resource. | resource=Key events in the history of the request.
  - commentsUnmatched | reason=Unknown | pattern=This element does not point to the Provenance associated with the *current* version of the resource - as it would be created after this version existed.  The Provenance for the current version can be retrieved with a _revinclude.  Referenced provenances SHOULD adhere to the [provenance-relevant-history profile](provenance-relevant-history.html).

See additional guidance [here](request.html#history). | resource=This might not include provenances for all versions of the request - only those deemed "relevant" or important.
This SHALL NOT include the Provenance associated with this current version of the resource.  (If that provenance is deemed to be a "relevant" change, it will need to be added as part of a later update.  Until then, it can be queried directly as the Provenance that points to this version using _revinclude
All Provenances should have some historical version of this Request as their subject.

### Unmapped Elements
- **Request.deliverTo** — Unknown
- **Request.category** — Unknown
- **Request.reported** — Unknown
- **Request.code** — Unknown
- **Request.statusReason** — Unknown
- **Request.performerType** — Unknown