The Standard Underneath It
QRDA constrains HL7 Clinical Document Architecture Release 2, the same base standard behind C-CDA. Documents are XML with a header identifying the reporting entity and body sections carrying measure data.
Custom Software
What Is QRDA (Quality Reporting Document Architecture)?
QRDA, or Quality Reporting Document Architecture, is an HL7 standard for exchanging electronic clinical quality measure data. It defines the document structure that hospitals and clinicians use to submit eCQM results to the Centers for Medicare and Medicaid Services and other quality programs. QRDA is built on HL7 Clinical Document Architecture Release 2, which means a QRDA submission is an XML document constrained by templates rather than an API call or a flat data file.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted Partners
Trusted by Industry Leaders Worldwide
Recognition
Awards & Recognitions
What QRDA Is and Where It Sits in Quality Reporting
Quality measurement has two distinct halves. The measure logic defines what to count, expressed through the Quality Data Model and Clinical Quality Language. QRDA defines how to package the answer and send it. Confusing the two is the most common source of implementation misunderstanding, because a correctly calculated measure can still fail submission if the document structure is wrong, and a structurally valid document can carry results that were calculated against the wrong measure version. QRDA is transport and structure, not calculation.
What a QRDA Document Contains
A submission identifies the program, reporting period, submitting entity, measures reported, and either patient-level clinical data or aggregate counts, depending on category. Template identifiers govern each element’s structure.
Who Produces QRDA Files
Certified EHR technology generates them, often supplemented by registry platforms, quality analytics vendors, or in-house reporting layers built over a clinical data warehouse.
Who Consumes Them
CMS is the primary recipient through its submission systems. State agencies, registries, accountable care organizations, and payer quality programs also accept QRDA in some workflows.
Why the Standard Exists
Before eCQM reporting, quality submission meant manual abstraction from charts. QRDA made automated extraction possible, which is what turned quality reporting into a data engineering problem rather than a staffing one.
The Three QRDA Categories and Which One You Need
QRDA defines three report categories, and only two matter in practice. Category I is a patient-level report, one document per patient, containing the clinical data elements that drove measure calculation. Category III is an aggregate report containing only the summarized results across a population. Category II, a patient list report, was defined in the standard but never gained meaningful adoption in CMS programs. Which category you produce is determined by the program you report to, not by preference, so the program requirement should drive architecture decisions from the start.
01
Category I: Individual Patient Report
One document per patient per reporting period, carrying the underlying clinical data elements. Volume is substantial, since a hospital reporting a full population generates one file per included encounter.
02
Category II: Patient List Report
Defined in the standard as a roster-style report spanning multiple patients for a measure. It has seen little practical use in federal reporting programs and rarely appears in vendor implementations.
03
Category III: Aggregate Report
A single document carrying population counts and performance results per measure, with no patient-level clinical detail. Far smaller than Category I and used where only summary results are required.
04
How the Program Decides for You
Hospital eCQM reporting requires Category I. Eligible clinician programs require Category III. Building a pipeline that produces only one when your organization spans both settings is a common early architecture mistake.
05
Where the Source Data Comes From
Both categories depend on structured clinical data captured during care. Our healthcare data lake architecture post covers assembling the source layer that quality extraction runs against.
How CMS Uses QRDA Across Its Reporting Programs
CMS publishes its own implementation guides constraining the HL7 standard further, and these are the documents that actually govern submission. The current QRDA Category III guide builds on the HL7 QRDA Category III Release 1 specification published in September 2021, while Category I builds on QRDA Category I Release 1, Standard for Trial Use 5.3. Guides are versioned by reporting year and released roughly annually. Using last year’s guide against this year’s submission window is a routine cause of rejected files, because template identifiers and measure identifiers change between editions.
Hospital Quality Reporting Uses Category I
The CMS QRDA I guide covers hospital eCQM submission for the Hospital Inpatient Quality Reporting Program, the Medicare Promoting Interoperability Program, and the Outpatient Quality Reporting Program.
Eligible Clinician Programs Use Category III
The CMS QRDA III guide covers eligible clinician programs including MIPS, MIPS Value Pathways, the Alternative Payment Model Performance Pathway, APP Plus, and Shared Savings Program Promoting Interoperability.
The Annual Implementation Guide Cadence
CMS published the 2027 QRDA I hospital guide in May 2026 and the 2027 QRDA III clinician guide in July 2026, with draft versions circulated for public comment beforehand.
Schematron Files Do the Validating
Each guide ships with a Schematron and sample files. Validating locally against the correct year’s Schematron before submission catches most conformance errors far more cheaply than a rejected upload.
Program Changes Land in the Guides
The 2026 clinician guide removed Primary Care First and Making Care Primary submission guidance entirely and updated eCQM identifiers for the performance period. Program participation changes surface as template changes.
CMS Context and Program Structure
Understanding which CMS program applies determines everything downstream. Our CMS glossary entry outlines the agency’s quality programs and their reporting obligations.
What Actually Goes Wrong in QRDA Implementations
QRDA failures cluster into a small number of predictable patterns, and almost none of them are about XML syntax. They are versioning problems, data capture problems, and validation problems mistaken for one another. A team that treats QRDA as a serialization task will produce documents that validate cleanly and still report the wrong numbers, because the measure logic ran against data that was never captured in the structured fields the Quality Data Model expects. The expensive discoveries happen at submission deadline rather than during development.
Template and Identifier Version Drift
Template identifiers carry version extensions that change between guide editions. Hardcoding them, rather than driving them from the applicable year’s guide, breaks submissions annually.
Measure Identifiers Change Every Year
eCQM UUIDs are updated for each performance period. Reusing prior-year identifiers produces documents that pass structural validation and are rejected or misattributed downstream.
Structured Capture Gaps
Measure logic requires specific coded data elements. If clinicians record information in free text, the measure denominator will be wrong regardless of how correctly the QRDA document is built.
Schematron Validity Is Not Acceptance
Schematron checks conformance to templates. It does not verify program eligibility, entity identifiers, or business rules applied at submission, so local validation success does not guarantee acceptance.
Retain the Source Data, Not Just the Output
Audits and resubmissions require regenerating reports. Teams that keep only submitted XML, without the underlying extract and measure version, cannot reproduce or correct a prior period.
Aggregation Across Multiple Systems
Organizations running several EHRs must reconcile patient identity and encounter attribution before aggregation. Our population health entry covers the cohort definition problems this creates.
QRDA and the Shift Toward FHIR-Based Quality Reporting
QRDA is a CDA-based document standard, and the wider direction of travel in health IT is toward FHIR APIs. That tension is real but slower moving than vendor marketing suggests. HL7 has published FHIR-based quality reporting specifications, notably the Data Exchange for Quality Measures implementation guide developed through the Da Vinci Project, and CMS has signalled a long-term intent to move toward fully digital quality measures. Meanwhile QRDA remains the required submission format for federal programs, with new guide editions published each year. Both realities need to hold in the same roadmap.
The FHIR Alternative
The Data Exchange for Quality Measures implementation guide defines FHIR-based patterns for exchanging measure data and results, aimed at replacing document submission with API interaction over time.
Where Da Vinci Fits
Payer and provider quality data exchange use cases have been developed largely through the Da Vinci accelerator. Our Da Vinci Project entry covers its implementation guide portfolio.
Why QRDA Is Not Going Away Soon
Federal submission systems, certification criteria, and a decade of vendor tooling are built around it. CMS continues publishing annual guides, which is the clearest signal of near-term continuity.
The Historical Thread
Quality reporting obligations originate in earlier EHR incentive programs. Our Meaningful Use entry traces how those requirements became today’s promoting interoperability measures.
How To Plan For Both
Build measure calculation independent of output format, then treat QRDA and FHIR as serialization targets. Teams that couple calculation logic to CDA generation pay for it twice.
FAQs
Frequently Asked Questions About QRDA
QRDA questions from engineering teams tend to concentrate on category selection, versioning, and validation, because those are the three areas where the standard’s documentation assumes prior familiarity with CDA. Answers below reflect the position as of September 2026. Implementation guides are revised annually, so confirm the applicable year’s guide and Schematron against the eCQI Resource Center before building or submitting rather than relying on any secondary summary, including this one.
Quality Reporting Document Architecture. It is an HL7 standard built on Clinical Document Architecture Release 2, defining how electronic clinical quality measure data is structured for submission.
Category I is a patient-level report containing the clinical data behind measure calculation, one document per patient. Category III is a single aggregate report carrying only summarized results per measure.
Hospital eCQM reporting uses Category I. Eligible clinician programs use Category III. Organizations spanning both inpatient and clinician settings need pipelines capable of producing each.
No, though both constrain HL7 Clinical Document Architecture Release 2. C-CDA carries clinical summaries for care coordination. QRDA carries quality measure data for reporting programs.
CMS publishes new guides for each reporting year, with drafts released for public comment first. Template identifiers and measure identifiers commonly change between editions.
Not currently. FHIR-based quality reporting specifications exist and CMS has signalled a long-term shift, but QRDA remains the required submission format for federal programs today.
The eCQI Resource Center hosts current CMS implementation guides, Schematrons, sample files, and a known issues dashboard. Technical questions route through the ASTP/ONC project tracking system.