October 7, 2012

The QRDA Category 1 XML Standard

The Quality Reporting Document Architecture (QRDA) Category 1 standard is a new XML standard designed for communicating patient-level clinical data that will be used to calculate Clinical Quality Measures (CQMs). This is an HL7 XML standard that is part of the Clinical Document Architecture  (CDA), which is an overall framework for expressing healthcare data in XML that is also stewarded by HL7.  

The QRDA Category 1 XML standard was created because systems needing to calculate Clinical Quality Measures (CMSs) could not guarantee that patient-level data would appear in the existing continuity of care standards such as the HITSP C32, HL7 Consolidated CDA (CCDA), and the ASTM Continuity of Care Record (CCR).  The QRDA Category 1 standard has been designed so that all of the clinical information needed for each specific CQM will need to be expressed within the QRDA Category 1 XML document. 

The QRDA Category 1 is a clinical document representing a single patient. It defines sections containing measure information and patient data that meets criteria for a measure. It also contains information on the reporting period. The markup for the patient data is the same as a CCDA document.  

In a nutshell, the QRDA Category 1 XML standard will include the templates needed for each attribute in each CQM that a patient could provide clinical data to be used to calculate any number of CQMs.  Additionally, more than one CQM can be included in the request for the clinical data associated with one patient.  

If you view the illustration below, you can see that an Electronic Health Record (EHR) system may be requested to generate QRDA Category 1 XML for patients to be used to drive the calculation of the Diabetes Blood Pressure Management CQM AND the Diabetes LDL Test CQM.  In that case, all clinical data that could be used to drive the calculation of either of those CQMs must appear in the QRDA Category 1 for each patient in the EHR.  Further, additional clinical information associated with each patient is not required, and will result in warnings (but not errors) in the QRDA Category 1 for each patient.

c32/ccda vs qrda category 1
The C32/CCDA vs QRDA Category 1
Only relevant data is expressed in the QRDA Category 1
based on the need for specific CQMs
I personally feel that the QRDA Category 1 reflects the failures of the CCR, C32, and CCDA standards.  It is difficult to explain why a single standard for expressing patient-level data that is interoperable and can provide sufficient fidelity of data for calculating CQMs does still not exist.  It's 2012.

Where problems are identified with a CQM when the CCR... the C32... the CCDA do not provide sufficient information for calculating MU CQMs, CQMs could be adjusted to be simpler, and conform to data that must exist in the CCR... the C32... the CCDA.  This lack of a good continuity of care standard for a single patient record is what I feel is the root cause of all of this work.  

Knowing that the QRDA Category 1 isn't going away anytime soon, I have found that the use of the QRDA Category 1 XML standard has been difficult due to lack of validation tests and example QRDA Category 1 XML files.  However, I suspect that these two shortcomings will be addressed in time.

The objective of using the QRDA Category 1 XML standard as a mechanism to present clinical quality data associated with a patient should unambiguously define clinical attributes so that there’s no confusion about what is expected of an EHR system's ability to export in XML artifacts.  Time will tell if this objective is realized in EHR systems... I remain skeptical.  I think we will know a lot more by 2013, when this standard is officially introduced into the Meaningful Use Stage 2 program.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2012.
Creative Commons License


  1. Rob,

    Thank you 1000 times for your work. I have just come in to the realm of working with Meaningful Use in the past 4 months. I have run in to a lot of roadblocks, misinformation and confusion between Stage 1 and Stage 2...but have now found your blog. The matter-of-fact way that you put this information together is refreshing, and very much appreciated.

  2. Erik, glad I am helping, and glad to find that others are actually reading the blog!

  3. Hi Rob ,

    Thanks for the explanation of difference between CDA and QRDA 1. We are planning to implement a system using SQL Server . We are planning to import CDA data into SQL Server and than output the QRDA Cat 1 and 3 from it . Do you know any database schema that we can use ? Also what decided what data to include in QRDA cat I report ?

    1. Hello George. The popHealth http://projectpophealth.org and Cypress http://projectcypress.org software systems use a non-relational MongoDB database to store the patient data that can be transformed into QRDA Category 1 XML with Cypress. The infrastructure to support QRDA Category 3 XML was started under popHealth, but halted mid-development by our sponsor. Unfortunately, I do not know about a free open source relational database schema that could be used to store this information, but I know that most of the major EHR products use either a relational DB, or a data warehouse to store data, and then SQL or stored procedures to process the CQM results. However, I doubt that you will find much assistance from the vendor community, since they almost all view their software as proprietary and closed.

  4. Hey Rob

    Your blog is awesome resource for beginners like me . Can you please share any resources you would recommend for a person implementing MU Stage 2 CQM and reporting . Also how can I validate QRDA 1 file ? Is there any library that I can use ?

    1. You can use the open source Cypress project to validate QRDA Category 1 XML and QRDA Category 3 XML. See http://projectcypress.org

      Setup of Cypress can be a bit heavy. See:


      If that is a bit too much, and you are familiar with Schematron, you can use just the QRDA Schematron rules that were developed by HL7 and are available inside of Cypress here:


      Hope this helps.

    2. Thank you for quick reply . I went through cypress and had some questions .

      1. Does cypress use https://github.com/projectcypress/health-data-standards for importing and exporting documents ?
      2. Does cypress Import entire CDA document or only information required for calculation ?
      3. Can cypress be used for testing 2014 CQM ?http://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/2014_ClinicalQualityMeasures.html


    3. 1. Yes.
      2. Only information relevant to the CQM under test* (but you mean QRDA document, not CDA document... QRDA documents are all CDA documents)
      3. Yes, Cypress is the sole tool that is recognized by ONC for testing the 2014 Outpatient and Inpatient CQMs.

  5. Thank you Rob, by any chance do you know where I can find a listing of all the possible QRDA sections (i.e. Lab Results, Vitals, Medications, etc.)

    1. Hello Steve, your best place to lookup the specific details are on the HL7 QRDA Cat 1 spec here http://www.hl7.org/implement/standards/product_brief.cfm?product_id=35

  6. Hey Rob, Thanks a lot for the information. I have a question related to the implementation of CCDA and QRDA for MU stage 2. Do you think it is feasible to reuse CCDA document import/export functionalities with some tweaks to import/export QRDA documents?

    Also what are the major challenges you feel in doing this?

    1. The problem you will run into is that the CCDA is a standard that allows for maybe 85% - 90% of the clinical data needed for the CQMs. The problem is that to accurately calculate the CQM results, that gap is a big concern. Since the QRDA Category 1 uses the HQMF definition of the measure to determine how to represent all the clonal data for a patient record, the QRDA Category 1 is at least a tractable standard for expressing the data. Ie. there is a guide from the HQMF definition of the CQM regarding how to express the data in the QRDA Category 1. You can read more about the rationale to not use the CCDA, and instead use the QRDA Category 1 XML if you click here http://projectcypress.org/news.html and scroll to the news story all the way at the bottom. We put this together for the broader EHR vendor and ATL community to explain why those gaps in the CCDA were too concerning to use the CCDA as an XML standard for expressing the data for the CQMs. The concern we had was if there are pay-for-performance programs adopted that use the CQMs to gate compensation… and then a provider has captured the clinical data into the numerator for a patient… but the CCDA cannot express that data… then you will have an exceedingly upset provider. Imagine getting a disincentive "hit" on your CMS payment because a CQM failed to meet a threshold, only to discover that you had performed within the threshold but the CCDA standard failed to allow the EHR to express the patient-level data. Hope this rationale makes sense.

    2. Hi Rob, Thanks for the quick response.

      In my basic research to compare CCDA and QRDA Cat I to identify the gaps between the formats. I can see that CCDA mainly lacks in the capability to present clinical attributes, which are part of EP CQMs but no all of them.

      What are your thoughts about the CQMs which do not require these elements?

      So to summarize the questions "Are there some universal gaps in CCDA which do not allow it to report any CQMs or CCDA is not capable to report some specific CQMs?"

      Thanks again.

    3. Well, I'm sure that there is support for some of the MU Stage 2 CQMs with the CCDA. It's the fact that only some of the CQMs will work that causes me and the policy-makers the heartache.

      The measure that made it from MU Stage 1 to MU Stage 2 are probably the best candidates. For instance, without doing the rigorous digging, the diabetic measures and hypertensive measures are probably a slam dunk. They only consider basic clinical attributes like the encounters, the conditions, the labs and medications. I might have forgotten some other attributes, but those are well-defined in the CCDA or even the C32.

      Without performing the rigorous assessment of the scope of the problem, the issue of incomplete support of the CQMs was mostly tied to the CQMs introduced into MU Stage 2 or CQMs that went through a significant re-write.

      This issue of incomplete clinical data is really prevalent with the hospital CQMs. We found information like "hospital transfer date time" in the hospital CQMs and I wouldn't know where to realistically expect to find that in a CCDA document.

      So yes, you can probably get some good number of the MU Stage 2 EP CQMs working with a well-formed and rich CCDA document. However, you will have some non-trivial number of problems with all the EP CQMs and bigger problems with the EH CQMs.

    4. Thanks a lot Rob for the detailed explanation. In my initial analysis to compare a small list of EP Stage 1 CQM data requirements with the CCDA data capturing requirements, I was unable to figure out any major differences and that's why I thought to validate my understanding.

      Thanks again for pointing out the major shortcomings and areas to which they are linked.

  7. Hi
    In some of CQM measure we require cumalative medications days.
    Do we need to show the cumalative days for medication in QRDA 1 template.
    Please solve my query .

  8. Hello,
    I was just wondering how to generate a QRDA Category I or III file using an EHR, for instance let's use eClinicalworks. I cannot find any how-to's on this topic.

  9. Hi Rob, I wonder if you'd be willing to answer some questions for me, representing the OpenEMR project, regarding implementation of eCQMs and QRDA reporting. I can't see from your web site how to contact you directly, so please email me if you are willing: rod@sunsetsystems.com. Thanks!