I am also facing the same issue. We have implemented a check in generating our QRDA I, that, if negation indicator is true, then the reason code have to be there otherwise the file would not be generated. As per HL7, the above scenario is valid.

Clark-

1) By "Filtering" I am just referring to section 3.1 of the QDM.

"Attribute filters can be applied to QDM elements to further restrict the set of events that are returned. These filters indicate a condition that the value of the attribute must satisfy for the given event to be included in the set."

In this specific case, the negated event does not meet the filter criteria to be include in the set. i.e., it does not have a coded value from the necessary valueset.

2) From a QDM perspective it is likely true that it could never match any criteria. This concept does not appear to have a clear mapping, nor is it used in any QDM based eCQMs. Because of this, we are considering removing these "reasonless" negated elements from our QRDA export.

For more information of what "no known" means, section 3.3 of the QRDA Category I Implementation Guide talks at length about 3.3 "Unknown" and "No Known Information."

As an aside, its likely that your implementation could treat these "reasonless" negations similar to how you would treat an entry will a nullFlavored code.

-Dave Czulada

David,

I don't understand your statement, "When performing measure calculation these elements will be filtered out". The issue, as I see it, is that one cannot represent these elements using the QDM since there is no Negation Reason. Hence, it's not that the item would be filtered out, it's that it cannot even be represented in the QDM and hence isn't subject to calculation at all. Is this correct?

I understand from your comment that a QRDA item that has negationInd flag set, but lacks a reason, has two properties: (a) it could never match any criteria, so is, for all practical purposes the same as ignoring the item altogether, and (b) ignoring this malformed item isn't a fatal error and raising a fatal error (even though the element has no representation in the QDM) would make a program non-compliant. Is this a correct understanding?

With regard to the "no known" – what does this mean? How would this be represented in the QDM? Is it a separate case from what I'm reporting?

Now even more confused,

• Clark

Clark-

When performing measure calculation these elements will be filtered out since they do not include the required negation reason valueset. So (essentially) they will be ignored.

Their inclusion in the QRDA files exported by Cypress is likely an oversight. We will consider filtering out these entries in the future.

A compliant process should not encounter a fatal error upon load. If the sender wants to state "no known", a negationInd can be used on the corresponding act. The conveyance of "no known" does not need a stated reason.

-Dave Czulada

David,

The problem I have is that the QDM doesn't admit the possibility of being negated and not having
a negation reason (the reason itself is how you indicate the negation). Therefore, I'm asking what
interpretation you expect a compliant processor to have. Should the event be ignored, treated as
if it was never provided? Or is this a fatal error upon load? If the former interpretation, why does
Cypress even include the event record?

Clark

Yan

I able to take a look at this patient and attached the template in question.

The template uses the valueset (2.16.840.1.113883.3.600.1.1525 - Intervention, Order: Above Normal Follow-up)
This template indicates that this Intervention, Order did not take place (using the negation Indicator)
This template does not provide a reason why the Intervention Order did not take place

The record for this patient (in the Cypress database) indicates that the reason this Intervention, Order was not done is code 105480006 (Refusal of treatment by patient) in the valueset (2.16.840.1.113883.3.600.791 - Patient Reason refused)

This Data Criteria is used in the Numerator of CMS69 is “Intervention, Order: Above Normal Follow-up (reason: Overweight)"

The Code 105480006, is not in the Overweight valueset - 2.16.840.1.113883.3.600.2387. Even if the reason was specified in this instance, this negated Intervention Order would not fulfill this logical expression.

So why does Cypress currently exclude the reason code?

When exporting QRDA Cat I documents, Cypress excludes information that is not relevant to the eCQM being testing. Cypress follows a literal interpretation of the following statement in the QRDA Implementation Guide “Test whether the QRDA contains more data than is required by the referenced eMeasures. This type of test might be necessary, for instance, by federal agencies precluded from receiving data above and beyond that which is absolutely required by an eMeasure. It would be possible for a validation report to issue warnings, showing that there are templates (or extensions to open templates) present that aren’t specifically called for by the referenced eMeasures.”

In the case of the attached patient, the fact that an “Intervention, Order: Above Normal Follow-up” was not done is relevant to the measure. The fact that the Intervention, Order was refused by the patient is not relevant to the measure. The reason would have been included if it was Overweight.

-Dave

Hi David, this seems like a Cypress issue, could the Cypress team help look into this? Thanks.

Some eCQMs specifications contain logic that include "not done". In eCQM specification, "not done" is specified using the "negation rationale" QDM attribute and it is also always specified by requiring a valid reason code for why the action did not occur to be provided at the same time. So a sample file that contains negationInd=”true” but without providing a reason with a code from the specified reason value set will not meet the measure criteria.

The HL7 QRDA-I patient data entry template has a May constraint for “Reason” (the entryRelationship to Reason is optional). For example, both “intervention order” and “intervention order not done” data are reported using the same “intervention order” template, and the negationInd is set to true in the case of not done. Because the eCQM logics always require a reason to be provided to make the not done meaningful for quality measurement purpose, if the example is intended to provide data for “"Intervention, Order not done: Patient Reason refused" for "Physical Activity Recommendation", then reason would be expected.

Your ticket is being reviewed by our experts. We will provide you feedback as soon as possible. Thank you for your patience.