[QRDA-294] CONF #s repeated for both the error condition and the warning condition in Schematron Created: 03/25/16 Updated: 12/22/20 Resolved: 07/18/16 |
|
Status: | Resolved |
Project: | QRDA Issue Tracker |
Component/s: | None |
Type: | QRDA-I Standard | Priority: | Minor |
Reporter: | Estelle Noone (Inactive) | Assignee: | Michael Holck |
Resolution: | Done | Votes: | 0 |
Labels: | 2016, QRDA-I |
Attachments: |
![]() |
Impact: | Potential source of confusion to end users (submitters of QRDAs) |
Institution/Name: | DECC/HQR-HITECH |
Contact Name: | Estelle Noone |
Contact Email: | Estelle.Noone@decc.hcqis.org |
Contact Phone: | 410-872-7830 |
Solution: | Update messages and CONF #s to clearly differentiate Errors and Warnings |
Description |
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">] Warning Message : [pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.46-2014-06-09-warnings">] 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"> ] Warning Message : [pattern :: <sch:pattern id="p-urn-hl7ii-2.16.840.1.113883.10.20.22.4.46-2014-06-09-warnings">] 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. |
Comments |
Comment by Michael Holck [ 07/08/16 ] |
For the second condition we will have different assert IDs but the conformance numbers will be the same. To have different conformance numbers would require a request through HL7 to change the way conformances with value sets are written and handled. |
Comment by Michael Holck [ 07/08/16 ] |
For the first condition in the 2017 Schematrons the second test in the warnings section will not exist at all. Since the valueset binding is DYNAMIC there is nothing to test for so only the base condition that there SHALL be one code will be tested. |
Comment by Jae Kim (Inactive) [ 03/25/16 ] |
Your ticket is being reviewed by our experts, we will provide you feedback as soon as possible. Thank you for your patience. |