CMS FHIR Quality Measure Development IG, published by Centers for Medicare & Medicaid Services (CMS). This guide is not an authorized publication; it is the continuous build for version 1.0.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/cqframework/cms-qmd/ and changes regularly. See the Directory of published versions

Devices

Devices

FHIR defines several resources for tracking and managing patient use, such as canes, glucometers or CPAP machines. These profiles Device and DeviceRequest. represent devices intended for personal use by the patient. In contrast, devices used by clinicians or for general resource management (e.g., infusion pumps, wheelchairs used in facilities) are represented using other profiles—not the patient-use device profiles. In comparison to STU 4.1.1, there are no new device profiles added to STU6 of QI-Core.

Device ordered

QI-Core defines the DeviceRequest profile to represent proposals, planning, and ordering of devices for a patient. By default, DeviceRequest resources are identified by their code element, which can be represented as a code or a reference.

CQL:
define "Device Indicating Frailty":
  [DeviceRequest: "Frailty Device"] FrailtyDeviceOrder
    where FrailtyDeviceOrder.status in { 'active', 'on-hold', 'completed' }
      and FrailtyDeviceOrder.intent in { 'order', 'original-order', 'reflex-order', 'filler-order', 'instance-order' }
      and not exists ([TaskRejected] TaskReject where TaskReject.focus.references(FrailtyDeviceOrder) and TaskReject.code ~ "fulfill")

NOTES: *Status element considerations: The DeviceRequest profile does not fix the value of the status element, authors must consider all the possible values of the element to ensure the expression matches measure intent. In this case the active, completed and on-hold statuses are used to ensure a positive device order.

*doNotPerform considerations: Because the DeviceRequest profile fixes the value of the doNotPerform element to false if it is present, that element does not need to be tested in the expression. However, since real-world applications may not populate the value for doNotPerform unless it is true, the expression should include indication that doNotPerform is not null.

Device not ordered

1. Search for patient-use device not ordered for a reason:

QI-Core defines the DeviceNotRequested profile to represent documentation of the reason for not ordering a particular device, or class of devices. By default, DeviceNotRequested resources in QI-Core are characterized by the code element, which can be represented as a code or a reference.

CQL:
define "CPAP Prohibited":
  [DeviceNotRequested: "CPAP"] CPAPProhibited
    where CPAPProhibited.status = 'active'
      and CPAPProhibited.intent = 'order'

NOTE: Because the DeviceNotRequested profile fixes the value of doNotPerform to true, this element does not need to be tested in the expression.

1. Search for evidence that the proposal to order the patient-use device was rejected:

CQL:
define "CPAP Order Rejected For Reason":
  [DeviceRequest: "CPAP"] DeviceOrdered
    with [TaskRejected: fulfill] TaskRejected
      such that TaskRejected.focus.references(DeviceOrdered)
        and (TaskRejected.statusReason in "Medical Reason"
          or TaskRejected.statusReason in "Patient Refusal"
        )
    where DeviceOrdered.status = "active"

Device in use

When the measure objective is to identify actual Device use, the Device profile should be used.

CQL:
define "CPAP In Use":
  [Device: "CPAP"] CPAPInUse
    where CPAPInUse.status = 'active'