Skip to main content

ICD-10 Testing: What healthcare providers need to know

By Carl Natale

Testing is going to make or break your ICD-10 transition. That is when you will find out if your project plan is working correctly.

While there hasn't been a whole lot of ICD-10 testing done yet there are some best practices:

  • Use real medical records to test systems. Make sure you're testing the types of cases you will actually be treating and submitting for reimbursement.
  • Work with your healthcare payers and submit test data that reflects your case load. Don't just test scenarios that match their mappings.
  • Dual coding will help create test data that can be used.
  • Provide documentation that supports your test ICD-10 codes.

The North Carolina Healthcare Information and Communications Alliance (NCHICA) is one of the organizations doing extensive end-to-end ICD-10 testing has published a ICD-10 testing pilot bulletin with good information. The Centers for Medicare and Medicaid (CMS) has just updated its ICD-10 testing checklists for:

CMS lists the following steps for large providers for organizing ICD-10 testing:

Create a Quality Assurance Plan that tracks:

  • internal testing
  • testing of transactions with multiple Trading Partners
  • testing schedule
  • testing results

Trading Partner communication

  • From the list of Trading Partners created in Assessment (task 2.2), identify those that are mission-critical.
  • Determine and document what percentage of mission-critical external Trading Partners that will be used in testing.
  • Mission-critical Trading Partners could be direct submit payers, clearinghouses, vendors (if purchased software), data Trading Partners.

Work with each Trading Partner identified for testing to:

  • establish communication
  • plan and schedule testing
  • determine how many test files can be sent for each transaction
  • obtain a copy of each Trading Partner's Test Plan
  • trade updated Companion Guides (if applicable)
  • Review each Trading Partner's Test Plan and work with vendors to fill in gaps as needed.
  • Having the ability to send multiple test files for each transaction allows any errors encountered to be resolved and verify they are corrected.

Confirm with each testing partner if identifiable data can be sent or whether de-identified test data must be used.

This guidance should be used to address privacy concerns regarding test data usage with each mission-critical Trading Partners.

Determine options for all applicable transaction types if either party is not ready by the regulatory implementation date. Document reasons why, plans to be taken to get ready, and estimated date to be ready.

Also include a back-up plan in the event one party is not ready for production by the regulatory implementation date.

Prepare test system by assuring new code is migrated and test case data is updated.

Create a Test Plan that can be used for each stage of testing;

  • System Testing
  • Regression Testing
  • Performance Testing
  • Privacy and Security Testing
  • User Acceptance Testing (UAT)
  • Level II (including end-to-end testing for each Trading Partner tested with)

Test Plan should track needed information to provide a management report that summarizes the testing results including which items passed and which items failed. Identify volume of success and where failure occurred, and action items to remediate testing failures.

Create test scripts that include:

  • both positive and negative tests
  • defined successful and unsuccessful test results
  • system edit/audit testing (pass/fail)
  • missing elements
  • complex and simple test cases
  • paired transactions that generate an appropriate response transactions for each inquiry
  • testing of reports and data extracts

Test Plan and scripts must include testing that will verify the implementation of current or future regulation or regulation changes, e.g., Administrative Simplification and Affordable Care Act, and should include the following applicable transaction(s):

  • Submit ASC X12 270 transaction(s) and receive a valid 271 response(s)
  • Submit ASC X12 837 claim transaction(s) and receive valid 835 response(s)
  • Submit ASC X12 276 transaction(s) and receive valid 277 response(s)
  • Submit ASC X12 278 transaction(s) and receive a valid 278 response(s)
  • Submit NCPDP X.X retail pharmacy, COB, transaction(s) and receive valid response(s)
  • Receive applicable acknowledgments on all tested transactions. (277CA, 999, TA1)
  • CAQH CORE Operating Rules
  • EFT and ERA Transactions including the timely re-association and resolving late or missing EFT or ERA transactions.
  • Track claims, eligibility, and prior authorization/referrals through system(s) to verify accuracy and identify programming, coding, payment, approval, or denial defects.

Determine if end-to-end testing will be completed in a production-like or production environment. If production-like environment, verify that this environment is a complete replica of production with up-to-date information such as providers, enrollment, workflows, medical policies, and error messages based on new code.

Determine if there is an adopted Errata and if and when it will be included in testing. If there is an adopted Errata, confirm with each Trading Partner that they have implemented the Errata and will the testing to include the Errata changes. If not, determine if retesting will be required retest once they have implemented the Errata.

Perform Level 1 testing activities; review test results, address defects, update Test Plan, and communicate test results on all current and future applicable transactions and acknowledgements.

  • Continue performing Level 1 testing until predictable results have been achieved.
  • Validate each testing scenario is tested and completed.
  • CMS provides the CMS Testing Framework document to define the below types of testing. "

Complete:

  • System Testing
  • Regression Testing
  • User Acceptance Testing
  • Non-functional testing such as Performance and Privacy/Security
  • Performance testing is to ensure the changes implemented have not impacted application speed, stability, and scalability.

Before moving to Level 2 end-to-end testing; complete a minimum of two internal tests working through any defects.

While the checklists will be valuable planning tools, the key part will be communicating with your partners to schedule tests and analyze results.