60 Day Public Comment Response

60-Day Comment Response Document.xlsx

Medicare Part C and Part D Data Validation (42 CFR 422.516(g) and 423.514(g)) (CMS-10305)

60 Day Public Comment Response

OMB: 0938-1115

Document [xlsx]
Download: xlsx | pdf
2020 DV 60-Day Comment Response Document









































Detailed Summary of Comments










Section Comment Commenter's Recommendation CMS Response Revised Documents Revised Burden Estimates
DUR In 2019 IDUR Reporting, PerformRx is going to report out the hard edit rejections data separately from the naïve member claims. In the event a claim has both the hard edit MME rejection and the naïve rejection, how should PerformRx report this data? Would the member be counted towards both the naïve and hard edit, or would one edit take precedence in reporting over the other? Seeking clarification CMS would expect members who received both MME edit and opioid naïve edit rejections on the same claims to be reported in both sets of DUR elements. For example, if a member had a claim that met the conditions for both the hard edit and the opioid naïve edit, then the member would be reported in the appropriate hard edit (Elements H-Q) and opioid naive elements (Elements R-X). No No
DUR This counting criteria does not match up with the counting criteria listed in the 2019 Reporting Requirements Technical Specifications on page 42 subsection 4: "Rejected claims are counted at the unique plan, beneficiary, prescriber, pharmacy, drug (strength and dosage form), quantity, date of service(DOS) and formulary-level cumulative opioid MME POS edit." We recommend aligning the Data Validation. Correction has been made. Yes No
DUR The Technical Specifications Section E. Note 4 states: "Rejected claims are counted at the unique plan, beneficiary, prescriber, pharmacy, drug (strength and dosage form), quantity, date of service (DOS) and formulary-level cumulative opioid MME POS edit." The Data Validation requirements have omitted this requirement (see cell 6D). We recommend that this missing Technical
Specification language be added to the Data Validation
requirement.
Correction has been made. Yes No
CD/RD 2.e; RSC-7: In the 2019 Technical Specifications document under item #13 on page 47, CMS stated the following: “Cumulative opioid MED POS edit coverage determination exceptions should be categorized as Utilization Management (Elements G-J).” However, in the Medicare Part D Plan Reporting Requirements Technical Specifications Document Contract Year 2019 under item #13 on page 47, CMS states the following: “Cumulative opioid MED POS edit coverage determination exceptions should be categorized as Utilization Management (Elements G-J)." If a request is reviewed for a non-formulary drug that is also returning an opioid related safety edit, should that request be classified as a formulary exception or a UM Exception? We are seeking clarification This request should be classied as a UM exception. No No
CD/RD Section 5.b. includes the total counts of exception types, as well as the totals for each decision type (e.g., Data element 1.G-1.R), which if summed up would exceed element 1.A.
United recommends that this section be updated to exclude the exception type totals (e.g., Data elements 1.G, 1.K, 1.O) to align with Section 5a. Correction has been made. Yes No
CD/RD Section 7.f indicates that request for withdrawn or dismissed are included in the total counts for each exception type (e.g., Data elements 1.G, 1.K, 1.O). However, it does not align with Section 2.16 of the Part D Technical Specifications. United requests that Section 7.f be updated to align with Section 2.16 of the Part D Technical Specifications of the standards where stated “withdrawn” (Data Element 1.B) and “dismissed” (Data Element 1.C) are not included in totals and have their own total categories. Correction has been made. Yes No
CD/RD The date a reopening occurs can be the same day the case is dispositioned, and a reopening disposition can occur on the same day as the reopening date of a case. We would recommend that CMS modify the language in
this section as follows, in order to prevent auditor
confusion:
f. Verify that the date of disposition for each reopening
(Data Element 3.B.11) equal to or later than the date
of original disposition (Data Element 3.B.5).
g. Verify that the date of each reopening disposition
(Data Element 3.B.11) equal to or later than the date
that the case was reopened (Data Element 3.B.9).
The language will be modified. Yes No
General File Layouts It would be good to have the Stage table specifications for each area at the same time that we are pulling the summary data that is entered into HPMS. Currently we pull the summary data and then the interview sheet is released with the stage table specifications after the data has been submitted. This adds complexity and time to the overall process. Furthermore, it would be ideal if the stage table specifications matched those of the CDAG/ODAG tables so that we have one process for both timeliness monitoring as well as data validation. This will make the auditing processes for CMS data more streamlined. CMS will consider this request in the future. No No
Grievances The Part D Technical Specifications dated 3/6/2019 do not align with the 2020 Data Validation Standard Appendix B 6.a. In the Data Validation standards document on page 19, 6.a, it states, “Includes all grievances that were completed (i.e. organization has notified member of its decision) during the reporting period, regardless of when the grievance was received”. The revised the Technical Specification released 3/6/2019 document page 37 it states “Grievances are reported based on the grievance decision date”. United seeks clarification from CMS on whether the reporting Technical Specifications will be updated to align with the Data Validation standards.
United recommends CMS to align the CMS Technical Specification to the Data Validation Standards and Part C reporting, as this will allow for aligned reporting.
Correction has been made. Please follow the directions in the Part D TS for Part D plans and follow the directions in the Part C TS for the Part C plans. Yes No
MTM Section 5.r and 5.s state:
r. If a CMR was received (Data Element P = Yes), there is a reported delivery date(s) (Data Element R ≠ missing). s. If a CMR was not received (Data Element P = No), there are no reported delivery date(s) (Data Element R = missing). Records may flag as outliers if Element P = N, and Element R is populated. The DVA Standards document does not account for post-CMR return mail. Technical Specifications: “E. Notes - additional clarifications to a reporting section” states:
15. For reporting annual CMR with written summary in CMS standardized format, the beneficiary must receive the CMR written summary. Therefore, returned mail does not count as a received CMR (element P).
16. If a CMR written summary in CMS standardized format is sent and returned, the date that the written summary was sent should still be reported (element R).
If the CMS standardized format (post-CMR member letter) is returned mail, then plans would report as follows:
Element P = N Element Q = blank Element R = post-CMR member letter delivery date
Therefore, United requests that CMS update the Appendix B: Data Validation Standards to align with the 2019 Part D Technical Specifications to mitigate any confusion by plans. Additional language has been added for clarity. Yes No
OD/RD (Reopenings) United is requesting the Centers for Medicare and Medicaid Services (CMS) introduce five data elements for validation for Part C Re-openings to maintain consistency between file record layout and the reporting elements. Specifically the data elements are Data Element C (Plan ID), Data Element D (Case ID), Data Element H (Was the case processed under the expedited timeframe? (Y/N)), Data Element J. (Status of treating provider (Contract, Non-contract)), and Data Element M (Additional Information - (Optional)). Include the additional data elements for validation. CMS disagrees with the proposal to add the five elements. The file layout for Organization Determination and Reconsideration is very large and the addition of five elements will increase burden. Three of the five proposed elements have not been validated previously and other two elements (C and D) were deleted as part of comprehensive effort to reduce burden for the entire section. No No
OD/RD The new RSC 12. a. Includes all adverse service reconsideration determinations requested by enrollee/representative, or provider on behalf of the enrollee, or non-contract provider (Subsection #4, Data Elements I and J). RSC 6.a. Includes all completed organization determinations (Part C only) for services requested by an enrollee/representative, a provider on behalf of the enrollee, or a non-contract provider, and all organization determinations for claims submitted by enrollee/representative or non-contract provider with a date of member notification of the final decision that occurs during the reporting period, regardless of when the request for organization determination was received. For the two changes below (RSC 12 and RSC 6) -- the sections reference "provider on behalf of the enrollee", does this include contracted and non-contracted providers? A “provider on behalf of the enrollee” includes contract providers. Non-contract providers have their own reporting elements. No No
SNP When to count members as eligible for a reassessment if there is no initial assessment: In the Data Validation standards, RSC-6.f Includes members who dis-enrolled from and re-enrolled into the same plan if an initial HRA or reassessment was not performed within 90 days of reenrollment. The enrollee becomes eligible for a reassessment HRA the day after the 90-day initial period expires. However, in the 2019 Part C Technical Specifications (Exclusion criteria under Element B), new enrollees who miss the deadline to complete an initial HRA and have not completed a re-assessment but do not hit the 365 day deadline in the following year are excluded from the corresponding element. The Data Validation standards count the member in this element on day 91 of enrollment, where as the Technical Specifications gives plans a full 365 days before counting members for whom no initial and no re-assessment was completed.

We urge CMS to take steps to reconcile the conflicting guidance between the Data Validation standards and Part C Technical Specifications to ensure consistent and accurate reporting by plans. Element B ( Number of enrollees eligible for an annual reassessment HRA) states:
An enrollee should be reported under this element when:
• The enrollee has been continuously enrolled for 365 days or more.
• The enrollee is a new enrollee who missed the deadline to complete an initial HRA, but completed a reassessment HRA by the 365-day deadline (even if the enrollee was covered for fewer than 365 days).
• The enrollee is a new enrollee who missed both the deadline to complete an initial HRA and the deadline to complete a reassessment HRA, and is enrolled for all 365 days of the measurement year.
• The enrollee is a new enrollee whose initial HRA was performed in the 90 days prior to the start of the calendar year, and the enrollee remained enrolled until their 365-day reassessment deadline.

The Data Validation RSC-6.f states: The enrollee becomes eligible for a reassessment HRA the day after the 90-day initial period expires. (Data Element B). Please note: If a new enrollee does not receive an initial HRA within 90 days of enrollment that enrollee’s annual HRA is due to be completed within 365 days of enrollment. A new enrollee who receives an HRA within 90 days of enrollment is due to complete a reassessment HRA no more than 365 days after the initial HRA was completed. The measurement year is the same calendar year. The Data Elements 7.b and 7.c relate to Technical Specifications C which refers to the number of initial HRAs performed on new enrollees. Inclusions are as follows:
• Initial HRAs performed on new enrollees (as defined above in data element A) within 90 days before or after the effective date of enrollment.
• If the initial HRA is performed in the 90 days prior to the effective enrollment date, it is reported as an initial HRA in the reporting year in which the effective enrollment date falls.
No No
SNP With respect to Members who dis-enroll and re-enroll, we are requesting clarification on the distinction between the requirements outlined in RSC-7.b and RSC-7.c of the Data Validation standards. The former excludes any HRAs from the previous enrollment for members who have dis-enrolled and re-enrolled (unless there is no break in coverage), whereas the latter includes HRAs performed during previous enrollment provided that the assessments are not more than 365 days old. Accordingly, these two elements seem to conflict. Note that the 2019 Part C Technical Specifications are silent on how to treat members who disenroll and re-enroll within the reporting period, which creates an inherent discrepancy with the Data Validation standards.
We urge CMS to take steps to reconcile the conflicting guidance between the Data Validation standards and Part C Technical Specifications to ensure consistent and accurate reporting by plans. Data Element A is the number of new enrollees due for an Initial Health Risk Assessment (HRA). An HRA that is performed after the first 90days of enrollment could be considered an reassessment if all related factors are true. 1) The enrollee completed their first year of coverage their initial HRA during the final 3 months of the previous year and either a reassessment was completed within 365 days of the initial OR the enrollee was enrolled until the due date for their reassessment and did not complete the reassessment; 2) the enrollee never completed their initial and was enrolled in the plan 365 days (regardless of whether a reassessment was completed), or the enrollee never completed their initial but completed a reassessment on time.

The 2019 Technical Specifications speaks to this scenario beginning on page 24 which reads “ IMPORATANT: A member cannot be counted more than once in the same data element for the same plan. In addition, on page 27 the following paragraph refers to enrollees who disenroll and then re-enroll, either in the same SNP or different one.

“Questions have arisen regarding how to report data elements in this reporting section when enrollees disenroll and then re-enroll, either in the same SNP or a different one (different organization or sponsor) within the measurement year. When a member disenrolls from one SNP and enrolls into another SNP (a different sponsor or organization), the member should be counted as a “new enrollee” for the receiving plan. Enrollees who received an initial HRA, and remain continuously enrolled under a MAO that was part of a consolidation or merger within the same MAO or parent organization will not need to participate in a second initial HRA.”


The highlighted areas above are relevant as it relates to the circumstances presented in scenario 1. If the initial HRA is not complete within the first 90 days of enrollment it must be completed with 365 days of enrollment. Thus the enrollee’s HRA is not counted as an initial but considered an reassessment provided that they are enrolled in the plan for 365 days (regardless of whether a reassessment was completed) or the enrollee never completed their initial but completed a reassessment on time.




No No
File Typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet
File Modified0000-00-00
File Created0000-00-00

© 2024 OMB.report | Privacy Policy