Testing Medical Devices for Year 2000 Compliance

May 1, 1998

10 Min Read
Testing Medical Devices for Year 2000 Compliance

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI May 1998 Column

YEAR 2000 COMPLIANCE

Manufacturers of devices containing embedded software that stores and processes dates need to ensure that those systems will continue to operate safely in the next millennium.

When the year 2000 arrives, patient lives could be at risk if medical devices with microprocessor-controlled, date-sensitive functions fail to operate properly or shut down as a result of a date-processing error. Some embedded microprocessors, like mainframe and personal computers, have the so-called millennium bug: they were not programmed to account for the two-digit year representation "00." To avoid dangerous malfunctions and ensure their products' continued safety and efficacy, manufacturers must identify devices with the potential for year 2000 problems now and thoroughly test the components and systems of those devices.

FDA called upon manufacturers to implement such a strategy in a June 1997 letter issued by the Center for Devices and Radiological Health (CDRH). The letter reminded manufacturers that "some computer systems and software applications currently used in medical devices, including embedded microprocessors, may experience problems beginning January 1, 2000, because of their use of two-digit fields for data representation. In addition to adversely affecting the functioning of some devices, the two-digit date format could also affect computer-controlled design, production, or quality control processes." CDRH recommended that all manufacturers conduct hazard and safety analyses to determine whether their devices will have operational, calibration, reporting, or other problems after 1999. If those analyses demonstrate a compromise in a device's safety or effectiveness, then action should be taken to correct the problem in future product releases and to educate and assist customers who have already purchased the device. (More details can be found on FDA's Web pages at http://www.fda.gov/cdrh/yr2000/year2000.html and http://www.fda.gov/cdrh/yr2000/ipyr2000.html.)

EMBEDDED SYSTEMS

Many medical devices contain embedded software that is used to control, monitor, or trigger the operation of the equipment or to perform a dedicated function in which the determination of real time is important. For example, the software may implement a timed control sequence or cause the device to operate on a timed basis (once per day or for three hours when activated). The software component may be undetectable by an observer. Rather than a user interface, input may be provided by sensors or detectors and outputs via actuators, switches, or regulators (valves). Devices may also be networked to obtain information from outside sources. Some examples of medical devices with embedded software include intravenous monitors, infant monitors, infusion pumps, pacemakers, heart defibrillators, ventilators, x-ray machines, and CT scanners.

Most medical devices with embedded systems will not have problems in the year 2000 because they do not store or process dates as part of their operations. According to a Veterans Health Administration database, only 102 companies (10.2%) in a sample of more than 1000 manufacturers of medical devices containing embedded chips reported non­year 2000 compliance for some of their devices.1 Of these 102 manufacturers, 27 (26.5%) identified 82 devices that were in use but were not currently produced or supported. The types of noncompliant devices included patient physiology monitors and external defibrillators. The other 75 respondents (73.5%) identified 305 devices that were noncompliant but indicated that efforts were under way to make them compliant.

Even though the likelihood of embedded system failures in medical devices is low, the risks can be high for those devices that do store and process two-digit year values in their operations. Therefore, manufacturers should start now to take an inventory of all their product offerings to assess the potential impact and scope of the year 2000 bug. Design control documentation for each type of medical device should be reviewed and assessed for date-sensitive functions. A safe approach to take is to assume the medical device is guilty until proven innocent. Manufacturers should also evaluate those devices that are no longer being produced but are still used by health-care providers or patients and determine whether to continue supporting these older devices with updated software or other solutions to year 2000 problems or to issue a recall.

POTENTIAL PROBLEMS

If a device with embedded software uses the year for display purposes only, then there may not be a serious risk to patients if the year 2000 is misinterpreted as 1900. FDA has indicated it does not expect manufacturers to spend time or money to correct minor problems that pose no health risks. If, however, another computerized device could read the two-digit year representation incorrectly, or if the key function of the embedded system is to calculate time-dependent events, then date-processing problems could create serious risks.

Typically, within the logic of the program, problems can occur in date and time sorts, calculations, comparisons, and projections. The units of interest may involve any combination of seconds, minutes, hours, days, weeks, months, and years. In addition, some medical devices have built-in schedules that alert technicians when maintenance is required. Because such devices determine this event by calculating the time since the last maintenance check, the limits for the between-maintenance period may be surpassed if the software cannot account for the year 2000 rollover. One manufacturer recently recalled a shipment of heart defibrillators after learning that the internal system clock that calculated the time since the last maintenance check couldn't handle the century change; once that date passed, the device wouldn't work.

Within the embedded software, when "00" is read as the two-digit year notation, one of two possible technical options could occur. The data processor could encounter incorrect logic or it could try to divide by zero, depending on the structure of the program. As a result of this type of error, the device could stop functioning, or it could go into an endless loop, or an alarm could be triggered. An IV monitor, for example, could stop pumping life-saving fluid if the underlying system didn't recognize "00" as a valid entry. All of these possibilities should be prevented before the medical device leaves the manufacturing facility.

YEAR 2000 TESTING

Once a medical device containing embedded software is identified as date sensitive, it must be tested for year 2000 compliance using a solid methodology that will generate accurate and reliable results within a minimum testing time. In identifying the scope of testing, manufacturers must define what year 2000 compliance means in terms of the device's performance. In most cases, the problems associated with the year 2000 involve dates that appear at or near key time boundaries. Examples include December 31, 1999, and January 1, 2000. The extra day in each leap year can also be a source of problems. The medical device's internal date-processing system logic should be consistent with the following leap year calculation. If the year is evenly divisible by 4, it is a leap year unless it is also divisible by 100, in which case it is a standard 365-day year. This rule is broken, however, if the year is also divisible by 400, which means it is a leap year. Take the year 2000: 2000 ÷ 4 = 500, which makes it a leap year. However, it is also divisible by 100 (2000 ÷ 100 = 20), suggesting it is not a leap year, except that it is also divisible by 400 (2000 ÷ 400 = 5), so it is a leap year after all.

One technique for year 2000 compliance testing involves the use of several different system clock settings and observation of the device's performance after each time boundary is passed. Table I lists the various recommended system clock settings and notes their significance. During this testing, not only should the device operate normally, but the system clock should continue to function accurately. For devices with an internal battery, testing at the indicated system clock settings may need to be repeated with the device in the power off position.

System Clock Setting

Test Rationale

December 31, 1999
@ 23:55:00

Represents month-end, quarter-end, and year-end prior to the year 2000; tests the rollover to the year 2000.

January 1, 2000
(1/1/2000)

The first day of the year 2000; tests the acceptance of "00" as a two-digit year notation.

February 28, 2000
@ 23:55:00

The day before the first leap day in the new century; tests the rollover to the first February 29th in the new century.

October 10, 2000
(10/10/2000)

The first eight-digit date in the year 2000; tests the acceptance of two-digit days and months in the year 2000.

December 31, 2000
@23:55:00

Represents month-end, quarter-end, and year-end in the year 2000; tests the rollover to the year 2001.

January 1, 1999
(1/1/99)
September 9, 1999
(9/9/99)

Represents all 9s in the date field; often used to signify no expiration date or a flag.

December 31, 1999
(12/31/99)

The last day of the 20th century; often used as a die date and may cause some devices to stop functioning.

December 31, 2000
(12/31/00)

The 366th day of the year; may cause device malfunction if programmed for only 365 days.



Table I. System clock settings for year 2000 compliance testing.

During the testing process, it is very important to observe all the device's expected functions. For example, if it saves data and is connected to another device or is part of a larger system, then the test must not only confirm that the device continues to save data properly but also that it functions properly as a subset of the larger system. For devices with an internal battery, the system clock should maintain the correct date and time during the testing process. Devices that reset their system clock to a year other than the testing point year, such as 1980 or 1990, will fail the test. For devices that store and process the day of the week, such settings must also be tested and verified.

If the year 2000 testing process reveals that a medical device is noncompliant, the manufacturer should take corrective action. Devices in production should be redesigned to eliminate the bug, and previous customers should be alerted to the problem in existing devices. Manufacturers must take care that no new errors or side effects are introduced in the device as a result of correcting the year 2000 problem. The potential for new bugs is highest for devices that are complex and have interdependencies with other systems.

If part of a manufacturer's corrective action plan is to retrieve the device from current users prior to December 31, 1999, then FDA will not classify this action as a recall. The manufacturer must, however, report its action to the agency. In addition, FDA's MedWatch voluntary problem-reporting system can be used to report any year 2000 problems with specific medical device types and models. (Information on MedWatch is available on FDA's Web page at http://www.fda.gov/medwatch/.)

CONCLUSION

To ensure that medical devices function properly in the year 2000 and beyond, manufacturers must identify those embedded systems that are date sensitive and test their performance at critical clock settings. If foresight was used in programming these devices and four-digit years were employed, there should be no problems. In those cases where problems are identified, corrective actions should be implemented in a timely manner. Because patient lives could be at risk if a device fails to operate as expected, manufacturers should make developing a year 2000 compliance strategy a top priority for 1998.

REFERENCE

1. Veterans Health Administration Medical Device Survey, [email protected] (Rx2000 List Administrator), January 22, 1998. (Links to this Web site can be made through several other government sites, such as http://www.y2k.policyworks.gov.)

Sunil Kumar Gupta is senior consultant and founder of Gupta Programming (Simi Valley, CA) and cofounder of Millennium Technologies Institute, Inc. (Spring Valley, CA).

Illustration by Lael Henderson

Copyright ©1998 Medical Device & Diagnostic Industry

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like