CMS-10320 CCIIO_PRA_Comment_Replies_20122731

Data Collection for HealthCare.gov

CMS responses to comments received regarding regulations.gov
Document ID: CMS-2012-0075-0001
(Collection Control Number(s): 0938-1086; 1545-2229; 1210-0147; and 0938-1146)

New Data Templates
The new individual and family plan benefits template includes 33 new required “limitations and
exceptions” fields that have been expanded to accommodate the SBC requirements. While we
understand that these fields are necessary for HHS to generate a SBC, they pose several
operational challenges and in some circumstances we recommend they are optional. While the
previous allowable response was “limitations and exceptions may apply” or “none” now health
plans are required to include free text to describe the most significant limitations and exceptions
including dollar or service limitations. Making this field optional would eliminate the need for
those plan benefits that do not have limitations and exceptions to be filled out. In addition, it
would eliminate the need for those companies who will not be using Healthcare.gov for “deemed
compliance” for the SBC requirements to complete. For these companies, the site could just
reference the benefit brochure which already includes the same information. We recognize that
this data is somewhat detailed, and the templates will incorporate optional status for a number
of elements. However, based on the desire for consistency in reporting, HealthCare.gov will be
using the SBC format for display and as such needs to be able to populate those fields. Issuers
will be creating SBCs under a variety of conditions, so the burden associated with defining what
should populate the fields is minimal. The issue of referring people to published brochures
elsewhere would not meet the statutory requirement of collecting and displaying the information
on one site where consumers can compare their options. We will entertain additional
suggestions specifically raised regarding how we may incorporate third party sites in future.
Currently, we allow for xml submissions which could be generated by the same computer
systems used to create SBCs for mailing.
We recommend that HHS takes steps to allow plans to review their SBC’s before they are
published online to address any data issues early. We also recommend that HHS use the first
two data submission windows to make any needed changes to the SBC generation process. We
recognize that reviewing SBCs as they are created and before publication is desirable by
Issuers. We will attempt to address this moving forward. Currently, technical issues associated
with creating 508 compliant versions of thousands of documents associated with the collection
will not allow adequate time for this review in the initial collection. Additionally, CMS has always
separated out issuer responsibility for submission from CMS responsibility for display. This
stance is essential to make sure objective standards for comparison information are applied.
CMS will retain this ultimate responsibility for the display.
We recommend that the new data templates are migrated to Excel 2010. Currently HHS only
supports Excel 2003 and XML. Many health plans are phasing out older version of Microsoft
office and the web portal’s use of Excel 2003 creates workarounds in the support areas. We

recommend HHS update the data collection templates to Excel 2010 for the August 2012
combined submission window. We appreciate the desirability of Excel 2010 support, and will be
implementing this change with this next collection.

Given the new fields, we recommend that HHS release an updated confidentiality template
with the finalization of the templates next month. CMS will be including an updated template
to collect confidentiality concerns.
Technical Recommendations
Submission of product level data thru the Health Insurance Oversight System (HIOS):
The HIOS submission process continues to pose challenges in that each issuer is contained in
separate spreadsheets. Simple contact changes often require health plans to have to change
multiple files with duplicate information. We recommend a similar approach is taken to RBIS
where the data is all included on one file. While we strive to minimize duplicative data entry,
issuers have been clear with us that different individuals may have responsibility for submitting
data in different states. The current design maximized the flexibility for issuers to indicate
different responsibility. Some issuers may have a fewer responsible parties. We will take this
under advisement to see if we can implement a default to primary user in future iterations, but
this would require significant changes to the data structure at this time. As CMS moves to
consolidate future collection efforts, we will be revising the user management system and will
attempt to address this concern.
New Data System: We understand that HHS is upgrading to a new data collection system in
August. We request information on this new system as soon as possible so health plans can
make any necessary adjustments to their operational processes. CMS has already provided two
training sessions to review the new structure for open collection periods. Weekly calls are held
with issuers to address any other questions which may emerge. Detailed user guides have been
prepared and only await finalization of collection authority before dissemination. Help desk
service and email are also available for questions.
Zip Code Timing Issue: RBIS validates the zip codes on the regions template at submission
time against real time data at the United States Postal Service (USPS). Health plans are using a
CD provided by the USPS which is updated monthly. Therefore, health plans are seeing zip
code errors due to timing differences of the source of zip code data. HHS should work to synch
up the timing by allowing health plans to access the same zip code data that HHS is using. An
alternative is for HHS to clearly specify at each data collection what version of the USPS data
they are using. CMS has contracted for continuously updated zip code information. We are
bound by contract from sharing this data directly. We review submitted information to make sure
that issuers have appropriate definitions of regions in place to assure them that the proper
information is provided to consumers. Initially, reports of errors were not detailed enough for
easy editing of submitted files, and we have attempted to improve the content of our error
messages. Issuers are ultimately responsible for appropriate definitions of their rating regions.
Auto Generated Emails: We recommend that the HIOS “Submission Error” and HIOS
“Submission Successful” emails include the state abbreviation and Issuer ID in the subject line
to allow for routing to the responsible parties. CMS appreciates that this may be a good idea, as

different parties may be responsible for different states. We will take under advisement and
attempt to include in future iterations.
Link Failures: We recommend that HHS provide descriptive failure link notifications before the
data submission window closes. This will allow health plans with sufficient time to make any
necessary adjustments. CMS does review and notify issuers regarding problematic links. This is
a manual process, and requires time to complete. We need to have complete data in order to be
able to review it, and we typically review and send notifications within 3 days. In our future
collection design, data submission windows for HIOS will only be closed for two weeks each
quarter, allowing issuers a substantial window for addressing problems.
Attestation: Issues with attestation have been a long-standing source of reporting burden. We
recommend the following changes are made to the attestation process:
o The “Ready for Attestation” and “Attestation complete” emails do not contain the state in the
subject line. We recommend that HHS include the state name in the “Ready for Attestation”
email and “Attestation complete” email so that it matches the attestation page in RBIS.
o CEOs/CFOs who are attesting on behalf of their companies continue to receive successful
submission auto generated email messages for the HIOS system. This causes confusion and
unnecessary processing by health plans especially because CEOs/CFOs are not required to
attest to the HIOS data. We appreciate that attestation officials (CEOs and CFOs) have
substantial demands on their time. They are required to attest as to the entirety of their
submission, including the HIOS data. We are attempting to simplify and streamline this process,
including an online facility which allows them to attest when submissions are completed in their
entirety. We are seeking ways to reduce emails while making sure these individuals are
informed moving forward.
Data Submitter and Validator Roles: We recommend the following changes are made to the
attestation process:
o Submitter and Validator roles cannot see what the Attester is seeing on the attestation screen.
We recommend that HHS provide “view only” access to the Submitter and Validator roles in
order to view what the Attester will see on the Attestation screen.
o The attestation page does not clearly display all Issuers available for Attestation at one time.
We recommend the page distinguish which Issuers had data submitted and which did not in a
table vs. using a scrolling box. We will consider allowing submitters to view the attestation page
versus using email notifications. Nevertheless, views of the information are consistent and
should not present substantial problems. Based on your second suggestion, we will be changing
the display to provide a full table rather than a display window for lists of submissions within
HIOS.