[CYPRESS-541] Unexpected Supplemental data errors for QRDA-III Stratifications Created: 03/16/15  Updated: 05/06/18  Resolved: 07/24/15

Status: Closed
Project: CYPRESS Issue Tracker
Component/s: None

Type: Question Priority: Major
Reporter: Kelli Klippenstein (Inactive) Assignee: David Czulada
Resolution: Delivered Votes: 0
Labels: None

Attachments: XML File Example QRDA-III File.xml     Microsoft Word Guidance document for Unexpected Supplemental Error.docx    
Previous Issue Type: Logic affecting more than 1 eCQM

 Description   

When validating QRDA-III documents with Cypress 2.6, we're currently getting hundreds of errors that say "Unexpected supplemental data for IPP Race", "Unexpected supplemental data for IPP Sex", etc.

The errors occur when the data for a stratification appears in the QRDA-III document and there are 0 patients that fall into that stratification. For example, if there are no male patients in the IPP, we still include the stratification of "male" but with a count of 0.

Several statements in the QRDA implementation guides explicitly say to include this supplemental data, even if the count is 0 (Examples listed below). This should not be causing an error in Cypress, and currently prevents us from certifying with Cypress 2.6.

In the 2015 Combined IG:
Section 8.3.1. Aggregate Count
The Aggregate Count captures the number of items aggregated. This template is contained in a parent template that describes the item. For CMS EP program reporting, the count must be sent even if the number is zero.

Section 8.3.11 Sex Supplemental Data Element
This observation represents the sex of a person as used for administrative purposes (as opposed to clinical gender) and provides the number of patients in the population that are of that sex. For CMS EP programs, all codes present in the value set must be reported, even if the count is zero. If the eMeasure is episode-based, the count will reflect the patient count rather than the episode count.
Similar sections exist for Payer, Ethnicity, Race, and Reporting Stratum.

In the 2014 IG:
Section 3.11 Sex Supplemental Data Element
This observation represents the sex of a person as used for administrative purposes (as opposed to clinical gender) and provides the number of patients in the population that are of that sex. For CMS EP programs, all codes present in the value set must be reported, even if the count is zero. If the eMeasure is episode-based, the count will reflect the patient count rather than the episode count.
(Same wording)



 Comments   
Comment by David Czulada [ 07/24/15 ]

This has been fixed in Cypress 2.6.1 and Cypress 2.7.0 released yesterday. They can be downloaded by following the links below.

https://github.com/projectcypress/cypress/wiki/Cypress-2.6.1-Install-Instructions
https://github.com/projectcypress/cypress/wiki/Cypress-2.7.0-Install-Instructions

-Dave Czulada

Comment by David Czulada [ 04/27/15 ]

Testing Guidance for Unexpected Supplemental Errors

Comment by Kelli Klippenstein (Inactive) [ 04/24/15 ]

Dave,
You are correct - the magnitude of errors comes from the number of measures in the document being tested. When certifying, we have to produce a document containing data ~30 measures, some of which contain multiple patient populations.

Kelli

Comment by Kelli Klippenstein (Inactive) [ 04/24/15 ]

Attaching an example of a file causing these errors.

Comment by David Czulada [ 04/15/15 ]

Kelli

We actually discussed this topic at the Cypress Tech Talk yesterday. These will be acceptable errors. We are working with ONC to draft official language for the test proctors.

Could you provide one of your sample files. I'm a bit surprised by the order of magnitude of the number of errors. I could expect to see ~10 errors for each population (and i believe CMS is only requiring a subset of the codes for race and ethnicity)...Granted this can add up quickly when reporting on multiple measures.

-Dave

Comment by Kelli Klippenstein (Inactive) [ 04/14/15 ]

Hi Dave - do you have an update for how we should proceed? Currently this is causing over a thousand errors for each QRDA-III test, which makes any legitimate validation for QRDA-III virtually impossible to complete.

Kelli Klippenstein

Comment by David Czulada [ 03/17/15 ]

Kelli

Thanks for brining this to our attention. This looks like an error on our side, we will get back to you with guidance on how to proceed with this issue.

-Dave Czulada

Generated at Fri Apr 19 01:51:26 EDT 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.