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

Dependencies

This guide does not define new clinical content or a new exchange pattern. It profiles and constrains existing specifications for CMS's specific HQR submission context:

This guide targets version 1.0.0 for its long-term dependency set — DEQM Universal Realm and US Quality Core. Version 0.1.0, validated at the September 2026 HL7 FHIR Connectathon, is built against DEQM US Realm STU5 and QI-Core instead, each for a specific structural reason detailed below.

Dependency	Role	What this guide does with it
QI-Core (hl7.fhir.us.qicore, 6.0.0)	Base clinical data profiles — version 0.1.0 dependency; not the version 1.0.0 target	This guide targets US Quality Core for clinical data profiling by version 1.0.0; QI-Core is used in version 0.1.0 as a structural requirement of the DEQM STU5 parent profile itself: MeasureReport.reporter and .subject on datax-measurereport-deqm have targetProfile constraints pointing at qicore-organization, qicore-patient, etc. specifically. Both reporter and subject are narrowed and QI-Core-conformant in examples: reporter via HQRReportingOrganization (constraining qicore-organization), subject via QICorePatient.
US Quality Core, 0.5.0 (fhir.onc.us-quality-core)	Base clinical data profiles — version 1.0.0 target	This guide's target for clinical data profiling by version 1.0.0, including Condition, Procedure, Observation, MedicationAdministration, and similar resources — none of these are profiled by this guide yet. US Quality Core's own profiles declare US Core, not QI-Core, as their StructureDefinition.baseDefinition, so a US Quality Core-conformant resource does not itself satisfy the QI-Core requirement above while DEQM STU5 is in use, despite US Quality Core's docs describing it as "a direct descendant of QI-Core" in a design/content sense — QI-Core and US Quality Core are siblings under US Core, not parent/child, so this can't be worked around by re-typing reporter/subject.
DEQM, US Realm (Da Vinci) STU5 (hl7.fhir.us.davinci-deqm, 5.0.0)	Exchange and operational pattern — version 0.1.0 dependency; not the version 1.0.0 target	Reuse the $submit-data operation, Data Provider/Data Consumer actor roles, and Bundle submission shape as-is. This guide targets DEQM Universal Realm (hl7.fhir.uv.deqm) by version 1.0.0; version 0.1.0 is built against US Realm STU5 instead, since it is the more mature, more widely implemented package available for the September 2026 Connectathon.
Bulk Data Access IG (hl7.fhir.uv.bulkdata, 3.0.0)	Exchange operation for the invited-pull concept	The invited-pull concept's Bulk $export operation (see Data Flow) references this package's OperationDefinition. Not yet a committed capability — see Open Questions item #11 for the newer ballot version this may need to move to.
CQFMeasures / FHIR Quality Measure IG (5.0.0)	Measure content and logic	Reference the Measure/Library resource structure and CQL packaging as-is.
US Core (6.1.0)	Transitively inherited via QI-Core and US Quality Core	No direct dependency; noted for lineage only.

See Open Questions for what remains undecided, including the push-versus-pull exchange pattern.

DEQM MeasureReport pattern

DEQM defines three MeasureReport-based patterns for the submission direction (facility to HQR). The table below compares them against a "North Star" reference point — submission decoupled from any one measure or program, with the receiving system performing calculation and low provider burden:

	North Star	Data Exchange MeasureReport	Individual / Subject List MeasureReport	Summary MeasureReport
Canonical id (US Realm STU5)	—	datax-measurereport-deqm	(not adopted in this guide)	(not adopted in this guide)
MeasureReport.type	—	data-collection	individual / subject-list	summary
Where calculation happens	Receiving system	Receiving system	Source (submitter)	Source (submitter), aggregated
Provider burden	Low	Moderate	High	High
Data exchange volume	Very high	High	High	Low

This guide's HQRSubmissionMeasureReport profile currently uses the Data Exchange MeasureReport pattern (datax-measurereport-deqm, built against DEQM US Realm STU5 in version 0.1.0 — see the dependency table above for this guide's version 1.0.0 target), which is receiver-calculates and raw-data-only, rather than the source-calculated Individual MeasureReport pattern used in earlier drafts of this guide. This is the closer match to the North Star reference point above (receiver calculates, lower provider burden). It does not require invited-pull specifically — Data Exchange MeasureReport works over push submission ($submit-data) as well, which is this guide's current primary exchange pattern; receiver-calculates and push-versus-pull are independent design questions.

What actually gets sent, precisely. MeasureReport.evaluatedResource is a list of References (Reference(Any), 0..) — it is not itself a Bundle, despite loose shorthand elsewhere calling it one. The Bundle in this picture is the *submission payload: $submit-data's own OperationDefinition names its input parameter bundle, typed Bundle, documented as needing to contain "1..* DEQM Data Exchange MeasureReports with data-of-interest" and recommended ("SHOULD") to cover a single subject. So the MeasureReport and its data-of-interest resources travel together inside one submission Bundle; evaluatedResource is how the MeasureReport points at which of that Bundle's entries were actually used.

Invocation: $submit-data, not $deqm-submit-data. This guide invokes the operation as POST [base]/Measure/[measure-id]/$submit-data. Implementers may also encounter the prefixed form, $deqm-submit-data — STU5's own published package (v5.0.0, dated 2025-05-19) is internally inconsistent here: its OperationDefinition declares code: deqm-submit-data, while that same package's own narrative and reference pages document invocation as plain $submit-data. The code was corrected to submit-data following a January 2026 tracker resolution and a March 2026 fix, after the May 2025 package was already published, so the published v5.0.0 package still carries the old, prefixed value. This guide and its supporting test systems all use plain $submit-data; use it for this Connectathon regardless of what the published package's OperationDefinition shows. This distinction is not expected to matter once this guide's basis moves to DEQM Universal Realm, which retires the operation entirely in favor of a plain Bundle POST (see Open Questions item #7).

Per-subject, not aggregate, by default. That same STU5 guidance ("SHOULD be for a single subject") is why this guide's design is one MeasureReport per patient, submitted in a per-patient Bundle — this matches DEQM's own recommended granularity, not just this guide's own preference. datax-measurereport-deqm still structurally allows subject to target Group instead of an individual (for population-level reporting), but that's the exception the profile permits, not the default this guide is built around. HQRSubmissionMeasureReport narrows subject to QICorePatient specifically, since this guide's current scope is individual patient-level eCQM data only.

Worth flagging directly as an open question: CCSQ's own FHIR transition materials describe QRDA I mapping to DEQM Individual MeasureReport (source-calculated, patient-level) and QRDA III to DEQM Summary MeasureReport (aggregate), not Data Exchange MeasureReport. This is a genuine open question for this guide, not yet resolved either way. See Background for the broader CCSQ FHIR transition context.

Which specific measures (CMS71, CMS506, and a synthetic non-published test measure) were chosen as this Connectathon's either/or test options, and why, is Connectathon-specific — not a structural dependency of this guide — and is covered in Acceptance Criteria rather than here.

Real-world comparison: NHSN Link

CDC's NHSN Link is a live, production system on the "receiver calculates" end of the spectrum described above: it pulls data directly from a facility's EHR FHIR API under a standing authorization and calculates the measure on the receiving side. It is built on the NHSN DQM Implementation Guide. It is a real precedent for receiver-side calculation, but architecturally different from DEQM's invited-pull concept — continuous live query under a standing authorization, rather than an event-driven ping for a specific dataset. It is useful context for evaluating either exchange pattern, not a direct blueprint for either one as currently scoped.