Will Y2K testing save your equipment or destroy it?
Some experts advise you not to test most items
If you test your equipment and information systems to ensure they are year 2000 (Y2K) compatible, will it give you peace of mind or drive you to the brink of mental breakdown?
One hospital tried to test an entire OR and ambulatory surgery center by shutting it down on a Friday night, says William McDonough, MPAH, ARM, FASHRM, vice president and national health care risk management practice leader for Johnson & Higgins National Health Group in Boston. The tests went fine over the weekend, and it opened for business on Monday morning. However, an infection control nurse did a routine check and found a significant number of insects and mold in the OR.
The problem? The hospital had shut down the heating and air conditioning system during the test, and the normally stable OR temperatures fluctuated. "They had to close the OR and ambulatory surgery center for nine days, and their CEO was very upset," McDonough says. The hospital learned its lesson the hard way: "Always include the infection control nurse in plans like this," McDonough says. "It’s an example of how far reaching the Y2K problem can be."
The potential exists for broad consequences from Y2K testing, warns Tony Montagnolo, vice president for technology planning at ECRI, a nonprofit research agency providing information and technical assistance to the health care community, based in Plymouth Meeting, PA.
"What I suggest is to have a year 2000 committee with risk management, biomedical engineering, operational people, and clinical people," he says. "Do some broad-based communication with any staff who might be around that particular device or area so you can become aware of any downstream’ consequences."
Some same-day surgery managers want to test all of their equipment, even if they’ve received compliance information from the manufacturers. Others are testing only when they can’t obtain the compliance information or when they think the compliance information is inadequate. Which procedure is correct?
Consider these suggestions from experts:
Consider not testing."From our perspective, we’ve not advocated strongly user testing for year 2000," Montagnolo says.
The reason? Testing may take time and money away from other higher Y2K priorities, such as obtaining compliance information and developing contingency plans, ECRI says in its position statement.
And here’s some additional reasons: The basic type of Y2K testing — a date roll-up — isn’t likely to detect subtle problems that might occur only under certain circumstances, such as logging an error code, ECRI maintains. More detailed tests may be beyond your program’s capability, the agency advises.
You might need specialized test procedures from the manufacturers, but they may be unwilling to supply these procedures. If the manufacturer does the testing, they might charge you, ECRI warns. Some manufacturers prohibit testing of their products, so you could void the warranty if you do so, the agency advises. You also risk damaging the device if you test it, ECRI says.
ECRI suggests you obtain advice from several sources, including legal advisors, risk managers, clinical engineers, information systems staff, key clinicians, and top administrators before making a decision about whether to test. (See related story, p. 70.)
Consider testing in these situations
Testing may be appropriate under certain circumstances, ECRI maintains. For example, when devices are interfaced as a system, they may not be Y2K compliant, even if the devices are compliant individually. In same-day surgery, an example of an interfaced device would be a video colonoscope interfaced to a video processor and monitor. Input and output date formats may differ, so obtain this information from the manufacturer, ECRI suggests. If the formats are different, test the devices as a system, the agency adds.
Also, if you don’t have good compliance information from the manufacturer, consider testing, Montagnolo advises. "Clearly, if you do testing, check with the manufacturer and find out if you do what you plan to do, is there the potential for a problem," he emphasizes.
Don’t test devices connected to patients, he advises. "That seems obvious, but with things being networked, you may not realize it."
Be wary about outside testing. Companies will claim high degrees of failures after they perform testing, Montagnolo says. "Often what they’ve done is found problems that manufacturers already have found."
Some groups, including the Health Care Financing Administration (HCFA), suggest that your shouldn’t rely on someone else’s word when it comes to Y2K testing. On Jan. 12, HCFA sent a letter with the following advice: "Do not assume that a system or a program is Y2K ready just because someone said it is," says Nancy-Ann DeParle, JD, MA, administrator. "Test to make sure."
Track your test plans and outputs in case a problem occurs later, HCFA suggests.
Despite earlier concerns, HCFA assures providers they will be ready on Jan. 1, 2000, to process claims. If you aren’t already using compliant electronic claim formats, the agency suggests you consider testing your electronic data interchanges (EDI) with one or more payers, including Medicare. "This will ensure that your payer can accept your EDI transactions, especially claims," DeParle says.
Get the vendor involved, if possible.Dave Hall, senior consultant at ACS Technology Solutions, a provider of information technology services, software solutions, and Y2K project services, based in Oak Brook, IL, says, "In our experience, the ideal case is to have the vendor or your service provider develop formal testing procedures and have them accomplished in conjunction with a clinical engineer or whoever does the maintenance of your equipment."
Think of this testing as an "add-on" to the acceptance test or functional test that the manufacturer normally performs for new equipment, Hall explains. He acknowledges that in a significant numbers of cases, vendors won’t do the testing or tell you how to do it yourself.
Of the approximately 50% of equipment or systems with Y2K impacts, "realistically, you may have to decide whether it’s worth testing to you, if the vendor won’t tell you how," Hall says. "We’ve run into cases in which it’s easier to buy a new piece of equipment rather than figure out how to test, especially with older equipment and/or complicated equipment — especially if you don’t have all the manufacturer’s documentation."
For example, if you don’t know the microcode, line by line, it will be resource-intensive to develop tests, he warns. "So it’s basically an exercise in risk management. How much risk are you willing to take vs. how long it will take you to catch everything?"
Evaluate what the manufacturer tells you about your equipment.Be careful about accepting a vendor’s certification, Hall warns. "Normally it will say, You will use equipment this way with this kinds of inputs and this kind of date formatting.’ Also [you] must use it hooked up to other Y2K-ready equipment. Otherwise, they don’t guarantee anything." Read the certification closely, he suggests.
If necessary, develop your own formal testing procedure.Have a formal test procedure before you turn any system’s date forward, Hall advises. Turning the date forward may "freeze up" the equipment or cause the software license to become expired, which will require going to the vendor to have the equipment made operational.
A formal test procedure should include exactly what you’re going to do, your expected results, and a process for making the equipment operational in the event that you run into problems, he says.
"I’ve seen people turn dates forward, watch the equipment lock up, and they have to get the vendor to give them — sometimes for extra money — the key to unlock software, or the system has become a boat anchor," he says.
You have reached your article limit for the month. Subscribe now to access this article plus other member-only content.
- Award-winning Medical Content
- Latest Advances & Development in Medicine
- Unbiased Content