CMS Hospital Quality Reporting FHIR Implementation Guide
0.1.0 - ci-build
CMS Hospital Quality Reporting FHIR Implementation Guide
0.1.0 - ci-build
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
The following package file includes an NPM package file used by many of the FHIR tools:
The source code for this implementation guide is maintained on GitHub.
Connectathon meta-content, not normative guidance. All data below is synthetic or de-identified test data, not real patient information. See Acceptance Criteria and the Data Element Testing Guide for how these test measures were selected.
Real, MADiE-exported test cases for CMS71 and CMS506 (maintained publicly by
cqframework, the organization behind the CQL/FHIR tooling MADiE
itself uses), plus MADiE-exported test data for EXMConnectathonSept2026Simple (built specifically
for this Connectathon), split into three bundle types per measure: Clinical Data (Patient,
Encounter, Observation, Condition, and similar data-of-interest resources, plus a Group
referencing all included patients), Measure Definition (Measure, Library — including its
compiled ELM content alongside the human-readable CQL source, for tooling that expects ELM
directly rather than translating CQL itself — and the ValueSet resources the measure's CQL logic
directly depends on), and Expected Results (the MeasureReport each patient's data is expected
to produce, for validating a Receiver's own calculation).
CMS71's source data is from an older QI-Core cycle (4.1.1) than this guide's pinned QI-Core 6.0.0;
fixes were applied to migrate it — Condition.meta.profile updated from the retired
qicore-condition to qicore-condition-encounter-diagnosis (QI-Core 6.0.0 splits Condition into
two profiles; all of CMS71's Condition instances use category=encounter-diagnosis, so the
mapping is unambiguous), a Coverage.relationship of self added where QI-Core 6.0.0 newly
requires it and the source data didn't have it, and a placeholder MedicationRequest.requester
(pointing at a Practitioner/example that doesn't exist anywhere in the source data — a MADiE
export convention, not a broken per-patient link) removed from all 12 instances that had it; none
of CMS71's population criteria reads requester, so it carried no measure-relevant information.
CMS506's source data was already built directly against QI-Core 6.0.0 and needed no changes.
EXMConnectathonSept2026Simple's source data was built directly against QI-Core 6.0.0 and needed no
changes. See scripts/generate-synthetic-data.py and scripts/generate-exmsimple-data.py in this
IG's source repository for the full generation logic and exact provenance.
Known gap, left as-is rather than guessed at: one CMS71 patient's Encounter has a malformed
diagnosis reference (wrong resource-type casing, and no Condition with that id exists in the
source data). A same-coded Condition ("Destruction of Right Atrium, Open Approach") does exist
for this patient, but it's already referenced by a different encounter roughly three weeks
later, and neither encounter's ablation-related data actually precedes it in time in a way that
would satisfy CMS71's "history of atrial ablation" exclusion logic regardless of which one the
reference pointed at. Redirecting it would have been a guess, not a verified fix, so this patient's
data should not be relied on to exercise that specific exclusion pathway — CMS71's other 40
patients are unaffected.
| Measure | Clinical Data | Measure Definition | Expected Results | Patients |
|---|---|---|---|---|
| CMS71 (STK-3) | cms71-clinical-data.json | cms71-measure-definition.json | cms71-expected-results.json | 41 |
| CMS506 | cms506-clinical-data.json | cms506-measure-definition.json | cms506-expected-results.json | 38 |
| EXMConnectathonSept2026Simple | exmsimple-clinical-data.json | exmsimple-measure-definition.json | exmsimple-expected-results.json | 3 |
Postman collection — example $submit-data push
requests (one per test measure, built from the synthetic patients above) and results-retrieval
searches, matching this guide's actor CapabilityStatements. Includes a separate folder for the
invited-pull concept ($bulk-submit-data / Bulk $export), presented for discussion only, not a
committed capability.
Clinical Data downloads are a source dataset, not a submission-ready payload. Each
*-clinical-data.json file in the table above is the full synthetic population for that measure —
a collection Bundle of every generated patient's data-of-interest resources, plus the Group
referencing them — with no MeasureReport, no evaluatedResource links, and no Parameters/
bundle submission envelope. The Postman collection's $submit-data requests do that assembly:
each selects one representative patient from the same Clinical Data file, builds the
HQRSubmissionMeasureReport-conformant MeasureReport with evaluatedResource pointing at that
patient's resources, and wraps the result in the Parameters shape $submit-data expects.
Building a custom submission from a Clinical Data download means reproducing that same assembly —
resubmitting the downloaded Bundle as-is will not work.
Package hl7.fhir.uv.extensions.r4#5.2.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Feb 10, 2025 21:45+1100+11:00) |
Package hl7.fhir.uv.extensions.r4#5.3.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, May 16, 2026 18:32+1000+10:00) |
Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00) |
Package hl7.fhir.uv.bulkdata#2.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00) |
Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. |
Package ihe.formatcode.fhir#1.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00) |
Package hl7.fhir.us.core#6.1.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Fri, Jun 30, 2023 14:02+0000+00:00) |
Package hl7.fhir.us.qicore#6.0.0 The QICore Implementation Guide defines a set of FHIR profiles with extensions and bindings needed to create interoperable, quality-focused applications. The profiles in this implementation guide derive from and extend the US Core profiles to provide a common foundation for building, sharing, and evaluating knowledge artifacts across quality improvement efforts in the US Realm. (built Fri, Mar 1, 2024 18:46+0000+00:00) |
Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00) |
Package hl7.fhir.uv.crmi#1.0.0 This implementation guide defines profiles, operations, capability statements and guidance to facilitate the content management lifecycle for authoring, publishing, distribution, and implementation of FHIR knowledge artifacts such as value sets, profiles, libraries, rules, and measures. The guide is intended to be used by specification and content implementation guide authors as both a dependency for validation of published artifacts, and a guide for construction and publication of content. (built Fri, May 31, 2024 16:38+0000+00:00) |
Package hl7.fhir.uv.cql#1.0.0 This implementation guide defines profiles, operations and guidance for the use of CQL with FHIR, both as a mechanism for querying, as well as inline and integrated usage as part of knowledge artifacts. (built Fri, May 31, 2024 14:18+0000+00:00) |
Package hl7.fhir.us.cqfmeasures#5.0.0 The Fast Healthcare Interoperability Resource (FHIR) Quality Measure Implementation Guide (this IG) describes an approach to representing Quality Measures (QMs) using the FHIR Clinical Reasoning Module and Clinical Quality Language (CQL) in the US Realm. However, this Implementation Guide can be usable for multiple use cases across domains, and much of the content is likely to be usable outside the US Realm. (built Mon, Nov 4, 2024 20:07+0000+00:00) |
Package hl7.fhir.uv.cpg#1.0.0 Implementation guidance for creating Clinical Practice Guidelines with formal artifacts to facilitate sharing and implementation of the guideline (built Thu, Feb 11, 2021 20:29+0000+00:00) |
Package fhir.cqf.common#4.0.1 This implementation guide contains common FHIR assets for use in CQFramework content IGs, including FHIRHelpers and the FHIR-ModelInfo libraries. (built Fri, Nov 12, 2021 16:25+1100+11:00) |
Package hl7.fhir.uv.cql#2.0.0 This implementation guide defines profiles, operations and guidance for the use of CQL with FHIR, both as a mechanism for querying, as well as inline and integrated usage as part of knowledge artifacts. (built Tue, Jul 8, 2025 14:47+0000+00:00) |
Package hl7.fhir.us.core#7.0.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Wed, May 8, 2024 15:33+0000+00:00) |
Package hl7.fhir.us.cql#2.0.0-ballot This implementation guide contains architectural guidance and re-usable libraries that facilitate the use of Clinical Quality Language (CQL) with FHIR in the US Realm, with an initial use case of Prior Authorization Support Questionnaires as described in the DaVinci Documentation Templates and Rules (DTR) implementation guide. Much of the guidance and content presented here is built on work done in the quality measurement domain, including patterns established by measure developers as part of testing and developing quality measures for use with FHIR. These patterns have been generalized to support US Core as well as harmonized to be usable across use cases. (built Fri, Apr 3, 2026 00:32+1100+11:00) |
Package fhir.onc.us-quality-core#0.5.0 The USQualityCore Implementation Guide defines a set of FHIR profiles with extensions and bindings needed to create interoperable, quality-focused applications. The profiles in this implementation guide derive from and extend the US Core profiles to provide a common foundation for building, sharing, and evaluating knowledge artifacts across quality improvement efforts in the US Realm. (built Mon, Jun 8, 2026 16:44+1000+10:00) |
Package hl7.fhir.uv.bulkdata#3.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Thu, Dec 11, 2025 13:43+0800+08:00) |
Package hl7.fhir.uv.tools.r4#1.1.2 This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00) |
Global Profiles:
All resources of these types must conform to these profiles.
This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (cms.fhir.us.hqr.r4) and R4B (cms.fhir.us.hqr.r4b) are available.
This publication includes IP covered under the following statements.
