Uploaded image for project: 'QRDA Issue Tracker'
  1. QRDA Issue Tracker
  2. QRDA-746

Discrepancy in location of Reason attribute within Device, Order template (2018 Reporting Period)

XMLWordPrintable

    • Icon: QRDA-I Standard QRDA-I Standard
    • Resolution: Answered
    • Icon: Moderate Moderate
    • None
    • Our customers' QRDA I files may not meet the Numerator for the VTE reports when they should.
    • Hide
      There are several "Act" templates (e.g. Device Order Act, Device Recommended Act, etc.) that are used in conjunction with their non-Act child templates (e.g. Device Order, Device Recommended, etc.) only because it allows for negation as described in section 3.4 of vol 1 of the IG. Setting the Act template's @negationInd="true" indicates that the action indicated by the child template was observed specifically not to have occurred. The reason for @negationInd="true" is given, naturally, in the Reason template, and it is within the Act template (not the non-Act child template) because that is where the negation is held. Negation is not allowed in the non-Act child template.

      For your example, when @negationInd="true", then yes, the Reason template should be outside of the Planned Supply/Device Order template, which places it in the Device Order Act template.
      Show
      There are several "Act" templates (e.g. Device Order Act, Device Recommended Act, etc.) that are used in conjunction with their non-Act child templates (e.g. Device Order, Device Recommended, etc.) only because it allows for negation as described in section 3.4 of vol 1 of the IG. Setting the Act template's @negationInd="true" indicates that the action indicated by the child template was observed specifically not to have occurred. The reason for @negationInd="true" is given, naturally, in the Reason template, and it is within the Act template (not the non-Act child template) because that is where the negation is held. Negation is not allowed in the non-Act child template. For your example, when @negationInd="true", then yes, the Reason template should be outside of the Planned Supply/Device Order template, which places it in the Device Order Act template.

      We have noticed a discrepancy between the QRDA specifications/sample file and how the calculation engines (Cypress and QualityNet) process the data in the Device, Order Not Done data element when submitting data for the 2018 reporting period (QRDA STU Release 4).

      The specifications and sample file have the Reason attribute inside the supply template. Here is an excerpt from the QRDA I Sample File for 2018 reporting period found at the eCQI Resource Center:

       

      {{ <!-- QDM Attribute: Reason -->}}
      {{ <entryRelationship typeCode="RSON">}}
      {{ <observation classCode="OBS" moodCode="EVN">}}
      {{ <templateId root="2.16.840.1.113883.10.20.24.3.88" extension="2014-12-01" />}}
      {{ <id root="aa348c15-ce6b-4988-b33b-7ae730c710e2" />}}
      {{ <code code="77301-0" codeSystem="2.16.840.1.113883.6.1"}}
      {{ displayName="Reason care action performed or not" codeSystemName="LOINC" />}}
      {{ <statusCode code="completed" />}}
      {{ <effectiveTime>}}
      {{ <low value="20140105" />}}
      {{ </effectiveTime>}}
      {{ <value xsi:type="CD" code="125629006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"}}
      {{ displayName="Injury of colon" sdtc:valueSet="2.16.840.1.113883.3.464.1003.113.12.1036" />}}
      {{ </observation>}}
      {{ </entryRelationship>}}
      {{ </supply>}}
      {{ </entryRelationship>}}
      {{ </act>}}
      {{ </entry>}}

      Note that the Reason attribute is inside the supply end tag.

      When we were testing our QRDA files, we found that while the file was passing validation and being fully accepted by QualityNet, the Device, Order Not Done data element was not being recognized by the Cypress Validation Utility nor the QualityNet eCQM Submission and Performance Feedback report. For instance, a patient that should be in the VTE-1 Numerator due to a Device, Order Not Done element was evaluating as being in the Denominator only.

      When we moved the Reason attribute outside the Planned Supply template, the Device, Order Not Done element was being found within the Cypress Validation Utility, and the QualityNet eCQM Submission and Performance Feedback report showed the patient in the VTE-1 Numerator. Here is an excerpt from one of our test files:

      {{ </supply>}}
      {{ </entryRelationship>}}
      {{<!-- QDM Attribute: Reason --> }}
      {{<entryRelationship typeCode="RSON"> }}
      {{<!-- Reason (V2) --> }}
      {{<observation classCode="OBS" moodCode="EVN"> }}
      {{<templateId root="2.16.840.1.113883.10.20.24.3.88" extension="2014-12-01"/> }}
      {{<id root="9B1C34CD-6EF1-459D-8861-442FBE532082"/> }}
      {{<code code="77301-0" codeSystem="2.16.840.1.113883.6.1" displayName="Reason care action performed or not" codeSystemName="LOINC"/> }}
      {{<statusCode code="completed"/> }}
      {{<effectiveTime> }}
      {{<low value="20180806101800"/> }}
      {{<high value="20180806101800"/> }}
      {{</effectiveTime> <!Device, Order not done: Medical Reason using Medical Reason SNOMEDCT Value Set> }}
      {{<value xsi:type="CD" code="397745006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMEDCT" displayName="Medical contraindication (finding)" sdtc:valueSet="2.16.840.1.113883.3.117.1.7.1.473"/> }}
      {{</observation> }}
      {{</entryRelationship> }}
      </act>
      </entry>

       

      I have also attached a picture comparing the change we made to the files and test files. While both pass validation, the ChangedFile.xml is evaluated as being in the Numerator and the OriginalFile.xml is evaluated as being in the Denominator.

      Can someone please look into the discrepancy and verify that the Reason template should be outside the Planned Supply template? Thank you very much.

            matthew.tiller Matthew Tiller
            dhall Deb Hall (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: