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."
My father works for GEMS as a Field Service Engineer; he repairs and installs X-Ray Machines, CAT Scanners, and Mamography machines. As far as I know, GEMS doesn't run Windows on any of it's boxes (other than Engineer Laptops). Most of their older systems are UltraSPARC/SunOS boxes. The newer ones are Intel Xeon/Red Hat rigs with their own custom window manager. Heh, he's even called me in a few times to help him with some Linux problems.
It makes sense to me, GEMS and the Hospitals aren't going to risk $500,000 to $2,000,000 machines because of Microsoft's poor track record. Not to mention, a bug in the software can bring down the system for hours, until someone can come in and fix the problem. My Dad has problems all the time with doctors breathing down his neck. Most the time they have a full schedule, and when a x-ray tube blows it can take up to 4 or 5 hours to replace. Not including shipping from Wisconsin or France.
Bugs are just features that have been fixed.
I.e. while one can build a simple manometer the reality is that blood pressure devices used today probably have all sorts of interdependancies that can cause a ripple effect, so one should be pretty darn careful before just applying patches licky-split ... in a work discussion earlier today, we talked about how one of the recent Microsoft security patches broke one of our applications.
Hulk SMASH Celiac Disease
Let me tell you, stuff gets inside hospital networks like nobody's business! The problem is that while the outer firewall is secure, there are all sorts of ways for things to get in via individual workstations. This is especially true since many hospitals, like mine, have standardized on IE. I was literally in the process of patching a Windows 2K based acquisition PC when it got hit with Sasser! Lucky for me the patch just barely beat the infection, so I didn't have to rebuild the machine.
Because the inside of the hospital network is so insecure, I've actually set up my own firewall around my test and development machines. One solution would be to totally cut off the hospital from the internet, but that wouldn't be very practical and would piss off a lot of doctors to boot!
To the making of books there is no end, so let's get started
No, most machines (from GE atleast) listen for incoming SSH sessions. This is so it's main tech guys can connect (from Wisconsin) and fix the problem. It saves the Hospitals money, they don't have to call in a field service guy for $150+ an hour. The tech guys can even find a faulty board, order it, have it shipped to the hospital, and have a guy swing by the next day and replace it without alot of wait.
Bugs are just features that have been fixed.
I work in one of the top hospitals in the US (Top 100 Wired, top 25 in a lot of the US News and World Report rankings, etc) as the principal technology architect, and I can say that people are idiots for going nuts and patching immediately.
Our CIO, who's pretty well respected among his peers, asked us last week on deployment schedules for this. We pushed back and said, if we deploy now, we'll run into a host of issues. Over the weekend we did some cursory testing against most of our Patient care apps (a lot are web based) such as Cerner Millennium and GE's CentricityWeb. We're far ahead in the CPOE game for healthcare, so our devices are used for input of labs and orders.
Most of the biomed equipment we have doesn't run Windows. Personally, if you do your environment right, then you shouldn't have to worry about viruses and stability.
Healthcare doesn't function like the rest of the business world. It's a completely different animal.
I work with MRI scanners, so I know about these issues very well, and here's an example from my own experience:
An old colleague of mine got funding to start his own reasearch group, meaning he got his own MRI scanner. He asked me to consult on some software that would extract the data from the console of a Siemens scanner (at the time, the console was based on an OLD version SunOS, whose native compilers did not even conform to standard ANSI C) and send it directly to another computer running software that we use for data analysis. The dialect of C was a little strange, but within a week, I was able to get the software together, and my colleague was able to do the type of experiments he wanted to. And his scanner hummed along. This was back in 2001.
Fast-forward to the present. His console has since been "upgraded" to Windows XP system, and in the times I've spoken to him, he's had nothing but bad things to say about the stability of the "upgraded" system. And it's not that he had a choice, as support for his previous system was phased out. So now patients, doctors and reasearchers in his group are at the mercy of the moods of an XP system. And mind you - this system is not even on a publicly accessible network. It is on its own dedicated, private network, and its stability still can't be maintained, even by the support staff of the scanner manufacturer.
When it comes down to it, Windows still does not have the stability (never mind the security issues to cut it in really "mission-critical" situations). Maybe in cases where you need your e-commerce site up, running, and handling 1000s of transaction per second. But NOT when peoples' lives are involved.
The article mentions one thing that needs to be emphasized, which is where the FDA guy states that they're not going back to the dark ages where systems don't talk to anything else. For years, every device was on its own proprietary network (if it was on a network at all), and talked to itself and absolutely nothing else. This was bad.
In only the last couple of years (because medical IT is very behind the rest of the IT industry in a lot of ways) these devices have moved rapidly to using commodity protocols and network infrastructures, driven by hospitals' needs to do all of this more cheaply, and not have a lot of chaos.
Also, they want to provide some value add on top of the monitoring systems. For instance, it's nice to be standing by the patient's bed and see the monitoring data. It's even better to be able to export that data to another system so that it's more useful, or display it on a website so MDs can see it. All of this requires networking capability, and Microsoft (like it or not) is considered a leader in the field for server software, and has a large division providing solutions to healthcare.
Overall, the more advanced features you want a clinical system to provide, the more that system needs to integrate with other systems. Companies have given up reinventing the wheel on this every time, and are basing what they do on standard software and protocols. Microsoft is one of those. We try to avoid it whenever possible, however in most instances the decision for one product over another is based on clinical value, and not IT preference.
Actually, there were a string of deaths due to an OS crash in a radiation therapy machine -- patients, already weak from chemo, were given several times the radiation dosage that they were prescribed. Unsurprisingly, some of them died
So, yes, these machines -- and, specifically, radiation therapy machines that crash -- can kill.
Uh, no. Do you work in the health care industry? I do as a software developer for a vendor. Don't throw the blame on us. We actually changed to Windows off of other systems because hospitals started putting PCs with Windows into their various departments. The backend for the software I work on actually runs in Unix, and we have hospitals that are thinking of going to NT only, which means we have to try to port our code to it or loose that customer.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
Why don't they design their software, so that it doesn't break when patches are applied?
You don't seriously believe that Microsoft gives anyone advance notice of what the patch is going to break, do you? Have you seen the ambiguous and undetailed language that goes with the WinXP SP2 patch? There's nothing actionable in there, certainly nothing testable. Until GE gets it and tests it, and authorizes it for the build, it's an astonishingly risky thing to install it.
21cfr11 mandates that only the tested configuration can be used, and if the hospital choses to violate that federal statute, they are not just at risk of screwing up their scanner, but they're technically in violation of federal statute.
I'm not defending Microsoft here, nor am I saying it's smart to have Windows in scanners, but it's there (less now than 5 years ago, but still there). The penalty for using it is that it's quite likely that some piece of malware _will_ find its way into the scanner. They're more vulnerable if they don't patch, they are going into an unsupported (and unsupportable) configuration if they do patch. The only answer is to not use Windows, but until all the 'doze-based scanners are history, they're stuck with it.
to quote:
The text of the Microsoft EULA from Windows XP Service Pack 1 and 2000 Service Pack 3 reveals the offending material:
By using these features, you explicitly authorize Microsoft or its designated agent to access and utilize the necessary information for updating purposes. Microsoft may use this information solely to improve our products or to provide customized services or technologies to you. Microsoft may disclose this information to others, but not in a form that personally identifies you.
The OS Product or OS Components contain components that enable and facilitate the use of certain Internet-based services. You acknowledge and agree that Microsoft may automatically check the version of the OS Product and/or its components that you are utilizing and may provide upgrades or fixes to the OS Product that will be automatically downloaded to your computer.
In short, this agreement gives Microsoft permission to scan your hard drive for information, "fix" security holes or other bugs via updates to your system, and while the company is there, it would effectively have access to other data on the system, which is where the conflict comes in. Better yet, the company can even let "designated agents" do this, an even more nebulous term that leaves Windows users with even less control over who is accessing their system, and what they might do when there. All of this occurs without the user's permission.
Remember, these are the same people who faked a presentation in front of a Federal Justice and told him over and over it was fact....
IMHO, the EULA parts that I've seen are so vague Microsoft could collect anything they want without worrying about legal action against them. After all, they are masters of vague verbiage in license agreements, are they not?
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Dude, you have no idea what an unverified binary does. You don't. Period. End of story.
I'm all for cutting through bullshit, but don't provide your own. Go read a book or take a class on basic security before you spout off.