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

Procedures

FHIR defines several resources to represent the proposal, planning, ordering, and performance of services and procedures for a patient.

Service in the US CQL implementation guide covers requested services, procedures performed, imaging procedures, and mammography. The patterns below add the US Quality Core profiles and the negated forms; see the Pattern Index for the full list.

For ServiceRequest and Procedure, see also modifier elements, search parameters, and cross-version considerations in that guide.

Neither the Procedure nor the ServiceRequest profile fixes status, so expressions must account for every value relevant to measure intent.

Procedure performed

See Procedures performed.

Measures use the US Quality Core Procedure profile, characterized by code.

define "Intermittent Pneumatic Compression Devices Applied":
  [USQualityCore.Procedure: "Application of Intermittent Pneumatic Compression Devices"] DeviceApplied
    where DeviceApplied.status = 'completed'

Procedure not done

US Quality Core defines the US Quality Core Procedure Not Done profile to document the reason a procedure, or class of procedures, was not performed. The profile fixes status to not-done, so it need not be tested. See Negation Patterns.

define "Intermittent Pneumatic Compression Devices Not Applied":
  [USQualityCore.ProcedureNotDone: "Application of Intermittent Pneumatic Compression Devices"] DeviceNotApplied
    where DeviceNotApplied.statusReason in "Medical Reason For Not Providing Treatment"
      or DeviceNotApplied.statusReason in "Patient Declined"

Procedure ordered

See Requested services.

Measures use the US Quality Core ServiceRequest profile, characterized by code.

define "Intermittent Pneumatic Compression Devices Ordered":
  [USQualityCore.ServiceRequest: "Application of Intermittent Pneumatic Compression Devices"] DeviceOrdered
    without [USQualityCore.TaskRejected] TaskReject
      such that TaskReject.focus.references(DeviceOrdered)
        and TaskReject.code ~ FHIRCommon."Fulfill"
    where DeviceOrdered.status in { 'active', 'completed', 'on-hold' }

ServiceRequest is the right profile for a service performed on the patient, including the use of a non-patient device such as an intermittent pneumatic compression device. An order for a device the patient themselves uses is a DeviceRequest; see Devices.

The profile fixes 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 rather than an equality comparison — see Working with doNotPerform.

Procedure not ordered

US Quality Core defines the US Quality Core Service Not Requested profile to document the reason a service, or class of services, was not ordered. The profile fixes doNotPerform to true.

define "Intermittent Pneumatic Compression Devices Prohibited":
  [USQualityCore.ServiceNotRequested: "Application of Intermittent Pneumatic Compression Devices"] DeviceProhibited
    where (DeviceProhibited.reasonRefused in "Medical Reason For Not Providing Treatment"
        or DeviceProhibited.reasonRefused in "Patient Declined")
      and DeviceProhibited.status in { 'active', 'completed', 'on-hold' }

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

define "Intermittent Pneumatic Compression Devices Order Rejected for Reason":
  [USQualityCore.ServiceRequest: "Application of Intermittent Pneumatic Compression Devices"] 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'

Imaging Procedures

See Imaging procedures, which describes how an imaging procedure may be spread across ServiceRequest, Procedure, ImagingStudy, DiagnosticReport, Observation, Claim, and ExplanationOfBenefit, and why not every resource is present for every procedure.

For measures, the practical question is how far to look. If intent is only that the scan was performed, the order and the procedure may suffice:

define "CT Scan Order Completed":
  [USQualityCore.ServiceRequest: "Abdominal or Pelvic CT Scan with Contrast"] SR
    where SR.intent = 'order'
      and SR.status = 'completed'

define "CT Scan Procedure Performed":
  [USQualityCore.Procedure: "Abdominal or Pelvic CT Scan with Contrast"] ScanAbdPelvic
    where ScanAbdPelvic.status = 'completed'

define "CT Scan Performed":
  exists "CT Scan Order Completed"
    or exists "CT Scan Procedure Performed"

If intent is that the scan was also resulted, the diagnostic report is the next level of evidence:

define "CT Scan Diagnostic Report":
  [USQualityCore.DiagnosticReportNote: "Abdominal or Pelvic CT Scan with Contrast"] ReportNote
    where ReportNote.status in { 'final', 'amended', 'corrected', 'appended' }

An imaging study may be checked as well, related to the order or procedure by procedureCode, procedureReference, or basedOn:

define "CT Scan Imaging Study":
  [USQualityCore.ImagingStudy] IS
    where exists (IS.procedureCode C where C in "CT Scan Procedure Codes")
      or exists ("CT Scan Procedure Performed" P
        where IS.procedureReference.references(P)
      )

Measurements taken during the scan are represented as observations; see Clinical Result.

NOTE: The US Quality Core ImagingStudy profile is marked with an asterisk in the US Quality Core profile list, meaning it is not part of that guide’s conformance expectations.

NOTE: This topic summarizes discussion with the Orders & Observations Work Group in this FHIR Zulip chat. That discussion also suggests ChargeItem may be useful as evidence that something was done, which needs follow-up.