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

Home

Official URL: http://example.org/fhir/us/hqr/ImplementationGuide/cms.fhir.us.hqr				Version: 0.1.0
Draft as of 2026-10-07				Computable Name: HQRImplementationGuide

Overview

This implementation guide describes the FHIR integration expectations for the CMS Hospital Quality Reporting (HQR) system in support of the transition to digital quality measures (dQMs). See Background for what HQR is and why CMS is moving toward FHIR-based dQMs.

This guide profiles and constrains DEQM (Data Exchange for Quality Measures) for CMS's HQR submission context. DEQM alone is intentionally broad enough to serve many federal quality programs; this guide defines what a conformant HQR submission looks like within that broader shape — reusing DEQM's operations and Bundle structure as-is, and adding HQR-specific must-support elements and value-set bindings on top: a mandatory MeasureReport-level program-year extension, enforced by this guide's profile, and a CMS Certification Number identifying the reporting facility, carried on the reporting Organization via HQRReportingOrganization, a QI-Core Organization profile requiring QI-Core's own identifier:ccn slice.

Scope

This guide's focal use case is CMS Hospital Quality Reporting (HQR) submission, with Hospital IQR as its stated reporting-program focus — a single vertical slice: one submission pathway (push, with results retrieval) exercised against a small set of representative measures, not the full set of CMS quality reporting programs or measures. That program focus is a statement about what this guide is being built and tested for, not a structural boundary: HQRSubmissionMeasureReport is measure-independent, so this guide could in principle support other measure types (e.g. claims-based measures, or measures from other programs) if the underlying dependencies grew to cover them — that is a potential future direction, not a current commitment. See Open Questions for more on this distinction.

• Exchange pattern. Push submission ($submit-data) with results retrieval is this guide's primary data-exchange pattern. Invited-pull (a $bulk-submit-data ping followed by a Bulk $export pull) is a second pattern this guide describes; its long-term role — including whether it becomes a co-equal, recommended option alongside push for production and v1.0 — is still open. See Data Flow and Open Questions.
• Base clinical profiles and DEQM realm. Version 0.1.0 of this guide, validated at the September 2026 HL7 FHIR Connectathon, is built against QI-Core and DEQM US Realm STU5. This guide targets US Quality Core and DEQM Universal Realm by version 1.0.0. See Dependencies for the full rationale.
• Vertical-slice test measures. A "vertical slice" here means testing this guide's exchange mechanics end-to-end against a small, representative set of measures, rather than the full Hospital IQR eCQM set. Three measures are available for this Connectathon, presented as either/or options with no primary or stretch tiering: CMS71 (STK-3, Anticoagulation Therapy for Atrial Fibrillation/Flutter) and CMS506 (Safe Use of Opioids) — two of the three candidate measures (out of seventeen assessed) found with zero unprofiled data elements against US Core (i.e., every clinical data element they need is already covered by a published US Core profile, so testing them doesn't get blocked on an unrelated profiling gap) — plus EXMConnectathonSept2026Simple (https://madie.cms.gov/Measure/EXMConnectathonSept2026Simple), a MADiE-authored measure built specifically for this Connectathon, exercising exchange mechanics without real clinical-data-element complexity. This is a test-data choice, not a scope decision: the HQRSubmissionMeasureReport profile is measure-independent and constrains any conformant submission equally, regardless of which measure it is for. This selection is specific to this Connectathon's test data, not a structural dependency of the guide — see Acceptance Criteria for the underlying analysis.

How to Navigate This Guide

• Background — the HQR Program, the digital quality measurement (dQM) transition, and this guide's relationship to DEQM.
• Data Flow — an end-to-end walkthrough of push submission and results retrieval, plus the invited-pull concept under discussion.
• Dependencies — what this guide constrains from and inherits (QI-Core, US Quality Core, DEQM, CQFMeasures, US Core), including a comparison of DEQM MeasureReport patterns.
• Open Questions — what is decided versus open, framed as concrete, testable questions for Connectathon participants.
• Acceptance Criteria — what is scored at the Connectathon and what is presented for discussion instead.
• Data Element Testing Guide — per-measure data-element cardinality checklists for Submitters and Receivers, scoped to this Connectathon's test measures.
• Artifacts (top menu) — the profiles, extensions, capability statements, and examples this guide defines.
• Downloads (top menu) — synthetic test-data bundles (30-40+ patients per test measure, split into Clinical Data / Measure Definition / Expected Results) and a Postman collection for exercising this guide's actor CapabilityStatements directly.

Status

This guide is explicitly not: a fully authored or ballot-ready specification, production or production-adjacent submission capability, a demonstration using real patient data or realistic scale, or a claim that hospital FHIR submission is mandated or imminent. Feedback that identifies gaps in any concept presented here — including invited-pull — is a valued outcome, not a failure.