Slashdot Mirror
Medical Equipment Crashes During Heart Procedure Because Of Antivirus Scan (softpedia.com)
An anonymous reader quotes a report from Softpedia: The device in question is Merge Hemo, a complex medical equipment used to supervise heart catheterization procedures, during which doctors insert a catheter inside blood veins and arteries in order to diagnose various types of heart diseases. According to one such report filed by Merge Healthcare in February, Merge Hemo suffered a mysterious crash right in the middle of a heart procedure when the screen went black and doctors had to reboot their computer. Merge investigated the issue and later reported to the FDA that the problem occurred because of the antivirus software running on the doctors' computer. The antivirus was configured to scan for viruses every hour, and the scan started right in the middle of the procedure. Merge says the antivirus froze access to crucial data acquired during the heart catheterization. Unable to access real-time data, the app crashed spectacularly.
Our antivirus is completely up to da
Upgrading to Windows 10......
SJW's don't eliminate discrimination. They just expropriate it for themselves.
Picking an OS that clear says not use it for real time possible life endangering task is a huge mistake!! QNX, RT_Linux, and more!!! Hello!!!
Based upon the available information, the cause for the reported event was due to the customer not following instructions concerning the installation of anti-virus software; therefore, there is no indication that the reported event was related to product malfunction or defect. The product security recommendations, (b)(4), explicitly state, "the intent of these guidelines is to configure the anti-virus software so that it does not affect clinical performance and uptime while still being effective. To accomplish this, the anti-virus software needs to be configured to scan only the potentially vulnerable files on the system, while skipping the medical images and patient data files. Our experience has shown that improper configuration of anti-virus software can have adverse affects including downtime and clinically unusable performance. ".
This is interesting; the configuration on a device like this should be highly controlled. I have no experience with medical devices, but I know that process control equipment generally has vendor approved configuration (and often they only certify one AV vendor so even if our corporate contract is with vendor A, we have to use vendor B for the process control stuff because that is what is certified by the control system vendor. They also have very specific settings you have to use. Failure to follow the settings could result in lack of process control at a critical time. It seems medical stuff must be under similar (if not even more restrictive) configuration control. Having AV do a "scan" every hour is very stupid since any competent AV is doing on-access scanning anyway. I would expect the vendor for the software has specified folders / files / etc. that must be exempted from the scan as well (vendors for process stuff such as Yokogawa, etc. specify that). Seems to be a configuration failure on the part of the facility.
For what? This was an antivirus scan and the report itself doesn't mention an OS. Furthermore, this crash brought down the whole system. If developers are writing their software to utilize drivers, they ought to make sure those drivers aren't so buggy that the mere stopping of data will tank the entire system...especially a system that should be as close to "bulletproof" as bulletproof can be in the technological sense of the word.
It just writes itself.
Antivirus systems aren't useless(I wouldn't trust their 'disinfection'; but they at least catch people reusing obsolete exploits and sometimes provide warnings that something is amiss); but this is one of those situations where hearing that antivirus software is running is a giant red flag: it usually means that a full-fat desktop/server OS with a network connection and who-knows-what-else running on it is doing the job of a dedicated computer. Quite probably being allowed to retain state over time except for the ever so occasional re-imaging. That just isn't going to go well. Even if your application needs full Windows whatever for some reason, there are plenty of ways to keep it on a much tighter leash than just shoving a desktop at the problem and hoping Norton can save you. If a system is contained by the network so that it can only talk to the external hosts it absolutely needs; and is booting from a clean, static, image every time(with all changes discarded after any data generated during the session are moved elsewhere) you are a great deal safer.
For what? This was an antivirus scan and the report itself doesn't mention an OS. Furthermore, this crash brought down the whole system. If developers are writing their software to utilize drivers, they ought to make sure those drivers aren't so buggy that the mere stopping of data will tank the entire system...especially a system that should be as close to "bulletproof" as bulletproof can be in the technological sense of the word.
Windows can never fail - only we can fail Windows.
And Bulletproof and Windows never belong in the same sentence.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
"Merge investigated the issue and later reported to the FDA that the problem occurred because of the antivirus software running on the doctors' computer. "
I seriously doubt the computer was owned by the doctor. More than likely, it was procured, set up and managed by a team of IT specialist at the hospital/clinic who know little to nothing about the software that might be running on it. Likewise, if the company supplying the software isn't providing a dedicated, hardened box to run the software on, they share the blame as well. Or, I have seen dedicated boxes with all kinds of crap loaded on them by operators who had no clue what the consequences might be. The bottom line here is that maybe computers should be kept out of the operating room. Or maybe doctors shouldn't be allowed to use them.
The machine didn't use Windows. It was hooked to a PC to record the logs during the procedure so the doctor could review them later. The AV software locked the log to perform the scan, and the medical device crashed. They had to reboot the PC to keep working.
There is no need to mention an OS - the only system that such problems with viruses is Windows, and the only OS that embeds a virus scan in the kernel IS windows. No other OS locks data like that.
"as close to "bulletproof" as bulletproof can be"
Certainly leaves out using Windows.
. ,even though it wasn't?), and that being able to use their knowledge of Windows is a benefit that will make their system better.
It is easy to fall for the siren-song hype from the marketeers that the general purpose operating system is up to the task (remember Microsoft's marketing push that Windows CE was a real-time operating system
Whether it is a weather application being used on live television, or a computer being used in an operating room, Microsoft has shown that Windows is not a proper steward of serious systems programming.
I used to work for a company that built ophthalmic ultrasound machines. It was Windows based (unfortunately). IT departments, being who they are, wanted to put things like antivirus on it. Then the doctors would complain that the MEDICAL INSTRUMENT wasn't performing as advertised. They send it in to us for 'repair'. We remove the shitty antivirus (and all the other crap that IT guys would install on it), then it works perfectly again. We return it.. and IT guys would screw it up again. Rinse, repeat, ad infinitum.
MEMO TO IT GUYS: Stop treating medical instruments like they're desktop computers! Find another solution, or AT LEAST be smart about how you're installing your junk on it, IT IS A MEDICAL INSTRUMENT, DAMNIT!
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
IIRC the EULA of every Windows version so far said that the OS must not be used in life-or-death critical operations.
Not that it isn't used in, say, nuclear plants (which are explicitly cited in the EULA, btw), but if you use something that is clearly not good enough for the job, and even tells you that it's too crappy for important tasks, well, you can't really complain, can you?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This is what I don't get. Why the hell is AV software running on a realtime apparatus?
1: If AV software is needed for legal eagle reasons, code a scanner for embedded use that runs -only- when the machine is offline and not doing anything. When the switch to online it is flipped, any scans and such get stopped immediately.
2: A medical machine should be air-gapped anyway, with firmware updates done via files on a signed SD card. There should never be a vector for introducing malware onto a machine without physical access.
3: Have the designers even done testing where the AV software (or even worse, GWX) fires up during a procedure? This is basic Q&A here, and for the astronomical cost of medical equipment, should be assumed that this was done.
From TFA, I'd lay the blame of this at the feet of the device maker. They need to use a real OS, or at least ensure that there is no state their environment can get into that can cause this.
This is what I don't get. Why the hell is AV software running on a realtime apparatus?
1: If AV software is needed for legal eagle reasons, code a scanner for embedded use that runs -only- when the machine is offline and not doing anything. When the switch to online it is flipped, any scans and such get stopped immediately.
2: A medical machine should be air-gapped anyway, with firmware updates done via files on a signed SD card. There should never be a vector for introducing malware onto a machine without physical access.
3: Have the designers even done testing where the AV software (or even worse, GWX) fires up during a procedure? This is basic Q&A here, and for the astronomical cost of medical equipment, should be assumed that this was done.
From TFA, I'd lay the blame of this at the feet of the device maker. They need to use a real OS, or at least ensure that there is no state their environment can get into that can cause this.
The AV software wasn't running on the medical device, it was running on the Doctor's computer. The Doctor's computer has a software app that gathers data from the medical device and, it seems, that there is some requirement for the medical device to be able to read this data as well. Or perhaps the App has some command and control functions. Either way, the AV software ran, freezing up the app on the doctors computer and causing the medical device to crash.
In my opinion, the hospital should have an air-gapped dedicated system for this instead of relying on the doctor's laptop.
Having a Windows based medical system is stupidity in itself. Even having an antivirus scan in embedded software is ridiculous, they should be stand alone devices, not dependent upon some apathetic home consumer company, not connected to the internet, etc. And yet so many developers are so amazingly uneducated and inexperienced that they think Windows is the perfect solution to everything, managers love Windows because they can hire so many cheap ass developers for it and mistakenly think they can save time this way. Maybe Windows is not the flaw, but the Windows mindset certainly is.