IsEndToEnd reported property

[Shane Jarrell]

From QCDR call, I heard that if we submit this then those measures' data will be compared against EHR benchmarks even if we submit as a registry. Is this correct? Can you point to any documentation?

[Shane Jarrell]

found it

[Sarah White]

Great! Thanks for sharing here too, Shane!

Sarah White

Business Analyst

Nava

--
You received this message because you are subscribed to the Google Groups "Developer Group for QPP APIs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qpp-apis+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/qpp-apis.
To view this discussion on the web visit https://groups.google.com/d/msgid/qpp-apis/60ebbadd-64cf-49c3-a231-d7acfe5f9a74%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[SRIDHAR G]

Hi Sarah,

We need clarification on "isEndToEndReported" flag.

Please confirm below statements are true these are based on previous Google group clarifications. 

1. If Submission method is "electronicHealthRecord" and we are reporting all EHR measures then "isEndToEndReported"  flag should be set to "true".
2. If Submission method is "registry" and we are reporting all Registry measures then "isEndToEndReported"  flag should be set to "false" if selected measures do not have any eCQM equivalent.
3. If Submission method is "registry" and we are reporting all Registry measures then "isEndToEndReported"  flag should be set to "true" if all selected measures are eCQM equivalents.
4. The Document attached in this email chain "eCQM EndToEnd FAQ_Final" in Table 1 says, If "isEndToEndReported" flag is set to "YES/true" we will receive 1 End-to-End Bonus point and it uses Registry Benchmark if EHR benchmark does not exists.
5. It also says, If "isEndToEndReported" flag is set to "No/false" we will not receive any End-to-End Bonus point and it uses Registry Benchmark if EHR benchmark does not exists.

Now we are confused, If Submission method is "registry" and we are reporting all Registry measures which does not have eCQM equivalents how can we receive End-to-End Bonus points ? should we set "isEndToEndReported" flag to "true/false"?

Please Clarify 

Thanks,

 

Sridhar Galipalli

 

Product Analyst

Population Health Analytics

 

eClinicalWorks

On Wednesday, February 21, 2018 at 5:47:09 PM UTC-5, Sarah White wrote:

Great! Thanks for sharing here too, Shane!

Sarah White

Business Analyst

Nava

On Wed, Feb 21, 2018 at 8:40 AM, Shane Jarrell <shanele...@gmail.com> wrote:

found it

On Tuesday, February 20, 2018 at 3:29:19 PM UTC-5, Shane Jarrell wrote:

From QCDR call, I heard that if we submit this then those measures' data will be compared against EHR benchmarks even if we submit as a registry. Is this correct? Can you point to any documentation?

--
You received this message because you are subscribed to the Google Groups "Developer Group for QPP APIs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-apis+u...@googlegroups.com.

Visit this group at https://groups.google.com/group/qpp-apis.

[Sarah White]

Hi Sridhar,

Answers in line in blue.

Sarah White

Business Analyst

Nava

On Mon, Dec 10, 2018 at 2:00 PM SRIDHAR G <sree...@gmail.com> wrote:

Hi Sarah,

We need clarification on "isEndToEndReported" flag.

Please confirm below statements are true these are based on previous Google group clarifications.  

1. If Submission method is "electronicHealthRecord" and we are reporting all EHR measures then "isEndToEndReported"  flag should be set to "true".

Yes, however as a QCDR or registry using the API to submit directly your submissionMethod should always be "registry" 

1. If Submission method is "registry" and we are reporting all Registry measures then "isEndToEndReported"  flag should be set to "false" if selected measures do not have any eCQM equivalent.

No, the isEndToEndReported flag should always be used truthfully if you need to report that the measure you are reporting is eligible and has fulfilled the requirements to receive the end to end bonus. If the measure has not, then you report "false". If the measure has and does, then you report "true". 

1. If Submission method is "registry" and we are reporting all Registry measures then "isEndToEndReported"  flag should be set to "true" if all selected measures are eCQM equivalents.

No. In the case where you are reporting directly via the API, your submission method is always "registry". Therefore the distinguishing factor between whether or not you are submitting an eCQM or registry measure is the isEndToEndReported flag. If you are reporting against the eCQM version of a measure, then the end to end flag should be "true". If you are reporting the registry version of a measure THAT DOES NOT HAVE AN ECQM VERSION then that would be reported with the flag as "false". 

You cannot report against a registry measure that also has an eCQM version with isEndToEndReported = true if you want it to still be counted as the registry measure. If there is an eCQM version and the flag is true - then the eCQM measure is what will count. 

1. The Document attached in this email chain "eCQM EndToEnd FAQ_Final" in Table 1 says, If "isEndToEndReported" flag is set to "YES/true" we will receive 1 End-to-End Bonus point and it uses Registry Benchmark if EHR benchmark does not exists.
2. It also says, If "isEndToEndReported" flag is set to "No/false" we will not receive any End-to-End Bonus point and it uses Registry Benchmark if EHR benchmark does not exists.

Now we are confused, If Submission method is "registry" and we are reporting all Registry measures which does not have eCQM equivalents how can we receive End-to-End Bonus points ? should we set "isEndToEndReported" flag to "true/false"?

If there is not an eCQM version of a registry measure, but the measure meets the requirements of to receive the end to end bonus, then you should report isEndToEndReported as true. As bonus will be applied in the case that it is a registry measure and there is NO eCQM measure equivalent.

To view this discussion on the web visit https://groups.google.com/d/msgid/qpp-apis/35576f72-cc00-4812-b5de-80c089a56b9e%40googlegroups.com.

[Melanie Horvath]

Hi Sarah - 

This post clarified most of my questions however I still have a couple questions.  When submitting eCQM measures in their measure set with isEndToEndReported = True, do we use the eMeasureId or the measureId?  For example, measureId "236" has an eCQM equivalent with eMeasureId "CMS165v7",  do we submit: 

{

"id": "12345",

"value": {

"performanceMet": 500,

"performanceNotMet": 30,

"eligiblePopulation": 600,

"isEndToEndReported": true,

"eligiblePopulationException": 1,

"eligiblePopulationExclusion": 0

},

"measureId": "236"

}

OR

{

"id": "12345",

"value": {

"performanceMet": 500,

"performanceNotMet": 30,

"eligiblePopulation": 600,

"isEndToEndReported": true,

"eligiblePopulationException": 1,

"eligiblePopulationExclusion": 0

},

"eMeasureId": "CMS165v7"

}

Additionally, can we submit the same measure in both the eCQM measure set AND registry measure set?  

Thanks

Melanie Horvath

ArborMetrix

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-...@googlegroups.com.

[Allison Johnson]

Hi Melanie,

A couple of things may help clarify your issue:

1. Formatting of your query - based on what you've sent it looks like you are referencing all the fields of the measure which is not correct for this purpose. 

2. Use the MeasureID, not the eMeasureID - more info for this is available in the dev docs, please see below. 

Please reference the Dev Docs that lay out each field including a definition and what type of field it is (e.g. created by API, boolean, etc.) . The right hand column shows if the field is writable or not. In addition, you may find the Swagger documentation helpful as this provides examples and an opportunity to test the submissions to the API. 

Dev Docs link: https://cmsgov.github.io/qpp-submissions-docs/measurements

Swagger Documentation: https://preview.qpp.cms.gov/api/submissions/public/docs/#/

Thanks!

Allison

[Shane Jarrell]

Allison and/or Sarah,

As a 2015 CEHRT EHR that also acts as a QDR, shouldn't we always get the end-to-end bonus for our registry measures per the qualification below? What does
"MIPS approved non-MIPS measures consistent with CMS-vetted protocols" mean? Currently, we can not submit measures 1, 130, 5, 8, 128, 110, 134, 317, 474 with "IsEndToEndReported" : "true" though we believe we should be able to do so.

[Nathanael Vissia]

Hi Sarah, 

Thank you for your helpful response to Sridhar's post. I have a follow-up question to your answer of: "You cannot report against a registry measure that also has an eCQM version with isEndToEndReported = true if you want it to still be counted as the registry measure. If there is an eCQM version and the flag is true - then the eCQM measure is what will count."

To your knowledge, does submitting a measure with the "electronicHealthRecord" submission method mean that an eCQM measure engine must be used to calculate the results? I ask because the MIPS CQM and the eCQM versions of a measure are often different (usually in eligible patient population and in how "not mets" are caclulated). So, if a user reported EndtoEnd=true, but their data was calculated through a MIPS CQM measure engine (and not a eCQM measure engine), can a registry with a MIPS CQM measure engine be able to report numbers with a "electronicHealthRecord" submission method? 

 

Thank you,

--Nathanael

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-...@googlegroups.com.

[Steven Szeliga]

Good Morning,

Utilizing the "electronicHealthRecord" submission method means you are utilizing the eCQM version of the measure specification and collected utilizing end to end (non manually interacted) methodology. If you are submitting the measure and not utilizing the eCQM version of the specification, you can continue to submit the measure but are not eligible to receive a bonus. Please let me know if I can provide any additional information.

[margalitG]

I do apologize, but I still don't understand one particular aspect of this subject. It seems (to me) that there is one rather important use case that has been overlooked.

If the submission method data element is really supposed to denote the collection method, then there should be one more scenario possible for eCQM that do not have an equivalent MIPS specification. If the data for the eCQM is "collected" via an EHR, but the final output is not a QRDA III file, and the practice uploads that output manually to a Registry, the Registry should be able to submit that data with "isEndToEndReporting"=false and submission=collection method = "electronicHealthRecord". Otherwise, and contrary to what I thought I heard during the last QCDR office hours call, there is no way for a Registry to submit eCQM only data obtained with some manual intervention, no matter how minimal, via the APIs.

As you surely know, once "electronicHealthRecord" is selected for the API request, the "isEndToEnd" flips to true even if false is sent in the request. If the API was adjusted to take the value from the request instead of assuming it is true (and no bonus points would be incorrectly awarded), this issue could be resolved rather easily.

I would just add that this is of some importance to less affluent small/medium/rural practices because most EHR vendors charge hefty sums for QRDA exports, and do not charge for reports/dashboards in other formats (Text, Excel, PDF, HTML).

Is this something that can be addressed for this reporting period? If not, I would appreciate any guidance you may have on this subject.....

Thanks,

Margalit

[Kevin Perdue]

I agree with margalitG and second this post.  Furthermore, QRDA file generation cost is not the only significant case - there are MANY certified EHR technologies that cannot even generate valid QRDA3 files.  I've seen so many that are garbage that we cannot import into our QR and would not be able to be converted to QPP JSON format using the converter endpoint or other tools...they have incorrect UUIDs, incorrect "extension" dates in the XML, and on and on.  The Num/Den/Excl/Excep values may be correctly calculated per the eCQM specs so that the performance on the EHR's eCQM dashboard reports that are available to the clinician on-screen, or in a PDF, XLS, CSV, etc. file are accurate, but the CEHRT vendor simply cannot build a valid QRDA3 file which essentially means the clinician or group cannot submit eCQMs whether through a QR or QCDR intermediary, or by Log-in and Upload themselves on the QPP site.  There are many of these invalid QRDA3 files out in the wild coming from "certified" EHRs, so this is a very significant problem.  Clinicians who find this out late in the year or perhaps during the submissions window don't really have the time or option to go back and do Part B Claims or MIPS CQMs collection and reporting.

-Kevin