Download:
pdf |
pdfResponses to Comments Received
Federal Register Notice on (CMS-10717)
Medicare Part C and Part D Program Audit and Industry-Wide Part C Timeliness Monitoring
Project (TMP) Protocols
CMS received 42 public submissions, which included 662 comments on the December 6, 2019, (CMS10717) Medicare Part C and Part D Program Audit and Industry-Wide Part C Timeliness Monitoring
Project (TMP) Protocols proposed information collection. We then combined the 662 comments into 329
unique comments and provided responses in the document below. Comments are categorized first, by
those that are general in nature, next, those that pertain to more than one program area and, finally, those
that apply to each individual collection tool and program area.
GENERAL COMMENTS
Comment 1: One commenter requested clarification on the full scope of impact within Supporting
Statement A.
Response 1: The total annual burden hours remains unchanged from the 60-day notice (84 FR 66912)
with 25 annual program audit respondents at 17,525 hours; 154 annual timeliness monitoring respondents
at 18,557 hours; and a one-time transition burden with 190 Sponsoring organizations at 64,600 hours and
20 independent validation auditing firms at 2,000 hours.
CMS Action 1: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 2: Several organizations commented on the consolidation of universes. Several commenters
expressed support for the consolidated universes and removal of collection instruments that are no longer
needed (e.g., CPE Self-Assessment questionnaire, CDAG and ODAG supplemental questionnaires, etc.).
Commenters stated that the consolidation will improve the audit data collection process and reduce
administrative burdens for stakeholders. Other commenters opposed the consolidation of audit universes,
stating that it will increase burden. One commenter stated consolidating the universes would reduce the
capacity of CMS to conduct appropriate oversight. One commenter stated that that consolidation will add
complexity because data from multiple system sources, departments, and first tier, downstream, or related
entities (FDRs) is required, presenting a higher risk for universe population errors to occur. The
commenter also stated that ongoing changes to universe fields makes it harder to trend errors as data is
not standardized over time. Another commenter expressed concern with CMS’ proposal to combine
universes stating that doing so will increase the number of lines per universe and the size of the files. The
commenter stated that some files may not be shareable at the Sponsoring organization level due to the
size of the files.
Response 2: We appreciate the commenters’ input. In general, we have proceeded in consolidating the
universe requests as proposed. Clarification at the program level is further summarized in the program
area summaries below.
CMS Action 2: No changes were made to the protocols in response to these comments. No changes were
made to the burden estimate in response to these comments.
Comment 3: Several commenters stated that Sponsoring organizations and their FDRs must make
significant operational and technical changes to their systems and processes (e.g., reprogramming data
extracts, developing new processes for quality assurance, other testing, and compliance reviews) to
implement the proposed protocols and requested that CMS release the finalized protocols as early as
Page 1 of 95
possible. One commenter requested that the changes be finalized prior to July 1, 2020, allowing
Sponsoring organizations and their FDRs enough time to make the necessary changes prior to the 2021
program audits.
Response 3: We agree with the importance of allowing sufficient time for Sponsoring organizations to
implement the changes associated with the collection request prior to the start of the 2021 audit year.
CMS continues to work toward the goal of finalizing this collection request such that stakeholders are
afforded the maximum amount of time possible to update their systems.
CMS Action 3: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 4: Two commenters asked CMS to keep technical specifications the same as past data
collections related to Part C and Part D program audits. For example, these commenters did not see the
value in changing ‘beneficiary’ to ‘enrollee’ and requiring Sponsoring organizations to enter ‘E’ instead
of ‘B.’ A commenter mentioned the resources needed to make changes from year to year can be
eliminated if data collection requests are kept consistent.
Response 4: We thank the commenters for their suggestion but note that these updates were made for the
sake of consistency with the overall program audit process. CMS does not intend to update these terms
annually in an effort to minimize burden.
CMS Action 4: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 5: Commenters asked about the timing for finalizing the collection request and suggested that
CMS offer training. One commenter asked whether CMS could identify the expected date by which these
protocols would be finalized and distributed. The commenter stated that sufficient advanced notice would
be needed to make system/reporting updates. The commenter also requested that CMS summarize the
protocol changes in a CMS conference, prior to implementing, to allow stakeholders the opportunity to
ask questions and receive clarification. One commenter recommended that CMS provide training on key
changes to the protocols and new fields within the data requests to promote uniform understanding and
clarity. The commenter specifically requested training for the new elements in the Special Needs Plans
Care Coordination protocol.
Response 5: We appreciate the commenters’ concerns and agree with the importance of finalizing the
protocols (inclusive of data requests) as far in advance of the start of audit year 2021 as possible. CMS is
actively working toward that goal. We will also take under consideration options for providing
stakeholders opportunities to ask questions and receive clarification.
CMS Action 5: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 6: One commenter identified inconsistency in the way in which CMS refers to organizations
within the protocols. The commenter recommended that CMS consistently use the terms “Sponsoring
organization/Part D plan sponsor” instead of “organization/Part D plan sponsor.”
Response 6: We thank the commenter for bringing this to our attention and agree that consistency in
terminology is important.
Page 2 of 95
CMS Action 6: CMS updated all protocols and data requests to reflect consistent terminology (i.e.,
Sponsoring organizations). No changes were made to the burden estimate in response to this comment.
Comment 7: One commenter referred to the term “may” in the context of CMS conducting integrity tests
to validate the accuracy of all universes, impact analyses, and other related documentation. The
commenter stated that all program area protocols have a compliance standard for integrity testing but,
given the use of the word “may,” asked CMS to clarify whether it may deem integrity testing optional in
some program areas and under what circumstances.
Response 7: CMS will conduct integrity testing of submitted information for all audited program areas.
CMS Action 7: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 8: One commenter stated that CMS performs its program audits in accordance with the
compliance standards outlined in the protocols that are part of this collection request and as described in
the Program Audit Process Overview document that is available on CMS’ website. The commenter asked
if CMS intends to issue subsequent protocol updates using the annual Program Audit Process Overview
document or if such updates will be subject to notice and comment rulemaking.
Response 8: Subsequent changes to the program audit protocols will be subject to notice and comment.
CMS Action 8: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 9: A few commenters recommended that CMS include a unique value per record-line in each
of the record layouts stating that it would make it easier to identify which record within a universe is
selected for a sample or has an error. One commenter noted this will enhance communications between
the Sponsoring organizations and CMS to ensure they are addressing the correct record.
Response 9: CMS does not believe the inclusion of an additional identifier is necessary and believes such
an addition could cause unnecessary programming burden for Sponsoring organizations. There is
currently sufficient case-identifying information provided in the universe submissions.
CMS Action 9: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 10: Two commenters requested that CMS reconsider the proposed layout of the new protocols,
stating the redesigned table format makes it difficult to readily identify the compliance standards being
assessed, the number of samples to be tested, and the types of supporting and supplemental
documentation to be submitted. Another commenter believes the new format reduces clarity of the
CDAG and ODAG timeliness measures in particular and makes it more difficult to determine what will
be measured.
The commenters also stated that by placing this table toward the beginning of each protocol and data
request document, the reader does not learn about the universes nor the audit scope, to which the protocol
refers, until several pages into the documents. The commenters conclude by stating that, because
stakeholders have grown accustom to the format of the protocols found in CMS-10191, CMS should
mirror that format so that stakeholders can more easily identify critical information.
Page 3 of 95
Response 10: We appreciate the challenges of adjusting to a change in the format of the protocols.
However, we maintain that the updated format continues to facilitate the collection of the relevant
information noted by the commenters, including the compliance standards in the Compliance Standard
column, the number of samples being tested in the Method of Evaluation column, and the types of
documentation to be submitted and reviewed in the Data Request column. We believe that the table
format of the protocols provides all required information in a cleaner, more consolidated format.
CMS Action 10: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 11: Two commenters requested confirmation that CMS would continue to allow Sponsoring
organizations three attempts to submit universes, noting that this information is not included in the
protocol.
Response 11: Sponsoring organizations will have a maximum of three attempts to provide complete and
accurate universes, whether these attempts all occur prior to the entrance conference or they include
submissions prior to and after the entrance conference. However, three attempts may not always be
feasible depending on when the data issues are identified, and the potential for impact to the audit
schedule and/or integrity of the audit findings (e.g. Sponsoring organizations will not be allowed to
resubmit universes after auditors have shared timeliness test results with the Sponsoring organization).
When multiple attempts are made, CMS will only use the last universe submitted. If the Sponsoring
organization fails to provide accurate and timely universe submissions twice, CMS will document this as
an observation in the Sponsoring organization’s program audit report. After the third failed attempt, or
when the Sponsoring organization determines after fewer attempts that it is unable to provide an accurate
universe within the timeframe specified during the audit, the Sponsoring organization will be cited an
Invalid Data Submission (IDS) condition relative to each element that cannot be tested, grouped by the
type of case. We appreciate the request for clarification and confirm that Sponsoring organizations will
have a maximum of three attempts to provide complete and accurate universes. Please note, this
information is still available to Sponsoring organizations in the Program Audit Process Overview
document that is available on CMS' website at: https://www.cms.gov/Medicare/Compliance-andAudits/Part-C-and-Part-D-Compliance-and-Audits/ProgramAudits.
CMS Action 11: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 12: One commenter stated that the ‘Calculation of Audit Score’ and ‘Informing Sponsor of
Results’ sections have been removed from the protocols. The commenter requested that CMS provide
information regarding how Sponsoring organizations will receive this information going forward.
Response 12: Because this information does not impact data collection or application of the compliance
standards, we have included it in the Audit Reporting section of the Program Audit Process Overview
document that is available on CMS’ website at: https://www.cms.gov/Medicare/Compliance-andAudits/Part-C-and-Part-D-Compliance-and-Audits/ProgramAudits.
CMS Action 12: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 13: One commenter requested that CMS clarify the timeline of audit activities.
Response 13: The timeline of audit activities is available in the Program Audit Process Overview
document. In addition, a blank Audit Submission Checklist template assigns a submission timeline to key
Page 4 of 95
audit deliverables. These documents are both available on CMS’ website at:
https://www.cms.gov/Medicare/Compliance-and-Audits/Part-C-and-Part-D-Compliance-andAudits/ProgramAudits. In addition, CMS will provide the Sponsoring organization with a populated
Audit Submission Checklist, including specific due dates for data and documentation submission, at the
time CMS issues the audit engagement letter.
CMS Action 13: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 14: One commenter encouraged CMS to align Medicare-Medicaid Plan (MMP) protocols as
closely as possible with those found in this collection request. The commenter also requested that MMP
protocols be made available for comment.
Response 14: Although this comment is beyond the scope of this collection request, CMS will share draft
MMP Program Audit Protocols in a manner similar to the way in which the 2020 MMP Program Audit
Protocols were circulated for comment. Future MMP Program Audit Protocols will align with the Part C
Organization Determinations, Appeals, and Grievances (ODAG) and Special Needs Plan Care
Coordination (SNPCC) Program Audit Protocols found within this collection request, as applicable to
three-way contract requirements.
CMS Action 14: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
TIMELINESS MONITORING PROJECT (TMP)
Comment 15: One commenter asked whether CMS will be conducting Timeliness Monitoring Project
(TMP) activity on Part D in the future.
Response 15: CMS announced in the Calendar Year (CY) 2020 Final Call Letter that it will stop
collection of Part D TMP data after the 2019 data are collected in 2020. Beginning in 2021, the annual
industry-wide timeliness monitoring effort will be limited to Part C data.
CMS Action 15: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 16: One commenter asked whether Medicare-Medicaid Plans (MMPs) would be included in
the Part C TMP.
Response 16: MMPs will continue to be excluded from the industry-wide timeliness monitoring project.
CMS Action 16: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 17: One commenter requested that CMS clarify if the annual Part C TMP will continue to
occur in the first quarter of the calendar year and whether it will continue to involve only a review of the
appeals universes.
Response 17: As in previous years, CMS will issue guidance regarding the timing and types of data
collected for future annual TMP efforts via an HPMS memo.
Page 5 of 95
CMS Action 17: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
MULTIPLE PROGRAM AREAS
Comment 18: A few commenters noted that the record layouts require Sponsoring organizations to enter
the Medicare Beneficiary Identifier (MBI) in the Enrollee ID field. One commenter recommended CMS
permit Sponsoring organizations to include the plan-assigned enrollee identifier in an optional field in
their universe submissions, as doing so would help Sponsoring organizations with their data production
and tracking efforts. Other commenters requested that Sponsoring organizations be permitted to populate
the Enrollee ID field with internal medical record numbers or Cardholder ID. This commenter stated that,
although the transition from Health Insurance Claim Numbers (HICNs) to MBIs is complete, in some
cases populating the MBI in the data universes requires an additional step, as MBIs are often stored
separately within membership-specific systems.
Response 18: Starting January 1, 2020, all Medicare Advantage (MA) and Prescription Drug Plans
(PDPs) were required to use the Medicare Beneficiary Identifier (MBI) for Medicare transactions. Since
the transition period has ended, the MBI must be submitted for CMS Program Audits for consistency in
data collection.
CMS Action 18: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 19: A commenter expressed appreciation for CMS’ attempt to reduce the number of CDAG
and ODAG universes but noted that systems and validation tools are already built for separate standard
and expedited cases and that leaving cases in separate universes makes timeliness testing much easier and
straightforward. Another commenter stated the record layouts will require their organization to merge
data from different sources and multiple business areas.
Response 19: CMS acknowledges that Sponsoring organizations need sufficient lead time to
operationalize changes to program audit data collection and submissions. The combining of universes
does not impact timeliness testing.
CMS Action 19: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 20: Two commenters stated that incorporating dismissed requests in the following ODAG
record layouts, instead of having a record layout specific to dismissed requests, only muddles the data to
be evaluated by CMS: OD, RECON, PYMT_C, and AIP.
Response 20: CMS disagrees with the commenter. CMS has aimed to simplify the ODAG data
collection by aligning it with CDAG record layouts that have consistently collected dismissed requests
within its coverage request universes. CMS believes this change better aligns with its process for
collecting data universes by type of request. As opposed to being a type of request, a dismissal is a
decision not to review a request because it is considered invalid or does not otherwise meet Medicare
Advantage or Part D requirements. CMS has, however, updated the CDAG and ODAG record layouts to
allow Sponsoring organizations to enter ‘None’ for dismissed requests where applicable.
CMS Action 20: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Page 6 of 95
Comment 21: CMS received numerous comments requesting the addition of ‘NA’ and/or ‘None’ as an
option for dismissed requests in the CDAG and ODAG record layouts as described in the CDAG and
ODAG sections below.
Response 21: CMS appreciates the comments. CMS updated the description fields in the CDAG and
ODAG record layouts to include applicable responses for dismissed requests.
CMS Action 21: CMS updated the description fields in the CDAG and ODAG record layouts, where
applicable, to include ‘None’ as an option for dismissed requests.
Comment 22: Three commenters asked if dismissed grievances should be included in the CDAG and
ODAG grievance universes.
Response 22: Dismissed grievances should be excluded from the GRV_C and GRV_D universes. CMS
has added this exclusion to the CDAG and ODAG grievance record layout instructions.
CMS Action 22: CMS added “and dismissed” to the GRV_C and GRV_D record layout exclusion
language. No changes were made to the burden estimate in response to these comments.
Comment 23: Two commenters opposed CMS increasing the sample size from 5 to 10 cases when
conducting CDAG and ODAG universe data integrity testing. A commenter stated that the increased
sample size would increase burden on Sponsoring organizations, taking key employees away from
working with beneficiaries. Another commenter noted they have found validating five samples accurately
predicts data quality during an audit and that ten samples are therefore more samples than necessary to
demonstrate data quality, even with the consolidation of request types within universes. The commenter
also noted this sample size is inconsistent with the SNPCC and FA protocols that propose five samples
for validation.
Response 23: We maintain that a sample size of 10 cases per CDAG and ODAG universe is essential to
conducting universe integrity testing given the variety of request types per CDAG and ODAG universe
submission.
CMS Action 23: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 24: Two commenters noted there was not an impact analysis record layout within the ODAG
and CDAG data request, and one of the commenters asked which record layouts will be used for the
ODAG and CDAG impact analysis requests. Another commenter requested that CMS provide impact
analysis record layouts in the FA, CDAG and ODAG data requests, as included in the SNPCC data
request.
Response 24: CMS is unsure what the commenter is requesting in regard to FA impact analysis record
layouts, as the FA data request that is part of this collection already includes record layouts specific to FA
impact analyses. However, because the information collected as a result of identifying deficiencies in
CDAG and ODAG would mirror the existing universe record layouts, and in the interest of streamlining
our data collection, we decline the commenter’s suggestion to add CDAG and ODAG impact analysis
record layouts to the data request. We clarify that when noncompliance is identified during an audit of
CDAG and ODAG requirements, Sponsoring organizations must submit each requested impact analysis,
comprehensive of all contracts and Plan Benefit Packages (PBP) identified in the audit engagement letter,
in either Microsoft Excel (.xlsx) file format with a header row or Text (.txt) file format without a header
Page 7 of 95
row. The CMS audit team will provide clarifying guidance specific to the noncompliance as needed
during the audit.
CMS Action 24: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 25: One commenter suggested that CMS could further revise the ODAG and CDAG audit
protocols to better focus on the outcomes of the appeals and grievances processes. This commenter stated
that concentrating on individual steps in complex operational processes, instead of on outcomes, results in
continued failures in these areas. The commenter suggested that an outcome focused audit would identify
whether the Sponsoring organization completed a Part C appeal consistent with CMS required
timeframes. The commenter further stated that Sponsoring organizations should be allowed to determine
the step at which the Sponsoring organization’s operational processes failed instead of focusing on
whether the Sponsoring organization mailed or contacted the member correctly, whether time stamps
reflected CMS’ requirements, whether the right language was included in the notification, etc.
Response 25: CMS appreciates the suggestion. At this time, CMS believes it would be more burdensome
for all Sponsoring organizations to implement further protocol changes prior to the start of the 2021 audit
year. We will take it under consideration in a future collection request.
CMS Action 25: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 26: One commenter recommended CMS use either an authorization number or a claim number
in the ODAG PYMT_C record layout, as opposed to giving Sponsoring organizations the option to
choose between the two options, so that Sponsoring organizations could have a clear definition of CMS’
preference.
Response 26: The Authorization or Claim Number field in the applicable CDAG and ODAG record
layouts is primarily used so Sponsoring organizations can quickly identify sample cases within its
system(s) during program audit sample review. CMS has learned that Sponsoring organizations track
coverage requests differently and are allowing flexibility within this field in an effort to minimize burden.
CMS updated the description of the Authorization or Claim Number field description to remove any
ambiguity.
CMS Action 26: CMS updated the Authorization or Claim Number field description in the applicable
CDAG and ODAG record layouts to add “or claim” so that the field description better aligns with the
field name. No changes were made to the burden estimate in response to this comment.
Comment 27: Many commenters noted that Part B drug requests are included in both the CDAG and
ODAG record layouts. The commenters asked if these data requests are duplicative and, if not, requested
clarification on which Part B drug requests should be reported in the CDAG and ODAG universes. Three
commenters asked CMS to clarify if the Part B drugs included in the CDAG record layouts are only those
that underwent a Part B versus Part D review and that all other Part B drug requests would be included in
the ODAG universes. A commenter noted that the CDAG PYMT_D record layout includes Part B drug
requests and asked what the timeliness metric is for Part B drug payment requests. A commenter asked
where grievances for Part B drugs get reported since neither the ODAG nor CDAG protocols specifically
request Part B grievances. The commenter also asked where to report effectuations of overturned
decisions by the IRE, ALJ or MAC for Part B drugs. Another commenter asked if Sponsoring
organizations should now auto-forward all late Part B drug reviews to the IRE and noted that, per the
Page 8 of 95
Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance, late
Part C determinations are denied and not auto-forwarded.
Response 27: Sponsoring organizations must include Part B drug requests based on the way in which the
request was processed. For example, if the Sponsoring organization processed the request as a coverage
determination first, and issued a Part D denial notice, then the case should be included in the CDAG CD
universe. If the Sponsoring organization processed the Part B drug as an organization determination, the
case would be included in the ODAG OD universe. The timeliness tests for payment of Part B drugs are
compliance standards 1.5 and 1.7 in the CDAG protocol and 1.9 and 1.10 in the ODAG protocol. If a
grievance concerning a Part B drug is processed under Part C it would be included in the ODAG GRV_C
universe and if processed under Part D it would be included in the GRV_D universe. Similarly, for
decisions overturned by the IRE, ALJ or MAC, if the overturned decision was a Part C determination, it
would be included in the EFF_C universe and, if it was a Part D determination, it would be included in
the EFF_D universe. While untimely decisions are considered adverse decisions, Sponsoring
organizations are not required to auto-forward untimely Part B drug organization determinations to the
IRE. Sponsoring organizations must notify the enrollee of the adverse decision and offer all applicable
appeal rights.
CMS Action 27: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 28: A few commenters suggested that CMS include a universe field in CDAG and ODAG
record layouts requiring Sponsoring organizations to identify who submitted a request.
Response 28: CMS agrees with the commenters and has added a Who made the request? field to the
following CDAG record layouts: CD; CDER; PYMT_D; and, RD. CMS also added this field to the
ODAG PYMT_C record layout.
CMS Action 28: CMS added a Who made the request? field in the following CDAG record layouts: CD,
CDER, PYMT_D and RD as well as the ODAG PYMT_C record layout. No changes were made to the
burden estimate in response to these comments.
Comment 29: One commenter was concerned about CMS referencing only the Code of Federal
Regulations (CFR) for the timeliness-related CDAG and ODAG compliance standards in the protocols
and asked CMS to include references to the appropriate section of the Parts C & D Enrollee Grievances,
Organization/Coverage Determinations, and Appeals Guidance as well. The commenter also noted that
there was no mention of the related timeliness regulations for the MMP-SARAG timeliness test.
Additionally, this commenter believes the new version of the method of evaluation is not as clear as
previous versions. This commenter believes the new format reduces clarity and makes it more difficult to
determine what will be measured.
Response 29: We appreciate the commenter's suggestion but will not be making the requested update.
CMS does not believe that adding sub-regulatory guidance references to the protocols is necessary since
such information is duplicative of the regulatory requirement citations. We believe the method of
evaluation clearly details the timeliness standards CMS will evaluate during program audits. MMPs are
demonstration programs. Section 3021 of the Affordable Care Act grants the Secretary of Health and
Human Services the authority to waive requirements of Titles XI, Titles XVIII, and sections 1902(a)(1),
1902(a)(13), and 1902(m)(2)(A)(iii) as necessary to conduct these demonstrations. The provision also
exempts the testing, evaluation, and expansion of demonstrations from Chapter 35 of title 44, the
Paperwork Reduction Act (PRA), which requires federal agencies to receive OMB approval for each
collection of information request. Therefore, the MMP-SARAG protocol is not included in this collection
Page 9 of 95
request. However, Sponsoring organizations offering MMPs are required to submit program audit data in
accordance with the MMP-SARAG data request.
CMS Action 29: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimates as a result of this comment.
Comment 30: One commenter asked CMS to update the Time oral response provided to enrollee and
Date written response provided to enrollee fields in the GRV_C record layout. This commenter
suggested CMS use the word “notification” instead of “response” to mirror all of the other ODAG record
layouts.
Response 30: CMS agrees with the commenter. For consistency purposes, CMS made this change in
both the CDAG and ODAG Grievance record layouts, GRV_D and GRV_C respectively.
CMS Action 30: CMS updated the word “response” to “notification” throughout the GRV_D and
GRV_C record layouts. No changes were made to the burden estimate in response to this comment.
Comment 31: CMS received many comments related to the use of ‘NA’, ‘NF’, ‘NE’ and ‘None’ in the
field descriptions within multiple CDAG and ODAG record layouts, as described in the CDAG and
ODAG sections below. The vast majority of commenters requested CMS streamline the use of ‘NA’,
‘NF’, ‘NE’ and ‘None’ across the record layouts.
Response 31: CMS agrees with the commenters’ recommendation for greater consistency. For this
reason, we have simplified the field descriptions within the CDAG and ODAG record layouts by
removing the options to enter ‘NA’, ‘NF’ and ‘NE’ and by allowing Sponsoring organizations to enter
‘None.’
CMS Action 31: CMS updated the description fields, where applicable, in the CDAG and ODAG record
layouts to reflect ‘None’ in place of ‘NA,’ ‘NF,’ and ‘NE.’
Comment 32: Two commenters asked for clarification on how to populate the AOR/Equivalent notice
Receipt Date and AOR/Equivalent notice Receipt Time fields in the CDAG and ODAG universes. One
commenter asked if the Date the request was received field should be populated with the date the AOR
was received, since this is when the request became valid, or the date the request was received without the
AOR. The other commenter asked how to populate the field if the AOR was received prior to the request
date. This commenter noted that prior guidance was to populate the field with the date the request was
received if an AOR was previously on file and recommended that this be consistent across record layouts
by allowing Sponsoring organizations to enter the date the request was received if an AOR was already
on file.
Response 32: The AOR/Equivalent notice Receipt Date and AOR/Equivalent notice Receipt Time fields
should be populated per the record layout field descriptions with the date or time the Appointment of
Representative (AOR) form or equivalent written notice was received by the Sponsoring organization.
Please note that prior guidance was specifically to address limitations within a different collection
request: CMS-10191.
CMS Action 32: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 33: A commenter asked for clarification of the meaning of “equivalent notice.”
Page 10 of 95
Response 33: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
Please see section 20.2 of the Parts C & D Enrollee Grievances, Organization/Coverage Determinations,
and Appeals Guidance for more information on equivalent written notice.
CMS Action 33: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 34: Two commenters requested that CMS use numerical values in the CDAG Issue
Description and Was the coverage determination request denied for lack of medical necessity? field
descriptions for the PYMT_D and RD record layouts. One commenter asked to use numerical values in
the Issue Description and Type of Service field in the ODAG Part B Drugs record layout. A few
commenters requested CMS segment the ODAG field Issue Description and Type of Service in the OD,
RECON and PYMT_C record layouts into distinct fields.
Response 34: CMS appreciates the suggestions. However, CMS declines to take these actions as CMS
has consistently collected data in this format and believes it would be more burdensome for all
Sponsoring organizations to implement this change at this time.
CMS Action 34: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 35: A commenter requested for CMS to add a list of categories to the Category of the issue
description field in the GRV_C and GRV_D record layouts. At a minimum, the commenter
recommended the following categories: Enrollment/Disenrollment, Benefit Package, Access, Marketing,
Customer Service, Organization Determination and Reconsideration Process, Quality of Care, Grievances
Related to CMS Issues, and Other. Another commenter stated the removal of the standardized category
labels may lead to many category labels being used and may bring up questions during an audit.
Response 35: CMS declines to make this change. Sponsoring organizations may populate this field
dependent upon how the request is classified by the organization, as these categories are not defined by
CMS for program audit purposes.
CMS Action 35: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 36: Two commenters asked if pending cases should be included in the CDAG and ODAG
universes. One commenter asked if a case pending receipt of an AOR should be excluded from the
CDAG universe submissions. One commenter asked if CMS continued to expect cases that are both
untimely and pending to be included in the PYMT_C universe submission.
Response 36: Sponsoring organizations may exclude from their CDAG and ODAG universe submissions
requests where a decision has not been issued while the Sponsoring organization awaits the appropriate
representative documentation. Requests that have been dismissed for no AOR should be included in the
applicable CDAG or ODAG universe submission as indicated in the record layout instructions of the
respective data requests. Finally, CMS no longer requires Sponsoring organizations to include requests
that are pending a decision within any of their universe submissions.
CMS Action 36: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Page 11 of 95
Comment 37: A commenter asked whether Sponsoring organizations must include requests from
enrollees whose enrollments are not yet effective when the request was received in their universe
submissions.
Response 37: Sponsoring organizations may exclude requests from members whose coverage is not yet
effective as of the date of the Engagement Letter from their CDAG universe submissions. However,
CMS would expect to see Part D claims rejected at the point of sale due to eligibility issues in the
applicable Part D Formulary and Benefit Administration universes, as those universes should not be
filtered in any way.
CMS Action 38: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 39: Numerous commenters asked CMS to clarify when written notification is considered
delivered by a Sponsoring organization. These commenters referenced the Parts C & D Enrollee
Grievances, Organization/Coverage Determinations, and Appeals Guidance. Two commenters noted that
CMS clarified this definition in section 10.5.3 of the guidance and asked if auditors will rely on this
refined definition when reviewing these fields and assessing overall universe timeliness. A commenter
asked if CMS' interpretation of written notification has changed and whether Sponsoring organizations
should follow the previous definition of “i.e., delivered.” The commenter also asked if the option for
‘NA’ should be applicable to both the Date written notification provided to enrollee and Time written
notification provided to enrollee fields. A commenter suggested that CMS update the field description to
include language from the Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and
Appeals Guidance. Conversely, another commenter recommended that CMS remove language from the
Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance for the
Date written notification provided to enrollee and Date written notification provided to enrollee/provider
field descriptions in the OD and AIP record layouts.
Response 39: For program audit purposes, CMS assesses notification timeliness according to the
regulations located in 42 CFR Parts 422 and 423 Subpart M and would accept the notification date based
on section 10.5.3 of the Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and
Appeals Guidance. As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within
the CDAG and ODAG record layout field descriptions and has added ‘None’ to each applicable field
description. Within the CDAG and ODAG protocols, CMS has removed the phrase “i.e. delivered” from
all applicable field descriptions. CMS removed the following language from the Date written notification
provided to enrollee field description in the OD record layout: “Written notification is considered
provided on the date (and time, if applicable) the Sponsoring organization or delegated entity has
deposited the notice in the courier drop box (e.g., U.S. Postal Service or FedEx bin).” CMS also removed
the following language from the Date written notification provided to enrollee/provider field description
in the AIP record layout, “The term “provided” means when the letter left the DSNP-AIP’s establishment
by US Mail, fax, or electronic communication.”
CMS Action 39: Within the CDAG and ODAG record layouts, CMS removed the phrase “i.e. delivered”
from all applicable field descriptions. CMS also removed the following language from the Date written
notification provided to enrollee field description in the OD record layout, “Written notification is
considered provided on the date (and time, if applicable) the Sponsoring organization or delegated entity
has deposited the notice in the courier drop box (e.g., U.S. Postal Service or FedEx bin).” Finally, CMS
removed the following language from the Date written notification provided to enrollee/provider field
description in the AIP record layout, “The term “provided” means when the letter left the DSNP-AIP’s
establishment by US Mail, fax, or electronic communication.” No changes were made to the burden
estimate in response to these comments.
Page 12 of 95
Comment 40: A commenter suggested that CMS replace the word “complaint” with “grievance” in the
description of the Grievance Description field in the GRV_D record layout.
Response 40: CMS agrees with the commenter’s suggestion and has updated the Grievance Description
field description in both the GRV_D and GRV_C record layouts to read, “Enter the description of the
grievance.”
CMS Action 40: CMS updated the Grievance Description field description in both the GRV_D and
GRV_C record layouts to read, “Enter the description of the grievance.” No changes were made to the
burden estimate in response to this comment.
Comment 41: A commenter asked if ‘NA’ could be entered for standard cases in the Date oral response
provided to enrollee field for the GRV_D record layout. Another commenter recommended consistency
between the Date oral response provided to enrollee and Time oral response provided to enrollee field
descriptions in the ODAG and CDAG record layouts and recommended adding enter ‘NA’ for standard
and dismissed cases as options for the Date oral response provided to enrollee field.
Response 41: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ in the CDAG
and ODAG record layout field descriptions. CMS declines to add ‘NA’ or ‘None’ for standard cases to
the Date oral notification provided to enrollee field because 42 CFR § 422.564(e) and § 423.564(e)
permit Sponsoring organizations to orally respond to oral grievances received unless the enrollee requests
a written response. The field descriptions currently permit Sponsoring organizations to enter ‘None’ if no
oral notification was provided. CMS will not be adding an option for dismissed cases since dismissed
cases are excluded from the GRV_C and GRV_D record layouts.
CMS Action 41: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 42: In regard to CDAG and ODAG record layouts, a commenter asked if Sponsoring
organizations can populate the oral notification date and time fields with good faith attempts or if they
should enter ‘None.’ Another commenter recommended that CMS revise definitions within the CDAG
and ODAG record layout field descriptions to align with the Parts C & D Enrollee Grievances,
Organization Determinations and Appeals Guidance. For the CDAG protocol specifically, two
commenters noted that the Date oral notification provided to enrollee field description for the CD record
layout states, “Enter None if no oral notification was provided.” However, in the RD record layout, this
field reads, “Enter None if no oral notification was attempted or provided.” One of the commenters
recommended that the field description be updated to match the CD record layout, “Enter None if no oral
notification was provided.”
Response 42: CMS does not deviate from the notification timeframes identified in 42 CFR Parts 422 and
423 Subpart M when assessing notification timeliness. Sponsoring organizations are to populate fields as
specified in the applicable field descriptions. Policy questions should be directed to the CMS policy
mailbox https://appeals.lmi.org. Within the CDAG and ODAG record layouts, CMS agrees with the
commenters and has removed the phrase “attempted or” from the description of the following fields: Date
oral notification provided to enrollee, Time oral notification provided to enrollee, Date oral notification
provided to enrollee, and Time oral notification provided to enrollee.
CMS Action 42: Within the CDAG and ODAG record layouts, CMS removed the phrase “attempted or”
from the following field descriptions: Date oral notification provided to enrollee, Time oral notification
Page 13 of 95
provided to enrollee, Date oral notification provided to enrollee, and Time oral notification provided to
enrollee. No changes were made to the burden estimate in response to these comments.
Comment 43: Two commenters asked about the instructions for the GRV_C and GRV_D record layouts
stating, “The date of the Sponsoring organization’s response (Column ID P or R) must fall within the
universe request period.” The commenters asked for clarification if, for example, an oral response falls
within the universe request period, but the written response falls outside of the universe request period.
For ODAG, a commenter recommended that the data be pulled on the Date written response provided to
enrollee field for written grievances and verbal quality of care (QOC) grievances, and for verbal
grievances recommended that that the data be pulled on the Date oral response provided to enrollee field.
Response 43: Per the record layout instructions, Sponsoring organizations should include the request if
either the Date oral notification provided to enrollee or the Date written notification provided to enrollee
falls within the universe request period. CMS believes it will be more burdensome for all Sponsoring
organizations to implement additional changes at this time.
CMS Action 43: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 44: A commenter noted that effectuation timeliness is no longer included as a timeliness
measurement in CDAG and ODAG protocols and recommended the measurement be included in the final
protocols. The commenter also noted that effectuation timeliness is no longer a compliance standard for
IRE auto-forwards and recommended the measurement be included as a requirement.
Response 44: While CMS is no longer measuring effectuation timeliness at the universe level, CMS is
continuing to ensure Sponsoring organizations effectuate cases. In accordance with Universe Integrity
Testing compliance standard, the Method of Evaluation column states, “Prior to field work, CMS will
schedule a webinar with the Sponsoring organization to verify accuracy of data within the universe
submissions, and to confirm effectuation of approved requests for each of the sampled cases.” In
addition, CMS will test all cases requiring auto-forwarding to the IRE, and measure effectuation
timeliness of overturned decision by the IRE.
CMS Action 44: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
PRE-AUDIT ISSUE SUMMARY (PAIS)
Comment 45: One commenter recommended that CMS add language into Supporting Statement A
regarding the Pre-Audit Issue Summary (PAIS).
Response 45: We are unsure what the commenter is requesting but note that the PAIS is included in this
collection request as noted in Supporting Statement A, Section 17.
CMS Action 45: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 46: One commenter requested that CMS clarify whether Sponsoring organizations are required
to provide a PAIS to identify incidents of noncompliance previously reported to their CMS Account
Manager. The commenter also asked whether Sponsoring organizations would still be offered
Page 14 of 95
“downgraded findings” in instances where they can demonstrate that an issue identified on audit was
previously identified by compliance and/or self-reported to CMS.
Response 46: We continue to request that Sponsoring organizations submit the PAIS document that is
included in this collection request. Directions for populating and submitting the PAIS are included in the
document. We further note that, if CMS determines on audit that a disclosed issue was promptly
identified, corrected (or is actively undergoing correction), and the risk to enrollees has been mitigated,
CMS will not apply the Immediate Corrective Action Required (ICAR) condition classification to that
issue.
CMS Action 46: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
ROOT CAUSE ANALYSIS TEMPLATE
Comment 47: One commenter requested that CMS define ways to determine root causes by providing
examples.
Response 47: Because noncompliance is specific to each audited organization, we are unable to define
standard ways for Sponsoring organizations to determine root causes. However, we remind Sponsoring
organizations that they are required to establish and implement procedures and a system for promptly
responding to compliance issues as they are raised, investigating potential compliance problems as
identified in the course of self-evaluations and audits, correcting such problems promptly and thoroughly
to reduce the potential for recurrence, and ensure ongoing compliance with CMS requirements.
CMS Action 47: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
INDEPENDENT VALIDATION AUDIT WORK PLAN
Comment 48: One commenter requested CMS clarify, within the Independent Validation Audit Work
Plan template, that a physician is just one example of a clinical auditor with expertise in processing
organization or coverage request requirements. In addition, this commenter requested CMS also clarify
that a social worker is just one example of a clinical auditor with expertise in evaluating the level of care
and social supports necessary for the provision of long-term services and supports for dual-eligible
populations. This commenter suggested additional examples, such as registered nurses, physician
assistants, or nurse practitioners could be added to the template. Finally, this commenter requested CMS
clarify that staff with operational experience for each of the audited areas would also be an acceptable
option for conducting a validation audit.
Response 48: For IVA purposes, CMS requires IVA vendors to conduct their reviews using the same
level of clinician or reviewer that the Sponsoring organization used (or was required to use) to evaluate
the request or appeal.
CMS Action 48: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
COMPLIANCE PROGRAM EFFECTIVENESS (CPE)
Page 15 of 95
Comment 49: One commenter suggested that CMS rename the “Compliance Program Effectiveness
(CPE) Program Audit Protocol and Data Request” document as the “Parts C and D Compliance Program
Effectiveness (CPE)” document for consistency and clarification of the audit scope.
Response 49: We have updated the name to, “Medicare Part C and Part D Compliance Program
Effectiveness (CPE) Program Audit Protocol and Data Request”.
CMS Action 49: CMS updated the name of the “Compliance Program Effectiveness (CPE) Program
Audit Protocol and Data Request” document to “Medicare Part C and Part D Compliance Program
Effectiveness (CPE) Program Audit Protocol and Data Request.” No changes were made to the burden
estimate in response to this comment.
Comment 50: One commenter asked whether CMS would continue to conduct a portion of the CPE audit
onsite at the Sponsoring organization, and requested that CMS address this question within the protocol.
Response 50: CMS will continue to conduct its CPE audit onsite. References to the onsite audit have
been added to the protocol.
CMS Action 50: CMS updated the CPE protocol to add references to the onsite audit. No changes were
made to the burden estimate in response to this comment.
Comment 51: One commenter expressed concern about CMS guidance requiring Sponsoring
organizations to undergo an annual compliance program effectiveness audit, noting that this timeframe
leaves minimal time to take meaningful action to enhance the compliance program based on the audit
results before the next audit. The commenter referred to the Institute of Internal Auditors' International
Professional Practices Framework Standard 1300 which specifies that an internal audit function undergo
an external review every five years. The commenter concludes by urging CMS to consider ways that will
make the required compliance program effectiveness audit most meaningful to drive Sponsoring
organization improvements.
Response 51: We consider the commenter's request to allow a less frequent compliance program
effectiveness audit to be outside of the scope of PRA and we are not able to revise the CPE audit
requirements found in 42 CFR Parts 422 and 423 Subpart M as part of this PRA process. However, we
did want to point the commenter to the CY2019 Final Call Letter that clarified Sponsoring organizations
are not required to conduct their internal CPE audit in the calendar year following the year a CMS
program audit is initiated. For example, if a CMS program audit begins at any point in 2020, Sponsoring
organizations are not expected to conduct an internal CPE audit until 2022.
CMS Action 51: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 52: One commenter asked when CMS plans to update Chapter 9 of the Prescription Drug
Benefit Manual and Chapter 21 of the Medicare Managed Care Manual.
Response 52: This comment is outside the scope of this PRA package.
CMS Action 52: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 16 of 95
Comment 53: One commenter requested that CMS provide an updated CPE audit checklist that lists all
items that are required to be provided by the Sponsoring organization and their associated due dates for
submission.
Response 53: We believe that the commenter is referring to the Audit Submission Checklist. This
document serves as a comprehensive reference tool to guide Sponsoring organizations on submission
deadlines connected to a program audit, as outlined in the individual protocols. Because this document
does not collect information from the Sponsoring organization undergoing a program audit, we have not
included it in this collection request. However, a blank Audit Submission Checklist template, reflective
of each program area’s data submission requirements will continue to be made available on CMS'
program audit website at: https://www.cms.gov/Medicare/Compliance-and-Audits/Part-C-and-Part-DCompliance-and-Audits/ProgramAudits.html. In addition, CMS will provide the Sponsoring organization
with the Audit Submission Checklist, including due dates for submission, at the time CMS issues the
audit engagement letter.
CMS Action 53: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 54: One commenter requested that CMS identify the due date by which a Sponsoring
organization should provide written compliance policies and procedures per the Audit Field Work Phase Supporting Documentation Submissions section of the CPE Data Request.
Response 54: If not previously submitted with the tracer case summary for CMS review, a Sponsoring
organization is expected to submit supporting documentation within two business days of the request.
Specifically, the Sponsoring organization is expected to present supporting documentation while auditors
evaluate sample cases live with the Sponsoring organization to determine whether the sample cases are
compliant. For cases deemed pended or noncompliant, the Sponsoring organization must take screen
shots or otherwise upload the supporting documentation, as requested, to the HPMS using the designated
naming convention.
CMS Action 54: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 55: One commenter, in referring to the timeframe for submitting supporting documentation,
requested that Sponsoring organizations be given at least five business days to respond to such requests,
indicating that two business days does not allow sufficient time for large, complex organizations that span
multiple geographic areas to produce complete and responsive documentation.
Response 55: CMS appreciates the commenter's concern. While we maintain the due date for submitting
supporting documentation within two business days, auditors have some flexibility to make adjustments
as needed by coordinating with the Sponsoring organization and the CMS auditor-in-charge.
CMS Action 55: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 56: One commenter requested that CMS further define “Corporate Compliance/Medicare
Compliance/FWA Plan” as listed in the Supplemental Documentation Requests section of the CPE Data
Request.
Page 17 of 95
Response 56: Upon consideration of the commenter’s request for CMS to further define the Corporate
Compliance/Medicare Compliance/FWA Plan document, we believe this document is no longer
necessary.
CMS Action 56: CMS removed the reference to the “Corporate Compliance/Medicare Compliance/FWA
Plan (or similar document in effect at any time during the audit review period)” from Supplemental
Documentation Requests section of the CPE Data Request. No changes were made to the burden estimate
in response to this comment.
Comment 57: One commenter requested that CMS clarify whether Sponsoring organizations should
submit Risk Assessments and Compliance Performance Mechanisms as they have in the past.
Response 57: Sponsoring organizations are instructed to submit these documents as part of this collection
request. As noted in the Supplemental Documentation Requests section of the CPE Data Request, these
materials must be submitted within 15 business days of the audit engagement letter date, unless otherwise
specified.
CMS Action 57: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 58: One commenter referred to the Data Request column in the CPE protocol and suggested
that, because CMS will use the same supplemental and supporting documentation to assess multiple
compliance standards, CMS should streamline the request rather than repeat the same information
multiple times throughout the column.
Response 58: We decline the commenter's suggestion. We believe that it is necessary to include this
level of clarification for assessing each compliance standard.
CMS Action 58: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 59: One commenter indicated it would be helpful to know how CMS intends to evaluate the
code of conduct and compliance policies and procedures, as referenced in compliance standard 1.1. The
commenter also asked whether there is a review tool or checklist that Sponsoring organizations can use to
ensure that they meet CMS requirements. The commenter suggested that Sponsoring organizations
should submit a table of contents summary of the compliance policies and procedures rather than the full
documents, then allow auditors to select which policies and procedures would be needed based on the
tracer selections and interview discussions.
Response 59: We intend to first evaluate the content of the Sponsoring organization’s written compliance
policies, procedures, and standards of conduct by gathering information during interviews with the
compliance officer and individuals responsible for SIU/FWA and FDR oversight, as applicable. Should
auditors need to request copies of documentation to assess or support the Sponsoring organization’s
compliance with CMS requirements, the request would be tailored to the specific standard(s) outlined in
the Method of Evaluation column of the protocol. For that reason, we do not believe that it is necessary
for Sponsoring organizations to submit a table of contents summary in advance of the onsite review.
CMS Action 59: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 18 of 95
Comment 60: Commenters requested that CMS further clarify the method of evaluation for compliance
standard 1.2 applicable to Prevention Controls and Activities, related to the sign-in sheet. Commenters
asked from which sign-in sheets the employees would be pulled and what type of information CMS
would expect to see on a sign-in sheet (e.g., name, job title, department, date, etc.). Commenters asked
whether the sign-in sheets were to be pulled from compliance trainings, the audit sign-in sheets for CPE
tracer summary reviews, ODAG webinars, CDAG webinars, or FA webinars, etc. One commenter asked
whether CMS would select samples from sign-in sheets to evaluate if acceptable evidence of compliance
training can be provided.
Response 60: We clarify that CMS is referring to the attendance logs that are collected throughout the
course of the audit, such as pre-audit preparation attendance logs, week one (e.g., CDAG, ODAG, FA,
SNPCC) and week two (as applicable) field work attendance logs, attendance logs from tracer
presentations, etc. The template for attendance logs is available in the Submission Materials section of
HPMS.
CMS Action 60: CMS updated the protocol to clarify “attendance logs” in place of “sign-in sheets” in
response to these comments. No changes were made to the burden estimate in response to these
comments.
Comment 61: One commenter referred to compliance standard 2.1 that states CMS will assess whether
Sponsoring organizations have well-publicized disciplinary standards. The commenter requested that
CMS provide examples of these standards that CMS is expecting from Sponsoring organizations (e.g.,
posters, email communications, Intranet publications, employee handbook, employee newsletters,
Compliance Week activities, policies and procedures, etc.). The commenter also asked if FDRs are
included in this standard.
Response 61: Well-publicized disciplinary standards may be conveyed in various ways including, but not
limited to, posters, standards of conduct, etc. CMS will be looking for Sponsoring organizations to
demonstrate the way in which they make this information available to employees that are located in a
variety of settings. Consistent with 42 CFR § 422.503(b) (4)(vi)(E) and § 423.504(b) (4)(vi)(E),
compliance standard 2.1 includes FDRs.
CMS Action 61: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 62: Commenters requested that CMS clarify compliance standard 4.1 by providing a timeline
for the tracer case summary reviews, including when the samples will be received and the due date by
which the Sponsoring organization will be required to submit the tracer case sample documentation to
CMS. A commenter also asked how far in advance presentations should be submitted to CMS given that
Sponsoring organizations are notified of the tracer selections only two weeks prior to the Entrance
Conference.
Response 62: CMS will provide tracer case sample selections to Sponsoring organizations two weeks
prior to the Entrance Conference, as long as the CPE universes and responsive Supplemental
Documentation Requests are deemed complete and accurate as a result of integrity testing. Sponsoring
organizations must upload the tracer presentations to HPMS prior to the start of the Entrance Conference.
This allows auditors to conduct a desk review of any materials submitted with the tracer case summary
submissions prior to the onsite audit. During the onsite audit, auditors will evaluate sample cases and
conduct interviews. To review tracer samples, auditors evaluate the Sponsoring organization’s
comprehensive approach to addressing an identified issue or noted deficiency. The supplemental
documentation, including the Organizational Structure and Governance presentation, and interview
Page 19 of 95
questions will be discussed during the CPE review. Supporting documentation will also be reviewed
throughout the audit.
CMS Action 62: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 63: One commenter requested that CMS specify whether Sponsoring organizations are
expected to submit tracer supporting documentation at the same time as the submission of tracer
presentations.
Response 63: Sponsoring organizations may submit supporting documentation as part of their tracer
presentation submission or wait to share supporting documentation with auditors until they are onsite
conducting tracer presentation reviews. Should CMS need to collect supporting documentation from a
Sponsoring organization as a result of the tracer presentation review, Sponsoring organizations will have
two business days after the tracer review is concluded to provide the supporting documentation through
HPMS.
CMS Action 63: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 64: One commenter, in referring to the Tracer Case Summary Submissions instructions, stated
that submitting all communications between a Sponsoring organization and its FDRs regarding the
sampled issue would be burdensome. The commenter stated that Sponsoring organizations should be
given discretion in identifying pertinent points of communication that are relevant to the tracer case
summary.
Response 64: Sponsoring organizations have discretion to submit only the pertinent points of
communication that are relevant to the tracer case summary.
CMS Action 64: CMS updated the Tracer Case Summary Submission instructions to clarify that CMS is
only interested in relevant communication. No changes were made to the burden estimate in response to
this comment.
Comment 65: One commenter requested that CMS clarify the meaning of the asterisks next to PBM,
Quality Improvement, if applicable, and FTE within the method of evaluation for compliance standard
4.1.
Response 65: The asterisks were intended to point out to auditors the tracer sample cases that should be
selected for every program audit. However, we understand the commenter’s confusion and have modified
the protocol to provide further clarification. Specifically, we have updated the method of evaluation for
compliance standard 4.1 to clarify the following categories from which auditors will pull tracer case
samples, when available: Pharmacy benefit management; Appeals and grievances, including oversight of
call routing process; FTE performing a delegated function; Quality improvement program, if applicable;
Network management; Enrollment and disenrollment, agent/broker misrepresentation, quality of care,
including issues reported through compliance mechanisms; Customer/member services; Compliance
actions (e.g., Notices of Noncompliance, Warning Letters) relative to the audit review period.
CMS Action 65: CMS removed the asterisks from the method of evaluation and further clarified CMS'
prioritization in selecting tracer samples within compliance standard 4.1. No changes were made to the
burden estimate in response to this comment.
Page 20 of 95
Comment 66: One commenter requested clarification as to "types of oral communication" within the
method of evaluation for compliance standard 4.2.
Response 66: The commenter is referring to the statement in the method of evaluation that reads, “Ask
compliance officer via interview to provide insight on types, including examples, of oral communication.”
We clarify that CMS will assess, during the tracer case summary reviews and the compliance officer
interview, the types of communication the Sponsoring organization uses to ensure effective lines of
communication, and to demonstrate that it has implemented a reporting system as required. CMS
removed the language that was causing confusion as it was duplicative of instructions already provided.
CMS Action 66: CMS removed the following statement from the method of evaluation for compliance
standard 4.2: “Ask compliance officer via interview to provide insight on types, including examples, of
oral communication.” No changes were made to the burden estimate in response to this comment.
Comment 67: One commenter referred to the strong emphasis on interviewing sessions within the
method of evaluation and asked whether additional questions not included in the questionnaires would be
covered and, if so, how Sponsoring organizations should best prepare for these interviews.
Response 67: We clarify that interviewing compliance staff is not new to the program audit process, nor
does CMS intend to emphasize it more than in prior protocols. In conducting the interviews, auditors
may ask clarifying questions to better understand the responses provided in the questionnaires, as the
questionnaires are only intended to streamline, not replace, the interview process.
CMS Action 67: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 68: Several commenters provided input on the shortened, 26-week review period for the
Compliance Oversight Activities (COA) record layout. One commenter requested that CMS confirm the
change in duration of the look-back timeframe as 26 weeks rather than 1 year preceding and including the
date of the audit engagement letter. One commenter expressed concern that Sponsoring organizations
may not have all audits completed during the 26-week timeframe and suggested that CMS extend the
review to one year. The remaining commenters supported the 26-week review period, noting that CMS
may expand it, if needed, to obtain a universe of sufficient size. The commenters in support of the change
stated that the change to a 26-week timeframe will reduce workload for both Sponsoring organizations
and CMS while still yielding sufficient information to audit.
Response 68: CMS clarifies that the 26-week period is intended to reflect activities that are in progress
within this timeframe. CMS does not expect Sponsoring organizations to have completed all audit
activities within the 26-week period.
CMS Action 68: No changes were made to the protocols in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 69: One commenter recommended CMS delete “or delivery” from the Supplemental
Documentation instructions that refer to “… employees who have involvement in the administration or
delivery of Medicare Advantage…” This will allow Sponsoring organizations flexibility in identifying
those employees who play a role in the administration of Part C and D programs and support critical
functions of the organization’s operations. This commenter believes that the word “delivery” implies
health care services whereas this request pertains to employees supporting functions that are integral to
the organization's Medicare lines of business and contractual requirements.
Page 21 of 95
Response 69: We have clarified the commenter's concern by removing this language.
CMS Action 69: CMS removed the following language throughout the protocol: “Listing of employees
who have involvement in the administration or delivery of Medicare Advantage (Part C) and/or
Prescription Drug (Part D) benefits who were hired during the 26-week period preceding and including
the date of the audit engagement letter, including the date of hire.” No changes were made to the burden
estimate in response to this comment.
Comment 70: One commenter suggested that CMS allow ten days, instead of one day, for Sponsoring
organizations to generate the employee listing.
Response 70: We clarify that Sponsoring organizations will no longer be asked to generate a complete
listing of all employees.
CMS Action 70: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 71: Many commenters noted that, with the removal of the ECT record layout, they are not
clear on the way in which the employee listing should be pulled, which data elements to include, and how
the data should be submitted to CMS. Commenters asked whether Sponsoring organizations would be
permitted to submit the information in the format of their choice or if CMS would provide the preferred
template. A couple of commenters expressed support for allowing Sponsoring organizations the
flexibility to generate the list of employees in a way that is consistent with their own systems parameters.
Some commenters asked whether CMS plans to choose samples from the employee listing and noted that,
in former protocols, Sponsoring organizations provided a comprehensive list of all new and existing
employees so that CMS could pick samples from this universe for training records. One commenter
expressed concern that the new approach will increase Sponsoring organization burden and may not yield
20 viable samples for the audit.
One commenter stated that they support focusing samples on recent hires to validate key compliance
program requirements. Other commenters requested that CMS clarify how samples would be split
between new and existing employees, including how many new hire and how many annual training
samples would be reviewed. Commenters also asked if only employees who were newly hired in the 26week period preceding and including the date of the engagement letter should be included in the listing or,
if there are no new hires or just a limited number of new hires within that 26-week period of time, will
additional employees be requested.
Commenters asked whether new hire employees who were also terminated during the 26-day period
should be included; whether re-hires should be treated like new hires; whether to include temporary
employees, contracted employees, part-time employees, full-time employees, interns or members of the
Board of Directors, and whether the submission should include the employees' names, position and hire
dates.
Response 71: CMS will select 20 samples from the week one and week two (as applicable) audit
attendance logs as well as individuals and entities involved in the tracer case summary reviews,
supporting documentation and/or supplemental documentation. CMS will target its sampling based on
the characteristics of the audited organization and audit participants, in line with CMS training
requirements, to include a mix of the compliance officer and organization employees, the Sponsoring
organization's chief executive and other senior administrators, and managers and governing body
members.
Page 22 of 95
CMS Action 71: CMS updated the method of evaluation for compliance standard 1.1 by adding the
following language: “Select targeted samples of 20 audit participants and 2 first tier entities (FTEs) from
attendance logs and impacted individuals and entities from tracers, supporting documentation and/or
supplemental documentation.” We have also updated the method of evaluation for compliance standard
1.2 to clarify the following, “Assess whether compliance training was provided annually to the
compliance officer and organization employees, the Sponsoring organization's chief executive and other
senior administrators, managers and governing body members.” No changes were made to the burden
estimate in response to these comments.
Comment 72: One commenter asked whether the 20 employee samples of audit participants will include
individuals from FDRs if the FDRs are involved in a tracer case summary review, or if only employees of
the Sponsoring organization will be selected.
Response 72: The 20 employee samples will not include audit participants from FDRs.
CMS Action 72: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 73: Several commenters requested that CMS clarify expectations pertaining to employee
training, submission of employee attestations of having received the compliance policies and procedures
and standards of conduct, and any associated documentation. One commenter suggested that employee
attestations would be sufficient and that organizations should not be required to demonstrate that the code
of conduct and compliance policies and procedures were distributed appropriately. Another commenter
asked whether proof of distribution without an attestation would be sufficient. Commenters also asked
whether employees reviewed for training during the live audit walk-throughs and tracer case summary
reviews would be selected from the organization's employee listing as well as other supporting
documentation such as annual training or attestations.
Response 73: We are interested in evidence that employee training has been completed and that the
standards of conduct and policies and procedures have been provided. Acceptable documentation would
not be limited to an attestation of training.
CMS Action 73: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 74: One commenter requested that CMS clarify when and how the OIG/GSA exclusion
screening will be tested. Another commenter requested confirmation that the OIG and GSA exclusion
screenings will not be completed for the 20 samples.
Response 74: CMS is not proposing to evaluate OIG/GSA exclusion lists as part of its Medicare Part C
and Part D program audit.
CMS Action 74: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 75: Several commenters requested clarification pertaining to the method of evaluation for
compliance standard 1.2 that states, “Sample selections will be provided to the Sponsoring organization
one day in advance.” One commenter asked CMS to clarify what this is in advance of, and at what point
the samples will be received within the audit timeline. Some commenters asked how long Sponsoring
organizations would be given to pull together documentation for the samples selected and whether they
Page 23 of 95
would only have one business day to compile the sample files and submit them to CMS. Another
commenter referred to the Audit Field Work Phase of the protocol that indicates that supporting
documentation must be submitted within two business days of the request and stated that CMS should
provide the sample selections mentioned in the method of evaluation, two business days prior to the
review of the sample, similar to the time afforded to the submission of supporting documentation.
Response 75: In response to the comment, we have further clarified that the employee sample selections
will be provided to the Sponsoring organization on the first day of the onsite audit. Evaluation of the
samples will be conducted in accordance with the audit schedule. Documentation review will take place
live during the onsite audit. In the event that CMS observes potential noncompliance during the review,
the Sponsoring organization will be asked to submit follow up documentation via a formal document
request that must be uploaded to HPMS within two business days of the request.
CMS Action 75: CMS updated the method of evaluation for compliance standard 1.2 to read, “Sample
selections will be provided to the Sponsoring organization on the first day of the onsite audit.” No
changes were made to the burden estimate in response to these comments.
Comment 76: One commenter noted that, within the Audit Engagement and Universe Submission Phase
section of the protocol, CMS refers to the submission of universes (plural) though it appears that there is
just one CPE universe. The commenter requested verification that there is just one CPE universe.
Response 76: We appreciate the commenter calling this error to our attention and confirm that there is
one CPE universe.
CMS Action 76: CMS updated the Audit Engagement and Universe Submission Phase section of the
protocol to reflect a single universe. No changes were made to the burden estimate in response to this
comment.
Comment 77: One commenter expressed support for CMS' consolidation of auditing and monitoring
activities into a single record layout.
Response 77: We appreciate the commenter's support and agree that the consolidation streamlines the
data collection effort.
CMS Action 77: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 78: One commenter suggested that CMS separate the fraud, waste, and abuse (FWA) activities
from auditing and monitoring activities captured in the COA record layout to better account for the way
Sponsoring organizations are structured. For example, an organization may have separate units for
Special Investigations versus Compliance.
Response 78: We appreciate that each Sponsoring organization is uniquely structured. However, we
decline the commenter's suggestion to separate FWA activities from routine auditing and monitoring
activities.
CMS Action 78: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 79: One commenter referred to the COA record layout inclusion instructions and requested
confirmation that activities that were started before the audit period and which remain ongoing through
Page 24 of 95
the end of the audit period should be included in its COA universe submission. The commenter stated
that the activity start and end dates will not fall within the universe request period as instructed.
Response 79: We have clarified the inclusion instructions to also reflect activities that are still in progress
but for which the start and completion dates fall outside the universe period.
CMS Action 79: CMS updated the first bullet of the COA record layout inclusion criteria to add the
following phrase at the end of the first bullet, “or if the activity is still in progress but the start and
completion dates fall outside the universe period.” No changes were made to the burden estimate in
response to this comment.
Comment 80: One commenter requested that CMS provide an example of when compliance would have
a reopening within the COA record layout regarding investigating noncompliance versus monitoring.
Response 80: CMS had previously included the term “reopening” to allow flexibility for Sponsoring
organizations in situations where investigations may need to be reopened. However, to improve clarity,
we have removed the reference to the term “reopening.”
CMS Action 80: CMS removed the reference to re-opened oversight activities within the COA record
layout instructions. No changes were made to the burden estimate in response to this comment.
Comment 81: One commenter requested that CMS clarify, within the Component field of the COA
record layout, the acronym FTE (i.e., is it meant to indicate first tier entity or something else).
Response 81: We clarify that FTE represents first tier entity. We have updated the field description
accordingly.
CMS Action 81: CMS updated the description of the Component field of the COA record layout to read,
“Enter the name of the Sponsoring organization’s department, operational area, or first tier entity that is
the focus of the oversight activity.” No changes were made to the burden estimate in response to this
comment.
Comment 82: One commenter requested that CMS clarify within the Component field of the COA record
layout if CMS is expecting Sponsoring organizations to include activities conducted by their FTEs or if
this column is limited to the compliance oversight activities being performed by the Sponsoring
organization. Another commenter asked whether FDRs are to be included in the COA record layout,
stating that it appears that the Component field is limited to the Sponsoring organization and not outside
delegates.
Response 82: Sponsoring organizations are instructed to enter the name of the Sponsoring organization’s
department, operational area, or first tier entity that is the focus of the oversight activity.
CMS Action 82: As mentioned previously, CMS updated the description of the Component field of the
COA record layout to read, “Enter the name of the Sponsoring organization’s department, operational
area, or first tier entity that is the focus of the oversight activity.” No changes were made to the burden
estimate in response to this comment.
Comment 83: Several commenters noted that there are two separate values in the Activity Type field of
the COA record layout to account for investigating noncompliance or investigating FWA but requested
that CMS clarify how Sponsoring organizations should account for simultaneously investigating
Page 25 of 95
noncompliance and FWA. The commenters requested that CMS add a value that would capture both,
such as “investigating both noncompliance and FWA.”
Response 83: We have simplified the Activity Type field of the COA record layout, limiting the values to
three choices. The Compliance or FWA field continues to provide further clarification, allowing the
organization to identify whether the activity is both compliance and FWA.
CMS Action 83: CMS revised the wording in the Activity Type field of the COA record layout to remove
the reference to investigating noncompliance and investigating FWA and simplified the activities into
three categories: auditing, monitoring and investigations. No changes were made to the burden estimate
in response to these comments.
Comment 84: Several commenters requested that CMS further clarify the Activity Frequency field within
the COA record layout. Commenters stated that reporting daily activities individually would be
burdensome due to the volume of activities. Commenters asked whether daily activities should be listed
as a single line item, or if it would be permissible for Sponsoring organizations to roll up the reporting of
daily, weekly or quarterly activities only once, noting the results of the activity in detail within that line of
the universe. Some commenters asked whether activities with multiple daily activities should be listed in
aggregate. One commenter asked whether investigations initiated to address reported incidents must be
included as one entry per investigation. Some commenters recommended that daily activities should be
rolled up into an aggregate time period of one month and included in the universe each time the aggregate
time period into which they were rolled occurred.
Response 84: We have added clarification into the COA record layout instructions to clarify that daily
activities should be rolled up into an aggregate time period of one month and included in the universe
each time the aggregate time period into which they were rolled occurred.
CMS Action 84: CMS added the following inclusion language to the COA record layout: Daily
activities should be rolled up into an aggregate time period of one month and included in the universe
each time the aggregate time period into which they were rolled occurred. No changes were made to the
burden estimate in response to these comments.
Comment 85: One commenter requested CMS to confirm that the choice of “ad hoc” within the Activity
Frequency field of the COA record layout would be appropriate for reflecting investigations initiated as a
result of a reported incident, as these are not routine activities.
Response 85: We confirm that the choice of “ad hoc” would be appropriate in the instance identified by
the commenter.
CMS Action 85: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 86: One commenter requested that CMS expand the character limit in the Activity Frequency
field of the COA record layout to allow additional values such as ‘semi-annual’ and ‘bi-monthly’.
Response 86: We appreciate the commenter's suggestion and have added the suggested values and
increased the character limits.
CMS Action 86: CMS added two additional values to the Activity Frequency field of the COA record
layout: ‘Bi-monthly’ and ‘Semi-annually’ and increased the character limit from 10 to 30. No changes
were made to the burden estimate in response to this comment.
Page 26 of 95
Comment 87: One commenter requested that CMS separate the Activity Description field within the
COA record layout, into two distinct fields: (1) subject of the oversight activity and (2) description of the
oversight activity.
Response 87: We updated the description of the Activity Description field within the COA record layout
by removing reference to the subject of the oversight activity. CMS will only collect the description of
the activity in this field.
CMS Action 87: CMS updated the Activity Description field of the COA record layout to remove the
reference to the subject of the oversight activity. The field description now reads, “Provide a description
of the activity (e.g., operational area, training requirements, timeliness, accuracy of organization
determinations and notifications, messaging errors, contractual agreements, unannounced or onsite audits,
spot checks, compliance monitoring, targeted or stratified sampling, audit protocols, etc.).” No changes
were made to the burden estimate in response to this comment.
Comment 88: One commenter requested that CMS clarify the way in which an activity that is opened,
closed, and then reopened during the audit period, should be recorded within the Activity Start Date field
of the COA record layout. The commenter believes that the reopening should be represented by a second
entry.
Response 88: We believe that the reference to reopened activities created confusion. As a result, we have
removed this reference, as described previously.
CMS Action 88: CMS removed the phrase ‘or reopened’ from the Activity Start Date field description in
the COA record layout. No changes were made to the burden estimate in response to this comment.
Comment 89: One commenter requested that CMS clarify within the Activity Start Date field of the COA
record layout, whether the date should reflect the beginning of the audit/monitoring period or the start of
the monitoring activity itself. The commenter provided the following example: a quarterly monitoring of
the first annual quarter would reflect a review period start date of January 1, but the act of reviewing data
for this period would not begin until after the close of the first quarter. The commenter asked which date
would be most appropriate for this example.
Response 89: In the example provided, the Sponsoring organization would be instructed to provide the
start date of the activity (i.e. reviewing the data).
CMS Action 89: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 90: One commenter requested that CMS define “findings” and “issues identified” within the
Number of Deficiencies field of the COA record layout.
Response 90: The terms “findings” and “issues identified” are terms that some organizations use to
describe deficiencies.
CMS Action 90: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 91: One commenter requested confirmation that deficiencies of the same type, impacting
multiple cases should be counted as one deficiency within the Number of Deficiencies field in the COA
Page 27 of 95
record layout. The commenter provided the following example: a processing delay that caused 100
claims decision letters to be mailed late would be listed in the universe as one deficiency, not 100
deficiencies.
Response 91: In this example, Sponsoring organizations are instructed to identify this as one deficiency.
CMS Action 91: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 92: One commenter stated that the COA record layout does not include a field to collect the
description of deficiencies or a description of the Corrective Action Plan (CAPs). The commenter
suggested that CMS include these data fields in its data collection to assist in targeting specific issues for
sampling purposes.
Response 92: CMS has updated the COA record layout to include a Description of Deficiencies field, but
a field for the descriptions of the CAP is not needed.
CMS Action 92: CMS added a new Description of Deficiencies field to the COA record layout and
relettered the subsequent column IDs accordingly. No changes were made to the burden estimate in
response to this comment.
Comment 93: One commenter requested clarification in populating the Activity Results Shared field of
the COA record layout. Specifically, to the extent that the activity is ongoing, should the Sponsoring
organization respond with TBD rather than yes or no?
Response 93: We do not believe that a TBD option is necessary. If, for example, the ongoing activity is
yet to be shared, Sponsoring organizations are instructed to enter ‘No.’
CMS Action 93: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 94: One commenter suggested that, for consistency in the Activity Type, Compliance or FWA?,
and Activity Frequency fields in the COA record layout, CMS capitalize all valid responses within the
field descriptions.
Response 94: We thank the commenter for calling this inconsistency to our attention. We have updated
the field descriptions within the COA record layout accordingly.
CMS Action 94: CMS updated the descriptions for the Activity Type, Compliance or FWA? and Activity
Frequency fields in the COA record layout to capitalize all valid responses. No changes were made to the
burden estimate in response to this comment.
Comment 95: One commenter referred to the last page of the protocol pertaining to the submission of
root cause analyses. The commenter asked whether root cause submissions would be limited to incidents
identified during the audit (i.e., not for all items included in the COA record layout).
Response 95: CMS does not intend to collect root cause submissions for all items included in the COA
universe submission. Rather, the reference to Root Cause Analysis Submissions is specific to
noncompliance identified by auditors through assessing the compliance standards listed in the program
audit protocol.
Page 28 of 95
CMS Action 95: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 96: One commenter requested that CMS confirm that Revenue by Line of Business is no
longer required as part of the Customized Organizational Structure and Governance PowerPoint
Presentation Template.
Response 96: The commenter is correct in that CMS is not requesting Sponsoring organizations to
provide the Revenue by Line of Business section in its Customized Organizational Structure and
Governance PowerPoint Presentation.
CMS Action 96: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 97: A couple of commenters requested clarification regarding the scope of information that is
being collected in Question 17 of the Compliance Officer Questionnaire.
Response 97: CMS is interested in compliance issues reported in accordance with 42 CFR §
422.503(b)(vi)(D).
CMS Action 97: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 98: Two commenters noted that the Special Investigation Unit (SIU)/Fraud, Waste, and Abuse
(FWA) Prevention and Detection Questionnaire was not included in this collection request and asked
whether it would continue to be collected as a supplemental document. One commenter stated that some
of the questions in the Compliance Officer Questionnaire mirror what was once included in CMS’
SIU/FWA Prevention and Detection Questionnaire that was collected for program audit purposes under
CMS-10191.
Response 98: The SIU/FWA Prevention and Detection Questionnaire is not included in this collection
request and will no longer be collected as a supplemental document.
CMS Action 98: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 99: One commenter expressed support for CMS' removal of the SIU/FWA Prevention and
Detection Questionnaire, stating that it reduces redundancy in data collection.
Response 99: We thank the commenter for their support and agree that removing this questionnaire has
reduced redundancy in data collection.
CMS Action 99: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 100: One commenter expressed appreciation and support for f CMS’ proposed changes that
improve the audit data collection and process. This commenter encouraged CMS to consider additional
ways to streamline the protocols and suggested that CMS remove redundancies in the CPE audit protocol
and Compliance Officer Questionnaire to minimize burden and associated costs. Another commenter
requested that CMS consider additional revisions to the CPE Compliance Officer Questionnaire, the First
Tier, Downstream, and Related Entity Operations Oversight Questionnaire, and the Customized
Page 29 of 95
Organizational Structure and Governance PowerPoint Presentation template to further eliminate
redundancy within collected information.
Response 100: We believe that the revised CPE protocol and the associated questionnaires align but we
do not consider the content within them to be redundant. We welcome specific recommendations for
further streamlining the information collection process.
CMS Action 100: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 101: One commenter requested that CMS provide additional detail on how CMS will test for
call routing, classification, etc., with the removal of the Part C and Part D call log record layouts.
Response 101: CMS will use the Compliance Officer Questionnaire to capture additional information
pertaining to the way in which organizations ensure incoming requests are handled correctly. Auditors
will ask follow up questions during the Compliance Officer interview, as necessary, to determine whether
Sponsoring organizations have measures that prevent, detect, and correct noncompliance related to
defining and processing requests according to program requirements. CMS defers to Sponsoring
organizations to determine which risks they consider when establishing and implementing a system for
routine monitoring and identification of compliance risks and will ask questions during the interview to
get a better understanding of the considerations made by the Sponsoring organization. In addition,
oversight of proper call routing, classification, etc., may be tested through a tracer sample, if selected.
CMS Action 101: CMS added the following question to the Compliance Officer Questionnaire to
facilitate discussion around how Sponsoring organizations oversee the handing of incoming calls and
requests, “17. Since CMS no longer collects call logs for program audit purposes, what has your
organization done to ensure that incoming requests are handled properly?” No changes were made to the
burden estimate in response to this comment.
Comment 102: One commenter referred to Question 5 in the First Tier, Downstream, and Related
Entities Operations Oversight Questionnaire that reads, “Please describe your criteria/process for
determining which delegated entities are identified as FDRs subject to Medicare compliance
requirements.” The commenter suggested that CMS clarify what the criteria is for defining FDRs. The
commenter also expressed concern over mixing the terms FDR and delegated entities, suggesting that
CMS distinguish the characteristics between the two.
Response 102: We have updated the First Tier, Downstream, and Related Entities Operations
Oversight Questionnaire and the Compliance Officer Questionnaire by spelling out first tier,
downstream, and related entities. For consistency, we have also standardized the terms for first tier
entity, downstream entity, and related entity among the two questionnaires.
CMS Action 102: First, CMS replaced the acronym “FDR” with “First Tier, Downstream, and/or Related
Entity” in the First Tier, Downstream, and Related Entities Operations Oversight Questionnaire and the
acronym “FDR” with “First Tier, Downstream, and Related Entity” in the Compliance Officer
Questionnaire. Second, we have removed the following language from the First Tier, Downstream, and
Related Entities Operations Oversight Questionnaire and the Compliance Officer Questionnaire, “FDRs”
refer to the organization’s first tier, downstream, and related entities contracted to perform an
administrative or healthcare service to enrollees on behalf of the organization.” We have also added the
following language to the Compliance Officer Questionnaire to mirror the definition already included in
the First Tier, Downstream, and Related Entities Operations Oversight Questionnaire:
• “First Tier Entity” refers to any party that enters into a written agreement, acceptable to CMS, with
Page 30 of 95
•
•
an organization to provide administrative services or health care services to a Medicare eligible
individual under the Part C and/or Part D program.
“Downstream Entity” refers to any party that enters into a written agreement, acceptable to CMS,
with persons or entities involved with the Medicare Part C and/or Part D benefits below the level of
the arrangement between an organization and a first tier entity. These written agreements continue
down to the level of the ultimate provider of both health and administrative services.
“Related Entity” refers to any entity that is related to an organization by common ownership or
control, and
o performs some of an organization’s management functions under contract or delegation,
o furnishes services to Medicare enrollees under an oral or written agreement, or
o Leases real property or sells materials to the organization at a cost of more than $2,500 during a
contract period.
No changes were made to the burden estimate in response to this comment.
PART D FORMULARY AND BENEFIT ADMINISTRATION (FA)
Comment 103: One commenter expressed support for changes that CMS made to the scope of its FA
universe requests, requiring only two weeks-worth of data for Sponsoring organizations with more than
500,000 enrollees, and in no longer requiring concatenated messaging to be repeated in every position in
the pharmacy message fields. The commenter stated their belief that these changes will result in more
manageable universe files.
Response 103: We thank the commenter for their support of these changes.
CMS Action 103: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 104: One commenter suggested that, to reduce burden associated with compiling and
transmitting the data requested in the audit protocol, CMS remove the PDE record layout from the FA
data request. The commenter asserted that, because Sponsoring organizations regularly supply PDE data,
CMS should already have access to the data that is being requested in the PDE record layout.
Response 104: Due to the variations in timing of data collection, CMS maintains that it needs to collect
PDE data from audited Sponsoring organizations in order to adequately target samples for review.
CMS Action 104: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 105: One commenter recommended that CMS remove the RCT-P record layout and use data
from the RCT-N record layout to test cross-year formulary changes. The commenter stated that the
information in the New enrollee and New Contract Year record layouts is adequate to test rejected claims
related to cross-year formulary changes between the audit year and previous contract year, and that the
RCT-P record layout is duplicative and unnecessary.
Response 105: The RCT-P universe was collected to test mid-year new enrollee transition and to test
enrollees impacted by negative formulary changes in the new plan year. However, we agree we can test
mid-year new enrollee transition using the RCFA universe and, thus, we have removed the RCT-P record
layout from our data request. We will continue to use the NE record layout to test negative cross year
formulary changes that impact transition.
Page 31 of 95
CMS Action 105: CMS removed the RCT-P record layout from the data request and made corresponding
numbering edits to the remaining record layouts. No changes were made to the burden estimate in
response to this comment.
Comment 106: One commenter suggested that CMS standardize the font size within the Method of
Evaluation column of the protocol to align with the remainder of the document.
Response 106: We thank the commenter for suggestion and have standardized the font size throughout
the protocol.
CMS Action 106: CMS standardized the font size throughout the FA protocol. No changes were made to
the burden estimate in response to this comment.
Comment 107: One commenter suggested that CMS update terminology throughout the FA record
layouts to refer to “Sponsoring organization” instead of “organization” and insert the word “number” after
PBP. The commenter also requested that CMS clarify whether ‘NA’ would be considered a valid value in
the Plan Benefit Package (PBP) field of the FA record layouts.
Response 107: We agree that the term “Sponsoring organization” improves clarity and consistency and
have reflected this change throughout the protocol. We decline the suggestion to insert the word
“number” after PBP and clarify that ‘NA’ is not an acceptable value for the Plan Benefit Package (PBP)
field.
CMS Action 107: CMS updated the protocol throughout to use the term “Sponsoring organization.” No
changes were made to the burden estimate in response to this comment.
Comment 108: One commenter referred to two fields that had been removed from the CDAG record
layouts (Enrollment Effective Date and Cardholder ID) and asked whether these fields should also be
removed from the FA record layouts.
Response 108: No. These fields are necessary in the formulary administration universes for purposes of
validating point of sale rejections related to the effective enrollment date.
CMS Action 108: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 109: One commenter stated that, prior to field work, CMS will schedule a webinar with the
Sponsoring organization to verify the accuracy of data within each rejected claims universe submission
for each of the sampled cases. The commenter requested additional detail surrounding the way in which
CMS will conduct pre-validation webinars for FA. The commenter referred to ODAG and CDAG stating
that validation is limited to the date/time fields and asked that CMS follow the same process for FA.
Another commenter stated that, because data used to populate the FA universes can come from both a
Sponsoring organization and a PBM, CMS should clarify the specific fields that will be tested for the FA
universes.
Response 109: CMS will validate all fields submitted in the FA record layouts.
CMS Action 109: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Page 32 of 95
Comment 110: One commenter referred to the method of evaluation for compliance standard 1.1 and the
RCFA record layout, stating their belief that prescriber ID rejections are out of scope for formulary
administration.
Response 110: We disagree with the commenter. Claims rejecting for inappropriate identification of an
eligible Part D prescriber prevent enrollees from accessing their formulary benefit.
CMS Action 110: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 111: One commenter referred to the dates cited parenthetically in the Scope of the Universe
Request in the NE record layout and suggested that CMS update the sample dates to reflect the year in
which the approved protocols will become effective.
Response 111: To ensure applicability for all years in which the protocols will be effective, we have
removed the current year date examples throughout the FA protocol.
CMS Action 111: CMS removed references to the year 2018 from the Scope of Universe Request
instructions. No changes were made to the burden estimate in response to this comment.
Comment 112: One commenter indicated that several fields including Enrollee ID, Enrollment Effective
Date, Effective Disenrollment Date, Contract ID, Plan Benefit Package (PBP), Date of Rejection, Reject
Reason Code, and Pharmacy Message are typically not submitted by the pharmacy. The commenter
questioned whether CMS assumed that these fields are always submitted by the pharmacy.
Response 112: CMS appreciates the commenter's input. For the fields not populated by the pharmacy,
Sponsoring organizations are instructed to populate the fields as instructed in the field descriptions in the
record layouts.
CMS Action 112: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 113: One commenter referred to the Enrollment Effective Date and Effective Disenrollment
Date fields within the record layouts and asked whether CMS is seeking the date of the enrollee’s most
current PBP or the original effective date if the enrollee has switched plans.
Response 113: Sponsoring organizations are instructed to enter the effective date of enrollment for the
enrollee at the PBP level and enter the enrollment date relevant to the contract and plan ID of the enrollee
at the time of the claim.
CMS Action 113: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 114: One commenter requested clarification in populating the NDC field in the FA record
layouts. First, the commenter asked how to reflect instances when a claim is submitted for a non-Part D
multi-ingredient compound and the submitted NDC is less than or greater than 11 characters. Second, the
commenter referred to instructions for not leaving blank fields in the record layout, but to alter the
submitted NDC into an invalid non-submitted value. The commenter stated their belief that this approach
would be the same as reporting a blank value. Third, the commenter expressed concern about the
potential for Sponsoring organizations to make a mistake in assessing a non-Part D drug and changing a
valid NDC into all zeros.
Page 33 of 95
Response 114: The full listing of instructions in the NDC field description pertain to multi-ingredient
compounds claims (i.e., not just the final bullet). However, to improve clarity and eliminate any
perceived contradiction, we removed the following instruction from NDC field description, “When
compound claims do not include any Part D medication products, populate the field with “00000000000”
consistent with the NDC 11 format.” Sponsoring organizations are instructed to follow the remaining
instructions in the NDC field description.
CMS Action 114: CMS removed the following instruction from the NDC field description, “When
compound claims do not include any Part D drug products, populate the field with “00000000000”
consistent with the NDC 11 format.” In addition, we simplified instructions pertaining to compounds
within the NDC field description to read, “For multi-ingredient compound claims populate the field as
submitted on the associated PDE.” No changes were made to the burden estimate in response to this
comment.
Comment 115: Two commenters requested that CMS clarify whether ‘UNK’ would be considered a
valid response for the Patient Residence and Pharmacy Service Type fields in instances where these fields
are left blank on the claim submitted by the pharmacy.
Response 115: As mentioned previously, we have removed the RCT-P record layout from the data
request. However, for the RCFA and RCT record layouts, Sponsoring organizations are instructed to
submit values as submitted by the pharmacy. Blank is an acceptable value.
CMS Action 115: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 116: One commenter stated that record layouts RCFA, RCT-N and RCT-P are claims
universes and asked why CMS does not use the industry standard Claim ID in collecting this data.
Response 116: The Claim ID is an internal value to Sponsoring organizations that is not used by CMS for
program audit purposes.
CMS Action 116: No changes were made to the protocols in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 117: One commenter stated that more specificity should be included with the IAS record
layout. The commenter stated that this record layout appears to begin with “Actions Taken to Resolve
System/Operational Issues.” The commenter recommended adding Date Issue Identified; Brief
Description of Issue; and Condition fields as well as Root Cause Analysis fields so that it will be easier to
assess impact analysis completeness without the need to refer to a separate document.
Response 117: We appreciate the commenter’s input and have clarified the IAS record layout by adding
two fields to capture the methodology for identifying the impact of the noncompliance and the list of
medications affected.
CMS Action 117: CMS added the following new fields to the IAS record layout: Methodology for
Identifying Noncompliance Impact and List of Medications Affected. We have also relettered the
remaining fields accordingly to align with these additions. No changes were made to the burden estimate
in response to this comment.
Page 34 of 95
Comment 118: One commenter referred to the Is the enrollee currently enrolled? field in the ENR-IA
record layout asking for clarification as to whether this field should be populated based on the date the
impact analysis is completed or as of the date of the claim.
Response 118: Sponsoring organizations are instructed to populate the ENR-IA record layout Is the
enrollee currently enrolled? field as of the date of the claim.
CMS Action 118: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 119: A couple of commenters referred to the ENR-IA record layout Process Date of
Subsequent Paid Claim field description, “Enter the date of the paid claim subsequent to the rejected
claim having the same RxCUI.” The commenter stated that GPI 14 is used to determine the subsequent
paid claim because many NDCs do not have an RxCUI. The commenter asked CMS to confirm that
using GPI is an acceptable approach.
Response 119: We confirm that it would be appropriate to use other identifiers such as Generic Product
Identifier (GPI), Generic Code Number (GCN), and Hierarchical ingredient code list (HICL); therefore,
we have edited the Process Date of Subsequent Paid Claim field description to allow for other identifiers.
CMS Action 119: CMS updated the Process Date of Subsequent Paid Claim field description in the
ENR-IA record layout to read, “Enter the date of the paid claim subsequent to the rejected claim for the
medication utilizing the same RXCUI, GPI, GCN, or HICL. Submit in CCYY/MM/DD format (e.g.,
2020/01/01). Enter NA if never received.” No changes were made to the burden estimate in response to
these comments.
Comment 120: One commenter suggested that CMS remove the Number of Hours Enrollee Went
Without Medication (Target or Related) field from the ENR-IA record layout, asserting that the field does
not represent a true enrollee medication access impact because most medications are processed
electronically by the pharmacies or may include a batch that is processed at night when enrollees are not
at the pharmacy.
Response 120: We thank the commenter for their input. To reduce inconsistency in data collection, CMS
will no longer collect this data element.
CMS Action 120: CMS removed the Number of Hours Enrollee Went Without Medication (Target or
Related) field from the ENR-IA record layout and relettered the subsequent column IDs accordingly. No
changes were made to the burden estimate in response to this comment.
Comment 121: One commenter asked CMS to clarify whether the IAS and ENR-IA record layouts
should be presented within the same workbook or separately.
Response 121: Sponsoring organizations will be instructed to submit the responsive data within the same
workbook.
CMS Action 121: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 122: One commenter suggested that CMS rename the IAS and ENR-IA record layouts as FAIA-SUM and FA-IA-ENR. The commenter stated that naming the impact analyses using the word
“Table” has the potential to cause confusion.
Page 35 of 95
Response 122: We decline the commenter's suggestion and will continue using the current naming
conventions.
CMS Action 122: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 123: One commenter referred to the IAS record layout instructions to "include all medications
and enrollees impacted by the issue of noncompliance." The commenter requested that CMS clarify the
inclusion of medications as there are no fields for medication in this record layout. The commenter stated
that the ENR-IA record layout seems to be the more appropriate record layout to have such inclusion
criteria.
Response 123: We thank the commenter for their input and have updated the inclusion instructions for
both the IAS and ENR-IA record layouts. We have also added two new columns to IAS record layout to
collect the Sponsoring organizations’ methodology for identifying the impact of the noncompliance and
the list of medications affected.
CMS Action 123: CMS updated the IAS record layout inclusion instructions to read: “Include all
medications impacted by the issue, including those that may not have an associated rejected claim.” We
also added two new fields to the IAS record layout: Methodology for Identifying Impact of
Noncompliance and List of Medications Affected and made corresponding edits to reletter the remaining
fields in the record layout. Finally, we updated the ENR-IA record layout inclusion instructions to read:
“Include the following data for impacted enrollees: (1) Rejected claims affected by the issue of
noncompliance; (2) Inaccurate records (i.e. authorization, enrollment records) that may not be associated
with a rejected claim. In this scenario, Sponsoring organizations should only complete the following
fields: Enrollee ID, Contract ID, Plan Benefit Package (PBP), Enrollment Effective Date, Is enrollee
currently enrolled and Drug Name and Strength (if applicable) ….” No changes were made to the burden
estimate in response to this comment.
Comment 124: One commenter referred to the Scope of Impact Analysis Request stating that it is not
clear how there could be issues that only impact medications. The commenter further stated their belief
that, if there is no impact to enrollees, no impact can be reported.
Response 124: An impact analysis can capture impacted medications that have not yet had a direct
impact on enrollees but that do have potential for enrollee impact if the issue remains uncorrected.
CMS Action 124: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 125: One commenter requested that CMS make the FA Supplemental Questionnaire available
in Word or PDF fillable format with response value drop-down choices where appropriate. The
commenter also requested that CMS include the questionnaire as part of the FA Protocol and Data
Request document as it would be helpful to Sponsoring organizations when preparing for the FA program
audit and in generating the NE universe.
Response 125: Documents included in this collection request are provided strictly in PDF format during
the comment period. However, finalized documents will be posted to the HPMS in a fillable format. We
decline the commenter’s suggestion to include the FA Supplemental Questionnaire as a part of the FA
Protocol and Data Request document at this time.
Page 36 of 95
CMS Action 125: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
PART D COVERAGE DETERMINATIONS, APPEALS AND GRIEVANCES (CDAG)
Comment 126: Two commenters asked if the adjudication timeframe for a request begins on the date
and time good cause is established.
Response 126: Please see section 50.3 of the Parts C & D Enrollee Grievances, Organization/Coverage
Determinations, and Appeals Guidance and direct policy questions to the CMS policy mailbox
https://appeals.lmi.org.
CMS Action 126: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 127: A commenter stated they had concern about including the NDC data element as coverage
determination or appeal requests are typically not made at an NDC level but rather at the drug name level.
In addition, the commenter noted that, when a coverage determination or appeal request is approved, it is
not approved at an NDC level as that would be inappropriately restrictive.
Response 127: CMS is not sure why the commenter believes that providing an NDC is a new data
element for CDAG. The CDAG NDC field has been retained from prior program audit protocols and the
field description was standardized for consistency with the NDC field description within the Part D
Formulary and Benefit Administration protocol.
CMS Action 127: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 128: A commenter referenced compliance standard 1.6 in the CDAG protocol and asked if the
30-60 day timeframe applies to the alternate second notice. The commenter stated it is quite common to
send an alternate second notice prior to 30 days post-initial notice.
Response 128: The alternate second notice is required to be sent within the 30-60 day timeframe. Please
see 42 CFR § 423.153(f)(8).
CMS Action 128: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 129: A commenter suggested that CMS revise two bullets within the Audit Field Work Phase Supporting Documentation Submissions section of the CDAG Data Request to remove references to
withdrawn cases.
Response 129: CMS agrees with the commenter's suggestion and has revised the two bullets as proposed.
CMS Action 129: For the first update, CMS revised the bullet language from “Copies of any case notes
as to why the case was withdrawn or dismissed” to “Copies of any case notes as to why the case was
dismissed.” For the second update, CMS revised the bullet language from “Any notification regarding
the dismissal or withdrawal” to “Any notification regarding the dismissal.” No changes were made to the
burden estimate in response to this comment.
Page 37 of 95
Comment 130: A commenter noted in the Universe Submissions section of the CDAG protocol that
CMS indicated when populating the individual universe record layouts characters are required in all
requested fields, unless otherwise specified. The commenter noted that the NDC field states in the "Field
Type” column ‘CHAR Always Required’; however, the description for the NDC field specifies when
“less than 11 characters or a blank field is submitted by the pharmacy or delegate, populate the field as
submitted.” The commenter recommend that CMS explicitly clarify the expectations for populating the
NDC field.
Response 130: As the commenter noted, the NDC field description permits the field to be populated as
blank when a blank field is submitted by the pharmacy or delegate.
CMS Action 130: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 131: A commenter asked when a quantity limit would be considered a coverage determination
versus an exception.
Response 131: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 131: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 132: For compliance standard 2.3, a commenter noted that, in selecting 30 denial cases, the
protected class drug denials are targeted. The commenter recommended that a mixture of protected class
and non-protected class drugs be selected and stated inappropriate non-protected class denials can result
in significant enrollee harm.
Response 132: CMS understands the commenter’s concern but would like to clarify that the samples will
most likely be a mixture of protected class and non-protected class drug denials. The method of
evaluation does not state to exclude non-protected class drug denials; rather, it states to target protected
class drug denial cases.
CMS Action 132: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 133: A commenter expressed support and appreciation for CMS' updates to the Scope of
Universe Request for Sponsoring organizations with more than 500,000 enrollees and noted the change
results in more manageable universe files.
Response 133: CMS appreciates the commenter's positive feedback and support.
CMS Action 133: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 134: A commenter recommended an update to compliance standards 4.1, 4.2, and 4.3 to
change the language “a copy of the notice” to “written notification/information.” The commenter stated
this would take into account Sponsoring organizations that provide prescribers written statements/notices,
which are intended to memorialize prescriber agreement, notice, confirmation and outcome of the case
management review. The commenter also stated that Sponsoring organizations may choose to send
prescriber-specific communications versus providing the prescriber a copy of the beneficiary notice.
Page 38 of 95
Response 134: The applicable regulations require “reasonable efforts” to provide a “copy of the notice.”
CMS has updated compliance standards 4.1, 4.2, and 4.3 in the CDAG protocol to align with the
regulation to read, “Also review case file documentation to ensure Sponsoring organization made
reasonable efforts to provide the beneficiary's prescriber(s) of frequently abused drugs with a copy of the
notice.” For program audit purposes, CMS would accept “reasonable efforts” consistent with CMS drug
management program guidance. For questions about Drug Management Program (DMP) policy, please
email [email protected].
CMS Action 134: CMS updated compliance standards 4.1, 4.2, and 4.3 to read, “Also review case file
documentation to ensure Sponsoring organization made reasonable efforts to provide the beneficiary's
prescriber(s) of frequently abused drugs with a copy of the notice.” No changes were made to the burden
estimate in response to this comment.
Comment 135: A commenter asked how to populate the Date the request was upgraded to expedited
field if the request was received as standard and an upgrade to process the request under the expedited
timeframe was never requested. The commenter recommended using ‘NA’ for this scenario.
Response 135: CMS agrees the field description can be clarified for this scenario and believes the same
clarification applies to the Time the request was upgraded to expedited field description. CMS has
updated these field descriptions in CDAG record layouts CD, CDER and RD. As previously mentioned,
CMS has updated all instances of ‘NA’ to ‘None’ within the field descriptions. The updated language for
these field descriptions reads, “Enter None if the initial request was made under the expedited timeframe,
if the Sponsoring organization chose not to expedite the request, or if the request was received and
processed under the standard timeframe.”
CMS Action 135: CMS updated the Date the request was upgraded to expedited and Time the request
was upgraded to expedited field descriptions in record layouts CD, CDER and RD to read, “Enter None if
the initial request was made under the expedited timeframe, if the Sponsoring organization chose not to
expedite the request, or if the request was received and processed under the standard timeframe.” No
changes were made to the burden estimate in response to this comment.
Comment 136: A commenter requested that CMS revise the Expiration date of the approval field
description to read, “List expiration date of the exception approval” instead of “Enter the expiration date
of the exception approval.”
Response 136: CMS declines to make this revision in the interest of consistency within the record layouts
as all other field descriptions use the phrase “Enter.”
CMS Action 136: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 137: One commenter stated that the requirement to provide an explanation of why the initial
coverage determination was denied was new for the CDAG Issue Description field and stated that
Sponsoring organizations will have to develop a process for tracking the information. The commenter
also stated that, because of the timing of 2021 audits, this would likely be problematic.
Response 137: We are not sure why the commenter believes that this is a new requirement. The CDAG
Issue Description field description has not been changed and previously read, “Provide a description of
the issue and, for denials, an explanation of why the decision was denied.”
Page 39 of 95
CMS Action 137: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 138: For the AOR/Equivalent notice Receipt Date and AOR/Equivalent notice Receipt Time
fields, a commenter recommended that CMS update the field descriptions to include additional forms of
acceptable authorization documentation, for example a Power of Attorney, healthcare proxy, or executor
of an estate.
Response 138: CMS does not believe that an update to the protocol is required. Policy questions related
to additional forms of equivalent notice should be directed to the CMS policy mailbox
https://appeals.lmi.org.
CMS Action 138: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 139: A commenter recommended that CMS list references to the applicable universes in order
within the protocol and encouraged CMS to explore ways to simplify the timeliness element of the
protocols to possibly reduce or consolidate the number of compliance standards from the current count of
seventeen.
Response 139: We believe the commenter is referring to the order of the record layouts listed within the
program audit protocol table. Since there are multiple types of requests, levels of appeal, and the
potential for both standard and expedited cases, CMS declines to update the number of compliance
standards. Also, because the compliance standards are currently listed within the protocol by element,
CMS will be retaining the current order.
CMS Action 139: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 140: A commenter asked if the 10 dismissed cases referenced in compliance standard 3.1 of
the protocol are a subset of the 10 approvals, 30 denials, and 20 grievance samples or in addition to these
samples.
Response 140: The 10 dismissed cases are in addition to the other samples.
CMS Action 140: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 141: Two commenters asked what constitutes a payment coverage determination or
redetermination and asked if they are different from a Direct Member Reimbursement (DMR) request
(Initial Determination and Level 1 Appeal).
Response 141: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
Please see 42 CFR § 423.566(b), § 423.568(c) and § 423.590(b).
CMS Action 141: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 142: A commenter asked how to populate the Date the request was received and Date the
grievance was received fields in the following record layouts for a dismissed case: CD, CDER,
PYMT_D, RD and GRV_D. Specifically, the commenter asked if the fields should be populated with the
Page 40 of 95
date the request or grievance was received even though the request may not be valid because there is no
AOR on file.
Response 142: For this scenario, Sponsoring organizations should populate the Date the request was
received field per the field description in the protocol with the date the request was received. Please note,
as previously mentioned, CMS has added dismissed grievances to the exclusion instructions for the
GRV_D record layout. Since dismissed cases are excluded from GRV_D, the Date the grievance was
received would not be populated for this scenario since the case would be excluded from the universe.
CMS Action 142: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 143: A commenter asked when ‘None’ would be used for the AOR/Equivalent notice Receipt
Date and AOR/Equivalent notice Receipt Time fields found in the CD, CDER, PYMT_D, RD and
GRV_D record layouts, since the ‘NA’ option would apply in instances where no AOR was received and
the case was dismissed. Two other commenters asked if ‘None’ or ‘NA’ should be entered if an AOR is
required but is not received. Another commenter asked, for the RD record layout, whether ‘NA’ or
‘None’ should be entered for dismissed requests and noted that the AOR/Equivalent notice Receipt Time
field states to enter ‘NA’ for dismissed requests, but has the ‘None’ option, as well. Finally, a commenter
asked for clarification on the use of ‘NA’ for dismissed requests.
Response 143: CMS believes these field descriptions could be updated for simplicity and consistency
purposes. Thus, we have eliminated the ‘NA’ option for the AOR/Equivalent notice Receipt Date and
AOR/Equivalent notice Receipt Time field descriptions for the CD, CDER, PYMT_D, RD and GRV_D
record layouts. Sponsoring organizations can enter ‘None’ for these fields when no AOR or equivalent
written notice was received, when an AOR or equivalent written notice was not required, and for
dismissed requests when applicable.
CMS Action 143: CMS removed the ‘NA’ option from the AOR/Equivalent notice Receipt Date and
AOR/Equivalent notice Receipt Time field descriptions in the CD, CDER, PYMT_D, RD and GRV_D
record layouts. CMS updated the field descriptions to allow Sponsoring organizations to enter ‘None’
when no AOR or equivalent written notice was received, when an AOR or equivalent written notice was
not required, and for dismissed requests when applicable. No changes were made to the burden estimate
in response to these comments.
Comment 144: For the Date forwarded to IRE and Time forwarded to IRE fields, a commenter
requested that CMS change ‘NF’ to ‘NA’ in the field descriptions for requests not forwarded to the IRE
because the Sponsoring organization already has ‘NA’ programmed and ‘NF’ adds limited value.
Response 144: As previously mentioned, CMS has updated all instances of ‘NA’ and ‘NF’ to ‘None’
within the CDAG record layout field descriptions. The Date forwarded to IRE and Time forwarded to
IRE field descriptions have been updated in the CDAG record layouts to read, “Enter None if the request
was not forwarded to the IRE.”
CMS Action 144: CMS updated the Date forwarded to IRE and Time forwarded to IRE field descriptions
in the CDAG record layouts to read, “Enter None if the request was not forwarded to the IRE.” No
changes were made to the burden estimate in response to this comment.
Comment 145: A commenter suggested that CMS add enter ‘NA’ for dismissed cases in the description
of the following fields found within the CD and CDER record layouts: Date Oral Notification provided to
Page 41 of 95
enrollee; Time Oral Notification provided to enrollee; and, Date Written Notification provided to
enrollee.
Response 145: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS agrees with the commenter's suggestion with regard to the
Date Oral Notification provided to enrollee and Time Oral Notification provided to enrollee fields and
has updated the descriptions within the CD and CDER record layouts to allow Sponsoring organizations
to enter ‘None’ for dismissed requests.
CMS Action 145: CMS added “Enter None for dismissed cases” in the Date Oral Notification provided
to enrollee and Time Oral Notification provided to enrollee field descriptions in the CD and CDER record
layouts. No changes were made to the burden estimate in response to this comment.
Comment 146: Several commenters stated the NDC field description language is confusing. For the NDC
field, a commenter asked why all zeros should be entered when there is an NDC available for the non-Part
D drug. The commenter also asked how cost is defined when entering the most expensive amount related
to compounds and stated the current reporting is sufficient and trying to adhere to this change would be an
administrative burden and potential increase in error rate. A commenter stated populating the field for
multi-ingredient compound claims of the most expensive drug would require a large manual effort as
ingredient cost information is not populated within the system that tracks coverage determination reviews
and recommended that it be populated with the name of the first Part D eligible ingredient within the
requested multi-ingredient compound. Another commenter asked if all compounds should be entered on
one line, or if each drug should be entered including compounds individually. A commenter asked if the
applicable Uniform Product Code (UPC) or Health Related Item Code (HRI) could be entered or if the
field could be left blank if the NDC is not available. Another commenter asked for compound claims in
situations other than when the compound claim does not include any Part D drug products, if the field
could be populated with "00000000000" and stated that Sponsoring organizations don't always know the
NDCs that will be used in the compound.
Response 146: Consistent with the update described in the FA section above, we are removing this
language from the CDAG NDC field description for the following record layouts: CD; CDER; PYMT_D;
RD; and, EFF_D. Sponsoring organizations should include the NDC value as submitted by the
pharmacy, even if a blank field, a UPC or HRI code is submitted. In instances where the pharmacy
submits a value greater than 11 characters in the NDC field, Sponsoring organizations should populate the
NDC field with "valueXeeded." CMS is also updating the CDAG NDC field description to align with the
NDC field description found in the FA data request by removing the phrase, “of the most expensive drug”
for multi-ingredient compound claims. The field description language now reads, “For multi-ingredient
compound claims populate the field with the NDC as submitted on the associated PDE.” CMS has
standardized the NDC field descriptions in the CDAG and FA protocols as we believe this will reduce
burden and confusion for Sponsoring organizations by enhancing data consistency.
CMS Action 146: CMS removed the following NDC field description language, “When compound
claims do not include any Part D drug products, populate the field with '00000000000' consistent with the
NDC 11 format” and “of the most expensive drug” from the following record layouts: CD, CDER,
PYMT_D, RD, and EFF_D. No changes were made to the burden estimate in response to these
comments.
Comment 147: Two commenters asked how to populate the NDC field for at-risk appeals in the RD and
EFF_D record layouts when no specific drug is under appeal.
Page 42 of 95
Response 147: To accommodate at-risk appeals, CMS has added the following language to the NDC field
description of the RD and EFF_D record layouts, “or NDC is not applicable (e.g., for at-risk
redeterminations).”
CMS Action 147: CMS updated the NDC field description in the RD and EFF_D record layouts to read,
"When less than 11 characters or a blank field is submitted by the pharmacy or delegate, or NDC is not
applicable (e.g., for at-risk redeterminations), populate the field as submitted." No changes were made to
the burden estimate in response to these comments.
Comment 148: A commenter asked if the Authorization or Claim Number fields should include the
actual drug authorization number or case review identifier. The commenter noted that if they are able to
use the case identifier, there would never be an instance where ‘None’ would apply.
Response 148: Per the field description in the record layout, Sponsoring organizations should enter the
actual drug authorization number. If the drug authorization number is not available, enter the internal
tracking or case number. If there is no other tracking number available, enter ‘None.’
CMS Action 148: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 149: A commenter asked if the Date forwarded to IRE field in the PYMT_D and RD record
layouts is only for auto-forwarded cases or is this field also for case file requests received from the
Independent Review Entity (IRE).
Response 149: The Date forwarded to IRE field is for the Sponsoring organization to enter the date the
request was forwarded to the IRE.
CMS Action 149: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 150: For the CDER and RD record layouts, a commenter asked why ‘PA’ for Prior
Authorization is available for the Formulary UM Exception Type field. The commenter noted that the
field description says to enter ‘NA’ if the request was not an attempt to satisfy formulary utilization
management (UM) criteria or was not a safety edit and asked for an example of this scenario.
Response 150: If the case was a request to except Prior Authorization UM criteria, ‘PA’ should be
entered in the Formulary UM Exception Type field. As previously mentioned, CMS has updated all
instances of ‘NA’ to ‘None’ within the CDAG record layout field descriptions. For the “enter None if the
request was not a formulary UM exception or safety edit exception” language, examples of this would
include a tiering exception, non-formulary exception, and hospice exception.
CMS Action 150: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 151: One commenter stated the removal of the Enrollment Effective Date field could increase
the risk of including an incorrect record for a given enrollment effective period.
Response 151: CMS aimed to reduce burden on Sponsoring organizations by excluding unnecessary
fields within the record layouts. At this time, CMS believes it would be more burdensome for all
Sponsoring organizations to include an Enrollment Effective Date field when the field is not needed by
CMS for program audit purposes.
Page 43 of 95
CMS Action 151: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 152: For the PYMT_D and RD record layouts, a commenter requested clarification on the
phrase, "establishing good cause after the 60-day filing timeframe, enter the date the Sponsoring
organization received the information establishing good cause…"
Response 152: For more information, please see 42 CFR § 423.582(c) and section 50.3 of the
Parts C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance. Policy
questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 152: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 153: A commenter asked if ‘NA’ is a valid option for standard coverage determinations and
standard coverage determination exception requests in the Time the request was received field.
Response 153: CMS collects this information for timeliness test purposes. ‘NA’ is not an available
option for this field since the applicable regulatory timeframes in 42 CFR Part 423 Subpart M are in
hours.
CMS Action 153: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 154: A commenter noted the Was the coverage determination request denied for lack of
medical necessity? field was only in the PYMT_D record layout and asked if it was necessary to retain.
Another commenter requested that CMS remove this field for the PYMT_D and RD record layouts
consistent with the CD and CDER record layouts.
Response 154: The CD and CDER universes do not contain redetermination cases. This information is
needed to test compliance standard 2.6 in the CDAG protocol. CMS will review sampled redetermination
case file documentation for proper evidence that the person(s) involved in making the coverage
determination or at-risk determination under a drug management program did not conduct the
redetermination, and if the denial of coverage was based on a lack of medical necessity, that the
redetermination was made by a physician with expertise in the field of medicine that was appropriate for
the services at issue.
CMS Action 154: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 155: A commenter requested for CMS to standardize the ‘NA’ option for the Expiration date
of the approval field description for the CDER and EFF_D record layouts to read, "Enter NA if the
exception was not approved or if the request was not an exception request."
Response 155: CMS declines to make the requested updates. It would not be accurate to add, "Enter NA
if the request was not an exception request" to the CDER record layout because this universe includes
only exception requests. Similarly, for the EFF_D record layout, instructions to "Enter NA if the
exception was not approved" are not applicable as the universe includes only cases fully or partially
overturned by the IRE, ALJ, or MAC requiring effectuation.
Page 44 of 95
CMS Action 155: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 156: A commenter asked when ‘NA’ would apply for the Formulary UM Type field in the CD
record layout.
Response 156: CMS agrees that the ‘NA’ option for the Formulary UM Type field in the CD record
layout can be removed.
CMS Action 156: CMS removed the following language from the Formulary UM Type field description
in the CD record layout, “Enter NA if the request was not an attempt to satisfy formulary UM criteria.”
No changes were made to the burden estimate in response to this comment.
Comment 157: For the Formulary UM Type field in the CD record layout, a commenter asked why the
field description does not state to enter ‘PA’ instead of ‘NA’ if the request was not an attempt to satisfy
formulary UM criteria or was not a safety edit.
Response 157: PA (Prior Authorization) is a UM management type and is one of the permissible field
entries. Sponsoring organizations should enter the formulary UM criteria the enrollee satisfied or was
attempting to satisfy; ‘PA’ for Prior Authorization or ‘ST’ for Step Therapy.
CMS Action 157: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 158: Two commenters asked if the intent is for quantity limit and safety edit reviews to be
classified as Coverage Determinations (and included in the CD record layout) or exceptions (and included
in the CDER record layout). Similarly, another commenter asked how Sponsoring organizations should
determine if a safety edit request should be considered a coverage determination or an exception, and two
commenters asked for a definition of the criteria to categorize a case as requiring a safety edit.
Response 158: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 158: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 159: Five commenters asked why the Quantity Limit (QL) and Safety Edit (SE) options were
included for the Formulary UM Type field in the CD and CDER record layouts.
Response 159: CMS agrees that these options can be removed from the Formulary UM Type field
description in the CD record layout but CMS is retaining the ‘QL’ and ‘SE’ options for this field in the
CDER record layout since quantity limit and safety edit requests are exceptions.
CMS Action 159: CMS updated the Formulary UM Type field description in the CD record layout by
removing the phrases, "QL for Quantity Limit", "If the case was a safety edit enter: SE for Safety Edit",
and "or was not a safety edit". No changes were made to the burden estimate in response to these
comments.
Comment 160: A commenter asked if the intent was for redetermination and coverage determination
reviews completed as a result of an at-risk determination from a Drug Management Program to be
classified as a coverage determination type or exception type. If these reviews are to be included as
exception requests, the commenter asked what Formulary UM Exception Type would apply.
Page 45 of 95
Response 160: Sponsoring organizations should submit cases as they were processed. We believe the
current descriptions for the Formulary UM Exception Type field in the CDER record layout allow for
classification of all UM exception types. Policy questions should be directed to the CMS policy mailbox
https://appeals.lmi.org.
CMS Action 160: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 161: A commenter noted that the AOR/Equivalent notice Receipt Time field description in the
CDER record layout includes ‘NA’ for dismissed cases but the AOR/Equivalent notice Receipt Date field
description does not. The commenter asked if ‘NA’ for dismissed cases was intended to be included in
the AOR/Equivalent notice Receipt Date field description as well.
Response 161: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS appreciates the comment and has updated the
AOR/Equivalent notice Receipt Date field description in the CDER record layout to allow Sponsoring
organizations to enter ‘None’ for dismissed cases.
CMS Action 161: CMS updated the AOR/Equivalent notice Receipt Date field description in the CDER
record layout to read, "Enter None for dismissed cases or if no AOR or equivalent written notice was
received or required.” No changes were made to the burden estimate in response to this comment.
Comment 162: A commenter noted that the Exception Type field in the CDER record layout permits an
entry for ‘Hospice’ exception types. The commenter requested clarification because their understanding
was hospice requests are coverage determinations and therefore would be included in the CD record
layout.
Response 162: The CD and CDER universes both contain coverage determinations. Hospice is a Part A
benefit. A request to cover a drug eligible for coverage under the Part A hospice benefit as a Part D
covered drug would always be an exception request.
CMS Action 162: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 163: For the CDER record layout, a commenter asked how the concept of an exception should
be applied for the hospice and safety edit options.
Response 163: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 163: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 164: For the Date prescriber supporting statement received and Time prescriber supporting
statement received fields in the CDER record layout, a commenter asked what to enter if the request was
initiated by the enrollee and all information (including the supporting statement) was provided by the
enrollee. The commenter also asked what to enter if the request was initiated by the enrollee and all
information (including the supporting statement) was available from prior claim history or previous prior
authorizations (PAs) on file.
Page 46 of 95
Response 164: If the information (including the supporting statement) was available from prior claim
history or previous PAs on file, enter ‘None’ for these fields if no prescriber supporting statement was
received for the subject request. If the enrollee provided the prescriber's supporting statement, enter the
date and time the Sponsoring organization received the supporting statement. If the prescriber supporting
statement was received with the initial request, enter the date and time the exception request was received.
CMS Action 164: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 165: For the CDER record layout, a commenter asked if Sponsoring organizations should
report each formulary UM type separately when a request for a drug involves multiple formulary UM
types. For example, a drug may have a PA and QL where the PA is approved but the QL is denied.
Response 165: CMS has clarified the CDER record layout instructions; they now read, “Each exception
request must be listed as its own line item in the submitted universe. If a request for multiple drugs is
made at the same time, enter each drug in a separate row. Requests for a single drug involving multiple
exception types (e.g., tiering exception, prior authorization exception, quantity limit exception, and step
therapy exception) must be entered as a single line item. Enter any request denied in whole or in part as
denied.” Per the Formulary UM Exception Type field description, if multiple formulary UM exception
criteria apply, enter the criteria applicable based on the approval or denial reason.
CMS Action 165: CMS updated the CDER record layout instructions to read, “Each exception request
must be listed as its own line item in the submitted universe. If a request for multiple drugs is made at the
same time, enter each drug in a separate row. Requests for a single drug involving multiple exception
types (e.g., tiering exception, prior authorization exception, quantity limit exception, and step therapy
exception) must be entered as a single line item. Enter any request denied in whole or in part as
denied.” No changes were made to the burden estimate in response to this comment.
Comment 166: A commenter asked if the PYMT_D universe should include reimbursement requests
from the enrollee, their representative, or their prescriber.
Response 166: Per the record layout instructions, Sponsoring organizations should include all payment
coverage determinations and redeterminations the Sponsoring organization approved, denied, re-opened
approved, re-opened denied, auto-forwarded to the IRE or dismissed during the universe request period.
CMS Action 166: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 167: A commenter noted that the protocol combines payment coverage determinations and
redeterminations. The commenter referenced the method of evaluation language “conduct timeliness test
at the universe level on payment coverage redeterminations and determine whether the Sponsoring
organization issued its redetermination no later than 14 calendar days after the Sponsoring organization
received the redetermination request and made payment (when applicable) no later than 30 calendar days
after receipt of the request.” The commenter noted that the record layout does not ask Sponsoring
organizations to indicate whether the payment request is a coverage determination or redetermination and
also noted that the timeliness timeframes are different. Two other commenters requested that CMS add a
field to denote whether the request was a coverage determination or redetermination for the PYMT_D
record layout.
Response 167: CMS conducts timeliness tests in accordance with the applicable regulations. In this case,
42 CFR § 423.568(c) for payment coverage determinations and 42 CFR § 423.636(a) and § 423.590(b)
Page 47 of 95
for payment coverage redeterminations. The protocol lists two separate compliance standards, 1.5 for the
payment coverage determination timeliness test, and 1.7 for the payment coverage redetermination
timeliness test. CMS believes the commenter may have been referring to the Data Request column listed
in the protocol which refers to the PYMT_D record layout for both compliance standards since the
protocol combines payment coverage determinations and redeterminations into one universe. CMS
agrees that the addition of a field to the PYMT_D record layout is warranted for the Sponsoring
organization to indicate whether the request is a payment coverage determination or redetermination.
CMS Action 167: CMS added a field to the PYMT_D record layout titled "Type of Request" and added
the following field description language, "Enter: payment coverage determination or payment
redetermination." No changes were made to the burden estimate in response to these comments.
Comment 168: A commenter noted that the PYMT_D record layout includes a data element asking if the
request was processed as an exception. The commenter asked how Sponsoring organizations should
apply the definition of an exception to a post-service reimbursement request, specifically when the drug
had no reviewable edit applied, e.g. non-formulary drug or utilization management.
Response 168: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 168: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 169: Four commenters noted that the PYMT_D record layout includes an instruction
indicating that requests processed as coverage determinations should be excluded and asked for
clarification. One commenter asked if this means that if the drug on the DMR request also required a
determination because it had a utilization management edit or was a non-formulary drug, that the
coverage determination case should be counted in the coverage determination universe and the DMR
claim should be excluded from the DMR universe.
Response 169: CMS appreciates this feedback. The language "Exclude all requests processed as
coverage determinations" has been removed from the PYMT_D record layout instructions. CMS has also
updated the instructions to read, “Each payment request must be listed as its own line item in the
submitted universe. If a request for multiple drugs is made at the same time, enter each drug in a separate
row. Requests for a single drug must be entered as a single line item. Enter any request denied in whole
or in part as denied.” If multiple requests are made at the same time for a single drug it should be
reported as a single case in the record layout. The processing timeframe for Part D payment requests is 14
calendar days and is not subject to tolling. All payment related requests must be submitted in the
PYMT_D universe. If an enrollee requests a reimbursement on the Part D side and the request is subject
to a PA/ST/QL, CMS would expect to see the reimbursement request entered as a single case within the
PYMT_D universe; the UM aspect of the case would not be reported in the Part D payment universe or in
other universes, regardless of whether the case was processed as separate requests or treated holistically.
CMS Action 169: CMS removed the following phrase from the exclusion language of the PYMT_D
record layout, “all requests processed as coverage determinations and any.” The updated language reads,
"Exclude requests for coverage that were withdrawn." CMS also updated the record layout instructions to
read, “Each payment request must be listed as its own line item in the submitted universe. If a request for
multiple drugs is made at the same time, enter each drug in a separate row. Requests for a single drug
must be entered as a single line item. Enter any request denied in whole or in part as denied.” No changes
were made to the burden estimate in response to these comments.
Page 48 of 95
Comment 170: A commenter noted the PYMT_D record layout includes a data element asking if the
request was denied for lack of medical necessity. The commenter asked how the definition of medical
necessity should be applied to a post-service reimbursement request.
Response 170: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 170: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 171: A commenter noted that CMS included the PYMT_D record layout in the Data Request
column for compliance standard 2.4 which states that universes will be tested to ensure that a physician or
other appropriate healthcare professional reviewed denials for clinical accuracy. The commenter noted
that a DMR request may be denied for a non-clinical administrative reason and asked if this statement
implies that CMS expects administrative denials to be reviewed by a physician or other healthcare
professional.
Response 171: No, CMS is not stating that administrative denials are required to be reviewed by a
physician or other healthcare professional. The method of evaluation within the protocol is only applied
to applicable cases and in accordance with the referenced regulatory requirements, in this case 42 CFR §
423.562(a) and § 423.566(d).
CMS Action 171: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 172: A commenter noted that CMS added, "If the Sponsoring organization obtained
information establishing good cause after 60-day filing timeframe, enter the date the Sponsoring
organization received the information establishing good cause" to the Date the request was received field
description in the PYMT_D record layout and asked how long after the 60-day timeframe the Sponsoring
organization should allow for good cause documents to be submitted.
Response 172: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
CMS Action 172: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 173: For the PYMT_D record layout a commenter asked, for redeterminations, if the Date
prescriber supporting statement received field should be populated with the date of the coverage
determination request or the date of the redetermination request if the prescriber supporting statement was
received with the initial request.
Response 173: For redeterminations, the Date prescriber supporting statement received field should be
populated with date of the redetermination request if the prescriber supporting statement was received
with the initial redetermination request.
CMS Action 173: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 174: A commenter asked the purpose of the Date prescriber supporting statement received
field in the PYMT_D record layout. Three commenters also asked about the addition of fields related to
the exception type and supporting statement in the PYMT_D record layout.
Page 49 of 95
Response 174: CMS may use these fields to guide sample selection.
CMS Action 174: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 175: Two commenters asked, for payment redeterminations, if the PYMT_D Was the
coverage determination request denied for lack of medical necessity? field should be populated based on
the initial coverage determination denial for lack of medical necessity.
Response 175: Yes, for payment redeterminations, this field should be populated as titled with a response
as to whether the coverage determination request was denied for lack of medical necessity.
CMS Action 175: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 176: A commenter asked if the word "received” should be replaced with “required” in the
following language for the Date prescriber supporting statement received field description in the
PYMT_D record layout, "Enter the date the prescriber’s supporting statement was received. If the
prescriber statement was received with the initial request, enter the date the exception was received."
Response 176: We don't believe this field description requires updating. Sponsoring organizations should
enter the date the prescriber's supporting statement was received. For cases where the prescriber's
supporting statement is received with the initial request, Sponsoring organizations should enter the date
the exception request was received.
CMS Action 176: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 177: A commenter asked what should be entered in the Expiration date of the approval field in
the PYMT_D record layout.
Response 177: If the request was an exception request, Sponsoring organizations would enter the
expiration date of the exception approval. If the request was not an exception request or if the exception
request was not approved, Sponsoring organizations would enter ‘None.’
CMS Action 177: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 178: A commenter asked if only exceptions and not approvals should be entered in the Date
prescriber supporting statement received field of the PYMT_D record layout.
Response 178: The PYMT_D record layout includes approved, denied, re-opened approved, re-opened
denied, auto-forwarded to the IRE and dismissed case types. A prescriber supporting statement may be
needed to support a formulary utilization management (UM) or an exception. Enter the date the
prescriber's supporting statement was received. If the prescriber statement was received with the initial
request, enter the date the exception request was received. Enter ‘None’ only if no prescriber supporting
statement was received.
CMS Action 178: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 50 of 95
Comment 179: A commenter requested clarification on when to use ‘NRD’ and ‘NP’ for the Date
Reimbursement Provided field in the PYMT_D record layout. Another commenter expressed
appreciation for CMS' efforts to clarify the Date reimbursement provided field description in the
PYMT_D record layout.
Response 179: CMS appreciates the positive feedback. A Sponsoring organization would enter ‘NRD’ if
the request was approved but no reimbursement was due to the enrollee. A Sponsoring organization
would enter ‘NP’ if the payment has not been issued at the time of the universe submission. For example,
‘NP’ would be used for a case where the request was approved and reimbursement was due to the
enrollee, but the reimbursement had not yet been issued to the enrollee at the time of universe submission
to CMS.
CMS Action 179: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 180: For the PYMT_D record layout, a commenter asked if the Date the request was received
field should be populated with the date the request was received and noted the field description does not
indicate an option to enter ‘None.’
Response 180: Yes, the Date the request was received field should be populated with the date the request
was received. Please also see the record layout instructions which state, "For cases with a Request
Determination of re-opened approved or re-opened denied, the date and time the request was received
must be the date and time the case was re-opened (i.e., the determination was made to re-open the case)."
CMS Action 180: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 181: A commenter asked how to populate the Date effectuated in the system field in the
PYMT_D record layout when no effectuation is needed for an approved case.
Response 181: For this scenario, the Date effectuated in the system field should be populated with the
date the benefit was authorized. Please note, there is an option to enter ‘NRD’ for the Date
reimbursement provided field if the request was approved but no reimbursement was due to the enrollee.
CMS Action 181: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 182: For the Formulary UM Exception Type field in the PYMT_D record layout, a commenter
asked what should be entered for redeterminations. The commenter asked if ‘NA’ should be entered or if
the information from the initial decision should be entered.
Response 182: Sponsoring organizations should submit cases as they were processed by the Sponsoring
organization and, for this scenario, should enter the information applicable to the redetermination request.
CMS Action 182: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 183: A commenter recommended that CMS remove the ‘NA’ option in the description of the
Is this a protected class drug? field that is found in the RD record layout to be consistent with the other
record layouts.
Page 51 of 95
Response 183: CMS agrees and has removed "NA if not applicable" from the Is this a protected class
drug? field description in RD record layout.
CMS Action 183: CMS removed "NA if not applicable" from the Is this a protected class drug? field
description in the RD record layout. No changes were made to the burden estimate in response to this
comment.
Comment 184: A commenter requested that CMS update the AOR/Equivalent notice Receipt Time field
description in the RD layout to permit Sponsoring organizations to enter ‘NA’ for standard cases.
Response 184: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS agrees with the commenter and has updated the field
description language to allow Sponsoring organizations to enter ‘None’ for standard cases.
CMS Action 184: CMS updated the AOR/Equivalent notice Receipt Time field description in the RD
record layout to read "Enter None for standard cases." No changes were made to the burden estimate in
response to this comment.
Comment 185: A commenter asked CMS to remove the phrase ‘Sponsoring organization's’ from the RD
record layout Date of Determination field description.
Response 185: In the interest of consistency of field descriptions within the record layouts, CMS
removed the phrase ‘Sponsoring organization's’ from the RD record layout Date of Determination and
Time of Determination field descriptions. The new field descriptions read, "Enter the date of the
determination. Submit in CCYY/MM/DD format (e.g., 2020/01/01)" and "Enter the time of the
determination. Submit in HH:MM:SS military time format (e.g., 23:59:59)."
CMS Action 185: CMS removed the phrase ‘Sponsoring organization's’ from the RD record layout Date
of Determination and Time of Determination field descriptions. No changes were made to the burden
estimate in response to this comment.
Comment 186: A commenter asked CMS to update the Was the coverage determination request denied
for lack of medical necessity? field description for the RD record layout by adding an ‘NA’ option if the
request was not denied (i.e., approved, auto-forwarded, dismissed).
Response 186: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
field descriptions of the CDAG record layouts. CMS agrees with adding a ‘None’ option for autoforwarded cases in the RD record layout, however, we decline to add a ‘None’ option for approved and
dismissed cases because, if the coverage determination request was approved or dismissed, the case
would not appear in the redetermination universe.
CMS Action 186: CMS added, "None if the request auto-forwarded" to the Was the coverage
determination request denied for lack of medical necessity? field description in the RD record layout. No
changes were made to the burden estimate in response to this comment.
Comment 187: A commenter requested clarification on the following RD record layout exclusion
language, "Exclude all requests processed as payment redeterminations, withdraws, and direct member
reimbursement requests." The commenter asked the difference between payment redeterminations and
direct member reimbursement requests and stated they use these terms interchangeably.
Page 52 of 95
Response 187: CMS agrees with the commenter and has deleted the phrase "and direct member
reimbursement requests" from the exclusion language. The RD record layout exclusion language now
reads, "Exclude all requests processed as payment redeterminations and withdrawn cases."
CMS Action 187: CMS deleted the phrase "and direct member reimbursement requests" from the RD
record layout exclusion language. The RD record layout exclusion language now reads, "Exclude all
requests processed as payment redeterminations and withdrawn cases." No changes were made to the
burden estimate in response to this comment.
Comment 188: For the Date oral notification provided to enrollee field in the RD record layout, three
commenters asked if ‘NA’ is an acceptable response for standard cases.
Response 188: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. For standard redeterminations, the Date oral notification
provided to enrollee field can be populated with ‘None.’ CMS has added this option to the field
description.
CMS Action 188: CMS updated the Date oral notification provided to enrollee field description in the
RD record layout to read "Enter None for standard cases, dismissed cases or if no oral notification was
provided.” No changes were made to the burden estimate in response to these comments.
Comment 189: Two commenters asked if CMS would add "NA for standard cases" in the RD record
layout AOR/Equivalent notice Receipt Time field.
Response 189: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS agrees with the commenters' suggestion and has added an
option to enter ‘None’ for standard cases. The AOR/Equivalent notice Receipt Time field description for
the RD record layout now reads, "Enter None for standard cases, dismissed cases or if no AOR or
equivalent written notice was received or required."
CMS Action 189: CMS updated the AOR/Equivalent notice Receipt Time field description in the RD
record layout to allow for ‘None’ to be entered for standard cases. No changes were made to the burden
estimate in response to these comments.
Comment 190: A commenter noted that the RD record layout does not include or exclude at-risk appeals
and stated they presumed at-risk determinations and appeals would be included in the AR record layout.
The commenter asked for CMS to confirm if their understanding is correct. Another commenter asked
how at-risk determination appeals should be reported.
Response 190: The RD record layout instructions state to include all redeterminations. As such, at-risk
determination appeals would be included in the RD universe. Please note the AR record layout
instructions state to "exclude appeals of at-risk determinations."
CMS Action 190: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 191: A commenter asked if the Time the request was received field description for the RD
record layout should be updated to read "redetermination" instead of "reconsideration."
Response 191: CMS agrees with the suggestion and has made this correction.
Page 53 of 95
CMS Action 191: CMS updated the Time the request was received field description for the RD record
layout to match the Date the request was received field description. The updated language reads, "If the
Sponsoring organization obtained information establishing good cause after the 60-day filing timeframe,
enter the time the Sponsoring organization received the information establishing good cause." No
changes were made to the burden estimate in response to this comment.
Comment 192: In the RD record layout, a commenter asked how to populate the Date written
notification provided to enrollee and Time written notification provided to enrollee fields when an appeal
is auto-forwarded to the IRE. The commenter asked if ‘NA’ should be entered or the date when the
Sponsoring organization mailed the auto-forward notice to the enrollee.
Response 192: For this scenario, if the Sponsoring organization did not send written notification of the
decision to the enrollee, ‘None’ would be entered for these fields.
CMS Action 192: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 193: A commenter requested that CMS add "PBP" to the end of the field Plan Benefit Package
field name in the EFF_D record layout.
Response 193: CMS agrees and in the interest of consistency has added "(PBP)" to the end of the Plan
Benefit Package field name.
CMS Action 193: CMS added "(PBP)" to the end of the Plan Benefit Package field name in the EFF_D
record layout. No changes were made to the burden estimate in response to this comment.
Comment 194: For the Date the overturn decision was effectuated in the system field description in the
EFF_D record layout, a commenter requested that CMS change the ‘NE’ option to ‘NA’ to read, "Enter
NA if the overturn decision was not effectuated or if no effectuation was required."
Response 194: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS agrees with the commenter’s suggestion. In light of the
aforementioned change from ‘NA’ to ‘None,’ CMS has updated the Date the overturn decision was
effectuated in the system and Time the overturn decision was effectuated in the system field descriptions in
the EFF_D record layout to read, "Enter None if the overturn decision was not effectuated or if no
effectuation was required."
CMS Action 194: CMS updated the Date the overturn decision was effectuated in the system and Time
the overturn decision was effectuated in the system field descriptions in the EFF_D record layout to read,
"Enter None if the overturn decision was not effectuated or if no effectuation was required." No changes
were made to the burden estimate in response to this comment.
Comment 195: For the Date Reimbursement Provided field in the EFF_D record layout, a commenter
asked how to populate the field for pre-service cases.
Response 195: Since a pre-service request would not have a reimbursement, Sponsoring organizations
would enter ‘NRD’ for this field if the request was approved but no reimbursement was due to the
enrollee.
CMS Action 195: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 54 of 95
Comment 196: A commenter noted their agreement with CMS' combining of all request types within the
EFF_D record layout.
Response 196: CMS appreciates the commenter's feedback and support.
CMS Action 196: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 197: A commenter asked about the EFF_D record layout inclusion instructions. The
commenter asked if "coverage determinations" is referring to untimely cases forwarded by the PBM and
asked what would be considered an at-risk determination.
Response 197: The EFF_D record layout instructions state to "Include all coverage determinations,
redeterminations, or at-risk determinations fully or partially overturned by the IRE, ALJ, or MAC
requiring an effectuation as pre-benefit, post-service (payment), or an at-risk determination received from
the IRE, ALJ, or MAC during the universe request period." Any coverage determinations fully or
partially overturned by the IRE, ALJ, or MAC requiring an effectuation and received from the IRE, ALJ,
or MAC during the universe request period should be included. This could include untimely coverage
determinations forwarded to the IRE by the Sponsoring organization or its Pharmacy Benefit Manager
(PBM). By at-risk determinations, CMS is referring to at-risk determinations made by a Sponsoring
organization pursuant to 42 CFR § 423.153(f).
CMS Action 197: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 198: A commenter stated that the Date the overturn decision was effectuated in the system,
Time the overturn decision was effectuated in the system, and Date reimbursement provided fields in the
EFF_D record layout appeared to be duplicative and asked when a Sponsoring organization would use the
Date the overturn decision was effectuated in the system field versus the Date reimbursement provided
field.
Response 198: CMS does not believe these fields are duplicative. Based on the commenter's question,
CMS has clarified the Date the overturn decision was effectuated in the system and Time the overturn
decision was effectuated in the system field descriptions in the EFF_D record layout. The field
descriptions previously read, "Enter the date/time the benefit was provided, payment was made or the
change to the at-risk determination was implemented." CMS has replaced "payment was made" with
"payment was authorized" since the Date reimbursement provided field captures the date the check or
reimbursement was provided.
CMS Action 198: CMS updated the Date the overturn decision was effectuated in the system and Time
the overturn decision was effectuated in the system field descriptions in the EFF_D record layout to read,
"Enter the date the benefit was provided, payment was authorized or the change to the at-risk
determination was implemented" and "Enter the time the benefit was provided, payment was authorized
or the change to the at-risk determination was implemented," respectively. No changes were made to the
burden estimate in response to this comment.
Comment 199: A commenter asked if the Expiration date of the approval field in the EFF_D record
layout is for exceptions requests only.
Page 55 of 95
Response 199: Yes, please note the field description states, "Enter the expiration date of the exception
approval" and instructs to enter ‘None’ if it was not an exception request.
CMS Action 199: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 200: A commenter asked which reopened cases should be excluded from the EFF_D universe.
The commenter offered two examples. Example 1: The Sponsoring organization effectuates an IRE
overturn. The Sponsoring organization asks the IRE to reopen the case. The IRE accepts the request to
reopen, but the reopening decision is still pending. The Sponsoring organization received the original
overturn decision during the universe period. The commenter asked if the original overturn should be
included in the universe. Example 2: The IRE upholds the Sponsoring organization's denial, but later
accepts the prescriber's request to reopen based on new information. The IRE reverses its decision and
sends the Sponsoring organization notice of the approval. The Sponsoring organization received the
notice of approval and effectuated it within the universe period. The commenter asked if the reopened
case should be included in the universe.
Response 200: For the examples provided, since these are cases fully or partially overturned by the IRE,
ALJ, or MAC requiring effectuation, they should both be included in the EFF_D universe. CMS believes
the record layout instructions could be clarified pertaining to reopenings and has updated the language to
read, "Exclude any cases that were re-opened by the Sponsoring organization..."
CMS Action 200: CMS updated the EFF_D record layout instructions to read, "Exclude any cases that
were re-opened by the Sponsoring organization or that were dismissed or upheld by the IRE, ALJ, or
MAC." No changes were made to the burden estimate in response to this comment.
Comment 201: A commenter asked if Sponsoring organizations could enter ‘NA’ for the Is this a
protected class drug? field in the EFF_D record layout for at-risk appeals where no specific drug is under
appeal and noted this option is available in the RD record layout.
Response 201: CMS appreciates the comment and has added "None if not applicable" to the Is this a
protected class drug? field description in the EFF_D record layout.
CMS Action 201: CMS added "None if not applicable" to the Is this a protected class drug? field
description in the EFF_D record layout and updated the field length from 1 to 4. No changes were made
to the burden estimate in response to this comment.
Comment 202: For the EFF_D record layout, a commenter asked how Sponsoring organizations should
assess priority (i.e. standard or expedited) for these types of cases. The commenter asked if the priority
should be entered based on the way the Sponsoring organization most recently processed the case or
based on how the external reviewer processed the case. The commenter also asked how the appeal should
be reported if an overturn involves both reimbursement and coverage for the same drug going forward.
Response 202: Sponsoring organizations should include cases for the EFF_D record layout based on how
they were received from the review entity per 42 CFR § 423.636(b) and § 423.638(b). If an overturn
involves both reimbursement and coverage for the same drug going forward, Sponsoring organizations
should report the appeal as a ‘Standard request for benefits’ in the Type of Request reversed by review
entity field.
CMS Action 202: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 56 of 95
Comment 203: A commenter asked if Sponsoring organizations should submit cases for the GRV_D
record layout based on the resolution date.
Response 203: Per the record layout instructions, Sponsoring organizations should include all grievances
responded to during the universe request period. The date of the Sponsoring organization’s response must
fall within the universe request period.
CMS Action 203: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 204: For the GRV_D record layout, a commenter requested that the use of ‘NA’ be made
consistent for the Time oral response provided to enrollee and Time written response provided to enrollee
field descriptions.
Response 204: As previously mentioned, CMS has updated these field names to Time oral notification
provided to enrollee and Time written notification provided to enrollee. We agree with the commenter's
suggestion and have also updated the GRV_D record layout Time oral notification provided to enrollee
field description. The language was changed from "For standard cases, entering NA is an acceptable
response" to "Enter None for standard cases or if no oral notification was provided."
CMS Action 204: CMS updated the Time oral notification provided to enrollee field description in the
GRV_D record layout to read, "Enter None for standard cases or if no oral notification was provided."
No changes were made to the burden estimate in response to this comment.
Comment 205: A commenter requested for CMS to apply the definition of “at-risk” determination to any
review that was decisioned during the universe request period, regardless of when case management
began. The commenter stated this would identify a beneficiary who meets Overutilization Monitoring
System (OMS) criteria, is not exempted from Drug Management Programs (DMPs), and was sent a
second notice confirming the implementation of a coverage limitation subsequent to case management
review. Another commenter asked if the intent for the AR record layout is to include all beneficiaries
reviewed as a part of a Drug Management Program or only those beneficiaries who have been determined
to be at-risk beneficiaries with a restriction in place. A third commenter asked for clarification on what
should be reported in the AR record layout.
Response 205: Sponsoring organizations are to include all at-risk determinations made by the Sponsoring
organization pursuant to 42 CFR § 423.153(f) during the universe request period. The record layout
instructions indicate that the date of the Sponsoring organization’s determination must fall within the
universe request period. This is the date the Sponsoring organization makes a determination that a
beneficiary is an at-risk beneficiary and to limit the beneficiary's access to coverage for frequently abused
drugs under 42 CFR § 423.153(f)(3) or the Sponsoring organization determines that the potential at-risk
beneficiary is not an at-risk beneficiary.
CMS Action 205: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 206: A commenter requested for CMS to permit an ‘NA’ entry for the AR record layout Drug
Name, Strength, and Dosage Form field description when the request is related to an at-risk determination
but is not related to a specific drug (pharmacy lock-in, prescriber lock-in) and when the at-risk
determination is drug related, but is not specific to a single drug (e.g. a beneficiary level edit blocking all
opioid access, and or a beneficiary level edit allowing a defined cumulative MME dosage).
Page 57 of 95
Response 206: As previously mentioned, CMS has updated all instances of ‘NA’ to ‘None’ within the
CDAG record layout field descriptions. CMS agrees with the commenter and has updated the AR record
layout Drug Name, Strength, and Dosage Form field description to read, “Enter None if not related to a
specific drug (e.g. pharmacy lock-in, prescriber lock-in) or if the at-risk determination is drug related, but
is not specific to a single drug (e.g. beneficiary level edit blocking all opioid access, beneficiary level edit
allowing a defined cumulative MME dosage).”
CMS Action 206: CMS updated the AR record layout Drug Name, Strength, and Dosage Form field
description to read, “Enter None if not related to a specific drug (e.g. pharmacy lock-in, prescriber lockin) or if the at-risk determination is drug related, but is not specific to a single drug (e.g. beneficiary level
edit blocking all opioid access, beneficiary level edit allowing a defined cumulative MME dosage).” No
changes were made to the burden estimate in response to this comment.
Comment 207: For the AR record layout, a commenter asked for a definition of the term "final status"
and recommended that it be defined as the final disposition of case management which led the beneficiary
to receiving a second or alternate second notice.
Response 207: CMS clarified the Request Determination field description in the AR record layout by
removing the phrase, "final status of the at risk."
CMS Action 207: CMS updated the Request Determination field description in the AR record layout to
read, "Enter the determination: At-Risk, Not At-Risk." No changes were made to the burden estimate in
response to this comment.
Comment 208: For the Confirmation of Agreement to Place Limitation upon Enrollee field found in the
AR record layout, a commenter asked how to populate the field in instances where Sponsoring
organizations have a network agreement in place which specifies how the pharmacy will be notified by
the Sponsoring organization of its selection and the pharmacy has agreed in advance in a network
agreement with the Sponsoring organization to accept all such selections.
Response 208: If there is a pharmacy advance agreement, the Sponsoring organization would enter
‘YPH’ for Yes from Pharmacy. If both the pharmacy and provider confirmed, the Sponsoring
organization would enter ‘YBO’ for Yes from Both.
CMS Action 208: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 209: For the If an enrollee edit was used, date the edit was effectuated in the system field, a
commenter asked for clarification that an "enrollee edit" can be a pharmacy lock-in, prescriber lock-in or
beneficiary-level drug edit.
Response 209: Enrollee edit includes the limitations on access to coverage for frequently abused drugs
described in 42 CFR § 423.153(f)(3). For questions about Drug Management Program (DMP) policy,
please email [email protected].
CMS Action 209: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 58 of 95
Comment 210: For the Type of At-Risk Limitation field in the AR record layout, a commenter requested
that CMS update the field length character value from 50 to 54 so Sponsoring organizations can enter up
to a total of three of the valid values.
Response 210: CMS agrees with the commenter's suggestion and has updated the field length to 54
characters.
CMS Action 210: CMS updated the Type of At-Risk Limitation field length in the AR record layout to 54.
No changes were made to the burden estimate in response to this comment.
Comment 211: A commenter referenced four fields in the AR record layout (the Date Second Written
Notification of At-Risk Determination Provided to Enrollee, At-Risk Determination Date, Request
Determination, and Type of Risk Determination fields) and asked how a Sponsoring organization makes
the determination of at-risk.
Response 211: Questions pertaining to at-risk determination policy and/or definition should be addressed
to the CMS policy mailbox [email protected].
CMS Action 211: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 212: A commenter asked for confirmation that the AR record layout is not required for
Sponsoring organizations who are not yet administering a Comprehensive Addiction and Recovery Act
(CARA) program to their enrollees.
Response 212: Sponsoring organizations should adhere to the AR record layout instructions. If the
Sponsoring organization did not make any at-risk determinations pursuant to 42 CFR § 423.153(f) during
the universe request period there would be no universe data to report. If a Sponsoring organization does
not have any cases responsive to a particular universe request, it must upload a Microsoft Excel (.xlsx) or
Text (.txt) file format document to the Health Plan Management System (HPMS) at the appropriate
universe level that includes a statement explaining it does not have responsive cases for the particular
universe during the requested audit period.
CMS Action 212: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 213: For the AR record layout, a commenter asked if the universe should only include
members who meet OMS clinical guidelines and who do not have a CMS-defined exemption from the
opioid drug management program. Specifically, the commenter asked if the record layout should include
only enrollees who are potentially at-risk beneficiaries and at-risk beneficiaries who received an initial
notification letter.
Response 213: Sponsoring organizations are to include all at-risk determinations made by the Sponsoring
organization pursuant to 42 CFR § 423.153(f) during the universe request period. The record layout
instructions indicate that the date of the Sponsoring organization’s determination must fall within the
universe request period. This is the date the Sponsoring organization makes a determination that a
beneficiary is an at-risk beneficiary and to limit the beneficiary's access to coverage for frequently abused
drugs under 42 CFR § 423.153(f)(3), or the Sponsoring organization determines that the potential at-risk
beneficiary is not an at-risk beneficiary. CMS has clarified the Date Second Written Notification of AtRisk Determination Provided to Enrollee field description by removing the phrase “that identified them as
being at risk” since the alternate second written notification does not identify enrollees as being at-risk.
Page 59 of 95
CMS Action 213: For the Date Second Written Notification of At-Risk Determination Provided to
Enrollee field description in the AR record layout CMS removed the phrase, “that identified them as
being at risk.” No changes were made to the burden estimate in response to this comment.
Comment 214: A commenter asked if a case should be included in the AR universe if the enrollee is
initially identified as a potentially at-risk beneficiary, but is later determined to be exempt based on
information obtained during provider outreach and no initial notification letter was sent.
Response 214: If a Sponsoring organization determines that a potentially at-risk beneficiary is exempt
through the case management process and did not make an at-risk determination pursuant to 42 CFR §
423.153(f) during the universe request period implementing a coverage limitation, the case would be
excluded from the AR universe.
CMS Action 214: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 215: For the Date the Initial Written Notification of potential at-risk status was provided to
enrollee and Date Second Written Notification of At-Risk Determination Provided to Enrollee fields in the
AR record layout, two commenters asked if delivered means when the letter enters the mail stream and a
third commenter asked for clarification on the meaning of delivered. Another commenter asked if the
standard for when the second written notification of an at-risk determination is considered "delivered" is
consistent with the standard for coverage determination notifications, as described in the Parts C & D
Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance, Section 10.5.3.
Another commenter requested that CMS have Sponsoring organizations populate this field with the date
the letter was sent to the vendor for mailing.
Response 215: Policy questions should be directed to the CMS policy mailbox https://appeals.lmi.org.
For program audit purposes, CMS would accept the notification date based on section 10.5.3 of the Parts
C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance.
CMS Action 215: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 216: For the AR record layout, two commenters asked if the Date the at-risk determination
was made field is the date the enrollee was identified as being at-risk or the date the limitation was
entered. Another commenter recommended that CMS expand the field definition to make it clear that
Sponsoring organizations are to populate this field with the date of the beneficiary second notice.
Response 216: The Date the at-risk determination was made field should be populated with the date the
at-risk determination was made, e.g., the date the limitation was entered by the Sponsoring organization.
CMS declines to adopt the suggestion to expand the field definition to include the date of the second
written notification provided to the enrollee as this is currently a separate field in the AR record layout
and could be a different date than when the Sponsoring organization made its at-risk determination.
CMS Action 216: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
PART C ORGANIZATION DETERMINATIONS, APPEALS AND GRIEVANCES (ODAG)
Page 60 of 95
Comment 217: One commenter asked CMS to update its protocol to specify the fields that will be
reviewed during universe integrity testing to “verify [the] accuracy of data.”
Response 217: At a minimum, CMS will verify the accuracy of dates and times provided in each
universe during integrity testing. However, CMS declines to make the change requested by the
commenter. CMS and Sponsoring organizations have occasionally identified issues within fields (other
than those requesting dates and times) that would result in inaccurate timeliness testing results.
Therefore, CMS maintains it needs flexibility in the fields it reviews to verify accuracy of the data that
would be precluded if spelled out in the protocol.
CMS Action 217: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 218: One commenter asked if email notification would be accepted as appropriate notification
if the Sponsoring organization demonstrates the enrollee opted to receive notifications through email.
Response 218: Per 40.12.1 of the Parts C & D Enrollee Grievances, Organization/Coverage
Determinations, and Appeals Guidance, this is acceptable. Sponsoring organizations must be able to
demonstrate when the notification was sent by email.
CMS Action 218: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 219: A commenter had questions regarding electronic submission of requests. This
commenter noted the Audit Field Work Phase – Supporting Documentation list in the ODAG Data
Request does not describe what must be available if a request is submitted through an electronic
submission (i.e. other than fax/mail/email).
Response 219: Sponsoring organizations must be able to demonstrate to CMS all data used to populate
their universes and any related supporting documentation (medical records, letters, etc.) pertaining to a
sample case. If Sponsoring organizations use an electronic system for tracking coverage requests, this
system must be made available to CMS for review during the audit.
CMS Action 219: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 220: One commenter asked if the samples selected for integrity testing will be the same
samples used for review during the processing of coverage requests element of the audit.
Response 220: The samples selected for integrity testing and processing of coverage requests will be
different.
CMS Action 220: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 221: Two commenters asked if CMS intended on sampling approved requests in its Processing
of Coverage Requests review. Both commenters noted CMS did not include approved cases in the
sample selection criteria related to compliance standard 2.1.
Response 221: Beginning in 2021, CMS will no longer review approved requests as part of the Part C
processing of coverage requests audit element.
Page 61 of 95
CMS Action 221: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 222: Two commenters asked if the 30 samples selected for the Processing of Coverage
Requests review, as mentioned in compliance standard 2.1, are comprised of a specific number of cases
from each applicable record layout.
Response 222: There is no specific number of cases that will be selected from each applicable record
layout for the Processing of Coverage Requests review. CMS has updated the method of evaluation for
compliance standard 2.1 to clarify this point.
CMS Action 222: CMS updated the method of evaluation for compliance standard 2.1 to read, “Select 30
denied requests from tables 1-3. The number of cases per record layout will vary. Additionally, select 5
denial cases from Table 6.” No changes were made to the burden estimate in response to these
comments.
Comment 223: One commenter asked if the “up to 15 dismissals” referenced in compliance standard 3.1
represent the total number of dismissed requests selected for sample review or if 15 dismissed requests
will be selected from each record layout for review.
Response 223: CMS clarifies it will select a total sample of 10 dismissed requests, distributed across the
applicable universes, for review.
CMS Action 223: CMS updated the method of evaluation for compliance standard 3.1 to clarify the
number of samples it will select to review dismissed requests. No changes were made to the burden
estimate in response to this comment.
Comment 224: One commenter raised concerns that the regulations cited under column Criteria Effective
1/1/2021 did not correlate to the specific timeliness associated with the compliance standard. For
example, this commenter stated 42 CFR § 422.590(g) is not associated with compliance standard 1.7.
Additionally, this commenter asked CMS to provide further information in the protocols on how auditors
will evaluate “proper notification of a denial decision,” what constitutes whether a "physician or other
appropriate health care professional with sufficient medical and other expertise reviewed the
determination,” and finally, how CMS determines “clinical accuracy” since the method of evaluation uses
the regulation as a source without further clarification.
Response 224: The regulations cited in the Criteria Effective column are cited at a high level within the
subsection. Sponsoring organizations should reference all information within the subsection of the
regulation to identify the specific areas used to test timeliness. We confirm each citation is appropriate
for assessing whether Sponsoring organizations are in compliance with the regulations cited in the
protocols. To determine clinical accuracy, CMS ensures Sponsoring organizations adhere to all National
Coverage Determinations (NCD), Local Coverage Determinations (LCD), and, in the instance no existing
NCD, LCD, or guidance on coverage in original Medicare manuals exist, a Sponsoring organization's
own internal coverage policies. CMS relies on the information a Sponsoring organization received and
reviewed in making its decision to determine compliance.
CMS Action 224: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 62 of 95
Comment 225: One commenter requested CMS update compliance standard 1.5 to account for allowable
extensions for Dual Integrated Special Needs Plans – Applicable Integrated Plans (DSNP-AIPs).
Response 225: CMS thanks the commenter for its suggestion and has updated compliance standard 1.5.
CMS Action 225: CMS updated compliance standard 1.5 to read, “For DSNP-AIPs, the timeliness
assessment will ensure written notification of the upheld reconsideration decision was provided to the
enrollee in addition to being forwarded to the IRE no later than 30 calendar days or 44 days with
extension after receipt of the request.” No changes were made to the burden estimate in response to this
comment.
Comment 226: One commenter asked CMS to share which fields are used to determine timeliness for
compliance standard 1.9. The commenter recommended CMS use the Provider Remittance Advice for
provider submitted claims and the Integrated Denial Notice or Explanation of Payment for enrollee
submitted claims.
Response 226: As previously mentioned, CMS assesses timeliness in accordance with the regulations
specified in the Criteria Effective 01/01/2021 column of the ODAG protocol. The specific fields used in
the timeliness calculation are dependent upon the characteristics of each request, as included in the
PYMT_C universe submission.
CMS Action 226: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 227: Several commenters requested clarification on the Part B Drugs record layout. A few
commenters noted the drug name, strength, and dosage form is not always readily available upon receipt
of a pre-service request. This would prevent Sponsoring organizations from populating this data in the
Part B Drugs record layout. Some commenters noted inconsistencies in, or requested updates to, the field
length value. A few commenters requested CMS update the Type of Request field. Another commenter
requested CMS split the Part B Drugs record layout into two separate record layouts; one for Part B drug
organization determination requests and the other for Part B drug reconsideration requests. A number of
commenters requested CMS add ‘NA’ as an option to field descriptions throughout the ODAG record
layouts to account for situations that do not apply to standard and dismissed requests. A commenter
noted the instructions for the Part B Drug record layout did not specifically tell Sponsoring organizations
to include reconsideration requests in the universe and requested CMS update the instruction language to
account for this. One commenter asked why CMS would not want to capture the time a letter is generated
or printed for Part B drug requests. One commenter noted that, as a delegate, they would not always have
access to Step Therapy requirements applied at the point of sale. Finally, a few commenters asked if the
Part B drug timeframes apply to requests submitted as part of a related office visit, home infusion, or
durable medical equipment request. One of these commenters expressed concern about the programming
challenges that would be required to include portions of a pre-service request in one record layout (i.e. the
OD or RECON record layouts) and the remainder in a separate layout specific to Part B drugs.
Response 227: In light of the numerous comments received, CMS removed the Part B Drugs record
layout from its data request and incorporated its data request for pre-service Part B drug organization
determination and reconsideration requests into the OD and RECON record layouts, respectively. CMS
did not include the following fields as part of this change: NDC; Drug Name, Strength, and Dosage
Form; and, Was Step Therapy Applied to this Request. However, we modified the description of existing
fields in the OD and RECON record layouts to account for this merger and added a new field.
Specifically, in order to assess the new Part B drug timeframes, CMS added a new field in both the OD
and RECON record layouts named, Part B Drug Request?. Sponsoring organizations must indicate if the
Page 63 of 95
pre-service request was for a Part B drug (whether primary or ancillary) using this field. When a
Sponsoring organization indicates the request was for a Part B drug, CMS will ensure Sponsoring
organizations are adhering to the Part B drug timeframe regulations effective January 1, 2020.
Sponsoring organizations should contact the CMS policy mailbox https://appeals.lmi.org/ with any
questions pertaining to these Part B drug rules.
CMS Action 227: CMS removed the Part B Drugs record layout from the ODAG data request and
removed all references to this record layout from the compliance standards within the ODAG protocol.
CMS also updated the instructions for the OD record layout to “Include all pre-service organization
determination requests for Part B drugs” and updated the instructions for the RECON record layout to
“Include all pre-service reconsideration requests for Part B drugs.” CMS then made corresponding
updates to existing field descriptions within the OD and RECON record layouts, as described in the
crosswalk, and added a Part B Drug Request? field to these record layouts for Sponsoring organizations
to specify whether the request was for a Part B drug to accommodate the removal of the Part B Drugs
record layout from the ODAG data request. No changes were made to the burden estimate in response to
these comments.
Comment 228: Two commenters asked about CMS’ expectations for populating the Part B Drugs record
layout. One commenter asked if the Part B Drugs record layout is inclusive of only Part B drugs or will it
also include Part B products typically processed through the pharmacy benefit such as blood glucose
monitoring supplies and Euflexxa? The other commenter also asked if pre-service requests for Part B
drugs that also include an office visit would be populated in the Part B Drugs record layout, or in the OD
or RECON record layouts.
Response 228: As previously mentioned, CMS removed the Part B Drugs record layout from the ODAG
data request. Sponsoring organizations should include all pre-service requests for Part B drugs, including
Part B products, or requests for Part B drugs that also include an office visit, in either its OD or RECON
universe submissions. All post-service requests for payment should be included in the PYMT_C universe
submission. As previously mentioned, CMS added a new Part B Drug Request? field to the OD and
RECON record layouts, wherein Sponsoring organizations must indicate if the pre-service request was for
a Part B drug (whether primary or ancillary) using this field.
CMS Action 228: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 229: One commenter asked if both Point-of-Sale and Buy and Bill (J-codes) should be
included in Sponsoring organizations’ Part B Drugs universe submission. A separate commenter asked if
Part B drugs rejected at the point of sale should be included in Sponsoring organizations’ Part B Drugs
universe submission.
Response 229: As previously mentioned, CMS has removed the Part B Drugs record layout from the
ODAG data collection. However, CMS expects Sponsoring organizations to include all requests that
have been approved, denied, or dismissed for Part B drugs in the appropriate record layouts. Specifically,
pre-service requests for Part B drugs should be included in either the OD or RECON universe
submissions and post-service requests for Part B drugs should be included in the PYMT_C universe
submission. Sponsoring organizations should not include Part B drugs denied at the point-of-sale in any
ODAG universe submission, as these do not meet the definition of an organization determination.
CMS Action 229: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Page 64 of 95
Comment 230: A commenter asked if payment requests submitted by an enrollee for Part B drugs that
also have a prior authorization requirement should be treated as both a payment organization
determination request and a Part B drug organization determination request. Specifically, the commenter
asked if in addition to the payment request, whether Sponsoring organizations are required to review the
Part B drug request for continued use as well.
Response 230: In this instance, Sponsoring organizations should only enter the request for payment
organization determination in the PYMT_C record layout. For policy clarification related to reviewing
Part B drugs for continued use when a payment request is received, please contact the policy mailbox
https://dpapportal.lmi.org/dpapmailbox/.
CMS Action 230: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 231: One commenter asked if pre-service requests that include multiple procedures should be
included in the OD and RECON record layouts if not all determination dates fall within the universe
request period.
Response 231: Sponsoring organizations should not include pre-service requests in its OD and RECON
universe submissions if all determination dates associated with the request do not fall within the universe
timeframe.
CMS Action 231: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 232: One commenter asked which type of services should be excluded from the OD, RECON
and PYMT_C record layouts based on the instruction to “Exclude all requests for Value Added Items and
Services.”
Response 232: CMS refers Sponsoring organizations to Chapter 4 Benefits and Beneficiary Protections,
Section 80, of the Medicare Managed Care Manual, for guidance on the Value Added Items and Services
that are to be excluded from the ODAG universe submissions.
CMS Action 232: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 233: One commenter asked if Common Procedural Codes (CPTs) and Healthcare Common
Procedure Coding System codes (HCPCS) could be used in the Issue Description and Type of Service
field throughout the ODAG record layouts.
Response 233: CMS believes, based on additional feedback we have received from multiple Sponsoring
organizations, that allowing CPTs, HCPCs, National Drug Code (NDC), and/or Durable Medical
Equipment (DME) numbers may be more burdensome at this time. Therefore, we decline to make this
change.
CMS Action 233: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 234: One commenter noted the additional programming requirements that are necessary to
populate ‘NA’ or ‘None’ in the time field for standard and dismissed requests within the combined record
Page 65 of 95
layouts. This commenter asked if CMS would allow sponsoring organizations to populate the time field
for standard and dismissed requests in place of ‘NA’ or ‘None.’
Response 234: CMS appreciates the suggestion and agrees with the commenter. Sponsoring
organizations always have the option to enter the time even if it is not required per the field descriptions.
CMS Action 234: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 235: Several commenters requested clarification and updates to the description for the
AOR/Equivalent Written Notice Receipt Date and AOR/Equivalent Written Notice Receipt Time (where
applicable) fields in the following record layouts: OD; RECON; PYMT_C; GRV_C; Part B Drugs; and,
AIP. Most commenters asked CMS to streamline the use of NA and None for dismissed requests within
these field descriptions. One commenter noted the use of ‘NA’ twice in the same description field for
different reasons. Two commenters asked for guidance on the appropriate response (‘NA’ or ‘None’) in
this field for dismissed requests since both responses are applicable. One commenter noted how AOR
receipt date in the Part B Drugs record layout did not include ‘NA’ or ‘None’ as an option for standard
and dismissed requests.
Response 235: As previously mentioned, CMS agrees these field descriptions could be updated for
simplicity and consistency purposes. Thus, we have removed ‘NA’ and ‘NF’ as valid responses
throughout the field descriptions in the remaining ODAG record layouts, inclusive of the AOR/Equivalent
notice Receipt Date and AOR/Equivalent notice Receipt Time fields, and removed the Part B Drugs record
layout entirely. Sponsoring organizations can enter None in these fields when no AOR or equivalent
written notice was received, when an AOR or equivalent written notice was not required, and for
dismissed cases when applicable.
CMS Action 235: CMS removed the ‘NA’ and ‘NF’ option from the descriptions of the AOR/Equivalent
notice Receipt Date and AOR/Equivalent notice Receipt Time fields in the following record layouts: OD;
RECON, PYMT_C; GRV_C; and, AIP. CMS updated the field descriptions to allow Sponsoring
organizations to enter ‘None’ when no AOR or equivalent written notice was received, when an AOR or
equivalent written notice was not required, and for dismissed cases when applicable. Finally, as
mentioned above, CMS removed the Part B Drugs record layout from the ODAG data request. No
changes were made to the burden estimate in response to these comments.
Comment 236: One commenter noted inconsistent field lengths for Request Determination field in the
RECON, PYMT_C, and Part B Drugs record layouts. The commenter noted that, in all instances, the
maximum field length value would be 9 characters.
Response 236: CMS agrees. We have updated the field length in the RECON and PYMT_C record
layouts for the Request Determination field to 9 characters. As previously mentioned, CMS removed the
Part B Drugs record layout from the ODAG data request.
CMS Action 236: CMS updated the field length of the Request Determination field in the RECON and
PYMT_C record layouts to 9 characters. For consistency, CMS also updated the field length of
equivalent field, Request Disposition, in the AIP record layout to limit this field to 9 characters.
Comment 237: Several commenters requested clarification and updates to the description of the
following fields: Date written notification provided to enrollee; Time written notification provided to
enrollee; Date oral notification provided to enrollee; and Time oral notification provided to enrollee, that
are found in the following ODAG record layouts: OD; RECON; PYMT_C; GRV_C; Part B Drugs; and,
Page 66 of 95
AIP. Two commenters asked CMS to include the option ‘NA’ to account for standard requests, dismissed
requests, and/or enrollee notification of upheld reconsideration requests (where applicable). One
commenter requested CMS use the word “delivered” instead of “provided” to reflect language in the Parts
C & D Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance. One
commenter noted CMS’ use of the word ‘attempted’ in the description field for oral notification implies
good faith attempts were an acceptable form of notification. One commenter asked CMS to provide a
response of ‘None’ if oral notification was not provided in the OD record layout. One commenter noticed
the use of the word ‘date’ in the language for the Time the request was received field description in the
OD and RECON record layouts.
Response 237: CMS agrees more clarification is needed in the description of the following fields found
in each ODAG record layout: Date written notification provided to enrollee; Time written notification
provided to enrollee; Date oral notification provided to enrollee; and, Time oral notification provided to
enrollee. To clarify these field descriptions, CMS has removed the language that was inadvertently
included in the OD and AIP record layouts that described when a notice is considered delivered;
Sponsoring organizations should refer to 10.5.3 of the Parts C & D Enrollee Grievances,
Organization/Coverage Determinations, and Appeals Guidance for more information on when a notice is
considered delivered. Finally, CMS removed ‘NA’ and ‘NF’ as valid responses in these fields and
updated each of these field descriptions to allow for ‘None’ as a response when applicable.
CMS Action 237: CMS updated the description field of the following field names in each ODAG record
layout: Date written notification provided to enrollee; Time written notification provided to enrollee;
Date oral notification provided to enrollee; and Time oral notification provided to enrollee. No changes
were made to the burden estimate in response to these comments.
Comment 238: Two commenters requested clarification on the inclusion of supplemental services in the
following record layouts: OD; RECON; and, PYMT_C. First, two commenters noted the following
language was included twice in the instructions for the OD record layout: “Include all pre-service requests
for supplemental services that meet the criteria defined in Chapter 4, Section 30.1.” Next, this same
commenter wanted to confirm that both pre- and post-service requests for supplemental services that have
been approved, denied, or dismissed should be included in the OD record layout. Finally, another
commenter asked CMS to reference the regulation in place of manual guidance.
Response 238: CMS thanks both commenters. Sponsoring organizations should include all requests for
supplemental services that have been approved, denied, or dismissed. Furthermore, we have removed the
duplication of the instructions and agree with the commenter regarding inclusion of the regulation over
the manual. Additionally, we have updated the instructions for the RECON and PYMT_C record layouts
to mirror these changes in the OD record layout.
CMS Action 238: CMS removed the duplicate instruction related to pre-service requests for
supplemental services from the OD record layout. Additionally, CMS updated the instructions for the OD
and RECON record layouts to read, "Include all pre-service requests for supplemental services that meet
the criteria defined at 42 CFR § 422.100(c)(2).” Finally, CMS updated the instructions for the PYMT_C
record layout to read, "Include all payment requests for supplemental services that meet the criteria
defined at 42 CFR § 422.100(c)(2).” No changes were made to the burden estimate in response to these
comments.
Comment 239: One commenter asked CMS to allow for an option for dismissed requests in the Time
reconsidered determination effectuated in the system field description of the RECON record layout.
Page 67 of 95
Response 239: CMS agrees and has added language to the description field to account for dismissed
requests.
CMS Action 239: CMS updated the description field to read, “Enter None for standard cases, dismissed
cases, or if the request was denied.” No changes were made to the burden estimate in response to this
comment.
Comment 240: One commenter asked CMS to include ‘NA’ as an option in the Was the request denied
for lack of medical necessity? field in the RECON record layout. The commenter made this request
because they do not feel this question is applicable to approved requests. Another commenter asked CMS
if they can consider this field a new requirement.
Response 240: CMS clarifies that this field is not a new requirement. In regard to the initial commenter,
CMS is unsure if the commenter is referring to approved organization determination requests or to
approved reconsideration requests. In either case, CMS reminds the commenter that the RECON record
layout is to be populated with reconsideration requests of denied organization determinations. Therefore,
each request for reconsideration in this universe, whether the reconsideration was ultimately approved,
denied, or dismissed, would have had an initial denial of which some may be denied for lack of medical
necessity. Sponsoring organizations must indicate whether or not the initial organization determination
was denied for lack of medical necessity and select the appropriate response in this field.
CMS Action 240: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 241: One commenter noted the character count for Was the request denied for lack of medical
necessity? field in the RECON record layout was 2 when an appropriate response would only require 1
character.
Response 241: CMS agrees. We have reduced the field length for the Was the request denied for lack of
medical necessity? field in the RECON record layout from 2 characters to 1 character.
CMS Action 241: CMS reduced the field length for the Was the request denied for lack of medical
necessity? field in the RECON record layout from 2 characters to 1 character. No changes were made to
the burden estimate in response to this comment.
Comment 242: A commenter requested CMS allow for a response of ‘NA’ in the Was the request denied
for lack of medical necessity? field in the Part B Drugs record layout if the case was dismissed. This
commenter identified that ‘NA’ was allowable in the OD and PYMT_C record layouts. Additionally,
another commenter asked if this field in the PYMT_C record layout should be populated based on the
initial decision, as described in the RECON record layout.
Response 242: As previously mentioned, CMS has removed the Part B Drugs record layout from the
ODAG data request in its entirety. Additionally, CMS has replaced the use of ‘NA’ with ‘None’ in the
applicable field descriptions throughout the ODAG record layouts, including the Was the request denied
for lack of medical necessity? field in the OD and PYMT_C record layouts. Finally, CMS confirms the
response for this field in the PYMT_C record layout is based on the initial decision. We have updated the
field name for clarity.
CMS Action 242: CMS updated the Was the request denied for lack of medical necessity? field name to ,
Was the initial organization determination request denied for lack of medical necessity in the PYMT_C
record layout. No changes were made to the burden estimate in response to these comments.
Page 68 of 95
Comment 243: Two commenters presented scenarios asking CMS whether or not each scenario would be
defined as a denial for lack of medical necessity. Both commenters asked if lack of medical necessity is
applicable to situations where a request for a Part B drug was denied because an enrollee did not meet
step therapy requirements.
Response 243: CMS does not define lack of medical necessity for program audit purposes. Sponsoring
organizations should use their definition of medical necessity to populate this field.
CMS Action 243: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to these comments.
Comment 244: A few commenters asked if contract provider claims are excluded from the PYMT_C
record layout and, if so, in instances of approved claims, this commenter asked if Sponsoring
organizations should include claims from enrollees challenging copay/coinsurance amounts on approved
claims to contract providers.
Response 244: Beginning in 2021, CMS will no longer require Sponsoring organizations to include
contract provider claims in the PYMT_C record layout. However, payment requests from enrollees who
are challenging copay/coinsurance amounts related to contract providers are considered enrollee
submitted claims and must be included in Sponsoring organizations’ PYMT_C universe submissions.
CMS Action 244: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 245: One commenter asked CMS to confirm if Sponsoring organizations should include Part B
drug claims in the PYMT_C record layout. This commenter noted the PYMT_C record layout did not
align with the standard NCPDP claim layout. For this reason, one could assume CMS did not wish to
collect pharmacy claims or DMRs. Additionally, this commenter pointed out that the Part B Drugs record
layout includes an NDC field and a Drug Name, Strength, and Dosage Form field whereas the PYMT_C
record layout does not. This commenter asked CMS to be explicit in stating whether or not Sponsoring
organizations should include pharmacy claims and DMRs in its PYMT_C universe submission.
Response 245: Per the instructions for the PYMT_C record layout, Sponsoring organizations should
include all payment organization determinations and payment reconsiderations that Sponsoring
organizations approved, denied, or dismissed from non-contract providers and enrollees. CMS has
consistently collected data in this format for program audit purposes. CMS has added language to the
instructions to the PYMT_C record layout which now clarify that pharmacy claims for Part B drugs
submitted to an organization’s Medicare Advantage (MA) line of business should be included in its
PYMT_C universe submission.
CMS Action 245: CMS updated the instructions for the PYMT_C record layout to include pharmacy
claims. No changes were made to the burden estimate in response to this comment.
Comment 246: One commenter suggested CMS add more to the list of exclusions in the instructions for
the PYMT_C record layout. This commenter suggested CMS add exclusions that do not require the case
to be decided on its merits such as worker compensation claims or untimely filing. They also suggested
CMS include an additional field that indicates whether or not a claim was denied for administrative
reasons.
Page 69 of 95
Response 246: CMS appreciates the suggestion. At this time, CMS believes it will be more burdensome
for all Sponsoring organizations to implement this change prior to the start of the 2021 audit year. We
will take it under consideration in a future collection request.
CMS Action 246: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 247: One commenter asked CMS to provide a definition of the term “payment adjustment.”
This commenter asked if corrected claims submitted by providers and processed by Sponsoring
organizations as payment adjustments met CMS’ definition of a payment adjustment, or if a payment
change made for other reasons was considered a payment adjustment.
Response 247: For program audit purposes, Sponsoring organizations should exclude adjustments that
have been made to any previously approved or paid claims. However, CMS would expect to see the
claim, prior to any adjustment, included in the PYMT_C record layout if the claim was paid during the
universe request period.
CMS Action 247: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 248: Two commenters noted the instructions for the PYMT_C record layout did not include
information on how Sponsoring organizations should populate this universe with payment reconsideration
requests.
Response 248: CMS appreciates this being brought to our attention. We have added additional
instructions to the PYMT_C record layout to account for inclusion of payment reconsideration requests.
CMS Action 248: CMS updated the instructions for the PYMT_C record layout to include the following
language; “Submit payment reconsiderations based on the date the overturned reconsideration was paid
or, for upheld reconsiderations, submit based on the date the case was forwarded to the IRE.” No changes
were made to the burden estimate in response to this comment.
Comment 249: One commenter asked if CMS expects Sponsoring organizations to include requests that
are both untimely and pending a decision in their PYMT_C universe submission.
Response 249: CMS is not instructing Sponsoring organizations to include cases that are both untimely
and pending within any of their ODAG universe submissions. Sponsoring organizations must populate
each record layout according to the instructions for that specific universe.
CMS Action 249: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 250: One commenter asked if partially denied claims should be treated as denied for purposes
of populating the PYMT_C record layout.
Response 250: CMS confirms that partially denied claims should be entered as denied within Sponsoring
organizations’ PYMT_C universe submission.
CMS Action 250: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 70 of 95
Comment 251: One commenter recommended CMS create a new field in the PYMT_C record layout to
capture the date a request for payment organization determination (i.e. claim) is received. The commenter
requested CMS add this new field because the current field description for Date the request was received
includes language pertaining to good cause which the commenter noted only applies to reconsiderations.
Response 251: CMS disagrees that a new field in the PYMT_C record layout is necessary. The field
description instructs Sponsoring organizations to enter the date the payment request was received, which
would include both claims and payment reconsideration requests. CMS agrees the good cause language
in the field description is applicable only to payment reconsideration requests.
CMS Action 251: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 252: Two commenters asked for clarification on time limits when applying good cause
exceptions for late filing. One commenter asked how long after the closure of the appeal timeframe
Sponsoring organizations can allow for late filing if good cause is granted. The other commenter asked,
based on a lack of description language in the applicable field of the Part B Drugs record layout, if good
cause exceptions are allowed for Part B drug requests.
Response 252: For policy clarification, Sponsoring organizations should reference the Parts C & D
Enrollee Grievances, Organization/Coverage Determinations, and Appeals Guidance (effective January 1,
2020) or contact the CMS policy mailbox https://appeals.lmi.org.
CMS Action 252: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 253: A few commenters asked for clarification on the Was it a clean claim field in the
PYMT_C record layout. One commenter asked if CMS’ timeliness test would be performed on enrollee
submitted claims. Two commenters asked CMS to provide a response in the field description for
populating this field with reconsiderations. One commenter asked if the collection of clean claims is a
new requirement. One commenter noted CMS does not account for the 30-day window for clean claims
from providers in the timeliness testing for compliance standard 1.9.
Response 253: CMS appreciates the comments. We have made an update to the field description for Was
it a clean claim. Sponsoring organizations should enter ‘None’ for reconsiderations. In addition,
Sponsoring organizations should not consider this a new requirement as CMS has consistently collected
this information and tested timeliness on enrollee submitted claims. Finally, although the prompt pay
provisions located at 42 CFR § 422.520 would apply, CMS Program Audits test all post-service
organization determinations (claims and payment reconsiderations) against a 60-day standard but notes
this standard is specific to CMS Program Audits only.
CMS Action 253: CMS added, “None for payment reconsiderations” as an option in the Was it a clean
claim? field description in the PYMT_C record layout. CMS also increased the field length value from 2
to 4 to accommodate this change. No changes were made to the burden estimate in response to these
comments.
Comment 254: One commenter inquired about unclean claims received from enrollees and providers.
This commenter asked if they should populate the Date the request was received field in the PYMT_C
record layout with the date of receipt of the unclean claim, or, if they should populate this field with the
date of receipt of the information needed to pay the claim.
Page 71 of 95
Response 254: Sponsoring organizations should populate this field with the date the initial claim was
received.
CMS Action 254: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 255: One commenter asked what should be populated in the Date claim was paid field in the
PYMT_C record layout if a provider is in recoupment of payment status. This commenter also asked if
these claims should be included in the universe submission if no payment has been made. Another
commenter asked what should be populated in this field if the enrollee is still within their deductible and
no payment is made on the approved claim.
Response 255: The PYMT_C record layout instructs Sponsoring organizations to include all payment
organization determinations and payment reconsiderations that were approved, denied or dismissed. It
does not exclude requests based on whether or not a sponsoring organization made a payment or sent a
denial notification. In the scenarios presented, Sponsoring organizations may enter the date of the
Explanation of Payment (EOP), the Explanation of Benefits (EOB), a zero pay check, or the date of
notification a Sponsoring organization sent to the provider or enrollee that explains the status of the claim.
CMS Action 255: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 256: One commenter asked CMS to remove ‘None’ as an option from the Date the claim was
paid field description within the PYMT_C record layout because approved claims would always generate
a claim paid date.
Response 256: CMS declines to make this change. As previously mentioned, all instances of ‘NA’ in the
ODAG record layouts have been replaced with ‘None,’ and per the record layout instructions, characters
are always required in this field. ‘None’ is a necessary option in instances the payment request was either
denied or dismissed.
CMS Action 256: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 257: One commenter asked CMS to include ‘PENDING’ as an option in the Date written
notification provided to enrollee field description of the PYMT_C record layout to account for instances
where enrollee notification has not occurred but will be in a forthcoming EOB.
Response 257: CMS appreciates the comment but declines to make this change. Sponsoring
organizations may enter ‘None’ if an enrollee will be notified in a forthcoming EOB, as notification has
not occurred at the time of universe submission.
CMS Action 257: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 258: One commenter asked what date should be populated in the Date written notification
provided to provider field in the PYMT_C record layout when a Sponsoring organization approves a
payment reconsideration request. For instance, should the Sponsoring organization enter the date of the
Explanation of Payment (EOP) and/or the date of the payment (which would be redundant information
Page 72 of 95
already collected in the Date claim/reconsideration was paid field), or should Sponsoring organizations
enter the date of the reconsideration decision letter.
Response 258: For approved payment reconsideration requests, Sponsoring organizations may enter the
date the payment was made (either put into the mail stream or, for electronic payments, transferred the
funds for payment), the date of the EOP, the date of the reconsideration decision letter, or enter ‘None’ if
no notification was sent to the provider.
CMS Action 258: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 259: A few commenters noted that payment organization determinations are not required to be
sent to the IRE and the Date Forwarded to IRE field in the PYMT_C record layout should only apply to
reconsiderations. This commenter asked CMS to identify where in the regulation it states payment
organization determinations must go to the IRE.
Response 259: CMS agrees with the commenter that adverse payment organizations determinations are
not required to be sent to the IRE, and notes that CMS does not deviate from the regulations in 42 CFR §
422 Subpart M. Sponsoring organizations are able to select if the request was an organization
determination (OD) or a reconsideration (recon) in the Was the request processed as an OD or a Recon?
Field. If OD is selected, CMS will not test whether the request was forwarded to the IRE. As previously
mentioned, CMS removed ‘NF’ as an option within this field description and Sponsoring organizations
may now enter ‘None’ in this field for payment organization determination requests.
CMS Action 259: CMS updated the description for the Date forwarded to the IRE field to read, “Enter
the date the reconsideration request was forwarded to the IRE. Submit in CCYY/MM/DD format (e.g.,
2020/01/01). Enter None for organization determination requests, or if the reconsideration request was
approved, dismissed, or not forwarded to the IRE.” No changes were made to the burden estimate in
response to these comments.
Comment 260: One commenter asked for clarification on the Date of determination field in the
PYMT_C record layout. This commenter asked if CMS expects this field to be populated with the date of
the pre-service decision or the appeal decision, depending on case type, or the date the claim is processed
in the system for claim payment or denial. Additionally, this commenter asked if the request was denied
for medical necessity, should the Date of determination field be populated with the date of the medical
director’s decision.
Response 260: Universes submitted in accordance with the PYMT_C record layout instructions should
be limited to post-service coverage requests only. CMS does not expect Sponsoring organizations to
populate this field, or any field within this table, with pre-service data related to the request. For program
audit purposes, Sponsoring organizations should populate the Date of determination field with the date
the Sponsoring organization recorded as the decision date. This could be either the date the medical
director made its decision or the date the medical director’s decision was recorded in the system, as
supported by appropriate documentation.
CMS Action 260: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 261: One commenter recommended CMS allow Sponsoring organizations to use the date a
claim was processed as the date the claim was paid in the PYMT_C record layout.
Page 73 of 95
Response 261: CMS disagrees. The Date the claim was paid field should be populated with date the
Sponsoring organization placed a check into the mail or for electronic payments (i.e., EFTs), the date the
Sponsoring organization or its delegate (if applicable) distributed the funds for payment.
CMS Action 261: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 262: One commenter suggested that CMS’ request for Sponsoring organizations to provide an
explanation of why the initial Part B drug request resulted in a denial is a new requirement. This
commenter mentioned Sponsoring organizations would have to develop a process for tracking this.
Response 262: CMS does not understand why the commenter believes this is a new requirement when
CMS has consistently collected denial rationale in its program audit data requests. While CMS has made
updates to the RECON and PYMT_C record layouts to better align its ODAG data collection with CDAG
record layouts, CMS does not view this as a new requirement.
CMS Action 262: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 263: Two commenters noted the Issue description and type of service field in the PYMT_C
record layout stated, “For denials, also provide an explanation of why the pre-service request was
denied.” This commenter believes this should field should state why the payment request was denied.
Response 263: CMS agrees with the commenter and updated the field description.
CMS Action 263: CMS updated the Issue description and type of service field description in the
PYMT_C record layout to read, “For denials, also provide an explanation of why the payment
organization determination or payment reconsideration request was denied.” No changes were made to
the burden estimate in response to these comments.
Comment 264: One commenter asked if ALJ cases arising from QIO determinations of denied discharges
should be included in the EFF_C record layout.
Response 264: ALJ cases arising from QIO determinations of denied discharges should not be included
in Sponsoring organizations’ EFF_C universe submissions.
CMS Action 264: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 265: A commenter asked if grievances expressed via a live chat-box should be classified as
oral or written within their GRV_C universe submission.
Response 265: For program audit purposes, Sponsoring organizations may consider these oral requests.
For more information pertaining to these requests, please contact the CMS policy mailbox
https://appeals.lmi.org.
CMS Action 265: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 266: One commenter identified the field length of the Enrollee ID field in the GRV_C record
layout allows for 20 characters, whereas all other record layouts only allow for 11 characters in this field.
Page 74 of 95
Response 266: CMS appreciates the commenter bringing this to our attention. We have updated the field
length of the Enrollee ID field in the GRV_C record layout to mirror all other ODAG record layouts.
CMS Action 266: CMS reduced the field length value from 20 characters to 11 characters in the Enrollee
ID field in the GRV_C record layout. No changes were made to the burden estimate in response to this
comment.
Comment 267: Two commenters noted the GRV_C record layout still used the Plan ID field name while
all other ODAG record layouts have changed to Plan Benefit Package (PBP). One commenter also
identified the description for this same field in the AIP record layout reads, “The PBP (e.g., 001) of the
organization” instead of “Enter the PBP (e.g., 001).”
Response 267: CMS appreciates the comment. We have updated the GRV_C and AIP record layouts to
align with all other ODAG record layouts.
CMS Action 267: CMS replaced the Plan ID field name with Plan Benefit Package (PBP). In addition,
CMS updated the Plan Benefit Package (PBP) field description to read, "Enter the PBP (e.g. 001)." No
changes were made to the burden estimate in response to these comments.
Comment 268: One commenter believes the Date oral response provided to enrollee and Time oral
response provided to enrollee fields in the GRV_C record layout should allow ‘NA’ as a response for
both standard and dismissed grievances.
Response 268: CMS disagrees with the commenter. As previously mentioned, CMS updated “response”
to “notification” in the GRV_C record layout. The Date oral notification provided to enrollee field is
needed for both standard and expedited grievances. Additionally, as previously mentioned, CMS has
excluded dismissed grievances from the GRV_C record layout, as well as removed ‘NA’ as an option
within the field descriptions. CMS has updated the field descriptions to allow Sponsoring organizations
to enter ‘None’ for standard grievances in the Time oral notification provided to enrollee field.
CMS Action 268: CMS updated the description of the Time oral notification provided to enrollee field in
the GRV_C record layout to read, “Enter None for standard grievances or if no oral notification was
provided.” No changes were made to the burden estimate in response to this comment.
Comment 269: One commenter requested CMS update the name of the AIP record layout to include
“organization determinations.” This commenter noted the current name only specifies reconsiderations.
Response 269: CMS understands the commenter’s request but declines to make this exact change.
Instead, CMS renamed the record layout and updated the instructions to clarify that this record layout is
specific to integrated organization determination cases where a previously approved service is being
reduced, suspended, or terminated by the DSNP-AIP. CMS maintains that the date of the DSNP-AIP
Integrated Denial Notification (Column ID G) must fall within the universe request period.
CMS Action 269: CMS updated the AIP table name and instructions. No changes were made to the
burden estimate in response to this comment.
Comment 270: One commenter asked if DSNP-AIPs should exclude all reductions, terminations, or
suspensions that are included in the AIP record layout.
Page 75 of 95
Response 270: CMS is not certain what the commenter is asking. Per the instructions, the AIP record
layout should be populated with all integrated organization determinations the DSNP-AIPs notified
enrollees would be terminated, suspended, or reduced during the universe request period.
CMS Action 270: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 271: Two commenters noted the use of the term ‘member’ in the AIP record layout. These
commenters asked CMS to update the AIP record layout to align with terminology in the other ODAG
record layouts and use the term ‘enrollee’ instead.
Response 271: CMS agrees with the commenters. We have updated the AIP record layout to align with
all other ODAG record layouts.
CMS Action 271: CMS updated the term ‘member’ to ‘enrollee’ throughout the AIP record layout. No
changes were made to the burden estimate in response to these comments.
Comment 272: One commenter asked CMS to update the description of the Contract ID field in the AIP
record layout to mirror the other ODAG record layouts which state, “Enter the contract number (e.g.
H1234).”
Response 272: CMS agrees and has made the update to the Contract ID field description in the AIP
record layout.
CMS Action 272: CMS updated the Contract ID field description to read, “Enter the contract number
(e.g. H1234).” No changes were made to the burden estimate in response to this comment.
Comment 273: One commenter asked CMS to update the description of the First Tier, Downstream, or
Related Entity field in the AIP record layout to mirror the other ODAG record layouts.
Response 273: CMS agrees and has updated the First Tier, Downstream, or Related Entity field
description, and moved the field from Column ID Z to Column ID F, to mirror other record layouts.
CMS Action 273: CMS updated the description of the First Tier, Downstream, or Related Entity field to
read, “Enter the name of the First Tier, Downstream, and Related Entity (which is any party that enters
into a written arrangement, acceptable to CMS, with the Sponsoring organization to provide
administrative or health care services to an enrollee under the Part C or D program) that processed the
request. Enter None if the Sponsoring organization processed the request.” CMS also moved the First
Tier, Downstream, or Related Entity field from column ID Z to column ID F. No changes were made to
the burden estimate in response to this comment.
Comment 274: A commenter identified the field length value for Was the decision appealed? field in the
AIP record layout did not account for the response ‘NA.’ The field length value allowed for 1 character.
Additionally, this commenter asked CMS to identify which fields should be populated with ‘NA’ within
the AIP record layout if the decision was not appealed.
Response 274: CMS agrees with the commenter. As previously mentioned, CMS now allows for a
response of ‘None’ instead of ‘NA.’ Therefore, we have updated the field length value to account for this
change. Additionally, CMS has added language to the field description in each of the applicable fields
that should be populated with ‘None’ if a decision was not appealed.
Page 76 of 95
CMS Action 274: CMS updated the Was the decision appealed? field length in the AIP record layout to
4. Additionally, CMS updated the descriptions in the AIP record layout to allow for a response of ‘None’
when no further data applicable to that case is required in the submitted universe.
Comment 275: A commenter noted the Was the request processed as standard or expedited field length
value in the AIP record layout is ‘1.’ However, instructions within the field description ask Sponsoring
organizations, when applicable, to populate this field with ‘NA’ which would require a field length value
of ‘2.’
Response 275: CMS agrees that an update to the Was the request processed as standard or expedited
field length value in the AIP record layout needs to be updated to accommodate all acceptable responses
outlined in the description. As previously mentioned, all instances of ‘NA’ in the ODAG record layout
field descriptions have been updated to ‘None.’ Therefore, CMS increased the field length for the Was
the request processed as standard or expedited field in the AIP record layout from 1 character to 4
characters.
CMS Action 275: CMS increased the Was the request processed as standard or expedited field length
value in the AIP record layout from 1 character to 4 characters. No changes were made to the burden
estimate in response to this comment.
Comment 276: One commenter noted the allowance of ‘NA’ in the Was a timeframe extension taken?
field description in the AIP record layout. This commenter noted no other record layout within the
ODAG data request allowed for the use of ‘NA’ in this field and asked CMS to update the field to mirror
the other record layouts.
Response 276: CMS declines to make this change. As previously noted, CMS removed the use of ‘NA’
throughout the ODAG record layouts. Sponsoring organizations may now enter ‘None.’ This will remain
as an option in the Was a timeframe extension taken? field description in the AIP record layout because
there may be instances when an enrollee does not elect to appeal a Sponsoring organization’s decision to
reduce, suspend, or terminate a service. Sponsoring organizations should use ‘None’ in these instances
per the Was the Decision Appealed? field description.
CMS Action 276: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 277: One commenter requested clarification on when ‘NA’ would be an appropriate response
in the Did the enrollee request continuation of benefits? field in the AIP record layout. This commenter
said a ‘yes’ or ‘no’ response should suffice.
Response 277: CMS agrees more clarification is needed. As a reminder, CMS removed ‘NA’ from the
ODAG record layouts. In this instance, Sponsoring organizations should enter ‘Y’ for yes or ‘N’ for no,
if the enrollee him or herself requested continuation of benefits. However, Sponsoring organizations
should enter ‘None’ if someone other than the enrollee requested continuation of benefits.
CMS Action 277: CMS updated the Did the enrollee request continuation of benefits field description in
the AIP record layout for additional clarity. No changes were made to the burden estimate in response to
this comment.
Comment 278: One commenter believes the Date of DSNP-AIP decision field and the If request denied,
date services were terminated, reduced, suspended field in the AIP record layout are duplicative.
Page 77 of 95
Response 278: CMS thanks the commenter for bringing this to our attention. We have updated the If
request denied, date services were terminated, reduced, suspended field description in the AIP record
layout for additional clarity.
CMS Action 278: CMS updated the If request denied, date services were terminated, reduced, suspended
field description to read, “Enter the date the services were terminated, reduced, suspended. Submit in
CCYY/MM/DD format (e.g., 2020/01/01). Enter None if the decision was not appealed as indicated by N
in column ID J.” No changes were made to the burden estimate in response to this comment.
SPECIAL NEEDS PLAN CARE COORDINATION (SNPCC)
Comment 279: One commenter requested clarification of data definitions and timeframes. The
commenter also recommended that CMS sync its audit of Model of Care (MOC) elements with review
requirements and scoring guidelines of the Model of Care as conducted by NCQA under contract with
CMS.
Response 279: As described in greater detail below, we have clarified the universe data collection
definitions and timeframes. However, we are unsure what the commenter is suggesting in regard to
syncing the program audit review of the MOC elements during the program audit with review
requirements and scoring guidelines of the MOC as conducted by NCQA. CMS clarifies the purpose of
this program audit is different from NCQA’s process for scoring MOCs, and this protocol is intended to
evaluate a Sponsoring organization’s implementation of its MOC, as approved by NCQA.
CMS Action 279: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 280: Several commenters requested that CMS confirm that the Plan Performance Monitoring
and Evaluation universe is not collected or evaluated in the proposed SNPCC protocol. One commenter
asked whether CMS is no longer interested in measurement metrics, SNP meeting notes, corrective action
plans, etc., since these are not included in the data request associated with the SNPCC protocol.
Response 280: CMS confirms that, for purposes of evaluating care coordination, its SNPCC protocol will
be limited to collecting and evaluating the Special Needs Plans Enrollees (SNPE) record layout and its
associated impact analyses; the Care Coordination Impact Analysis (CC-IA) record layout and the Health
Risk Assessment Timeliness Impact Analysis (HRAT-IA) record layout. To facilitate the review of care
coordination activities at the enrollee level, CMS requests the measurement metrics to which the
commenter has referred. For additional detail outlining the type of information that may be requested
during case review, please refer to the Audit Field Work Phase - Supporting Documentation Submissions
section of the SNPCC Data Request.
CMS Action 280: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 281: One commenter requested confirmation that enrollment verification has been eliminated
as an audit element in the SNPCC protocol. The commenter also stated that, without verification of
enrollment, it would not be possible to verify that the initial health risk assessment (IHRA) was
completed within the required timeframe.
Response 281: CMS confirms the SNPCC protocol is limited to the Care Coordination audit element. In
addition, CMS will verify accuracy of enrollment effective dates via universe integrity testing in order to
assess timeliness of HRAs.
Page 78 of 95
CMS Action 281: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 282: One commenter referred to the method of evaluation in the SNPCC protocol, requesting
that CMS provide more detail on its process for conducting pre-audit universe integrity testing webinars.
The commenter asked whether validation would be limited to date/time fields asserting that this is the
way the CDAG and ODAG universe integrity tests are conducted. Another commenter requested
clarification as to which fields will be verified for accuracy during the universe integrity test.
Response 282: Auditors will provide the Sponsoring organization with samples one hour in advance of
the universe integrity testing webinar. Sponsoring organizations will be required to pull up information
live from their systems to support data points that were included in their SNPE universe, such as
enrollment dates, dates of initial HRA, etc. The same process could be used to verify the integrity of the
impact analyses requested during the audit. The method of evaluation field of the protocol has been
updated, and examples have been added, to clarify the process for SNPCC integrity testing.
CMS Action 282: CMS updated the method of evaluation for universe integrity testing in the SNPCC
protocol to provide the following clarification; “System data such as enrollment dates, dates of initial
HRA, etc., will be verified.” No changes were made to the burden estimate in response to these
comments.
Comment 283: Several commenters referred to the method of evaluation for compliance standard 1.3
noting that sample selections would be provided to the Sponsoring organization approximately one hour
before the start of audit field work. These commenters noted that, previously, CMS would provide
sample selections for the Care Coordination audit element by close of business on the Thursday prior to
the start of audit field work. Many commenters opposed the change to only one hour in advance of audit
field work. One commenter asserted that the one-hour time frame conflicts with guidance in the Audit
Field Work Phase, which states, “Sponsoring organization must submit supporting documentation within
two business days of the request.” Commenters stated that the shorter timeframe would compromise an
organization’s ability to provide the same level of supporting documentation as is provided currently to
satisfy each of the compliance standards. Commenters provided a list of information that they would
need to gather such as HRA; ICP; ICT; details on claims; encounters; Prescription Drug Events; evidence
of communication with enrollees, caregivers, and providers; credentials and training of any involved
clinician or staff member; related meeting minutes and attendance records; case files; and phone scripts.
Commenters further noted that this information is documented in multiple systems, from many years, and
may need to be retrieved from historical systems. Several commenters stated that D-SNP care
management cases are highly complex and it takes time for Sponsoring organizations to review the
enrollee's care management records and to understand the evolution of the enrollee's movement through
the care management pathway. Commenters stated that without the additional preparation time, it is
highly unlikely that a review of 30 sample files could be completed within one week of field work.
Commenters also stated that sufficient preparation for presenting the case samples potentially lessens the
number of items that would be added to the auditors' document request logs. Commenters concluded by
requesting that CMS maintain the timeframe that is allowed under the prior protocol to assist
organizations in preparing for a smooth walkthrough of information during the audit webinars. One
commenter requested that, if the one-hour timeframe is finalized, CMS clarify whether organizations will
be required to provide the same level of documentation for each case as is presented under the prior
protocol.
Response 283: In response to public comment, CMS will provide the 30 care coordination samples the
Thursday prior to the start of audit field work. We would expect that the same level of documentation
Page 79 of 95
would continue to be readily available by the Sponsoring organization to present during the field work
webinar.
CMS Action 283: CMS updated the method of evaluation for compliance standard 1.3 to state, “Sample
selections will be provided to the Sponsoring organization the Thursday prior to the start of audit field
work.” No changes were made to the burden estimate in response to this comment.
Comment 284: One commenter requested that CMS limit the IHRA timeliness test to enrollees that have
been enrolled with effective dates within 13 months of the audit engagement notice. For example, if the
audit engagement notice is received on April 15, 2021, the IHRA timeliness test would be limited to those
enrollees with enrollment effective dates March 1, 2020, or later. The commenter further stated that, if an
enrollee remains continuously enrolled and did not have an IHRA completed timely, the Sponsoring
organization will fail this timeliness test in every CMS performance audit as the failure to conduct an
IHRA timely cannot be remediated retrospectively.
Response 284: We will limit the IHRA timeliness calculation to enrollees that have been enrolled with
effective dates within 12 months of the audit engagement letter. The HRAT-IT record layout will be used
to mitigate untimeliness due to enrollees who are unable to reached, unable to be contacted, and refuse to
participate, as documented per the MOC. The impact analysis request will be limited to the same 12month period.
CMS Action 284: CMS updated the method of evaluation for compliance standard 1.1 by adding the
following, “IHRA Timeliness calculations will be conducted using current enrollments, from Table 1.
Assessments will be limited to individuals enrolled with effective dates within 12 months of the audit
engagement letter.” We have also updated the guidance pertaining to the impact analysis request by
adding the following, “Impact analysis review period is limited to the 12 month period prior to date of the
engagement letter, to align with the timeliness test. *Outreach data points in Table 2IA are subject to
validation, as requested by CMS.” No changes were made to the burden estimate in response to this
comment.
Comment 285: Several commenters requested that CMS clarify the following SNPE record layout
instruction: List all current SNP enrollees as of the date of the audit engagement letter that have been
enrolled with Sponsoring organization for at least 90 days and for 13 continuous months. Commenters
indicated that the phrase, “for at least 90 days and for 13 consecutive months” is confusing. One
commenter stated that an enrollee who is enrolled in a plan for 13 consecutive months will have met the
90-day requirement as well. Commenters provided numerous examples in trying to articulate their
understanding of the way the universe period is defined. One commenter stated that a minimum of 90
days makes it seem like CMS is looking for enrollees who have only been enrolled 90 days, in addition to
those who have been continuously enrolled for 13 months. A couple commenters asked if the SNPE
record layout is meant to include enrollees that have been enrolled for at least 90 days but less than 13
continuous months. One commenter noted that this would omit persons enrolled less than 90 days. One
commenter suggested that, if this is CMS' intent, CMS should revise the universe inclusion criteria
language to read: “...a list of all current SNP enrollees as of the date of the audit engagement letter that
have been enrolled with Sponsoring organization for at least 90 days.” A couple commenters suggested
that CMS replace the word "and" with "or" such that the instructions would read: List all current SNP
enrollees as of the date of the audit engagement letter that have been enrolled with Sponsoring
organization for at least 90 days or for 13 continuous months. Many commenters asked whether CMS is
looking for two separate universe submissions: one reflective of all persons enrolled continuously for 13
months, and one that would be HRA-specific as a subset of the first universe which only reflects those
persons enrolled at least 90 days up to 13 continuous months.
Page 80 of 95
Response 285: To simplify our request, we have updated the SNPE record layout inclusion criteria
limiting it to all current SNP enrollees as of the date of the audit engagement letter. CMS is able to
complete its analysis of subsets within the data using data points already included in the SNPE record
layout. Therefore, it is not necessary to further clarify start and stop dates of the enrollments that should
be included in the universe. As such, we removed the following language: “…that have been enrolled
with Sponsoring organization for at least 90 days and for 13 continuous months.”
CMS Action 285: CMS updated the first bullet of the SNPE record layout instructions to read: “List all
current SNP enrollees as of the date of the audit engagement letter.” No changes were made to the burden
estimate in response to these comments.
Comment 286: One commenter stated that HRA data should include 90 days prior to or after enrollment.
The commenter indicated that enrollees who enrolled 13 months ago may have had an IHRA up to 3
months prior to that, extending the timeframe to 16 months. The commenter asked whether CMS will
narrow the universe to enrollees with HRA information that falls within the 13-month timeframe after
enrollment.
Response 286: To simplify our universe request, we have updated the SNPE record layout instructions to
request all SNP enrollees as of the date of the audit engagement letter. CMS will limit the IHRA
timeliness calculation to current enrollments with effective dates within 12 months of the audit
engagement letter.
CMS Action 286: As noted above, we have updated the SNPE record layout instructions to read: List
all current SNP enrollees as of the date of the audit engagement letter. No changes were made to the
burden estimate in response to this comment.
Comment 287: One commenter requested further clarification regarding document submission in
instances where changes to operational components of the Model of Care have to be made while awaiting
CMS’ off-cycle window “opening.” The commenter asked what information should be provided to CMS
for program audit purposes and how it should be provided. The commenter further noted that the
documents requested include the approved MOC and any red-line off-cycle submissions with updates to
the original MOC applicable to the audit timeframe, which is understood to be 13 months prior to the
engagement letter. The commenter expressed concern about Sponsoring organizations' inability to upload
and have reviewed (by NCQA) updates to their MOCs in sufficient time prior to program audits. The
commenter stated that, because of the 6-month “closed window” for MOC updates from December 1 to
June 1 of each year, Sponsoring organizations do not have an avenue for informing CMS about
operational changes during this time period except for individual communication to their CMS Account
Manager. The commenter asked whether the notification to the CMS Account Manager would be
considered sufficient. The commenter requested additional detail regarding the way auditors will review
Sponsoring organizations updated/redlined MOCs while awaiting reopening of the window to upload the
redlined MOC into HPMS or awaiting NCQA review of the redlined version. The commenter provided a
series of sample scenarios, requesting input as to the way in which auditors would handle the scenarios.
Response 287: CMS is only interested in NCQA "approved MOCs" and any NCQA "approved redline
modifications" as of the date of the audit engagement letter. For technical inquiries related to the MOC
requirements, or other issues related to the SNP MOC, please contact the SNP MOC Inquiry mailbox
https://dpap.lmi.org.
CMS Action 287: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 81 of 95
Comment 288: One commenter requested clarification on whether the sample selection for compliance
standards 1.1 and 1.2 will be selected from the SNPE universe to conduct the timeliness impact analyses.
The commenter requested that CMS specify how enrollees without an HRA will be identified and
whether the scope for the impact analysis would include the whole universe or some subset of sample
cases. The commenter also requested clarification on whether enrollees identified as “Unable to Contact”
(UTC) or members who declined their HRA would be included in the scope of the timeliness impact
analysis.
Response 288: CMS will review timeliness for compliance standards 1.1 and 1.2 using a subset of data
from the SNPE universe. The IHRA timeliness calculation will be limited to enrollees that have been
enrolled with effective dates within 12 months of the audit engagement letter. AHRA timeliness will be
assessed for those enrollees that were due an AHRA within the entire universe. The HRAT-IA record
layout will be requested if a Sponsoring organization's timeliness calculation falls below a threshold (as
specified by CMS) and will be used to mitigate any assessment deemed untimely, such as if the
Sponsoring organization was unable to contact the enrollee.
CMS Action 288: As stated previously, we have updated the method of evaluation for compliance
standard 1.1 by adding the following language, “IHRA Timeliness calculations will be conducted using
current enrollments, from Table 1. Assessments will be limited to individuals enrolled with effective dates
within 12 months of the audit engagement letter.” No changes were made to the burden estimate in
response to this comment.
Comment 289: One commenter suggested that CMS collect data using the SNPE record layout regarding
whether sufficient outreach attempts were made to the enrollee and/or enrollee refusal. The commenter
stated that this additional information would avoid the SNPE record layout appearing to indicate that
HRAs were not completed timely, requiring additional work through the impact analysis.
Response 289: To minimize burden, CMS has decided to collect and consider mitigating factors, such as
outreach attempts and refusals for untimely cases, separately in the HRAT-IA record layout. This twostep approach minimizes data collection by CMS as it limits collection of outreach attempts to only those
cases that appear to be untimely, as opposed to collecting outreach attempts for those who also had a
timely HRA.
CMS Action 289: CMS updated the first bullet within the HRAT-IA record layout instructions to read,
“Include all enrollees without a completed HRA or with an untimely HRA to quantify outreach attempts,
as specified in the request.” No changes were made to the burden estimate in response to this comment.
Comment 290: One commenter, in referring to compliance standards 1.1 and 1.2, requested further
clarification as to what fields CMS will use to assess timeliness of initial or annual HRAs. One
commenter asked whether the timeframe in compliance standard 1.1 should be considered "ever" or
"within the previous 26 weeks."
Response 290: CMS will review timeliness for compliance standards 1.1 and 1.2 using a subset of data in
the SNPE record layout. The IHRA timeliness calculation will be limited to enrollees that have been
enrolled with effective dates within 12 months of the audit engagement letter. AHRA timeliness will be
assessed for those enrollees that were due an AHRA and will be calculated on the entire universe. The
HRAT-IA record layout will be requested if a Sponsoring organization's timeliness calculation falls below
a threshold (as specified by CMS) and will only be used to mitigate any assessment deemed untimely,
such as if the Sponsoring organization was unable to contact the enrollee per the MOC.
Page 82 of 95
CMS Action 290: As stated previously, we have updated the method of evaluation for compliance
standards 1.1 and 1.2, and the instructions for the HRAT-IA record layout. First, for compliance standard
1.1, we have added the following language, “IHRA Timeliness calculations will be conducted using
current enrollments, from Table 1. Calculations will be limited to individuals enrolled with effective
dates within 12 months of the audit engagement letter; and Impact analysis review period is limited to the
12 the month period prior to date of the engagement letter, to align with the timeliness test. *Outreach
data points in Table 2IA are subject to validation, as requested by CMS.”
Second, we have updated compliance standard 1.2 to read, “Conduct timeliness test at the universe level
of enrollees, who have either been continuously enrolled for 365 days or more, or new enrollees who
missed the deadline to complete an initial HRA, to determine whether the Sponsoring organization
conducted timely annual health reassessments (AHRAs). Request an impact analysis for any enrollee
identified as having an untimely AHRA to quantify the outreach made by the Sponsoring organization in
an attempt to conduct the AHRA within 365 days of the prior HRA completion date, or date of
enrollment, if no initial HRA was conducted.”
Finally, we have updated the inclusion language in the HRAT-IA record layout, removing the reference
to a 26-week lookback period and adding the following inclusion language: “Impact analysis review
period is the 12 month period prior to date of the engagement letter. Sponsoring organizations
conducting HRA events within the 12-month period on a single enrollee should populate the IA record
layout with the most recent HRA event that occurred during the applicable timeframe.” No changes were
made to the burden estimate in response to this comment.
Comment 291: One commenter referred to compliance standard 1.2 and requested clarification regarding
untimely AHRA versus prior HRA. Specifically, the commenter asked whether an enrollee that hasn't
had an HRA in many years should be included in the universe or if only enrollees who had an HRA in the
year prior to the audit review period who should have then had the AHRA should be included in the
universe submission.
Response 291: CMS clarified the scope of the universe request instructions for the SNPE record layout to
include all enrollees as of the date of the engagement letter. If there was no HRA completed, Sponsoring
organizations are instructed to enter ‘None’ in the applicable fields. CMS would also expect to see
enrollees that have not received an HRA in many years included in the HRAT-IA submission, if those
enrollees fell within CMS’ review period.
CMS Action 291: As noted above, we have updated the SNPE record layout instructions to read: “List all
current SNP enrollees as of the date of the audit engagement letter.” No changes were made to the burden
estimate in response to this comment.
Comment 292: One commenter asked whether enrollee activity should be combined across numerous
enrollee IDs for enrollees who change enrollee IDs.
Response 292: The commenter is correct. In cases where enrollees change IDs, their activity should be
combined across their numerous enrollee IDs. Sponsoring organizations should identify the enrollee in
the universe using their current Enrollee ID at the time of the engagement letter.
CMS Action 292: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 83 of 95
Comment 293: One commenter referred to the HRA timeliness impact analysis and recommended that
CMS specify, within the instructions, the way in which certain factors (i.e., documented refusals, unable
to reach, etc.) will be taken into account for mitigation purposes.
Response 293: CMS requests Sponsoring organizations provide outreach attempts for enrollees who
refused an HRA or were unable to be reached when the organization attempted to complete an HRA, etc.,
in order to apply mitigating factors while assessing the level of noncompliance with CMS and MOC
requirements (e.g., observation or condition requiring corrective action). While this information is
included in the method of evaluation for compliance standard 1.1, CMS has further clarified its intent in
the HRAT-IA record layout instructions.
CMS Action 293: CMS updated the instructions in the HRAT-IA record layout to read: “Include all
enrollees without a completed HRA or with an untimely HRA to quantify outreach attempts, as specified
in the request.” No changes were made to the burden estimate in response to this comment.
Comment 294: One commenter requested confirmation that impact analysis submissions would only be
required in the event an issue is identified during audit field work/sample review.
Response 294: CMS confirms that the CC-IA record layout would be used to further pursue issues
identified during audit field work. The HRAT-IA record layout would be used to identify mitigating
factors in determining HRA timeliness.
CMS Action 294: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 295: One commenter requested that CMS clarify whether the CC-IA record layout should be
populated with only enrollees who have never had an HRA/ICP/ICT or enrollees who have not had one in
the past 26 weeks (even though they might only need this one time per year).
Response 295: When noncompliance with contract and/or MOC requirements is identified on audit,
Sponsoring organizations must submit the CC-IA record layout, for the specific issue of noncompliance,
as instructed by auditors.
CMS Action 295: CMS updated the inclusion criteria in the CC-IA record layout to read: “Include all
enrollees impacted by the care coordination issue as specified in the request for an impact analysis.” No
changes were made to the burden estimate in response to this comment.
Comment 296: One commenter asked whether it would be sufficient for Sponsoring organizations to
provide auditors with documentation that the HRA was done but is not yet available. The commenter
stated that, in instances where an enrollee enrolled just 90 days ago, the Sponsoring organization may
contact the enrollee to learn whether they have completed/mailed their HRA form. The commenter
requested clarification that documentation of contact with an enrollee who indicates that they have
completed and mailed their form (but it has not yet been received by the Sponsoring organization) would
be considered sufficient on audit.
Response 296: Only HRAs that have been received by the Sponsoring organization are considered
completed for program audit purposes.
CMS Action 296: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 84 of 95
Comment 297: One commenter stated that for certain beneficiaries, the State’s designee, such as a
county care manager or other delegate, conducts the State-designated comprehensive health risk
assessment which is usually quite extensive and in-person. The commenter also stated that this happens
prior to the individual finalizing their enrollment into the plan and that this completed comprehensive
health risk assessment is the assessment that the plan care managers and providers use to begin their
service to this beneficiary, such as to craft an Individualized Care Plan. The commenter requested that
CMS confirm that if the individual enrolling has this at least within the 90-day timeframe, CMS would
consider the HRA standard to have been met.
Response 297: For program audit purposes, we would deem HRAs completed within 90 days before or
after the enrollment effective date compliant if completed in accordance with the approved Model of
Care.
CMS Action 297: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 298: One commenter provided an example of the initial HRA being completed untimely with
documentation of the Sponsoring organization's attempts at contacting the enrollee and followed up with
several requests for clarification. In the example, the Sponsoring organization has record of a January 1st
enrollment date with multiple documented unsuccessful attempts to reach the enrollee in January and
February due to a new phone number and address. The Sponsoring organization documents contacting
the enrollee on February 15th when the enrollee refuses the assessment. The Sponsoring organization
also documents care manager contact with the enrollee on May 15th when the enrollee agrees to be seen
by the care manager at home for some care concerns. On June 1st, the care manager completes and
documents the HRA. The commenter requested confirmation that the 365-day clock for reassessment
would begin on June 1st and not on the enrollment effective date in this example.
Response 298: The reassessment is due within 365 days of the previous assessment (i.e., May 31st of the
following year, using this example).
CMS Action 298: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 299: One commenter requested clarification on the Date Initial HRA (IHRA) was completed
field in the SNPE record layout. Specifically, the commenter asked if CMS defines the IHRA as an HRA
completed within 90 days of the enrollee's effective date or is it the first HRA completed for the enrollee,
regardless of when it was completed.
Response 299: For program audit purposes, CMS considers the IHRA the first HRA completed within
90 days (before or after) the effective date of enrollment.
CMS Action 299: CMS updated the Date Initial HRA (IHRA) was completed field description in the
SNPE record layout to define an IHRA with the following language: “Enter the date of the enrollee’s first
HRA completion (within 90 days before or after the effective date of enrollment).” No changes were
made to the burden estimate in response to this comment.
Comment 300: One commenter asked whether, in instances where there is no initial assessment due to
enrollee refusal that is documented by the Sponsoring organization, the annual HRA date would default to
the enrollment date.
Page 85 of 95
Response 300: In line with Part C reporting requirements, if a new enrollee does not receive an initial
HRA within 90 days of enrollment, that enrollee’s annual HRA must completed within 365 days of
enrollment. A new enrollee who receives an HRA within 90 days of enrollment must complete a
reassessment HRA no more than 365 days after the initial HRA was completed.
CMS Action 300: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 301: One commenter referred to compliance standards 1.6, 1.7 and 1.8 and suggested that
CMS change "and" to "and/or" as follows:
Standard 1.6: "... case management notes, ICT documentation, and/or systems information will used..."
Standard 1.7: "...ICT notes and/or communications..."
Standard 1.8: "...case management notes, ICT member notes and/or communications (e.g. documented
phone calls, letters to/from providers regarding enrollee care, etc.), and/or ICT meeting agendas/minutes
pertaining..." The commenter also recommended revising compliance standards 1.6, 1.7 and 1.8 to align
with compliance standard 1.10 which indicates that "documentation may include but is not limited to."
Response 301: We have clarified compliance standard 1.6, 1.7, and 1.8.
CMS Action 301: CMS added the following phrase to the method of evaluation within compliance
standards 1.6, 1.7, and 1.8: "…documentation which may include, but is not limited to…" The updated
compliance standards now read:
1.6: Review documentation which may include, but is not limited to case management notes, ICT
documentation, and systems information such as utilization management, claims data, and prescription
drug events (PDE) for each of the 30 selected samples to determine whether the Sponsoring organization
implemented the ICP.
1.7: Review documentation which may include, but is not limited to ICT notes and communications
(amongst ICT members and/or with enrollees/caregivers) pertaining to each of the 30 selected samples to
determine how the enrollee or the caregiver/representative was involved in the ICP development.
1.8: Review systems for documentation which may include but is not limited to case management notes,
ICT member notes and communications (e.g. documented phone calls, letters to/from providers regarding
enrollee care, etc.), and ICT meeting agendas/minutes pertaining to each of the 30 selected samples to
determine whether the Sponsoring organization coordinated communication amongst its personnel,
providers, and enrollees.
No changes were made to the burden estimate in response to this comment.
Comment 302: One commenter requested that CMS further clarify the meaning of "has knowledgeable,
credentialed individuals performing HRA analysis and ICP development" within compliance standard
1.11. The commenter also requested clarification as to what is meant by "HRA analysis" in this context.
Response 302: “HRA Analysis” has been removed from compliance standard 1.11 and the standard has
been clarified. In applying this standard, CMS will assess whether ICPs were developed and implemented
by staff that met the professional requirements (including credentials) described in the MOC, in
accordance with42 CFR § 422.101(f)(1)(ii).
CMS Action 302: CMS updated compliance standard 1.11 as follows: “Review documentation for each
of the 30 selected samples to determine whether ICPs were developed and implemented by staff that met
Page 86 of 95
the professional requirements, including credentials, described in the MOC.” No changes were made to
the burden estimate in response to this comment.
Comment 303: One commenter referred to the Supplemental Documentation Requests section of the
SNPCC Data Request and requested that CMS further define the meaning of “selected MOCs.” The
commenter expressed concern with submitting MOCs within 15 business days of the audit engagement
letter date if that is when the SNPE universe is also due. The commenter recommended that MOCs only
be requested after universes are submitted to CMS and samples have been selected so that only MOCs
related to the samples have to be provided.
Response 303: CMS will limit the number of MOCs selected for review and will inform Sponsoring
organizations of the MOC selections following the universe follow up-call and submission of the SNPCC
Supplemental Questionnaire.
CMS Action 303: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 304: One commenter referred to the method of evaluation for compliance standard 1.3 and
requested that CMS clarify how many cases would be selected for Sponsoring organizations that only
have one type of SNP plan.
Response 304: CMS will select a total of 30 samples, regardless of the number of SNP plan types.
CMS Action 304: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 305: One commenter referred to the language in compliance standard 1.3 stating that it refers
to "the ICP will be reviewed for measurable goals." The commenter requested clarification as to whether
this statement is referring to the initial ICP or latest ICP.
Response 305: Compliance standard 1.3 pertains to HRAs, therefore, we believe that the commenter may
be referring to compliance standard 1.4 pertaining to ICPs. The method of evaluation for compliance
standard 1.4 is referring to the evolution of the ICP up through the date of the engagement letter, which
may include multiple iterations of an enrollee’s ICP.
CMS Action 305: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 306: One commenter asked if the intent of compliance standard 1.5 is to assess ICPs that were
changed or updated outside of the annual HRA time period.
Response 306: CMS is looking for changes to the enrollees’ health care needs that would require updates
to the ICP in accordance with the approved MOC.
CMS Action 306: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 307: One commenter requested guidance on the way that Sponsoring organizations would be
expected to present documentation connected to compliance standard 1.6 during an audit. The
commenter stated that nurses don’t have access to prescription or claims systems.
Page 87 of 95
Response 307: CMS expects the Sponsoring organization to ensure that all appropriate systems can be
accessed during the review of case samples. Sponsoring organizations would be expected to have the
necessary personnel involved to provide the requested information.
CMS Action 307: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 308: One commenter recommended that CMS add language back into the SNPE record layout
instructions that would limit enrollees that are considered in scope of review to those "with no breaks in
enrollment" and "enrollees may have switched from one SNP plan to another so long as they did not
experience a break in enrollment." One commenter requested that CMS clarify the Enrollment Effective
Date field description within the SNPE record layout. Specifically, the commenter asked whether PBP
changes initiated by the Sponsoring organization are also included in this description as it appears the
guidance is only referring to PBP changes initiated by the enrollee. Another commenter suggested that
CMS add a field to the SNPE record layout, after the Enrollment Effective Date field, called “Most
Recent Plan Change Effective Date.” The commenter suggested that this field would capture the date of
last plan change within the continuous SNP enrollment, excluding plan consolidations. The commenter
further stated that the universe definition of Enrollment Effective Date does not match up to the way in
which new versus annual enrollee HRAs are administered. The commenter concludes by stating that the
addition of this column would allow auditors to have this additional information.
Response 308: We have adopted the last commenter’s suggestion and added a field to the SNPE record
layout to account for the most recent plan change. This change allowed us to address the other
commenters by updating the Enrollment Effective Date field, and to clarify the way in which Sponsoring
organizations are instructed to report enrollees with breaks in coverage. We also clarify that the PBP
change is intended to reflect changes either initiated by the Sponsoring organization or the enrollee.
Finally, CMS will collect information from Sponsoring organizations related to seamless enrollments,
PBP mergers, acquisitions, or plan consolidations in response to Question 1 of the SNPCC Supplemental
Questionnaire.
CMS Action 308: CMS removed the following language from the Enrollment Effective Date field
description of the SNPE record layout: For a PBP change or consolidation event the Sponsoring
organization must use the pre-event effect date for the enrollee (e.g., If an enrollee is effective 4/1/2010
and stays in D-SNP through 12/31/2016 but moves to C-SNP effective 1/1/2017. We would expect to see
04/01/2010 in the universe). In addition, CMS added a new field after the Enrollment Effective Date field
named Most Recent Plan Change Effective Date. The field description reads, “Enter the date of last plan
change within the continuous SNP enrollment. Submit in CCYY/MM/DD format (e.g., 2020/01/01). For
a PBP change or consolidation event the Sponsoring organization must use the post-event effect date for
the enrollee. Enter None if there were no PBP or plan consolidation events.” No changes were made to
the burden estimate in response to this comment.
Comment 309: One commenter requested confirmation that if a plan enters “EXC-10” in the Date Initial
HRA (IHRA) was completed field of the SNPE record layout that CMS does not expect the plan to
produce evidence of the IHRA during the webinar review.
Response 309: CMS does not expect Sponsoring organizations to produce evidence of the IHRA during
the webinar review for enrollees whose initial HRA was conducted in excess of 10 years prior to the audit
engagement letter.
CMS Action 309: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 88 of 95
Comment 310: One commenter requested that CMS define the valid values for inclusion in the Enrollee
Risk Stratification Level at time of audit engagement letter field of the SNPE record layout (e.g.,
numbers, colors, low, medium, high, etc.).
Response 310: Sponsoring organizations are instructed to enter the risk stratification level as defined in
the specific Model of Care. Because this varies from organization to organization, Sponsoring
organizations may enter the risk stratification level used internally, regardless of the system and resulting
value. For example, values such as numbers, colors, low, medium, and high, would all be considered
acceptable as long as it aligned with the MOC. Please note, the SNPCC Supplemental Questionnaire
provides a risk stratification process description for CMS to use as a guide when reviewing the submitted
values in the universe.
CMS Action 310: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 311: One commenter expressed concern that the Enrollee Risk Stratification Level at time of
audit engagement letter field of the SNPE record layout requests data by enrollee risk level at the time of
the engagement letter. The commenter stated that stratification level definitions differ based on program
design, and enrollee risk level may vary depending on the timing of the audit. The commenter requested
flexibility around the timing of the provision of enrollee level data, and clarification on how CMS would
use the stratification level data for audit purposes.
Response 311: Collection of enrollee risk level allows CMS to stratify its sample selection. The Enrollee
Risk Stratification Level at time of audit engagement letter field in the SNPE record layout requests that
data for each enrollee as documented within the Sponsoring organization’s system(s) “at the time of the
engagement letter.”
CMS Action 311: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 312: One commenter referred to Date of most recent Individualized Care Plan (ICP) field of
the SNPE record layout stating that ICPs are continuous in nature. The commenter requested that CMS
clarify whether Sponsoring organizations should populate the field using the date the ICP was first
created or using the date the ICP was last updated.
Response 312: Sponsoring organizations are instructed to enter the date of the most recent ICP update in
the Date of most recent Individualized Care Plan (ICP) field of the SNPE record layout.
CMS Action 312: CMS updated the Date of most recent Individualized Care Plan (ICP) field description
of the SNPE record layout to read, “Enter None if the Sponsoring organization did not develop an ICP. If
care plan is continuous, enter the date of the most recent update.” No changes were made to the burden
estimate in response to this comment.
Comment 313: One commenter requested further clarification for the Date of most recent Individualized
Care Plan (ICP) field description within the SNPE record layout. Specifically, the commenter asked for
confirmation that CMS would consider a Basic Care Plan (BCP) to be an ICP for purposes of this field.
Response 313: We refer Sponsoring organizations to their individual Models of Care to determine
whether the basic care plan is considered equivalent to the ICP.
Page 89 of 95
CMS Action 313: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 314: One commenter referred to the Was an Interdisciplinary Care Team (ICT)
created/identified? field of the SNPE record layout, and the Was ICT created? and If an ICT was created,
was the ICT involved in creating and updating the enrollee’s ICP? fields of the CC-IA record layout.
The commenter presumes CMS is seeking to confirm within these fields that care was managed by an
ICT comprised of appropriate clinical disciplines (inclusive of specialists when needed) according to the
SNP’s approved MOC. This commenter suggested the fields be consolidated in each record layout and
renamed as follows, “Was an ICT meeting held with appropriate representation?.” Another commenter
requested clarification as to whether CMS is looking for anything beyond who the Sponsoring
organization has identified as part of the ICT according to the MOC. Specifically, this commenter asked,
if an enrollee did not have measurable goals but was closed and tracked for a year, and the ICT consisted
of the enrollee, PCP, and nurse, should the organization enter “Yes” in this field, or, is CMS trying to
identify the more complex cases.
Response 314: Within the Was an Interdisciplinary Care Team (ICT) created/identified? field of the
SNPE record layout, CMS is collecting data as to whether an ICT has been assigned to the enrollee.
Sponsoring organizations are instructed to enter ‘Yes’ if the enrollee has an ICT assigned and ‘No’ if the
enrollee does not have an ICT assigned. CMS is not trying to identify more complex cases.
CMS Action 314: No changes were made to the protocol in response to these comments. No changes
were made to the burden estimate in response to these comments.
Comment 315: One commenter asked which timeframe should be used in populating the following
fields, as found in the CC-IA record layout: Was an HRA conducted; If an HRA was conducted, were
needs identified?; If an ICP was created, were the identified needs addressed?; and; If an ICP was
created, was enrollee or enrollee representative involved in its development?
Response 315: As noted in the Scope of Impact Analysis table, Sponsoring organizations are instructed to
submit a list of enrollees impacted by the issue(s) identified during the 26-week period preceding the date
of the audit engagement letter through the date the issue was identified on audit. The responses entered in
these fields would be dependent upon what happened during the 26-week request period.
CMS Action 315: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 316: One commenter expressed concern about the challenge of completing the impact analysis
tables within 10 business days, noting that many of the fields would need to be pulled manually. The
commenter further noted that the If an HRA was conducted, were needs identified? field and the If an ICP
was created, were the identified needs addressed? field in the CC-IA record layout would require review
of enrollee-level documentation and records.
Commenters also expressed concern over collecting impact analyses for every untimely case. One
commenter stated that providing the level of detail proposed in the impact analyses at the universe level is
not necessary for CMS to determine the extent of impact, and suggested that CMS could request enrolleelevel documentation for a sample rather than requiring the detailed fields for all impacted enrollees.
Another commenter suggested that CMS limit requests for impact analyses to instances when a
Sponsoring organization appears at-risk from a universe level based on a CMS timeliness threshold
determination rather than CMS generating requests for full impact analyses for each missed case.
Page 90 of 95
Response 316: The HRAT-IA record layout will only be requested if a Sponsoring organization's
timeliness calculation falls below a threshold (as specified by CMS) and will only be used to mitigate any
assessment deemed untimely, such as if the Sponsoring organization was unable to contact the enrollee.
In addition, the process for asking Sponsoring organizations to quantify deficiencies related to care
coordination at the enrollee level is not new to CMS’ program audit process. To the extent that an
extension of the 10 business day deadline is necessary, auditors have the flexibility to extend that
deadline.
CMS Action 316: First, we have updated compliance standard 1.1 with the following language,
“Conduct a timeliness test at the universe level of enrollees who have been continuously enrolled for at
least 90 days, to determine whether the Sponsoring organization conducted a timely initial health risk
assessments (IHRAs) within 90 days (before or after) the effective date of enrollment. IHRA Timeliness
assessments will be conducted using current enrollments, from Table 1. Assessments will be limited to
individuals enrolled with effective dates within 12 months of the audit engagement letter.
Request an impact analysis for any enrollee identified as having an untimely IHRA to quantify the
outreach made by the Sponsoring organization in an attempt to conduct the IHRA within 90 days of
enrollment. Impact analysis review period is limited to the 12 month period prior to date of the
engagement letter, to align with the timeliness test. *Outreach data points in Table 2IA are subject to
validation, as requested by CMS.”
Next, we have updated compliance standard 1.2 with the following language, “Conduct timeliness test at
the universe level of enrollees who have either been continuously enrolled for 365 days or more, or new
enrollees who missed the deadline to complete an initial HRA, to determine whether the Sponsoring
organization conducted timely annual health re-assessment HRAs (AHRAs). Request an impact analysis
for any enrollee identified as having an untimely AHRA to quantify the outreach made by the Sponsoring
organization in an attempt to conduct the AHRA within 365 days of the prior HRA completion date, or
date of enrollment if no initial HRA was conducted.”
Finally, we updated the HRAT-IA record layout with the following new instructions, “Impact analysis
review period is the 12 month period prior to date of the engagement letter. Sponsoring organizations
conducting HRA events within the 12-month period on a single enrollee should populate the IA record
layout with the most recent HRA event that occurred during the applicable timeframe.”
No changes were made to the burden estimate in response to this comment.
Comment 317: One commenter suggested that CMS add a new field to the SNPE record layout to collect
the last ICT date after the Was an Interdisciplinary Care Team (ICT) created/identified? field to allow
auditors to quickly assess timeliness of ICTs.
Response 317: We decline to make the suggested update as there is no timeliness requirement for
establishing an ICT.
CMS Action 317: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 318: One commenter requested that CMS further define the phrase “other change in health
status” that is included in the Did enrollee experience a hospitalization or other change in health status
during the impact analysis request period? field of the CC-IA record layout.
Response 318: We refer Sponsoring organizations to their individual Models of Care to define "changes
in health status."
Page 91 of 95
CMS Action 318: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 319: One commenter asked if Sponsoring organizations would be allowed to use ‘EXC-10’ to
populate the Initial ICP Date field in the CC-IA record layout.
Response 319: The CC-IA record layout is an impact analysis with a 26 week period preceding the date
of the audit engagement letter through the date the issue was identified on audit. If a Sponsoring
organization is instructed to populate the Initial ICP Date field in the CC-IA record layout, CMS would
not expect to see data prior to the requested period.
CMS Action 319: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 320: One commenter referred to the Is there evidence that the PCP was invited to participate
on the enrollee’s ICT? field within the CC-IA record layout, requesting that CMS further define what is
meant by "invited to participate."
Response 320: CMS refers Sponsoring organizations to their individual approved Models of Care to
define appropriate methods of PCP participation on the ICT.
CMS Action 320: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 321: One commenter requested that CMS clarify that Sponsoring organizations will only be
required to complete fields within the CC-IA and HRAT-IA record layouts that are material to the
conditions cited during the webinars.
Response 321: CMS confirms that Sponsoring organizations will only be required to populate data fields
within the CC-IA and HRAT-IA record layouts as applicable to the issue(s) noted and requested by the
audit team.
CMS Action 321: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 322: One commenter referred to the IHRA completion date field of the HRAT-IA record
layout, noting that timeliness of IHRAs and AHRAs will undergo universe-level testing, and that CMS
will request an impact analysis for enrollees who fall outside the expected completion timeframe. The
commenter stated that, because the timing of the IHRA is tied to the enrollment date and, if the
enrollment effective date is not accurate, it would not be possible to have full confidence in the timeliness
test. The commenter believes that it will have to be assumed that the enrollment effective dates in the
universe are correct.
Response 322: CMS agrees with the commenter. As such, during the universe integrity testing webinars,
auditors will request that Sponsoring organizations show documentation or information live from their
systems to support data points within their SNPE universe, such as enrollment dates, dates of initial HRA,
etc., prior to performing IHRA and AHRA timeliness tests. Universe integrity testing will be required to
verify usability of the submitted universe prior to assessing timeliness at the universe level, and CMS may
also request to validate data within the submitted impact analysis.
Page 92 of 95
CMS Action 322: As previously mentioned, CMS updated the method of evaluation for the universe
integrity testing compliance standard to clarify that system data, such as enrollment dates, dates of initial
HRA, etc., will be verified. No changes were made to the burden estimate in response to this comment.
Comment 323: One commenter stated that a timeliness test and resulting impact analysis for the AHRA
reassessment will not be accurate as it will not be able to capture approved Model of Care (MOC) "Hard
to Reach" protocols.
Response 323: The HRAT-IA record layout will be used to mitigate untimeliness due to enrollees who
are unable to be reached, unable to be contacted, and refuse to participate as per the MOC.
CMS Action 323: As previously mentioned, CMS updated the method of evaluation for universe
integrity testing in the SNPCC protocol to reflect the following clarification, “System data such as
enrollment dates, dates of initial HRA, etc. will be verified.” We have also added the following language
to the method of evaluation section pertaining to the HRAT-IA record layout, “Outreach data points in
Table 2IA are subject to validation, as requested by CMS.” No changes were made to the burden estimate
in response to this comment.
Comment 324: One commenter referred to the following fields within the HRAT-IA record layout: IHRA
completion date; Number of IHRA outreach attempts required by MOC; Number of IHRA outreaches
attempted; Date of first IHRA outreach attempt; Date of last IHRA outreach attempt; and Date of enrollee
IHRA refusal. This commenter asked if Sponsoring organizations should only include timely HRA and
HRA outreach attempts, or include them all (i.e. timely and untimely attempts)?
Response 324: Sponsoring organizations should include any relevant data responsive to the request that
would demonstrate compliance or attempted compliance with its approved MOC, specific to the factors
outlined in the HRAT-IA record layout and as requested by auditors.
CMS Action 324: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 325: One commenter referred to the field IHRA completion date within the HRAT-IA record
layout and asked if an enrollee's first HRA fell outside that period, would that count as an IHRA or would
it be an AHRA?
Response 325: Initial HRAs are conducted within 90 days before or after the enrollment date. HRAs
outside of the 90-day timeframe would be considered AHRAs. The impact analysis review period for the
HRAT-IA record layout has been updated to extend the period to 12 months. This change will align with
the entire timeliness review period. In addition, CMS will tailor the impact analysis request in accordance
with these revised instructions, based on the noncompliance identified during the audit (i.e. either
untimely IHRAs or untimely AHRAs).
CMS Action 325: CMS updated the instructions in the scope of the impact analysis request in the HRATIA record layout to align with the timeliness review period of 12 months. The updated language reads,
“Submit a list of enrollees who did not receive a timely initial and/or annual HRA within the 12 month
period prior to the date of the engagement letter. Populate untimely cases with the appropriate outreach
information for initial and/or annual HRAs as identified during the timeliness test.” No changes were
made to the burden estimate in response to this comment.
Comment 326: One commenter requested further clarification on Date the HRA - Unable to Contact
(UTC) Letter was sent to non- responding enrollee field description within the HRAT-IA record layout.
Page 93 of 95
Specifically, the commenter asked whether the date entered in this field should reflect the most recent
Unable to Contact letter sent or if it should reflect any Unable to Contact letter sent to a non-responding
enrollee.
Response 326: In this example, Sponsoring organizations are instructed to populate the date of the first
Unable to Contact Letter.
CMS Action 326: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
SPECIAL NEEDS PLAN CARE COORDINATION (SNPCC)
SUPPLEMENTAL QUESTIONNAIRE
Comment 327: One commenter indicated that the questions included in the SNPCC Supplemental
Questionnaire are slightly different from the standards and guidelines in the CMS Model of Care Scoring
Guidelines used in the National Committee for Quality Assurance (NCQA) reviews. The commenter
asked for a crosswalk of guidance between the questions in the SNPCC Supplemental Questionnaire and
the Scoring Guidelines.
Response 327: CMS believes the commenter is suggesting that CMS Program Audits would be
evaluating and scoring the MOC in a manner that is duplicative of NCQA’s role in scoring MOCs.
However, we clarify that MOC scoring is under the purview of NCQA, and program audits evaluate
Sponsoring organizations’ implementation of the MOC that was approved by NCQA on behalf of CMS.
Therefore, the SNPCC Supplemental Questionnaire is considered separate from NCQA requirements.
CMS Action 327: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Comment 328: One commenter stated that they believe the questions included in the SNPCC
Supplemental Questionnaire overlap with data that is available in the Sponsoring organizations' MOC(s).
The commenter asked whether organizations should simply cut and paste information from the MOC into
the SNPCC Supplemental Questionnaire.
Response 328: We thank the commenter for raising this concern and agree that is important to reduce any
overlap in reporting, when possible. Therefore, we have removed this overlap from the questionnaire as
described in the CMS Action, below.
CMS Action 328: CMS removed questions 3, 7, 9, 10, 11, and 14 from the SNPCC Supplemental
Questionnaire. We revised the language in Question 12 to read, “Describe the outreach policy pertaining
to HRA administration and ICP development. Describe the process for beneficiaries that cannot or do not
want to be contacted.” We renumbered the remaining questions accordingly. No changes were made to
the burden estimate in response to this comment.
Comment 329: One commenter referred to the following question in the SNPCC Supplemental
Questionnaire, “Describe the process for tracking MOC training for ICT-implicated staff and FDRs.” The
commenter requested that CMS further define who would be considered, "ICT-implicated staff and
FDRs."
Response 329: CMS refers Sponsoring organizations to their approved Models of Care to define ICT
implicated staff and FDRs.
Page 94 of 95
CMS Action 329: No changes were made to the protocol in response to this comment. No changes were
made to the burden estimate in response to this comment.
Page 95 of 95
File Type | application/pdf |
File Title | 10717 60D Comments Summaries |
Subject | 60D Comments |
Author | CMS |
File Modified | 2020-05-22 |
File Created | 2020-05-22 |