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.This article will not go into detail explaining the reasons or pros and cons of implementing ICD-10 / 5010. There are plenty of resources covering those topics. These mandates are coming whether anyone wants it or not. This article focuses on the impact on computer systems implementing ICD-10 / 5010 and compares that impact to other wide-scale IT initiatives.
NPI as a Recent ExampleThe 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:o Multiple providers use the same NPI
o Payers cross walk NPI to link to older reference numbers
o 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)
o Clearinghouses strip off the NPI to accommodate payers who do not handle itSans 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.It seems simple enough to add a new field to a provider table and print it on a form or stick it into a file. Information Technology often seems simple at first. When one starts to drill in to the growing list of exception cases with any type of change, it always gets more difficult.The reality was NPI had quite a bit of “scope creep”. Most claim generating systems had some form of decision matrixes that put the correct legacy code in the claim. These matrixes had to be updated for NPI and still do what they did before. Claim forms had to be modified, file structures updated and everything distributed to the users that needed it.These kinds of changes are common-place in IT, but they still have to be accommodated. They also have expenses and resources tied to them. Those expenses and resources are often underestimated, especially when the project starts off as “add a new field to a provider table and print it on a form”. Quality assurance and testing cannot be bypassed either. If the change involves third parties, it takes even longer. NPI implementation was not a complex change by any degree, but did require effort. Enough effort to extend the deadline for a year.To date, we have not seen any estimates on the cost of NPI implementation. Without question that number is several thousand dollars per practice. A higher price than most people estimated.Compare ICD-10 / 5010 System Changes to NPIICD-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 in the soon-to-be-affected computer systems: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. Regardless of the database technology used, increasing the number of records by a factor of nine in an often-queried-table is going to have an impact on many computer systems.
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. The changes are in the form of:o Codes Added / Changed / Deleted
o New Elements
o Segments Added / Deleted
o Name Changes
o Increased Sizes
o Loop Changes
o Elements Added
o Segments Added / Deleted
o Situational usage changesMany 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.5010 changes focus on NPI and ICD-10 -The majority if the field changes in the 5010 are related to NPI issues that could not be handled in the 4010. 4010 flat out does not have space needed for the ICD-10 codes. This single fact more than anything else drives the 5010 deadlines.What Will it Take to Get There?ICD-10 / 5010 can be done. There is no question about this. The question becomes one of time and resources. On a micro level, some estimate a practice will spend $87K to $2.7M to convert. These are not all direct costs. They are spread across from software fees, training classes, inefficiencies of learning curves and delayed revenue cycles.On the macro side, 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.Considering the US spent approximately $500B on Y2K, we do not think the total cost will come close to that. On an individual company basis though, the cost of integrating with ICD-10 / 5010 may be very close to what they spent on Y2K.Whatever estimates one chooses to believe, the fact is the healthcare industry will have to spend heavily to meet the goals of January 1, 2012 for the 5010 standards and October 1, 2013 for ICD-10. No one will be able to implement these changes for free.Community Health Centers will be hit hard. If there is a payer that will require first and timely adoption of ICD-10 / 5010, it is Medicare and Medicaid payers. Community Health Centers (CHCs) receive a large portion of their money from these payers. They also bill Medicare and Medicaid a higher percentage than most other types of practices. CHCs also make much less money. While the majority of these CHCs operate as non-profits, most do not even get to a financial breakeven point. As the number of uninsured in the nation increases, the burden of care is shifting more and more to the CHC market.The operations making the least money, and having a heavier burden, will have to meet the new standards with greater degree of accuracy than their private practice and hospital counterparts. Not a fair deal, but it is the cards they are dealt. Perhaps the National Association of Community Health Centers (NACHC) can lobby for some additional grant money for to meet these needs.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.With NPI as a recent example, we can expect the multiple interpretations from multiple payers to cloud the waters even more. Any company that is now on the 4010 transaction set, needs to act soon to have as little payment disruption as possible.