Best Use of the Fourth ICD-10 Delay: Refine Testing… Then Help Others

By Juliet A. Santos, MSN, CCRN, FNP-BC
Original story posted on: June 2, 2014

One of the challenges of the previous October 1, 2014, deadline was the “rush factor” that seemed to cause organizations to circumvent the details of testing all systems, which could overwhelmingly affect their level of success.

In addition, during the WEDI Conference in Hollywood, Calif., on May 12-15, participants once again discussed a major gap in healthcare IT today. Because healthcare has never really had an end-to-end test that required multi-stakeholder national coordination, a glaring abyss is hard to miss when it comes to information on standardized testing for providers, payers, clearinghouses, vendors, and others in the patient visit life cycle.

The majority of attendees agreed that along with continued clinical documentation improvement efforts, the industry must also take testing up a notch—specifically creating a standardized testing process that identifies all the requirements according to the ICD-10 regulation. The healthcare industry needs to know what to test, and how to test end-to-end with external stakeholders in a way that will minimize the guesswork and trial and error costs for all, especially the small physician groups. The healthcare industry certainly does not want to leave out the “physicians” (a generic terminology used in this article to mean doctors, nurse practitioners, physician assistants, and other prescribers or diagnosticians).

ICD-10 Testing Tips

The many components and sub-components of systems testing can be perplexing. It may perhaps be the most complex part of testing for some, since it consists of multiple sub-tests, interfacing links, and internal interoperability challenges. Systems testing incorporates the overall regulatory and solution requirements that need validation by the end users in terms of quality, functionality, and accuracy. It requires a flawless performance as its desired outcome when all systems are integrated and tested together.

Systems Testing Components

Components of systems testing may include, but are not limited to, the following:

  • Validating requirements to ensure all business requirements are met.
  • Usability testing to determine how user-friendly it is to the end-user (i.e., unit coordinators, nurses, ancillary personnel, providers, etc.). It tests for poor design caused by human errors/factors that are often missed by designers but easily identified by the end user.
  • Stress testing, if applicable, to ensure the integrated systems are capable of handling high data traffic all at once with heavy, simple, and complex transactions volumes, concurrent users, multiple commands, etc.
  • Security testing that confirms superior levels of security, internal controls, and breach-free protocols are in place.
  • Disaster recovery testing to identify how quickly data can be recovered in case of disaster or massive systems failure that could cripple an organization.
  • Regression testing to ensure that no new defects are introduced in the process of well-intended upgrades and remediation.
  • Unintended defects can be costly and difficult to correct if not detected immediately. This is typically done after the User Acceptance Testing and repeated as needed until the go-live date to ensure the system has not been corrupted accidentally.
  • Procedures validation to ensure the application is understandable and simple enough for use by the end user for an easy workflow.

Additionally, the following tips may be helpful in developing a test strategy and test plan if testing has not commenced:

  • Start with thorough test planning. 
  • Create a test strategy so your test plan can easily flow from it.
  • Since this is the most comprehensive federal regulation we’ve tested for to date, document well and plan to use the test strategy and test plan for future federal mandates. You will be experts on testing after this exercise.
  • Leverage what you’re doing now, so that testing comes much easier to you when testing for Meaningful Use, upgrades, and other federal regulations.
  • Create reusable, validated test data. Ensure that testing is not just another one-off, but also can be easily replicated by your organization, regardless of who is leading the test team the next time around.
  • Store dual-coded test data that were previously submitted in ICD-9 in a safe repository for easy access for future testing.
  • Communicate the test plan to the Steering Committee and Test Planning team for review and feedback. They will have to communicate and explain these to their various departments and the test team will need their support and involvement. 
  • Document the test plan well and include the following:
    • Identify testing approach
    • Estimate resource needs, duration of testing period, and the expertise required for testing activities
    • Estimate how many test cycles are appropriate for the organization
    • Identify all testing processes
    • Identify or create tools for: test case management, defect management, reporting and metrics

When testing with physician provider groups, consider the following:

  • Verify and validate readiness to test to save time and frustration. Some may indicate they’re ready to test, but the testing team will need to validate that to avoid costly trial and errors.
  • The definition of testing both small and large entities varies industry-wide. There are many best practices and opinions, but no identified standards. Although testing with physician groups should not be complicated, the fact remains that most end users in smaller organizations may not have the skill set required for testing.
  • Ensure that test scripts are clear, concise, to the point, and at least one end user in that office can run the tests.
    • End users must be part of testing. End users may be the clinicians, office manager, or other support staff.
    • End users should be engaged in writing test scripts to ensure the required functionalities are captured.

In summary, use this extra time to work collaboratively, internally and externally. It is not just about ICD-10 testing or CDI; it is all about people, and ultimately, it’s all about patient safety.

Although systems are tested and coders may be ready to go, organizations will not get very far without the buy-in and the dedication of the people to implement and finalize ICD-10— effectively, safely.

ICD-10 is doable for both small and large organizations. It’s not a choice—it’s a compliance issue with a federal mandate many see as overdue. During this fourth delay, let us not forget to assist the small physician groups. Extend them a hand, or two.

The extra time is not really extra time to those who are behind. Identify what must be done to finish ICD-10… then go help others. You will find that as you’re helping others, you will learn more and will be able to improve your own readiness. When CMS announces another opportunity to test, all should be ready to participate.

About the Author

Juliet Santos is the principal ICD-10 consultant for Leidos Health, which specializes in solving complex problems across the healthcare continuum. Santos formerly was executive vice president of the Lott QA Group and assisted with the creation of ICD-10 National Testing Platform.

Contact the Author

.

To comment on this article go to

Disclaimer: Every reasonable effort was made to ensure the accuracy of this information at the time it was published. However, due to the nature of industry changes over time we cannot guarantee its validity after the year it was published.