It was about a year ago that I did not receive a reply to an e-mail for several days from a PAC system administrator at a major institution in Houston. After three days, I called her and asked whether there might be a problem - finding out that the e-mail system had been down for three days, hopefully to be back up in another day or so. It was on the bottom priority of the IT staff, which was focusing on getting all clinical systems back up, after being infected with a virus. Just the Web distribution system for imaging was down for a whole day.
I heard a similar story from a vendor's representative, who spent a whole day after a virus struck at a Boston healthcare institution that basically wiped out all the DR systems, not allowing any routine x-rays for a day. Viruses, worms, or whatever malicious software, are a common threat that not only do we have to deal with in our business and home environment, but even more in healthcare institutions. In particular, with more UNIX-based systems being replaced with Microsoft products, the threat becomes even more imminent. The question is generally not whether a system will be infected but rather when, and how to react to it.
The federal government has addressed this issue and made this part of the HIPAA security requirements. One of the so-called Administrative Safeguards that have to be in place is the risk analysis that has to be done periodically - which includes the assessment of risk for a virus attack. Protection against malicious software is even spelled out as a specifically required item. Therefore, besides it making common sense, it is a legal requirement.
One could therefore assume that every medical device has virus protection software that performs a regular scan and is updated frequently, simply applying the same ground rules that any IT department would implement to protect the users, and ultimately making sure operations are available to serve patients. The problem, however, is that vendors have been very reluctant to release "control" over their equipment. They have had bad experiences in the past because users would add software to their devices which interfere with the operation of the imaging software, resulting in unnecessary service calls and therefore additional cost of maintenance.
Some vendors have taken a hard-line approach and threaten to discontinue or void warranty of their equipment if a user adds and/or changes anything regarding the software configuration. To back them up, vendors use the argument that it is not "FDA-approved." The good news is that the tide is turning, both through pressure of users who simply don't accept these arguments - knowing that HIPAA makes them ultimately responsible and not the vendor, and also because the vendors have had to clean up numerous infected systems during the series of malicious software attacks of the past year.
Another argument from vendors against using virus scanners is that a user should just make sure that the network is protected, e.g. by isolating the physical network through appropriate firewalls and routers. However, I would argue that there is always the chance of an attack from "within". This can take place, for example, from a laptop of a service engineer, which is connected to a device to run diagnostics, and which just has been infected through a virus coming in through his e-mail. Another source could be a floppy disk or CD with a software patch, or even downloaded via the Internet for installing a software upgrade. Therefore, there is no single system that is completely isolated; there is always a change for compromising its integrity
Now, let's consider the "not-FDA approved" argument. The FDA guidelines explicitly state that there is no requirement for off the shelf components such as Operating Systems and other utilities to be explicitly FDA approved, such as what is needed for medical device software. However, the FDA guidelines for off-the-shelf components require each medical vendor to validate it. In addition, they need to have a quality system in place which also requires proper validation and verification of all software regardless of whether it is off-the-shelf, as well as implementing software configuration control. Therefore, it is a requirement for the vendor to verify the impact of the virus scanner on the integrity of their software. I cannot imagine that this could take more than one or two days at the most, which is a negligible effort compared