“Year 2000 bug could bite hospitals! Senate hearing asks: how prepared is US health sector?” – MSNBC
“Senate Sees Y2K Doom For Health Care System” – National Underwriter
Is anesthesia equipment vulnerable to the Y2K “bug”???
With the year 2000 less than 500 days away, individuals as well as large corporations are concerned about how computers and computer-driven devices will be affected after December 31, 1999. A seemingly small problem with date calculations that is commonly referred to as the “Year 2000 Bug,” or simply “Y2K,” is affecting nearly every segment of the economy, and is expected to consume a significant portion of the GNP for years to come. Physicians, biomedical engineers, and hospital administrators have become concerned about Y2K’s impact on medical equipment because equipment that malfunctions due to inaccurate date calculations could produce serious health and safety dangers. Fortunately, however, many life-sustaining biomedical devices do not use date calculations to perform their tasks, and will continue to function after 2000 or can be easily updated. Briefly described here are the Y2K bug and how it affects anesthesia and monitoring devices.
What, exactly, is the Y2K problem? Until recently, computers had only limited amounts of storage space for programs and data. To conserve this valuable resource, computer programmers used only the last two digits of the year when performing date calculations. For example, instead of storing a birth year as “1962”, it was stored as “62”. Although this seems like only a small difference in size, this technique resulted in a significant reduction in storage space as databases grew to include millions of records. The problem with this approach is that it works only as long as both years occur in the same century. If for example, a patient was born in 1962, his age would be determined by subtracting 62 from 98, leaving 36. On January 1, 2000, however, a program that uses only the last two digits of the year would subtract 62 from 0, leaving –62. This is not the only problem related to the year 2000. Leap years occur every four years, except on century years. The exception to this exception rule is that a leap year does occur on a century year evenly divisible by 1,000. So January 1, 2000, is not the only date to worry about — some programs may also behave unpredictably on February 29 and March 1, 2000. A third problem will occur somewhat later, when the calendar of computers that use the Unix operating system, which counts milliseconds since midnight, January 1, 1970, rolls over.
Old Programs Still in Use
The developers of programs now facing the Y2K bug largely assumed that their programs would be updated and replaced long before the end of this century. Contrary to their expectations, however, this did not occur. Moreover, many of the original programmers have retired or died, and the “source code,” or representation of the software logic in “human readable” form, has in some cases been lost. The result is millions of lines of program code that must be read, understood, and modified, and also database structures that must be updated, so that date calculations can be performed correctly after the year 2000. Unfortunately, the consequences of the Y2K problem are not limited to inaccurate date calculations. Since most programs never anticipate a date result less than zero, calculations of all types might become unpredictable, leading programs or entire systems to malfunction.
Many older mainframe, desktop, and laptop computers will malfunction or become unpredictable after the Year 2000. The BIOS (a very low-level interface for input and output to/from computer hardware) in many PC compatible computers sold even as late as the beginning of 1998 does not handle the year 2000 correctly. The problem is not limited to desktop and mainframe computers. Importantly, many electronic medical devices employ microcomputers and embedded software, possibly even in such a way that their presence would be unknown to the user. Some of these devices may stop working or produce unpredictable results. Some manufacturers of affected medical equipment offer solutions to the problem with existing equipment, while others require that a solution be purchased or even that a new device be bought.
To begin to solve the Y2K problem, the first step is to recognize that it exists, and also to convince administrators of the involved medical facility (hospital, surgery center, clinic, office, etc.) that the problem is real. It is important for anesthesiologists either to be sure that someone is being responsible for this or to take responsibility for their own equipment. The second step is to understand that 2000 is too close to implement a definitive solution to the problem for all affected devices. Instead, it is important to triage equipment and computers into three categories. Life sustaining equipment that is susceptible to the Y2K bug must be fixed or replaced prior to the year 2000. Equipment which is not life sustaining should be fixed, although not necessarily prior to the year 2000. Some equipment may not be able to be updated, and should be replaced or discarded. Physicians and administrators should contact the manufacturer of each medical device and work with them to determine which items will be affected by the Y2K bug and what action should be taken.
EQUIPMENT TRIAGE NOW MANDATORY
Fortunately, for most medical equipment, Y2K is not as big an issue as it is for hospital information systems. Some life sustaining devices used daily by anesthesiologists (e.g., physiologic monitors, anesthesia machines, infusion pumps, ventilators, and cardiopulmonary bypass machines) may be vulnerable to the Y2K bug, and must be either fixed or replaced prior to 2000. While a comprehensive list of which pieces of relevant equipment are compliant and which are not is far beyond the scope of this article, such resources do exist. The Food and Drug Administration has set up a World Wide Web resource with their statement regarding Year 2000 compliance, a letter to equipment manufacturers, and the status of many brands of medical equipment. The FDA has defined Year 2000 compliance as “…accurately processes and stores date/time data (including, but not limited to calculating, comparing, displaying, recording and sequencing operations involving date/time data) during, from, into and between the twentieth and twenty-first centuries, and the years 1999 and 2000, including correct processing of leap year data.” The FDA has also requested that medical equipment manufacturers supply either a statement of whether or not a product is Year 2000 compliant or a statement that the problem is not applicable to a given product.
Y2K will have a substantial impact on nearly all sectors of the economy, from air travel to credit card transactions. Our patients, however, will not be adversely affected under our care if appropriate steps are taken in a timely fashion.
Y2K Information Resources
http://www2.mc.duke.edu/depts/clineng/yr2000.html
A description of the Duke University Clinical Engineering department’s Y2K plan.
http://www.y2k.gov.au/biomed
A database of equipment, listed by manufacturer, model number, and description.
http://www.fda.gov/cdrh/yr2000.html
Information about the Y2K problem, administered by the US Food and Drug Administration. Contains a letter to manufacturers, and a database of equipment.
http://www.year2000.com
A forum for disseminating information about Y2K and discussion of possible solutions. Has a link to a free PC test program.
http://www.itaa.org
General information about the Y2K problem.
http://www.rx2000.org
General information, downloadable Y2K presentations, and a list of equipment.
http://www.abbott.com/year2k/monitorequip.html
A list of equipment marketed by Abbott Laboratories.
http://www.mallinckrodt.com/Corporate/Y2K/index.html
Information about the Y2K problem and a list of products made by many medical equipment manufacturers.
http://www.hp.com/go/healthcare2000
Y2K compliance for Hewlett-Packard products, and links to other Y2K information resources.
Dr. Ruskin is Associate Professor of Anesthesiology at Yale in New Haven, CT, and Webmaster for the APSF as well as the GASNet Administrator on the WWW.