One of our hospital clients has a sign above his desk reading “Hope is not a plan.” While this would apply to any IT project, nowhere is this aphorism more true than in ICD-10 testing.
Testing certainly isn’t new for anyone in the IT world – we do it whenever we upgrade a system. But traditional concepts about testing upgrades often fall short of the mark when planning ICD-10 testing. This is because ICD-10 is not only a technical upgrade, but also a major business process update.
Given the complexity of the processes and systems involved in generating ICD-10-compliant claims and processing payments, it is critical to test the entire operation from end to end. This is far more like the testing needed when installing a whole new system, not performing an upgrade.
To ensure that your organization adequately addresses the risks involved in this major undertaking, consider the following when setting up your test plan.
Start with testing the functionality of every system that has been upgraded to accommodate ICD-10. The system vendor should have performed its own testing, but you need to test systems in your own unique operating environment to ensure that the upgrades don’t introduce new issues into your environment (or undo former resolutions of old issues). Recurring issues can be problematic in environments with large amounts of custom code that could be overwritten in the upgrade.
When you test the functionality of systems upgrades, your vendors should provide examples to test as part of your validation. However, internally based test cases also must be created, using patient examples that reflect your hospital’s particular business processes and data flow.
When developing test cases, take a look at your organization’s high-risk and high-volume areas first. Focus on the generation of charges and claims for critical payers and in areas with particularly high claim volume or reimbursement rates. Test cases should include:
- Inpatient and outpatient claims for all your organization’s patient types.
- Claims generation for ICD-10-coded scenarios, including primary and secondary claims.
- Claims generation for ICD-9-coded scenarios; some claims won’t be affected by ICD-10 because of the date of service, or because a payer isn’t making the transition (e.g. an auto or worker’s compensation payer).
- Simultaneous processing of mixed ICD-9 and ICD-10 claims. This is needed for the reasons outlined above. Also, claims from older dates of service and current services will be generated on any given day.
- Injury claims for which a medical and a liability payer may pay on the same claim. These may require both ICD-9 and ICD-10 codes on the same claim – a complex scenario.
- Special cases for your organization requiring unique processes for particular business or payer needs.
- Finally, don’t forget paper claims. Though uncommon today, facilities still print claims for appeals purposes, as well as for minor payers, such as auto and other liability insurers.
Unlike internal testing, which addresses each system individually, integration testing focuses on an organization’s systems as a whole – the entire software environment, including every interface. Many hospitals find integration testing a challenge because they don’t have a completely integrated test environment in which to work. One potential solution is to create specific test patients in the production environment that will not drop to a final bill. Other test situations require creative manual intervention, which adds risk, since the manual portions of the process are not identical to those of your production environment.
Unfortunately, many hospitals skip integration testing, which can have disastrous results. Last year, when the Centers for Medicare & Medicaid Services (CMS) conducted its first round of acceptance testing with providers, a significant number of providers that had planned to participate couldn’t do so because they weren’t able to generate claims properly within their production environment. Yet integration testing is not a step to ignore!
If you perform integration testing correctly, it can become part of the first phase of operational readiness testing (ORT). ORT is a more broadly focused effort than IT testing alone; it requires testing the complete patient process, from patient presentation to discharge to claims submission. ORT includes close looks at all of the included process activities, using standard operating procedures and job aids, no matter what is within or outside your technical environment.
Finally, in this phase, don’t forget to look at the impact on systems throughout. The explosion of codes may put significant burdens on claims processing systems – particularly when mappings and non-vendor-supported items such as custom interfaces are involved.
As the name indicates, external testing requires participation with your organization’s external partners – clearinghouses and payers. If you use a single clearinghouse to submit all your claims, external testing is greatly simplified. Facilities that directly submit claims, including government claims, should test with every partner.
In any case, external testing should focus on your organization’s high-volume procedures, diagnoses, DRGs, and payers. You probably can’t test everything, but making sure the top scenarios are covered will go a long way toward mitigating your risk of conversion problems.
Like internal testing, external testing comes in more than one flavor:
Acceptance testing is by far the most popular with payers because of its relative ease and low cost: the payer simply receives your claim file and determines whether it meets the requirements for including ICD-10 data.
Unfortunately, acceptance testing won’t fully resolve your risks. During the HIPAA 4010-to-5010 changeover in 2012, acceptance testing was common, and many providers passed testing with payers because the payers were simply validating the affected fields. However, errors occurred elsewhere on the claims (in the creation of new claim form templates, for example), causing actual claims to fail in production.
End-to-end testing is the gold standard for final testing. End-to-end testing means not only testing your internal processes for generating a claim, as described above, but also testing your clearinghouse and payers’ processing of claims, including returning responses to you for test posting in your systems.
A true end-to-end test is advantageous because it will result in:
- Real adjudicated data. Using actual de-identified patient data on your high-volume claims produces genuine data about what payers will actually pay on your organization’s specific claims. This information, including payment and rejection data, will replace the assumptions previously made in your financial impact models. It may uncover areas where high-volume claims are impacted by payers’ changes to their claim adjudication rules.
- A genuine test of your system’s ability to post payments and rejections back to patient accounts. Almost any other test must be based on mocked up 835 transactions, not live data.
- More data reflecting your organization’s operational readiness.
Unfortunately, end-to-end testing is uncommon. Payers don’t want to do it because of the high costs involved in manually adjudicating large numbers of claims (10 to 20 percent of claims require manual intervention by the payer). You can volunteer as a testing partner with a payer, but be aware that they are severely limiting the number of participants in testing sessions. Even CMS, which has provided wide-scale acceptance testing, is greatly limiting end-to-end test participation.
Working with payers and other providers to examine properly de-identified versions of other organizations’ claims can also be useful. While not as valuable as scrutiny of your own data, understanding patterns of rejections that impact common ICD-10 codes will help when fine-tuning your coding, claims processing, and insurance follow-up rulesets.
Testing is a critical component of any well-planned ICD-10 conversion effort. By testing extensively, you can reduce operational and other risks to your organization and mitigate potential financial impacts.
Test early and test often, because hope is not a plan.
About the Authors
As a co-founder of Phoenix Health Systems, D’Arcy Gue has had leadership roles in the growth of the company. Currently, she leads overall corporate administration, marketing and industry relations, services development, human resources, and knowledge management. She has led various strategic initiatives, including the development of ICD-10 services, HIPAA-based security and privacy compliance tools, and online education programs.
Thomas Grove has more than 16 years of experience in healthcare IT. As a principal at Phoenix Health Systems, he provides IT project leadership and consulting services with a focus on ICD-10, meaningful use, and privacy and security.
Contact the Authors
Comment on this Article