MEDICARE 

INFORMATION 

TECHNOLOGY

Centers for Medicare 

and Medicaid Services 

Needs to Pursue a 

Solution for Removing 

Social Security 

Numbers from Cards

Report to Congressional Requesters

September 2013

GAO-13-761

United States Government Accountability Office
United States Government Accountability Office

Highlights of GAO-13-761, a 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 

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 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. 

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 costView GAO-13-761. For more information, effective manner. contact Valerie C. Melvin at (202) 512-6304 or 

melvinv@gao.gov. 
Page i GAO-13-761 Removal of SSNs from Medicare Cards 

Letter 1 

Background 5

CMS Has Not Actively Pursued an IT Solution but Has Taken 

Actions That Could Support Efforts to Do So 13

CMS Has Initiated Actions Intended to Address Modernization 

Goals That Could Facilitate SSN Removal but Has Not Made 

Specific Plans for Leveraging Efforts 20

Conclusions 22

Recommendations for Executive Action 23

Agency Comments and Our Evaluation 23

Appendix I Objectives, Scope, and Methodology 26

Appendix II GAO’s Assessment of Three CMS Systems and the Types of 

Potential Changes Needed to Support SSN Removal 30

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

Appendix IV GAO Contact and Staff Acknowledgments 39

Tables

Table 1: Description of HETS and Examples of Potential Changes 

Needed to Support SSN Removal 30

Table 2: Description of FISS and Examples of Potential Changes 

Needed to Support SSN Removal 32

Table 3: Description of MBDSS and Examples of Potential Changes 

Needed to Support SSN Removal 34

Figures

Figure 1: Medicare Card 7

Figure 2: Flow of Data and Use of the Health Insurance Claim 

Number in CMS’s and Medicare Stakeholders’ Systems 10

Contents 
Page ii GAO-13-761 Removal of SSNs from Medicare Cards 

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

This is a work of the U.S. government and is not subject to copyright protection in the 

United States. The published product may be reproduced and distributed in its entirety 

without further permission from GAO. However, 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.
Page 1 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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.

2

 

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.

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 

2

CMS’s contractors that process fee-for-service claims are referred to a Medicare 

Administration Contractors. 

 
 

Page 2 GAO-13-761 Removal of SSNs from Medicare Cards 

reimbursed by Medicare for services and supplies that they deliver to 

beneficiaries in accordance with Parts A and B rules.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 

Act4

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) 

and began to take steps toward planning an agencywide IT 

modernization initiative.

 

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.
 

Page 3 GAO-13-761 Removal of SSNs from Medicare Cards 

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 
 

Page 4 GAO-13-761 Removal of SSNs from Medicare Cards 

guide systems development,5

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.

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.

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.

 

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).
 

Page 5 GAO-13-761 Removal of SSNs from Medicare Cards 

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,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)7

Certain federal agencies, including the Departments of Defense (DOD) 

and Veterans Affairs (VA), have similarly taken actions to remove the 

numbers from identification cards.

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.

8

 

6

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

2725).

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 

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.

Background
 

Page 6 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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.

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.10

 

9

Cards are used by active duty military personnel and their dependents to access health 

care services.

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 

10This 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.

Use of SSN-Based Health 

Insurance Claim Number 

by CMS and Its 

Stakeholders
 

Page 7 GAO-13-761 Removal of SSNs from Medicare Cards 

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

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.
 

Page 8 GAO-13-761 Removal of SSNs from Medicare Cards 

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.11

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.

For example, CMS’s Medicare 

Administrative Contractors, who are responsible for processing and 

paying claims, use their own systems to determine whether fee-forservice 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.

12

 

11In addition, CMS uses the number and associated claims information for internal 

purposes, such as for analyzing Medicare program performance and conducting program 

integrity efforts.

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, 

12The 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.
 

Page 9 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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.

 

13Railroad 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.
 

Page 10 GAO-13-761 Removal of SSNs from Medicare Cards 

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

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 

CMS’s IT Environment and 

Modernization Initiatives
 

Page 11 GAO-13-761 Removal of SSNs from Medicare Cards 

committees that later evaluated CMS’s IT environment14

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.

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.

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.

 

14The 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). 

15Use 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.
 

Page 12 GAO-13-761 Removal of SSNs from Medicare Cards 

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.16

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.

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.

17

We reported again in 2006 that there were gaps in federal requirements 

for protecting SSNs.

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. 

18

 

16Department 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).

Specifically, we noted that Congress could 

consider possible options for addressing gaps related to safeguarding 

17GAO, Social Security Numbers: Governments Could Do More to Reduce Display in 

Public Records and on Identity Cards, GAO-05-59 (Washington, D.C.: Nov. 9, 2004).

18GAO, Social Security Numbers: Stronger Protections Needed When Contractors Have 

Access to SSNs, GAO-06-238 (Washington, D.C.: Jan. 23, 2006).

Prior Reports on CMS’s 

and Other Agencies’ Use 

and Display of SSNs
 

Page 13 GAO-13-761 Removal of SSNs from Medicare Cards 

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.19

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.

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.

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 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.21

Specifically, according to CMS, a 2006 study was initiated in response to 

congressional concerns regarding identity theft and expectations that the 

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.

 

19GAO, Social Security Numbers: More Could Be Done to Protect SSNs, GAO-06-586T 

(Washington, D.C., Mar. 30, 2006).

20GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate for Removing 

Social Security Numbers from Medicare Cards, GAO-12-831 (Washington, D.C.: Aug. 1, 

2012).

21CMS, 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).

CMS Has Not Actively 

Pursued an IT 

Solution but Has 

Taken Actions That 

Could Support Efforts 

to Do So
 

Page 14 GAO-13-761 Removal of SSNs from Medicare Cards 

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,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.23

 

22

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.

GAO-12-831. 

23The 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.
 

Page 15 GAO-13-761 Removal of SSNs from Medicare Cards 

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.24

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

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:

• 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 

 

24Centers 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). 
 

Page 16 GAO-13-761 Removal of SSNs from Medicare Cards 

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 lifecycle phase.25

 

25GAO’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.

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 
 

Page 17 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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).27

• 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 

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.

 

26Agency officials stated that they referred to the list of systems that was developed to 

meet Federal Information Security Management Act, or FISMA, requirements.

27Of 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.
 

Page 18 GAO-13-761 Removal of SSNs from Medicare Cards 

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.28

• CMS also involved state program stakeholders and collected highlevel estimates of changes that would have to be made to states’ 

Medicaid systems.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,30

 

28While 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. 

eligibility determination, and Part D 

29The 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. 

30Buy-in occurs when state Medicaid programs pay for their beneficiaries’ Medicare 

premiums. 
 

Page 19 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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.

 

31GAO, Federal Chief Information Officers: Opportunities Exist to Improve Role in 

Information Technology Management, GAO-11-634 (Washington, D.C.: Sept. 15, 2011).
 

Page 20 GAO-13-761 Removal of SSNs from Medicare Cards 

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.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

 

32GAO, 2013 Annual Report: Actions Needed to Reduce Fragmentation, Overlap, and 

Duplication and Achieve Other Financial Benefits, GAO-13-279SP (Washington, D.C.: 

Apr. 9, 2013); Information Technology: OMB and Agencies Need to Focus Continued 

Attention on Eliminating Duplicative Investments, GAO-13-685T (Washington, D.C.: June 

11, 2013); Information Technology: FDA Needs to Establish Key Plans and Processes for 

Guiding Systems Modernization Efforts, GAO-09-523 (Washington, D.C.: June 2009); and 

ADP Modernization: Half-Billion Dollar FmHA Effort Lacks Adequate Planning and 

Oversight, GAO/IMTEC 92-9 (Washington, D.C: October 1991).

CMS Has Initiated 

Actions Intended to 

Address 

Modernization Goals 

That Could Facilitate 

SSN Removal but Has 

Not Made Specific 

Plans for Leveraging 

Efforts
 

Page 21 GAO-13-761 Removal of SSNs from Medicare Cards 

• 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 
 

Page 22 GAO-13-761 Removal of SSNs from Medicare Cards 

implementation rather than for 18 of the 20 systems that would need to 

perform a crosswalk between a new identifier and the existing HICN.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.

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 

 

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

Conclusions
 

Page 23 GAO-13-761 Removal of SSNs from Medicare Cards 

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.

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.

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 

Recommendations for 

Executive Action

Agency Comments 

and Our Evaluation
 

Page 24 GAO-13-761 Removal of SSNs from Medicare Cards 

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 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 
 

Page 25 GAO-13-761 Removal of SSNs from Medicare Cards 

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.

Valerie C. Melvin

Director

Information Management and Technology Resources Issues
Appendix I: Objectives, Scope, and 

Methodology

Page 26 GAO-13-761 Removal of SSNs from Medicare Cards 

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.1 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.2

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 

 

1

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).

2

Centers for Medicare and Medicaid Services, CMS Expedited Life Cycle Process: 

Detailed Description, Version 2.11 (Baltimore, Md.: November 2012).

Appendix I: Objectives, Scope, and 

Methodology 
Appendix I: Objectives, Scope, and 

Methodology

Page 27 GAO-13-761 Removal of SSNs from Medicare Cards 

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.3

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 

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.

 

3

GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate for Removing 

Social Security Numbers from Medicare Cards, GAO-12-831 (Washington, D.C.: Aug. 1, 

2012).
Appendix I: Objectives, Scope, and 

Methodology

Page 28 GAO-13-761 Removal of SSNs from Medicare Cards 

of the impact the SSN removal would have on their systems.4 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.5

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,

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.

6

 

4

CMS, SSN Removal from Medicare Card: Cost Analysis Summary (Baltimore, Md.: May 

2013).

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 

5

One state did not provide an estimate to CMS.

6

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).
Appendix I: Objectives, Scope, and 

Methodology

Page 29 GAO-13-761 Removal of SSNs from Medicare Cards 

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.
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 30 GAO-13-761 Removal of SSNs from Medicare Cards 

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 

Appendix II: GAO’s Assessment of Three 

CMS Systems and the Types of Potential 

Changes Needed to Support SSN Removal
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 31 GAO-13-761 Removal of SSNs from Medicare Cards 

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. 
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 32 GAO-13-761 Removal of SSNs from Medicare Cards 

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 

Contractorsa 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 Noticesd for beneficiaries

and payment remittance advice for providers, and sends claims information to 

coordination-of-benefits partners.
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 33 GAO-13-761 Removal of SSNs from Medicare Cards 

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. 
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 34 GAO-13-761 Removal of SSNs from Medicare Cards 

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 databasec 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 midtier 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.
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 35 GAO-13-761 Removal of SSNs from Medicare Cards 

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. 
Appendix II: GAO’s Assessment of Three CMS 

Systems and the Types of Potential Changes 

Needed to Support SSN Removal

Page 36 GAO-13-761 Removal of SSNs from Medicare Cards 

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. 
Appendix III: Comments from the Department 

of Health & Human Services 

Page 37 GAO-13-761 Removal of SSNs from Medicare Cards 

Appendix III: Comments from the 

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

of Health & Human Services 

Page 38 GAO-13-761 Removal of SSNs from Medicare Cards 
Appendix IV: GAO Contact and Staff 

Acknowledgments

Page 39 GAO-13-761 Removal of SSNs from Medicare Cards 

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

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.

Appendix IV: GAO Contact and Staff 

Acknowledgments 

GAO Contact

Staff 

Acknowledgments

(310994)
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.

The fastest and easiest way to obtain copies of GAO documents at no 

cost is through GAO’s website (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 http://www.gao.gov and select “E-mail Updates.”

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, 

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 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 www.gao.gov. 

Contact:

Website: http://www.gao.gov/fraudnet/fraudnet.htm

E-mail: fraudnet@gao.gov

Automated answering system: (800) 424-5454 or (202) 512-7470

Katherine Siggerud, Managing Director, siggerudk@gao.gov, (202) 512-

4400, U.S. Government Accountability Office, 441 G Street NW, Room 

7125, Washington, DC 20548

Chuck Young, Managing Director, youngc1@gao.gov, (202) 512-4800

U.S. Government Accountability Office, 441 G Street NW, Room 7149 

Washington, DC 20548

GAO’s Mission

Obtaining Copies of 

GAO Reports and 

Testimony

Order by Phone

Connect with GAO

To Report Fraud, 

Waste, and Abuse in 

Federal Programs

Congressional 

Relations

Public Affairs

Please Print on Recycled Paper.