[QRDA-70] "Smoking gun" discrepancy between HL7 specification and Final Rule? Created: 03/09/13  Updated: 12/22/20  Resolved: 08/15/13

Status: Resolved
Project: QRDA Issue Tracker
Component/s: None

Type: Policy/ Guidance Priority: Moderate
Reporter: Sasha TerMaat (Inactive) Assignee: Yan Heras
Resolution: Delivered Votes: 3
Labels: Policy, QRDA-I

Issue Links:
Duplicate
duplicates QRDA-61 CQM Reporting in QRDA Category I format Resolved
Solution: This had been answered previously in issue CQM-335. From the policy perspective, CMS prefers to receive only the data elements that are part of the measure specifications for the CQM(s) being submitted. The file would not likely get rejected by the receiving system if it contains additional data elements, but we strongly encourage restricting the submission to the data elements in the measure specifications.

The example shown here is correctly interpreted. You can "cease searching as soon as the engine identifies one qualifying diagnoses".

 Description   

The HL7 implementation guide states the following:

The EHR may have more data than are relevant to the referenced eMeasure(s) and more data than are needed to compute the criteria. For instance, a patient who has been in the Intensive Care Unit undergoing continuous blood pressure monitoring will have reams of blood pressure observations. QDM-based QRDA adheres to a "smoking gun" philosophy where, at a minimum, the conclusive evidence needed to confirm that a criterion was met shall be included in the instance.
the very least, the QRDA document should include:
• For each data element in each referenced eMeasur, smoking gun data that offers confirmatory proof, where a patient has met the criterion. (For disjunctive criteria, e.g., where a criterion can be satisfied by either of two data elements, include smoking gun data for both data elements).
• Stratification variables, supplemental data elements, risk adjustment variables, and any other data element specified in the referenced eMeasure(s)

A quality program implementing QRDA will often provide prescriptive guidelines that define additional data, outside the smoking gun, that may or must be sent (such as the complete problem or medication list). Where such prescriptive guidelines exist, those take precedence over the more general guidance provided here. In other words, the "smoking gun" heuristic ensures that the minimum is present in the QRDA, and does not preclude inclusion of additional data.

We did not find any additional guidelines in the final rules. Is further guidance forthcoming? If so, when is it expected?

Can we assume “smoking gun” philosophy for what needs to be included in the QRDA I document and only include data elements that affect the outcome for a given measure? This is different than how Cypress is testing and validating EHRs so again that seems a bit misaligned.

 Comments   
Comment by Bob Dolin (Inactive) [ 08/15/13 ]

Hi Sasha, Your interpretation is correct. You can "cease searching as soon as the engine identifies one qualifying diagnoses".

Comment by Sasha TerMaat (Inactive) [ 06/05/13 ]

I know we are starting to have some of the same discussion here and in issue CQM-620. Was the example provided in the other issue helpful? Was my restatement of the situation in my earlier comment in this thread accurate? Is there any additional information I can provide here?

Comment by Sasha TerMaat (Inactive) [ 05/03/13 ]

Thanks Maria for referring us to that other ticket, the information is very helpful. Just to make sure I understand, across the two tickets you are saying that:

(1) Data that is not part of the measures being reported should obviously not be included, though it is not likely to cause a rejection. So an irrelevant asthma diagnosis should not be included in reporting a diabetes measure.
(2) Smoking gun data (for example, if there are 10 qualifying diagnoses for the measure being reported) is optional. So if there are 10 diabetes diagnoses falling into the same value set, including either 1 (to show that it qualifies) or all 10 is acceptable, neither are going to be rejected.

Am I understanding (2) correctly? I follow (1) but I was inferring (2) more out of the other comments and want to be sure I understand.

For a software developer, the computation of the xml can be faster if you cease searching as soon as the engine identifies one qualifying diagnoses and moves to the next data element. If it is necessary to continue exhaustively searching all of the data to find all possible items in that value set, then the engine has to comb through more data.

Comment by Maria Michaels (Inactive) [ 05/03/13 ]

This had been answered previously in issue CQM-335. From the policy perspective, CMS prefers to receive only the data elements that are part of the measure specifications for the CQM(s) being submitted. The file would not likely get rejected by the receiving system if it contains additional data elements, but we strongly encourage restricting the submission to the data elements in the measure specifications.

Comment by Sasha TerMaat (Inactive) [ 05/02/13 ]

Checking in again, is there any progress on this issue?

Comment by Sasha TerMaat (Inactive) [ 03/28/13 ]

Checking in since it's been about three weeks since this was submitted. Will CMS be expecting XML including all of the data or just the smoking gun data per the QRDA guidance?

Comment by Sasha TerMaat (Inactive) [ 03/20/13 ]

Apologies, the anonymous comment was me (Sasha) – I neglected to log in.

Comment by Anonymous [ 03/20/13 ]

Yes, I think this is a question for a combination of CMS and ONC first, and then possibly Cypress. It seems that CMS and ONC should align on what CMS wants for electronic submission being the same as what is required in certification. Then if what CMS wants does not equal how Cypress is currently testing, Cypress might need updates.

Comment by Rob McCready (Inactive) [ 03/15/13 ]

This is a policy issue for the ONC testing and certification team on the use of the Cypress test data.

As of the Cypress v2.0 release in December 2012, and the Cypress v2.1 release in February 2013, the patient records were crafted to be a smallest number possible by providing additional clinical attributes that can execute numerous CQMs using a single patient record. Removing additional clinical data on each record could be something that future versions of Cypress support, but that will increase the burden on EHR vendors by requiring larger numbers of patient records to be manually entered.

ONC is aware of and tracking this topic, and are best qualified to comment on this issue and if the change will be made to Cypress, the test procedures, or the final rule.

Generated at Sun Aug 31 08:14:54 UTC 2025 using Jira 10.3.8#10030008-sha1:cdaed80cecc964184c5b19b002388d56f96e274e.