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

CONF #s repeated for both the error condition and the warning condition in Schematron

XMLWordPrintable

    • Icon: QRDA-I Standard QRDA-I Standard
    • Resolution: Done
    • Icon: Minor Minor
    • None
    • Potential source of confusion to end users (submitters of QRDAs)
    • DECC/HQR-HITECH
    • Estelle Noone
    • 410-872-7830
    • Update messages and CONF #s to clearly differentiate Errors and Warnings

      While investigating other peculiarities involving looking at the Schematron file provided to the DECC HQR team by the Lantana team on 9/29/2015 (“Schematron generated from Trifolia on 9/29/2015”), we noticed that there are several CONF numbers that are repeated for both the error condition and the warning condition. It appears that there are two general cases where this happens, both of which involve a compound Schematron test condition. The compound test condition has a SHALL test first to check for the presence of a code or the cardinality of it followed by a second (actual or implied) test with a SHOULD that the code be contained in the specified Value Set. The duplicate CONF #s identified are shown in the attached file (CONF Numbers repeated for Error and Warning Messages).

      Case 1: Same Test Condition, Feedback Message, and CONF # whether an Error or Warning

      There is no difference between the test condition performed, the message generated, and the CONF # issued whether it is an Error or a Warning. If it is Error, it is assumed the first test condition triggered the message. If it is a Warning, then it is assumed that the second test condition triggered the message. The submitter will have to look at their data file submitted to determine what needs to be corrected.

      For Case 1, a suggestion could be to provide different CONF numbers with the same error message, which would look like this:

      Error Message : [ pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.49-2014-06-09-errors">]
      <sch:assert id="a-1098-8714" test="count(cda:code)=1">SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet EncounterTypeCode urn:oid:2.16.840.1.113883.3.88.12.80.32 DYNAMIC (CONF:1098-8714). </sch:assert>

      Warning Message : [pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.46-2014-06-09-warnings">]
      <sch:assert id="a-1098-8714-v-warning" test="count(cda:code)=1">SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet EncounterTypeCode urn:oid:2.16.840.1.113883.3.88.12.80.32 DYNAMIC (e.g., CONF:1098-8715 or another unused CONF #). </sch:assert>

      Although this might not even make sense if the test condition is the same for the Error and the Warning validation and only tests the SHALL portion of the conformance statement.

      Case 2: Different Test Condition, but Same Feedback Message and CONF # whether an Error or Warning

      In this case, there is actually a separate test condition performed in the Schematron rules for the SHALL portion of the compound conformance statement, which if triggered will generate an Error message. A different test is indicated for the Warning portion. But the same message and CONF # is issued whether it was the Error or the Warning condition that triggered the message.

      It might make it more helpful to the submitter to have unique CONF #s and messages to clearly identify which test condition generated the message, in this case.

      For Case 2, a suggestion could be to provide different CONF numbers with different messages for the error and the warning, which would look like this:

      Error Message : [ pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.46-2014-06-09-errors"> ]
      <sch:assert id="a-1098-32427" test="count(cda:code)=1">SHALL contain exactly one [1..1] code (CONF:1098-32427).</sch:assert>

      Warning Message : [pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.46-2014-06-09-warnings">]
      <sch:assert id="a-1098-32427-v-warning" test="count(cda:code[@code=document('voc.xml')/voc:systems/voc:system[@valueSetOid='2.16.840.1.113883.3.88.12.3221.7.2']/voc:code/@value or @nullFlavor])=1">Code SHOULD be selected from ValueSet Problem Type urn:oid:2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2014-09-02 (e.g., CONF:1098-32428 or another unused CONF #).</sch:assert>

      It should be noted though that currently for the CMS HQR EHR receiving system (HQR 10.0), only if the Value Set is fully specified in the supplied vocabulary file (voc.xml), will the actual codes submitted be validated as to belonging in the Value Set.

            michael.holck Michael Holck
            enoone Estelle Noone (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: