This new version of the International Classification of Diseases involves a four-fold leap in the diagnostic codes and a 22–fold leap in the procedure codes used in every part of the clinical and business value chain.While this will eventually help improve care and drive efficiencies, the complexity and breadth of this shift requires organizations to begin remediation and testing now, in close cooperation with business stakeholders, to ensure compliance by the proposed October 1, 2013, deadline.
Effective ICD–10 testing must focus not just on technical requirements but also on business objectives, such as clinical equivalency, benefit neutrality, financial integrity and operational stability. The test plan should take a risk–based approach to prioritizing testing of the most critical functions and scenarios. It should take into account internal constraints – such as competition for funding – as well as external constraints, such as delays in the availability of ICD–10–compliant products from vendors. Because each organization has its own mix of applications with unique dependencies and process flows, ICD–10 testing requires each healthcare payer to properly schedule its unique sequence of unit and end– to–end testing.
Healthcare payers must also coordinate ICD–10 testing with the ongoing QA of other enterprise applications. Additionally, there is the challenge of creating accurate test data for an ICD–10 application environment that does not yet exist. This requires not only tools but also an analytical approach and method that depends on human input and decision– making.
How Testing Meets the Challenge
Testing plays an especially important role in ICD–10 remediation because of the breadth and depth of how the codes are used in both clinical and business processes, as well as the need to ensure the transition does not harm clinical decisions, financial or operational processes.
However, because of the unique requirements of ICD–10 remediation, standard system testing lifecycle models will not suffice. Very few organizations will be able to test all scenarios, so they will need to turn to risk–based testing to prioritize which scenarios are most critical.
The first step is creating a clear test strategy and detailed test plan. This plan must go beyond testing technical and functional application requirements, to include outcome–based testing of business scenarios and macro processes such as customer service, customer enrollment and provider management. This will ensure that the defined goals are met at the business, financial, benefit, clinical and operational levels
Next is the development (with the help of domain experts) of business scenarios that represent the ICD–related processes that generate the highest volume of transactions and processes and thus could have the greatest financial impact on the payer organization.
From there, the scenarios are executed through end–to–end testing that validates the full execution of a business process with a business partner. This testing should ensure that all of the payer's IT systems, as well as the external trading partner's systems, are integrated, interoperable and ready to accept and process the new codes and formats.
The creation of the test environment begins with identifying the hardware and software requirements for all relevant applications, as well as which existing test environments can be reused for ICD–10 testing, such as those used for enterprise system and Version 5010 compliance.
It is also critical to understand how the current test environment will be affected by ICD–10 enterprise testing. This is especially challenging in the case of ICD–10 because, in a regular test cycle, an organization maintains multiple test environments to run various scenarios. Since under ICD–10 the scenarios involve all core systems, it is much more difficult to create dedicated test environments.
Because of the hard deadline, a phased approach to testing and implementation is not possible. All forms of testing, from unit to end–to–end testing, must be completed for the most critical processes by the “go–live” date. This, again, increases the importance of prioritizing which scenarios and processes to test first, and the need to involve business partners in identifying and aligning them.