[QRDA-219] QRDA1 files necessary for eCQM measure calculations can not pass Lantana Schematron validation. Created: 07/10/15 Updated: 12/22/20 Resolved: 08/19/15 |
|
| Status: | Resolved |
| Project: | QRDA Issue Tracker |
| Component/s: | None |
| Type: | QRDA-I Standard | Priority: | Minor |
| Reporter: | David Wade (Inactive) | Assignee: | Yan Heras |
| Resolution: | Delivered | Votes: | 0 |
| Labels: | 2015, Measure, QRDA-I, ValueSet | ||
| Issue Links: |
|
||||||||
| Impact: | Valid QRDA1 files with a Patient Characteristic Expired code (CONF:15142) in it can not be used for eCQM measures calculations (CMS159v3 & CMS160v3). The HL7 IG contradicts the eCQM measures definitions. One of them must change. | ||||||||
| Solution: | Please refer to comments added to this ticket for solution. | ||||||||
| Description |
|
The base HL7 IG and the eCQM measure definitions contradict each other about which code should be provided for the Patient Characteristic Expired Code. If a QRDA1, with a Patient Characteristic Expired Code of '419099009' in it is submitted it will pass Schematron validation but that Code will not satisfy eCQM measures 159v3 and 160v3. If a Patient Characteristic Expired Code is enter that satisfies eCQM measures 159v3 and 160v3 is submitted it will not pass Schematron validation. Here are the details of the problem... HL7 IG requires the "Dead" clinical code '419099009'. 8. SHALL contain exactly one [1..1] value with @xsi:type="CD" (CONF:14857). eCQM measures 159v3 and 160v3 require that the code come from valueSet "2.16.840.1.113883.3.67.1.101.11.721". Here is that definition... "Patient Characteristic Expired: Deceased" using "Deceased Grouping Value Set (2.16.840.1.113883.3.67.1.101.11.721)" The eCQM valueSet has only two values in it, neither of which is "419099009"... 18632008 Patient status determination, deceased (finding) "419099009" is a valid code in the SNOMED-CT codeSystem and the VOC does define a valueSet with that code but currently no one references that valueSet. The base Lantana rule requires the "419099009". Here is that rule... <sch:assert id="a-81-15142" test="cda:value[@xsi:type='CD'][@code='419099009']">This value SHALL contain exactly one [1..1] @code="419099009" Dead (CodeSystem: SNOMED CT 2.16.840.1.113883.6.96 STATIC) (CONF:15142).</sch:assert> The PQRS rule further validates that the correct codeSystem has been provided... <sch:assert id="a-15142" test="not(cda:value[@xsi:type='CD'][@code='419099009']) or (cda:value[@xsi:type='CD'][@code='419099009'][@codeSystem='2.16.840.1.113883.6.96'])">This value SHALL contain exactly one [1..1] @code="419099009" Dead (CodeSystem: SNOMED-CT 2.16.840.1.113883.6.96 STATIC) (CONF:15142).</sch:assert> The R3 HL7 IG to be used for the 2016 submission period has the exact same constraint in it... 8. SHALL contain exactly one [1..1] value with @xsi:type="CD" (CONF:1098-14857). |
| Comments |
| Comment by Yan Heras [ 08/06/15 ] |
|
The HQMF template for Patient Characteristic Expired was remodeled in the QDM-based HQMF Implementation Guide DSTU R1 (and R1.1) that are based on HQMF R2.1. The HQMF R2.1 based template for Patient Characteristic Expired now uses the Assertion style with a fixed SNOMED code of “419099009”, therefore no value set binding is allowed at the eCQM authoring time. When the Measure Authoring Tool (MAT) was updated last year to support the HQMF R2.1, the HQMF R2.1 based Patient Characteristic Expired template was implemented in the MAT. The HQMF representation now matches the QRDA-I representation for Patient Characteristic Expired. The 2015 annual update eCQMs for EH and EP programs published this year, therefore, no longer has this issue. |
| Comment by David Wade (Inactive) [ 07/31/15 ] |
|
In conversations with Yan Heras she let me know this was a known problem that was corrected for the 2016 submission year but still needs to be dealt with for the 2015 submission year. It isn't clear what the best solution might be for 2015 but the most straight-forward path is to obey both the HL7 base IG and the eCQMs. The HL7 IG says that code "419099009" must be provided and the eCQMs (measures 159v3 and 160v3) require that valueSet 2.16.840.1.113883.3.67.1.101.11.721 (Deceased Grouping) be provided and so that is what the submitter should provide. Normally PQRS would validate that '419099009' is in 2.16.840.1.113883.3.67.1.101.11.721 and, of course, that validation would fail (which is the whole problem being discussed). For this to work PQRS is no longer going to validate this entry at all. The Lantana Schematron rules are going to require that the user provide '419099009' and that is the only validation that will be done for this entry. I will note that without valueSet validation the submitter is allowed to put a different valueSet or no valueSet at all and it will pass PQRS validation but will not support measures calculation for measures 159v3 and 160v3. Yan indicated she would post to this ticket to explain how this was resolved for the 2016 submission year. |