Y2K: Think you’re ready? Surprises may await you

GAO raises red flag of warning

Besides concerns about how well federal and private payers will handle the Y2K problem come Jan. 1, the General Accounting Office has raised a red flag noting that many providers may not get paid because they have not corrected potential Y2K problems in their own systems.

Even groups that think they have done their Y2K homework may be in for a rude awakening when they learn that the Y2K-compliant guarantee they thought they received from their equipment or software vendor does not mean what they assumed it did. And they may find that by independently testing various software products, medical devices, and pieces of office equipment, they violated their contract, exposing the practice to possible liability. (See related story, p. 157.)

For instance, in one test, some 28% of provi ders had problems submitting electronic Medicare claims. The biggest reimbursement roadblock was the inability of providers to submit claims dated in the year 2000. In order to bill Medicare, claims must use 8-digit dates, with the year being 4 digits. For instance, Oct. 2, 2000, would appear as 10/02/2000.

If you have not already done so, practices are being urged to arrange a Y2K test submission with their Medicare intermediary, using future dates such as 01/01/2000, 02/29/2000, etc.

These problems, combined with the lackluster response to Medicare’s free Y2K training sessions and low usage of its toll-free hotline, have Medicare officials worried that providers are not concerned enough about what could happen once the calendar rolls over to 2000.

For those that want it, Medicare carriers also have Y2K-ready software that is being offered to providers for free or at minimal cost.

Just because you are able to submit electronic data interchanges using a Y2K-compliant 8-digit date does not mean all of your systems are Y2K-ready, warn computer experts.

For instance, in another Y2K test series run by Nationwide Medicare, a subsidiary of Nationwide Insurance Co., in Columbus, OH, some 21% of the claims submitted failed to process on their first try, despite the fact they had been submitted on Nationwide’s own Y2K-certified software. The most common reason for the snafu was that provi ders failed to follow instructions.

However, even after the procedural mistakes were corrected, a significant 3% of provider submissions still crashed, producing claims with dates of service in 1900, 1901, etc., when the dates should have reflected 2000, 2001, etc.

Nationwide’s follow-up analysis found the practices had correctly followed instructions and nothing was wrong with the software, and the carrier concluded the problem had to be with the hardware and/or operating systems of the PCs being used by the providers. Specifically, these providers’ computers were not able to generate dates later than 12/31/1999.