4 Lessons Learned from HIPAA 5010 That’ll Benefit Your ICD-10 Project

It’s a fact: ICD-10 has far more impact and involves far more change to people, processes and technology than HIPAA 5010. I’m of the opinion that much of the work expended and artifacts created during a HIPAA 5010 project - particularly test plans and test cases - will not lend direct value to an ICD-10 project. But I’m convinced that many organizations learned are a lot of 5010 lessons that can be leveraged in your ICD-10 project.

This view was supported by a number of letters to the National Committee on Vital Health and Statistics that shared some lessons learned from 5010 projects. Here’s a summary of these lessons I gleaned from two of these letters. I recommend reading these letters - see below - to learn the authors recommended approach for addressing each lesson learned.

1. Being “ready” was an essentially meaningless term
Vendor readiness was largely communicated via self-reporting and there was no “true” definition of vendor readiness in the healthcare community

2. Successful testing was a misnomer
Most testing was quantitative and not qualitative; too high level and not representative of the real world. There was a profound lack of transparency between all the stakeholders: providers, payers, clearinghouses and vendors.

3. Dearth of information and guidance
Most information publicly available and shared between constituents was informational and not pragmatic. There seemed to be a number of Chinese Walls erected between payers and providers, vendors and end users, etc. Everyone involved needs to understand why the changes are critical and where key business partner’s stand in the compliance timeline.

4. It wasn’t a “technical” problem with a solely technical solution.
It’s easy to always label challenges involving software as purely technical problems. But ICD-10, even more so than 5010, will require extensive collaboration between all the constituent stakeholders.

Those charged with implementing ICD-10 have a unique opportunity to learn from the lessons of the 5010 implementation. It’s up to those leading and managing ICD-10 projects to understand these lessons and demonstrate an approach to avoiding their repetition. 

References
“ICD-10: Avoiding the 5010 Pitfalls” Holly Louie, CHBME, June 20, 2012 http://www.ncvhs.hhs.gov/120620p36.pdf 

"5010 – Lessons Learned”, Holly Louie, CHBME, June 20, 2012
http://www.ncvhs.hhs.gov/120620p35.pdf

Identifying and Categorizing ICD-10 Test Cases - 6 Key Elements

Developing the test cases to verify and validate your ICD-10 remediation efforts is no trivial task. Where do you start? What are the key elements needed? How can you leverage certain tests across different areas? How do you know when you have covered all the bases? It’s easy to get bogged down and overwhelmed by the shear depth and breadth of testing requirements.

As someone smart once said “The journey of 1000 miles begins with a single step.” The purpose of this post is to provide you with information on creating a map to guide you in making that first step toward developing your ICD-10 test cases.

Six Key Elements

Type of Test - Describes the general area addressed by the test case. Examples include:

Pre-authorization required
Claim Processing – DRG pricing
HCC Risk Assignment
Actuarial Analysis – High Cost Conditions
Pre-existing condition
Other Party Liability Claim

Product or Line of Business- Identifies the specific product or line of business to which the test is targeted. Examples include:

Commercial
Medicare
Medicaid
Dental
HSA

Type of Transaction - Defines the type of transaction involved with the test case? Examples include:

Institutional Claim
Professional Claim
Dental Claim
Pre-authorization
Claim Status Inquiry

Key Test Variables - Lists key data elements/variables involved with the test.  Examples include:

Procedure Code
Revenue Code
Diagnosis Code
Provider Category
Provider Type/Specialty
Date of Service
Date of Discharge
Place of Service
Bill Type

Exception Conditions- What are the exceptions that should be anticipated for the specific test case? Examples include:

Accumulator Maximum Reached
Pre-existing condition detected
Claim denied due to benefits
No pre-authorization on file
Claim out sorted in workflow

Verification & Validation Areas- What data elements, variables and outcomes are associated with a successful test? Examples include:

Limits
Deductible
Coinsurance
Copay
Claim Status

By creating a grid with 6 columns and collecting the above information for each test, you’ll have assembled the important, high-level information you'll need to triage and flesh out the details of your test cases - before diving into the details of individual tests.

Testing ICD-10 is NOT like Testing 5010: Enabling Tests vs. Logic Tests

Many people talk about leveraging their 5010 test plans and scripts for ICD-10 – and I continue to have a hard time understanding how 5010 brings significant value to the ICD-10 testing challenge. My experience shows that ICD-10 testing will be much more pervasive, complex, clinically-based and, in many cases, may not involve as much vendor/clearinghouse dependency as testing 5010.

See my earlier post on this topic: Leverage Your 5010 Testing for ICD-10 Testing? I think not…

The crux of the difference lies in the number, depth and breadth of clinically-based logic test cases that must be developed.  These “logic tests” will be more difficult to define, execute and evaluate than the “enabling tests” typical of 5010 testing.  By “enabling tests” I mean validating changes made to accommodate the longer ICD-10 code field and to be able to differentiate between I-9 and I-10 codes.  The Y2K remediation was rife with enabling tests.

Simple Data vs. Real-World Data

A key challenge will be bridging the huge gap between the simple ICD-10 test data needed to perform the enabling tests and the more complex, real-world data needed to effect the logic tests. Here are a few thoughts and ideas on logic test areas:

Establishing Clinical Profiles and Episodes of Care

Diagnoses codes are a key element used to assemble patient profiles and determine when episodes of care start and stop for certain conditions like breast cancer, diabetes, hip fracture, congestive heart failure, etc.

DRG, HCC and Other Groupings

Many of these ICD-related data points exchanged between providers, payers and 3^rd parties have yet to be formally updated for ICD-10.  And many organizations are dependent on 3^rd party pricers, code assignment and chart coding services that must be included in test scenarios.

Workflow

Many expensive and/or limited procedures related to sterilization, TMJ, reproductive disorders and fertility, cataract surgery, maternity claims processed under regular hospital benefits, etc. are based on the identification of specific diagnosis code(s) and will require in-depth test case preparation.

Pre-authorization/Referrals & Pre-Existing Conditions

Inaccurate matching, denials and/or delays can have a large impact on financial neutrality and patient service.  Matching claims with either or both I-9 and I-10 codes before and after the implementation date will require a number of detailed test cases.

Wide Variety of Billing and Payment Processes

Physicians, Hospitals, Ambulatory Surgical Centers, Ancillary Providers, Alternative Providers (chiropractors, acupuncture, etc.), Dental and Pharmacy all have unique processes and transactions impacted by ICD-10

For more information on testing ICD-10, see these earlier posts:

ICD-10 Application Integration Testing Considerations & Tips
 
11 Areas to Consider When Testing ICD-10 Impact to Payer Business Processes

Validating and Verifying Your ICD-10 Remediation Efforts

6 Considerations for Verifying ICD-10 Operational Neutrality

Collaborating Toward ICD-10 Compliance: 10 Ideas

A little collaboration could go a long way toward helping providers and payers work through some of the more challenging aspects of their ICD-10 implementations. This collaboration might originate through vendor organizations, user groups, local chapters of HIMSS or AHIMA associations and/or other mechanisms.

While some providers and payers may feel that a collaborative relationship with their peers and competitors might put them at a competitive disadvantage or expose weaknesses, I believe there are some opportunities for organizations that take a collaborative approach to their ICD-10 implementation.

The following are some areas of opportunity where a collaborative association of two or more organizations working on the ICD-10 mandate may well benefit: 

1. Identify tools that could be built or purchased and made available to group
2. Identify services for which the group might negotiate pricing for their common benefit
3. Share Lessons Learned 
4. Discuss provider outreach strategies
5. Collaborate on and share education and training plans/ materials
6. Share staff training strategies
7. Develop a list of vendors each participant is using or may use and discuss strategies for vendor interaction, negotiation and compliance
8. Share general remediation approaches for databases, logic/processes and reporting
9. Identify criteria for validating GEMs, reimbursement maps and development of purpose-built maps
10. Share testing strategies 

Keep in mind that collaboration does not have to be time-consuming or create risks for participants – nor does it have to be a permanent arrangement. Try it, you may like it.

Developing a Database Remediation Strategy for Your ICD-10 Project

A database remediation strategy informs and guides the data modeling solution intended to bring consistency, ensure comprehensiveness, and provide strategic direction to your ICD-10 data modeling approach. If your organization has any internally developed applications and/or office applications, you should consider developing a formal database remediation strategy before your embark on updating your internally-developed applications to accommodate ICD-10.

Why do you need a Database Remediation Strategy? 

1.   ICD-10 codes have a different structure and composition (syntax) than ICD-9 codes. 

2.   The overlap between ICD-9 and ICD-10 codes that make it impossible to distinguish a specific code set (ICD-9 or ICD-10) on inspection. 

3.   Determining the type of code set depends on the data of service (professional claims) or discharge date (institutional claims) 

4.   The ability to access transaction history as ICD-10 codes become mixed with ICD-9 codes must be accommodated for the immediate period before and after the implementation date; and also to support mandated audit periods of up to 10 years. 

5.   Most organizations have a number of systems to remediate and some databases will require remediation in advance of the compliance deadline.    

What should your Database Remediation Strategy include? 

1.   A means to use data type and/or code attributes to facilitate logic for searching and matching single codes and ranges of codes.

2.   Use of a code indicator or prefix to discretely distinguish between I- 9 and I-10 codes. 

3.    Include attributes to facilitate accurate identification of professional vs. institutional processing logic and to provide the fidelity necessary for analytic reporting.

4.   Ability to capture both I-9 and I-10 codes to enable analysis and reporting.  Include attributes to identify how the code originated (native, converted GEM, converted custom, etc.,) translation version, potential duplicate mappings, confidence level associated with discrepancies between forward and backward mapping relationships. etc.

5.     A means to track remediation strategy used across multiple systems and scenarios with all applications using the same code set to ensure enterprise-wide consistency, compatibility and auditability. In addition, consider an approach for building a brand new data structure containing ICD Code attributes vs. extending existing structures.

Hopefully the above post provides some ideas for developing a database remediation strategy.  Stay tuned for a future post on topics related to ICD-10 logic remediation strategies.