This is the accessible text file for GAO report number GAO-13-761 entitled 'Medicare Information Technology: Centers for Medicare and Medicaid Services Needs to Pursue a Solution for Removing Social Security Numbers from Cards' which was released on October 17, 2013. This text file was formatted by the U.S. Government Accountability Office (GAO) to be accessible to users with visual impairments, as part of a longer term project to improve GAO products' accessibility. Every attempt has been made to maintain the structural and data integrity of the original printed product. Accessibility features, such as text descriptions of tables, consecutively numbered footnotes placed at the end of the file, and the text of agency comment letters, are provided but may not exactly duplicate the presentation or format of the printed version. The portable document format (PDF) file is an exact electronic replica of the printed version. We welcome your feedback. Please E-mail your comments regarding the contents or accessibility features of this document to Webmaster@gao.gov. This is a work of the U.S. government and is not subject to copyright protection in the United States. It may be reproduced and distributed in its entirety without further permission from GAO. Because this work may contain copyrighted images or other material, permission from the copyright holder may be necessary if you wish to reproduce this material separately. United States Government Accountability Office: GAO: Report to Congressional Requesters: September 2013: Medicare Information Technology: Centers for Medicare and Medicaid Services Needs to Pursue a Solution for Removing Social Security Numbers from Cards: GAO-13-761: GAO Highlights: Highlights of GAO-13-761, a report to congressional requesters. Why GAO Did This Study: The health insurance claims number on Medicare beneficiaries’ cards includes as one component the beneficiary’s (or other eligible person’s, such as a spouse’s) SSN. This introduces risks to beneficiaries’ personal information, as the number may be obtained and used to commit identity theft. Many organizations have replaced SSNs on these types of cards with alternative identifiers. However, the introduction of such a new data element into IT environments can require changes to systems that process and share data. Moreover, previous assessments of CMS’s IT environment have found that it consists of many aging, “stove-piped” systems that cannot easily share data or be enhanced; thus the agency has ongoing efforts to modernize its environment. As requested, GAO studied CMS’s efforts related to the removal of SSNs from Medicare cards. GAO’s objectives were to (1) assess actions CMS has taken to identify and implement IT solutions for removing SSNs from Medicare cards and (2) determine whether CMS’s ongoing IT modernization initiatives could facilitate SSN removal efforts. To do this, GAO reviewed agency documentation and interviewed officials. What GAO Found: The Centers for Medicare and Medicaid Services (CMS)—-which is the agency within the Department of Health and Human Services (HHS) responsible for administering Medicare-—has not taken needed steps, such as designating a business owner and establishing a business case for an information technology (IT) project, that would result in selecting and implementing a technical solution for removing Social Security numbers (SSN) from Medicare cards. However, the agency has collected information and data as part of its most recent study of SSN removal that could contribute to the identification and development of an IT solution. These include information relevant to examining alternative approaches, identifying costs and risks, and assessing the impact of different approaches on the agency’s existing IT systems. For example, the agency identified two approaches for removing the SSN: (1) replacing it with a new identifier, referred to as the Medicare Beneficiary Identifier, and (2) masking the first five digits of the SSN for display on Medicare cards. CMS system and business owners also conducted high-level assessments of the types of changes that would need to be made to systems identified in the agency’s IT inventory. For example, system owners estimated the level of complexity of the changes, the number of hours of work at each life- cycle phase, business and technical risks, and the potential to leverage related efforts. CMS noted in its most recent study that replacing the SSN with a new identifier could reduce the risk of identity theft from a lost or stolen card, and actions taken thus far could inform a future IT project to address SSN removal. However, according to CMS officials, agency leadership has not directed them to initiate such a project. Until such a project is undertaken, the agency will not be positioned to identify or implement a solution to support the removal of SSNs from beneficiaries’ cards. CMS has efforts under way to modernize its IT systems, some of which could be leveraged to facilitate the removal of SSNs from Medicare cards. Specifically, one of CMS’s high-level modernization goals is to establish an architecture to support “shared services”—IT functions that can be used by multiple organizations and facilitate data sharing. According to agency officials, a service established to automate and manage certain aspects of CMS programs could be used to support a “crosswalk” function that would translate the existing claims number to the new beneficiary identifier (and vice versa). This would enable internal systems to receive information containing the new identifier and continue to process data based on the existing number. Another project was intended to consolidate eligibility determination services from four systems, which could reduce the extent of modifications that would have to be made to each of the systems. However, because the agency has not initiated a project for removing SSNs from identification cards, officials have not considered including shared services or other IT initiatives in their modernization activities and related plans to specifically support changes needed as a result of SSN removal. As a result, CMS may miss opportunities to incorporate such a project into ongoing agencywide modernization initiatives that could facilitate efforts to design, develop, and implement an IT solution for SSN removal in a timely and cost-effective manner. What GAO Recommends: GAO recommends that CMS initiate an IT project to develop a solution for SSN removal and incorporate such a project into plans for ongoing IT modernization initiatives. HHS agreed with GAO’s recommendations, if certain constraints were addressed. However, GAO maintains that its recommendations are warranted as originally stated. View [hyperlink, http://www.gao.gov/products/GAO-13-761]. For more information, contact Valerie C. Melvin at (202) 512-6304 or melvinv@gao.gov. [End of section] Contents: Letter: Background: CMS Has Not Actively Pursued an IT Solution but Has Taken Actions That Could Support Efforts to Do So: CMS Has Initiated Actions Intended to Address Modernization Goals That Could Facilitate SSN Removal but Has Not Made Specific Plans for Leveraging Efforts: Conclusions: Recommendations for Executive Action: Agency Comments and Our Evaluation: Appendix I: Objectives, Scope, and Methodology: Appendix II: GAO's Assessment of Three CMS Systems and the Types of Potential Changes Needed to Support SSN Removal: Appendix III: Comments from the Department of Health & Human Services: Appendix IV: GAO Contact and Staff Acknowledgments: Tables: Table 1: Description of HETS and Examples of Potential Changes Needed to Support SSN Removal: Table 2: Description of FISS and Examples of Potential Changes Needed to Support SSN Removal: Table 3: Description of MBDSS and Examples of Potential Changes Needed to Support SSN Removal: Figures: Figure 1: Medicare Card: Figure 2: Flow of Data and Use of the Health Insurance Claim Number in CMS's and Medicare Stakeholders' Systems: Abbreviations: CIO: chief information officer: CMS: Centers for Medicare and Medicaid Services: COBOL: Common Business-Oriented Language: DOD: Department of Defense: FISS: Fiscal Intermediary Standard System: GUI: graphical user interface: HETS: HIPAA Eligibility Transaction System: HHS: Department of Health and Human Services: HICN: Health Insurance Claim Number: HIPAA: Health Insurance Portability and Accountability Act: IT: information technology: IUI: integrated user interface: MARx: Medicare Advantage and Prescription Drug System: MBD: Medicare Beneficiary Database: MBDSS: Medicare Beneficiary Database Suite of Systems: MBI: Medicare Beneficiary Identifier: OMB: Office of Management and Budget: SSA: Social Security Administration: SSN: Social Security number: VA: Department of Veterans Affairs: VSAM: Virtual Storage Access Method: XLC: Expedited Life Cycle: [End of section] GAO: United States Government Accountability Office: 441 G St. N.W. Washington, DC 20548: September 10, 2013: The Honorable Sam Johnson: Chairman: Subcommittee on Social Security: Committee on Ways and Means: House of Representatives: The Honorable Kevin Brady: Chairman: Subcommittee on Health: Committee on Ways and Means: House of Representatives: As one of the federal government's largest programs, Medicare provides health insurance to the nation's elderly, certain disabled individuals, and individuals with end-stage renal disease. The program, which served approximately 50 million beneficiaries in 2012, consists of four parts: A, B, C, and D. Parts A and B are referred to as fee-for-service programs, and respectively, provide health insurance coverage for (1) hospital and inpatient stays, hospice, and home health services; and (2) hospital outpatient, physician, and other services such as home health care, and durable medical equipment such as wheelchairs and walkers.[Footnote 1] The Centers for Medicare and Medicaid Services (CMS)--the federal agency within the Department of Health and Human Services (HHS) that administers Medicare--and its contractors process more than a billion fee-for-service claims each year.[Footnote 2] These claims for payment are submitted by about 1.5 million health care providers such as physicians, hospitals, and medical equipment suppliers. The providers are reimbursed by Medicare for services and supplies that they deliver to beneficiaries in accordance with Parts A and B rules.[Footnote 3] For their part, Medicare beneficiaries show proof of eligibility for coverage under Parts A and B by presenting printed insurance cards to their providers at the point of care. The approximately 50 million cards that have been issued and are currently in use display Social Security numbers (SSN) as a component of beneficiaries' claims identification numbers. However, the visual display of the SSN introduces risks to the security of beneficiaries' personal information, as the number may, among other things, be obtained and used by criminals to conduct identity theft. CMS depends on more than 200 information technology (IT) systems to support administration of the Medicare program, including determination of eligibility for benefits, processing and payment of claims, and exchange of Medicare-related data with external stakeholders. Many of these systems were developed decades ago and are difficult to modify or update to incorporate changes in business rules or data, or to integrate with other systems. In 2010 the agency assessed its IT environment in response to direction from the Patient Protection and Affordable Care Act[Footnote 4] and began to take steps toward planning an agencywide IT modernization initiative. At your request, we conducted a study of CMS's efforts related to the removal of SSNs from Medicare cards. Our specific objectives were to (1) assess the actions CMS has been taking to identify and implement IT solutions for removing SSNs from Medicare beneficiaries' cards, and (2) determine whether CMS's ongoing IT modernization initiatives could offer opportunities to facilitate efforts to remove the SSN from the cards. To address the first objective, we examined documentation that described studies the agency conducted in 2006, 2011, and 2013 of different approaches toward removing SSNs from Medicare cards. Specifically, we focused our work on results of the most recent study and assessed relevant technical documents, such as those which identify system components that would be affected by the removal of the SSN from cards, and other documents that describe the data and message format requirements for exchanging data between systems. We compared activities identified in these documents to department-level requirements for identifying, developing, and implementing technical solutions for business processes. We also assessed a sample of the systems that CMS identified as ones that would be affected by the removal of the SSN from cards. We based our selection on the level of effort CMS estimated would be needed to implement modifications and the functionality provided by the systems. Specifically, we identified 29 systems that we determined accounted for over 90 percent of the total estimated level of effort and selected 3 for our assessment--1 with a low estimate, 1 with a high estimate, and 1 that provided critical functionality within the claims processing IT environment. We examined technical documents for these 3 systems, such as those that describe architectural characteristics, data formats, and exchanges with other systems. To further address the objective, we examined data collected by CMS from the federal stakeholders with whom it exchanges data related to Medicare beneficiaries--the Social Security Administration (SSA) and the Railroad Retirement Board. We also held discussions with Medicaid program officials from eight states to obtain their perspectives on roles they played in CMS's SSN removal study. We selected these states based on the level of effort they estimated would be needed to make changes to their systems to address SSN removal. The information we obtained from them is not generalizable to all Medicaid programs but provides insight into the extent to which CMS involved program stakeholders in conducting its 2013 study. To address the second objective, we identified criteria by examining federal laws and guidance for leveraging IT modernization initiatives to guide systems development,[Footnote 5] and assessed plans and briefings describing CMS's initiatives to modernize its IT environment. To determine the extent to which the goals and objectives of these initiatives could be leveraged to facilitate the SSN removal effort, we compared descriptions of specific modernization projects to information obtained from agency technical documents describing the systems that would have to be modified if the SSN were to be removed from cards. In making these comparisons, we identified common characteristics and efforts that could be coordinated to achieve efficiencies in implementing system changes. To supplement our assessment of documentation and data relevant to both objectives, we held discussions with CMS officials from the agency's Office of Information Services, including the Chief Information Officer (CIO), regarding actions taken to collect and analyze information needed to complete the 2013 study. We also discussed with these officials the steps they took to involve stakeholders in identifying approaches for removing the SSN from cards and assessing the potential impact on IT systems. Finally, we obtained descriptive information from the agency's CIO and other Office of Information Services officials regarding plans and ongoing initiatives intended to lead to the modernization of CMS's IT environment. A more detailed description of our objectives, scope, and methodology is provided in appendix I. We conducted this performance audit from October 2012 to September 2013 in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objectives. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objectives. Background: The use of SSNs on identification cards by federal, state, and private organizations, such as health insurance companies, was prevalent until the early 2000s. However, many organizations have since replaced these types of identification cards with those that do not contain SSNs. This step was taken, in large part, in response to certain federal and state laws that place restrictions on entities' use and disclosure of consumers' personal information, including SSNs. Examples of federal laws include the Driver's Privacy Protection Act,[Footnote 6] which generally prohibits a state department of motor vehicles from disclosing or otherwise making available SSNs and other personal information from a motor vehicle record, and the Health Insurance Portability and Accountability Act (HIPAA)[Footnote 7] and its implementing regulations, which protect the privacy of health information that identifies an individual (including by SSNs) and restricts health care organizations from disclosing such information to others without the patient's consent. Additionally, several state statutes include provisions related to restricting the display of SSNs, their unnecessary collection, and their disclosure without the individual's consent. Many state agencies have discontinued the use of the numbers on identification cards and other documents, such as driver's licenses, to comply with such laws. Similarly, private sector health insurers have discontinued use of SSNs on insurance cards in an effort to protect beneficiaries' personal health information. Certain federal agencies, including the Departments of Defense (DOD) and Veterans Affairs (VA), have similarly taken actions to remove the numbers from identification cards.[Footnote 8] For example, in June 2011, DOD completed efforts begun in 2008 to replace almost 10 million military identification cards that had SSNs printed on them with cards that stored the numbers in bar codes. Additionally, in November 2004, VA completed a project begun earlier that year aimed at replacing almost 8 million cards that contained the printed number. The department did so by embedding the numbers in magnetic stripes on the cards. However, both DOD and VA continued to use the number as an identifier and have described other steps they are taking to better protect beneficiaries against theft or improper use of the numbers. Specifically, DOD officials stated that the department is in the process of developing and implementing a solution for removing embedded SSNs from the bar codes on military identification cards and replacing them with a new identifier; they plan to complete this project in late 2016.[Footnote 9] Additionally, VA is working to remove the number embedded in magnetic stripes because of increased security risks introduced by the prevalence of electronic readers on devices such as smart phones; it plans to complete this project in late 2016. Use of SSN-Based Health Insurance Claim Number by CMS and Its Stakeholders: Since the inception of Medicare in 1965, CMS and its program stakeholders--SSA, the Railroad Retirement Board, and state Medicaid programs--have used an SSN-based identifier when filing and processing fee-for-service claims, and when exchanging data related to the Medicare program. This number, referred to as the Health Insurance Claim Number (HICN), is displayed on Medicare beneficiaries' health insurance cards. Individuals' eligibility to participate in the Medicare fee-for- service programs is initially determined by SSA, based on factors such as age, work history, contributions made to the programs through payroll deductions, and the presence of certain medical conditions. Once SSA determines that an individual is eligible, it provides information about the individual to CMS, including the SSN and a 1-or 2-digit beneficiary identification code.[Footnote 10] These data are transmitted to and stored in CMS's Enrollment Database--the repository of data about individuals who are or have ever been on Medicare. This system combines these two data fields to create the 10-or 11-digit HICN. CMS prints and issues to the individual a paper identification card (similar to the example shown in fig. 1) that displays the HICN (i.e., the Medicare claim number), the cardholder's full name, his or her gender, and the effective dates of Medicare program eligibility. Figure 1: Medicare Card: [Refer to PDF for image: illustration] Medicare Health Insurance: 1-800-MEDICARE (1-800-633-4227) Name of Beneficiary: Jane Doe. Medicare Claim Number: 000-00-0000-A. Sex: Female. Is entitled to: Hospital (Part A); effective date: 07-01-1986; Medical (Part B); effective date: 07-01-1986. Sign here: Source: Centers for Medicare & Medicaid Services. [End of figure] The HICN is maintained and referenced throughout CMS's IT environment. For example, health care providers may reference Medicare beneficiaries' printed cards at the point of care to determine eligibility for the fee-for-service program. Providers may then query a CMS system using the HICN printed on the card, along with other demographic data, to obtain information regarding eligibility for specific treatments or services they intend to deliver, such as glaucoma screening or smoking cessation counseling. Specifically, the agency provides verification services through its HIPAA Eligibility Transaction System (HETS), which allows providers to access real-time data regarding beneficiaries' eligibility at the point at which care is scheduled or delivered. Likewise, providers are required by CMS to use the number when they submit claims to receive payment for those treatments and services. CMS's and its contractors' systems also process data based on the HICN to check for duplicate claims, apply claims and medical policy edits, issue Medicare Summary Notices, authorize or deny payment of claims, and conduct printing and mailing operations.[Footnote 11] For example, CMS's Medicare Administrative Contractors, who are responsible for processing and paying claims, use their own systems to determine whether fee-for-service claims meet certain requirements, such as completeness of data. Specifically, if a claim did not include the HICN or other required data, the contractor's system would return it to the provider as incomplete or invalid. Once the aforementioned contractors' systems determine that claims meet initial data requirements, the contractors use one of three CMS systems, depending on the type of claim, to continue and complete claims processing.[Footnote 12] These systems, referred to as "shared systems" (because they are used to continue processing claims received from all the Medicare Administrative Contractors), use the HICN to retrieve data from the contractors' files about the beneficiary for whom the claim is submitted. The shared systems apply additional coverage and payment policy criteria, such as whether a certain treatment or service is allowed, and may approve the claims submission, automatically deny claims that do not meet these criteria, or flag them for review by staff. Approved claims are sent by the shared systems to the central CMS system that authorizes payment for claims. This system, known as the Common Working File, verifies beneficiary eligibility, coordinates Part A and Part B benefits, and determines the extent of Medicare's responsibility for payment based on such factors as whether beneficiaries' deductibles have been met. Electronic inputs to the Common Working File include the HICN, which is used to retrieve data from the Enrollment Database that are relevant to eligibility and coverage determinations. After being processed by the Common Working File, claims are returned to the appropriate shared system for final processing, and, if determined to be valid, payments are sent to the providers who filed the claims. The Common Working File also provides transaction data to other systems, including HETS, on a daily basis. These data are used to update those systems' databases. In addition to using the HICN to support the provision of and payment for health care to Medicare beneficiaries, CMS and its federal stakeholders, SSA and the Railroad Retirement Board, use the number to share data needed to coordinate health insurance coverage and payments for premiums. In this regard, CMS provides information that includes the number to SSA when beneficiaries' eligibility status or other data change, and SSA refers to the HICN when beneficiaries request replacement of lost Medicare cards. CMS also shares data that include the number with the Railroad Retirement Board when it administers health benefits for railroad retirees who are eligible for Medicare. [Footnote 13] Further, CMS and the 56 state and territorial Medicaid programs share data based on beneficiaries' HICNs. Specifically, these programs provide the number along with other data on their beneficiaries that are used to help identify individuals who are eligible for both Medicare and Medicaid benefits. The states also provide information regarding Medicaid beneficiaries for whom their programs pay Medicare Part A or B premiums. In turn, CMS provides several types of data to the Medicaid programs based on the HICN, including data needed to coordinate payment for claims when a beneficiary is covered by multiple insurers and information on the current drug prescription insurer for beneficiaries who are covered by Medicare Part D private plans. Figure 2 depicts a simplified view of the flow of data and the use of the HICN in CMS's and its stakeholders' systems. Figure 2: Flow of Data and Use of the Health Insurance Claim Number in CMS's and Medicare Stakeholders' Systems: [Refer to PDF for image: flow diagram] Social Security Administration: Sends Social Security Number (SSN), Beneficiary Identifier Code (BIC), and other beneficiary data to Centers for Medicare and Medicaid Services (CMS). Centers for Medicare and Medicaid Services (CMS): Sends card to beneficiary; Creates Health Insurance Claim Number and updates Medicare Enrollment Database System[A]. Railroad Retirement Board: Sends SSN, BIC, and other beneficiary data to Medicare Enrollment Database System[A]. Beneficiary: Beneficiary identifier sent to Provider. Medicare Beneficiary Database Suite of Systems[A]: Beneficiary eligibility data sent to HIPAA Eligibility Transaction System[A]; Utilization data received from Common Working File[A]. Eligibility data, premiums to and from State Medicaid agencies; Medicare Enrollment Database System[A]: Service eligibility data sent to Common Working File[A]. HIPAA Eligibility Transaction System[A]: Verify beneficiary eligibility to and from Provider. Provider: Submit claim to Medicare Administrative Contractor (MAC) systems[A]. Medicare Administrative Contractor (MAC) systems[A]: Claims data sent to Shared systems (Fiscal Intermediary Standard System, Multi-carrier System, ViPS Medicare System[A]. Shared systems[A]: Adjudicated claims data sent to MAC systems[A]; Prepayment claims to Common Working File[A]; MAC systems[A]: Payment to Provider; Medicare summary notice to Beneficiary; Claims payment information to Coordination of benefits contractor. Common Working File[A]: Claims authorized for payment to Shared systems[A]. Coordination of benefits contractor: Payment information to Private Health plans; Payment information to State Medicaid agencies. Source: GAO analysis of CMS data. [A] Centers for Medicare and Medicaid Services systems. [End of figure] CMS's IT Environment and Modernization Initiatives: In 2010, CMS officials developed a plan to upgrade the agency's IT environment and noted that the modernization of enterprise information systems and the supporting infrastructure was necessary in order for CMS to continue to meet its mission. Further, two scientific advisory committees that later evaluated CMS's IT environment[Footnote 14] found that the agency operated in a "stove-piped" environment in which many systems were developed to meet specific time-sensitive and legislatively driven needs, such as claims processing and eligibility determination, without consideration of the need for systems to interoperate or integrate data from other sources. The committees indicated that, because the agency continues to operate in such an environment, enhancement and sharing of data across its systems can be costly, risky, and time-consuming. In 2013 the agency took steps to update the 2010 IT modernization plan. According to officials in the Office of Information Services, this was to address recommendations resulting from the two advisory committees' evaluations. These officials described seven goals of the plan, the first of which is to establish an architecture that supports the development and implementation of IT functions, known as "shared services," that can be provided to support multiple needs of organizations conducting business within or between federal agencies. [Footnote 15] Other goals include, but are not limited to, the transformation of the agency's IT operations to enable CMS to use technologies such as cloud computing and virtual data centers; improvements to privacy and security controls to better protect personal health information stored and processed by the agency; and the transition to a coordinated, enterprise approach toward developing and implementing IT solutions. The Chief Information Officer stated that the agency was continuing to work toward addressing the seven goals defined in 2013. Prior Reports on CMS's and Other Agencies' Use and Display of SSNs: Both the SSA and HHS inspectors general have reported on risks associated with the use of the SSN on Medicare cards and have recommended that SSA and CMS work toward identifying alternate identifiers to better safeguard Medicare beneficiaries' SSNs.[Footnote 16] Additionally, we have previously issued reports that addressed federal agencies' use and display of SSNs on identification cards and for other purposes, as well as CMS's study of this issue. In a 2004 study, we found that SSNs were widely exposed to view in a variety of public records, particularly those held by state and local governments, and appeared in some public records nearly everywhere in the nation.[Footnote 17] We reported that SSNs are a key piece of information used in identity thefts, and that the widespread use and retention of the number by both the public and private sectors may provide opportunities for criminals to easily obtain and misuse this personal information. We stressed that the display of nine-digit SSNs on such cards, which may need to be carried and must often be disclosed, puts cardholders at risk for identity theft due to the increased potential for accidental loss, theft, or visual exposure. To help mitigate this risk, we recommended that the Office of Management and Budget (OMB) identify those federal activities that require or engage in the display of SSNs on health insurance, identification, or any other cards issued to federal government personnel or program beneficiaries, and devise a governmentwide policy to ensure a consistent approach to this type of display. In response to our recommendation, in May 2007 OMB issued a memorandum that required federal departments to establish a plan to eliminate unnecessary use of SSNs. We reported again in 2006 that there were gaps in federal requirements for protecting SSNs.[Footnote 18] Specifically, we noted that Congress could consider possible options for addressing gaps related to safeguarding SSNs shared with contractors by private companies. We also reported in 2006 that the threat of identity theft was heightened by the visual display of SSNs on federal identification cards.[Footnote 19] We noted that there were gaps in federal and state agencies' practices for protecting SSNs and that Congress was still considering actions to address the issues that remain. More recently, in 2012 we assessed the results of CMS's 2011 study of the cost and effort associated with three approaches to removing SSNs from Medicare cards.[Footnote 20] As a result of our assessment, we reported in August 2012 that CMS had not committed to removing the SSNs and lagged behind other federal agencies. We recommended that the agency select an approach for removing the SSN from the Medicare card that best protects beneficiaries from identity theft and minimizes burdens for providers, beneficiaries, and CMS. We also recommended that it develop an accurate, well-documented cost estimate for such an option using standard cost-estimating procedures. CMS officials concurred with our recommendations and, as discussed later in this report, took actions to address them. CMS Has Not Actively Pursued an IT Solution but Has Taken Actions That Could Support Efforts to Do So: CMS has not yet taken steps needed to select and implement a technical solution for removing SSNs from Medicare cards. Since 2006, the agency has conducted three studies on potential approaches to replacing the SSN-based Medicare identifier, issuing reports to Congress on the results of those studies in October 2006, November 2011, and May 2013. [Footnote 21] However, while each of the studies addressed, at a high level, the impact of various approaches on CMS's IT environment, they were not intended to identify a specific technical solution for removing SSNs from cards. Specifically, according to CMS, a 2006 study was initiated in response to congressional concerns regarding identity theft and expectations that the Secretary of Health and Human Services would accelerate ongoing plans to convert the HICN to a non-SSN based identifier for display on Medicare beneficiaries' health insurance cards. The second study was conducted to respond to congressional requests for CMS to re- examine approaches and costs of removing the SSN from the cards. Officials in the Office of Information Services, the CMS entity that would be responsible for identifying and implementing a technical solution for SSN removal, stated that the 2006 and 2011 studies were intended to develop "rough order of magnitude" estimates of costs and efforts associated with a potential SSN removal project. In response to a request by congressional committee members and to address our August 2012 recommendation,[Footnote 22] the agency initiated a third study in August 2012 and issued the resulting report to Congress in May 2013. According to CMS officials, the third study was conducted to provide cost estimates that were more reliable than those previously reported. The new estimates for two approaches documented in the 2013 report were approximately $255 million and approximately $317 million, including the cost of efforts to develop, test, and implement modifications that would have to be made to the agency's IT systems. The costs of the IT-related efforts for the two approaches were estimated at about $26 million (10 percent of the $255 million total estimated cost) and $64 million (20 percent of the $317 million total estimated cost), respectively.[Footnote 23] According to the May 2013 report, the estimates were based on the assumption that these efforts would span an 18-month period, from October 2013 to April 2015. According to Office of Information Services officials, however, these costs and schedules represented high-level estimates based on the two overall approaches and did not fully reflect the effort that would be required to implement a specific IT solution. Furthermore, while the 2013 report noted that one of the two approaches would better protect beneficiaries' personal information, the officials said that the agency did not intend for this study to result in the identification of an IT solution to address SSN removal. CMS officials stated that any initiatives specifically intended to identify an IT solution to address SSN removal would need to be conducted in accordance with departmental processes and requirements for managing the life cycle of IT projects.[Footnote 24] In this regard, CMS's IT project life-cycle management guidance, the Expedited Life Cycle (XLC) framework, defines the activities that are required to execute and monitor the development of IT projects throughout five phases--project initiation, requirements analysis and design, development and test, implementation, and operations and maintenance. The framework requires the following activities to be completed as part of a project initiation phase before the IT organization takes subsequent steps to identify technical solutions that support business needs: * designate a business owner to serve as an advocate for the project; * identify a business need for which a technological solution is required and a business case is established; * explore alternative concepts and methods to satisfy the need; * develop and approve initial project cost, preliminary schedule, performance baseline, and basic business and technical risks; * conduct a preliminary enterprise architecture review to determine whether the proposed project potentially duplicates, interferes with, contradicts, or can leverage another project that already exists or is proposed, under development, or planned for near-term disposition; * identify significant assumptions and constraints on solutions relative to that need; * issue a project charter; and: * conduct a selection review to determine if the proposed project is sound, viable, and worthy of funding, support, and inclusion in the information technology project portfolio. However, CMS has not taken a number of the key steps called for by the IT project life-cycle management guidance to identify an IT solution to address SSN removal and has not made plans to do so. For example, it has not completed several steps of a project initiation phase, such as designating a business owner who would submit a request to the Chief Information Officer to initiate an IT project. Additionally, the agency has not established a business case for developing an IT solution to address SSN removal, issued a project charter, or presented a potential IT project for SSN removal to an architectural review board for preliminary review and approval. Furthermore, CMS has not conducted a selection review to determine if such an IT project should be included in its portfolio of IT investments. Nonetheless, when conducting the 2013 study, agency officials undertook activities that could address certain steps called for by the agency's IT project life-cycle management processes for initiating a project, and that could provide information needed for identifying and implementing a technical solution, including the following: * CMS officials and program stakeholders explored alternative concepts for addressing the business need, which is one of the steps called for by agency IT project management guidance. Specifically, from September 2012 through December 2012, Railroad Retirement Board and SSA officials participated in work groups with CMS to determine potential approaches to SSN removal. As a result, they identified two approaches: (1) replacing the SSN-based HICN with a new identifier that does not include the SSN, referred to as the Medicare Beneficiary Identifier; and (2) truncating the first five digits of the SSN for display on Medicare cards. Agency officials conducting the study ruled out other options, such as embedding the number in smart cards or magnetic strips, because they were determined to be too costly, technically infeasible, or burdensome to providers and beneficiaries. * Project officials collected information that could be used to develop initial project costs and identify basic business and technical risks associated with implementing each approach. Specifically, officials conducting the 2013 study collected data that could be used for establishing a technical baseline for cost estimates, such as the level of effort system owners estimated would be required for each life-cycle phase.[Footnote 25] Project officials also collected input from system and business owners regarding technical and business risks associated with the two approaches. For example, the owners of one of the shared systems described a risk that unacceptable processing times would result from the implementation of a mechanism for translating between the HICN and a new identifier. This information could be useful in identifying efficient translation mechanisms that would be less likely to introduce such a risk. * Agency officials took steps to determine the changes that would have to be made throughout the agency's and program stakeholders' IT environment. The results of these actions could provide information essential to conducting a preliminary enterprise architecture review-- another step required for initiating an IT project. Specifically, officials conducting the 2013 study identified internal and external stakeholder systems that could be affected if the SSN was removed from cards, and identified other IT initiatives that could be coordinated with an SSN removal project. For example, during the 2013 study, CMS system and functional-level business owners conducted high-level impact assessments of the two approaches on the agency's business processes and all systems identified in its information technology inventory.[Footnote 26] Of CMS's more than 200 systems, these officials identified 72 systems that could be affected by the introduction of a new identifier and 41 that would be affected by the second approach (masking the first 5 digits of the SSN).[Footnote 27] They conducted high-level assessments of the types of changes that would need to be made to those systems, including the level of complexity of the changes, the number of hours of work at each life- cycle phase, and the potential to leverage related efforts. Appendix II provides a detailed assessment of the types of system changes that would have to be made to three internal CMS systems that provide functionality key to determining beneficiaries' eligibility for specific treatments and services, validating and adjudicating Part A claims, and sharing data for coordination of benefits payment between Medicare and program stakeholders. * Agency officials also established assumptions regarding the two approaches for SSN removal. For example, when collecting data regarding the impact on its internal systems, system owners were instructed to assume that a crosswalk service would be available to translate the HICN to a new identifier, and that the new identifier would retain the same length as the existing HICN but have a different format. CMS officials also established assumptions regarding conditions under which data exchanged with external stakeholders would include either number. * CMS collected data from its federal partners to estimate the impact of the proposed approaches on external systems. For example, officials conducting the 2013 study collected level-of-effort estimates from SSA and the Railroad Retirement Board for implementing changes to their affected systems. Although their estimates varied, the changes these stakeholder officials described were similar. SSA officials stated that they would have to make system changes to identify beneficiaries when they contact SSA and provide the new identifier, instead of the HICN, to request a new Medicare card. Railroad Retirement Board officials also stated that they would have to make changes in order to use the new identifier instead of the HICN when issuing or replacing retirees' Medicare cards.[Footnote 28] * CMS also involved state program stakeholders and collected high- level estimates of changes that would have to be made to states' Medicaid systems.[Footnote 29] Because each state implements IT solutions to support its unique Medicaid program, the design, implementation, and level of effort estimated to modify their systems varied widely. For example, we assessed Medicaid program estimates provided to CMS by eight states. Of these, three states estimated that less than 500 hours would be needed to make the changes, in part because some of the systems already convert identifiers. One of these states reported that no effort would be required since their systems were already capable of updating records when changes to identifiers are made. On the other hand, officials with another state Medicaid program estimated that about 22,000 hours of effort would be needed to, among other things, expand databases to include a new identifier, and another estimated that over 58,000 hours would be required to modify systems to process functions based on a new identifier, including Medicare buy-in,[Footnote 30] eligibility determination, and Part D processing systems. Three other states estimated around 4,000 hours of work to implement mechanisms to cross reference or convert the HICN to a new identifier. While the data and information collected during the 2013 study could be leveraged to support a future IT project to address SSN removal, according to officials with CMS's Office of Information Services, the agency's Chief Information Officer has not received direction from CMS's leadership to submit a proposal for an IT project that would lead to the identification, development, and implementation of a technical solution. We have noted in prior reports the importance of protecting Medicare beneficiaries from increased risks of identity theft, and OMB has required federal agencies to take steps to eliminate unnecessary uses of SSNs. We have also noted that federal agencies' Chief Information Officers are responsible for, among other key IT management areas, information security along with systems development and integration.[Footnote 31] Additionally, CMS has designated the Office of Information Services as the lead for developing and enforcing the agency's IT policies, standards, and practices. As such, these entities should play an active role in pursuing IT solutions for securing personal data, such as Medicare beneficiaries' SSNs. The data and information the Office of Information Services collected during the 2013 study could provide valuable input to future efforts to define such a solution. Nonetheless, until the agency designates a business owner, establishes a business case, issues a project charter, and conducts architectural and IT project selection reviews for SSN removal, it will lack sufficient information and resources needed to actively pursue the identification of an IT solution for SSN removal that best protects beneficiaries' identities. CMS Has Initiated Actions Intended to Address Modernization Goals That Could Facilitate SSN Removal but Has Not Made Specific Plans for Leveraging Efforts: CMS has efforts under way to modernize its IT systems, a number of which could be leveraged to facilitate the removal of SSNs from Medicare cards. For example, one of the agency's modernization goals is to establish IT functionality that can be used to support multiple business needs of organizations and facilitate data sharing among the agency and its stakeholders. This and other goals were described by Office of Information Services officials who indicated that the agency is in the process of developing an agencywide IT modernization strategy to align with newly defined business goals. A well-defined modernization strategy includes plans for systems that are integrated into an enterprise's IT environment and that do not duplicate other systems' functionality. By planning accordingly, agencies increase the likelihood that they will design and develop systems that easily exchange information with other systems and improve their ability to modernize systems in a timely and cost- effective manner.[Footnote 32] In this regard, CMS has initiated actions that could eliminate duplicative programming efforts and help establish standards for integrating new systems and making the modifications to existing systems needed to implement an IT solution for SSN removal. For example, CMS officials with the Office of Information Services described modernization projects that were initiated to support administrators' ability to carry out other programs and that were aligned with the first of the seven stated modernization goals--to establish an IT architecture capable of supporting the development and implementation of shared services. Specifically, the agency established such an architecture to implement five shared services to support the administration of other agency programs, including but not limited to, programs established by the Affordable Care Act. The shared services are: * Enterprise Identity Management, which is planned to enable individuals to use a single online identity (e.g., user ID) for engaging in business with CMS that meets all federal security requirements; * Master Data Management, which is a suite of data records and services that will allow CMS to link and synchronize beneficiary, provider, and organization data to multiple disparate sources; * Enterprise Portal, a central channel for beneficiaries, providers, organizations, and states to receive CMS information, products, and services via consistent web pages; * Business Rules Enterprise Service, which provides a framework for automating and managing decision logic and routines for CMS programs (e.g., provider and beneficiary cross check for Accountable Care Organization programs); and: * Enterprise Eligibility, a consistent and reusable way for business applications to access beneficiary eligibility data for a variety of uses (e.g., claims processing, providers and plans, and external programs). In implementing these services, the agency has taken some steps that could help define and put into place the necessary architectural components and standardized interfaces to enable sharing of the services' capabilities across the IT infrastructure and CMS's business areas. One of the five shared services that CMS implemented, the Business Rules Enterprise Service could facilitate the implementation of an IT solution for SSN removal. For example, the IT infrastructure that was established to implement the service could support the implementation of a crosswalk service needed by multiple systems to translate a new identifier to the HICN (and vice versa). By providing this functionality through a shared service, the crosswalk would be available for use by any system within CMS's IT infrastructure and therefore eliminate the need to duplicate programming efforts for each system to implement such functionality. Specifically, if such a shared service were implemented to support an SSN-removal IT project, it would be available for use by all the systems that, according to CMS officials, would have to be modified to use a new identifier. As a result, of the 20 systems that the agency estimated would account for 86 percent of the costs to modify, systems changes would only have to be developed and tested for one implementation rather than for 18 of the 20 systems that would need to perform a crosswalk between a new identifier and the existing HICN.[Footnote 33] In addition to the five shared services described, another shared service, the Beneficiary Data Streamlining service, was designed to consolidate into one system the functionality for determining fee-for- service eligibility that is currently implemented in four different systems (the Common Working File and the three shared systems). This new service, which is planned to be implemented in October 2013, would be used by these systems to eliminate duplicate or unnecessary processing. Consequently, the implementation of the service could also facilitate SSN removal efforts. For example, it could reduce the extent of modifications that would have to be made to the four systems by eliminating the need to make changes to their current eligibility determination functions to process a new non-SSN-based identifier. Instead, that capability would be provided by the new service. As a result, the agency could save unnecessary costs and efforts associated with duplicative programming changes to the four affected systems. While these projects could offer opportunities for leveraging ongoing modernization initiatives to facilitate SSN removal, CMS officials stated that because the agency has not yet established a business case and IT project for removing SSNs from Medicare cards, they have not included shared services or other IT initiatives in their modernization activities and related plans to specifically support changes needed as a result of SSN removal. Until CMS establishes an IT project for SSN removal that could be incorporated into ongoing agencywide modernization initiatives, it may miss opportunities to leverage other ongoing system development activities that could facilitate efforts to design, develop, and implement an IT solution in a timely and cost-effective manner. Conclusions: While CMS has spent time and resources over the past 7 years studying approaches that could be taken toward removing the SSN from Medicare beneficiaries' cards, the agency has not actively established and pursued a goal to identify an IT solution for doing so. The efforts made thus far by CMS and its stakeholders could provide some of the information needed to initiate an IT project to design and develop the system changes that would have to be made to address an agencywide effort to better safeguard Medicare beneficiaries' identity. However, until the agency takes other critical steps, such as designating a business owner, establishing a business case, issuing a project charter, and conducting architectural and IT project selection reviews, it will not be in a position to design, develop, and implement the changes that would have to be made to systems affected by the removal of SSNs from display on Medicare beneficiaries' health insurance cards. Additionally, the agency may miss opportunities to improve the timeliness and cost effectiveness of any actions taken to develop and implement a technical solution that could be achieved if it incorporated such actions into plans for ongoing enterprisewide IT modernization initiatives. Recommendations for Executive Action: To better position the agency to efficiently and cost-effectively identify, design, develop, and implement an IT solution that addresses the removal of SSNs from Medicare beneficiaries' health insurance cards, we recommend that the Administrator of CMS take the following two actions: * direct the initiation of an IT project for identifying, developing, and implementing changes that would have to be made to CMS's affected systems, including designating a business owner and establishing a business case, issuing a project charter, and conducting project selection and architectural reviews of proposed approaches for the removal of SSNs from Medicare beneficiaries' cards; and: * incorporate such a project into plans for ongoing enterprisewide IT modernization initiatives. Agency Comments and Our Evaluation: In written comments on a draft of this report, signed by HHS's Assistant Secretary for Legislation (and reprinted in appendix III), HHS stated that it appreciated the opportunity to review the report prior to its publication. Further, the department stated that it concurred with both of our recommendations under the condition that certain constraints were addressed. With respect to our first recommendation, HHS agreed that removing the SSN from Medicare cards is an appropriate step toward reducing the risk of identity theft, but that the agency could not make a decision to proceed with such a project without agreement from SSA and the Railroad Retirement Board. In addition, the department stated that a clear source of funding for both IT and non-IT activities associated with SSN removal would need to be identified before proceeding. However, as we noted in our report, CMS's Chief Information Officer and the Office of Information Services should play an active role in pursuing IT solutions for securing personal data, such as Medicare beneficiaries' SSNs. For this reason, it is important that CMS determine the appropriate actions to take toward initiating an IT project for addressing the removal of SSNs from cards and guide its stakeholders, such as SSA and the Railroad Retirement Board, in taking the steps needed to achieve the goals of any SSN removal project. In addition, the final step of the IT project initiation phase, as defined by CMS's IT life-cycle project management guidance, is a review to determine if proposed projects are worthy of funding and inclusion in an IT project portfolio. Accordingly, uncertainties regarding a clear source of funding should not constrain CMS from taking steps to initiate an IT project to address SSN removal. Regarding our second recommendation, HHS concurred, again with the caveat that the above-mentioned constraints were addressed. The department also noted that while CMS had not implemented its shared services initiative specifically for the purpose of SSN removal, the general functionality exists in the shared services to support this effort, and this was reflected in the agency's 2013 cost estimate. However, unless the agency considers SSN removal as part of its enterprisewide modernization initiative, it may miss additional opportunities for leveraging system changes being made as part of the modernization to support SSN removal. In this regard, we believe that CMS is currently positioned to implement both our recommendations, regardless of perceived constraints, and to take the actions needed to initiate an IT project as part of its agencywide modernization initiative. If such actions are taken CMS could improve HHS's ability to protect Medicare beneficiaries against increased risk of identity theft introduced by the use of SSNs on Medicare cards. HHS also provided technical comments, which we incorporated into the report as appropriate. As agreed with your offices, unless you publicly announce the contents of this report earlier, we plan no further distribution until 30 days from the report date. At that time, we will send copies to the Secretary of HHS and interested congressional committees. In addition, the report will be available at no charge on the GAO website at [hyperlink, http://www.gao.gov]. If you or your staffs have any questions about this report, please contact me at (202) 512-6304 or melvinv@gao.gov. Contact points for our Offices of Congressional Relations and Public Affairs may be found on the last page of this report. GAO staff who made key contributions to this report are listed in appendix III. Signed by: Valerie C. Melvin: Director: Information Management and Technology Resources Issues: [End of section] Appendix I: Objectives, Scope, and Methodology: The objectives of our review were to (1) assess the actions the Centers for Medicare and Medicaid Services (CMS) has been taking to identify and implement information technology (IT) solutions for removing Social Security numbers (SSN) from Medicare beneficiaries' cards, and (2) determine whether CMS's ongoing information technology modernization initiative could offer opportunities to facilitate efforts to remove the SSN from the cards. To determine the extent to which CMS has been taking steps to implement a technical solution for removing the SSN from Medicare cards, we examined studies conducted by agency officials in 2006, 2011, and 2013 of different approaches.[Footnote 34] We reviewed supporting documents that were used by project officials to gather information from system and business owners regarding the impact that two approaches would have on the agency's IT systems, including estimates of the levels of effort that would be needed to implement the changes that would have to be made to affected systems. We assessed the data from these documents, referred to as "workbooks," to determine the steps agency officials took that could be used to identify a technical solution for the two approaches-one to introduce a new identifier that does not include the SSN and another to mask the first five digits of the SSN in the existing SSN-based identifier, the Health Insurance Claim Number (HICN). We determined which activities resulted in outcomes that could be used to initiate actions towards identifying a specific technical solution by comparing documented results of CMS's efforts to requirements defined by CMS's processes for managing information technology projects to develop and implement technical solutions for business processes.[Footnote 35] To better understand the extent of changes that would have to be made to the systems, we assessed a sample of the systems that the agency identified as being affected by the removal of the SSN from cards and replacement with a unique, non-SSN-based number. To select the systems for our sample, we obtained and analyzed system impact workbooks for 29 systems that we determined accounted for over 90 percent of the total estimated level of effort needed to modify existing systems to process the new identifier. Based on our assessment, we determined that these systems provided adequate examples of the types of system modifications that would be required to implement a technical solution for agencywide efforts to remove the SSN from Medicare cards. Additionally, we focused our analysis of the data included in the workbooks on the option to replace the SSN-based identifier, the HICN, on the Medicare card with a new identifier since findings resulting from our prior assessment of CMS's 2011 report on SSN removal established this option as the one most likely to protect beneficiaries' SSNs and help prevent identify theft.[Footnote 36] From the 29 systems, we selected 3--1 system that represented a low level of effort based on the estimated levels of effort reported by system and business owners in the workbooks, 1 that represented a high level of effort, and 1 of the shared systems that performs a critical function--fee-for-service claims processing. To determine the types of changes that would have to be made to the systems, we examined technical documents to identify architectural components, data types, message formats, and interfaces with other systems that would have to be modified to either translate a new identifier to the HICN for internal processing, or translate the HICN back to the new identifier for purposes such as printing notices or new cards. We also held discussions with owners of the selected systems to confirm our understanding of the systems and related files and databases, along with the functionality they provide. In addition, we held discussions with CMS officials from the agency's Office of Information Services, including the Chief Information Officer, regarding actions taken to complete the 2013 study, particularly steps taken to collect information regarding the impact on CMS's existing IT systems. To further address the first objective, we determined the extent to which CMS involved stakeholders to estimate the levels of effort that would have to be made to address the two approaches for removing the SSN from Medicare cards. To do so, we reviewed documentation that described the actions CMS took to solicit input from its federal Medicare and state Medicaid program stakeholders, such as CMS's most recent report to Congress and documented results of stakeholders' assessment of the impact the SSN removal would have on their systems. [Footnote 37] We obtained and analyzed such documentation from the Social Security Administration and the Railroad Retirement Board, CMS's two federal program stakeholders. To select states for our study, we examined documents that were provided by 49 states and the District of Columbia in response to CMS's request for data related to the system changes that would have to be made. We then calculated the median level of effort estimated and selected states whose estimates represented high, medium, and low levels of effort.[Footnote 38] Specifically, we identified the 3 states that estimated the highest level of effort, 4 states that estimated a medium (or closest to the median) level of effort, and the 3 that estimated the lowest level of effort. Of the 10 that we selected, we received responses from 8--the 3 lowest, 3 of the medium, and 2 of the highest estimators. We assessed the data they provided to CMS and collected additional data by conducting semistructured interviews or through written responses to a standard set of questions. While we could not generalize the information we collected from the 8 states to reflect the level of participation by all 49 states and the District of Columbia, the views obtained from these state officials offered insights into the extent to which CMS involved its program stakeholders in assessing approaches for removing SSNs. We also held discussions with program stakeholders from each of the federal and state entities. To address the second objective, we identified criteria by examining federal laws and guidance on the importance of planning for modernization to guide systems development,[Footnote 39] and compared CMS's actions to identify potential system changes for SSN removal to these criteria. To do so, we examined modernization plans and briefings describing CMS's goals for modernizing the agency's IT environment along with documents that described the agency's ongoing modernization initiatives. Specifically, we examined CMS's plan for developing shared services, one of the modernization goals described by the Chief Information Officer and officials from the Office of Information Services. We then compared information obtained from this plan to descriptions of modifications to systems that would have to be made if the SSN were removed from cards. We also reviewed documentation provided to the Office of Information Services by the owners of these systems to identify other IT projects that could facilitate the development and implementation of a technical solution for an SSN removal effort. We interviewed CMS officials, including the Chief Information Officer, to obtain additional information regarding the agencywide IT modernization goals and objectives and the extent to which the goals and objectives addressed the removal of SSNs from Medicare cards. For each of the objectives, we assessed the reliability of the documentation we received from CMS, including the workbooks and technical documentation, by obtaining corroborating evidence through interviews with the agency's system and business owners who were knowledgeable of the various systems, the individuals who were responsible for filling out the workbooks at the states, and individuals knowledgeable about CMS's modernization efforts, including the Chief Information Officer. Based on how we used the information and the corroborating evidence provided in the interviews, we determined that the documentation and data provided by the agency were sufficiently reliable for the purposes of our review. We conducted this performance audit from October 2012 to September 2013 in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objectives. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objectives. [End of section] Appendix II: GAO's Assessment of Three CMS Systems and the Types of Potential Changes Needed to Support SSN Removal: We selected three systems for assessment to better understand the types of changes that would have to be made to process beneficiary data based on the introduction of a new identifier, or Medicare Beneficiary Identifier (MBI), to replace SSNs as data entered into the systems. The three systems are the HIPAA Eligibility Transaction System (HETS), the Fiscal Intermediary Standard System (FISS), and the Medicare Beneficiary Database Suite of Systems (MBDSS). (See app. I for a description of the methodology used to select and assess the systems.) The following tables provide descriptions of the systems and the functionality they provide, the number of hours that owners of the systems estimated would be required to modify the systems, and a summary of the technical characteristics and components (e.g., the programming languages and tools, software applications, data bases, data storage files, and outcomes of data processing) that would have to be considered in estimating the impact of removing SSNs from Medicare cards on these systems. Our assessments were conducted based on information collected from technical documentation relevant to each of the systems and from discussions with system owners in CMS's Office of Information Services. Table 1: Description of HETS and Examples of Potential Changes Needed to Support SSN Removal: Description: HETS was developed and implemented in 2005 to process query and response transactions that release patients' data to Medicare providers, or their authorized billing agents, to support their efforts to complete accurate Medicare claims when determining beneficiary liability and eligibility for specific services. Users and stakeholders: Medicare providers, suppliers, or their authorized billing agents. System and business owner(s): CMS's Business Applications Management Group and Provider Communications Group. CMS preliminary estimate of hours required to modify systems for SSN removal: CMS estimated that it would require 1900 hours (0.99 FTEs) to modify HETS to replace the SSN on the Medicare card with an MBI, with more than half of the hours required for development and system testing. This estimate is about 0.5 percent of the total effort estimated for the 29 systems from which we selected examples. Databases, key systems operations, and use of HICN: HETS is comprised of applications and databases. Users access HETS through one of two means, HETS 270/271 and HETS User Interface (UI).[A] According to officials, approximately 99.5 percent of queries are submitted to and processed by the 270/271 system. A key application of HETS, the Data Access Service, is used to access beneficiary data housed in the Integrated User Interface (IUI) database. Another database, referred to as the HETSLOG, records information about all HETS transactions, including the date, time, response time, and error messages. The HETSLOG and IUI databases include the HICN. HETS operates from CMS's data center in Baltimore, Maryland, and is accessed by users via the CMS extranet.[B] The system is comprised of software that processes query and response transactions, along with hardware, such as servers that support connections with users' facilities and the Internet, and devices that store the data provided by the system. The system software is designed to process transactions according to standards and formats defined by HIPAA. To request beneficiary eligibility information, HETS users submit beneficiary information, including the HICN, first and last name, and date of birth. Users can also request historical data for a beneficiary's eligibility. To protect the privacy of beneficiary information, the system checks for mismatches between the HICN and other data, and provides responses to errors occurring as a result from such mismatches. If the request does not have errors, the system queries the IUI database to retrieve information on the beneficiary's eligibility and responds to the provider. HETS creates a record of the query and the response. The response may include information about a beneficiary, including eligibility and deductible information for different services; information on preventive programs for the beneficiary, such as smoking cessation; plan coverage for Medicare Parts C and D; and information on the beneficiary's use of hospice and skilled nursing facilities. System technical description: operating system(s), programming language(s), and lines of code: * HETS is designed based on a service-oriented architecture framework that includes services for retrieving, processing, and displaying the beneficiary information[C]; * The HETS IUI database is an Oracle database that contains Medicare eligibility data for more than 93 million beneficiaries. The HETSLOG database is also an Oracle database; * Operating system: Unix; * Programming languages and tools: XML, Java, Helpdesk, JCD, JSP, and SQL; * Estimated lines of code: Approximately 37,360 lines of code inclusive of XML, Java, Helpdesk, JCD, JSP, and SQL. Examples of potential changes needed to implement non-SSN-based identifier: * A data element would be added for the MBI to the HETSLOG and IUI databases, so that requests for eligibility information can be processed based on the MBI; * HETS would be modified to use the MBI for processing eligibility requests and for accessing eligibility data. This includes changes to allow searches with the MBI as one of the data elements; * CMS would need to replicate systems' front-end edits for validating HICN size, length, and other data-typing characteristics for the MBI. This will ensure that the user entered the MBI in an acceptable format; * Changes would need to be made for the 6-month transition period during which users will be able to submit requests using either the HICN or MBI. These include (1) the ability to determine whether a query is submitted with a HICN or an MBI; (2) the ability to return results containing the MBI even when a HICN was submitted; and (3) at the end of the 6-month transition, stop allowing requests based on HICN; * Reports would need to be created to track the number of users who transition to using MBI; * Online user manuals would need to be updated to include the MBI in place of the HICN for capabilities or screens that currently use the HICN, and possibly expand help desk activities to assist users in transitioning to use of the MBI. Source: GAO analysis of data provided by CMS. [A] CMS officials stated that they plan to phase out the HETS User Interface and expect to do so by the first half of calendar year 2014. HETS users are to continue to have access to the 270/271 system and HETS users will be able to obtain eligibility information using an online portal provided by Medicare Administrative Contractors which is to provide similar screens to those of the UI but which is to use the 270/271 as the source of data. [B] An extranet is a computer network that allows controlled access from outside an organization's intranet, usually by partners, vendors, and suppliers, in isolation from all other Internet users. The CMS extranet is a secure closed private network used for transmission of electronic transactions between CMS and Medicare contractors, providers, or clearinghouses. [C] A service-oriented architecture is an approach for sharing functions and applications across an organization by designing them as discrete, reusable, business-oriented services. [End of table] Table 2: Description of FISS and Examples of Potential Changes Needed to Support SSN Removal: Description: FISS is a shared system that processes Part A and certain types of Part B claims for medical services from institutional providers such as hospitals and skilled nursing facilities. According to agency officials, FISS was developed between 1989 and 1990. The system performs a range of actions necessary to process claims, including validating claims against edits, reporting on the status of submitted claims, adjudicating claims, providing information for coordinating claims payment between Medicare and other insurers, submitting approved claims for payment to providers, and creating a complete record of each claim for historical and audit purposes. FISS is designed to process claims in 3 days with a minimum of manual intervention. Users and stakeholders: Institutional providers, including hospitals, submit claims, and Medicare Administrative Contractors[A] use FISS to process the claims. System and business owner(s): CMS's Center for Medicare, Medicare Contractor Management Group. CMS preliminary estimate of hours required to modify systems for SSN removal: FISS owners estimated that it would require 5,251 hours (2.73 FTEs) to modify FISS for SSN removal. The majority of the effort would be required for requirements analysis and design, development and testing, and implementation. This estimate is about 1.2 percent of the total estimated effort for modifying the 29 systems from which we chose examples. Databases, key systems operations, and use(s) of HICN: FISS includes a core claims processing system that reviews claims for errors and adjudicates claims, and a financial processing system that facilitates claims payment. The claims and financial systems are written using the Common Business-Oriented Language (COBOL) programming language. In place of a database, FISS uses a file system to store information on each claim. The FISS file system is implemented using IBM's Virtual Storage Access Method (VSAM).[B] The VSAM files are populated with claims data entered by users and beneficiary eligibility data from CMS's eligibility database. One design provision of the system is that all necessary data required for accurate claims adjudication, including HICNs, are retained in the FISS record to provide a reliable and auditable history of activity related to the claims. Once a claim is processed, the data are added to the Integrated Data Repository and the National Claims History database.[C] Claims data, including the HICN, can be entered by providers using either an online form, which allows providers to enter claims directly into FISS, or by batch submission of one or more claims to the provider's Medicare Administrative Contractor electronically. A very small percentage of claims (less than 1 percent) are submitted to the contractors on paper and the contractors' staff enter the claim data into the FISS system. Upon submission of a claim, FISS's Common Edits and Enhancements Module ensures the claim is compliant with the standard claim format and performs error checks. For example, error checks are performed to determine whether the claim is a duplicate of another filed claim, and whether the HICN was included with the claim; if not, the claim is returned to the provider as incomplete or invalid. In addition, FISS may identify additional information needed from the submitting provider to adjudicate the claim. If the claim passes this level of editing, the system then electronically transmits a portion of the claim data, including the HICN, to another CMS system, the Common Working File. This system then verifies beneficiary eligibility and conducts additional benefit utilization edits on the claim and either authorizes payment or returns the claim to the FISS system with an error code. Once the claim has been authorized by the Common Working File, FISS sends the adjudicated claim, including the HICN, to the Healthcare Integrated General Ledger Accounting System, which records accounting data and sends payment information back to FISS. To complete the claims process, FISS generates an Electronic Funds Transfer or a paper check as well as produces reports such as Medicare Summary Notices[D] for beneficiaries and payment remittance advice for providers, and sends claims information to coordination-of-benefits partners. System technical description: operating system(s), programming language(s), and lines of code: * Operating System: Primarily on z/OS-based IBM mainframes located at the two Enterprise Data Centers; * Programming languages and tools: COBOL, 96 percent; Assembly Language, 4 percent; JAVA, 0.1 percent; * Estimated lines of code: 3.2 million lines of COBOL and Assembly Approximately 160 JAVA Modules; 31,000 lines; * Updated per quarterly release: approximately 1,600 modules and 33,000 lines of code. Examples of potential changes needed to implement non-SSN-based identifier: * The system would be modified to access a crosswalk service to translate from the MBI to the HICN before it begins processing claims. This approach would enable claims to continue to be processed using HICN; * FISS would be modified to return a claim to the provider if the claim is submitted using an invalid MBI that the crosswalk service is unable to locate; * FISS would be modified to use the crosswalk service at multiple points in the claims adjudication process to verify whether the beneficiary's MBI is still valid. This step is needed because during the claims process, which can take between 3 days and up to 30 days, a beneficiary may receive a new MBI to replace a compromised MBI. Consequently, the system would need to use a crosswalk service during claims processing to check whether a new MBI was issued and, if so, update the MBI on the claim that is being processed; * Data exchanged with external partners would be modified to include the MBI. For example, claims information sent to coordination-of- benefit contractors would be modified; * All external claims reports would be modified to display the MBI instead of the HICN. For example, Medicare Summary Notices that are sent to beneficiaries on adjudicated claims would be modified; * To accommodate changes needed during the transition period when claims can be submitted using either the HICN or MBI, certain FISS capabilities would be modified to use the crosswalk service. For example, during the transition period if a claim is submitted using the HICN, FISS would use the crosswalk service to obtain the corresponding MBI; * Claims records would be modified to store the MBI in the FISS file in addition to the HICN on every record to ensure a reliable claim history and an audit trail for tracking clams processing. Source: GAO analysis of data provided by CMS. [A] Medicare Administrative Contractors process and pay claims, answer questions from Medicare providers, and implement Medicare coverage rules. CMS is replacing fiscal intermediaries--legacy claims payment contractors with jurisdiction for hospital providers and institutional suppliers--with Medicare Administrative Contractors. [B] IBM's Virtual Storage Access Method (VSAM) is a file system that includes functions for accessing data that are stored on a mainframe operating system. [C] The Integrated Data Repository is an enterprise data warehouse that includes Medicare and Medicaid data. It is intended to provide a single repository for the agency's data and enable data analysis within and across programs. The National Claims History database collects and maintains billing and utilization data on Medicare beneficiaries enrolled in hospital insurance (Part A) or medical insurance (Part B) for statistical and research purposes related to evaluating and studying the operation and effectiveness of the Medicare program. [D] The Medicare Summary Notice provides Medicare beneficiaries with a summary record of action taken on intermediary processed claims and the status of any deductible. [End of table] Table 3: Description of MBDSS and Examples of Potential Changes Needed to Support SSN Removal: Description: MBDSS was developed in 2003 and is comprised of the Medicare Beneficiary Database and several systems that provide a single, enterprisewide authoritative source for Medicare beneficiary demographic data. MBDSS receives and provides beneficiary data among CMS, the Social Security Administration (SSA), the Railroad Retirement Board, Medicare Advantage and Prescription Drug Plans, and state Medicaid program offices. In addition, MBDSS supports business processes such as Part D eligibility, beneficiary batch eligibility queries for plans, determining low-income beneficiaries, auto and facilitated assignment of beneficiaries to Part D Plans, mass mailings, and state phase down. MBDSS also disseminates data and notifications of changes to beneficiary demographic, eligibility, and enrollment data to various systems such as 1-800 Medicare, the Common Working File, the True-out-of-pocket Expenditures System,[A] Retiree Drug Subsidy System, Medicare Advantage and Prescription Drug (MARx) System, and the Enrollment Database. Users and stakeholders: Users include CMS central and regional offices, CMS systems such as the Common Working File and the True-out-of-pocket Expenditures System, SSA, Railroad Retirement Board, Medicare Advantage and Prescription Drug Plans, and state Medicaid program offices. System and business owner(s): Office of Information Services, Innovative Healthcare Delivery Systems Group and Center for Medicare, Center for Drug and Health Plan Choice, Medicare Enrollment and Appeals Group. CMS preliminary estimate of hours required to modify systems for SSN removal: CMS estimated that it would require 40,312 hours (21 FTEs) to modify MBDSS systems for SSN removal. This estimate is about 9.6 percent of the total estimated effort for modifying the 29 systems from which we chose examples. Databases, key systems operations, and use(s) of the HICN: MBDSS's key databases include the Medicare Beneficiary Database (MBD) and the Common Medicare Environment.[B] MBD is a DB2 database[C] and includes data such as controls for security and user access to the systems' capabilities. The Common Medicare Environment is a DB2 database for which MBDSS updates specific database tables. The MBDSS Graphical User Interface (GUI) enables users, including Medicare workers who provide assistance such as answering beneficiary inquiries, to access and update MBDSS information. In addition, MBDSS includes about 39 interfaces that use files to exchange information with MBDSS users; 36 of these interfaces include the HICN. Information exchanged via the interfaces, which includes entitlement data provided to participating states and territories, beneficiary data provided to the true-out-of-pocket facilitator,[D] and data on beneficiaries who voluntarily disenroll from a Part D plan, is used to create a report on the quality of health plans based on voluntary disenrollment rates. System technical description: operating system(s), programming language(s), and lines of code: * MBDSS consists of a mainframe environment that includes the databases and a mid-tier environment that includes the GUI; * Operating systems: IBM's z/OS; the MBD GUI uses the z/Linux operating system; * Programming languages and tools: COBOL; * Estimated lines of code: 1,003,199. Examples of potential changes for implementing non-SSN-based identifier: * MBDSS includes approximately 39 interface files that provide beneficiary information to MBDSS users, including all state Medicaid agencies (50 states plus U.S. territories), more than 500 Part D plans, the database used to support 1-800-Medicare, the facilitator for True-out-of-pocket Expenses Part D transactions, the Coordination of Benefits Contractor, and the Retiree Drug Subsidy System. Of the 39 interface files, 36 include the HICN, and, depending on the interface partner's use, would need one or both of the following modifications to the file they receive: - Add the MBI to the end of the file to provide it to MBDSS users; - During the transition period, when both the HICN and the MBI may be needed, modify the files to include both identifiers. At the end of the transition period, when the HICN will no longer be transmitted to MBDSS users, add blanks to files in the space that previously stored the HICN; * In addition to modifying the file layout of the 36 files that include the HICN, CMS would need to coordinate changes to the files with each MBDSS user so that the users would be prepared to accept beneficiary information in the new format that includes the MBI. For example, CMS would need to coordinate the change with the more than 500 Part D plan providers and all states and territories; * During the transition period when beneficiary information could be submitted with either the HICN or the MBI, MBDSS would use a control module to keep track of whether beneficiary information was submitted with the HICN or the MBI, so that it could send information back to the user with the same identifier that the user submitted. After the 6- month transition period, the control module would be changed to not accept a request made with the HICN; * The beneficiary matching criteria for both batch processing and the user interface would need to be modified; * MBDSS would need to translate the MBI to the HICN, so that it could continue to use the existing software to process beneficiary information using the HICN. To accomplish this, MBDSS would need to use the crosswalk service to translate the MBI to the HICN. MBDSS would also need to translate the HICN to the MBI and would use a direct lookup table for this translation; * MBDSS user interface screens would be modified to allow users to search for beneficiaries using the MBI; * The MBD database would be modified to add the MBI to some tables in order to improve the performance of business functions that require faster translation or lookup than the crosswalk service could provide; * MBDSS would be modified to notify interface systems in the event that a new MBI is generated for a beneficiary, and, depending on the interface, would be modified to send the new MBI either using a notification of a change to the systems that can read from the Common Medicare Environment database or through a data file; * MBDSS system documentation would be modified to show changes to capabilities that previously used the HICN and would now need the MBI; for example, changes would be shown to input screens that previously used the HICN. Source: GAO analysis of data provided by CMS. [A] The True-out-of-pocket Part D Transaction Facilitator system was established in order to accurately track and calculate Medicare beneficiaries' true-out-of-pocket expenditures. The system provides beneficiary data to pharmacies and plans in order to determine if the beneficiary is eligible to receive the benefit and what, if any, other coverage he or she has. [B] The Common Medicare Environment is an enterprisewide database that provides information to several systems, including MBDSS, the Medicare Advantage and Prescription Drug (MARx) System, and the Enrollment Database, each of which is responsible for updating and retrieving information it owns. Common Medicare Environment is a DB2 database, and it includes approximately 350 tables that store data for the systems that access and update CMS. [C] DB2 is a relational database management system developed by IBM that serves a number of different operating systems platforms. [D] The true-out-of-pocket facilitator is responsible for establishing procedures for facilitating eligibility queries at the point of service, identifying costs that are being reimbursed by other payers, and for alerting Part D plans about such transactions. MBDSS transmits data regarding Part D plan coverage and eligibility, including the HICN, to the true-out-of-pocket facilitator. [End of table] [End of section] Appendix III: Comments from the Department of Health & Human Services: Department of Health & Human Services: Office of The Secretary: Assistant Secretary for Legislation: Washington, DC 20201: August 23, 2013: Valerie C. Melvin, Director: Information Management and Technology Resources Issues: U.S. Government Accountability Office: 441 G Street NW: Washington, DC 20548: Dear Ms. Melvin: Attached are comments on the U.S. Government Accountability Office's (GAO) report entitled, "Medicare Information Technology: Centers for Medicare and Medicaid Services Needs to Pursue a Solution for Removing Social Security Numbers from Cards" (GAO-13-761). The Department appreciates the opportunity to review this report prior to publication. Sincerely, Signed by: Jim R. Esquea: Assistant Secretary for Legislation: Attachment: General Comments Of The Department Of Health And Human Services (HHS) On The Government Accountability Office's (GAO) Draft Report Entitled, "Centers For Medicare And Medicaid Services Needs To Pursue A Solution For Removing Social Security Numbers From Cards," (GAO-13-761): The Department appreciates the opportunity to review and comment on this draft report. GAO Recommendation: GAO recommends that CMS Administrator take the following action: * Direct the initiation of an IT project for identifying, developing and implementing changes that would have to be made to CMS's affected systems, including designating a business owner and establishing a business case, issuing a project charter, and conducting project selection and architectural reviews of proposed approaches for the removal of SSNs from Medicare beneficiary cards. HHS Response: While we agree that removing the SSN from the Medicare card is an appropriate step to reducing the risk of identity theft, CMS cannot make a decision to proceed unilaterally. CMS, Social Security Administration and the Railroad Retirement Board must all agree to proceed with the initiative, considering existing workloads and priorities. Moreover, a clear source of funding for both IT and non-IT costs must be identified before proceeding. As GAO points out, the IT cost of the initiative comprises only 10 to 20 percent of the total cost. HHS concurs with GAO's recommendations for this finding assuming these constraints can be addressed. GAO Recommendation: GAO recommends that CMS Administration take the following action: * Incorporate such a project into plans for ongoing enterprise-wide IT modernization initiatives. HHS Response: HHS concurs with the GAO recommendation once the constraints described above have been addressed. Additionally, CMS would like to clarify a finding made by the GAO that was stated in both the highlights and on page 24 of the draft that, "CMS may have missed opportunities to leverage enterprise shared services to remove the SSN from the Medicare card." While we have not specifically built the shared services with the intent to utilize them for the purpose of removing the SSN from Medicare cards, the general functionality exists in the shared services to do so, and in fact our 2013 cost estimate did assume that shared services could be utilized. [End of section] Appendix IV: GAO Contact and Staff Acknowledgments: GAO Contact: Valerie C. Melvin at (202) 512-6304 or melvinv@gao.gov: Staff Acknowledgments: In addition to the contact named above, Teresa F. Tucker (Assistant Director), Wilfred B. Holloway, Lee A. McCracken, Thomas E. Murphy, Maria Stattel, Daniel K. Wexler, Merry L. Woo, and Charles E. Youman made significant contributions to this report. [End of section] Footnotes: [1] Medicare beneficiaries may also enroll in Part C, or Medicare Advantage, which pays private health plans to provide generally the same services covered by Parts A and B. Further, all Medicare beneficiaries may purchase coverage for outpatient prescription drugs under Part D, and some Medicare Advantage plans also include Part D coverage. [2] CMS's contractors that process fee-for-service claims are referred to a Medicare Administration Contractors. [3] Providers of health care under Part C and prescriptions under Part D do not file claims for payment. Rather, CMS pays private plans a monthly amount per beneficiary to provide health care services for each beneficiary enrolled in these plans. Instead of setting prices administratively, Medicare's payment to each Part C plan is determined by the plan's bid--its projected revenue requirements for providing standard Medicare services to an average enrollee--and a benchmark-- the maximum amount Medicare will pay in each county within the plan's service area. Medicare's payments to Part D plans are determined through a competitive process. [4] The Patient Protection and Affordable Care Act (Affordable Care Act) directed CMS to develop a plan to modernize its computer and data systems. Pub. L. No. 111-148, § 10330, 124 Stat. 119, 965 (2010), as amended by the Health Care and Education Reconciliation Act of 2010, Pub. L. No. 111-152, 124 Stat. 1029. [5] See Government Performance and Results Act of 1993, Pub. L. No. 103-62, 107 Stat. 285 (1993), as amended by the GPRA Modernization Act of 2010, Pub. L. No. 111-352, 124 Stat. 3866 (2011); Office of Management and Budget, Management of Federal Information Resources, Circular A-130 (Washington, D.C.: Nov. 28, 2000), and Planning, Budgeting, Acquisition, and Management of Capital Assets, Circular A- 11, Part 7 (Washington, D.C.: July 2003). [6] Pub. L. No. 103-322, § 300001, 108 Stat. 1796 (1994) (codified at 18 U.S.C. §§ 2721-2725). [7] Pub. L. No. 104-191, Title II, Subtitle F, 110 Stat. 1936, 2021 (codified at 42 U.S.C. §§ 1320d-1320d-8). HIPAA, among other things, required the adoption of data interchange standards to enable electronic exchange. [8] The numbers on the VA cards are identification numbers that allow beneficiaries to access facilities; the cards are not insurance cards. DOD's cards are also used primarily for identification purposes, and are not insurance cards. [9] Cards are used by active duty military personnel and their dependents to access health care services. [10] This code is used by SSA to determine the type of beneficiary. For example, an A suffix indicates the card holder is a retired or disabled worker (primary claimant). The B or B1 suffix indicates a wife or husband, respectively, of the retired wage earner. The C suffix indicates a child of a retiree, or a disabled child or student. The D suffix indicates a widow and an E suffix signifies a widowed mother. The SSN on the card is usually the cardholder's own; however, about 14 percent of the cards contain the SSN of the family member whose work history provides eligibility for services and treatment under Medicare. [11] In addition, CMS uses the number and associated claims information for internal purposes, such as for analyzing Medicare program performance and conducting program integrity efforts. [12] The shared systems are the Fiscal Intermediary Shared System, which processes part A claims; the Multi-carrier system, which processes part B claims; and the ViPS Medicare System, which is used to process claims for durable medical equipment. [13] Railroad retirees usually become eligible for Medicare at age 65. At that point, the Railroad Retirement Board assumes administrative responsibilities for railroad retirees' Medicare Parts A and B benefits. [14] The following reports documented evaluations of CMS's information technology and included recommendations that CMS modernize its information technology environment: the President's Council of Advisors on Science and Technology, Report to the President Realizing the Full Potential of Health Information Technology to Improve Healthcare For Americans: The Path Forward (December 2010), and the National Academy of Sciences, Strategies and Priorities for Information Technology at the Centers for Medicare and Medicaid Services (2011). [15] Use of shared services can be cost efficient because when a service is reused by multiple IT systems, initial system development costs occur once, and these costs can be avoided each time the service is reused. In addition, use of shared services promotes standardization and interoperation of data and can reduce stove piping. [16] Department of Health and Human Services Office of the Inspector General, CMS Responses to Breaches and Medical Identity Theft, OEI-02- 10-00040 (Rockville, Md.: October 2012), and Social Security Administration Office of the Inspector General, Removing Social Security Numbers from Medicare Cards, A-08-08-18026 (Baltimore, Md.: May 2008). [17] GAO, Social Security Numbers: Governments Could Do More to Reduce Display in Public Records and on Identity Cards, [hyperlink, http://www.gao.gov/products/GAO-05-59] (Washington, D.C.: Nov. 9, 2004). [18] GAO, Social Security Numbers: Stronger Protections Needed When Contractors Have Access to SSNs, [hyperlink, http://www.gao.gov/products/GAO-06-238] (Washington, D.C.: Jan. 23, 2006). [19] GAO, Social Security Numbers: More Could Be Done to Protect SSNs, [hyperlink, http://www.gao.gov/products/GAO-06-586T] (Washington, D.C., Mar. 30, 2006). [20] GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate for Removing Social Security Numbers from Medicare Cards, [hyperlink, http://www.gao.gov/products/GAO-12-831] (Washington, D.C.: Aug. 1, 2012). [21] CMS, Removal of Social Security Number from the Medicare Health Insurance Card and Other Medicare Correspondence (Baltimore, Md.: October 2006), and Update on the Assessment of the Removal of Social Security Numbers from Medicare Cards (Baltimore, Md.: November 2011). [22] [hyperlink, http://www.gao.gov/products/GAO-12-831]. [23] The remainder of the estimated cost was associated with business processes, such as printing and mailing new cards and training personnel to use a new number, which would be completed in October 2015. [24] Centers for Medicare and Medicaid Services, CMS Expedited Life Cycle Process: Detailed Description, Version 2.11 (Baltimore, Md.: November 2012). CMS's XLC framework was developed in accordance with departmental guidance, the Department of Health and Human Services, Enterprise Performance Life Cycle Framework (Washington, D.C.: September 2011). [25] GAO's guidance for estimating costs includes determining technical requirements associated with implementing business projects, such as modifications to IT systems and purchase of additional computer hardware. [26] Agency officials stated that they referred to the list of systems that was developed to meet Federal Information Security Management Act, or FISMA, requirements. [27] Of the 72 systems potentially affected by the first approach, CMS officials identified 20 that accounted for 86 percent of the total estimated cost of effort. Likewise, of the 41 affected by the second approach, 20 systems accounted for 95 percent. [28] While CMS provides cards for beneficiaries when they enroll in Medicare, SSA is responsible for processing beneficiaries' requests for replacements. However, the Railroad Retirement Board issues cards both at enrollment and when beneficiaries request replacements when, for example, they are lost. [29] The states' systems use the HICN to identify beneficiaries about whom data are being shared, to share data about those beneficiaries, and to coordinate health care delivery and payment. Therefore, the introduction of a new identifier to replace the SSN-based HICN would require modifications to the IT systems that are used to support these practices. [30] Buy-in occurs when state Medicaid programs pay for their beneficiaries' Medicare premiums. [31] GAO, Federal Chief Information Officers: Opportunities Exist to Improve Role in Information Technology Management, [hyperlink, http://www.gao.gov/products/GAO-11-634] (Washington, D.C.: Sept. 15, 2011). [32] GAO, 2013 Annual Report: Actions Needed to Reduce Fragmentation, Overlap, and Duplication and Achieve Other Financial Benefits, [hyperlink, http://www.gao.gov/products/GAO-13-279SP] (Washington, D.C.: Apr. 9, 2013); Information Technology: OMB and Agencies Need to Focus Continued Attention on Eliminating Duplicative Investments, [hyperlink, http://www.gao.gov/products/GAO-13-685T] (Washington, D.C.: June 11, 2013); Information Technology: FDA Needs to Establish Key Plans and Processes for Guiding Systems Modernization Efforts, [hyperlink, http://www.gao.gov/products/GAO-09-523] (Washington, D.C.: June 2009); and ADP Modernization: Half-Billion Dollar FmHA Effort Lacks Adequate Planning and Oversight, [hyperlink, http://www.gao.gov/products/GAO/IMTEC-92-9] (Washington, D.C: October 1991). [33] One of the 20 systems is the crosswalk service itself. [34] CMS, Removal of Social Security Number from the Medicare Health Insurance Card and Other Medicare Correspondence (Baltimore, Md.: October 2006); Update on the Assessment of the Removal of Social Security Numbers from Medicare Cards (Baltimore, Md.: November 2011); and SSN Removal from Medicare Card: Cost Analysis Summary (Baltimore, Md.: May 2013). [35] Centers for Medicare and Medicaid Services, CMS Expedited Life Cycle Process: Detailed Description, Version 2.11 (Baltimore, Md.: November 2012). [36] GAO, Medicare: CMS Needs an Approach and a Reliable Cost Estimate for Removing Social Security Numbers from Medicare Cards, [hyperlink, http://www.gao.gov/products/GAO-12-831] (Washington, D.C.: Aug. 1, 2012). [37] CMS, SSN Removal from Medicare Card: Cost Analysis Summary (Baltimore, Md.: May 2013). [38] One state did not provide an estimate to CMS. [39] See Government Performance and Results Act of 1993, Pub. L. No. 103-62, 107 Stat. 285 (1993), as amended by the GPRA Modernization Act of 2010, Pub. L. No. 111-352, 124 Stat. 3866 (2011); Office of Management and Budget, Management of Federal Information Resources, Circular A-130 (Washington, D.C.: Nov. 28, 2000), and Planning, Budgeting, Acquisition, and Management of Capital Assets, Circular A- 11, Part 7 (Washington, D.C.: July 2003). [End of section] GAO’s Mission: The Government Accountability Office, the audit, evaluation, and investigative arm of Congress, exists to support Congress in meeting its constitutional responsibilities and to help improve the performance and accountability of the federal government for the American people. GAO examines the use of public funds; evaluates federal programs and policies; and provides analyses, recommendations, and other assistance to help Congress make informed oversight, policy, and funding decisions. GAO’s commitment to good government is reflected in its core values of accountability, integrity, and reliability. Obtaining Copies of GAO Reports and Testimony: The fastest and easiest way to obtain copies of GAO documents at no cost is through GAO’s website [hyperlink, http://www.gao.gov]. Each weekday afternoon, GAO posts on its website newly released reports, testimony, and correspondence. To have GAO e-mail you a list of newly posted products, go to [hyperlink, http://www.gao.gov] and select “E-mail Updates.” Order by Phone: The price of each GAO publication reflects GAO’s actual cost of production and distribution and depends on the number of pages in the publication and whether the publication is printed in color or black and white. Pricing and ordering information is posted on GAO’s website, [hyperlink, http://www.gao.gov/ordering.htm]. Place orders by calling (202) 512-6000, toll free (866) 801-7077, or TDD (202) 512-2537. Orders may be paid for using American Express, Discover Card, MasterCard, Visa, check, or money order. Call for additional information. Connect with GAO: Connect with GAO on facebook, flickr, twitter, and YouTube. Subscribe to our RSS Feeds or E mail Updates. Listen to our Podcasts. Visit GAO on the web at [hyperlink, http://www.gao.gov]. To Report Fraud, Waste, and Abuse in Federal Programs: Contact: Website: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]; E-mail: fraudnet@gao.gov; Automated answering system: (800) 424-5454 or (202) 512-7470. Congressional Relations: Katherine Siggerud, Managing Director, siggerudk@gao.gov: (202) 512-4400: U.S. Government Accountability Office: 441 G Street NW, Room 7125: Washington, DC 20548. Public Affairs: Chuck Young, Managing Director, youngc1@gao.gov: (202) 512-4800: U.S. Government Accountability Office: 441 G Street NW, Room 7149: Washington, DC 20548. [End of document]