By now, you've heard the warnings many times: On Jan. 1, 2000, computers around the world will stop doing calculations that involve dates, or will simply miscalculate them. Some say that the so-called “year 2000 problem” will be limited to businesses and government agencies that use large mainframe computers. Others warn of a meltdown that will affect everyone who uses a computer. Here's what the fuss is about and what you can do to minimize the impact on your practice.

A brief history

Punched cards were used to enter data into early computer systems. Since each punched card contained just 80 columns of data, programs were written that conserved space by entering only the last two digits (instead of four) to designate the year — for example, 68 instead of 1968. Storage space inside mainframe computers and early personal computers (PCs) was limited, too, so programmers continued to use the two-digit year format for dates, both in developing software and in storing date values in hardware. The causal relationship between this strategy and the year 2000 problem is very complicated, but here's a simplified version of the effect: To calculate a patient's age using two-digit years, a computer program would subtract the patient's date of birth from the present date: for example, 98 – 68 = 30. In the year 2000, however, this calculation would be 00 – 68 = −68. You see the problem.

The mainframe computers of the 1950s and 1960s and the PCs of the early 1980s have been replaced several times, but many organizations have been reluctant to abandon crucial computer programs that still work and that would cost a small fortune to replace. For years, computer manufacturers responded by developing new machines that would allow buyers to run their old “legacy” programs. As the end of the century approached and the cost of computer memory and disk storage dropped to a small fraction of what it was in the early days of computerization, programmers began developing new programs that use four-digit years. Now it's very difficult for any organization to tell which of its programs are “Y2K compliant” and which will begin misbehaving a year from next January.

Four problems are making it tough for organizations to update old programs to accommodate four-digit years:

1. Lots of legacy programs are still in use, and many of them have been revised often over the decades.

2. The original programmers often poorly documented the programs they designed. To figure out how one works, today's programmer has to painstakingly analyze each of possibly thousands of lines of code.

3. Many programs interact with other programs. Changing the way one runs could affect the way others run.

4. Programmers today write few programs in the computer languages used in the 1950s and 1960s. As a result, few people have the skills to revise the old programs.

What medical practices can do

The year 2000 problem is most likely to affect older programs that are written in FORTRAN, COBOL and other older languages and that run on mainframe computers. For that reason, your hospital or insurance company is more likely to be affected than your practice. Your risk is lower if your programs run on stand-alone or networked PCs, but some older PCs have demonstrated hardware and software problems.

Keep in mind that the implications of the problem for your practice could involve more than just calculating patients' ages. Many of the calculations that keep your practice running could be affected: time since a patient's last visit, date when a patient's next visit should be scheduled, date when a patient's next screening test should be performed and date when a payment is due. (Do you know what your aged accounts receivable will look like in early 2000?)

You should take steps now to ensure that your computer system will be able to accurately process date and time data from and into the 21st century and that it can correctly do calculations involving the years 1999 and 2000 and leap years.

Begin by asking your computer and software vendors to prove to you that your system is safe (see the tips below). You may also wish to ask your attorney to draft a letter to the vendors making it clear that you will hold the companies liable if their assurances of year 2000 compliance prove incorrect. If a software upgrade is required to make your system compliant, it should be covered by the maintenance fees you pay your vendor. Contact your vendor now. Many have already booked appointments months into the future.

Testing your system

If your vendor is no longer in business, you may want to take the following steps to determine whether your system has a problem. Computer experts point out that these tests pose their own risks to your system. If you have software applications that perform automatic functions based on the computer date, disable them before you conduct these tests. And, of course, you should back up your data.

• Try to create a record for a patient with a birth year of 2001. If you can enter all four digits for the year and you get a message that the birth date is invalid, you're probably safe. If you enter all four digits but the computer calculates the patient's age as 97, you may have a problem.

• Set your computer's internal clock's date and time to 12/31/1999 and 23:59:50 (or 11:59:50 p.m.). The computer should continue running after the date and time change to 1/1/2000 and 00:00:01. If that works, try shutting the computer down and restarting it before you change the clock back; make sure the clock hasn't reset itself during the restart. If you can't get the computer to make the transition to the 21st century and stay there, you may have a problem.

• Set the internal date to 2010 and see what happens when you register a patient born in 1991. The computer should calculate the patient's age as 19.

• Experiment with other situations involving combinations of dates. For example, set your computer's date to sometime in December 1999 and post a few charges to test accounts. Produce insurance claims for the test accounts. Change the date to January 2000. Post payments and contractual adjustments against the charges. Then produce patient bills for the test accounts. The system should post transactions and calculate dates correctly.

Despite good test results and assurances from your vendor, a good backup system is essential. You should back up all the files on your computer system at least once a month. You should also do an incremental backup of the files that change each day. If your computer system stops working, you might be able to convert the data to a new system. Finally, maintain a paper backup of source documents that support all charges, payments and adjustments, organized by date. In the worst-case scenario, you can use these records to continue billing manually and reconstruct your files on a new computer system.

If you determine that your system is not Y2K compliant and your vendor can't correct the problem, don't waste time trying to find an expert programmer to fix it. Capable programmers are hard to find because most are helping large corporations fix their systems, and they charge premium fees. Instead, start shopping for a new computer system. You've got a little more than a year to get ready for the year 2000.