Where the ICD-10 and HIPAA 5010 Rubber Meets the Road – The Impact on Computer Systems

July 9, 2009 - PRLog -- No one likes an unfunded mandate. One is told to do something by a higher authority but not given any resources or budget to implement. Everything else your organization has to do, your organization still has to do.  Someone has to come up with the needed resources and pay.

Healthcare IT has recently completed one such mandate – the National Provider Index (NPI). There are two more unfunded mandates coming down the pipeline that make NPI look simple by comparison. These are the ICD-10 (International Statistical Classification of Diseases and Related Health Problems, Version 10) and the Health Insurance Portability and Accountability Act (HIPAA) 5010.

NPI as a Recent Example

The NPI appears to have been a good long-term idea. Providers have so many identifying numbers (e.g. UPIN, SSN, EIN, OSCAR) and different payers require different combinations of them, why not just create a single number to replace all the others? It sounds easier and more efficient. After all, one of anything is easier to manage than twelve.  While Medicare has a good job adopting the NPI number, many others have implemented NPI to a lesser degree. Here are some issues still revolving around NPI implementation:

•   Multiple providers use the same NPI
•   Payers cross walk NPI to link to older reference numbers
•   The existence of department-based or location-based NPI to cover everything for all providers in a physical location (not the original intent of NPI)
•   Clearinghouses strip off the NPI to accommodate payers who do not handle it

Sans Medicare and Medicaid, NPI use and benefits are questionable. One clearinghouse summed it up as “it is just one more number to deal with on top of all the others”.

A month before the initial deadline for NPI implementation, The Centers for Medicare & Medicaid Services (CMS) extended the deadline by a year, from May 23, 2007 to May 23, 2008. CMS realized few payers, providers and others were ready. The top reason organizations were not ready was because their computer systems were not ready.

Compare ICD-10 / 5010 System Changes to NPI

ICD-10 and HIPAA 5010 need to be spoken of in conjunction with each other. If we did not have the ICD-10 mandate, 5010 would not be a consideration. 5010 has to come first to allow the claims to accommodate the new ICD codes. If nothing else, it needs to accept the new size of the code. Here are a few facts about the ICD-10 / 5010 that need consideration:

The number of ICD codes increases from 17,000 to over 155,000 – Every computer system has to provide ways for the users to select the item they want. How the system does this for a list of 15 items is different from a list of list of 1000 and is different from a list of 155,000.  Many Practice Management (PM) and Electronic Health Records (EHR) applications will have to change the user interface and the behind-the-scenes-architecture to accommodate the increased number.

A constant mantra in the software industry is “storage is cheap”. Storing 155,000 records is not a huge issue. Retrieving them may be. There are several systems based on Access, FoxPro, Paradox, Dbase and a flurry of other technologies popular ten or more years ago. These systems work fine today. Tables that big in older technologies are prime targets for creating corrupted database files. Systems that use SQL Server and Oracle do not escape potential hazard. Inefficient queries often reveal themselves after a big increase in data. ICD tables are often a big component of any query JOIN.

Payers will cross-walk ICD-10 to ICD-9 – Software applications will go through a lot of trouble and effort to accommodate ICD-10 changes only to find out that the payers themselves do not use them yet and cross-walk everything back to the ICD-9 codes. On top of this, the claim files will have to be adjusted to accommodate their cross-walking. The same issue happened with NPI. Several payers required non-standard data in the claim files. Systems put the NPI in along with the legacy identification numbers in loops and segments not intended to hold this data. This was later used to validate their cross-walking. In theory payers should not do this. In practice they do. The IT systems end up having to accommodate because without doing it, clinics wind up not being paid.

Some ICD-10 codes are specific to which encounter (e.g. first visit, final visit) – Everything about the related codes will be the same except when this code is intended to be used. One code is specific to the first encounter. Another code for the same diagnosis is only to be used on subsequent encounters. Not using the correct code may result in claims being rejected. PM and EHR applications will require changes in business logic to accommodate this. The visionaries will be able to apply the rules to the codes themselves. Regardless if the program source code is hacked together or utilizes current OOP principles, this is a feature does not exist in the ICD-9 as it does with the ICD-10.

ICD-10 codes are much more specialized – Providers have contracts with payers detailing how much is paid for a procedure. ICD codes are a component of these contracts. Any application generating a claim has contracts with the payers somewhere in the data structures. This contract data is needed to calculate how much money to put on the claim files. Not all payers pay the same rate. They also have different exception conditions. More specialized codes will result in more specialized contracts. One can expect new rates for the new codes and more exceptions. For the computer systems, the question becomes will their current contract functionality will accommodate 155,000 potential rates.

ICD-10 codes have combination codes - The goal is to group cause and manifestation of the diagnosis (e.g. unequal limb length (acquired), left humerus). While this is a trend in the ICD-9, ICD-10 takes it further. The concept is that the providers go through a decision process where the chosen ICD code is the end result of those decisions. Many today use the ICD codes as a simple list. While the code is designed to navigate the provider through the code selection process, many of the applications in use today are not designed to do it this way. Hopefully the visionaries rule on this and change their applications to reflect the intended decision process.

In one 5010 file there are over 700 changes from current 4010 standard - The 4010 format 837 file has just over 2000 individual data elements to be addressed. There are 700+ changes to this one file.

Many of these changes are simple and will be easy to implement. New segments, elements and codes are always open for interpretation about what is to go there. The same goes for any type of situational usage. One should expect payers to provide ample, and sometimes conflicting, opinions on what goes where.

700 modifications change a significant percentage of the 837 claim file. Any change of this magnitude should not be taken lightly. For many software developers this will be the largest change they have undertaken for some time.

The changes are not on an island - It is one thing to change a computer system for internal use only. ICD-10 / 5010 have changes that have to be done in conjunction with numerous third parties (e.g. payers, clearinghouses). Creating computer systems with third parties takes longer, requires more testing and much more management coordination.

What Will it Take to Get There?
Some estimate the healthcare industry will spend somewhere between $5.5B and $17.5B to make the changes. A premier accounting / consulting group is cautioning that we might spend more on ICD-10 / 5010 than we did on Y2K. At least the ICD-10 / 5010 changes are real.

ICD-10 / 5010 are no small endeavors by any measure. There are many changes to many computer systems that need to be made. Early and thorough planning are fundamental success criteria for any systems project. These changes require plenty of both.

# # #

To read the full article please visit:

http://decideinfotech.com/whitepapers/whitepapers.aspx
or
http://decideinfotech.com/whitepapers/Executive%20Briefin...

Decide Information Technologies LLC, is as an SDVOSB. Decide IT brings a skill set of software and information technology knowledge. Decide IT also provides these services specifically to the healthcare market.