ICD-10 Testing, Testing … 1-2-3

By
In Coding Edge Archive
November 1, 2011
No Comments
85 Views

Lessen testing anxiety by following a timeline, creating a taskforce, and executing a plan.

By Julia Croly, CPC, CPC-P, CPC-I

ICD-10 implementation testing can be frightening. But how often have you found that when you are prepared for a test, it’s not as bad as you originally anticipated? Such is the case with ICD-10: With careful preparation, in just three steps, you can earn an A+.

  • As you prepare for ICD-10 testing, keep these essential goals in mind:
  • Testing needs to include ICD-10 and any projects underway.
  • Testing needs to be robust, due to the high number of code changes.
  • Testing needs to ensure financial neutrality.
  • Testing may need to ensure dual processing (e.g., both ICD-9 and ICD-10 functionality).
  • Testing must include considerations for trading partners.
  • Testing must be coordinated.

1. Create a Timeline to Begin Testing in Mid-2012

Your timeline should include several key events, such as when to begin testing. Many organizations, for example, are drafting timelines for ICD-10 implementation testing to occur from mid-2012 up to the compliance date of Oct. 1, 2013, as shown below. But there is no “one size fits all” suggested start date: The actual testing kickoff date depends on each organization. And like many organizations, you may want to segregate internal and external testing to account for vendor dependencies and the deep penetration of ICD-10 code in systems and processes.

I-10-timeline

2. Create a Taskforce

Establishing a testing taskforce helps to manage the testing effort. The taskforce oversees complete, integrated testing, and forms multiple workgroups, each of which is in charge of a particular testing effort. Communication among the workgroups is essential.

This effort is complex and requires a high-level test plan to address the overall requirements and the design details of subsystems and components. Test plan document formats can be as varied as the products and organizations to which they apply, but generally contain some common features, including:

  1. Test coverage in defining scope and objectives
  2. Identification of business areas and participants, including roles and responsibilities
  3. Testing methodologies and functions to tests
  4. Identifying risk factors that may jeopardize testing
  5. A testing schedule

In the past, testing has focused on the transaction and whether it can be initiated, received, and understood correctly. Testing in the case of ICD-10 must involve all of the aforementioned, plus validation that business rules continue to work as designed pre-ICD-10.

To help your team effort, collaborate in developing test strategies, test cases, and test scripts. Workgroups should develop specific guidelines and standard operating procedures for testing, and indicate desired end results for modifications made along the way. Creating a test environment separate from production will greatly facilitate this effort.

The testing effort will produce a great deal of information. Use tools to log and track your findings throughout all testing. Change logs are highly recommended to maintain control over individual changes, and to track subsequent effects of those changes. From this information, metrics can be extracted to measure and track project milestones.

A risk-based approach to testing helps ensure that changes, delays, and other unforeseen obstacles can be dealt with effectively. Changes, especially to older systems, can create unforeseen bugs unrelated to the ICD-10-CM/ICD-10-PCS conversion. The more robust your testing efforts, the better off you will be.

3. Begin Testing

Internal Testing

After the necessary ICD-10 changes have been made, it’s time to test information technology (IT) systems and business processes. Internal testing identifies localized system glitches that may occur when creating and receiving transactions that contain ICD-10 codes. Internal testing also encompasses manual and workflow processes using diagnosis and procedure codes (in collection, reporting, or both).

Every change to a system or application must be tested before it goes into production. Testing can be broken into the following categories:

  • Quality Assurance: This answers the question, “Do all of the changes made provide the expected outcome?”
  • User Acceptance Testing: This testing should be planned and executed by participants from the business area affected by the changes. These participants will sign off that the systems are functioning properly and workflow design is accurate and suitable for the purpose intended. With this effort, it’s critical there are no gaps in functionality.
  • Integration Testing: This combines the parts to determine if they are working together.
  • Regression Testing: This ensures there is no impact on previously tested results, and retests the programs to ensure there is an increase in functionality and stability. Don’t forget to test business processes not affected by ICD-10 (these may be few and far between), preferably using an automated testing tool.
  • Performance Testing: This is done to ensure the system provides acceptable response times, and to identify and remove all bottlenecks that may result in less-than-optimal performance. Testing system compliance through performance testing is usually done with a large number of users.
  • End-to-end Testing: This involves testing the interfacing applications and the full life cycle of a claim from receipt to payment to data storage. It also tests business processes to ensure the desired outcome.

Remember: Internal testing must include not only time for testing, but also remediation and retesting.

External testing

Organizations often depend on third-party vendors and trading partners; and with ICD-10 compliance testing, you must ensure the desired functionality is achieved and business processes are maintained.

Planning and coordination are essential to external testing because such testing involves coordinating with many entities. Remediated application availability should be obtained well in advance to planning for testing activities. From the impact analysis,  have a list of third-party vendor and trading partners that must be contacted to discuss testing expectations. Prioritization involves identifying those who are most critical to ensuring compliance. Scheduling follows prioritization. In case a vendor or trading partner is not ready on the agreed-upon date, flexibility and contingency planning may be necessary.

Just as with internal testing, there needs to be adequate time for testing, remediation, and retesting to ensure desired functionality. The purpose of external testing is to identify any issues that must be resolved prior to the compliance deadline.

Testing is just one component of ICD-10 implementation, but it’s a critical step that is often underestimated. To limit your stress and minimize operational and financial risk to your practice or facility: Understand the complexity of ICD-10 implementation; establish a timeline that includes both internal and external testing; and create a detailed plan.

Julia Croly, CPC, CPC-P,CPC-I, has 25 years experience in health care insurance and works as an independent health care consultant and educator in Honolulu, Hawaii. She can be reached at mjcroly@gmail.com.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Menu Title