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

Open Questions

Purpose

This page states this guide's open design questions as concrete, testable items for the September 2026 Connectathon. Each one is framed as something a Submitter or Receiver participant can evaluate and report a result on, rather than as a standing design debate.

Core exchange (evaluated at the Connectathon)

1. End-to-end push submission and results retrieval. Can a Submitter send a MeasureReport for any of this Connectathon's three either/or test measures — CMS71, CMS506, or EXMConnectathonSept2026Simple (see Acceptance Criteria for the selection rationale; no primary/stretch tiering among them) — to a Receiver; does the Receiver accept it and return a clear status response; and can the Submitter, or another authorized party, retrieve status and results afterward through a separate read or search, rather than only the original synchronous response? The profile is measure-independent — any conformant measure works structurally. CMS71/CMS506 are verified low-risk data for this exercise; EXMConnectathonSept2026Simple carries minimal clinical data criteria by design (see item #4).
2. Authentication pattern. Does SMART-on-FHIR / SMART Backend Services work cleanly for push submission with no user in the loop? This remains open pending review against production authentication requirements; for the Connectathon itself, the priority is following whatever pattern participants' own sandboxes already expect, rather than holding out for a production-grade answer.
3. Rejection, correction, and resubmission. If a payload is rejected, is the returned result specific enough that a Submitter can correct and resubmit without out-of-band support? Does a corrected resubmission cleanly supersede the rejected one, without duplicate persisted data?
4. EXMConnectathonSept2026Simple validates exchange mechanics only, not real data-element coverage. EXMConnectathonSept2026Simple (https://madie.cms.gov/Measure/EXMConnectathonSept2026Simple), added alongside CMS71/CMS506, is a MADiE-authored measure built specifically for this Connectathon with deliberately minimal CQL criteria (Initial Population/Denominator both true, Numerator checking only Patient.sex) — so a successful exchange test against it says little about whether a real-world eCQM's full data-element set is covered by QI-Core/US Core. CMS832 (HH-AKI) is not part of this guide's current test set; unlike CMS71/CMS506, its data-element coverage against QI-Core/US Core has not been independently verified, and it should not be assumed to pass the same gap check without going through it (see Dependencies for what that check involves).
5. Invited-pull concept. Does the invited-pull direction (a $bulk-submit-data ping followed by a Bulk $export pull) hold up under participant scrutiny? Identifying objections and gaps here is itself a useful outcome — see Acceptance Criteria.

Base profile transition

1. Clinical base. Version 0.1.0 of this guide is built against QI-Core, a structural requirement rather than a preference: DEQM US Realm STU5's parent profile constrains reporter/subject to QI-Core-profiled target types, and US Quality Core's own profiles derive from US Core rather than QI-Core, so a US Quality Core-conformant resource does not itself satisfy that constraint. This guide intends to move to US Quality Core as its clinical base by version 1.0.0, which requires moving off DEQM US Realm STU5 first (see item #7). See Dependencies.

DEQM realm and exchange pattern

1. DEQM realm. Version 0.1.0 of this guide is built against Da Vinci DEQM US Realm STU5 (hl7.fhir.us.davinci-deqm, 5.0.0), validated at the September 2026 HL7 FHIR Connectathon. This guide intends to move to DEQM Universal Realm (hl7.fhir.uv.deqm) by version 1.0.0, once that package is ready to build and test against directly. This is not only a package/version change: Universal Realm has retired its own $submit-data operation (its own package marks that OperationDefinition status as retired/deprecated) in favor of submitting a Bundle via a plain POST to the FHIR server's base URL, with no operation invocation at all. STU5's $submit-data remains active and is exactly correct for this guide today; moving to Universal Realm at version 1.0.0 will require modeling that plain-POST submission mechanism, not just re-pointing the same operation at a different canonical. STU5 itself is not expected to change: it keeps the $submit-data operation indefinitely, simply deprecated relative to newer DEQM versions rather than altered or removed, so this guide's Connectathon-testing pin is stable through the event.
2. Raw data versus raw-plus-calculated-result. Individual measure reports today typically include both evaluated patient data and calculation data. Should HQR submissions carry raw data only, or raw data plus an end calculation? This guide currently leans toward raw data only, consistent with the Data Exchange MeasureReport pattern (see Dependencies), but this is not yet final.
3. $collect-data as a third exchange pattern. DEQM's $collect-data operation offers a consumer-initiated pull of data-of-interest, distinct from both push submission and invited-pull. It is not built into either actor CapabilityStatement in this guide yet, and remains a pattern to evaluate rather than a commitment either way.
4. DEQM reporting-program extension. DEQM defines its own reporting-program extension on MeasureReport, carrying either an Identifier or a canonical reference to a CRMI Manifest Library that identifies which program a report is for. In DEQM US Realm STU5 (this guide's Connectathon-testing pin — see item #7), it is extension-reportingProgram (http://hl7.org/fhir/us/davinci-deqm/StructureDefinition/extension-reportingProgram); the Universal Realm ballot package's equivalent extension has a different id/canonical, deqm-reportingProgram. This guide's HQRSubmissionMeasureReport profile does not currently use it; it identifies the reporting year through a custom HQRProgramYear extension but does not separately identify the program. Should this guide adopt extension-reportingProgram to identify the program explicitly, particularly if this guide is one of several program-specific submissions that could eventually reach a shared, multi-program receiving system? See also item #18 below — this goes from optional to load-bearing the moment a second program shares a receiver.

Beyond the Connectathon

1. Bulk Data Access IG version alignment. The Bulk Data Access IG is advancing toward a new ballot version. Does the invited-pull design (the $export operation referenced in the actor CapabilityStatements) still align once that ballot content is available, or does it need adjusting?
2. Snapshot versus incremental submission. Does declaring, and enforcing, snapshot versus incremental through the DEQM Submit Data Update Type extension behave as specified — does a mismatched update type produce a clean rejection?
3. Hybrid-measure payload. For hybrid-measure implementers: is Questionnaire/ QuestionnaireResponse (SDC) a workable carrier for core clinical data elements not present in structured EHR data, or does it introduce more friction than it resolves?
4. CCN enforcement (resolved). CCN and program year were not parallel cases: HQRProgramYear was a proper MeasureReport-context extension, declared and made mandatory by HQRSubmissionMeasureReport itself, while CCN was a custom Organization-context extension with no Organization profile to enforce it. Resolved by adding HQRReportingOrganization, a profile of QI-Core's qicore-organization that makes its existing Organization.identifier:ccn slice (Identifier, patternIdentifier.system = http://terminology.hl7.org/NamingSystem/CMSCertificationNumber, both .value and .use required) mandatory — the standards-based way to carry CCN, replacing the custom extension. HQRSubmissionMeasureReport.reporter now targets HQRReportingOrganization specifically. The extension-based round-trip question this item originally asked still applies to HQRProgramYear, which remains extension-based by design, since there is no equivalent built-in MeasureReport element or slice to carry it.
5. Terminology bindings. Do CMS-approved value sets, beyond the generic QI-Core bindings, surface additional validation failures that need their own error category?
6. Cross-vendor interoperability. Can two independently built Submitter implementations produce payloads or pulls that a single Receiver accepts without vendor-specific accommodations?
7. Developer portal and endpoint naming. A developer portal where implementers can read, interact with, and test this guide's capabilities is an expected companion deliverable and has not yet been started. A related, still-open naming question: this guide may become the first phase of a broader, multi-program CCSQ receiving system, so both the developer portal location and the actual API endpoint naming are being considered generically rather than defaulting to HQR-specific naming, to avoid a rename if that broader system materializes.

HQR + QPP unification (forward-looking, not a Connectathon item)

CCSQ has discussed HQR's FHIR API as a potential first phase of a broader, multi-program receiving system, with QPP expected to fold in before the end of the decade (see Background). These items are what that would actually mean for this guide's design, not just its endpoint naming.

1. IG architecture: shared base vs. one expanded IG. If HQR and QPP eventually converge on one FHIR-based receiving system, should this remain a standalone HQR IG plus a separate QPP IG that both constrain a shared base profile, or should this IG itself expand to cover both programs directly? HQR and QPP have different rule-making cycles, measure sets, and submission calendars — coupling them into one IG's release cadence is a real cost, not just an implementation detail. The shared-base pattern (matching how QI-Core sits under program-specific IGs today) is the more likely direction, but this is not decided.
2. Facility-specific assumptions that wouldn't hold for QPP. CCN identifies facilities, and HQRSubmissionMeasureReport.reporter is structurally typed to HQRReportingOrganization (a QI-Core Organization profile) — both fit HQR's hospital/ASC/IPF reporters but not QPP's eligible-clinician reporters, who are identified by NPI/TIN and represented as Practitioner/PractitionerRole, not Organization. If a shared base profile is the direction (item #18), these HQR-specific assumptions would need to live in an HQR-specific layer rather than a shared base — worth flagging now, before more content is built on top of the current shape.
3. Program-modality honesty if unification proceeds. QPP includes cost measures, claims-based and registry reporting, and improvement activities that aren't MeasureReport-shaped at all. A unified direction would need to be as explicit as this guide already is about being a vertical slice — scoped to two programs' FHIR/eCQM-reportable measures, not a full replacement for either program's existing multi-modal reporting.

Data networks and exchange intermediaries (forward-looking, not a Connectathon item)

1. Could existing data-sharing networks reduce per-facility integration burden? This guide's exchange patterns — push submission and the invited-pull concept (see items #5, #8, #9) — both assume a direct facility-to-HQR relationship. Worth exploring whether existing infrastructure could sit between the two instead:
   • HIEs and Health Data Utilities (HDUs), many of which already aggregate clinical data from participating facilities for other purposes (care coordination, ADT alerting), could play the same role NHSN Link already plays for CDC today — HQR (or a facility acting through its HIE/HDU) pulling data-of-interest from a network that already holds it, rather than every facility independently building submission capability. Architecturally this is the same pull-based direction already under discussion here, just with a network operator standing in as the data source instead of the reporting facility itself.
   • TEFCA Qualified Health Information Networks (QHINs) extend the same idea nationally: a facility (or its EHR vendor) already participating in TEFCA could, in principle, make HQR data-of-interest discoverable the way clinical data is already exchanged for treatment or other approved Exchange Purposes — but this depends on whether quality reporting is, or becomes, a recognized TEFCA Exchange Purpose, which has not been confirmed here and needs direct verification against TEFCA's Common Agreement before this guide asserts anything more specific.
   • CMS-aligned networks (e.g., ACOs and other value-based care arrangements that already exchange bulk FHIR data with CMS) may be the most immediately tractable of the four, since they start from an existing bulk-data relationship with CMS rather than a net-new one — though which specific programs/networks this could extend to is itself still open.

   None of this changes HQRSubmissionMeasureReport today — the profile is intermediary-agnostic, since it constrains the payload shape, not who originates it. This is a real question for this guide's long-term exchange-pattern direction, not a decision made here.

DEQM realm migration follow-ups (forward-looking, not a Connectathon item)

1. $submit-data's eventual replacement needs a real payload-shape answer, not just a name (see item #7). This guide's design relies on submitting an array of Bundles in one call. Base FHIR R4 core doesn't support an array-of-Bundles operation until R6, and DEQM Universal Realm has retired its own submit-data operation in favor of a plain Bundle POST — neither of those paths preserves the array-of-Bundles shape this guide currently uses. Migrating to Universal Realm may require defining a new, HQR-specific operation for this, not reusing anything base-FHIR or DEQM-native currently offers.

Not being tested this round (explicitly out of scope)

Two different senses of "scope" are at play in this guide, and it's worth being precise about which one each item below is: HQRSubmissionMeasureReport is structurally measure-independent — it validates equally for any conformant measure, regardless of clinical domain or program (CMS138, an eligible-clinician/ambulatory measure, is deliberately used as a Data Element Testing Guide-style example precisely to demonstrate this — its inclusion is not a scope exception). Separately, this guide's stated program focus is Hospital IQR — that's a statement about which real-world reporting program this guide is being built and tested for, not a claim about what the profile can structurally validate. The items below are out of scope in the program-focus sense, not the structural sense:

• QRDA-to-FHIR cutover mechanics — a business and program decision, not a technical test.
• Provider-facing feedback and results reporting — a separate scope decision.
• Eligible-clinician, claims-based, web-based, and chart-abstracted measures as HQR's reporting program focus — Hospital IQR is this guide's stated target program, not a structural limitation of HQRSubmissionMeasureReport (see CMS138 note above).
• The full current-year IQR eCQM set — this guide profiles a single vertical slice, not the complete measure set.