CMS Hospital Quality Reporting FHIR Implementation Guide
0.1.0 - ci-build
CMS Hospital Quality Reporting FHIR Implementation Guide
0.1.0 - ci-build
CMS Hospital Quality Reporting FHIR Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Hospital Quality Reporting (HQR) is a CMS system, operated within the Center for Clinical Standards and Quality (CCSQ), that collects quality data from hospitals, ambulatory surgical centers (ASCs), and inpatient psychiatric facilities (IPFs), among other provider types. Its goal is to foster health care quality improvement through measurement and transparency, and to help beneficiaries make more informed decisions about their care. Data collected through HQR is made publicly available at Care Compare and data.medicare.gov.
HQR currently supports 13 distinct CMS quality reporting programs, spanning inpatient, outpatient, and other care settings: Hospital Inpatient Quality Reporting (IQR), Hospital-Acquired Condition Reduction (HACRP), Hospital Readmissions Reduction (HRRP), Hospital Value-Based Purchasing (HVBP), Inpatient Psychiatric Facility Quality Reporting (IPFQR), PPS-Exempt Cancer Hospital Quality Reporting (PCHQR), Promoting Interoperability (PI), Ambulatory Surgical Center Quality Reporting (ASCQR), Outpatient Quality Reporting (OQR), Rural Emergency Hospital Quality Reporting (REHQR), Validation, eCQM, and Public Reporting. Each program has its own measure set, established through the annual CMS proposed/final rule cycle, and its own submission burden depending on how data is collected — claims-based, chart/web-based, NHSN-reported, or eCQM (collected from the provider's EHR and submitted as a QRDA file).
The program traces back to the Hospital IQR Program, created under the Medicare Prescription Drug, Improvement, and Modernization Act (MMA) of 2003 and expanded by subsequent legislation, including Section 5001(a) of Public Law 109-171, the Deficit Reduction Act of 2005. Successful reporting is tied to an annual payment update (APU) to a facility's Medicare reimbursement. Across its 13 programs, HQR today reaches roughly 4,000 hospitals, 4,400 ASCs, 1,500+ IPFs, 11 PCHs, and 44 REHs, covering an estimated 67 million Medicare beneficiaries. Over 250 distinct quality measures have been introduced across HQR's programs since inception; the active measure set (updated with every proposed and final rule) currently totals 133 measures across the ASC, IQR, OQR, IPF, PCH, and REH programs combined, and changes with each annual rule cycle.
This guide is scoped to the Hospital IQR eCQM measure set specifically (see Open Questions for the current scope decision on OQR and other programs) — it is a vertical slice of one submission pathway within one HQR program, not a specification for HQR as a whole.
CMS/CCSQ is transitioning its quality reporting systems from QRDA/QDM-based eCQMs to FHIR-based digital quality measures (dQMs). Two mostly independent efforts make up this transition:
Reporting, submission, and data exchange. Today, patient-level quality data is submitted as QRDA Category I, and aggregated/population-level data as QRDA Category III (plus assorted CMS-specific JSON, XML, and CSV formats for other submission types). The FHIR future state replaces these with FHIR-based exchange built on the DEQM (Data Exchange for Quality Measures) IG — QRDA I's patient-level equivalent is a DEQM Individual MeasureReport, and QRDA III's aggregate equivalent is a DEQM Summary MeasureReport — layered on QI-Core and US Core clinical data profiles instead of the QDM-derived formats used today.
Measure authoring and calculation. Independently, the measures themselves are moving from the
Quality Data Model (QDM) to QI-Core-based FHIR profiles as the clinical data model, and from
HQMF (the XML-based machine-readable measure format) to the FHIR Measure resource. CQL, the
expression language used to author measure logic, stays in place either way — only the data model
it queries against changes (QDM-shaped CQL today, FHIR/QI-Core-shaped CQL going forward).
CCSQ has stated its rationale for the move in terms of reduced burden and improved interoperability: a single FHIR mapping replaces the current patchwork of program-specific formats, standards-based APIs can replace manual web submission, and the shift enables both dQMs and a longer-term vision of near-real-time feedback to providers on their quality results. This is also consistent with ONC's broader direction under the 21st Century Cures Act, which requires certified health IT to support FHIR R4, and with USCDI/USCDI+ as the underlying nationwide data element baseline (USCDI alone covers only a fraction of what quality reporting needs, which is part of why USCDI+ and quality-specific FHIR IGs like QI-Core and DEQM exist).
CCSQ has described this transition as occurring in three stages: a current state with no FHIR server and multiple submission formats; a near-term state that layers a FHIR API alongside existing submission paths without removing them; and a long-term state, referred to as the "North Star," with a single FHIR server, a single submission method (FHIR API/Bulk FHIR), and CMS pulling patient-level data directly rather than having it pushed program by program. CCSQ has stated several guardrails for the nearer-term stages of this transition: CMS does not intend to require more data than is submitted today, absent a program or standards change; CMS does not intend to require patient-level submitters to switch to aggregate reporting, or vice versa; CMS will not host a national repository of patient-level health information; and CMS will continue to calculate measures in-house for patient-level submissions rather than shifting that burden to submitters. CMS has also indicated it expects to support both FHIR and non-FHIR submission, and both QDM- and FHIR-based eCQM authoring, side by side for a multi-year transition window rather than a hard cutover.
This guide, and the September 2026 Connectathon vertical slice it supports, sits inside the first of these two independent tracks — reporting/submission/data exchange — and does not attempt to re-author or re-validate any measure's clinical logic.
CCSQ has also discussed HQR's FHIR API as a potential first phase of a broader, multi-program receiving system spanning CCSQ's quality programs, consistent with the "North Star" single-server direction described above. Under that framing, another CMS quality program is expected to join a shared receiver before the end of the decade. This guide does not depend on that broader system materializing, but naming and design choices made here — the developer portal, the API endpoint, and authentication approach in particular — are being made with that possibility in mind, to avoid rework later. See Open Questions for the specific items this affects.
Separately, CMS is developing a data-quality scorecard initiative (PIQI) for measure-reporting data quality. PIQI is an HL7-published standard, though production implementation is still limited industry-wide. This guide tracks PIQI as a related, emerging initiative; it is not currently a dependency of this guide.
DEQM (Data Exchange for Quality Measures) is the HL7 FHIR IG that defines the operations, actor
roles, and MeasureReport-based payload shapes for exchanging and evaluating quality measures in
FHIR — the $submit-data, $bulk-submit-data, $collect-data, and $evaluate-measure
operations, and the Individual, Summary, and Data Exchange MeasureReport patterns, all originate
in DEQM, not in this guide.
This guide does not compete with or duplicate DEQM. It profiles and constrains DEQM for CMS's
specific HQR submission context — the same relationship CCSQ has described wanting for FHIR-based
submission generally ("CMS will receive QRDA I or QRDA III equivalent submissions in FHIR
standards, e.g. DEQM IG"). Concretely, that means: reusing DEQM's operations and Bundle submission
shape as-is rather than defining new ones, adding HQR-specific must-support elements on top of the
base DEQM MeasureReport profile (a mandatory program-year extension, enforced by this guide's
profile; a CMS Certification Number, carried on the reporting Organization via
HQRReportingOrganization, a QI-Core Organization profile requiring QI-Core's own
identifier:ccn slice), and narrowing DEQM's general-purpose flexibility down to what an HQR
submission specifically requires. DEQM alone is
intentionally broad enough to serve many federal quality programs; this guide's job is to say what
a conformant HQR submission looks like within that broader DEQM shape.
One DEQM-related question has a version-anchored target; another is still evolving. Both are tracked in more detail in Dependencies and Open Questions:
The same version-anchored pattern applies to the clinical base. This guide targets US Quality Core
for clinical data profiling by version 1.0.0, not directly against DEQM (DEQM itself doesn't
define patient/encounter/medication-level clinical profiles). Version 0.1.0 is built against
QI-Core instead — not a preference, but a structural requirement of the DEQM US Realm STU5 package
this version builds against: the parent
Data Exchange MeasureReport profile's reporter and subject elements are structurally
constrained to QI-Core-profiled target types (qicore-organization, qicore-patient, etc.). US
Quality Core's own profiles derive from US Core, not QI-Core, so a US Quality Core-conformant
resource does not by itself satisfy this requirement — QI-Core and US Quality Core are siblings
under US Core, not parent/child, so this can't be worked around by re-typing the target. See
Dependencies for the full picture.
CMS is moving toward FHIR-based digital quality measures (dQMs) system-wide; draft dQM packages
for hospital inpatient, hospital outpatient, and eligible-clinician measures were opened for
public comment January 21 – February 25, 2026. In parallel, CMS/ONC have signaled a longer-term
move from QI-Core to US Quality Core as the base clinical-data profile set for quality
reporting. US Quality Core (current build v0.5.0) descends from QI-Core 6.0.0 in design/content lineage and
is stated to be backward-compatible with it, adding USCDI+ Quality guidance on top — but its
profiles are not literally derived from QI-Core's StructureDefinitions: US Quality Core's
Patient, Organization, and MedicationAdministration profiles all declare US Core, not QI-Core, as
their baseDefinition. This guide is built directly on QI-Core 6.0.0 today, since that is what
DEQM STU5 itself requires for reporter/subject — see Dependencies.