Attachment - Ovations-2008-0104-0002[1].1

WI080-1000
2725 Mall Drive
Eau Claire, WI 54701

To:

CMS, Office of Strategic Operations and Regulatory Affairs
Attn: Document ID: CMS-2008-0104-001; CMS-2008-0103-001
OMB Office of Information and Regulatory Affairs
Attn: CMS Desk Officer
Submitted electronically at: http://www.regulations.gov.

From: Michael Warschauer, Sr. Project Manager, Product Administration, Ovations
Barbara Reid, Manager, Regulatory Affairs, Ovations
Date: October 20, 2008
Re:

CY2010 Master Application Automation Consolidated Collection:
• CMS-10237, Medicare Advantage - Part C
• CMS-10214, MA Organizations to Offer New Medicare Advantage
Employer/Union-Only Group Waiver Plans
•

CMS—10137, Part D Plan Applications

We have reviewed the CY2010 Master Application Automation Consolidated Collection
in response to the notice published under the Paperwork Reduction Act in the September
18, 2008 Federal Register (73 FR 54160) and provide the attached comments concerning
the following applications:
-Part C – Medicare Advantage Application;
-Service Area Expansion Application for Medicare Advantage;
-Application for Prescription Drug Plans (PDP); and
-Application for Medicare Advantage Prescription Drug (MA–PD);
These comments are provided on behalf of Ovations and other UnitedHealth Group
affiliates, including AmeriChoice, that manage Medicare Advantage and Part D business
(collectively “United”).
We greatly appreciate the opportunity to comment, and we look forward to continuing to
work with CMS to develop successful products and services for Medicare beneficiaries.
If you have any questions or concerns on our comments, please contact Michael
Warschauer at 740-824-5142 or via email at michael_j_warschauer @uhc.com or Barbara
Reid at 715-832-5235 or via email at barbara_reid@uhc.com.

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
1 of 8

CY2010 Master Application Automation Consolidated Collection
Comments Submitted by
UnitedHealth Group/Ovations
October 20, 2008
1.

Part D Application
Part D Schedule, Pharmacy Access, MA-PD, Section 2.8
This section indicates that there will be a courtesy submission window and a final
submission window for Part D but does not contain the dates or the open duration
of the windows. Please clarify the dates and length of time for both submission
windows.
In addition to the clarification, it is recommended that CMS apply the Part C
application scheduling correction timeframes to the Part D application process.
This would include having the same corrections windows scheduled in HPMS for
responses to the incompleteness and intent to deny letters. At a minimum, an
opportunity to make corrections to Part D applications should be made available
prior to April. This would provide plans with an opportunity to correct
discrepancies or supply minor information and avoid unnecessary Notices of
Intent to Deny.

2.

Part D and Part C - Medicare Advantage Applications
a. Communication Channels
Last application season, communication was effectively discouraged between the
CMS Regional Offices and the applicants since the content of those
communications were not considered part of the official application record in
HPMS. This limited the free exchange of information and increased the number
of issues in the appeals process.
Applicants and CMS reviewers should be encouraged to communicate so that
necessary information can be supplied and reviewed with the understanding that
critical information be added to the HPMS record prior to an approval. For
example, a reviewer requires a document that was not uploaded in the
incompleteness window of March 30th. Instead of issuing an Intent to Deny
Letter on April 24th and the applicant having to wait until April 24th to supply the
required information, it could be supplied directly to the reviewer. This would
allow the application to proceed through the process without delay. That
information could then be uploaded into HPMS either by the reviewer or by the
applicant during the next available window.
b. Change History Document
During the 2009 application process, CMS was not always aware when plans had
made changes as requested by CMS in an incompleteness letter. This may have

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
2 of 8

been due, in part, because the electronic process in HPMS apparently did not alert
CMS reviewers that certain files had been re-uploaded or updated.
Adding a “Change History” document to the HPMS module or a mechanism to
upload such a document as part of the plan response to an incompleteness letter
would alert CMS reviewers to changes and facilitate a more efficient review.
3.

Part C - Medicare Advantage Applications
a. Filing for Partial County, Section 1.6
Question #1, indicates a plan is attesting to the county integrity rule as outlined in
Chapter 4 of the Medicare Managed Care Manual. However, if a plan is only
filing for a partial county, the county integrity rule is not applicable. It is
recommended the question be updated to reflect the 2009 application that
contained additional wording clarifying that YES meant the applicant was
applying for a partial county.
b. Contracts for Administrative & Management Services, Section 1.10,
Statement #8
The statement “Note: This question is not applicable to PFFS and MSA PFFS
network model applicants” may be confusing, as there is no MSA-PFFS plan
type. For clarity, this should be reworded to “This question is not applicable to
network-based PFFS and network-based MSA plan applicants.”
c. Health Services Management & Delivery, Section 1.11, Statement #4
Same comment as in 3.b., above.
d. Quality Improvement Program, Section 1.12
Both the table of contents and the title indicate that this section applies to CCP
and RPPOs only. However, MIPPA requires that PFFS participate in quality
improvement programs beginning in 2010. Therefore, PFFS plans should be
required to complete this section of the application as well.
e. Access to Services, Section 3.1, Statement #4
The statement references both full and partial networks for PFFS plans. Please
clarify if CMS considers a partial network type of plan to be network-based or
non-network based. And, if a PFFS plan files with a partial network in 2010 will
it be required to complete another application in 2011 if it is located in a service
area with two or more coordinated care plans?
f. Access to Services, Section 3.1, Statement #4 and Statement #5
Both statements refer only to contracted networks where providers are paid less
than Original Medicare. Please clarify why is there a distinction in these
statements between paying above Medicare, paying less than Medicare and
paying at Medicare.

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
3 of 8

g. Schedule for correction windows-State Licensure
During the 2009 application process, a 1 day window of time was provided for
uploading state licensure information by the June deadline. The 2010 tentative
schedule does not reflect a window for this purpose. The last window per the
2010 schedule ends on May 4. Since the deadline for information regarding the
state licensure is the first Monday in June, please provide a later window for plans
to submit that information.
h. Release of HSD tables Prior to Final Release of Application in Early
January
While it is recognized and appreciated that CMS has provided the draft
application earlier this year, it is requested that the final HSD Tables be made
available by November or December 1 rather than with the release of the Final
Application in early January. This would allow organizations with a high volume
of submissions additional time to train network personnel and sufficient time to
upgrade HSD tools, excel formulas, etc. on any changes made to the tables. In
addition, it is recommended that the tables be consistent from year to year.
i. HSD Tables-addition of HSD 3 to HSD 1 and Reporting Participating
Providers
Please clarify the intent of adding the HSD 3 providers to the HSD 1 table. The
value of the addition is not immediately clear. The addition of "HSD3" providers
to the HSD1 table requires plans to report the number of the HSD 3 providers that
are participating in the Medicare program. This requires use of the Medicare.gov
website which does not always have the information available or makes the
information available in inconsistent formats (by county or zip code). This
requires plans to do manual counts which become administratively burdensome.
It is recommended that CMS supply a more workable data source for determining
the Medicare participating providers by county field or, in the alternative, not
requiring this field to be completed for these "HSD3" providers. It is further
recommended the tables remain consistent with the provider types from year to
year unless there is a compelling reason for the change.
j. Claims - Section 1.13.4 Claims, # 2
Currently Attestation #2 reads: “Applicant will ensure that all claims are
processed in chronological order, by date of receipt.” Claims are generally
processed in the order in which they are received. However, in order to process
claims in a more efficient manner, an applicant may not always process every
claim in strict chronological order. For example, some claims may auto
adjudicate earlier than claims requiring some type of manual review, even if the
manually reviewed claims are received earlier.
It is recommended that this attestation be revised to read as follows:
• "Applicant will employ a process that seeks to process claims in accordance
with CMS regulations and guidelines.”
UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
4 of 8

This change to the attestation wording will more closely align with the CMS
requirements and will allow applicants to answer this attestation with a “yes”
without having to qualify the response.
k. Claims -- Section 1.13.4 Claims, # 3
Currently, Attestation #3 reads as follows: “Applicant will give the beneficiary
prompt notice of acceptance or denial of a claims’ payment in a format specified
by CMS.”
There are two concerns with the current attestation as worded. First, the phrase
“prompt notice of acceptance or denial of a claims’ payment” implies that a notice
of acceptance or denial is required for all claims. There are some cases where a
notice is not required. For example, when there is no beneficiary cost sharing
involved (except for PFFS claims), a claim approval notice is not sent to the
beneficiary and the provider will receive a provider remittance advice or similar
document with payment. In addition, plans might not notify beneficiaries of
claim denials when the claim only involves provider reimbursement/liability.
Rather, plans may comply with CMS’s requirement that, when a claim is denied
resulting in member liability, the member is provided with his or her appeals
rights.
Second, the current wording of the attestation suggests that plans are required to
utilize a format specified by CMS. The understanding from the CMS guidelines
is that CMS provides a form notice that can be used for these denials, but this
form is not required and plans may provide it in an alternative manner when
approved by CMS.
It is recommended that this attestation be revised to read as follows:
• “Applicant will provide CMS required notices of claims’determinations to
beneficiaries.”
The suggested change in the wording of the attestation will more closely align
with the CMS requirements and will allow applicants to answer this attestation
with a “yes” without having to qualify the response.
l. Claims -- Section 1.13.4, Attestation # 4
It is recommended that this attestation be revised to read as follows:
•

“Applicant will comply with all applicable standards and requirements and
establish meaningful procedures in accord with CMS requirements for the
development and processing of claims including having an effective system
for receiving, controlling, and processing claims actions promptly and
correctly.”

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
5 of 8

This revision will more closely align with the CMS requirements. For example,
plans may not “develop” all claims that are incomplete, such as certain claims that
are missing information or have invalid coding. These claims typically involve
only provider liability, so they would not affect the member. This slight change
in the attestation wording would allow plans to answer this attestation with a
“yes” without having to qualify the response.
4.

Part C – Medicare Advantage Applications – Special Needs Plans Section
(SNP)
a. State Medicaid Agency Contracts, pp 71, 78
We are in the process of reviewing and commenting on the proposed regulations,
which contain the same requirements provided under the draft application. We
note that MIPPA requires that SNPs have a contract with the state to provide for
or arrange for benefits for dual eligible individuals. In a number of states, the MA
organization sponsoring a SNP may already have an existing agreement with a
state Medicaid agency that addresses the dual-eligible population, but does not
address each of the identified eight elements. Rather than requiring SNPs to
reapproach states in this situation, we recommend that CMS provide SNPs and
states with as much flexibility as possible in identifying and designing the
contract that will satisfy the MIPPA requirements.
b. Checklist of providers, p. 87
This section has a series of questions (checklist) asking whether the SNP network
includes various types of providers. If the purpose of the checklist is for plans to
attest to the presence of each type of provider, it seems unnecessary and
redundant, since plans are already supplying HSD tables. Also, slight variations
may require a different set of responses for each SNP application and for each
particular county which drastically increases the number of responses required. It
is recommended that this section be removed and CMS refer to the HSD tables to
analyze the SNP network.
c. State Assessment Tool, p 82
In this portion of the SNP section, the application states that institutional SNPs
serving those in a community should base their enrollment on a state assessment
tool. It further states that the assessment must be performed by an entity other
than the organization offering the SNP. Large healthcare companies, such as
UnitedHealth Group, have distinct affiliates which could perform the assessment
outside of the health plan. This would create operational efficiencies and reduce
costs while maintaining an arm's length transaction. Please clarify that CMS does
not intend to preclude affiliated companies, who are distinct entities from the
health plan, from performing the State Assessment for their sister companies.
d. Service Area Expansion Application (SAE), p 78, et.al.

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
6 of 8

The draft application indicates that adding a SNP type to an existing contract
would require a full SAE Application. Previously CMS allowed organizations
that were adding a SNP to their existing service area to file the SNP section of the
application along with HSD tables to CMS outside of the regular application
process.
CMS should continue to make this option available to plans that seek to only add
a SNP type product to their existing contracts/service areas. The reduced set of
documentation could be supplied via HPMS if that option was made available so
that there is an electronic record. For example, if a plan wants to add a chronic
SNP to a dual SNP area, the Part C application requirements are the same. If
there is a different network, then the plan could submit the additional HSD
table(s). If utilizing the same network, then the plan could use the tables filed for
the existing plan.
e. Contract with Assisted Living Facilities (ALF)
The purpose of the question regarding whether or not the plan has a contract with
assisted living facilities is unclear. Since ALFs do not provide Medicare
reimbursable services, plans do not typically contract with ALFs to serve the
members that reside in the ALF. This would remain true even if the Institutional
SNP wishes to offer an Institutional SNP for qualified beneficiaries in a
community setting. It is suggested CMS remove the word “contracted” and/or
clarify the purpose of the question.
f. SNP Care Management Requirements- Targeted Special Needs
Individuals, p 84
It is unclear when indicating which model of care applies to a plan whether each
plan must have a special model of care for end-stage renal disease. Please clarify
that a plan only needs to check the model of care to manage the delivery of
specialized services and benefits for individuals with ESRD if the plan has
requested an ESRD waiver.
Also it is unclear whether this section is designed to identify which type of special
needs plans the applicant is providing or to identify whether the applicant has
specialized models of care to serve each identified population. For example, a
plan may have one model of care that is designed to meet the needs of individuals
who are dual eligible and medically complex. Does the plan check the box that
will identify the type of SNP they are applying for or each model of care that is
applicable? It is recommended that the plan identify the model of care that is
relevant to the SNP for which they are applying.
g. Health Risk Assessment, p 91
MIPPA requires that SNPs conduct “an initial assessment and an annual
reassessment of the individual’s physical, psychosocial, and functional needs” and
UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
7 of 8

“develop a plan, in consultation with the individual as feasible, that identifies
goals and objectives, including measurable outcomes as well as specific services
and benefits to be provided.” It appears that the application has placed additional
requirements on the plans regarding the format and content of the assessment.
Based on our experience, often the member is best served if the plan can conduct
an initial baseline assessment to identify whether the individual would benefit
from a more comprehensive assessment. To require a comprehensive assessment
on every individual creates an undue burden on the plan both in terms of overall
costs and personnel, and is not necessary to ensure that the individual is receiving
appropriate services/benefits from the plan. It is recommended that CMS allow
plans flexibility to identify and design assessment tools that meet the
requirements under MIPPA, and allow plans to conduct comprehensive
assessments on those individuals who would most benefit.

UnitedHealth Group/Ovations
Oct. 20, 2008

Master Application Automation Collection
CMS-10237, CMS-10214, CMS-10137
8 of 8