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

US Quality Core Update Process

This topic describes a process for refactoring FHIR-based 2025 AU draft CMS measures expressed using QI Core version 6.0.0 to:

1. Use the US Quality Core Implementation Guide as the model
2. Make use of shared artifacts in the Using CQL With FHIR and Common CQL Artifacts for FHIR (US-Based) implementation guides.

NOTE: Throughout this discussion, we use the version 0.1.0-cibuild for the US Quality Core references. This is because the content here is under freeze while we complete discrepancy testing between the QICore and USQualityCore versions of the measures. This will be updated to the 0.5.0 published version once that discrepancy testing completes.

For the purposes of this discussion, we will be focusing on the following 5 measures:

​Note that this list is not a complete listing of the measures, see the input/cql directory for all CQL source, and see the Measures index in the CI build for a listing of all the specifications.

For an explicit listing of the changes in each measure, refer to the following draft PR: https://github.com/cqframework/dqm-content-cms-2025/pull/5/changes?diff=split

NOTE: This PR will not be merged, it is only to provide an explicit listing of changes between the QICore and USQualityCore versions of the measures.

The measures make use of the following shared libraries:

This topic will use CMS125: Breast Cancer Screening as a running example

Step 1: Update Models

To facilitate reuse across models, the USQualityCore 0.1.0 and USCore 6.1.0-derived models provide model information for CQL that provides a “derived” view of FHIR profiles.

For example, in QI Core 6.0.0, a QI Core Encounter is effectively a base class. However, in US Quality Core, a US Quality Core Encounter is a derived class, derived from a US Core Encounter, which is in turn derived from a FHIR Encounter:

QI Core:

Encounter

US Quality Core:

FHIR.Encounter
    |- USCore.Encounter
        |- USQualityCore.Encounter

For almost all the measure logic, this change is transparent and the only thing that needs to happen is to change the version of the model being used:

QI Core:

using QICore version '6.0.0'

US Quality Core:

using USQualityCore version '0.1.0-cibuild'
using USCore version '6.1.0-derived'
using FHIR version '4.0.1'

Note carefully that the order of using declarations is important here because there are multiple models that define a patient context. To resolve the ambiguity, the reference implementation uses the first using declaration. To make this explicit:

using FHIR
using USQualityCore

context Patient // This resolves as FHIR.Patient

as opposed to

using USQualityCore
using FHIR

context Patient // This resolves as USQualityCore.Patient

NOTE: This repository is still using 0.1.0-cibuild because there is still active discrepancy testing happening on the content and so there is a content freeze while that testing is being completed. Once that freeze is lifted, these measures will be updated to the published 0.5.0 US Quality Core IG.

Step 2: Update Libraries

Once the models have been updated, we need to update the shared library references:

For example, the following snippet is the includes section of the CMS125 QI Core 6.0.0 Breast Cancer Screening measure:

include FHIRHelpers version '4.4.000' called FHIRHelpers
include SupplementalDataElements version '5.1.000' called SDE
include QICoreCommon version '4.0.000' called QICoreCommon
include AdultOutpatientEncounters version '4.19.000' called AdultOutpatientEncounters
include Hospice version '6.18.000' called Hospice
include Status version '1.15.000' called Status
include PalliativeCare version '1.18.000' called PalliativeCare
include AdvancedIllnessandFrailty version '1.27.000' called AIFrailLTCF

And the equivalent section for the CMS125 US Quality Core Breast Cancer Screening measure:

include hl7.fhir.uv.cql.FHIRHelpers version '4.0.1' called FHIRHelpers
include hl7.fhir.uv.cql.FHIRCommon version '2.0.0' called FHIRCommon
include hl7.fhir.us.cql.USCoreCommon version '2.0.0-ballot' called USCoreCommon
include hl7.fhir.us.cql.USCoreElements version '2.0.0-ballot' called USCoreElements

include USQualityCoreCommon version '0.1.0-cibuild' called USQualityCoreCommon
include SupplementalDataElements version '6.1.000' called SDE
include Status version '2.1.000' called Status
include AdultOutpatientEncounters version '5.1.000' called AdultOutpatientEncounters
include AdvancedIllnessandFrailty version '2.1.000' called AIFrailLTCF
include Hospice version '7.1.000' called Hospice
include PalliativeCare version '2.1.000' called PalliativeCare

Step 3: Update Types

When a CQL library includes multiple models, there is a possibility of having classes with the same name in each model. This will result in an “ambiguous type” error, where the translator cannot determine which model should be used.

QI Core (flat):

define "Bilateral Mastectomy Procedure":
  ( ( [Procedure: "Bilateral Mastectomy"] ).isProcedurePerformed ( ) ) BilateralMastectomyPerformed
    where BilateralMastectomyPerformed.performed.toInterval ( ) ends on or before end of "Measurement Period"

US Quality Core (derived):

define "Bilateral Mastectomy Procedure":
  ( ( [USQualityCore.Procedure: "Bilateral Mastectomy"] ).isProcedurePerformed ( ) ) BilateralMastectomyPerformed
    where BilateralMastectomyPerformed.performed.toInterval ( ) ends on or before end of "Measurement Period"

To avoid potential confusion, when using multiple models, type names SHOULD be qualified.

NOTE: A CQL feature request has been submitted (FHIR-58706) to propose the ability to define an “alias” for a type name within a library, so that authors can say “In this library, the identifier “Encounter” always means the USQualityCore Encounter.

In addition, the possibility of derived profiles means that some logic can be simplified. For example, in QICore 6.0.0, ConditionEncounterDiagnosis and ConditionProblemHealthConcerns are separate types, whereas in USQualityCore, they both ultimately derive from Condition, allowing logic that needs to deal with both to be written at the FHIR.Condition level, rather than the USQualityCore EncounterDiagnosis and ProblemHealthConcern level:

QI Core (flat):

define "Bilateral Mastectomy Diagnosis":
  ( ( [ConditionEncounterDiagnosis: "History of bilateral mastectomy"]
      union [ConditionProblemsHealthConcerns: "History of bilateral mastectomy"]
  ).verified ( ) ) BilateralMastectomyHistory
    where BilateralMastectomyHistory.prevalenceInterval ( ) starts on or before end of "Measurement Period"

US Quality Core (derived):

define "Bilateral Mastectomy Diagnosis":
  ( ( [FHIR.Condition: "History of bilateral mastectomy"] ).verified ( ) ) BilateralMastectomyHistory
    where BilateralMastectomyHistory.prevalenceInterval ( ) starts on or before end of "Measurement Period"

Although Condition is the most impacted area for this change, anywhere that more than one profile is derived from the same underlying resource (or profile) could pontentially benefit from this type of refactor. If the QICore-based logic required a union to bring together multiple profiles of the same underlying resource, consider refactoring the logic to make use of that underlying resource directly, rather than using the union.

Step 4: Replace extension elements:

In the derived models, extensions and slices are no longer created as first-class elements, rather they are represented as fluent functions:

QI Core:

    and Patient.sex = '248152002'

US Quality Core:

    and Patient.sex() = '248152002'

See the Extension Index topic in the Refactored Index for a complete description of extension-based elements in QICore that are now accessed with fluent functions in USQualityCore.

Step 5: Consider Functions

QI Core:

define "Initial Population":
  AgeInYearsAt(date from end of "Measurement Period") in Interval[42, 74]

US Quality Core:

define "Initial Population":
  Patient.ageInYearsAt(date from end of "Measurement Period") in Interval[42, 74]

See the Function Index topic in the Refactored Index for a complete index of where refactored functions are now located.

Step 6: Consider Elements and Patterns

And finally, consider whether the patterns documented in the CQL US Common IG can be applied to the measure logic. For example, the Mammography pattern proposes that in addition to Observation resources, Mammographies may be represented in FHIR data as DiagnosticReport resources:

QI Core:

define "Numerator":
  exists ( ( [ObservationClinicalResult: "Mammography"] ).isDiagnosticStudyPerformed ( ) ) Mammogram
    where Mammogram.effective.toInterval ( ) ends during day of Interval["October 1 Two Years Prior to the Measurement Period", end of "Measurement Period"]

US Quality Core:

define "Numerator":
  exists ( 
    ( ( [USQualityCore.ObservationClinicalResult: "Mammography"] ).isDiagnosticStudyPerformed ( ) ) Mammogram
      where Mammogram.effective.toInterval ( ) ends during day of Interval["October 1 Two Years Prior to the Measurement Period", end of "Measurement Period"]
  ) or exists (
    ( ( [USQualityCore.DiagnosticReportNote: "Mammography"] ).complete ( ) ) Mammogram
      where Mammogram.effective.toInterval ( ) ends during day of Interval["October 1 Two Years Prior to the Measurement Period", end of "Measurement Period"]
  )

See the Pattern Index topic in the Refactored Index for a complete index of where data element patterns are documented.

Example: Updated Billing Access

In QI Core:

define "Encounter With Asthma Present On Admission":
  [QICore.Encounter] E
    where E.isDiagnosisPresentOnAdmission("Asthma", "Present On Admission Positive Indicators")

Challenges:

1. Hides the logic
2. Doesn’t cache (functions don’t cache/expressions do)
3. Relies on direct encounter reference

In US Quality Core:

define "Encounter With Asthma Present On Admission":
  [USQualityCore.Encounter] E
    with "Claim Item Diagnosis" D
      such that (
        D.encounter.references(E)
          or D.serviced during E.period
          or D.claim.billablePeriod includes E.period
      )
        and D.claim.isActive()
        and D.claim.isClaim()
        and D.diagnosis in "Asthma"
        and D.onAdmission in "Present On Admission Positive Indicators"