Slashdot Mirror
Fed-Up Hospitals Defy Windows Patching Rules
bingbong writes "According to Network World: 'Amid growing worries that Windows-based medical systems will
endanger patients if Microsoft-issued
security patches are not applied, hospitals
are rebelling against restrictions from device manufacturers that have
delayed or prevented such updates. Device makers such as GE Medical Systems,
Philips Medical Systems and Agfa say it typically takes months to test Microsoft patches because they could break the medical systems to which they're applied. In some instances, vendors won't authorize patch updates at all.' This is the typical patch vs. crash problem. Unfortunately, the stakes here could be human lives."
...do they not just put these devices and systems behind something as simple as a $50 hardware NAT firewall, especially for a device that costs hundreds of thousands - or millions - of dollars? (Or better yet, why does the vendor not integrate such protection if they're relying on network-connected Windows systems for device control/interaction?)
The norm is that these devices may need to connect *out* to something else, but don't necessarily need any inbound connections, so a hardware firewall, or even a host-based software firewall, would work perfectly in most instances; those that do need externally initiated inbound communication can *still* set up the necessary rules to allow such communication to take place. And yes, it is just this simple. (I did RTFA, and noted that some vendors actually recommend this, but that, startlingly, "there have been several instances in which viruses originated from medical instruments straight from the vendors"!)
I work for a hospital,and I have to say that our network may be 'stable' but it really sucks. We run Windows2000 Pro with many problems, and frequent crashing. If one of our secondary databases crashes, as they seem to do often, we have to wait a day or two until we can get a reboot of the system because the main database runs on the same server. Productivity really goes down the tubes sometimes to allow for the 'stable' network.
Boxing Equipment Reviews
The recent times I've been in hospitals I've checked to see what they're running. The two major hospitals near me don't appear to have the real "life and death" equipment running Windows. I'm talking about vital stat monitors and other surgical recovery equipment. I've seen certain medical records being accessed on Windows-based systems. Perhaps then there could be issues with lost information as to current prescription or observational data being lost or corrupted.
But even then wouldn't such systems be running separate from the public Internet? If so, on top of that wouldn't they be secure enough so that executives with their laptops can't just plug in and hose things up? With even entry-level expertise IT staff should be able to separate these boxes onto some sort of a VLAN that would secure them by default. What are the IT folks' take on this who are working front line in the medical arena?
I was going to complain about how Windows is not appropriate for embedded devices, but then I reread the article for examples. They don't make one mention to any kind of "device." The only thing they mention is some system by Kodak for transferring images. I think the word "device" is there to scare the public into thinking that their heart monitors and chemotherapy machines are going to be infected. I doubt these devices have hard drives or TCP/IP connections to infect. More likely, they are talking about hospital computer systems. My experience in the Medical Informatics biz is that this sector is technologically further behind than any other section of IT.
Having spent 10 years working in the Medical Device/Biotech domain, I can tell you that the FDA really does govern these things. Unfortunately, their internal understanding of computer systems in general is frighteningly scarce. Essentially, the only body of legislation they have to go by is a small portion of a CFR (Code of Federal Regulations: 21CFR Part11) that was released in 1997, and the enforcement guidance documents that followed it. The Code is extremely ambiguous and realistically lumps "electronic documents" and "electronic signatures" together. The compliance issues resulting from the vague document and its (mis)interpretation and enforcement were enough for me to change industries. My heart goes out to all of the people still battling this.
Part of the problem is that the vendors chose Windows as a development platform.
I'm a rabid Linux user, but if I were designing equipment that held human lives in its anthropomorphic hands, I'd build it as an entirely atomic OS built from Linux or a BSD variant. And communications would be data-only, over a serial port. No network.
In high school, a nurse from St Mary's (here in Grand Rapids, MI) was showing us screenshots of their radiation therapy machine. I recognized CDE...she didn't know what version of UNIX it ran, though.
tasks(723) drafts(105) languages(484) examples(29106)
All computer systems involved in patient care (and paper tracking as well) are forced to go through governmental processes for design, documentation and testing. These regulations add weeks, if not months, to system changes, regardless of change scope.
Case in point is the drug study setup. Setting up data entry screens and processes can take up to 6 months for a given trial, and that trial may only run 3 months for the study metrics. If any of these processes are documented incorrectly, and entire trial can be dropped and the drug denied.
This, in the hospital realm, is all about CYA. If a piece of equipment is not certified to this extent, the hospital can be held more liable for patient injuries if said equipment falters.
On the other hand, if it just malfunctions...
-- Will quantum computers run imaginary-time operating systems?
Here's a clue: stop being so sensitive. A hospital that tries to save a buck is different from an entrepreneur saving a buck. Heck, a hospital could try saving a buck by watering it's potted plants less, and that'll be fine by me.
Speaking of a radiation therapy machine with software bugs.....
/. a while back: An Investigation of the Therac-25 Accidents
This was posted to
I develop an enterprise-level hospital app at a large corporation for a living, and I had the same questions when I started.
Hospital hardware surely does run embedded systems. However, most parts of the hospital are probably kiosks running a web-based app that controls bed management, scheduling, the financial parts, etc.
They are running windows for the same reason they are using IBM Websphere for the app server instead of Apache Tomcat: liability. What happens when a patient dies because of a server crash? Who do you blame? Oh, we'll blame Microsoft or IBM for our own bugs. You don't have that luxury if you're using Tomcat and Linux. Yes, it's dirty, sleazy and nasty, but I have no control over it.
'When the going gets weird, the weird turn pro.' -HST
All computer systems involved in patient care (and paper tracking as well) are forced to go through governmental processes for design, documentation and testing
So, if the hospital installs an uncertified piece of software on the machine, then they would be at risk if death or injury occurs, not the vendor.
If someone was injured by an unpatched machine, the hospital could pass liability back to the manufacturer - after all, they were in full compliance with the federally tested machine configuration. In which case, the manufacturer would be held liable for any injuries.
But it doesn't stop there. The manufacturer could easily and convincingly claim that Microsoft overstated the reliability of their operating systems, and the failure was due to Microsoft's code. Convincing a jury that a Windows crash caused the injury would be a trivial exercise for even the most inexperienced attorney; almost everyone has had some experience with a Blue Screen of Death.
Now comes the interesting part. Yes, the manufacturer may have agreed to the EULA, and may not be able to sue Microsoft. The patient, however, did not agree to the EULA, and having been damaged by Microsoft's code, could easily convince a jury, that in spite of the EULA, because Microsoft knew that their code was being used in medical devices failed to show due diligence to protect the user. Microsoft can't weasel their way out of this one, because the EULA doesn't apply to the patient. And, unlike the software liability cases, a medical malpractice case could easily charge the defendant with millions, or even billions of dollars in punitive damages.
The society for a thought-free internet welcomes you.
Thanks for the link but wow. So, when Microsoft was collecting data from users MS Word documents( over the internet, behind the users back, and databasing it ) they were doing so without provisions and protections in their OS EULA? And they got away with just being able to say they won't do it again and that they've deleted the database....
,etc business. After all, they are already a convicted felon. Hearing Bill Gates or Steve Balmer/etc saying 'trust me, we won't do xxxxxx' is meaning less. IMHO.
One thing of interest in that article is how the Microsoft exec specifically states the EULA of the SP and not the original EULA. This would be fine as long as the SP EULA states that it replaces completely the original EULA the user has been operating under and I don't know that it doesn't.
I do know of quite a few people who refuse to upgrade to WinXP because of the EULA and the fact that Microsoft can legally update anything on the OS without the user/admin/etc knowing should be cause to exclude them from any financial, healthcare, public service
Sure seems like all of these businesses would be on the high road to replace MS Windows ASAP with something they can have more control over...
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
its been running VxWorks from day one. I should know I build the software for the damed thing...
... (he's pretty busy lately, though). Yes, the digital front end is running a quad PPC (more now maybe?). MGD is not the entire scanner.
Then you probably know who I am if you look at my initials. I left there in early 2002. OK, so let's take the MR scanner. ECG input comes from patient through the SCM. Gets displayed on a...anybody? Anybody? PC running Windows. Just one example, but I could dredge up more if you'd like. If Bill E. hasn't retired again, he could fill you in on the history you don't know. Rob J. could undoubtedly do the same, or Steve C., or John Z, or J. Eric S.
Maybe current production has (finnally) phased out the 'doze box, but to say "has never contained" is demonstrably false.
I doubt YOU have any customers to deal with, especially with your "my way or the highway" attitude. Get back to being laid off [...]
I work for a GPO. It's my job to write contracts for health care companies. It's a staggeringly boring occupation, but I do get to spend a lot of time thinking about what would happen if someone died because of a failure in a piece of equipment bought through one of my contracts.*
I see a lot of EULA-style documents. You might be surprised how many software companies have simply taken the EULA from Windows98 and adopted it as their own license agreement. You might also be surprised how many suppliers are willing to offer code escrow or source code access to customers. I've certainly seen some things I never would have expected.
But you know what surprises me the most? That some vendors don't seem to care that their slipshod implementation could result in harm to a patient. For example, I recently spoke with a sales rep from a large point-of-care software vendor. He was very very excited to tell me all about the features his web-enabled software offered, like giving me REALTIME! ACCESS! TO! PATIENT! DIAGNOSTICS! but when I asked him about security, his answer was "well, that's the customer's responsibility." The base functionality required for this app is to take a bunch of data from a handheld device over serial port, dump it into a networked database, and then provide reports from that database into a web frontend for multiple users, with a user administration tool tacked on as an afterthought. What did his application run on? IIS, and it requires IE on the client desktop. Do they SSL-encrypt traffic on the network? Of course not. Do they send patient name and ID number in cleartext along with their REALTIME!!! test results? Well, the data wouldn't be much good if you don't know who it belongs to, now would it?
tinfoil-hat concerns aside, healthcare organizations are now required to comply with HIPAA, and if they fail to do so, people can go to jail. If the blood lab at one of my customers' hospitals buys this software, and someone is able to plug a laptop into their network and intercept data sent by their crappy IIS application, that's a clear HIPAA breach - but who is responsible for it? It's my job to make sure my customers aren't going to federal prison as a result of a poorly informed software purchase... you can bet that they're not buying the software.
see, you assume that the customer is always right. In fact, the customer is often wrong, either because they are ignorant, or because they are receiving some kind of incentive (read: bribe) from at least one vendor in order to influence their decisions. When you use Windows in healthcare, the "customer is always right" attitude could land your customer in federal prison.
*(what happens? Somebody gets sued. Usually, the dead patient's family sues the doctor and/or the hospital, and potentially the vendor, and also potentially my company. If the contract is written well, the vendor is obligated to step in and indemnify the doctor, our customer, and us against any claims. The funny thing is that vendors running on windows are NEVER NEVER NEVER willing to volunteer this indemnification- I always have to fight for it, and sometimes we just can't get it. If there's an alternative vendor who will indemnify, they usually end up winning the business, because this is such an important concern for the health care providers...)
Humpty Dumpty was pushed.