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:
Lots of legacy programs are still in use, and many of them have been revised often over the decades.
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.
Many programs interact with other programs. Changing the way one runs could affect the way others run.
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.
HCFA: Y2K problems won't stop Medicare payments
HCFA is one of the federal agencies facing the “largest challenges” in making its computer systems year 2000 compliant, says John Koskinen, chair of the President's Council on the Year 2000 Conversion. But the agency is telling providers they shouldn't worry about the effect of the millennium bug on Medicare payments.
All federal agencies have a March 31, 1999, deadline for making their information systems year 2000 compliant, but HCFA has set its own deadline of Dec. 31, 1998.
Even in the event of an unforeseen problem in January 2000, “the money will continue to flow,” says Joe Tilghman, administrator of HCFA's regional office in Kansas City, Mo. The agency is creating a backup plan to ensure that all submitted claims will be processed — even if that means writing checks by hand.
“We aren't leaving anything to chance,” says HCFA Administrator Nancy-Ann Min DeParle, quoted in the Aug. 3 Washington Post. “We are developing contingencies, and I'm personally managing this within the agency. There is no more serious concern.”
Once HCFA's year 2000 updates are in place, Tilghman says, physician practices will be able to test their billing systems against those of Medicare carriers. Testing should be available by April 1999.
Tilghman also urges practices that work with billing companies to ensure that the vendors' systems will be year 2000 compliant.
For more information on HCFA's efforts to deal with the millennium bug, visit the agency's year 2000 web site, http://www.hcfa.gov/y2k/default.htm.
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.
Tips for writing to your vendor
The most straightforward way of determining whether your computer system is year 2000 compliant is to contact your vendor. The following tips are developed from sample letters included in a new AAFP monograph on the Y2K problem (see the reading list for details about how to obtain the monograph):
Do it in writing and ask for a written response.
Do it now; the Y2K clock is ticking.
Provide details about your system.
Explain how a malfunction will affect your practice.
Set a response deadline.
Ask for the name of a person you can contact with questions.
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.
The following publications provide more detailed information about the year 2000 problem. Numerous web sites are also devoted to the issue, including http://www.year2000.com.
“Double Zero.” Celko J. 1997;22(7):89-95.
Family Physicians and the Year 2000: Preventive Medicine for the Millennium Bug. Kansas City, Mo: American Academy of Family Physicians; 1998. AAFP members may obtain a free copy of this monograph by calling the AAFP Order Department at 800-944-0000 and requesting item 710. A shipping and handling charge will apply. Nonmembers may purchase copies for $10 each. The monograph may also be downloaded from the AAFP web site at https://www.aafp.org/fpnet/y2k.
Finding and Fixing Your Year 2000 Problem: A Guide for Small Businesses and Organizations. J. Feiler. Boston: AP Professional; 1998.
Managing '00: Surviving the Year 2000 Computing Crisis P. de Jager and R. Bergeon. New York: John Wiley & Sons; 1997.
Time Bomb 2000! What the Year 2000 Computer Crisis Means to You! E. Yourdon and J. Yourdon. Upper Saddle River, NJ: Prentice Hall; 1998.
The Year 2000 Software Crisis: Challenge of the Century W. Ulrich and I. Hayes. Upper Saddle River, NJ: Prentice Hall; 1997.
Year 2000 Solutions for Dummies K.C. Bourne. Foster City, Calif: IDG Books Worldwide; 1997.