View raw Markdown
type: resourceresource: 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.
  • 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 section of the Request pattern.

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 and devicerequest-right-lens examples are based on the general glasses 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)

Mappings

Implementation Guide

implementationguide-DeviceRequest-core.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 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

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

devicerequest-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

devicerequest-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.

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.

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.

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'.

See additional guidance here. | 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