This is the accessible text file for GAO report number GAO-13-761 
entitled 'Medicare Information Technology: Centers for Medicare and 
Medicaid Services Needs to Pursue a Solution for Removing Social 
Security Numbers from Cards' which was released on October 17, 2013. 

This text file was formatted by the U.S. Government Accountability 
Office (GAO) to be accessible to users with visual impairments, as 
part of a longer term project to improve GAO products' accessibility. 
Every attempt has been made to maintain the structural and data 
integrity of the original printed product. Accessibility features, 
such as text descriptions of tables, consecutively numbered footnotes 
placed at the end of the file, and the text of agency comment letters, 
are provided but may not exactly duplicate the presentation or format 
of the printed version. The portable document format (PDF) file is an 
exact electronic replica of the printed version. We welcome your 
feedback. Please E-mail your comments regarding the contents or 
accessibility features of this document to Webmaster@gao.gov. 

This is a work of the U.S. government and is not subject to copyright 
protection in the United States. It may be reproduced and distributed 
in its entirety without further permission from GAO. Because this work 
may contain copyrighted images or other material, permission from the 
copyright holder may be necessary if you wish to reproduce this 
material separately. 

United States Government Accountability Office: 
GAO: 

Report to Congressional Requesters: 

September 2013: 

Medicare Information Technology: 

Centers for Medicare and Medicaid Services Needs to Pursue a Solution 
for Removing Social Security Numbers from Cards: 

GAO-13-761: 

GAO Highlights: 

Highlights of GAO-13-761, a report to congressional requesters. 

Why GAO Did This Study: 

The health insurance claims number on Medicare beneficiaries’ cards 
includes as one component the beneficiary’s (or other eligible 
person’s, such as a spouse’s) SSN. This introduces risks to 
beneficiaries’ personal information, as the number may be obtained and 
used to commit identity theft. Many organizations have replaced SSNs 
on these types of cards with alternative identifiers. However, the 
introduction of such a new data element into IT environments can 
require changes to systems that process and share data. Moreover, 
previous assessments of CMS’s IT environment have found that it 
consists of many aging, “stove-piped” systems that cannot easily share 
data or be enhanced; thus the agency has ongoing efforts to modernize 
its environment. 

As requested, GAO studied CMS’s efforts related to the removal of SSNs 
from Medicare cards. GAO’s objectives were to (1) assess actions CMS 
has taken to identify and implement IT solutions for removing SSNs 
from Medicare cards and (2) determine whether CMS’s ongoing IT 
modernization initiatives could facilitate SSN removal efforts. To do 
this, GAO reviewed agency documentation and interviewed officials. 

What GAO Found: 

The Centers for Medicare and Medicaid Services (CMS)—-which is the 
agency within the Department of Health and Human Services (HHS) 
responsible for administering Medicare-—has not taken needed steps, 
such as designating a business owner and establishing a business case 
for an information technology (IT) project, that would result in 
selecting and implementing a technical solution for removing Social 
Security numbers (SSN) from Medicare cards. However, the agency has 
collected information and data as part of its most recent study of SSN 
removal that could contribute to the identification and development of 
an IT solution. These include information relevant to examining 
alternative approaches, identifying costs and risks, and assessing the 
impact of different approaches on the agency’s existing IT systems. 
For example, the agency identified two approaches for removing the 
SSN: (1) replacing it with a new identifier, referred to as the 
Medicare Beneficiary Identifier, and (2) masking the first five digits 
of the SSN for display on Medicare cards. CMS system and business 
owners also conducted high-level assessments of the types of changes 
that would need to be made to systems identified in the agency’s IT 
inventory. For example, system owners estimated the level of 
complexity of the changes, the number of hours of work at each life-
cycle phase, business and technical risks, and the potential to 
leverage related efforts. CMS noted in its most recent study that 
replacing the SSN with a new identifier could reduce the risk of 
identity theft from a lost or stolen card, and actions taken thus far 
could inform a future IT project to address SSN removal. However, 
according to CMS officials, agency leadership has not directed them to 
initiate such a project. Until such a project is undertaken, the 
agency will not be positioned to identify or implement a solution to 
support the removal of SSNs from beneficiaries’ cards. 

CMS has efforts under way to modernize its IT systems, some of which 
could be leveraged to facilitate the removal of SSNs from Medicare 
cards. Specifically, one of CMS’s high-level modernization goals is to 
establish an architecture to support “shared services”—IT functions 
that can be used by multiple organizations and facilitate data 
sharing. According to agency officials, a service established to 
automate and manage certain aspects of CMS programs could be used to 
support a “crosswalk” function that would translate the existing 
claims number to the new beneficiary identifier (and vice versa). This 
would enable internal systems to receive information containing the 
new identifier and continue to process data based on the existing 
number. Another project was intended to consolidate eligibility 
determination services from four systems, which could reduce the 
extent of modifications that would have to be made to each of the 
systems. However, because the agency has not initiated a project for 
removing SSNs from identification cards, officials have not considered 
including shared services or other IT initiatives in their 
modernization activities and related plans to specifically support 
changes needed as a result of SSN removal. As a result, CMS may miss 
opportunities to incorporate such a project into ongoing agencywide 
modernization initiatives that could facilitate efforts to design, 
develop, and implement an IT solution for SSN removal in a timely and 
cost-effective manner. 

What GAO Recommends: 

GAO recommends that CMS initiate an IT project to develop a solution 
for SSN removal and incorporate such a project into plans for ongoing 
IT modernization initiatives. HHS agreed with GAO’s recommendations, 
if certain constraints were addressed. However, GAO maintains that its 
recommendations are warranted as originally stated. 

View [hyperlink, http://www.gao.gov/products/GAO-13-761]. For more 
information, contact Valerie C. Melvin at (202) 512-6304 or 
melvinv@gao.gov. 

[End of section] 

Contents: 

Letter: 

Background: 

CMS Has Not Actively Pursued an IT Solution but Has Taken Actions That 
Could Support Efforts to Do So: 

CMS Has Initiated Actions Intended to Address Modernization Goals That 
Could Facilitate SSN Removal but Has Not Made Specific Plans for 
Leveraging Efforts: 

Conclusions: 

Recommendations for Executive Action: 

Agency Comments and Our Evaluation: 

Appendix I: Objectives, Scope, and Methodology: 

Appendix II: GAO's Assessment of Three CMS Systems and the Types of 
Potential Changes Needed to Support SSN Removal: 

Appendix III: Comments from the Department of Health & Human Services: 

Appendix IV: GAO Contact and Staff Acknowledgments: 

Tables: 

Table 1: Description of HETS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Table 2: Description of FISS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Table 3: Description of MBDSS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Figures: 

Figure 1: Medicare Card: 

Figure 2: Flow of Data and Use of the Health Insurance Claim Number in 
CMS's and Medicare Stakeholders' Systems: 

Abbreviations: 

CIO: chief information officer: 

CMS: Centers for Medicare and Medicaid Services: 

COBOL: Common Business-Oriented Language: 

DOD: Department of Defense: 

FISS: Fiscal Intermediary Standard System: 

GUI: graphical user interface: 

HETS: HIPAA Eligibility Transaction System: 

HHS: Department of Health and Human Services: 

HICN: Health Insurance Claim Number: 

HIPAA: Health Insurance Portability and Accountability Act: 

IT: information technology: 

IUI: integrated user interface: 

MARx: Medicare Advantage and Prescription Drug System: 

MBD: Medicare Beneficiary Database: 

MBDSS: Medicare Beneficiary Database Suite of Systems: 

MBI: Medicare Beneficiary Identifier: 

OMB: Office of Management and Budget: 

SSA: Social Security Administration: 

SSN: Social Security number: 

VA: Department of Veterans Affairs: 

VSAM: Virtual Storage Access Method: 

XLC: Expedited Life Cycle: 

[End of section] 

GAO:
United States Government Accountability Office: 
441 G St. N.W. 
Washington, DC 20548: 

September 10, 2013: 

The Honorable Sam Johnson: 
Chairman: 
Subcommittee on Social Security: 
Committee on Ways and Means: 
House of Representatives: 

The Honorable Kevin Brady: 
Chairman: 
Subcommittee on Health: 
Committee on Ways and Means: 
House of Representatives: 

As one of the federal government's largest programs, Medicare provides 
health insurance to the nation's elderly, certain disabled 
individuals, and individuals with end-stage renal disease. The 
program, which served approximately 50 million beneficiaries in 2012, 
consists of four parts: A, B, C, and D. Parts A and B are referred to 
as fee-for-service programs, and respectively, provide health 
insurance coverage for (1) hospital and inpatient stays, hospice, and 
home health services; and (2) hospital outpatient, physician, and 
other services such as home health care, and durable medical equipment 
such as wheelchairs and walkers.[Footnote 1] 

The Centers for Medicare and Medicaid Services (CMS)--the federal 
agency within the Department of Health and Human Services (HHS) that 
administers Medicare--and its contractors process more than a billion 
fee-for-service claims each year.[Footnote 2] These claims for payment 
are submitted by about 1.5 million health care providers such as 
physicians, hospitals, and medical equipment suppliers. The providers 
are reimbursed by Medicare for services and supplies that they deliver 
to beneficiaries in accordance with Parts A and B rules.[Footnote 3] 

For their part, Medicare beneficiaries show proof of eligibility for 
coverage under Parts A and B by presenting printed insurance cards to 
their providers at the point of care. The approximately 50 million 
cards that have been issued and are currently in use display Social 
Security numbers (SSN) as a component of beneficiaries' claims 
identification numbers. However, the visual display of the SSN 
introduces risks to the security of beneficiaries' personal 
information, as the number may, among other things, be obtained and 
used by criminals to conduct identity theft. 

CMS depends on more than 200 information technology (IT) systems to 
support administration of the Medicare program, including 
determination of eligibility for benefits, processing and payment of 
claims, and exchange of Medicare-related data with external 
stakeholders. Many of these systems were developed decades ago and are 
difficult to modify or update to incorporate changes in business rules 
or data, or to integrate with other systems. In 2010 the agency 
assessed its IT environment in response to direction from the Patient 
Protection and Affordable Care Act[Footnote 4] and began to take steps 
toward planning an agencywide IT modernization initiative. 

At your request, we conducted a study of CMS's efforts related to the 
removal of SSNs from Medicare cards. Our specific objectives were to 
(1) assess the actions CMS has been taking to identify and implement 
IT solutions for removing SSNs from Medicare beneficiaries' cards, and 
(2) determine whether CMS's ongoing IT modernization initiatives could 
offer opportunities to facilitate efforts to remove the SSN from the 
cards. 

To address the first objective, we examined documentation that 
described studies the agency conducted in 2006, 2011, and 2013 of 
different approaches toward removing SSNs from Medicare cards. 
Specifically, we focused our work on results of the most recent study 
and assessed relevant technical documents, such as those which 
identify system components that would be affected by the removal of 
the SSN from cards, and other documents that describe the data and 
message format requirements for exchanging data between systems. We 
compared activities identified in these documents to department-level 
requirements for identifying, developing, and implementing technical 
solutions for business processes. We also assessed a sample of the 
systems that CMS identified as ones that would be affected by the 
removal of the SSN from cards. We based our selection on the level of 
effort CMS estimated would be needed to implement modifications and 
the functionality provided by the systems. Specifically, we identified 
29 systems that we determined accounted for over 90 percent of the 
total estimated level of effort and selected 3 for our assessment--1 
with a low estimate, 1 with a high estimate, and 1 that provided 
critical functionality within the claims processing IT environment. We 
examined technical documents for these 3 systems, such as those that 
describe architectural characteristics, data formats, and exchanges 
with other systems. To further address the objective, we examined data 
collected by CMS from the federal stakeholders with whom it exchanges 
data related to Medicare beneficiaries--the Social Security 
Administration (SSA) and the Railroad Retirement Board. We also held 
discussions with Medicaid program officials from eight states to 
obtain their perspectives on roles they played in CMS's SSN removal 
study. We selected these states based on the level of effort they 
estimated would be needed to make changes to their systems to address 
SSN removal. The information we obtained from them is not 
generalizable to all Medicaid programs but provides insight into the 
extent to which CMS involved program stakeholders in conducting its 
2013 study. 

To address the second objective, we identified criteria by examining 
federal laws and guidance for leveraging IT modernization initiatives 
to guide systems development,[Footnote 5] and assessed plans and 
briefings describing CMS's initiatives to modernize its IT 
environment. To determine the extent to which the goals and objectives 
of these initiatives could be leveraged to facilitate the SSN removal 
effort, we compared descriptions of specific modernization projects to 
information obtained from agency technical documents describing the 
systems that would have to be modified if the SSN were to be removed 
from cards. In making these comparisons, we identified common 
characteristics and efforts that could be coordinated to achieve 
efficiencies in implementing system changes. 

To supplement our assessment of documentation and data relevant to 
both objectives, we held discussions with CMS officials from the 
agency's Office of Information Services, including the Chief 
Information Officer (CIO), regarding actions taken to collect and 
analyze information needed to complete the 2013 study. We also 
discussed with these officials the steps they took to involve 
stakeholders in identifying approaches for removing the SSN from cards 
and assessing the potential impact on IT systems. Finally, we obtained 
descriptive information from the agency's CIO and other Office of 
Information Services officials regarding plans and ongoing initiatives 
intended to lead to the modernization of CMS's IT environment. A more 
detailed description of our objectives, scope, and methodology is 
provided in appendix I. 

We conducted this performance audit from October 2012 to September 
2013 in accordance with generally accepted government auditing 
standards. Those standards require that we plan and perform the audit 
to obtain sufficient, appropriate evidence to provide a reasonable 
basis for our findings and conclusions based on our audit objectives. 
We believe that the evidence obtained provides a reasonable basis for 
our findings and conclusions based on our audit objectives. 

Background: 

The use of SSNs on identification cards by federal, state, and private 
organizations, such as health insurance companies, was prevalent until 
the early 2000s. However, many organizations have since replaced these 
types of identification cards with those that do not contain SSNs. 
This step was taken, in large part, in response to certain federal and 
state laws that place restrictions on entities' use and disclosure of 
consumers' personal information, including SSNs. Examples of federal 
laws include the Driver's Privacy Protection Act,[Footnote 6] which 
generally prohibits a state department of motor vehicles from 
disclosing or otherwise making available SSNs and other personal 
information from a motor vehicle record, and the Health Insurance 
Portability and Accountability Act (HIPAA)[Footnote 7] and its 
implementing regulations, which protect the privacy of health 
information that identifies an individual (including by SSNs) and 
restricts health care organizations from disclosing such information 
to others without the patient's consent. Additionally, several state 
statutes include provisions related to restricting the display of 
SSNs, their unnecessary collection, and their disclosure without the 
individual's consent. Many state agencies have discontinued the use of 
the numbers on identification cards and other documents, such as 
driver's licenses, to comply with such laws. Similarly, private sector 
health insurers have discontinued use of SSNs on insurance cards in an 
effort to protect beneficiaries' personal health information. 

Certain federal agencies, including the Departments of Defense (DOD) 
and Veterans Affairs (VA), have similarly taken actions to remove the 
numbers from identification cards.[Footnote 8] For example, in June 
2011, DOD completed efforts begun in 2008 to replace almost 10 million 
military identification cards that had SSNs printed on them with cards 
that stored the numbers in bar codes. Additionally, in November 2004, 
VA completed a project begun earlier that year aimed at replacing 
almost 8 million cards that contained the printed number. The 
department did so by embedding the numbers in magnetic stripes on the 
cards. However, both DOD and VA continued to use the number as an 
identifier and have described other steps they are taking to better 
protect beneficiaries against theft or improper use of the numbers. 
Specifically, DOD officials stated that the department is in the 
process of developing and implementing a solution for removing 
embedded SSNs from the bar codes on military identification cards and 
replacing them with a new identifier; they plan to complete this 
project in late 2016.[Footnote 9] Additionally, VA is working to 
remove the number embedded in magnetic stripes because of increased 
security risks introduced by the prevalence of electronic readers on 
devices such as smart phones; it plans to complete this project in 
late 2016. 

Use of SSN-Based Health Insurance Claim Number by CMS and Its 
Stakeholders: 

Since the inception of Medicare in 1965, CMS and its program 
stakeholders--SSA, the Railroad Retirement Board, and state Medicaid 
programs--have used an SSN-based identifier when filing and processing 
fee-for-service claims, and when exchanging data related to the 
Medicare program. This number, referred to as the Health Insurance 
Claim Number (HICN), is displayed on Medicare beneficiaries' health 
insurance cards. 

Individuals' eligibility to participate in the Medicare fee-for-
service programs is initially determined by SSA, based on factors such 
as age, work history, contributions made to the programs through 
payroll deductions, and the presence of certain medical conditions. 
Once SSA determines that an individual is eligible, it provides 
information about the individual to CMS, including the SSN and a 1-or 
2-digit beneficiary identification code.[Footnote 10] These data are 
transmitted to and stored in CMS's Enrollment Database--the repository 
of data about individuals who are or have ever been on Medicare. This 
system combines these two data fields to create the 10-or 11-digit 
HICN. CMS prints and issues to the individual a paper identification 
card (similar to the example shown in fig. 1) that displays the HICN 
(i.e., the Medicare claim number), the cardholder's full name, his or 
her gender, and the effective dates of Medicare program eligibility. 

Figure 1: Medicare Card: 

[Refer to PDF for image: illustration] 

Medicare Health Insurance: 
1-800-MEDICARE (1-800-633-4227) 

Name of Beneficiary: Jane Doe. 

Medicare Claim Number: 000-00-0000-A. 

Sex: Female. 

Is entitled to: 
Hospital (Part A); effective date: 07-01-1986; 
Medical (Part B); effective date: 07-01-1986. 

Sign here: 

Source: Centers for Medicare & Medicaid Services. 

[End of figure] 

The HICN is maintained and referenced throughout CMS's IT environment. 
For example, health care providers may reference Medicare 
beneficiaries' printed cards at the point of care to determine 
eligibility for the fee-for-service program. Providers may then query 
a CMS system using the HICN printed on the card, along with other 
demographic data, to obtain information regarding eligibility for 
specific treatments or services they intend to deliver, such as 
glaucoma screening or smoking cessation counseling. Specifically, the 
agency provides verification services through its HIPAA Eligibility 
Transaction System (HETS), which allows providers to access real-time 
data regarding beneficiaries' eligibility at the point at which care 
is scheduled or delivered. Likewise, providers are required by CMS to 
use the number when they submit claims to receive payment for those 
treatments and services. 

CMS's and its contractors' systems also process data based on the HICN 
to check for duplicate claims, apply claims and medical policy edits, 
issue Medicare Summary Notices, authorize or deny payment of claims, 
and conduct printing and mailing operations.[Footnote 11] For example, 
CMS's Medicare Administrative Contractors, who are responsible for 
processing and paying claims, use their own systems to determine 
whether fee-for-service claims meet certain requirements, such as 
completeness of data. Specifically, if a claim did not include the 
HICN or other required data, the contractor's system would return it 
to the provider as incomplete or invalid. 

Once the aforementioned contractors' systems determine that claims 
meet initial data requirements, the contractors use one of three CMS 
systems, depending on the type of claim, to continue and complete 
claims processing.[Footnote 12] These systems, referred to as "shared 
systems" (because they are used to continue processing claims received 
from all the Medicare Administrative Contractors), use the HICN to 
retrieve data from the contractors' files about the beneficiary for 
whom the claim is submitted. The shared systems apply additional 
coverage and payment policy criteria, such as whether a certain 
treatment or service is allowed, and may approve the claims 
submission, automatically deny claims that do not meet these criteria, 
or flag them for review by staff. Approved claims are sent by the 
shared systems to the central CMS system that authorizes payment for 
claims. This system, known as the Common Working File, verifies 
beneficiary eligibility, coordinates Part A and Part B benefits, and 
determines the extent of Medicare's responsibility for payment based 
on such factors as whether beneficiaries' deductibles have been met. 
Electronic inputs to the Common Working File include the HICN, which 
is used to retrieve data from the Enrollment Database that are 
relevant to eligibility and coverage determinations. After being 
processed by the Common Working File, claims are returned to the 
appropriate shared system for final processing, and, if determined to 
be valid, payments are sent to the providers who filed the claims. The 
Common Working File also provides transaction data to other systems, 
including HETS, on a daily basis. These data are used to update those 
systems' databases. 

In addition to using the HICN to support the provision of and payment 
for health care to Medicare beneficiaries, CMS and its federal 
stakeholders, SSA and the Railroad Retirement Board, use the number to 
share data needed to coordinate health insurance coverage and payments 
for premiums. In this regard, CMS provides information that includes 
the number to SSA when beneficiaries' eligibility status or other data 
change, and SSA refers to the HICN when beneficiaries request 
replacement of lost Medicare cards. CMS also shares data that include 
the number with the Railroad Retirement Board when it administers 
health benefits for railroad retirees who are eligible for Medicare. 
[Footnote 13] 

Further, CMS and the 56 state and territorial Medicaid programs share 
data based on beneficiaries' HICNs. Specifically, these programs 
provide the number along with other data on their beneficiaries that 
are used to help identify individuals who are eligible for both 
Medicare and Medicaid benefits. The states also provide information 
regarding Medicaid beneficiaries for whom their programs pay Medicare 
Part A or B premiums. In turn, CMS provides several types of data to 
the Medicaid programs based on the HICN, including data needed to 
coordinate payment for claims when a beneficiary is covered by 
multiple insurers and information on the current drug prescription 
insurer for beneficiaries who are covered by Medicare Part D private 
plans. Figure 2 depicts a simplified view of the flow of data and the 
use of the HICN in CMS's and its stakeholders' systems. 

Figure 2: Flow of Data and Use of the Health Insurance Claim Number in 
CMS's and Medicare Stakeholders' Systems: 

[Refer to PDF for image: flow diagram] 

Social Security Administration: 
Sends Social Security Number (SSN), Beneficiary Identifier Code (BIC), 
and other beneficiary data to Centers for Medicare and Medicaid
Services (CMS). 

Centers for Medicare and Medicaid Services (CMS): 
Sends card to beneficiary; 
Creates Health Insurance Claim Number and updates Medicare Enrollment 
Database System[A]. 

Railroad Retirement Board: 
Sends SSN, BIC, and other beneficiary data to Medicare Enrollment 
Database System[A]. 

Beneficiary: 
Beneficiary identifier sent to Provider. 

Medicare Beneficiary Database Suite of Systems[A]: 
Beneficiary eligibility data sent to HIPAA Eligibility Transaction 
System[A]; 

Utilization data received from Common Working File[A]. 
Eligibility data, premiums to and from State Medicaid agencies; 
Medicare Enrollment Database System[A]: 
Service eligibility data sent to Common Working File[A]. 

HIPAA Eligibility Transaction System[A]: 
Verify beneficiary eligibility to and from Provider. 

Provider: 
Submit claim to Medicare Administrative Contractor (MAC) systems[A]. 

Medicare Administrative Contractor (MAC) systems[A]: 
Claims data sent to Shared systems (Fiscal Intermediary Standard 
System, Multi-carrier System, ViPS Medicare System[A]. 

Shared systems[A]: 
Adjudicated claims data sent to MAC systems[A]; 
Prepayment claims to Common Working File[A]; 

MAC systems[A]: 
Payment to Provider; 
Medicare summary notice to Beneficiary; 
Claims payment information to Coordination of benefits contractor. 

Common Working File[A]: 
Claims authorized for payment to Shared systems[A]. 

Coordination of benefits contractor: 
Payment information to Private Health plans; 
Payment information to State Medicaid agencies. 

Source: GAO analysis of CMS data. 

[A] Centers for Medicare and Medicaid Services systems. 

[End of figure] 

CMS's IT Environment and Modernization Initiatives: 

In 2010, CMS officials developed a plan to upgrade the agency's IT 
environment and noted that the modernization of enterprise information 
systems and the supporting infrastructure was necessary in order for 
CMS to continue to meet its mission. Further, two scientific advisory 
committees that later evaluated CMS's IT environment[Footnote 14] 
found that the agency operated in a "stove-piped" environment in which 
many systems were developed to meet specific time-sensitive and 
legislatively driven needs, such as claims processing and eligibility 
determination, without consideration of the need for systems to 
interoperate or integrate data from other sources. The committees 
indicated that, because the agency continues to operate in such an 
environment, enhancement and sharing of data across its systems can be 
costly, risky, and time-consuming. 

In 2013 the agency took steps to update the 2010 IT modernization 
plan. According to officials in the Office of Information Services, 
this was to address recommendations resulting from the two advisory 
committees' evaluations. These officials described seven goals of the 
plan, the first of which is to establish an architecture that supports 
the development and implementation of IT functions, known as "shared 
services," that can be provided to support multiple needs of 
organizations conducting business within or between federal agencies. 
[Footnote 15] Other goals include, but are not limited to, the 
transformation of the agency's IT operations to enable CMS to use 
technologies such as cloud computing and virtual data centers; 
improvements to privacy and security controls to better protect 
personal health information stored and processed by the agency; and 
the transition to a coordinated, enterprise approach toward developing 
and implementing IT solutions. The Chief Information Officer stated 
that the agency was continuing to work toward addressing the seven 
goals defined in 2013. 

Prior Reports on CMS's and Other Agencies' Use and Display of SSNs: 

Both the SSA and HHS inspectors general have reported on risks 
associated with the use of the SSN on Medicare cards and have 
recommended that SSA and CMS work toward identifying alternate 
identifiers to better safeguard Medicare beneficiaries' SSNs.[Footnote 
16] Additionally, we have previously issued reports that addressed 
federal agencies' use and display of SSNs on identification cards and 
for other purposes, as well as CMS's study of this issue. 

In a 2004 study, we found that SSNs were widely exposed to view in a 
variety of public records, particularly those held by state and local 
governments, and appeared in some public records nearly everywhere in 
the nation.[Footnote 17] We reported that SSNs are a key piece of 
information used in identity thefts, and that the widespread use and 
retention of the number by both the public and private sectors may 
provide opportunities for criminals to easily obtain and misuse this 
personal information. We stressed that the display of nine-digit SSNs 
on such cards, which may need to be carried and must often be 
disclosed, puts cardholders at risk for identity theft due to the 
increased potential for accidental loss, theft, or visual exposure. To 
help mitigate this risk, we recommended that the Office of Management 
and Budget (OMB) identify those federal activities that require or 
engage in the display of SSNs on health insurance, identification, or 
any other cards issued to federal government personnel or program 
beneficiaries, and devise a governmentwide policy to ensure a 
consistent approach to this type of display. In response to our 
recommendation, in May 2007 OMB issued a memorandum that required 
federal departments to establish a plan to eliminate unnecessary use 
of SSNs. 

We reported again in 2006 that there were gaps in federal requirements 
for protecting SSNs.[Footnote 18] Specifically, we noted that Congress 
could consider possible options for addressing gaps related to 
safeguarding SSNs shared with contractors by private companies. We 
also reported in 2006 that the threat of identity theft was heightened 
by the visual display of SSNs on federal identification 
cards.[Footnote 19] We noted that there were gaps in federal and state 
agencies' practices for protecting SSNs and that Congress was still 
considering actions to address the issues that remain. 

More recently, in 2012 we assessed the results of CMS's 2011 study of 
the cost and effort associated with three approaches to removing SSNs 
from Medicare cards.[Footnote 20] As a result of our assessment, we 
reported in August 2012 that CMS had not committed to removing the 
SSNs and lagged behind other federal agencies. We recommended that the 
agency select an approach for removing the SSN from the Medicare card 
that best protects beneficiaries from identity theft and minimizes 
burdens for providers, beneficiaries, and CMS. We also recommended 
that it develop an accurate, well-documented cost estimate for such an 
option using standard cost-estimating procedures. CMS officials 
concurred with our recommendations and, as discussed later in this 
report, took actions to address them. 

CMS Has Not Actively Pursued an IT Solution but Has Taken Actions That 
Could Support Efforts to Do So: 

CMS has not yet taken steps needed to select and implement a technical 
solution for removing SSNs from Medicare cards. Since 2006, the agency 
has conducted three studies on potential approaches to replacing the 
SSN-based Medicare identifier, issuing reports to Congress on the 
results of those studies in October 2006, November 2011, and May 2013. 
[Footnote 21] However, while each of the studies addressed, at a high 
level, the impact of various approaches on CMS's IT environment, they 
were not intended to identify a specific technical solution for 
removing SSNs from cards. 

Specifically, according to CMS, a 2006 study was initiated in response 
to congressional concerns regarding identity theft and expectations 
that the Secretary of Health and Human Services would accelerate 
ongoing plans to convert the HICN to a non-SSN based identifier for 
display on Medicare beneficiaries' health insurance cards. The second 
study was conducted to respond to congressional requests for CMS to re-
examine approaches and costs of removing the SSN from the cards. 
Officials in the Office of Information Services, the CMS entity that 
would be responsible for identifying and implementing a technical 
solution for SSN removal, stated that the 2006 and 2011 studies were 
intended to develop "rough order of magnitude" estimates of costs and 
efforts associated with a potential SSN removal project. 

In response to a request by congressional committee members and to 
address our August 2012 recommendation,[Footnote 22] the agency 
initiated a third study in August 2012 and issued the resulting report 
to Congress in May 2013. According to CMS officials, the third study 
was conducted to provide cost estimates that were more reliable than 
those previously reported. The new estimates for two approaches 
documented in the 2013 report were approximately $255 million and 
approximately $317 million, including the cost of efforts to develop, 
test, and implement modifications that would have to be made to the 
agency's IT systems. The costs of the IT-related efforts for the two 
approaches were estimated at about $26 million (10 percent of the $255 
million total estimated cost) and $64 million (20 percent of the $317 
million total estimated cost), respectively.[Footnote 23] According to 
the May 2013 report, the estimates were based on the assumption that 
these efforts would span an 18-month period, from October 2013 to 
April 2015. According to Office of Information Services officials, 
however, these costs and schedules represented high-level estimates 
based on the two overall approaches and did not fully reflect the 
effort that would be required to implement a specific IT solution. 
Furthermore, while the 2013 report noted that one of the two 
approaches would better protect beneficiaries' personal information, 
the officials said that the agency did not intend for this study to 
result in the identification of an IT solution to address SSN removal. 

CMS officials stated that any initiatives specifically intended to 
identify an IT solution to address SSN removal would need to be 
conducted in accordance with departmental processes and requirements 
for managing the life cycle of IT projects.[Footnote 24] In this 
regard, CMS's IT project life-cycle management guidance, the Expedited 
Life Cycle (XLC) framework, defines the activities that are required 
to execute and monitor the development of IT projects throughout five 
phases--project initiation, requirements analysis and design, 
development and test, implementation, and operations and maintenance. 
The framework requires the following activities to be completed as 
part of a project initiation phase before the IT organization takes 
subsequent steps to identify technical solutions that support business 
needs: 

* designate a business owner to serve as an advocate for the project; 

* identify a business need for which a technological solution is 
required and a business case is established; 

* explore alternative concepts and methods to satisfy the need; 

* develop and approve initial project cost, preliminary schedule, 
performance baseline, and basic business and technical risks; 

* conduct a preliminary enterprise architecture review to determine 
whether the proposed project potentially duplicates, interferes with, 
contradicts, or can leverage another project that already exists or is 
proposed, under development, or planned for near-term disposition; 

* identify significant assumptions and constraints on solutions 
relative to that need; 

* issue a project charter; and: 

* conduct a selection review to determine if the proposed project is 
sound, viable, and worthy of funding, support, and inclusion in the 
information technology project portfolio. 

However, CMS has not taken a number of the key steps called for by the 
IT project life-cycle management guidance to identify an IT solution 
to address SSN removal and has not made plans to do so. For example, 
it has not completed several steps of a project initiation phase, such 
as designating a business owner who would submit a request to the 
Chief Information Officer to initiate an IT project. Additionally, the 
agency has not established a business case for developing an IT 
solution to address SSN removal, issued a project charter, or 
presented a potential IT project for SSN removal to an architectural 
review board for preliminary review and approval. Furthermore, CMS has 
not conducted a selection review to determine if such an IT project 
should be included in its portfolio of IT investments. 

Nonetheless, when conducting the 2013 study, agency officials 
undertook activities that could address certain steps called for by 
the agency's IT project life-cycle management processes for initiating 
a project, and that could provide information needed for identifying 
and implementing a technical solution, including the following: 

* CMS officials and program stakeholders explored alternative concepts 
for addressing the business need, which is one of the steps called for 
by agency IT project management guidance. Specifically, from September 
2012 through December 2012, Railroad Retirement Board and SSA 
officials participated in work groups with CMS to determine potential 
approaches to SSN removal. As a result, they identified two 
approaches: (1) replacing the SSN-based HICN with a new identifier 
that does not include the SSN, referred to as the Medicare Beneficiary 
Identifier; and (2) truncating the first five digits of the SSN for 
display on Medicare cards. Agency officials conducting the study ruled 
out other options, such as embedding the number in smart cards or 
magnetic strips, because they were determined to be too costly, 
technically infeasible, or burdensome to providers and beneficiaries. 

* Project officials collected information that could be used to 
develop initial project costs and identify basic business and 
technical risks associated with implementing each approach. 
Specifically, officials conducting the 2013 study collected data that 
could be used for establishing a technical baseline for cost 
estimates, such as the level of effort system owners estimated would 
be required for each life-cycle phase.[Footnote 25] Project officials 
also collected input from system and business owners regarding 
technical and business risks associated with the two approaches. For 
example, the owners of one of the shared systems described a risk that 
unacceptable processing times would result from the implementation of 
a mechanism for translating between the HICN and a new identifier. 
This information could be useful in identifying efficient translation 
mechanisms that would be less likely to introduce such a risk. 

* Agency officials took steps to determine the changes that would have 
to be made throughout the agency's and program stakeholders' IT 
environment. The results of these actions could provide information 
essential to conducting a preliminary enterprise architecture review--
another step required for initiating an IT project. Specifically, 
officials conducting the 2013 study identified internal and external 
stakeholder systems that could be affected if the SSN was removed from 
cards, and identified other IT initiatives that could be coordinated 
with an SSN removal project. For example, during the 2013 study, CMS 
system and functional-level business owners conducted high-level 
impact assessments of the two approaches on the agency's business 
processes and all systems identified in its information technology 
inventory.[Footnote 26] Of CMS's more than 200 systems, these 
officials identified 72 systems that could be affected by the 
introduction of a new identifier and 41 that would be affected by the 
second approach (masking the first 5 digits of the SSN).[Footnote 27] 
They conducted high-level assessments of the types of changes that 
would need to be made to those systems, including the level of 
complexity of the changes, the number of hours of work at each life-
cycle phase, and the potential to leverage related efforts. Appendix 
II provides a detailed assessment of the types of system changes that 
would have to be made to three internal CMS systems that provide 
functionality key to determining beneficiaries' eligibility for 
specific treatments and services, validating and adjudicating Part A 
claims, and sharing data for coordination of benefits payment between 
Medicare and program stakeholders. 

* Agency officials also established assumptions regarding the two 
approaches for SSN removal. For example, when collecting data 
regarding the impact on its internal systems, system owners were 
instructed to assume that a crosswalk service would be available to 
translate the HICN to a new identifier, and that the new identifier 
would retain the same length as the existing HICN but have a different 
format. CMS officials also established assumptions regarding 
conditions under which data exchanged with external stakeholders would 
include either number. 

* CMS collected data from its federal partners to estimate the impact 
of the proposed approaches on external systems. For example, officials 
conducting the 2013 study collected level-of-effort estimates from SSA 
and the Railroad Retirement Board for implementing changes to their 
affected systems. Although their estimates varied, the changes these 
stakeholder officials described were similar. SSA officials stated 
that they would have to make system changes to identify beneficiaries 
when they contact SSA and provide the new identifier, instead of the 
HICN, to request a new Medicare card. Railroad Retirement Board 
officials also stated that they would have to make changes in order to 
use the new identifier instead of the HICN when issuing or replacing 
retirees' Medicare cards.[Footnote 28] 

* CMS also involved state program stakeholders and collected high-
level estimates of changes that would have to be made to states' 
Medicaid systems.[Footnote 29] Because each state implements IT 
solutions to support its unique Medicaid program, the design, 
implementation, and level of effort estimated to modify their systems 
varied widely. For example, we assessed Medicaid program estimates 
provided to CMS by eight states. Of these, three states estimated that 
less than 500 hours would be needed to make the changes, in part 
because some of the systems already convert identifiers. One of these 
states reported that no effort would be required since their systems 
were already capable of updating records when changes to identifiers 
are made. On the other hand, officials with another state Medicaid 
program estimated that about 22,000 hours of effort would be needed 
to, among other things, expand databases to include a new identifier, 
and another estimated that over 58,000 hours would be required to 
modify systems to process functions based on a new identifier, 
including Medicare buy-in,[Footnote 30] eligibility determination, and 
Part D processing systems. Three other states estimated around 4,000 
hours of work to implement mechanisms to cross reference or convert 
the HICN to a new identifier. 

While the data and information collected during the 2013 study could 
be leveraged to support a future IT project to address SSN removal, 
according to officials with CMS's Office of Information Services, the 
agency's Chief Information Officer has not received direction from 
CMS's leadership to submit a proposal for an IT project that would 
lead to the identification, development, and implementation of a 
technical solution. We have noted in prior reports the importance of 
protecting Medicare beneficiaries from increased risks of identity 
theft, and OMB has required federal agencies to take steps to 
eliminate unnecessary uses of SSNs. We have also noted that federal 
agencies' Chief Information Officers are responsible for, among other 
key IT management areas, information security along with systems 
development and integration.[Footnote 31] Additionally, CMS has 
designated the Office of Information Services as the lead for 
developing and enforcing the agency's IT policies, standards, and 
practices. As such, these entities should play an active role in 
pursuing IT solutions for securing personal data, such as Medicare 
beneficiaries' SSNs. The data and information the Office of 
Information Services collected during the 2013 study could provide 
valuable input to future efforts to define such a solution. 
Nonetheless, until the agency designates a business owner, establishes 
a business case, issues a project charter, and conducts architectural 
and IT project selection reviews for SSN removal, it will lack 
sufficient information and resources needed to actively pursue the 
identification of an IT solution for SSN removal that best protects 
beneficiaries' identities. 

CMS Has Initiated Actions Intended to Address Modernization Goals That 
Could Facilitate SSN Removal but Has Not Made Specific Plans for 
Leveraging Efforts: 

CMS has efforts under way to modernize its IT systems, a number of 
which could be leveraged to facilitate the removal of SSNs from 
Medicare cards. For example, one of the agency's modernization goals 
is to establish IT functionality that can be used to support multiple 
business needs of organizations and facilitate data sharing among the 
agency and its stakeholders. This and other goals were described by 
Office of Information Services officials who indicated that the agency 
is in the process of developing an agencywide IT modernization 
strategy to align with newly defined business goals. 

A well-defined modernization strategy includes plans for systems that 
are integrated into an enterprise's IT environment and that do not 
duplicate other systems' functionality. By planning accordingly, 
agencies increase the likelihood that they will design and develop 
systems that easily exchange information with other systems and 
improve their ability to modernize systems in a timely and cost-
effective manner.[Footnote 32] 

In this regard, CMS has initiated actions that could eliminate 
duplicative programming efforts and help establish standards for 
integrating new systems and making the modifications to existing 
systems needed to implement an IT solution for SSN removal. For 
example, CMS officials with the Office of Information Services 
described modernization projects that were initiated to support 
administrators' ability to carry out other programs and that were 
aligned with the first of the seven stated modernization goals--to 
establish an IT architecture capable of supporting the development and 
implementation of shared services. Specifically, the agency 
established such an architecture to implement five shared services to 
support the administration of other agency programs, including but not 
limited to, programs established by the Affordable Care Act. The 
shared services are: 

* Enterprise Identity Management, which is planned to enable 
individuals to use a single online identity (e.g., user ID) for 
engaging in business with CMS that meets all federal security 
requirements; 

* Master Data Management, which is a suite of data records and 
services that will allow CMS to link and synchronize beneficiary, 
provider, and organization data to multiple disparate sources; 

* Enterprise Portal, a central channel for beneficiaries, providers, 
organizations, and states to receive CMS information, products, and 
services via consistent web pages; 

* Business Rules Enterprise Service, which provides a framework for 
automating and managing decision logic and routines for CMS programs 
(e.g., provider and beneficiary cross check for Accountable Care 
Organization programs); and: 

* Enterprise Eligibility, a consistent and reusable way for business 
applications to access beneficiary eligibility data for a variety of 
uses (e.g., claims processing, providers and plans, and external 
programs). 

In implementing these services, the agency has taken some steps that 
could help define and put into place the necessary architectural 
components and standardized interfaces to enable sharing of the 
services' capabilities across the IT infrastructure and CMS's business 
areas. 

One of the five shared services that CMS implemented, the Business 
Rules Enterprise Service could facilitate the implementation of an IT 
solution for SSN removal. For example, the IT infrastructure that was 
established to implement the service could support the implementation 
of a crosswalk service needed by multiple systems to translate a new 
identifier to the HICN (and vice versa). By providing this 
functionality through a shared service, the crosswalk would be 
available for use by any system within CMS's IT infrastructure and 
therefore eliminate the need to duplicate programming efforts for each 
system to implement such functionality. Specifically, if such a shared 
service were implemented to support an SSN-removal IT project, it 
would be available for use by all the systems that, according to CMS 
officials, would have to be modified to use a new identifier. As a 
result, of the 20 systems that the agency estimated would account for 
86 percent of the costs to modify, systems changes would only have to 
be developed and tested for one implementation rather than for 18 of 
the 20 systems that would need to perform a crosswalk between a new 
identifier and the existing HICN.[Footnote 33] 

In addition to the five shared services described, another shared 
service, the Beneficiary Data Streamlining service, was designed to 
consolidate into one system the functionality for determining fee-for-
service eligibility that is currently implemented in four different 
systems (the Common Working File and the three shared systems). This 
new service, which is planned to be implemented in October 2013, would 
be used by these systems to eliminate duplicate or unnecessary 
processing. Consequently, the implementation of the service could also 
facilitate SSN removal efforts. For example, it could reduce the 
extent of modifications that would have to be made to the four systems 
by eliminating the need to make changes to their current eligibility 
determination functions to process a new non-SSN-based identifier. 
Instead, that capability would be provided by the new service. As a 
result, the agency could save unnecessary costs and efforts associated 
with duplicative programming changes to the four affected systems. 

While these projects could offer opportunities for leveraging ongoing 
modernization initiatives to facilitate SSN removal, CMS officials 
stated that because the agency has not yet established a business case 
and IT project for removing SSNs from Medicare cards, they have not 
included shared services or other IT initiatives in their 
modernization activities and related plans to specifically support 
changes needed as a result of SSN removal. Until CMS establishes an IT 
project for SSN removal that could be incorporated into ongoing 
agencywide modernization initiatives, it may miss opportunities to 
leverage other ongoing system development activities that could 
facilitate efforts to design, develop, and implement an IT solution in 
a timely and cost-effective manner. 

Conclusions: 

While CMS has spent time and resources over the past 7 years studying 
approaches that could be taken toward removing the SSN from Medicare 
beneficiaries' cards, the agency has not actively established and 
pursued a goal to identify an IT solution for doing so. The efforts 
made thus far by CMS and its stakeholders could provide some of the 
information needed to initiate an IT project to design and develop the 
system changes that would have to be made to address an agencywide 
effort to better safeguard Medicare beneficiaries' identity. However, 
until the agency takes other critical steps, such as designating a 
business owner, establishing a business case, issuing a project 
charter, and conducting architectural and IT project selection 
reviews, it will not be in a position to design, develop, and 
implement the changes that would have to be made to systems affected 
by the removal of SSNs from display on Medicare beneficiaries' health 
insurance cards. Additionally, the agency may miss opportunities to 
improve the timeliness and cost effectiveness of any actions taken to 
develop and implement a technical solution that could be achieved if 
it incorporated such actions into plans for ongoing enterprisewide IT 
modernization initiatives. 

Recommendations for Executive Action: 

To better position the agency to efficiently and cost-effectively 
identify, design, develop, and implement an IT solution that addresses 
the removal of SSNs from Medicare beneficiaries' health insurance 
cards, we recommend that the Administrator of CMS take the following 
two actions: 

* direct the initiation of an IT project for identifying, developing, 
and implementing changes that would have to be made to CMS's affected 
systems, including designating a business owner and establishing a 
business case, issuing a project charter, and conducting project 
selection and architectural reviews of proposed approaches for the 
removal of SSNs from Medicare beneficiaries' cards; and: 

* incorporate such a project into plans for ongoing enterprisewide IT 
modernization initiatives. 

Agency Comments and Our Evaluation: 

In written comments on a draft of this report, signed by HHS's 
Assistant Secretary for Legislation (and reprinted in appendix III), 
HHS stated that it appreciated the opportunity to review the report 
prior to its publication. Further, the department stated that it 
concurred with both of our recommendations under the condition that 
certain constraints were addressed. 

With respect to our first recommendation, HHS agreed that removing the 
SSN from Medicare cards is an appropriate step toward reducing the 
risk of identity theft, but that the agency could not make a decision 
to proceed with such a project without agreement from SSA and the 
Railroad Retirement Board. In addition, the department stated that a 
clear source of funding for both IT and non-IT activities associated 
with SSN removal would need to be identified before proceeding. 
However, as we noted in our report, CMS's Chief Information Officer 
and the Office of Information Services should play an active role in 
pursuing IT solutions for securing personal data, such as Medicare 
beneficiaries' SSNs. For this reason, it is important that CMS 
determine the appropriate actions to take toward initiating an IT 
project for addressing the removal of SSNs from cards and guide its 
stakeholders, such as SSA and the Railroad Retirement Board, in taking 
the steps needed to achieve the goals of any SSN removal project. In 
addition, the final step of the IT project initiation phase, as 
defined by CMS's IT life-cycle project management guidance, is a 
review to determine if proposed projects are worthy of funding and 
inclusion in an IT project portfolio. Accordingly, uncertainties 
regarding a clear source of funding should not constrain CMS from 
taking steps to initiate an IT project to address SSN removal. 

Regarding our second recommendation, HHS concurred, again with the 
caveat that the above-mentioned constraints were addressed. The 
department also noted that while CMS had not implemented its shared 
services initiative specifically for the purpose of SSN removal, the 
general functionality exists in the shared services to support this 
effort, and this was reflected in the agency's 2013 cost estimate. 
However, unless the agency considers SSN removal as part of its 
enterprisewide modernization initiative, it may miss additional 
opportunities for leveraging system changes being made as part of the 
modernization to support SSN removal. 

In this regard, we believe that CMS is currently positioned to 
implement both our recommendations, regardless of perceived 
constraints, and to take the actions needed to initiate an IT project 
as part of its agencywide modernization initiative. If such actions 
are taken CMS could improve HHS's ability to protect Medicare 
beneficiaries against increased risk of identity theft introduced by 
the use of SSNs on Medicare cards. HHS also provided technical 
comments, which we incorporated into the report as appropriate. 

As agreed with your offices, unless you publicly announce the contents 
of this report earlier, we plan no further distribution until 30 days 
from the report date. At that time, we will send copies to the 
Secretary of HHS and interested congressional committees. In addition, 
the report will be available at no charge on the GAO website at 
[hyperlink, http://www.gao.gov]. 

If you or your staffs have any questions about this report, please 
contact me at (202) 512-6304 or melvinv@gao.gov. Contact points for 
our Offices of Congressional Relations and Public Affairs may be found 
on the last page of this report. GAO staff who made key contributions 
to this report are listed in appendix III. 

Signed by: 

Valerie C. Melvin: 
Director: 
Information Management and Technology Resources Issues: 

[End of section] 

Appendix I: Objectives, Scope, and Methodology: 

The objectives of our review were to (1) assess the actions the 
Centers for Medicare and Medicaid Services (CMS) has been taking to 
identify and implement information technology (IT) solutions for 
removing Social Security numbers (SSN) from Medicare beneficiaries' 
cards, and (2) determine whether CMS's ongoing information technology 
modernization initiative could offer opportunities to facilitate 
efforts to remove the SSN from the cards. 

To determine the extent to which CMS has been taking steps to 
implement a technical solution for removing the SSN from Medicare 
cards, we examined studies conducted by agency officials in 2006, 
2011, and 2013 of different approaches.[Footnote 34] We reviewed 
supporting documents that were used by project officials to gather 
information from system and business owners regarding the impact that 
two approaches would have on the agency's IT systems, including 
estimates of the levels of effort that would be needed to implement 
the changes that would have to be made to affected systems. We 
assessed the data from these documents, referred to as "workbooks," to 
determine the steps agency officials took that could be used to 
identify a technical solution for the two approaches-one to introduce 
a new identifier that does not include the SSN and another to mask the 
first five digits of the SSN in the existing SSN-based identifier, the 
Health Insurance Claim Number (HICN). We determined which activities 
resulted in outcomes that could be used to initiate actions towards 
identifying a specific technical solution by comparing documented 
results of CMS's efforts to requirements defined by CMS's processes 
for managing information technology projects to develop and implement 
technical solutions for business processes.[Footnote 35] 

To better understand the extent of changes that would have to be made 
to the systems, we assessed a sample of the systems that the agency 
identified as being affected by the removal of the SSN from cards and 
replacement with a unique, non-SSN-based number. To select the systems 
for our sample, we obtained and analyzed system impact workbooks for 
29 systems that we determined accounted for over 90 percent of the 
total estimated level of effort needed to modify existing systems to 
process the new identifier. Based on our assessment, we determined 
that these systems provided adequate examples of the types of system 
modifications that would be required to implement a technical solution 
for agencywide efforts to remove the SSN from Medicare cards. 
Additionally, we focused our analysis of the data included in the 
workbooks on the option to replace the SSN-based identifier, the HICN, 
on the Medicare card with a new identifier since findings resulting 
from our prior assessment of CMS's 2011 report on SSN removal 
established this option as the one most likely to protect 
beneficiaries' SSNs and help prevent identify theft.[Footnote 36] From 
the 29 systems, we selected 3--1 system that represented a low level 
of effort based on the estimated levels of effort reported by system 
and business owners in the workbooks, 1 that represented a high level 
of effort, and 1 of the shared systems that performs a critical 
function--fee-for-service claims processing. To determine the types of 
changes that would have to be made to the systems, we examined 
technical documents to identify architectural components, data types, 
message formats, and interfaces with other systems that would have to 
be modified to either translate a new identifier to the HICN for 
internal processing, or translate the HICN back to the new identifier 
for purposes such as printing notices or new cards. We also held 
discussions with owners of the selected systems to confirm our 
understanding of the systems and related files and databases, along 
with the functionality they provide. In addition, we held discussions 
with CMS officials from the agency's Office of Information Services, 
including the Chief Information Officer, regarding actions taken to 
complete the 2013 study, particularly steps taken to collect 
information regarding the impact on CMS's existing IT systems. 

To further address the first objective, we determined the extent to 
which CMS involved stakeholders to estimate the levels of effort that 
would have to be made to address the two approaches for removing the 
SSN from Medicare cards. To do so, we reviewed documentation that 
described the actions CMS took to solicit input from its federal 
Medicare and state Medicaid program stakeholders, such as CMS's most 
recent report to Congress and documented results of stakeholders' 
assessment of the impact the SSN removal would have on their systems. 
[Footnote 37] We obtained and analyzed such documentation from the 
Social Security Administration and the Railroad Retirement Board, 
CMS's two federal program stakeholders. To select states for our 
study, we examined documents that were provided by 49 states and the 
District of Columbia in response to CMS's request for data related to 
the system changes that would have to be made. We then calculated the 
median level of effort estimated and selected states whose estimates 
represented high, medium, and low levels of effort.[Footnote 38] 
Specifically, we identified the 3 states that estimated the highest 
level of effort, 4 states that estimated a medium (or closest to the 
median) level of effort, and the 3 that estimated the lowest level of 
effort. Of the 10 that we selected, we received responses from 8--the 
3 lowest, 3 of the medium, and 2 of the highest estimators. We 
assessed the data they provided to CMS and collected additional data 
by conducting semistructured interviews or through written responses 
to a standard set of questions. While we could not generalize the 
information we collected from the 8 states to reflect the level of 
participation by all 49 states and the District of Columbia, the views 
obtained from these state officials offered insights into the extent 
to which CMS involved its program stakeholders in assessing approaches 
for removing SSNs. We also held discussions with program stakeholders 
from each of the federal and state entities. 

To address the second objective, we identified criteria by examining 
federal laws and guidance on the importance of planning for 
modernization to guide systems development,[Footnote 39] and compared 
CMS's actions to identify potential system changes for SSN removal to 
these criteria. To do so, we examined modernization plans and 
briefings describing CMS's goals for modernizing the agency's IT 
environment along with documents that described the agency's ongoing 
modernization initiatives. Specifically, we examined CMS's plan for 
developing shared services, one of the modernization goals described 
by the Chief Information Officer and officials from the Office of 
Information Services. We then compared information obtained from this 
plan to descriptions of modifications to systems that would have to be 
made if the SSN were removed from cards. We also reviewed 
documentation provided to the Office of Information Services by the 
owners of these systems to identify other IT projects that could 
facilitate the development and implementation of a technical solution 
for an SSN removal effort. We interviewed CMS officials, including the 
Chief Information Officer, to obtain additional information regarding 
the agencywide IT modernization goals and objectives and the extent to 
which the goals and objectives addressed the removal of SSNs from 
Medicare cards. 

For each of the objectives, we assessed the reliability of the 
documentation we received from CMS, including the workbooks and 
technical documentation, by obtaining corroborating evidence through 
interviews with the agency's system and business owners who were 
knowledgeable of the various systems, the individuals who were 
responsible for filling out the workbooks at the states, and 
individuals knowledgeable about CMS's modernization efforts, including 
the Chief Information Officer. Based on how we used the information 
and the corroborating evidence provided in the interviews, we 
determined that the documentation and data provided by the agency were 
sufficiently reliable for the purposes of our review. 

We conducted this performance audit from October 2012 to September 
2013 in accordance with generally accepted government auditing 
standards. Those standards require that we plan and perform the audit 
to obtain sufficient, appropriate evidence to provide a reasonable 
basis for our findings and conclusions based on our audit objectives. 
We believe that the evidence obtained provides a reasonable basis for 
our findings and conclusions based on our audit objectives. 

[End of section] 

Appendix II: GAO's Assessment of Three CMS Systems and the Types of 
Potential Changes Needed to Support SSN Removal: 

We selected three systems for assessment to better understand the 
types of changes that would have to be made to process beneficiary 
data based on the introduction of a new identifier, or Medicare 
Beneficiary Identifier (MBI), to replace SSNs as data entered into the 
systems. The three systems are the HIPAA Eligibility Transaction 
System (HETS), the Fiscal Intermediary Standard System (FISS), and the 
Medicare Beneficiary Database Suite of Systems (MBDSS). (See app. I 
for a description of the methodology used to select and assess the 
systems.) The following tables provide descriptions of the systems and 
the functionality they provide, the number of hours that owners of the 
systems estimated would be required to modify the systems, and a 
summary of the technical characteristics and components (e.g., the 
programming languages and tools, software applications, data bases, 
data storage files, and outcomes of data processing) that would have 
to be considered in estimating the impact of removing SSNs from 
Medicare cards on these systems. Our assessments were conducted based 
on information collected from technical documentation relevant to each 
of the systems and from discussions with system owners in CMS's Office 
of Information Services. 

Table 1: Description of HETS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Description: 
HETS was developed and implemented in 2005 to process 
query and response transactions that release patients' data to Medicare 
providers, or their authorized billing agents, to support their efforts 
to complete accurate Medicare claims when determining beneficiary 
liability and eligibility for specific services. 

Users and stakeholders: 
Medicare providers, suppliers, or their 
authorized billing agents. 

System and business owner(s): 
CMS's Business Applications Management 
Group and Provider Communications Group. 

CMS preliminary estimate of hours required to modify systems for SSN 
removal: 
CMS estimated that it would require 1900 hours (0.99 FTEs) to 
modify HETS to replace the SSN on the Medicare card with an MBI, with 
more than half of the hours required for development and system 
testing. This estimate is about 0.5 percent of the total effort 
estimated for the 29 systems from which we selected examples. 

Databases, key systems operations, and use of HICN: 
HETS is comprised of applications and databases. Users access HETS 
through one of two means, HETS 270/271 and HETS User Interface 
(UI).[A] According to officials, approximately 99.5 percent of queries 
are submitted to and processed by the 270/271 system. A key 
application of HETS, the Data Access Service, is used to access 
beneficiary data housed in the Integrated User Interface (IUI) 
database. Another database, referred to as the HETSLOG, records 
information about all HETS transactions, including the date, time, 
response time, and error messages. The HETSLOG and IUI databases 
include the HICN. HETS operates from CMS's data center in Baltimore, 
Maryland, and is accessed by users via the CMS extranet.[B] The system 
is comprised of software that processes query and response 
transactions, along with hardware, such as servers that support 
connections with users' facilities and the Internet, and devices that 
store the data provided by the system. The system software is designed 
to process transactions according to standards and formats defined by 
HIPAA. To request beneficiary eligibility information, HETS users 
submit beneficiary information, including the HICN, first and last 
name, and date of birth. Users can also request historical data for a 
beneficiary's eligibility. To protect the privacy of beneficiary 
information, the system checks for mismatches between the HICN and 
other data, and provides responses to errors occurring as a result from 
such mismatches. If the request does not have errors, the system 
queries the IUI database to retrieve information on the beneficiary's 
eligibility and responds to the provider. HETS creates a record of the 
query and the response. The response may include information about a 
beneficiary, including eligibility and deductible information for 
different services; information on preventive programs for the 
beneficiary, such as smoking cessation; plan coverage for Medicare 
Parts C and D; and information on the beneficiary's use of hospice and 
skilled nursing facilities. 

System technical description: operating system(s), programming 
language(s), and lines of code: 
* HETS is designed based on a service-oriented architecture framework 
that includes services for retrieving, processing, and displaying the 
beneficiary information[C]; 
* The HETS IUI database is an Oracle database that contains Medicare 
eligibility data for more than 93 million beneficiaries. The HETSLOG 
database is also an Oracle database; 
* Operating system: Unix; 
* Programming languages and tools: XML, Java, Helpdesk, JCD, JSP, and 
SQL; 
* Estimated lines of code: Approximately 37,360 lines of code 
inclusive of XML, Java, Helpdesk, JCD, JSP, and SQL. 

Examples of potential changes needed to implement non-SSN-based 
identifier: 
* A data element would be added for the MBI to the HETSLOG and IUI 
databases, so that requests for eligibility information can be 
processed based on the MBI; 
* HETS would be modified to use the MBI for processing eligibility 
requests and for accessing eligibility data. This includes changes to 
allow searches with the MBI as one of the data elements; 
* CMS would need to replicate systems' front-end edits for validating 
HICN size, length, and other data-typing characteristics for the MBI. 
This will ensure that the user entered the MBI in an acceptable format; 
* Changes would need to be made for the 6-month transition period 
during which users will be able to submit requests using either the 
HICN or MBI. These include (1) the ability to determine whether a 
query is submitted with a HICN or an MBI; (2) the ability to return 
results containing the MBI even when a HICN was submitted; and (3) at 
the end of the 6-month transition, stop allowing requests based on 
HICN; 
* Reports would need to be created to track the number of users who 
transition to using MBI; 
* Online user manuals would need to be updated to include the MBI in 
place of the HICN for capabilities or screens that currently use the 
HICN, and possibly expand help desk activities to assist users in 
transitioning to use of the MBI. 

Source: GAO analysis of data provided by CMS. 

[A] CMS officials stated that they plan to phase out the HETS User 
Interface and expect to do so by the first half of calendar year 2014. 
HETS users are to continue to have access to the 270/271 system and 
HETS users will be able to obtain eligibility information using an 
online portal provided by Medicare Administrative Contractors which is 
to provide similar screens to those of the UI but which is to use the 
270/271 as the source of data. 

[B] An extranet is a computer network that allows controlled access 
from outside an organization's intranet, usually by partners, vendors, 
and suppliers, in isolation from all other Internet users. The CMS 
extranet is a secure closed private network used for transmission of 
electronic transactions between CMS and Medicare contractors, 
providers, or clearinghouses. 

[C] A service-oriented architecture is an approach for sharing 
functions and applications across an organization by designing them as 
discrete, reusable, business-oriented services. 

[End of table] 

Table 2: Description of FISS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Description: 
FISS is a shared system that processes Part A and certain types of 
Part B claims for medical services from institutional providers such 
as hospitals and skilled nursing facilities. According to agency 
officials, FISS was developed between 1989 and 1990. The system 
performs a range of actions necessary to process claims, including 
validating claims against edits, reporting on the status of submitted 
claims, adjudicating claims, providing information for coordinating 
claims payment between Medicare and other insurers, submitting 
approved claims for payment to providers, and creating a complete 
record of each claim for historical and audit purposes. FISS is 
designed to process claims in 3 days with a minimum of manual 
intervention. 

Users and stakeholders: 
Institutional providers, including hospitals, submit claims, and 
Medicare Administrative Contractors[A] use FISS to process the claims. 

System and business owner(s): 
CMS's Center for Medicare, Medicare Contractor Management Group. 

CMS preliminary estimate of hours required to modify systems for SSN 
removal: 
FISS owners estimated that it would require 5,251 hours (2.73 FTEs) to 
modify FISS for SSN removal. The majority of the effort would be 
required for requirements analysis and design, development and 
testing, and implementation. This estimate is about 1.2 percent of the 
total estimated effort for modifying the 29 systems from which we chose 
examples. 

Databases, key systems operations, and use(s) of HICN: 
FISS includes a core claims processing system that reviews claims for 
errors and adjudicates claims, and a financial processing system that 
facilitates claims payment. The claims and financial systems are 
written using the Common Business-Oriented Language (COBOL) 
programming language. In place of a database, FISS uses a file system 
to store information on each claim. The FISS file system is 
implemented using IBM's Virtual Storage Access Method (VSAM).[B] The 
VSAM files are populated with claims data entered by users and 
beneficiary eligibility data from CMS's eligibility database. One 
design provision of the system is that all necessary data required for 
accurate claims adjudication, including HICNs, are retained in the 
FISS record to provide a reliable and auditable history of activity 
related to the claims. Once a claim is processed, the data are added 
to the Integrated Data Repository and the National Claims History 
database.[C] Claims data, including the HICN, can be entered by 
providers using either an online form, which allows providers to enter 
claims directly into FISS, or by batch submission of one or more 
claims to the provider's Medicare Administrative Contractor 
electronically. A very small percentage of claims (less than 1 percent) 
are submitted to the contractors on paper and the contractors' staff 
enter the claim data into the FISS system. Upon submission of a claim, 
FISS's Common Edits and Enhancements Module ensures the claim is 
compliant with the standard claim format and performs error checks. For 
example, error checks are performed to determine whether the claim is a 
duplicate of another filed claim, and whether the HICN was included 
with the claim; if not, the claim is returned to the provider as 
incomplete or invalid. In addition, FISS may identify additional 
information needed from the submitting provider to adjudicate the 
claim. If the claim passes this level of editing, the system then 
electronically transmits a portion of the claim data, including the 
HICN, to another CMS system, the Common Working File. This system then 
verifies beneficiary eligibility and conducts additional benefit 
utilization edits on the claim and either authorizes payment or returns 
the claim to the FISS system with an error code. Once the claim has 
been authorized by the Common Working File, FISS sends the adjudicated 
claim, including the HICN, to the Healthcare Integrated General Ledger 
Accounting System, which records accounting data and sends payment 
information back to FISS. To complete the claims process, FISS 
generates an Electronic Funds Transfer or a paper check as well as 
produces reports such as Medicare Summary Notices[D] for beneficiaries 
and payment remittance advice for providers, and sends claims 
information to coordination-of-benefits partners. 

System technical description: operating system(s), programming 
language(s), and lines of code: 
* Operating System: Primarily on z/OS-based IBM mainframes located at 
the two Enterprise Data Centers; 
* Programming languages and tools: COBOL, 96 percent; Assembly 
Language, 4 percent; JAVA, 0.1 percent; 
* Estimated lines of code: 3.2 million lines of COBOL and Assembly 
Approximately 160 JAVA Modules; 31,000 lines; 
* Updated per quarterly release: approximately 1,600 modules 
and 33,000 lines of code. 

Examples of potential changes needed to implement non-SSN-based 
identifier: 
* The system would be modified to access a crosswalk service to 
translate from the MBI to the HICN before it begins processing claims. 
This approach would enable claims to continue to be processed using 
HICN; 
* FISS would be modified to return a claim to the provider if the 
claim is submitted using an invalid MBI that the crosswalk service is 
unable to locate; 
* FISS would be modified to use the crosswalk service at multiple 
points in the claims adjudication process to verify whether the 
beneficiary's MBI is still valid. This step is needed because during 
the claims process, which can take between 3 days and up to 30 days, a 
beneficiary may receive a new MBI to replace a compromised MBI. 
Consequently, the system would need to use a crosswalk service during 
claims processing to check whether a new MBI was issued and, if so, 
update the MBI on the claim that is being processed; 
* Data exchanged with external partners would be modified to include 
the MBI. For example, claims information sent to coordination-of-
benefit contractors would be modified; 
* All external claims reports would be modified to display the MBI 
instead of the HICN. For example, Medicare Summary Notices that are 
sent to beneficiaries on adjudicated claims would be modified; 
* To accommodate changes needed during the transition period when 
claims can be submitted using either the HICN or MBI, certain FISS 
capabilities would be modified to use the crosswalk service. For 
example, during the transition period if a claim is submitted using 
the HICN, FISS would use the crosswalk service to obtain the 
corresponding MBI; 
* Claims records would be modified to store the MBI in the FISS file in 
addition to the HICN on every record to ensure a reliable claim history 
and an audit trail for tracking clams processing. 

Source: GAO analysis of data provided by CMS. 

[A] Medicare Administrative Contractors process and pay claims, answer 
questions from Medicare providers, and implement Medicare coverage 
rules. CMS is replacing fiscal intermediaries--legacy claims payment 
contractors with jurisdiction for hospital providers and institutional 
suppliers--with Medicare Administrative Contractors. 

[B] IBM's Virtual Storage Access Method (VSAM) is a file system that 
includes functions for accessing data that are stored on a mainframe 
operating system. 

[C] The Integrated Data Repository is an enterprise data warehouse 
that includes Medicare and Medicaid data. It is intended to provide a 
single repository for the agency's data and enable data analysis 
within and across programs. The National Claims History database 
collects and maintains billing and utilization data on Medicare 
beneficiaries enrolled in hospital insurance (Part A) or medical 
insurance (Part B) for statistical and research purposes related to 
evaluating and studying the operation and effectiveness of the 
Medicare program. 

[D] The Medicare Summary Notice provides Medicare beneficiaries with a 
summary record of action taken on intermediary processed claims and 
the status of any deductible. 

[End of table] 

Table 3: Description of MBDSS and Examples of Potential Changes Needed 
to Support SSN Removal: 

Description: 
MBDSS was developed in 2003 and is comprised of the Medicare 
Beneficiary Database and several systems that provide a single, 
enterprisewide authoritative source for Medicare beneficiary 
demographic data. MBDSS receives and provides beneficiary data among 
CMS, the Social Security Administration (SSA), the Railroad Retirement 
Board, Medicare Advantage and Prescription Drug Plans, and state 
Medicaid program offices. In addition, MBDSS supports business 
processes such as Part D eligibility, beneficiary batch eligibility 
queries for plans, determining low-income beneficiaries, auto and 
facilitated assignment of beneficiaries to Part D Plans, mass mailings, 
and state phase down. MBDSS also disseminates data and notifications of 
changes to beneficiary demographic, eligibility, and enrollment data to 
various systems such as 1-800 Medicare, the Common Working File, the 
True-out-of-pocket Expenditures System,[A] Retiree Drug Subsidy 
System, Medicare Advantage and Prescription Drug (MARx) System, and the 
Enrollment Database. 

Users and stakeholders: 
Users include CMS central and regional offices, CMS systems such as 
the Common Working File and the True-out-of-pocket Expenditures 
System, SSA, Railroad Retirement Board, Medicare Advantage and 
Prescription Drug Plans, and state Medicaid program offices. 

System and business owner(s): 
Office of Information Services, Innovative Healthcare Delivery Systems 
Group and Center for Medicare, Center for Drug and Health Plan Choice, 
Medicare Enrollment and Appeals Group. 

CMS preliminary estimate of hours required to modify systems for SSN 
removal: 
CMS estimated that it would require 40,312 hours (21 FTEs) to modify 
MBDSS systems for SSN removal. This estimate is about 9.6 percent of 
the total estimated effort for modifying the 29 systems from which we 
chose examples. 

Databases, key systems operations, and use(s) of the HICN: 
MBDSS's key databases include the Medicare Beneficiary Database (MBD) 
and the Common Medicare Environment.[B] MBD is a DB2 database[C] and 
includes data such as controls for security and user access to the 
systems' capabilities. The Common Medicare Environment is a DB2 
database for which MBDSS updates specific database tables. The MBDSS 
Graphical User Interface (GUI) enables users, including Medicare 
workers who provide assistance such as answering beneficiary 
inquiries, to access and update MBDSS information. In addition, MBDSS 
includes about 39 interfaces that use files to exchange information 
with MBDSS users; 36 of these interfaces include the HICN. Information 
exchanged via the interfaces, which includes entitlement data provided 
to participating states and territories, beneficiary data provided to 
the true-out-of-pocket facilitator,[D] and data on beneficiaries who 
voluntarily disenroll from a Part D plan, is used to create a report 
on the quality of health plans based on voluntary disenrollment rates. 

System technical description: operating system(s), programming 
language(s), and lines of code: 
* MBDSS consists of a mainframe environment that includes the 
databases and a mid-tier environment that includes the GUI; 
* Operating systems: IBM's z/OS; the MBD GUI uses the z/Linux 
operating system; 
* Programming languages and tools: COBOL; 
* Estimated lines of code: 1,003,199. 

Examples of potential changes for implementing non-SSN-based 
identifier: 
* MBDSS includes approximately 39 interface files that provide 
beneficiary information to MBDSS users, including all state Medicaid 
agencies (50 states plus U.S. territories), more than 500 Part D 
plans, the database used to support 1-800-Medicare, the facilitator 
for True-out-of-pocket Expenses Part D transactions, the Coordination 
of Benefits Contractor, and the Retiree Drug Subsidy System. Of the 39 
interface files, 36 include the HICN, and, depending on the interface 
partner's use, would need one or both of the following modifications to 
the file they receive: 
- Add the MBI to the end of the file to provide it to MBDSS users; 
- During the transition period, when both the HICN and the MBI may be 
needed, modify the files to include both identifiers. At the end of 
the transition period, when the HICN will no longer be transmitted to 
MBDSS users, add blanks to files in the space that previously stored 
the HICN; 
* In addition to modifying the file layout of the 36 files that 
include the HICN, CMS would need to coordinate changes to the files 
with each MBDSS user so that the users would be prepared to accept 
beneficiary information in the new format that includes the MBI. For 
example, CMS would need to coordinate the change with the more than 
500 Part D plan providers and all states and territories; 
* During the transition period when beneficiary information could be 
submitted with either the HICN or the MBI, MBDSS would use a control 
module to keep track of whether beneficiary information was submitted 
with the HICN or the MBI, so that it could send information back to 
the user with the same identifier that the user submitted. After the 6-
month transition period, the control module would be changed to not 
accept a request made with the HICN; 
* The beneficiary matching criteria for both batch processing and the 
user interface would need to be modified; 
* MBDSS would need to translate the MBI to the HICN, so that it could 
continue to use the existing software to process beneficiary 
information using the HICN. To accomplish this, MBDSS would need to 
use the crosswalk service to translate the MBI to the HICN. MBDSS 
would also need to translate the HICN to the MBI and would use a 
direct lookup table for this translation; 
* MBDSS user interface screens would be modified to allow users to 
search for beneficiaries using the MBI; 
* The MBD database would be modified to add the MBI to some tables in 
order to improve the performance of business functions that require 
faster translation or lookup than the crosswalk service could provide; 
* MBDSS would be modified to notify interface systems in the event 
that a new MBI is generated for a beneficiary, and, depending on the 
interface, would be modified to send the new MBI either using a 
notification of a change to the systems that can read from the Common 
Medicare Environment database or through a data file; 
* MBDSS system documentation would be modified to show changes to 
capabilities that previously used the HICN and would now need the MBI; 
for example, changes would be shown to input screens that previously 
used the HICN. 

Source: GAO analysis of data provided by CMS. 

[A] The True-out-of-pocket Part D Transaction Facilitator system was 
established in order to accurately track and calculate Medicare 
beneficiaries' true-out-of-pocket expenditures. The system provides 
beneficiary data to pharmacies and plans in order to determine if the 
beneficiary is eligible to receive the benefit and what, if any, other 
coverage he or she has. 

[B] The Common Medicare Environment is an enterprisewide database that 
provides information to several systems, including MBDSS, the Medicare 
Advantage and Prescription Drug (MARx) System, and the Enrollment 
Database, each of which is responsible for updating and retrieving 
information it owns. Common Medicare Environment is a DB2 database, 
and it includes approximately 350 tables that store data for the 
systems that access and update CMS. 

[C] DB2 is a relational database management system developed by IBM 
that serves a number of different operating systems platforms. 

[D] The true-out-of-pocket facilitator is responsible for establishing 
procedures for facilitating eligibility queries at the point of 
service, identifying costs that are being reimbursed by other payers, 
and for alerting Part D plans about such transactions. MBDSS transmits 
data regarding Part D plan coverage and eligibility, including the 
HICN, to the true-out-of-pocket facilitator. 

[End of table] 

[End of section] 

Appendix III: Comments from the Department of Health & Human Services: 

Department of Health & Human Services: 
Office of The Secretary: 
Assistant Secretary for Legislation: 
Washington, DC 20201: 

August 23, 2013: 

Valerie C. Melvin, Director: 
Information Management and Technology Resources Issues: 
U.S. Government Accountability Office: 
441 G Street NW: 
Washington, DC 20548: 

Dear Ms. Melvin: 

Attached are comments on the U.S. Government Accountability Office's 
(GAO) report entitled, "Medicare Information Technology: Centers for 
Medicare and Medicaid Services Needs to Pursue a Solution for Removing 
Social Security Numbers from Cards" (GAO-13-761). 

The Department appreciates the opportunity to review this report prior 
to publication. 

Sincerely, 

Signed by: 

Jim R. Esquea: 
Assistant Secretary for Legislation: 

Attachment: 

General Comments Of The Department Of Health And Human Services (HHS) 
On The Government Accountability Office's (GAO) Draft Report Entitled, 
"Centers For Medicare And Medicaid Services Needs To Pursue A Solution 
For Removing Social Security Numbers From Cards," (GAO-13-761): 

The Department appreciates the opportunity to review and comment on 
this draft report. 

GAO Recommendation: 

GAO recommends that CMS Administrator take the following action: 

* Direct the initiation of an IT project for identifying, developing 
and implementing changes that would have to be made to CMS's affected 
systems, including designating a business owner and establishing a 
business case, issuing a project charter, and conducting project 
selection and architectural reviews of proposed approaches for the 
removal of SSNs from Medicare beneficiary cards. 

HHS Response: 

While we agree that removing the SSN from the Medicare card is an 
appropriate step to reducing the risk of identity theft, CMS cannot 
make a decision to proceed unilaterally. CMS, Social Security 
Administration and the Railroad Retirement Board must all agree to 
proceed with the initiative, considering existing workloads and 
priorities. Moreover, a clear source of funding for both IT and non-IT 
costs must be identified before proceeding. As GAO points out, the IT 
cost of the initiative comprises only 10 to 20 percent of the total 
cost. HHS concurs with GAO's recommendations for this finding assuming 
these constraints can be addressed. 

GAO Recommendation: 

GAO recommends that CMS Administration take the following action: 

* Incorporate such a project into plans for ongoing enterprise-wide IT 
modernization initiatives. 

HHS Response: 

HHS concurs with the GAO recommendation once the constraints described 
above have been addressed. Additionally, CMS would like to clarify a 
finding made by the GAO that was stated in both the highlights and on 
page 24 of the draft that, "CMS may have missed opportunities to
leverage enterprise shared services to remove the SSN from the 
Medicare card." While we have not specifically built the shared 
services with the intent to utilize them for the purpose of removing 
the SSN from Medicare cards, the general functionality exists in the 
shared services to do so, and in fact our 2013 cost estimate did 
assume that shared services could be utilized. 

[End of section] 

Appendix IV: GAO Contact and Staff Acknowledgments: 

GAO Contact: 

Valerie C. Melvin at (202) 512-6304 or melvinv@gao.gov: 

Staff Acknowledgments: 

In addition to the contact named above, Teresa F. Tucker (Assistant 
Director), Wilfred B. Holloway, Lee A. McCracken, Thomas E. Murphy, 
Maria Stattel, Daniel K. Wexler, Merry L. Woo, and Charles E. Youman 
made significant contributions to this report. 

[End of section] 

Footnotes: 

[1] Medicare beneficiaries may also enroll in Part C, or Medicare 
Advantage, which pays private health plans to provide generally the 
same services covered by Parts A and B. Further, all Medicare 
beneficiaries may purchase coverage for outpatient prescription drugs 
under Part D, and some Medicare Advantage plans also include Part D 
coverage. 

[2] CMS's contractors that process fee-for-service claims are referred 
to a Medicare Administration Contractors. 

[3] Providers of health care under Part C and prescriptions under Part 
D do not file claims for payment. Rather, CMS pays private plans a 
monthly amount per beneficiary to provide health care services for 
each beneficiary enrolled in these plans. Instead of setting prices 
administratively, Medicare's payment to each Part C plan is determined 
by the plan's bid--its projected revenue requirements for providing 
standard Medicare services to an average enrollee--and a benchmark--
the maximum amount Medicare will pay in each county within the plan's 
service area. Medicare's payments to Part D plans are determined 
through a competitive process. 

[4] The Patient Protection and Affordable Care Act (Affordable Care 
Act) directed CMS to develop a plan to modernize its computer and data 
systems. Pub. L. No. 111-148, § 10330, 124 Stat. 119, 965 (2010), as 
amended by the Health Care and Education Reconciliation Act of 2010, 
Pub. L. No. 111-152, 124 Stat. 1029. 

[5] See Government Performance and Results Act of 1993, Pub. L. No. 
103-62, 107 Stat. 285 (1993), as amended by the GPRA Modernization Act 
of 2010, Pub. L. No. 111-352, 124 Stat. 3866 (2011); Office of 
Management and Budget, Management of Federal Information Resources, 
Circular A-130 (Washington, D.C.: Nov. 28, 2000), and Planning, 
Budgeting, Acquisition, and Management of Capital Assets, Circular A-
11, Part 7 (Washington, D.C.: July 2003). 

[6] Pub. L. No. 103-322, § 300001, 108 Stat. 1796 (1994) (codified at 
18 U.S.C. §§ 2721-2725). 

[7] Pub. L. No. 104-191, Title II, Subtitle F, 110 Stat. 1936, 2021 
(codified at 42 U.S.C. §§ 1320d-1320d-8). HIPAA, among other things, 
required the adoption of data interchange standards to enable 
electronic exchange. 

[8] The numbers on the VA cards are identification numbers that allow 
beneficiaries to access facilities; the cards are not insurance cards. 
DOD's cards are also used primarily for identification purposes, and 
are not insurance cards. 

[9] Cards are used by active duty military personnel and their 
dependents to access health care services. 

[10] This code is used by SSA to determine the type of beneficiary. 
For example, an A suffix indicates the card holder is a retired or 
disabled worker (primary claimant). The B or B1 suffix indicates a 
wife or husband, respectively, of the retired wage earner. The C 
suffix indicates a child of a retiree, or a disabled child or student. 
The D suffix indicates a widow and an E suffix signifies a widowed 
mother. The SSN on the card is usually the cardholder's own; however, 
about 14 percent of the cards contain the SSN of the family member 
whose work history provides eligibility for services and treatment 
under Medicare. 

[11] In addition, CMS uses the number and associated claims 
information for internal purposes, such as for analyzing Medicare 
program performance and conducting program integrity efforts. 

[12] The shared systems are the Fiscal Intermediary Shared System, 
which processes part A claims; the Multi-carrier system, which 
processes part B claims; and the ViPS Medicare System, which is used 
to process claims for durable medical equipment. 

[13] Railroad retirees usually become eligible for Medicare at age 65. 
At that point, the Railroad Retirement Board assumes administrative 
responsibilities for railroad retirees' Medicare Parts A and B 
benefits. 

[14] The following reports documented evaluations of CMS's information 
technology and included recommendations that CMS modernize its 
information technology environment: the President's Council of 
Advisors on Science and Technology, Report to the President Realizing 
the Full Potential of Health Information Technology to Improve 
Healthcare For Americans: The Path Forward (December 2010), and the 
National Academy of Sciences, Strategies and Priorities for 
Information Technology at the Centers for Medicare and Medicaid 
Services (2011). 

[15] Use of shared services can be cost efficient because when a 
service is reused by multiple IT systems, initial system development 
costs occur once, and these costs can be avoided each time the service 
is reused. In addition, use of shared services promotes 
standardization and interoperation of data and can reduce stove piping. 

[16] Department of Health and Human Services Office of the Inspector 
General, CMS Responses to Breaches and Medical Identity Theft, OEI-02-
10-00040 (Rockville, Md.: October 2012), and Social Security 
Administration Office of the Inspector General, Removing Social 
Security Numbers from Medicare Cards, A-08-08-18026 (Baltimore, Md.: 
May 2008). 

[17] GAO, Social Security Numbers: Governments Could Do More to Reduce 
Display in Public Records and on Identity Cards, [hyperlink, 
http://www.gao.gov/products/GAO-05-59] (Washington, D.C.: Nov. 9, 
2004). 

[18] GAO, Social Security Numbers: Stronger Protections Needed When 
Contractors Have Access to SSNs, [hyperlink, 
http://www.gao.gov/products/GAO-06-238] (Washington, D.C.: Jan. 23, 
2006). 

[19] GAO, Social Security Numbers: More Could Be Done to Protect SSNs, 
[hyperlink, http://www.gao.gov/products/GAO-06-586T] (Washington, 
D.C., Mar. 30, 2006). 

[20] GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate 
for Removing Social Security Numbers from Medicare Cards, [hyperlink, 
http://www.gao.gov/products/GAO-12-831] (Washington, D.C.: Aug. 1, 
2012). 

[21] CMS, Removal of Social Security Number from the Medicare Health 
Insurance Card and Other Medicare Correspondence (Baltimore, Md.: 
October 2006), and Update on the Assessment of the Removal of Social 
Security Numbers from Medicare Cards (Baltimore, Md.: November 2011). 

[22] [hyperlink, http://www.gao.gov/products/GAO-12-831]. 

[23] The remainder of the estimated cost was associated with business 
processes, such as printing and mailing new cards and training 
personnel to use a new number, which would be completed in October 
2015. 

[24] Centers for Medicare and Medicaid Services, CMS Expedited Life 
Cycle Process: Detailed Description, Version 2.11 (Baltimore, Md.: 
November 2012). CMS's XLC framework was developed in accordance with 
departmental guidance, the Department of Health and Human Services, 
Enterprise Performance Life Cycle Framework (Washington, D.C.: 
September 2011). 

[25] GAO's guidance for estimating costs includes determining 
technical requirements associated with implementing business projects, 
such as modifications to IT systems and purchase of additional 
computer hardware. 

[26] Agency officials stated that they referred to the list of systems 
that was developed to meet Federal Information Security Management 
Act, or FISMA, requirements. 

[27] Of the 72 systems potentially affected by the first approach, CMS 
officials identified 20 that accounted for 86 percent of the total 
estimated cost of effort. Likewise, of the 41 affected by the second 
approach, 20 systems accounted for 95 percent. 

[28] While CMS provides cards for beneficiaries when they enroll in 
Medicare, SSA is responsible for processing beneficiaries' requests 
for replacements. However, the Railroad Retirement Board issues cards 
both at enrollment and when beneficiaries request replacements when, 
for example, they are lost. 

[29] The states' systems use the HICN to identify beneficiaries about 
whom data are being shared, to share data about those beneficiaries, 
and to coordinate health care delivery and payment. Therefore, the 
introduction of a new identifier to replace the SSN-based HICN would 
require modifications to the IT systems that are used to support these 
practices. 

[30] Buy-in occurs when state Medicaid programs pay for their 
beneficiaries' Medicare premiums. 

[31] GAO, Federal Chief Information Officers: Opportunities Exist to 
Improve Role in Information Technology Management, [hyperlink, 
http://www.gao.gov/products/GAO-11-634] (Washington, D.C.: Sept. 15, 
2011). 

[32] GAO, 2013 Annual Report: Actions Needed to Reduce Fragmentation, 
Overlap, and Duplication and Achieve Other Financial Benefits, 
[hyperlink, http://www.gao.gov/products/GAO-13-279SP] (Washington, 
D.C.: Apr. 9, 2013); Information Technology: OMB and Agencies Need to 
Focus Continued Attention on Eliminating Duplicative Investments, 
[hyperlink, http://www.gao.gov/products/GAO-13-685T] (Washington, 
D.C.: June 11, 2013); Information Technology: FDA Needs to Establish 
Key Plans and Processes for Guiding Systems Modernization Efforts, 
[hyperlink, http://www.gao.gov/products/GAO-09-523] (Washington, D.C.: 
June 2009); and ADP Modernization: Half-Billion Dollar FmHA Effort 
Lacks Adequate Planning and Oversight, [hyperlink, 
http://www.gao.gov/products/GAO/IMTEC-92-9] (Washington, D.C: October 
1991). 

[33] One of the 20 systems is the crosswalk service itself. 

[34] CMS, Removal of Social Security Number from the Medicare Health 
Insurance Card and Other Medicare Correspondence (Baltimore, Md.: 
October 2006); Update on the Assessment of the Removal of Social 
Security Numbers from Medicare Cards (Baltimore, Md.: November 2011); 
and SSN Removal from Medicare Card: Cost Analysis Summary (Baltimore, 
Md.: May 2013). 

[35] Centers for Medicare and Medicaid Services, CMS Expedited Life 
Cycle Process: Detailed Description, Version 2.11 (Baltimore, Md.: 
November 2012). 

[36] GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate 
for Removing Social Security Numbers from Medicare Cards, [hyperlink, 
http://www.gao.gov/products/GAO-12-831] (Washington, D.C.: Aug. 1, 
2012). 

[37] CMS, SSN Removal from Medicare Card: Cost Analysis Summary 
(Baltimore, Md.: May 2013). 

[38] One state did not provide an estimate to CMS. 

[39] See Government Performance and Results Act of 1993, Pub. L. No. 
103-62, 107 Stat. 285 (1993), as amended by the GPRA Modernization Act 
of 2010, Pub. L. No. 111-352, 124 Stat. 3866 (2011); Office of 
Management and Budget, Management of Federal Information Resources, 
Circular A-130 (Washington, D.C.: Nov. 28, 2000), and Planning, 
Budgeting, Acquisition, and Management of Capital Assets, Circular A-
11, Part 7 (Washington, D.C.: July 2003). 

[End of section] 

GAO’s Mission: 

The Government Accountability Office, the audit, evaluation, and 
investigative arm of Congress, exists to support Congress in meeting 
its constitutional responsibilities and to help improve the 
performance and accountability of the federal government for the 
American people. GAO examines the use of public funds; evaluates 
federal programs and policies; and provides analyses, recommendations, 
and other assistance to help Congress make informed oversight, policy, 
and funding decisions. GAO’s commitment to good government is 
reflected in its core values of accountability, integrity, and 
reliability. 

Obtaining Copies of GAO Reports and Testimony: 

The fastest and easiest way to obtain copies of GAO documents at no 
cost is through GAO’s website [hyperlink, http://www.gao.gov]. Each 
weekday afternoon, GAO posts on its website newly released reports, 
testimony, and correspondence. To have GAO e-mail you a list of newly 
posted products, go to [hyperlink, http://www.gao.gov] and select 
“E-mail Updates.” 

Order by Phone: 

The price of each GAO publication reflects GAO’s actual cost of 
production and distribution and depends on the number of pages in the 
publication and whether the publication is printed in color or black 
and white. Pricing and ordering information is posted on GAO’s 
website, [hyperlink, http://www.gao.gov/ordering.htm]. 

Place orders by calling (202) 512-6000, toll free (866) 801-7077, or 
TDD (202) 512-2537. 

Orders may be paid for using American Express, Discover Card, 
MasterCard, Visa, check, or money order. Call for additional 
information. 

Connect with GAO: 

Connect with GAO on facebook, flickr, twitter, and YouTube.
Subscribe to our RSS Feeds or E mail Updates. Listen to our Podcasts.
Visit GAO on the web at [hyperlink, http://www.gao.gov]. 

To Report Fraud, Waste, and Abuse in Federal Programs: 

Contact: 
Website: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]; 
E-mail: fraudnet@gao.gov; 
Automated answering system: (800) 424-5454 or (202) 512-7470. 

Congressional Relations: 

Katherine Siggerud, Managing Director, siggerudk@gao.gov: 
(202) 512-4400: 
U.S. Government Accountability Office: 
441 G Street NW, Room 7125: 
Washington, DC 20548. 

Public Affairs: 

Chuck Young, Managing Director, youngc1@gao.gov: 
(202) 512-4800: 
U.S. Government Accountability Office: 
441 G Street NW, Room 7149: 
Washington, DC 20548. 

[End of document]