Most healthcare organizations have modified or customized their billing applications to meet their own unique needs in regard to payer mix, clinical programs, or provider-based billing arrangements. While these customizations are fine for their intended purposes, they nonetheless pose rather large obstacles to the ICD-10 code conversion process.

There is still a misconception among many organizations that vendors are chiefly responsible for ICD-10 preparation. In truth, vendors are only one piece of the puzzle. While they indeed must alter products to accommodate ICD-10, they typically are not liable for any of your in-house customizations. Furthermore -- and perhaps needless to say -- vendors are not the ones who will suffer claims rejections starting Oct. 1, 2013, should your organization not meet the ICD-10 implementation deadline successfully.

To mitigate cash flow risk throughout the ICD-10 transition, organizations must be able to identify any customized data fields that either directly or indirectly relate to diagnosis codes. Customizations frequently appear in applications such as dictionaries, charge entry screens, code scrubbing logic, claim form logic, and reports. But these applications often are only the beginning.

For better or for worse, tracking the location of diagnosis data fields within customized applications depends as much on relationships as on spreadsheets. The very first step, in fact, is to ramp up internal communications where necessary to make sure your IT shop is in tune with your billing shop. IT staff must understand existing revenue process and flow; billing staff are pivotal for accurately identifying areas of ICD-9/ICD-10 contact.

Billing staff are in the best position, for instance, to identify those payers with the largest impact on the revenue stream. Your IT staff will need to assess and test electronic data interchange (EDI) transactions with these payers before those with smaller revenue footprints. Often -- especially in situations when the billing and IT staffs operate in relative isolation -- it's helpful to establish the ICD-10 project management team as a liaison.

Once the political groundwork is smooth, you can begin looking for actual applications that involve diagnosis codes. Obviously, highest priority goes to those systems that most closely affect patient health and safety. Interface engines should be the next area of focus, followed by billing systems.

In each case, walk through the entire data cycle. Start from the moment a patient encounter is scheduled and a presenting diagnosis is documented. Map all incoming and outgoing diagnosis-related data fields, and determine whether each piece of data is supplied in-house or by a vendor. In other words, the project management team must identify whether each data field is:

•    Incoming or outgoing; and
•    Vendor-sourced or internally-sourced.

This will provide an overall assessment of where diagnosis data resides within your systems, how it gets there, where it moves, and who is responsible for each individual piece of it.

Remember that in addition to evaluating electronic data fields, you must also take into account data that still exists on paper. Even paper forms present conversion challenges because they very often are scanned into one electronic system or another. At each point, those optical scans must be able to accommodate ICD-10.

While completing your overall assessment, pay particular attention to each place within data flow where diagnoses can be input by either a user or another system. Among those that bear scrutiny: charge entry, scheduling, encounter forms, fee sheets, and hand-held applications. You will be responsible for modifying any data fields you have identified as originating from an "internal" source.

[Tip: Use this opportunity to begin keeping a continually-updated list of all IT customizations within your healthcare organization. The fact that this is seldom done is a big area of weakness within the industry; this is a perfect chance to offer all the work you're doing now for future benefit. Whether the list is manual or electronic doesn't matter, but it can be helpful whenever applications are upgraded. Upgrades always carry the potential to ruin customizations, but a running list makes it much easier to compare "before" and "after" any uploads to ensure all internal modifications still function as desired.]

The process of identifying, testing, and altering systems to accommodate ICD-10 will be even more exhaustive for healthcare organizations with homegrown systems, of course. For these groups, it is imperative to evaluate the level of internal support available for the transition, and how much responsibility must be shouldered internally for EDI programming. Once that evaluation takes place, three options are available:

1)    devote the resources necessary for serious programming upgrades;
2)    appropriate the budget to assess, purchase and install new off-the-shelf vendor software; or
3)    outsource EDI transactions if budget and resources limitations thwart the first two choices.

By contrast, vendor-supplied systems that offer little opportunity for internal customization (many claim scrubbers, for example) will require you to rely mainly on the vendor for ICD-10 adaptations. Nevertheless, be careful not to downplay the time it will take your organization to thoroughly test all vendor updates.

Coordination and testing, in fact, will be the most resource- and time-intensive aspect of the ICD-10 transition for most healthcare organizations. Make sure to build time into your timetable to contact each payer and vendor to coordinate an ICD-10 acceptance schedule. Plan to test all EDI transactions --those that involve customized applications and those that involve vendor-supplied data -- in order to minimize the potential for claim rejections after the ICD-10 compliance deadline.

Scott Kelly is a Senior Management Consultant with Culbert Healthcare Solutions.