The Year 2000 and the Medical Office: Diagnosis and Prognosis

Within the next 16 months, you're going to get tired of hearing about the "Year 2000 problem" - if you aren't already.

By many estimates, the health care industry has been a relative latecomer to awareness of the problem. "Several recent studies by the Gartner Group put health care near the bottom of heap, just above the federal government, in Year 2000 progress," according to Joel Ackerman, executive director of the Minnesota-based Rx2000 Solutions Institute, a nonprofit organization aimed at increasing awareness and action within the health community. "Virtually every other industry has higher level of activity."

The problem, known by its shorthand designation as Y2K, is simply defined but not easily solved. The underlying assumption of computer programming from the 1950s until the early '90s was that dates could be shortened to the last two digits of the year, e.g., 1990 would be stored in a computer as 90. Initially, the decision to use two-digit year designations appears to have been an effort to save two columns on the punch cards that were used to enter data. Eventually, it became such a commonplace practice that no one questioned it until the late 1980s, when some programmers began to notice that the "19" in front of the year digits would not apply forever.

When the clock passes 11:59:59 p.m. on Dec. 31, 1999, the calendar will show the date to be Jan. 1, 2000. But for computers that have not been reprogrammed, the new date will be Jan. 1, 1900. When that happens, a world that has become totally dependent on the output of those computers could be thrown into chaos.

Databases may be corrupted or destroyed. Billing records may be voided. Births may be treated as future events. Insurance policies may be canceled. Claims may be denied. ATMs may shut down. Checks may bounce. Premium payments may be lost. Invoices and accounts receivable may vanish. Renewal notices may not be mailed. Auto policies may be voided because there are no guidelines for drivers who are minus 70 years old.

The problem is especially acute in the health care industry. The Rx2000 Solutions Institute notes on its Web site, "The health care system relies heavily upon dates and time intervals. Care plans, dosages, lab results, reminder notices, expiration dates...all depend upon accurate calculations."

"Health care has some unique issues, some of them potentially life-threatening," says Ackerman. "A lot of them have to do with the quality of care."

Ackerman cites the case of a hospital in the United Kingdom that had to shut down its surgeries because a computer reported it was out of sterile swabs. "They had a full supply of swabs," he notes, "but they had a '00' expiration date and the computer thought they were 98 years out of date!"

A simple problem, such as how long a patient has been in the hospital, could suddenly become a mathematical nightmare. For example, a patient admitted on Dec. 30, 1999, and discharged two days later could be billed for a 99-year stay.

Complicating the problem is the enormous variety of computers and software in use throughout the economy in general, and the health system in particular. Insurance companies and hospitals depend on large mainframe computers, many of which run customized software. Service bureaus and medical groups generally rely on work stations, which are more powerful than personal computers but smaller than mainframes. Physicians use PCs or workstations for record-keeping and billing, relying on commercially available software or on customized programs provided by hospitals or managed care organizations. Each of these vehicles presents a unique set of challenges to programmers trying to find and eradicate the so-called millennium bug:

• The software running on mainframe computers consists of hundreds of thousands of separate instructions, many of which may refer directly or indirectly to dates. Each of these instructions-known as lines of code- must be analyzed and tested against one another to ensure that no date glitches develop. As problems are identified and fixed, the revised lines of code must be tested to ensure that they cause no unforeseen problems.

• Work stations use powerful, high-speed chips with many instructions permanently built in. Older versions of those chips...and the software that depends on them...need to be individually tested. If they are not "Y2K compliant"- meaning that they correctly recognize four-digit dates beginning with 2000- they need to be replaced.

• Personal computers contain a "real time clock" that may not recognize 2000 as a valid year. In addition, the BIOS...Basic Input Output System...chips may not be able to handle four-digit dates, and the operating system and applications software, such as billing or database programs, may not be properly configured.

Generally, computers and software sold since 1996 are assumed to be Y2K compliant, but that isn't always true. Earlier this year, for example, Microsoft found to its embarrassment that its Windows 95 operating system, which the company previously had said was Y2K compliant, needed a "patch" to solve some date-related problems. Even brand-new, off-the-shelf systems and programs need to be tested to ensure compliance.

"Some of the computer vendors are working on solutions," says Maryann Szostak-Ricardo, a consultant and member of AMA ConsultingLink, a national network of attorneys and consultants credentialed by Chicago-based AMA Solutions Inc. "My concern is that not all physicians are getting an upgrade. Some of them are working with dated software that hasn't had an upgrade in years."

Szostak-Ricardo, who is president of The Ricardo Group in Gardena, Calif., adds that many service bureaus are "mom-and-pop operations using proprietary software, so there's no way of knowing whether or not it will handle the date change."

Simply making sure that systems are currently compliant is not enough to prevent a millennium disaster. Information that has been stored under older versions of programs that have been upgraded may suddenly become inaccessible in the year 2000, so testing must be broadened to make sure that nothing is lost when the century changes.

For example, patient records entered into an older (or "legacy") version of a database program may have two-digit date fields that won't respond to a date ending in 00. And, because these records are not accessed every day, the problems may not be noticed for months, or even years, after the beginning of the millennium. If a patient record is entered in 1998, but the patient is not seen again until 2001, the older records could easily be lost.

Not all Y2K-related problems are as obvious. Programmers recently have been calling attention to so-called embedded systems- chips that operate medical devices but do not necessarily display a date. According to Ackerman, many of those chips have date instructions programmed into them and could fail when the calendar moves ahead to the next century.

"The majority of devices are not going to have any problem," he says, "but we don't know which ones will. Until nine months ago, the prevailing thought was that if a device did not have the ability to display date or time or was not doing interval calculations, it was OK.

"But that view is changing because many devices are made with general purpose chips. You could have the same chip in a Ford or a defibrillator, and that chip may have programming in it that isn't taken advantage of in the medical device. It could still cause a lockup," he added.

In a worst-case scenario, Ackerman says, not only will medical devices fail, but public utilities that depend on computers may not be able to delivery power supplies to hospitals and clinics. "Most physicians are trained in the use of equipment, not in 'hands on' medicine like the old-style, pre-electric days. What is going to happen if the devices are out of whack?"

Ackerman says that progress toward solving Y2K problems has been hampered because of denial or lack of understanding. "We don't have universal acceptance of the problem," he notes. "There's still a lot of debate going on."

Last spring, the American Medical Association Board of Governors passed a resolution calling on the government to ensure that all of its systems are Y2K compliant. The AMA also voted to appoint a study group to report back in December about the extent of the problem. By December 1998, there will be only 11 months remaining to solve the most egregious Y2K problems.

Congress has been less than responsive to Y2K concerns as well, except for a few politicians who hope to make political capital by blaming the crisis on the opposition.

Earlier this year, the U.S. Food and Drug Administration, which regulates medical devices, and the Health Care Financing Administration (HCFA), which pays the bills for Medicare and Medicaid, began pressuring the industry to find solutions.

HCFA issued an order earlier this year requiring all vendors with whom it has dealings to certify that their computer systems would be Y2K-compliant by the end of 1998. When contractors objected that the date was unrealistic, HCFA formed a working group aimed at facilitating compliance. The agency also has posted on its Web site a list of expected compliance dates for various payment-related operations. It can be accessed on the Internet at http://www.hcfa.gov/y2k/.

"HCFA is in terrible shape, but they expect everybody else to be ready, "Ackerman comments. "I read where [the U.S. Department of] Health and Human Services said their mission critical systems will be ready in 2003."

Ackerman also believes physicians will have to face social consequences of an expected Y2K crisis. "There is a strong survivalist movement developing out there," he notes. "People have guns, and if supply chain systems fail, they may use them." In addition, he says, surveys indicate many individuals believe hospitals would be used as shelters if Y2K problems cause disruptions in the deliveries of food or energy.

By now, systems that are not Y2K-compliant may not be ready for the millennium. Ackerman says the best solution may be to identify those systems that will not be ready and develop "work-arounds" for them.

"There will be no 'silver bullet' solution," he adds. "We systems people do not have a good track record for delivering on time, on budget and within a certain scope. This whole thing is because we screwed up. I say that as a former programmer and one of the people who helped cause the Year 2000 problem."

For additional information, the following Web sites are useful sources of information: Rx2000 Solutions Institute at http://www.rx2000.org/; and the Y2kInfo Healthcare Page at http://www.y2kinfo.com/y2khealth.htm.