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

Data Flow

This guide profiles two data-exchange patterns for the facility-to-HQR submission direction: push submission with results retrieval, and invited-pull. Push submission is the committed, live-tested pattern for this guide and the Connectathon; invited-pull is presented as a concept for discussion. The diagram below depicts both, end to end.

Push submission and results retrieval

HQRSubmissionMeasureReport is built on the Data Exchange MeasureReport pattern (DEQM US Realm STU5 in version 0.1.0 — see Dependencies for this guide's version 1.0.0 target), which carries raw data-of-interest rather than a pre-calculated result. Whether the Submitter also runs CQL and includes a calculated result, or sends raw data only, is addressed in Open Questions; step 4 below reflects the Data-Exchange-native behavior (receiver calculates) as the current design assumption, not a settled decision.

1. The EHR captures clinical data during care delivery.
2. The Submitter system maps that data to base profiles and produces a MeasureReport (HQRSubmissionMeasureReport in this guide) carrying raw data-of-interest, packaged together with the resources it references (via evaluatedResource) in one submission Bundle — see Dependencies for the precise shape and why this is one Bundle per patient, not an aggregate. The profile itself is measure-independent — this vertical slice exercises it against three either/or test measures, with no primary/stretch tiering: CMS71 (STK-3), CMS506, and EXMConnectathonSept2026Simple (https://madie.cms.gov/Measure/EXMConnectathonSept2026Simple). CMS71 and CMS506 are among the measures with the fewest US Core gaps, and EXMConnectathonSept2026Simple has minimal clinical data criteria by design — not because the guide targets any of them structurally. See Dependencies.
3. The Submitter sends the MeasureReport to the HQR Receiver (push, via $submit-data).
4. The Receiver validates conformance — structural, terminology, and CMS business rules — runs measure evaluation when the payload is raw-data-only, persists accepted data, and returns a clear acceptance or status response.
5. The Submitter, or another authorized party, retrieves submission status and results afterward through a separate read or search, independent of the original synchronous response.
6. Accepted MeasureReport resources flow to the relevant CMS Quality Programs for scoring and public reporting.

Invited-pull: a concept presented for discussion

Invited-pull is not live-tested at the Connectathon. Under this concept, the Submitter (acting as a Data Provider) exposes a Bulk $export endpoint and notifies the Receiver via $bulk-submit-data; the Receiver (acting as a Data Consumer) then pulls the dataset through a standard Bulk $export: the kick-off request starts an asynchronous job that, on completion, returns a manifest listing the location of one or more NDJSON files per resource type, which the Receiver reads asynchronously to reconstitute the dataset. Its long-term role in this guide remains open.

CDC's NHSN Link is a real-world precedent for the "receiver calculates" pull model in production today, though it operates under a standing facility authorization with continuous live query, which is architecturally different from DEQM's event-driven, per-dataset ping-and-pull. It is useful context, not a direct blueprint for either pattern as currently scoped.

Authentication for either pattern is addressed in Open Questions; SMART-on-FHIR / SMART Backend Services is a promising candidate for pilots and Connectathons but is not confirmed as a production requirement.

The actor CapabilityStatements under Artifacts reflect this split: push submission and results retrieval are the committed capabilities; the invited-pull roles are included to illustrate the concept under discussion, not as capabilities either actor is expected to run live at the Connectathon.