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 Element Testing Guide

Scope

This page covers this Connectathon's three either/or test measures — CMS71, CMS506, and EXMConnectathonSept2026Simple (https://madie.cms.gov/Measure/EXMConnectathonSept2026Simple) — not the full Hospital IQR eCQM set. None of the three is a primary or stretch measure; participants may exercise any of them. 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 (see Open Questions item #4). If a measure like CMS832 is ever added to the test lineup, it belongs on this page only after the same per-element gap check CMS71/CMS506 already got.

EXMConnectathonSept2026Simple carries deliberately minimal clinical data criteria — one Patient demographic element — so it exists mainly to exercise DEQM exchange mechanics without the noise of real measure-calculation complexity, but it does get its own (much shorter) checklist below.

Purpose

HQRSubmissionMeasureReport is intentionally measure-independent — it constrains the MeasureReport wrapper itself (program year, reporter/subject typing) but does not define cardinality or must-support rules for clinical data elements. (CMS Certification Number is a separate, Organization-level identifier, not a MeasureReport element — see the cross-cutting table below for how it's enforced.) Data-element rules are inherited from this guide's base clinical profiles (QI-Core 6.0.0 in version 0.1.0; US Quality Core is the version 1.0.0 target — see Dependencies).

That means the "is this data element required, and in what shape" question is really: does each selected test measure's own data criteria line up with what QI-Core already makes must-support? This page answers that, per test measure, so Submitters know what to populate and Receivers know what to expect and be able to extract for calculation — bounded, per-measure verification work, not a from-scratch clinical data model exercise. It has already been done once, at a pass/fail level, as part of selecting CMS71/CMS506 for this event (see Acceptance Criteria); this page is the detailed, element-by-element version of that same check.

Why this matters under the Data Exchange MeasureReport pattern

This guide's exchange pattern is receiver-calculates: the Submitter does not send a pre-calculated result. It sends raw data-of-interest resources, referenced from the MeasureReport via evaluatedResource and packaged together with it in one submission Bundle, and the Receiver runs the measure's CQL against that raw data itself (see Dependencies for the pattern comparison). That makes this page load-bearing for both sides, in different ways:

• Submitting System: must actually populate every data element the measure's logic reads — a technically conformant but data-sparse MeasureReport/Bundle will pass structural validation but produce an incorrect (likely null/exception) calculation result on the Receiver side.
• Receiving System: must know which QI-Core-profiled resource type and element each measure's data criteria maps to, in order to locate and extract it from the submitted Bundle correctly — instead of receiving it pre-shaped by the Submitter's own calculation engine.

Cross-cutting elements (all three measures)

These come from HQRSubmissionMeasureReport and its DEQM STU5 parent directly, not from either measure's data criteria — every submission needs them regardless of which measure is under test.

Element	Source	Cardinality	Notes
MeasureReport.extension:programYear (HQRProgramYear)	HQR-specific, on MeasureReport	1..1, MS	Mandatory on this profile
MeasureReport.reporter	DEQM STU5 parent, narrowed by HQR	1..1, MS, targetProfile = HQRReportingOrganization	HQR narrows the parent's qicore-organization target further, to require CCN (see below)
MeasureReport.extension:reportingVendor	DEQM STU5's own extension-reportingVendor, reused as-is	0..1, MS, targetProfile = plain QI-Core Organization	Identifies who technically submitted the data, when different from reporter — e.g. a health IT vendor or HIE submitting on a facility's behalf. Not narrowed to HQRReportingOrganization: a vendor isn't a CMS-certified facility and shouldn't need a CCN.
MeasureReport.subject	DEQM STU5 parent, narrowed by HQR	1..1, MS, targetProfile = QICorePatient	HQR narrows the parent's broader target list (Patient, Practitioner, PractitionerRole, Location, Device, RelatedPerson, Group) to QICorePatient only, since this guide's scope is individual patient-level eCQM data, not population/Group reporting
MeasureReport.type	DEQM STU5 parent (datax-measurereport-deqm)	fixed data-collection	Confirms receiver-calculates, raw-data-only pattern

CMS Certification Number (CCN) is not a MeasureReport element — it's carried on the reporting Organization (the reporter), via 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) mandatory. This replaced an earlier custom valueString extension, which duplicated something QI-Core already solved with a standards-based identifier slice — see Open Questions item #14.

Per-measure data element checklists

CMS71 / STK-3 — Anticoagulation Therapy for Atrial Fibrillation/Flutter

Version referenced: v13.1.000 (2024 Hospital IP cycle) — [confirm this is still the version in force for the 2026-09 Connectathon before finalizing; a newer version may exist]

Data Element (measure logic)	FHIR Resource	QI-Core Profile	Sender: populate?	Receiver: can extract?
Encounter, Performed: Nonelective Inpatient Encounter	Encounter	qicore-encounter	Yes	Confirmed profile
Diagnosis: Atrial Fibrillation or Flutter	Condition	qicore-condition-encounter-diagnosis	Yes	Resolved against the actual population CQL: the qualifying Condition is retrieved via Encounter.diagnosis.condition (CQMCommon.cql's encounterDiagnosis()), the same real-world linkage qicore-condition-encounter-diagnosis exists to represent (it fixes Condition.category to encounter-diagnosis). All 136 synthetic CMS71 Condition instances already use this profile.
Diagnosis/Assessment: History of Atrial Ablation	Condition / Observation	ambiguous	Only if excluding on this basis	Unverified — QDM "Assessment, Performed" has no single obvious QI-Core profile. One synthetic patient's own data has a separate, concrete gap here too — see Downloads
Procedure, Performed: Atrial Ablation	Procedure	qicore-procedure	Only if excluding on this basis	Confirmed profile
Medication, Discharge: Anticoagulant Therapy	MedicationRequest	qicore-medicationrequest, category = discharge	Yes	Resolved: QI-Core doesn't split MedicationRequest by context the way it splits Condition — instead, MedicationRequest.category is an open, must-support element bound to a valueset that already includes a standard discharge code (http://terminology.hl7.org/CodeSystem/medicationrequest-category), matching the real population CQL's own isDischarge() check. qicore-medicationrequest is the correct and only profile; discharge context is carried in category, not a separate profile.
Medication, Not Discharged: Anticoagulant Therapy	MedicationRequest (negation)	qicore-medicationnotrequested	Only if applicable	Standard negation-profile convention
Intervention: Comfort Measures (exclusion)	ServiceRequest / CarePlan	not confirmed	Only if excluding on this basis	Unverified — QDM "Intervention" has no 1:1 FHIR mapping

CMS506 — Safe Use of Opioids – Concurrent Prescribing

Version referenced: v7.0.000 — [confirm current version for 2026-09 cycle]

Data Element (measure logic)	FHIR Resource	QI-Core Profile	Sender: populate?	Receiver: can extract?
Encounter, Performed: Encounter Inpatient	Encounter	qicore-encounter	Yes	Confirmed profile
Medication, Discharge: Schedule II/III/IV Opioids	MedicationRequest	qicore-medicationrequest, category = discharge	Yes	Same resolution as CMS71 — see above
Medication, Discharge: Schedule IV Benzodiazepines	MedicationRequest	qicore-medicationrequest, category = discharge	Yes	Same resolution as CMS71 — see above
Diagnosis: Cancer-Related Pain (exclusion)	Condition	qicore-condition-encounter-diagnosis or qicore-condition-problems-health-concerns	Only if excluding on this basis	Resolved: the CQL explicitly checks both, via isProblemListItem()/isHealthConcern() or encounterDiagnosis() — either profile satisfies this element by design, not an open ambiguity.
Diagnosis: Sickle Cell Disease with and without Crisis (exclusion)	Condition	either QI-Core Condition profile	Only if excluding on this basis	Resolved: the CQL retrieves this Condition with no category-based check at all, so it doesn't matter which of the two QI-Core Condition profiles is used.
Diagnosis: Opioid Use Disorder (exclusion)	Condition	either QI-Core Condition profile	Only if excluding on this basis	Resolved: same as Sickle Cell Disease — no category-based CQL check, so either profile works.
Intervention: Palliative or Hospice Care (exclusion)	ServiceRequest / CarePlan	not confirmed	Only if excluding on this basis	Unverified — same mapping gap as CMS71

EXMConnectathonSept2026Simple

A MADiE-authored measure (https://madie.cms.gov/Measure/EXMConnectathonSept2026Simple, draft/ experimental, v0.0.000) built specifically for this Connectathon, with deliberately minimal CQL data criteria — it exists to let Submitters and Receivers exercise $submit-data and the Data Exchange MeasureReport pattern without the data-element complexity CMS71/CMS506 involve.

Data Element (measure logic)	FHIR Resource	QI-Core Profile	Sender: populate?	Receiver: can extract?
Patient, Sex (Numerator: Patient.sex = '248152002')	Patient	qicore-patient (extension:us-core-sex)	Yes	Confirmed profile — the CQL's Patient.sex resolves to the US Core Sex extension, present and SNOMED-coded on all three provided test patients

Its Initial Population and Denominator are both simply true — no data element backs them. Do not treat a successful exchange against this measure as validating real-world data-element coverage the way a full eCQM would — that's what the CMS71/CMS506 checklists above are for. Real, MADiE-exported test data (three patients, the measure definition, and expected results) is available on the Downloads page.

Sender checklist (all three measures)

• Test data includes every data element flagged "Yes" above, not just enough to pass structural (must-support) validation — a structurally valid but data-sparse submission will still fail calculation on the Receiver side.
• Submission Bundle entries reference the correct QI-Core profile per resource — not a plain, unprofiled resource instance. Both the reporting Organization (HQRReportingOrganization) and the subject Patient (QICorePatient) are QI-Core-conformant.
• Program year extension populated on the MeasureReport itself; CCN identifier populated on the reporting Organization — not the same resource (see the cross-cutting table above).
• EXMConnectathonSept2026Simple satisfies these with just its one Patient.sex data element — this checklist is primarily about CMS71/CMS506.

Receiver checklist (all three measures)

• Calculation engine can resolve each measure's CQL data criteria to a specific QI-Core profile + element path — not just "some Condition/Observation/etc. exists somewhere in the Bundle."
• Confirm handling for the ambiguous rows above (which Condition profile, discharge-context medications) — if your engine assumes one specific profile, say so, so Submitters can match it or the gap becomes a documented open question rather than a silent test failure.
• Confirm rejection behavior: if a required data element for the chosen measure is absent from an otherwise-conformant submission, does the Receiver return a specific, actionable error rather than a generic calculation failure? (See Acceptance Criteria #4.)

Open items to resolve

1. Confirm the in-force eCQM version year for CMS71 and CMS506 against the 2026-09 Connectathon cycle (versions above were the most recent confirmed at time of writing; EXMConnectathonSept2026Simple is versioned directly as v0.0.000 and has no separate eCQM version-year cycle to confirm).
2. Resolve which QI-Core Condition profile (qicore-condition-encounter-diagnosis vs. qicore-condition-problems-health-concerns) applies to each Diagnosis element — affects both CMS71 and CMS506.
3. Decide how "Medication, Discharge" data elements are represented, since QI-Core has no dedicated discharge-context medication profile — affects both CMS71 and CMS506.
4. If CMS832 (or any other measure) is added back to this Connectathon's test lineup, give it the same per-element treatment before publishing it here — see Open Questions item #4.