Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

news.softpedia.com

Post reply on HN
Print view View original

161–170 of 211 posts

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#161

Post by MertsA »

Coincoin wrote: post #115
wyager wrote: post #74

Earlier quoted context omitted.

>No matter what OS you choose it is vulnerable to viruses This may be theoretically true, but it is not practically the case. There is a reason Linux and OS X users almost never use antivirus software. Using Windows on a medical device is inexcusable. It's a heart monitor, not a game system.

Medical devices are used by humans. Humans, for some reason prefer and know Windows better. Why shouldn't the devices use Windows? Today, doctors from a hospital the other side of the country can diagnose your cancer realtime while you are still in the MRI machine, and they do it with Windows, because that's what humans know and use.

The benefit you're describing is just end users already being familiar with the interface because it's running Windows. That's not the case here, the entire interface on this device is of the custom application itself. It doesn't matter that the user already knows that the start button can be used to launch new programs, they're never going to see any hint that the device is built around Windows unless it's broken. There are numerous disadvantages to using Windows for a heart monitor, everyone else has described this to death but the only real benefit to using Windows is that development doesn't require a software developer competent with embedded work. Now they can hire any Tom, Dick, and Harry from the local community college because it's just a Windows app.

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#163

Post by tmptmp »

>>The company claims that they included proper instructions in their documentation, advising companies to whitelist Merge Hemo's folders in order to prevent crashes from happening, so it seems that the whole incident was nothing more than an oversight on the medical unit's side.

These Merge Hemo fucktards should learn a bit about systems design from Margaret Hamilton [1] [2] before they start coding for such life critical software.

Another point is no closed source software (including the greatest ones like Windows) should be allowed to use in such institutions.

[1] http://www.nasa.gov/home/hqnews/2003/sep/HQ_03281_Hamilton_H... [2] https://en.m.wikipedia.org/wiki/Margaret_Hamilton_%28scienti...

edit: added point about closed-source software

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#164

Post by JackdawX »

scruple wrote: post #150
emcrazyone wrote: post #142

Earlier quoted context omitted.

I'm just curious. I work in the automotive sector and develop hardware and software using components that are advertised as functionally safe. I use harden RTOS from vendors who claim their RTOSes are in medical devices as well as military systems. One such system is Disti ( http://www.disti.com/ ) In the automotive field, our software is MISRA compliant, static analysis is done (Klockworks - http://www.klocwork.com/…

> I find it amazingly short sited that antivirus software is even allowed on a medical device to begin with. Well... Then you should consider yourself blessed to have never had to deal with the bureaucracy of a hospital IT department and administrative staff. Who owns the medical device? Who paid for it? If it's a glorified Windows machine and it's attaching itself to a hospitals WiFi network... Who has to use this m…

> Yes, we do "have to meet FDA compliance." I can't define "have to meet" and I work here. Of course, I'm just an engineer.

You are not an engineer. This is a protected term in the US and other countries. If you were a professional engineer, you would be bound by a legal and moral framework preventing you from doing work on unsafe medical equipment.

There is a good argument that there should be a software equivalent of protected engineer status for this kind of work. This kind of story should be a wake up call. I personally had no idea that critical medical equipment would be running on MS windows...

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#165

Post by LeifCarrotson »

Avernar wrote: post #77

"Merge says the antivirus froze access to crucial data acquired during the heart catheterization. Unable to access real-time data, the app crashed spectacularly. The company claims that they included proper instructions in their documentation, advising companies to whitelist Merge Hemo's folders in order to prevent crashes from happening, so it seems that the whole incident was nothing more than an oversight on the m…

I build software that does the exact same thing. We're running automotive tests, and our management/customers are unwilling to invest in solutions that will work in spite of the fact that Windows is not a real-time OS.

We use a National Instruments DAQ card, and need the PC to respond within 50 ms to issue new commands for hours or days. Remarkably, it usually (over hundreds of machines and decades of operation) does. When it doesn't, it's blamed on antivirus or firewall or technicians using the PC for other things while the software runs.

National Instruments provides real-time IO systems, but they cost a lot more than the basic systems. You can write driver-layer code that will run in real-time on Windows, but that takes longer.

Our customers and management, with varying levels of comprehension of the problem, elect to not spend that money. I hate to say it, but if we didn't make this compromise, there are competitors who would.

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#167

Post by morgante »

scruple wrote: post #132
sathackr wrote: post #89

Earlier quoted context omitted.

Exactly this. As I was reading the article I hoped to find this exact point in the HN comments. The fault lies in the bad software. It could have been the indexing service, online defrag, automatic updates, or any of the other various background processes windows runs. If it is critical software, it should be designed in a way to not fail when something non-critical malfunctions, and even the critical pieces should b…

I work for a medical devices company and I just want to say: We, specifically a few of us on the engineering staff, bring this sort of shit up constantly. I go hoarse having the same conversations over and over and over again about robustness in the face of failure, resiliency, redundancy, etc... The truth is that we're beholden to a board and an executive management team that, quite simply, doesn't give a fuck about…

It's not a decision which should be made at the level of executives though.

Presumably developers are the one's estimating how long things take. (If they're not, you have even bigger problems and I'm sorry.) The time to make it safe should automatically be included in those estimates.

Moreover, making it safe shouldn't be a separate part of the process. It should just be part of how you write software. It's either safe or it doesn't exist at all. (Compare this to how organizations like Google deal with concurrency: it's built in from the start.)

A reputable engineer wouldn't design and build a bridge which might collapse. A developer shouldn't build software which puts lives at risk, regardless of management pressure.

If they refuse to relent, there are plenty of jobs where safety isn't critical.

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#168

Post by Blackthorn »

symtos wrote: post #101
Blackthorn wrote: post #93

Earlier quoted context omitted.

Is the medical device working right now? Yes. Could, upon upgrading, the device stop working, possibly in a subtle way that might kill somebody? Yes. The approval process for medical devices is rightfully difficult. Software upgrades, even if they seem trivial, should not be a backdoor process of bypassing testing and approval.

...and could software deployed to the device by some random who just exploited some well-known security flaw that never got patched, kill people?

This whole discussion has been about stuff air-gapped. That's not a guarantee when you have USB ports, but it does help.

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#169

Post by morgante »

sathackr wrote: post #135
scruple wrote: post #132

Earlier quoted context omitted.

I work for a medical devices company and I just want to say: We, specifically a few of us on the engineering staff, bring this sort of shit up constantly. I go hoarse having the same conversations over and over and over again about robustness in the face of failure, resiliency, redundancy, etc... The truth is that we're beholden to a board and an executive management team that, quite simply, doesn't give a fuck about…

I'm with you...I can see exactly how this can happen. Unfortunately the only thing that can solve the apathetic board and executive management problem(who only see dollar signs) is the actuality, or realistic possibility, of significant financial loss, or loss of their personal freedom(prison) due to the negligence of the system. And a $10 Mil fine for a fault in something that you make $100 Mil off of is not signifi…

> Unfortunately the only thing that can solve the apathetic board and executive management problem(who only see dollar signs) is the actuality, or realistic possibility, of significant financial loss, or loss of their personal freedom(prison) due to the negligence of the system.

Or developers refuse to build software without safety built in.

If they can't hire anyone to build their unsafe systems, they'll have to start building safe software.

Let the market work for you.

Re: Medical Equipment Crashes During Heart Procedure Because of Antivirus Scan

#170

Post by morgante »

CamperBob2 wrote: post #116
brians wrote: post #114

Earlier quoted context omitted.

For software critical to human life, test the rare code paths.

The easiest way to be sure a code path will run properly is to avoid writing it in the first place. This kind of application should be designed to run in a highly linear, predictable fashion on robust, fault-tolerant hardware. Why is nobody questioning the propriety of using an off-the-shelf Windows PC in safety-of-life applications?

> This kind of application should be designed to run in a highly linear, predictable fashion on robust, fault-tolerant hardware.

No, that's a recipe for failure. Hardware will fail. Period.

Hoping that nothing will fail and therefore not taking steps to mitigate it is akin to designing cars not to crash. [0]

Failures need to be explicitly designed for and tested. It's truly depressing that companies where failure is fine (ex. Netflix's Chaos Monkey) understand this, while companies where failure is deadly don't.

[0] https://news.ycombinator.com/item?id=11652940

Post reply on HN