The ICD-9 code set was adopted in the United States in 1979 as the standard for documenting morbidity and mortality information for statistical purposes. It was expanded and adopted in 2000 under HIPAA as the standard code set for use in all electronic transactions by covered entities. Specifically, ICD-9 codes are currently used in all U.S. health care settings to document diagnoses and are also used in all U.S. inpatient hospital settings to document procedures. ICD codes are used in a variety of ways by Medicare. For example, Medicare uses the codes to help determine hospital inpatient payment rates based on the Medicare-Severity Diagnosis-Related Groups system, which classifies inpatient stays according to both patients’ diagnoses and the procedures a patient receives. Further, CMS uses the diagnosis codes to determine whether the care provided by physicians is medically necessary and, therefore, eligible for reimbursement. The transition to ICD-10 is intended to increase the number of codes and, thus, improve providers’ ability to designate the level of specificity when documenting diagnoses and procedures. Specifically, ICD-9 codes are made up of three to five alphanumeric values, while ICD-10 codes are made up of three to seven values, allowing for more codes and increased specificity. While there are approximately 15,000 ICD-9 diagnosis codes, there are approximately 70,000 ICD-10 diagnosis codes. Likewise, there are approximately 4,000 ICD-9 procedure codes, while there are approximately 72,000 ICD-10 procedure codes. The additional codes were defined by the Centers for Disease Control and Prevention and CMS to enable providers and payers to capture greater specificity and clinical information in medical claims. For example, using ICD-10 codes, a provider will be able to identify a body part and the side of the body subject to an evaluation or procedure; however, the ICD-9 codes do not allow this level of differentiation between the left and right sides of the body. As another example, there is only one ICD-9 code that a provider would enter on a claim for angioplasty (a procedure to restore blood flow through an artery), but there are 854 ICD-10 codes for angioplasty, with these codes including additional details on the affected body parts and the approaches and devices used for the procedure. (Within these 854 codes there will be higher-level generic codes available for entry if a lower level of detail is not needed. Therefore, a provider may not need to know or use all the 854 codes for angioplasty.) Another difference between the ninth and tenth versions of the codes is the terminology and disease classifications, which are to be updated so that they are consistent with new technology and current clinical practice. For example, under ICD-9, when filing Medicare claims, providers use a single code to reflect tobacco use or dependence, while, under ICD-10, they will be able to use a code that indicates a category for nicotine dependence with subcategories to identify the specific tobacco product and nicotine-induced disorder. In this example, the updated disease classifications for nicotine disorders reflect the increased knowledge of the effects of nicotine. Other differences between the code sets include the addition of new concepts that do not exist in ICD-9 diagnosis codes, such as the expansion of postoperative codes to distinguish between intraoperative and post-procedural complications, and the designation of trimester for pregnancy codes. HHS issued a final rule on January 16, 2009, that mandated the use of ICD-10 codes by all HIPAA-covered entities by October 1, 2013; hence, the transition from version 9 to version 10 of the codes was initially to take effect approximately 2 years ago. However, on September 5, 2012, the department issued a final rule that delayed the effective date until October 1, 2014. The Secretary of HHS made this decision because, among other reasons, results of industry surveys and polls had indicated that HIPAA- covered entities throughout the country were not prepared to successfully complete the transition. Subsequently, the Protecting Access to Medicare Act of 2014, enacted April 1, 2014, mandated an additional delay by prohibiting HHS from requiring the use of ICD-10 codes sooner than October 1, 2015. On August 4, 2014, the department issued a final rule that established October 1, 2015, as the new compliance date. Accordingly, on October 1, 2015, all health care transactions that include ICD codes must begin using the tenth version of the codes for services that occur on or after that date. (Transactions with dates of service that occur prior to the transition date of October 1, 2015, must continue to be documented with ICD-9 codes.). Figure 1 illustrates the sequence of events leading to the current compliance date. Medicare fee-for-service claims that include ICD codes are submitted, processed, and authorized for payment through a combination of stakeholders’ systems and CMS’s internal claims processing systems. For example, health care providers use systems within their practices to complete and submit claims for payment of services covered under the Medicare fee-for-service program, and the Medicare Administrative Contractors (MAC), who administer the processing of the claims, use their own and CMS’s internal systems to complete processing of the claims for approval and authorization of payment. Additionally, other health care insurers receive claims data from CMS that may include ICD codes when payments of health care benefits are shared between these insurers and Medicare. These insurers’ systems must be able to accept and process the data sent by CMS, including the ICD codes. Therefore, all these types of systems would need to be modified by Medicare stakeholders in order to function properly in an electronic claims processing environment when the transition from ICD-9 to ICD-10 is made. Stakeholders in CMS’s electronic Medicare claims processing environment include providers, health care clearinghouses, and private health care insurers, all of which use their own systems to exchange claims data that include ICD codes with CMS’s internal systems. For example, health care providers use systems within their practices to complete claims for payment of services delivered to their patients, including beneficiaries of the Medicare fee-for-service program. Once the data for a patient visit have been entered into a provider’s system, the claim is electronically submitted for processing and payment authorization, either directly from the provider’s systems or through a health care clearinghouse—an organization that converts nonstandard data elements of health information into standard data elements so that they can be transmitted to and used within other claims processing systems. The claims data are transmitted from the provider’s (or clearinghouse’s) system to a MAC—one of the contractors whose services CMS uses to administer the claims processing requirements of the program. Each MAC uses one of two standard software modules to accept electronic claims for processing. These systems, referred to as “front-end” systems, are used to first determine whether the data submitted are valid. There are two front-end validation systems—one for the Part A/B institutional, physician and non-physician practitioner claims, and one for durable medical equipment, prosthetics, and orthotics claims. When validating ICD codes, the front-end systems are designed to check to ensure that the codes and related data are properly entered on the claim. Specifically, in order to be accepted by the MACs’ systems, the claim must include a diagnosis indicator that specifies whether the ICD-9 or ICD-10 code set is being used, one or more dates of service, and ICD codes. These ICD-related data must be consistent in order to pass through the front-end systems and on to the MACs’ systems. For example, a claim with an ICD-10 diagnosis indicator; a September 30, 2014, date of service; and an ICD-10 code entered into a data field that is 7 values in length should be rejected by the front-end data validation routines because the date of service (September 30, 2014) is earlier than the ICD- 10 compliance date (October 1, 2015). Instead, the claims data would require an ICD-9 indicator and code. Therefore, it would not be transmitted from the front-end validation system for further processing by the MAC; rather, it would be rejected and sent back to the submitting provider (via the MAC’s system) for correction. Thus, these front-end data validation systems would require modifications in order to accept and process the expanded 7-value ICD-10 code field in addition to the 5-value ICD-9 code field. The systems would also need to be modified to ensure that they can determine that the version of the codes used is consistent with the date service was delivered—for version 9, a date of service prior to October 1, 2015, and for version 10, a date of service on or after October 1, 2015. After claims pass the front-end validation routines, each MAC uses its own systems to receive electronic Medicare claims data that would include ICD codes from providers (or clearinghouses). For example, the MACs use systems such as claims imaging software, interactive voice response systems, provider portals, and workflow management systems to accept providers’ data. A MAC then uses its systems to transmit the claims data to CMS’s systems that are used to determine whether to approve and authorize payment of the claims. Each of the systems used by a MAC to accept, process, and transmit claims data would require modifications in order to process ICD-10 rather than ICD-9 codes. While private insurers do not submit health care claims data to CMS, they nonetheless also use systems that would need to be changed to process ICD-10 codes that are included with other claims data sent to them by CMS. Specifically, in cases when a beneficiary is covered by both Medicare and another payer, such as a supplemental Medigap insurer or a primary payer other than Medicare, the other payer (insurer) could receive claims data, including ICD codes, from CMS if it was responsible for paying all or a portion of a claim. In such cases, the other payers’ systems that receive the claims data from CMS would have to be modified to accept ICD-10 rather than ICD-9 codes. The Medicare claims data that are transmitted to CMS by the MACs are to be further processed by four internal systems operating within CMS’s Virtual Data Center. These systems are developed and maintained by four information services contractors. The systems are the Fiscal Intermediary Shared System (FISS)—the Medicare Part A and Part B claims processing system used to process claims related to medical care provided by institutional providers, such as hospital inpatient and outpatient departments, skilled nursing facilities, and hospices; Multi-Carrier System (MCS) —the Medicare Part B claims processing system used to process claims related to physician and non-physician practitioners, laboratories, therapy, independent diagnostic testing facilities, and ambulance claims; ViPS Medicare System (VMS)—used by the Durable Medical Equipment contractors to process claims for medical equipment, such as wheelchairs and walkers, and for prosthetics, orthotics, and medical supplies; and Common Working File—provides a single data source where the contractors can verify beneficiary eligibility, compare claims history for a beneficiary across the shared systems, and receive prepayment review and approval of claims. FISS, MCS, and VMS are referred to as “shared systems.” The information services contractors who maintain them are called “shared systems maintainers”. Collectively, these four systems are used by the MACs to support their review of claims prior to payment and ensure that payments are made to legitimate providers for reasonable and medically necessary services covered by Medicare for eligible individuals. When CMS’s FISS, MCS, and VMS shared systems receive the properly formatted claims data from a MAC’s system, additional processing is conducted to determine whether the data, including ICD codes, meet requirements of CMS’s payment policies before the claims can be approved for payment. If the systems determine that the data do not meet the requirements, the claim is denied and sent back via the MAC’s system to the provider for corrections. For example, the shared systems execute automated prepayment controls called “edits,” which are instructions programmed into the system software to identify errors in individual claims and prevent payment of incomplete or incorrect claims. These prepayment edits may rely on an analysis of ICD codes to identify claims for services unlikely to be provided in the normal course of medical care and services for diagnoses that are anatomically impossible. For example, the analysis conducted by a prepayment edit may identify two ICD-10 codes on a claim that indicate a patient was diagnosed with two broken right femurs, when there is only one femur on a person’s right side. As a result, payment of the claim would be denied because the ICD codes used indicate a diagnosis that is anatomically impossible. However, an ICD-10 code that indicates a broken right femur and another that indicates a broken left femur would be accepted because it is anatomically possible for a person to break both femurs. On the other hand, ICD-9 codes entered on the claim for two broken femurs would not indicate that the right and left femurs were both broken, so the analysis conducted by the same prepayment edit would likely identify the ICD coding to be duplicative and, consequently, deny payment of the claim. As such, the software that processes such edits would need to be modified to conduct the analysis based on ICD-10 values rather than ICD- 9 since, as noted in the example, the logical analysis performed would be different for each. Once a claim has been completely processed by the appropriate shared system, its data are transmitted to the Common Working File, which conducts additional processing to determine whether the claim’s beneficiary is eligible for the service for which the claim was filed, compares the claims to other claims filed for that beneficiary across the shared systems, and determines whether payment for the claim should be authorized. This system sends payment authorization and beneficiary information, including ICD codes, back to the shared systems, where they are then processed for payment by the MACs. It also stores beneficiary data that include the ICD codes for use by other CMS systems, such as the systems that store claims data to be used when coordinating benefits between Medicare and private insurers. An overview of CMS’s and stakeholders’ Medicare fee-for-service claims processing and the related systems that utilize ICD-10 codes is illustrated in figure 2. Within CMS, business owners in the policy and business groups (such as the Center for Medicare, Center for Program Integrity, Center for Financial Management, etc.) are responsible for defining requirements to be supported by the agency’s internal systems, including the systems that process fee-for-service claims. Business owners also are responsible for overseeing maintenance of the internal systems, which are operated at CMS’s Virtual Data Center. Within the agency the Center for Medicare and the Office of Technology Solutions are responsible for following the systems development and change management processes for updating the shared systems, including changes needed to support the transition to ICD-10 on October 1, 2015. Specifically, among other responsibilities, the Office of Technology Solutions provides day-to-day oversight of the contractors that perform ongoing systems maintenance and support for Medicare fee-for-service claims processing. The Office of Enterprise Information leads the coordination, development, implementation, and maintenance of the HIPAA electronic data interchange information standards in the health care industry, such as the transition of the ICD standard from revision 9 to revision 10. The Office of Enterprise Information is the agency lead for ICD-10 implementation. CMS’s processes require its internal claims processing systems (the shared systems and Common Working File) to be updated quarterly in order to remain current with ongoing changes in health care procedures, technologies, and policies. Medicare program changes made to comply with the electronic data interchange standards used by the health care industry to conduct electronic transactions (such as Medicare claims processing and other transactions defined by HIPAA rules) are a major driver of system update requirements. Thus, the system changes needed to support the transition from ICD-9 to ICD-10 are to be implemented through the agency’s quarterly updates. To complete its quarterly system updates, CMS is to follow an established agency-wide software development life cycle process, which defines a change management process for identifying and implementing any changes that need to be made to provide functionality within existing operational systems (and that do not require development of new systems). The need to make changes to the systems is determined when a business requirement is identified based on new legislation or other business requirements, such as the transition to the tenth revision of ICD codes required by HHS. To begin the process for implementing the system changes, CMS officials within policy and business groups who are affected by new business requirements are to write change requests. A change request is a formal instruction that defines specifications for making modifications to a system or systems, along with updates to the corresponding technical documentation. The change request is to be presented to the shared systems and Common Working File maintainers, as well as the MACs, who are to analyze the business requirements and translate them into system requirements. The maintainers and MACs are to then analyze the system requirements to determine the scope and effort of the changes that would need to be made to the systems. The change requests are then grouped into a release “baseline,” which is presented to CMS’s Medicare Change Control Board. This board, which is made up of representatives from the policy and business groups that are responsible for the Medicare fee-for-service program, is to then review and approve the change requests to be implemented in the next release. If the release baseline and work to implement changes are approved by the board, the change requests are submitted to the systems maintainers and the MACs who are to follow the agency’s software development life cycle processes and program the systems to implement the functionality needed to meet the new business requirements, such as requirements for processing ICD-10 codes. Any quarterly release may address many change requests for various business requirements. In this regard, the quarterly releases that implement changes to support the ICD-10 business requirements would also include changes to address other business requirements or modifications needed to correct errors in CMS’s claims processing systems. Once the system changes have been made, the contractors are to conduct three levels of testing prior to releasing the updated systems into production. CMS’s Office of Technology Solutions is to oversee the first two levels, and the Center for Medicare is to oversee the third level of testing. The first level of testing—alpha testing—is internal testing of the individual systems conducted by the shared systems maintainers. During this level of testing, the maintainers are to conduct test cases to validate that each change request has been addressed and that appropriate changes have been made within the CMS system they maintain. The second level of testing—beta testing—is to be conducted by CMS’s single testing contractor to ensure that all the shared systems work together as expected in CMS’s claims processing environment. The third level—user acceptance testing—is to be conducted by the MACs to test the integration of their claims submission systems with CMS’s shared systems. This level of testing is supposed to simulate a live production environment in which claims are submitted by providers (or clearinghouses) via the MACs, adjudicated by CMS, and approved or denied for payment. Completion of each of the lower levels of testing is important to ensure that system errors are detected and addressed as soon as possible within a release cycle. User acceptance testing is intended to identify errors that may occur when the stakeholders’ and CMS’s systems are integrated to simulate claims processing from the point when they are completed and submitted by the providers’ systems, through adjudication and payment authorization by CMS’s internal systems. At this level of testing, the MACs are to conduct test cases that simulate a live environment and validate that the interconnections and interfaces between the stakeholders’ and CMS’s systems function properly. Outcomes of this type of testing can also identify errors that were not detected during lower levels of testing, and any additional changes that were not identified earlier in the change management process but are needed to fully address business requirements. The shared systems and Common Working File maintainers and single testing contractor participate in the user acceptance testing to correct any errors that may not have been detected during the first two levels (alpha and beta testing), and to implement any additional system changes needed to address business requirements. Further, the MACs are to conduct testing to ensure that any system changes implemented for a quarterly software update do not adversely affect the ongoing operations of the system or introduce any new system errors. This type of testing is referred to as “regression” testing and is needed to re-test changes made in previous releases of software, such as changes made to process ICD code revisions, during testing of subsequent releases. Therefore, user acceptance testing is intended to provide a comprehensive validation of the readiness of systems to be released into production. Once all the MACs that were affected by the system changes have completed user acceptance testing, the Office of Technology Solutions is to hold a management-level review to determine whether all the systems that had been changed since the last quarterly release are ready to be moved into the live production systems environment. Along with officials from the office’s Business Application Management Group, Division of Shared Systems, Development, Testing, and Operations, the shared systems maintainers and MACs participate in the reviews. An overview of CMS’s quarterly release change management process that was to be applied to the implementation of ICD-10 system changes is depicted in figure 3. Anticipating the transition from ICD-9 to ICD-10 by October 2013, CMS’s Office of E-Health Standards and Services began to plan for the transition in 2007 by identifying systems that needed to be modified in order to process the new codes. The office, in conjunction with the American Health Information Management Association, initiated an assessment in September 2007 of the business processes, systems, and operations under CMS’s direct responsibility that could be impacted by a transition to the ICD-10 code set. The systems identified by the assessment were the three shared systems and the Common Working File that are used to process Medicare fee-for-service claims. As previously mentioned, we reported in January 2015 the results from a related study of CMS’s efforts to help entities affected by changes to ICD codes better prepare for the October 1, 2015, transition. In that report, we described steps that CMS had taken, such as providing educational materials; conducting stakeholder outreach; and monitoring readiness through stakeholder collaboration meetings, focus group testing, and reviews of surveys conducted by the health care industry. We also noted that CMS had documented that the agency had completed all ICD-10-related changes to its Medicare fee-for-service claims processing systems. However, we described several areas of concern identified by stakeholders regarding the ICD-10 systems transition. For example, stakeholders had expressed concerns that CMS’s testing activities had not been comprehensive. We noted that, in response, CMS officials had scheduled end-to-end testing with 2,550 covered entities during 3 weeks in 2015 (in January, April, and July). Additionally, stakeholders had recommended that CMS do more to make its Medicare contingency plans public. We reported that the information in the agency’s contingency plans that are relevant to providers was made publicly available by CMS. We did not make recommendations to CMS in this report. CMS has finished implementing the Medicare claims processing system changes that it determined to be necessary for addressing the October 1, 2015, transition to ICD-10. Based on the agency’s change management documentation, officials responsible for overseeing the transition began taking steps to update the systems in March 2010 and had finished making the systems changes to address ICD-10 requirements in time to meet the initial October 2013 compliance date. In the approximately 2 years since then, the agency has continued to make modifications to systems functionality, as needed, to meet a legislated requirement to update the ICD code sets and to implement changes needed to address the two extensions of the ICD-10 compliance date. Beginning in January 2010 and ending in March 2013, CMS’s business groups submitted 37 change requests to the systems maintainers that required modifications to the shared systems and Common Working File software to meet the October 2013 compliance date. The change requests identified system modifications needed to implement software functionality related to the processing of ICD-10 codes rather than ICD-9 codes. Specifically, changes were needed to establish a structure for defining and maintaining the new codes themselves, which are to be stored in an internal table within CMS’s enterprise data processing environment. The table is to be referenced by the shared systems and Common Working File when processing ICD codes. CMS’s change management documentation reports that the systems contractors completed and CMS approved the implementation of the ICD-10 code table in July 2012. In addition to building the new table to maintain the codes, CMS’s contractors had to make changes to the two front-end validation systems to properly process the ICD-10 codes entered on claims. Toward this end, the agency implemented system changes to validate the ICD-10 codes in the two front-end systems in the July 2012 quarterly system release. Beyond these changes, other requests submitted by CMS’s business groups identified changes that needed to be made to implement functionality related to the utilization of ICD-10 codes by the pre-payment edits within the shared systems and the Common Working File. As previously noted, such edits are used within the systems to analyze claims data and determine whether a claim should be authorized for payment. According to technical documentation that described the systems that needed to be changed, about 200 prepayment edits were affected by the transition from ICD-9 to ICD-10 codes. Changes were made to the shared systems and Common Working File to update the edits in the 2012 and 2013 quarterly releases. CMS’s change management reports indicate that its contractors made changes to update the shared systems and Common Working File to process ICD-10 codes through the quarterly release process. The contractors began to make system changes in July 2010 and continued to make and implement changes the agency identified through 11 system releases until October 2013. The July 2010 quarterly release implemented one change to expand a file structure within FISS for ICD-10 codes. The July and October 2011 quarterly releases implemented five changes for VMS and MCS to address requirements such as the removal of obsolete processes and reports based on ICD-9 codes, identification and printing of ICD-10 indicators, and expansion of various files to accommodate ICD-10 codes. The January, April, July, and October 2012 quarterly releases implemented 19 changes for FISS, VMS, MCS, and the Common Working Files to address various file expansions and conversions, and changes to prepayment and Common Working File edits. The January, April, July, and October 2013 releases implemented 12 changes to FISS, VMS, MCS, and the Common Working File to modify screens and processes, update prepayment edits, and update effective dates for ICD-10. Subsequent to the October 2013 quarterly release, at which time CMS documented that all the changes had been implemented, the agency implemented 5 additional systems modifications related to the processing of ICD-10 codes. These modifications involved making software updates to the shared systems and Common Working File that were needed to address legislated requirements related to new technologies and diseases. Another change was made in October 2014 to address the latest year-long extension by updating the effective date-of-service value throughout the shared systems and Common Working File from October 1, 2104 to October 1, 2015. More detailed information regarding each quarterly system release that addressed ICD-10 change requests is provided in appendix II. According to officials with CMS’s Office of Technology Solutions, on October 1, 2015, the agency’s claims processing systems are expected to begin referencing the internal tables that store ICD-10 codes to validate, edit, and authorize payments to Medicare fee-for-service providers when claims data indicate a service date of October 1, 2015, or later. According to agency documentation, CMS followed processes and practices consistent with industry standards to make changes to and approve the implementation of systems that will be used for processing Medicare claims filed with ICD-10 codes. In addition, the agency identified contingency plans to be followed if its systems experience problems that disrupt the processing of Medicare claims that include the new codes when the systems change over to ICD-10 coding on October 1, 2015. Our body of work related to information systems testing has shown that testing an IT system is essential to validate that the system will satisfy the requirements for its intended use and user needs. Effective testing facilitates early detection and correction of software and system anomalies; provides an early assessment of software and system performance; and provides factual information to key stakeholders for determining the business risk of releasing the product in its current state. Industry standards developed by the Institute of Electrical and Electronics Engineers (IEEE) state that systems testing should be conducted early and often in the life cycle of a systems development project to allow for the modification of products in a timely manner, thereby reducing the overall project and schedule impacts. In addition, CMS’s established software change management processes require that the agency’s development and testing contractors begin testing early in the development process, and that they test often throughout a software development life cycle through three levels of testing—alpha, beta, and user acceptance tests. IEEE also defines practices to help organizations validate systems’ readiness for production. It also recommends planning for contingencies to help mitigate risks and minimize the impact of errors that may be introduced when new or modified systems are implemented into a live production environment. CMS’s change management process used to update its systems to accommodate ICD-10 codes established practices for testing of ICD-10 changes that began early in the software development life cycle for release of systems that would be affected, and continued throughout the quarterly release process. Such practices were established in accordance with IEEE’s recommendation that testing be conducted early and often in a software development process. Based on reports from the agency’s system maintainers, single testing contractor, and MACs, testing of all quarterly software releases was conducted prior to implementation, and included three levels of testing within about 5 months. The results of each level of testing were sent to CMS management for approval before the systems advanced to the next level. Additionally, within each of the 11 quarterly release cycles that implemented ICD-10 system changes, CMS’s Office of Technology Solutions and Center for Medicare oversaw and approved the three levels of testing conducted by the contractors to verify that all change requests had been addressed, the system changes had been implemented, and any system errors had been corrected. CMS’s shared systems and Common Working File maintainers (the CMS contractors who are responsible for developing and maintaining the Medicare claims processing systems) initiated the first level of software testing for ICD-10 changes for each release when they began to program the systems’ software to implement the needed changes. The first level of testing, or alpha testing, for each quarterly release was begun 3 to 5 months prior to implementation of the updated systems. For example, CMS officials and change management documentation for the October 2013 release stated that the first testing of the design and development of the changes made to each of the affected systems—the shared systems and Common Working File—began in May 2013 and was completed and approved in July 2013. Test cases and results for the alpha level define the specific criteria that were to be tested, such as the ICD-10 diagnosis and procedure codes; steps to be taken to verify that results of the test were as expected; the actual results of the test; and whether the test passed. Documented results of the testing indicated that any known errors related to system modifications that were made to address the ICD-10-related change requests had been corrected. After the first level of testing was completed and the results approved, the single testing contractor conducted a second level of testing, in which the systems maintainers participated. Testing was performed for the October 2013 systems release for all of the systems that would be affected—the shared systems and Common Working File—and was completed and approved in September 2013. Documented test results indicated that any detected errors related to the system changes made to support the ICD- 10 transition had been resolved. Specifically, reports on beta test results provided to CMS by the single testing contractor identified 23 errors detected when 84 test cases were conducted in early July 2013. The reports indicated that all the errors were corrected and re-tested by mid- July 2013, and that all test cases for the ICD-10 changes had passed beta testing for the release. Additionally, the final report identified one other ICD-10-related error that was reported to the system maintainers for correction. The report stated that the error was corrected in August 2013. Finally, a third level of testing—the comprehensive user acceptance testing—was conducted by the MACs, with continued involvement of the shared systems maintainers and single testing contractor, about one month prior to each quarterly release. Documented results of the MACs’ user acceptance test cases indicated that the MACs had verified that the system changes made to address ICD-10 change requests had been tested and any errors detected had been corrected by the systems maintainers. In conducting the user acceptance tests leading up to the October 2013 release, seven of the nine MACS identified system errors in test case results. The errors were related to the implementation of system changes that had been made to address two ICD-10 requests for changes needed to process certain prepayment edits. The MACs’ reports indicated that, in each of these cases, the errors were communicated to the system maintainers, who then corrected the errors in the appropriate systems (FISS and MCS) prior to the October 2013 release. The MACs’ user acceptance test results (for each of the shared systems and Common Working File) that were reported weekly to CMS throughout September 2013 identified system issues related to four change requests; however, none of the issues was related to ICD-10 changes. In accordance with IEEE standards and CMS’s change management processes for validating systems’ readiness for production, officials with the Office of Technology Solutions held quarterly release readiness reviews of CMS’s claims processing systems during which agency officials and their contractors considered whether the systems had been tested sufficiently to ensure that they were ready to process ICD-10. Minutes from the October 2013 reviews for each of the shared systems and the Common Working File indicated that results of testing supported CMS officials’ views that the systems were ready to process Medicare claims that include ICD-10 codes. Specifically, the minutes provided details regarding the status of the four ICD-10-related change requests that were to be implemented in the October 2013 quarterly release, including confirmation that each system had been tested and each of the changes had been implemented for the release. The minutes also indicated that the reviews were attended by representatives from all of the MACs, the system maintainers, the single testing contractor, CMS officials responsible for overseeing the implementation of the internal claims processing systems, and representatives of the business or policy groups that requested the system changes. Minutes from each of the shared systems’ release readiness reviews showed that the participating entities were in agreement that the systems were ready to process ICD- 10 codes and to be released into production in October 2013. CMS has established contingency plans to be executed in case errors occur as a result of implementing modifications to the existing claims processing systems, which is consistent with IEEE recommendations that organizations define actions to be taken to minimize the impact of system errors. In August 2014, CMS developed an ICD-10 “day-1” emergency plan, which defined actions that it intends to take in case errors occur when their systems begin processing ICD-10 codes. The plan defines procedures for daily calls between CMS’s Office of Technology Solutions, the MACs, and systems maintainers to identify any problems and discuss possible workarounds to minimize the impact that claims processing system errors may have on Medicare stakeholders. The calls are intended to continue until the agency determines that they are no longer needed. The plan has also established a process, including specific steps and guidelines for engaging an emergency response team, intended to address adverse events related to ICD-10 processing after the modified systems have been released into production. In addition, in February 2015, the agency finalized a systems-level contingency plan that defined corrective actions to be taken by the emergency response team in instances when internal systems may fail to accept and correctly process claims containing ICD-10 codes beginning on October 1, 2015. The plan describes scenarios that would call for action. For example, in describing a scenario in which CMS’s fee-for- service systems do not function as expected, the plan states that if the front-end validation routines fail to properly process correct ICD-10 codes, the team would temporarily disable the faulty routines until corrections could be made. For each claim that was improperly rejected because of the system error, CMS would then determine whether to re-submit the claim for processing by the shared systems. The plan describes other actions to be taken if the shared systems and Common Working File encounter errors in utilizing ICD-10 codes by prepayment edits. In such cases, the emergency response team would determine whether the errors could be fixed quickly, in which case systems would “hold” the claims until the errors were corrected and processing could be completed, or if additional actions would be required prior to the errors being corrected. Corrective actions are also described for another scenario that would occur if the ICD-10 compliance date were delayed until later than October 1, 2015. In this scenario, the contingency plan identifies the system changes that would have to be made, along with the time needed to make them, to the front-end processing systems, the shared systems, and the MACs’ local systems to continue to process ICD-9 codes after October 1, 2015. Although CMS has taken such actions to mitigate risks and minimize the impact of errors occurring in its own and its stakeholders’ systems, the implementation of new or modified software always introduces risks that unforeseen errors will be encountered when the software is released into a live production environment. Such errors may occur if the systems encounter unanticipated conditions related to ICD-10 that had not been considered during system testing. Further, unidentified risks related to the ICD-10 transition could cause disruptions for which the need for corrective actions or contingency plans had not been recognized. Therefore, while it can be expected that system errors will occur, the extent to which any such errors will disrupt the agency’s ability to properly process claims cannot be determined until CMS’s systems begin processing ICD-10 codes. CMS has taken various steps to help providers, clearinghouses, and insurers that participate in the Medicare fee-for-service program implement the systems changes they need to make for transitioning their systems to ICD-10. For example, CMS developed a website for publishing technical support and other information to help stakeholders identify, test, and implement system changes needed to process ICD-10 codes. CMS also provided enhanced technical capabilities that allowed stakeholders to test the integration of their updated systems with CMS’s claims processing systems environment. Further, CMS officials informed stakeholders of alternative ways to file claims that include ICD-10 codes in case any stakeholders have not completed their systems changes by October 1, 2015. As early as 2008, CMS had developed and published a website that includes information related to the implementation of systems changes needed to process and submit ICD-10 codes for Medicare claims processing. The website is updated regularly and, among other information, provides technical guidance to help various stakeholders (e.g., small, medium, and large physician practices; rural physician practices; hospitals) identify and implement needed system changes. The website also includes checklists that stakeholders can use to help guide the development of operational plans for their systems and to identify criteria for developing systems test data and conducting various levels of testing. The checklists identify steps that need to be taken, such as including the most-often-used codes in test cases and testing with external partners, such as payers and clearinghouses. In addition, the “Medicare Learning Network” page on the website provides resources that are intended to keep stakeholders informed of new developments in ICD-10 implementation planning and help them prepare for the ICD-10 transition. These resources include videos, notifications of phone calls with the industry, and subscriptions to e-mail updates. Further, to enhance its efforts to meet stakeholders’ ongoing need for support in implementing system changes for ICD-10, in March 2013, the CMS Office of E-Health Standards and Services collaborated with stakeholders that represent health care providers, health information technology professionals, and insurers. CMS and these stakeholders discussed the need for small providers to update their existing systems in preparation for the ICD-10 transition. Information collected from these collaborations and published on the ICD-10 website identified “lessons learned” from previous experiences in updating systems, such as the need to conduct testing early in the process and to communicate results and information so that providers do not repeat the mistakes made by others. In response to the information collected through these collaborative efforts, CMS identified and developed tools and guidance to address stakeholders’ needs and help them implement and test the systems changes to process ICD-10 claims data. For example, the “Road to 10” made available from the ICD-10 website provides information to help small providers identify the steps they need to take to transition to ICD- 10. Among other things, this resource includes checklists for updating Medicare claims data entry and submission systems, preparing test cases, and conducting internal and external testing. According to the health care information technology stakeholder representatives with whom we spoke—from AHIMA, HIMSS, WEDI, Cooperative Exchange, and AHIP—the information and guidance provided by CMS through its website, collaborations, and industry phone calls have proved to be helpful and valuable to their constituents in updating their systems that process ICD codes. Additionally, CMS took steps to assist the MACs in their efforts to update the systems they use to submit providers’ claims to CMS and to address challenges identified by these contractors as they make changes to their systems. For example, when three of the MACs noted a challenge in mapping ICD-9 to ICD-10 codes when updating their systems, CMS provided a cross-walk data base to help them conduct the mapping. Representatives of the MACs reported that this tool was helpful in their development of software edits associated with ICD-10 coding. Since March 2014, CMS has allowed stakeholders to conduct unlimited testing of their systems that are being changed to submit ICD-10 claims data. Specifically, stakeholders are allowed to conduct “acknowledgment tests” to determine whether providers’ claims data are valid and acceptable for processing by CMS’s internal front-end validation systems. According to information provided on CMS’s ICD-10 website, stakeholders can continue to conduct acknowledgment testing up to October 1, 2015. During acknowledgment testing, test claims are submitted from providers’ systems, either directly or through clearinghouses, to their supporting MACs. The claims are either accepted or rejected by the front-end validation systems. To be accepted, the claims data must include a valid ICD-10 code that matches the date of service and a valid National Provider Identifier. The submitter must also enter an indicator into a data field to specify whether a claim is using an ICD-9 or ICD-10 code, respectively. Claims data that do not meet these requirements are rejected by the front-end systems and sent back to the providers for correction via the MACs’ systems. CMS also conducted and monitored four weeks of structured acknowledgment testing during which agency officials collected data regarding the results of stakeholders’ tests on a national basis. Specifically, it collected data during one week in March 2014, one in November 2014, one in March 2015, and one again in June 2015, about the claims transmitted to CMS’s systems by the stakeholders. The purpose of these national acknowledgment tests was to help providers assess the readiness of their systems to submit claims with ICD-10 codes. During the four weeks of national acknowledgment testing, CMS measured the percentage of claims accepted by the front-end systems, which provided an indicator of the extent to which stakeholders’ systems were ready to submit ICD-10 codes to the Medicare claims processing systems. Table 1 describes the results of this testing and the percentage of claims that were accepted by CMS’s front-end validation systems. To further support stakeholders in their efforts to update their systems for the ICD-10 transition, CMS officials responded to stakeholders’ feedback to address a risk associated with the lack of external testing, which agency officials with the Office of Technology Solutions had identified in their own ICD-10 planning activities. To address this risk, CMS introduced an additional level of testing and offered opportunities for selected stakeholders to conduct end-to-end testing of their systems with CMS’s internal claims processing systems. This additional testing allowed stakeholders to test cases that simulate their live claims processing environment and determine whether the test claims data were valid and properly processed by CMS’s shared systems and Common Working File for authorization or denial of payment. Specifically, during three weeks of end-to-end testing, CMS allowed selected stakeholders (i.e., providers and clearinghouses that submit Medicare claims) to submit test claims data to their supporting MACs, to be processed by the front-end data validation systems that had been modified to accept ICD-10 data. Any claims that were rejected by the front end could be corrected and re-submitted by the provider or clearinghouse. The accepted test claims data were then transmitted to a test environment of CMS’s shared systems, which determined whether the claims had been properly submitted. The approved claims data were transmitted to a test version of the Common Working File, which authorized or denied payment of the claim. The shared systems then created remittance notices that were sent back to the providers. As a result of participating in the end-to-end tests, stakeholders could confirm that their systems were able to accept and transmit the new codes to CMS’s claims processing systems. The end-to-end testing was conducted for a week during each of the months of January, April, and July 2015 to accommodate up to 2,550 stakeholders. In this regard, CMS’s test plans allowed up to 850 stakeholders to participate in the first week of testing; 850 more to participate in the second week (in addition to any of the previous testers who wanted to re-test), and another 850 to participate in the third week (also in addition to any who wanted to re-test, for a total of 2,550 stakeholders). The MACs were responsible for selecting volunteers from the providers and clearinghouses they support to participate in the tests. The MACs’ selections were subject to approval by CMS. To be approved, the participants had to be enrolled in electronic data interchange and able to receive electronic remittance advice. They also had to have an active, valid National Provider Identifier number. According to officials representing the MACs, their test participant selections included a representative cross section of providers and a variety of specialties and facilities. They also stated that they considered the types of claims, the size of the providers, and the geographic location when selecting participants. According to the MACs, the testers were responsible for developing their own test cases, which were to be designed to reflect a wide variety of services or equipment for which they normally submit claims for Medicare payment. Testing criteria were provided to the approved testers via the MACs’ websites, and CMS hosted training sessions with the testers to review procedures. CMS scheduled monthly status calls with the system maintainers and MACs to discuss challenges or issues encountered by their test participants during end-to-end testing. Officials from the nine MACs stated that technical support from CMS during the end-to-end testing weeks was available and easily accessible. As reported by CMS and noted in table 2, in January 2015, 661 testers submitted claims and, in April 2015, 546 additional and 329 repeat submitters participated in the tests. In July 2015, 1173 testers submitted claims, including 680 additional and 493 repeat submitters. While the reported number of testers and claims submitted during the April and July 2015 test periods increased from the number in January, the level of participation was considerably lower than the level of participation that CMS’s facilities were designed to accommodate—850 during the first period, 1,700 during the second period, and 2,550 during the third period. Stakeholders with whom we spoke told us that, while there was concern regarding this level of participation in end-to-end testing, CMS had communicated the availability of enhanced testing capabilities and provided guidance to encourage broader participation. Representatives of the MACs and stakeholders noted that CMS was responsive to their requests for additional testing and expanded outreach to targeted groups in an attempt to broaden the scope of test participants. The MACs noted that, given the variety of testers participating and claims submitted during end-to-end testing, along with the three levels of testing conducted as part of CMS’s change management process, in their view overall testing had been comprehensive and sufficient to ensure that stakeholders’ and CMS’s systems would be ready to process ICD-10 claims data on October 1, 2015. Figure 4 provides an overview of the time frames during which CMS offered structured acknowledgment and end-to-end testing opportunities to stakeholders. Though not generalizable to all stakeholders, representatives of the health information technology groups with whom we spoke stated that CMS’s efforts to support the ICD-10 system transition, particularly over the past 2 years, have been very effective. Officials with AHIMA, AHIP, HIMSS, WEDI, Cooperative Exchange, and the MACs stated that they believed that the majority of their constituencies—i.e. providers, insurers, and clearinghouses—have updated their systems to accommodate the ICD-10 transition, and most had done so in time for the earlier October 2014 compliance date—the first extension allowed by HHS to give stakeholders more time to prepare for the transition. The agency and the MACs have also provided alternative methods for providers to submit claims data to CMS should any of their systems not be ready to process and submit claims with ICD-10 codes by October 1, 2015. For example, free billing software is available from all the MACs and can be downloaded from their websites onto providers’ computers and used by providers to manually enter and electronically submit claims data until they have completed the system changes needed to submit claims with ICD-10 codes. Additionally, five of the nine MACs (that cover 8 of the 16 MAC jurisdictions) provide access to online portals that allow entry of Medicare Part B claims data for submission to CMS. For example, a provider may log into its MAC’s website and access the claims data entry system, which allows providers to manually enter data, including ICD-10 codes, and submit them to the MAC’s system. According to CMS data provided by the Office of Technology Solutions, in 2014, more than 1.3 million Medicare Part B claims were submitted in this manner. CMS also defined a contingency plan that would allow for paper claims submission for a temporary period of time, if specified conditions are met, in the event that stakeholders’ systems are not ready to submit ICD-10 codes beginning October 1, 2015. Under some circumstances, CMS allows providers to request a waiver from electronic submission requirements and, if granted, submit paper instead of electronic claims. However, very few stakeholders currently submit paper claims. According to a CMS official with the Office of Technology Solutions, 98 percent of Medicare fee-for-service claims are filed electronically. However, this alternative to electronic claims filing provides an option for providers to submit claims that include ICD-10 codes if they have not yet completed making changes to their systems. CMS communicated information to its stakeholders about the availability and use of these alternative solutions through its “Road to 10” web page. The agency also included information about the free billing software and the MACs’ portals in a “Medicare Learning Network” article published on its website in February 2014. According to CMS officials in the Office of Enterprise Information, the known costs of the agency’s efforts to update its claims processing systems for the ICD-10 transition are estimated to be approximately $116 million for developing, testing, and implementing the system changes. The officials stated that the agency incurred about $96 million of these costs from September 2007 through September 2014. The officials added that this estimate reflects efforts to address 42 ICD-10-related change requests that were submitted during that time. Although CMS identified its systems changes as having been completed in time for the initial October 2013 compliance date, additional costs were incurred after the delay of the compliance date from October 2014 to October 2015. Specifically, agency officials stated that they incurred costs associated with rework that needed to be completed in order to reinstate software specific to ICD-9 that had been changed to process ICD-10 data. In addition, CMS officials reported that resources were redirected to conduct regression tests of the systems throughout the delay to ensure that functionality and changes already implemented, such as for ICD-10, were not negatively affected by additional changes made to the systems for other reasons (e.g., new technologies or policy changes) at each quarterly release. Agency officials with the Office of Technology Solutions further stated that they had initially planned to conduct just one period of end-to-end testing prior to the October 2014 compliance date, but added that they were able to schedule the two later end-to-end test periods during the delay to provide additional opportunities for stakeholders to test their systems from October 2014 through October 1, 2015. According to officials with the Office of Enterprise Information, the additional IT costs associated with these combined activities were estimated to be about $20 million. Beyond the estimated costs reported by CMS, little is known about the costs that providers, clearinghouses, and insurers incurred for updating their Medicare claims submission systems. Such costs were not identified by the professional associations we contacted or by industry studies that we reviewed. HHS (in its final ICD-10 compliance rule) and the associations reported estimates of the overall costs for their constituencies to transition to ICD-10, and one study conducted for AMA estimated costs that would be incurred by providers to update their systems environment, including the systems they use for provider management and electronic health records implementation. However, none of these entities studied, estimated, or reported costs specific to stakeholders’ efforts to upgrade systems to process Medicare fee-for- service claims data that include ICD-10 codes. We received written comments on a draft of our report, signed by HHS’s Assistant Secretary for Legislation. In the comments (reprinted in appendix III), HHS described a number of actions that it has taken to help ensure that its systems are ready to process Medicare claims that include ICD-10 codes and ongoing efforts to support stakeholders in their transition to the new code set. The department also said our report stated that CMS’s systems were completely updated and had undergone comprehensive and sufficient testing to process ICD-10 codes. In fact, we reported that agency officials had finished making the changes that they determined were needed to process the new codes and had conducted system testing and validation procedures consistent with industry practices. We cautioned that unanticipated system errors could disrupt Medicare claims processing when systems are required to begin processing ICD-10 codes and emphasized that the actions taken by CMS were important steps to help minimize the impact of any such disruptions. HHS also provided technical comments, which have been incorporated as appropriate. We are sending copies of this report to interested congressional committees, the secretaries and agency heads of the departments and agencies addressed in this report, and other interested parties. In addition, the report will be available at no charge on GAO’s website at http://www.gao.gov. If you or your staffs have any questions on the matters discussed in 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 major contributions to this report are listed in appendix IV. The objectives of our review were to determine (1) the status of CMS’s effort to implement changes needed to be made to its systems in order to process Medicare claims that include ICD-10 codes; (2) the extent to which CMS’s testing and verification actions are sufficient to ensure changes to its systems have been made to process Medicare claims that include ICD-10 codes by October 1, 2015; (3) steps CMS is taking to ensure that health care insurers, providers, and other entities have access to the technical support, tools, and other resources needed to identify, develop, and test system modifications, and to process Medicare claims that include ICD-10 codes if needed system changes have not been made; and (4) what is known about estimated costs to CMS, insurers, and providers. For each of the objectives, our scope included the CMS systems used to process Medicare fee-for-service claims including the Fiscal Intermediary Shared System (FISS), the Multi-Carrier System (MCS), the ViPS Medicare System (VMS), and the Common Working File. To address the first objective, we obtained and reviewed documentation describing the CMS systems impacted by the ICD-10 transition, the necessary system changes, and the modified systems’ implementation dates. To determine the actions taken by CMS to implement the changes for the ICD-10 transition, we obtained and examined relevant project management documents, including project plans and release notes that provided information about the systems changes that were needed and activities planned for completion by October 1, 2015. To determine the steps taken to identify and address risk, we examined documentation describing practices and methods for identifying and categorizing risks associated with ICD-10 system changes. We also reviewed documentation describing mitigation strategies used to manage the identified risks such as contingency plans for processing claims data in case errors occurred. In addition, we held discussions with CMS officials responsible for the ICD-10 systems transition to obtain their views on the status of steps taken to implement system changes. To address the second objective, we identified criteria for assessing the sufficiency of systems testing and verification practices based on established industry standards for conducting software and systems testing. We obtained and analyzed documentation describing the processes CMS has established to test and validate the changes it identified that needed to be made to process Medicare claims with ICD- 10 data. We compared the reported outcomes of CMS’s testing and validation processes to criteria and practices defined by industry standards. In particular, we assessed steps conducted by the agency during the testing phases of its systems change management process to practices defined by the Institute of Electrical and Electronics Engineers standards for conducting software and system tests. To determine the extent to which CMS followed its established process and adhered to these standards, we reviewed documentation that described test schedules, plans, and results. We focused our study of CMS’s ICD-10 testing activities on the final phase, the user acceptance test, because its purpose is to provide a comprehensive test that replicates a live production claims processing environment and involves the participation of end users along with the support of the testing and development contractors that conducted lower levels of testing that preceded user acceptance testing. These contractors’ support was intended to ensure that any errors that were not detected previously could be corrected prior to systems being released into production. We examined documents, including minutes of weekly status meetings, that described tests conducted by CMS’s contractors, errors identified during the tests, and the status of efforts to address the errors prior to the initial compliance date of October 1, 2013. We also reviewed minutes of and documentation supporting release readiness reviews held by CMS officials that describes the status of testing and any remaining tests to be done. We assessed the reliability of the data provided by CMS by reviewing related documentation and collecting supporting data via questionnaires we issued to, and received from, all the Medicare Administrative Contractors (MACs) that documented the status of and progress made toward testing system changes and correcting errors. We analyzed detailed test data, such as examples of test cases and documented test results, provided by the MACs’ documents to understand the extent of testing that was conducted leading up to the October 2013 release. We determined that the data we collected were reliable for the purpose of our report to understand the extent to which CMS’s efforts were sufficient to validate that any errors associated with ICD-10 system changes were addressed and the software changes approved for release into production. To address the third objective, we identified stakeholders’ needs for technical assistance based on prior GAO work and information collected from entities such as professional associations that represent providers, insurers, and health care clearinghouses, and the MACs that process Medicare fee-for-service claims. To determine the types of technical resources CMS provided to help stakeholders identify and test the changes that needed to be made to their systems, we examined documentation describing tools such as user guides and data crosswalks, and additional resources such as claims processing software and testing facilities to support the ICD-10 transition. We also analyzed agency and contractors’ documentation that described practices for selecting and approving participants for testing activities conducted by CMS to help stakeholders test the integration of their systems with CMS’s claims processing systems. We obtained and reviewed the list of participants and number of claims submitted to obtain an understanding of the level of stakeholder representation in the testing activities. We also collected information from the contractors that supported the stakeholders to obtain their views on the outcomes and comprehensiveness of the tests. Finally, we examined CMS’s plans for providing alternate resources for stakeholders’ to submit claims that include ICD-10 codes in case their systems are not yet updated to include and submit ICD-10 data for Medicare claims. To determine the extent to which the industry stakeholder groups found the support provided by CMS useful, we selected and held discussions with entities that play a role in supporting the implementation of health care information technology, including implementing system changes needed to be made for the ICD-10 transition. The entities we selected were the Healthcare Information Management Systems Society (HIMSS), American Health Information Management Association (AHIMA), America’s Health Insurance Plans (AHIP), and the Workgroup for Electronic Data Interchange (WEDI). From these discussions, we obtained their views on the effectiveness of the technical support CMS has provided to their constituencies since 2008. For the fourth objective, we collected data available from CMS regarding any actual or estimated costs known to have been incurred by the agency associated with the development, testing, and implementation of necessary system changes for the ICD-10 transition, to include additional costs incurred as a result of the delay until October 1, 2015. We assessed the reliability of the data provided by CMS by examining agency documentation and discussing with an official of the Office of Enterprise Information the agency’s approach for producing financial statements and the outcomes of independent audits of those statements, which were reportedly produced in accordance with generally accepted accounting principles. We also reviewed published reports of selected health care professional associations that support providers that submit claims to CMS for reimbursement. These entities were the Professional Association of Health Care Office Management and the American Medical Association, along with HHS’s final rule on ICD-10 compliance. We determined that the cost data we collected were reliable for the purpose of our report to identify any costs known to have been incurred by CMS and its Medicare stakeholders for implementing system changes needed to process ICD-10 codes. We conducted this performance audit from January 2015 to September 2015 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 conclusion based on our audit objectives. Description Implement Fiscal Intermediary Shared System ( FISS) Integrated Outpatient Code Editor changes related to the tenth revision of the International Classification of Diseases (ICD-10) Expand Multi-Carrier System (MCS) Diagnosis File to accommodate ICD-10 diagnosis codes Create ViPs Medicare System (VMS) utility run for Durable Medical Equipment MACs identification of edits for ICD-10 Update VMS Automated Development System to recognize and print the ICD-10 indicator Remove any obsolete Quarterly Medical Review processes and reports from VMS that include ICD-9 codes Expand MCS procedure code file to accommodate ICD-10 diagnosis codes Expand Expert Claims Processing System for FISS to accommodate ICD-10 Expand FISS End Stage Renal Disease Parameter files, Hook Selection files, and Medical Policy Parameter files to accommodate the transition to ICD-10 Convert FISS reason codes to ICD-10 format Update MCS hard-coded edits for ICD-10 diagnosis codes Expand MCS to accommodate ICD-10 by expanding Common Working File elements Update the existing VMS Utilization Parameter files for ICD-10 Expand Related Diagnosis file to accommodate ICD-10 diagnosis codes Update VMS Inbound and Outbound Claims Interface Processing Convert FISS reason codes, Phase II Expand FISS Medical Policy Parameter Convert FISS reason codes, Phase III Convert the Common Working File, Phase I Implementation Include Type of Bill 33X for ICD-10 Create file to be used for planning and testing purposes in preparation for the ICD-10 code conversion Convert FISS for Add-on Payment for Blood Clotting Factors, and ESRD Co-morbidity Adjustment Factors Implement VMS ICD-10 Release III, No. 1; update VMS online screens Convert the Common Working File for ICD-10 changes (Phase II Implementation) Expand the Laboratory National Coverage Determination edit software Implement VMS ICD-10, Release III, No.2; updates to Online Claims Processing and Entry Code Convert FISS Present on Admissions indicator Convert from ICD-9 and related code infrastructure of the Medicare Shared Systems as they relate to CMS National Coverage Determinations (change request 1 of 3) In addition to the contact named above, Teresa F. Tucker, Assistant Director; Melina I. Asencio; Christopher G. Businsky; Nancy E. Glover; Ashfaq M. Huda; Thomas E. Murphy, Terry L. Richardson, and Amber H. Sinclair made key contributions to this report.

Summary: ICD is the standard code set used in the United States to document patient medical diagnoses and inpatient medical procedures. Every claim submitted by health care providers to payers for reimbursement, including those for Medicare programs, includes these codes. CMS is responsible for enforcing the use of ICD codes and is requiring providers to begin using the 10th revision of the codes (ICD-10) on October 1, 2015. Its role in preparing for the transition includes making changes to the agency's information technology systems used to process Medicare fee-for-service claims and supporting stakeholders' efforts to implement changes to the systems they use to submit Medicare claims that are to include ICD-10 data. GAO was asked to study the actions planned and taken by CMS to support entities' transition to ICD-10. This report discusses (1) CMS's efforts to implement system changes needed for the agency to process claims that include ICD-10 codes, (2) the extent to which CMS's testing and verification actions are sufficient to ensure the system changes are made, and (3) steps CMS is taking to ensure that stakeholders have access to technical support needed to make system changes. To do this, GAO reviewed project documentation and held discussions with Medicare officials, contractors, and selected stakeholder groups that represent providers, health care clearinghouses, and insurers that share claims data with CMS. GAO provided a draft of this report to HHS and incorporated its comments as appropriate. The Centers for Medicare & Medicaid Services (CMS) has finished updating its systems with the changes it determined were needed to process the new International Classification of Diseases codes (ICD-10) on Medicare fee-for-service claims. In 2007, CMS began taking steps to identify components of its systems that needed to be changed to update the ICD codes from version 9 to 10. CMS began making the system changes in early 2010 as part of an established change management process for releasing system updates on a quarterly basis, and, by October 2013, had completed actions to modify its systems to process the new data. In doing so, CMS made changes to validate that codes on submitted claims were of the correct length and format specific to ICD-10 requirements and to determine whether submitted claims data included the proper codes to be processed and approved for payment. Industry guidance states that systems testing should be conducted early and often in the life cycle of a project to allow for the modification of software in a timely manner, and that organizations should define procedures for approving systems for release and plan for contingencies to help mitigate risks that may be introduced when software changes are implemented into a live production environment. Consistent with these practices, CMS began testing and validating the changes made to its systems in March 2010. For each quarterly release, CMS conducted three levels of testing prior to implementing the systems that had been changed, including a level conducted to simulate a live production environment of Medicare claims processing. Agency reports on the outcomes of the tests described errors found and steps taken to ensure any such errors were corrected. The agency also held management reviews to determine whether each version of the modified systems was ready to be released into a live claims processing environment. In addition, CMS officials defined contingencies for cases when systems may not properly process claims that include ICD-10 codes. Such actions are important to help minimize the impact on Medicare stakeholders that could result from errors in CMS's systems. While CMS's actions to update, test, and validate its systems, and plan for contingencies can help mitigate risks and minimize impacts of system errors, the extent to which any such errors will affect the agency's ability to properly process claims cannot be determined until CMS's systems begin processing ICD-10 codes. CMS provided technical support to help its stakeholders identify and make system changes. As early as 2008, CMS had developed and published a website that includes information related to the implementation of system changes to process and submit ICD-10 codes, such as checklists and “lessons learned” identified through collaboration with stakeholders, to help stakeholders identify and implement system changes. The agency also developed tools to help its Medicare Administrative Contractors update claims review and submission systems, such as those used to ensure valid claims are transmitted to CMS's claims processing systems. In addition, CMS expanded and enhanced capabilities to accommodate end-to-end testing that allowed stakeholders to test the integration of their systems with CMS's internal systems, and offered alternative technical solutions for submitting claims with ICD-10 data in case their systems are not modified in time to meet the compliance date.