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

FHIR represents devices intended for personal use by a patient — canes, glucometers, CPAP machines — with the Device and DeviceRequest resources. Devices used by clinicians, or managed as facility resources such as infusion pumps and wheelchairs, are not represented with the patient-use device profiles: an order for a service performed with such a device is a ServiceRequest, and its availability is a non-patient observation.

The US CQL implementation guide does not publish a Device patterns page, so this page is the primary source for device patterns; see the Pattern Index for the full list of available patterns.

Device ordered

US Quality Core defines the US Quality Core DeviceRequest profile to represent the proposal, planning, or ordering of a device for a patient, characterized by code, which may be a code or a reference.

define "Device Indicating Frailty":
  [USQualityCore.DeviceRequest: "Frailty Device"] FrailtyDeviceOrder
    without [USQualityCore.TaskRejected] TaskReject
      such that TaskReject.focus.references(FrailtyDeviceOrder)
        and TaskReject.code ~ FHIRCommon."Fulfill"
    where FrailtyDeviceOrder.status in { 'active', 'on-hold', 'completed' }
      and FrailtyDeviceOrder.intent in { 'order', 'original-order', 'reflex-order', 'filler-order', 'instance-order' }

The profile does not fix status, so the expression must account for every value relevant to measure intent; active, on-hold, and completed together identify a positive device order. The profile does fix doNotPerform to false where present, but systems commonly omit the element unless it is true, so logic testing it against an unconstrained request should use doNotPerform is not true — see Working with doNotPerform.

Device not ordered

US Quality Core defines the US Quality Core Device Not Requested profile to document the reason a device, or class of devices, was not ordered. The profile fixes doNotPerform to true, so it need not be tested. See Negation Patterns.

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

A prohibition is a different statement from the rejection of a proposal, which uses TaskRejected against the positive request:

define "CPAP Order Rejected for Reason":
  [USQualityCore.DeviceRequest: "CPAP"] DeviceOrdered
    with [USQualityCore.TaskRejected] TaskRejected
      such that TaskRejected.focus.references(DeviceOrdered)
        and TaskRejected.code ~ FHIRCommon."Fulfill"
        and (TaskRejected.statusReason in "Medical Reason For Not Providing Treatment"
          or TaskRejected.statusReason in "Patient Declined")
    where DeviceOrdered.status = 'active'

Device in use

Where measure intent is that a device is actually in use rather than ordered, the Device profile is used:

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

NOTE: The US Quality Core Device and DeviceUseStatement profiles are both marked with an asterisk in the US Quality Core profile list, meaning they are not part of that guide’s conformance expectations. DeviceRequest and Device Not Requested, used above, are in scope.