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."
Why is hospital equipment running windows? Anyone that knows anything about embedded systems with high quality requirements know that you stay away from large OSes. Even Linux is avoided unless you need tcp/ip and if you don't then its better to have a small maybe even off the shelf OS. The Key is to limit the testing requirements and limit changes, which are goofy to test a life support system just to have the latest and greatest IE 6 or 7 that you shouldn't even, have hooked to a wide-open Internet anyway.
Why are they even accessible on the internet? Seems like these should be in a secure private network unlikely to be attacked.
pshaw! what's a few human lives when network security is at stake?
OK.... We now have the Food and Drug Administration in charge of computer security?
Why are these things on any sort of publicly accessable network? They should, at least, be on a private network that's physically separate from everything they don't absolutely need to talk to & firewalled all to hell.
my sig's at the bottom of the page.
...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
Okay, so MS fixes all its ports so they are closed by default and it breaks SQL but ups security...any great shock vendors don't trust customers to apply patches that haven't been tested by the vendor first?
MS isn't going to get hordes of screaming and angry customers, the vendor is. It's a catch-22 and odds are pretty good stuff is going to break because it was easier to do it fast than right.
scary new meaning to blue screen of death.....
Medical machines responsible for human life should never need to be patched. The software was tested at one point and should be controlled to stay at that test point until it is to be retested. For machines running windows this means they should be segregated from other parts of yoru network and should be airgap firewalled from the rest of the world. Intenet worms and email trojans shouldn't be relevant.
Wouldn't it also be alot more likely that a patch would make it through the testing phase without crashing anything important if the patch maker had access to the source code of the OS?
So...add another argument!
I say Open Source for our health.
You teach a child to read and he or her will be able to pass a literacy test. - George W. Bush
Look before you leap ...
...
Not only is IBM showing evidence of compatibility issues with XP SP2. Microsoft's own software is also affected. Earlier this week the software vendor released an update for Microsoft CRM 1.2 because SP2 will prevent the original application from running correctly.
Because of the broad changes, analysts have compared the XP service pack to a Windows upgrade instead of a simple update. Business users typically take much longer to install a new version of Windows than a service pack because of compatibility testing.
IBM says "dont patch"
IBM, for one, is holding off on installing the security focused update for Windows XP. In a note headlined "To patch - or not to patch" posted Friday on its corporate intranet, IBM tells its employees not to download SP2 when it becomes available because of compatibility issues.
Comment removed based on user account deletion
I'm not a big fan of Microsoft, but I don't think the quality (or lack thereof) of their products is the issue here. I've read from their EULAs that their products are not suited towards critical applications (ie nuke facilities, life support). My point is that although a EULA is not a legally-binding contact, the fact that MS is stating in public Windows shouldn't be used in critical applications should tell you something. The bottom line is that if GE, Philips or Agfa build a medical system, they should be responsible for that product from the software up to the hardware. The fact that *they don't have control* over one of the components in their products (the underlying OS) is negligent, IMO.
I would get laughed out of court if I tried to blame a critical problem with a report I wrote on my secretary, and the same should happen with these companies if somebody's loved one dies from their irresponsibility.
Bill Clinton: Pimp we can believe in. - The Shirt!!!
Crap! Who put that wireless card in this heart lung machine? Oh no! I've been slashdotted...
Idol Star Astronomer
Survery says... Beeep! Beeep! Beeep!
What "security" or other risk with a turnkey standalone system? I'd rather risk the remote chance of someone breaking into my room to run CAT-5 to my vitals monitor rather than a BSOD (possible REAL death in this case) because Service Pack x broke some obscure function and failed to alarm the nurse when my heart stopped.
Do the morons at the hospitals run Windows Update on the defibrillators?
The manufacturers have tested and retested and regression tested everything that goes into those medical devices (or they say, anyway), so why deviate from a known good combination without a compelling reason?
This comment does not necessarily represent the views and opinions of the author.
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.
Of course administrative computers used for record-keeping do run M$ mostly (somebody should point out to the HMO's how much money they'd save with Linux! They'd be onto it in a shot). But the "patients lives on the line" threat there is not as great as the having faulty code controlling a laser in a brain surgeons hands.
I suppose that M$ must be developing a real RTOS for use in medical machinery. They would have managed to get in some OS variant into some non-critical systems. And they will probably penetrate the critical medical systems market at some point in time.
That would be a bad time to visit a hospital.
See that long UID - that's what you get for lurking too long
I'm sorry, but no matter what OS these devices are on, WTF are they doing on a generally available network where they can be crashed and where security updates are necessary? They should be completely isolated!
This is not so much a Windows problem as opposed to a lazy network admin's problem.
Isolate those damn machines!!! Don't have network ports just opened everywhere! Come on, this is why network admins get paid the big bucks!
I used to do IT work for a hospital chain in Austin and there were no devices that could "kill" a patient if windows crashed. Windows was only on the workstations ant there were multiple workstations in the area so if one crashed the user could go to another one. If Phillips & GE are planning on using embeded XP as an OS for their medical machines then they are the ones putting the patient at risk.
MS patches before have caused considerable slowdown and possible icompatabilities before(that isn't to say they are the only ones with bad patches). If your computer slows down or has a problem, it's a minor inconvience, imagine what would happend if a life support machine went down. There is no way that MS can test for every conceivable setup, they just try to get the most general problem down and rely on others to test them on their systems. :P
The problem is using an operating system that was meant for the home/server for a much different purpose, in this case running life support machines. The things were built 8 years ago, but even then there were OSs made for embedded systems. Now there is real-time embedded linux. While I'm not going to say it's perfect, it has what is needed and nothing more
The more features you add to a system, the more places you have to exploit it. Minimalism in design is always key
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.
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
Pshaw, what a pant load. Here's a more rational look at this.
1: Chances are, your life won't be at stake. Any doctor or nurse worth their salt should be able to keep you alive without a computer. It's not like it's sitting in the room beside you, monitoring you. At least, not one running Microsoft
2: Any System Administrator worth his/her salt never, ever, ever puts a patch on a critical system without first testing, testing, testing on another system.
3: Also, any System Administrator with half a brain puts some type of firewall in place between the world and critical systems.
If the above three conditions are not true then the failure has occured in more important places then Microsoft or the Software Provider.
And BTW, Linux is not the solution here. Sure the vendor might be able to put together a fix faster with open source but there would still be some lag time; assuming the software vendor chose to make a fix at all and not take the same attitude they are taking with Microsoft.
It take more faith to believe in evolution than it takes to believe in God
They *are* worried about malicious activities (e.g., worms, breakins, etc.), because that's the whole reason they're talking about patching.
The whole point is that a hardware firewall mitigates the need to patch for those reasons, and leaves the OS in a state that is supported by the vendors for use with the specialized equipment and software.
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.
Firewalls won't help. If it runs Windows, some idiot's going to bring in a CD full of pictures from his latest vacation and the CD's going to be infected with MyDoom or (heck, probably and...) Sobig or any number of other nasties. Or it's going to be something he wants to print on the nice laser printer at the office.... there's a hundred ways to get infected just by clueless users.
Pretty soon, the internal network's either too busy generating random traffic to do anything else-- and even if the Big Iron of the business, the dialysis machines and heart-lung devices and all those wonderful things that better damned well not break work fine, you've still got the terminal the nurse sits in front of that keeps track of when to issue you your shot that keeps you alive spending half its time rebooting because it's got Sasser.
This is not a problem a firewall can solve, and it's pretty darned big: You can't go throwing software around willy-nilly to solve this problem (even though the real problem is that the users _are_ throwing software around willy-nilly), so you can't just go "oooh! A next-day patch from Microsoft, let's hope their two hours worth of QA before it walked out the door was good enough!".
-JDF
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.
The article on informIT.com is 3 months shy of being 2 years old.
SP4 solved any lingering questions about HIPAA and auto-update, but auto-update was always an option, and the act of disabling it made the system HIPAA compliant anyway.
Ongoing questions about what "due diligence" means have yet to be decided. We're still waiting for the first lawsuits based solely on a medical office selecting Windows in the first place.
The fact that people are installing patches on these machines against recommendations to do so scares the living shit out of me. I know that these people have good intentions but the road to hell is paved with good intentions. They don't know all of the variables. Some patch might introduce a new feature (something that does happen from time to time with MS patches) that causes the software to malfunction. This could cost lives. I really think a $50 firewall box would be a much better idea.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
> Unfortunately, the stakes here could be human lives.
Soon to be made into a movie starring Uma Thurman.
It's called "Bill Kills".
assert(birth_date<time-86400)
I don't know how GE and Philips do their stuff, but in the systems that I work on, the computer that controls the actual X-Ray's and gantry movements don't use window's, its a custom, very stripped down version of Unix. We do use windows in several other of our devices, such as the imaging system. But if any of those systems should go down, the worse that will happen is a loss of image quality. The doctor will still have X-Ray, and Gantry movement, and the ability to remove the anything he has in the patient, or even continue the proceedure. It won't look pretty, but it will still work.
I can't imagine Philips and GE doing any differntly. None of the medical manufactures want to take a chance of putting something critical on a windows machine, and killing a patient due to a windows system crash.
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.
"Why, exactly? Because nobody would know how to hack your tiny little proprietary OS? That's crap and you know it."
The reason it the smaller the OS the less you have to test it. The whole KISS thing. Keep it simple stupid.
On a standalone ebedded system you do not need support for TrueType fonts, every printer and USB device known to man, or even video playback. On an Embeded device you often only need a few functions but those functions have to work. If you have ever programmed under windows you will find all sorts of APIs just do not work or do not work the way they are documented. Windows programers just program around these issues. You should always use the smallest OS that you can get away with for the device you are using. Linux is a good option for very flexable embedded devices. I would tend to stay clear of X and use nano-x myself.
There are many off the shelf ebeded OSs the most popular I can think of is QNX. For life critcal systems I would go for QNX over windows any day.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
on life-safety equipment, why in hell is ANY outside operating system in use??? you CAN control bugs in your own code if it is YOUR OWN code. get back to machine language FSMs for the specific purpose on a piece of hardware like a monitor. it is irresponsible in the extreme to rely on somebody else's box 'o' bugs as part of your life-safety system. period. anything in that realm that needs wide access should have an outboard trusted "my code only, dammit" interface that the wild wild web plugs into.
basically, it's just pseudocode that anybody is writing any more, anyway. flip it through a different compiler, a cheaper machine language compiler, and debug with a logic analyzer if you have to. this is what the better high school kids were doing in the late 60s and early 70s, anyway, kids like wozniak and gates and kildall. wasn't any rougher for me to debug in the late 70s and early 80s than anything else.
if this is supposed to be a new economy, how come they still want my old fashioned money?
we both were terrified and shocked for a second before the doctor stopped the scan and rebooted the scanner. It came out normally next time. She said it happens once in a while every April 15th. Heck man i plan to sue GE for using Windows
"Doing what i can, with what i have." ~ Burt Gummer
Sure, you can modify the Linux kernel. But if you do, you don't have a million man-hours on your modifications.
The distinction about "off the shelf" is between that and "roll your own". Off the shelf would include vxWorks, Green Hills, and pDos and OS-9 (if they are still around), and probably a few others.
I'm most familiar with vxWorks, so I'll talk about that one. If you don't need, say, TCP/IP, you can simply take it out. Your memory footprint just went down. Don't need memory management? Don't put it in. Don't need disk support? Remove it. Need to initialize something before the kernel starts time-slicing? They've got a standard hook for that - no hacks needed. Want to run on a PowerPC chip? Supported. Motorola ColdFire? Ditto. MIPS? Ditto.
Back to quality: The core code of an embedded OS has been beat to death in that environment, and proven rock-solid. No "if the wrong interrupt comes at just the wrong time, it goes off into an extended thrashing session for several seconds". Their customers simply won't put up with the kind of semi-broken behavior that Windows exhibits all too frequently.
My wife and I had twins in March - our first (two). When we arrived and were assigned to our room, a nurse came in and put two fetal heart monitors on her. I, being the geek I am, was interested in the computer and software that the nurse was configuring and looking at. It turns out, the computer was a standard off-the-shelf HP running Win2K and the monitoring software.
:)
It is a standard desktop app with a bunch of fancy bar graphs and options buttons, a view for a single monitor, or I could switch to a multi-monitor view and watch all of the monitors in maternity from that machine. I know all of this because I played around with it while waiting (it took a while
The sofware is designed so that the nurses can monitor all of the rooms from the nurses' station or from any room. It's a good idea but the security involved is a joke. I don't suppose they anticipate every new dad coming in to be a curious geek but any moron can see that it's a standard windows pc running a standard windows app. Had I not been so tired and had more presence of mind, I may have tried to browse the web with it just to see if I could.
In any case, leaving a machine like that unlocked could be as much of a risk as leaving it unpatched. The maternity ward is a lock-down environment from a physical security perspective and fetal heart beat monitors aren't quite as critical as the iron lung but the ramifications are the same. Some wandering kid roaming the halls sees a Windows screensaver somewhere, associates it with *internet* and it's lights out uncle charlie.
If you do what you always did, you get what you always got.
They are.
The ultrasound machine that they use on you isn't running windows.
The computer hooked up to it, which handles the image analysis, display, and archiving, however, probably is.
Vintage computer games and RPG books available. Email me if you're interested.
This is just one of the many huge problems inside hospitals these days. Many people do not realize how often just a simple name and patient number gets assigned to the wrong person. Records get swapped with someone else or a gender or age gets changed. All these life threatening mistakes are human error. The problem is that the transcriptionists get paid per word. Not whether they word is correct and the document they transcribe is correct. It's also all about money and internal politics. They choose systems not based on whether its a good match for the hospital and the patients but based upon which board member is in bed with which company. They'll spend 10s of millions of dollars on a new system just because some higher up gets a kick back or has a golfing buddy. Then the system turns out to be total crap and they start the process all over. All the while they raise their cost of doing business and push it off to the patient.
Knowing what I know there is no way in hell I will ever go to a hospital unless I'm already dead. Cause they'll kill you just sitting in the waiting area.
Kinda give a new meaning to the blue screen of death huh?
"Capital punishment makes the state into a murderer. Imprisonment makes the state into a gay dungeon-master"
The problem is that staff need connectivity to application servers, and the same staff need access to a ton of other servers, including outside governmental services on the Internet. You can't segregate the "critical" servers from the user's PCs very easily, so the "critical" servers are usually one hop away from the Internet, via the users' PCs. In any case, the managers making decisions where I've been can't make the case for putting the users through the increased difficulty of doing things securely.
:^)
Another thing is that we're under huge pressure to give physicians and radiologists access to data via the web. This could help save lives, if a patient's physician can look at their ultrasound, etc from his hotel while he's on vacation, etc, but the price you pay (which never counts for much with our managemnet) is decreased security. I am in this situation with some SW vendors who refuse to support a system if we let Windows Update automatically patch their system. They're afraid that they'll waste some support time on a problem related to a M$ patch breaking the OS or something their code depends on. I'm tired of seeing services killed and machines hung by what appear to be patchable exploits, so I'm doing it anyway. By doing this, you're giving the vendor a "get out of supporting their own app for free" card.
A final perspective is the class war between technical folks and the suits, who in my health care career have been non-technical folks who don't really like or understand technology, just data and applications, and in my current case, who seem to have a psychological/emotional problems with technical people in general.
When a clinical staff member here asks for some new functionality, or complains about having to change their password, management always comes down on their side, security be damned, because the implication is that if we require clinical folks to do _any_ extra work, or don't give them some new one-click, time-saving feature, we are impairing their ability to care for patients. It's the same way with supporting applications or hardware after hours, if a printer's jammed, it's perceived as being equivalent to a patient bleeding to death. Oh my god, it's "affecting patient care"! That's one of the reasons management doesn't want to tell a clinical user "no" Any time we say "no" we're perceived as being a problem. Those types of users can't see far enough don into the technical aspects fo things to understand the threats, just that they have to remember another password, or click another button.
Enough of this ranting. I'm getting disgusted with the whole thing all over again!
If you can't tell yet, I've had enough of being a technical proletariat. I'm sick and tired of dealing with Microsoft OS's and applications, and since there's not much else IT work in our area, I'm starting a new career in teaching with taking a 40% pay cut to teach at a local university.
By this weekedn, this will no longer be my problem
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.
Are there really systems that human lives depend directly on that are running Windows?
If my life ever depends on some software, I want the operating systems and all the other software to be mathematically proven to be correct and I want multiple backups/failsafes present. I don't want it to be some VB app running on Windows because it's quicker and easier to develop.
[Gates] (pointing to a machine with lots of flashing lights) And that is?
[Administrator] Aha, that's the Windows XP machine that goes "ping"!
[Gates] (beaming) Very good... very good... and the patient? What's she here for?
[Administrator] She's shortly to give birth, Mr Gates.
[Gates] A birth, eh? So what's one of those then?
[Administrator] That's when the doctor takes the baby from the lady's tummy.
[Gates] Ah, I see. And will you be using the machine that goes "ping"?
[Administrator] Of course, Mr Gates.
[Gates] And you'll be wanting the upgrade of course...
[Administrator] Upgrade, Mr Gates?
[Gates](putting his arm round the adminstrator's shoulders) Administrator, as of Service Pack 2, your machine that goes "ping" will become a machine that goes "thweep ftang chortle whoop".
[Administrator] Really, Mr Gates? Well, we'd better have one of those then.
[Gates] (taking out a pen and a contract) Excellent! Well, if I can just have your signature here and a deposit for £100,000, I'll have the upgrade winging it's way to you first thing in the morning.
[Administrator] (after signing contract and giving Gates a cheque) So, any other questions, Mr Gates?
[Gates] (beaming) Yes, actually there is one. The patient? What's she here for?
[Administrator] She's shortly to give birth, Mr Gates.
[Gates] A birth, eh? So what's one of those then?
etc.
Gentoo Linux - another day, another USE flag.
But there are a lot of applications that are not themselves critical, but could play a part. I work for a company that does materials management software for hospitals. This stuff is tweaked for efficiency, and hospitals rely on it. It runs on Windows only. Doesn't sound quite like the importance of a pacemaker, right? Well let's say the hospital gets hit by a virus. Yes, it happens, even with firewalls. Now their materials system is fubar, and they are used to it having the right supplies on hand at the right times. If it is low on something, it reorders it automatically. Now they are screwed, and they don't have something that they really need. Someone could die.
Hospitals have to operate on razor thin margins, and they can't stock millions upon millions of dollars of everything. They look to lower their on-hands inventory as much as possible.
There is all kinds of software in the hospitals that can go horribly wrong, not just the obvious stuff.
My beliefs do not require that you agree with them.
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.
That's a good question. I think there are a number of factors.
1. The uninsured who are clogging up the system and sticking us with the bill.
2. Increased litigation costs as doctors have to pay higher malpractice insurance, they up their prices so they can stay profitable.
3. Large numbers of the eldery who need expensive treatments (such as hip replacements) end up pulling more money out of the system then they contribute (thus our premiums go up)
4. Every increasingly complicated legistation that forces insurance companies / hospitals to expend more man hours shuffling paper. i.e. HIPPA.
That's just a couple things I think might be the cause. I'm sure there are dozens more.
Yes Francis, the world has gone crazy.
Configuration Management means:
- controlling the Configuration of equipment, in order to ensure consistent behavior.
Unfortunately, Configuration Management often does not take into account the fact that when you put a system on a network, it becomes part of a larger system, and unless you manage the entire network of systems, then you cannot really control your conditions, nor can you ensure consistent behavior.
This needs to be taken into account as a basic "sky is blue" assumption of Configuration Management.
Sadly, it is not.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
This has been a real problem for a very long time in many industrial applications. And it is not limited to the OS but the box as well.
The temptation is way to great for the bean counters and greedy sales typs to switch the robust hardware and OS for the commodity type and save a bundle up front.
Consider a $500 PC and an $2500 industrial PC. If you let the bean counter do the math he will tell you about the 3ghz P4, GeForce 4 100 gig hdd v. the P3 20 gig with an average video card.
Then you explain that the OS's have the same disparity in cost and he starts to get confused
I have said many times before that we have Windows not because it was best but because it was cheapest. Same with the clone PC. MS got to be the default OS because it was generaly 50% of what the other OS's were.
Now when it comes to saving lives the cost should not matter, however, it is still a business. And there are still bean counters and greedy sales people who get to make some very powerful decisions.
I am a biomedical engineer at a USN&WR top 20 hospital, working in the cardiology-related departments. We do have medical devices, including patient monitors, that run in Windows OS's. One is the Witt Biomedical monitors we have in our adult cardiac cath lab. The software was originally written to run on MS-DOS and really only runs on Windows 2000 to provide a GUI for the nurses to point-n-click. It uses Windows file sharing but doesn't even utilize print services. The whole thing should have been rewritten about ten years ago but Witt already has over 25% market share and is trying to compete with the big dogs like GEMS (GE Medical Systems) and Siemens. The old Siemens Cathcor monitors we used to have ran on *nix but the brand spankin' new GEMS Combolab we got for our pediatric cath lab runs on Windows XP for the nursing stations and Windows 2003 for the servers. The Siemens Axiom Artis x-ray angiography systems in our adult cath lab runs a mix of OS's, such as Windows NT (soon to be XP) on the Host-PC, Vertex on the Real Time PC, Neutrino on the Real Time Controller (the truly patient critical part), and Windows CE on touch panels and displays. Siemens will tell you all about their "revolutionary OS" called Syngo that will, to paraphrase, "provide one user interface for all imaging modalities" but it's really just running on top of Windows NT/XP. The intravascular ultrasound machine that we have, a Boston Scientific Galaxy runs on Windows NT. Even the Kodak laser printer we have for printing on x-ray film has a DICOM server running Windows NT. All of this runs on the hospital's open network and has been disconnected for either being actively infected with a virus or for not being patched.
Now a lot of our stuff is not Windows based. Most of it I don't know what OS it does run on (perhaps proprietary information) but I can say it doesn't appear to be Windows. Philips Intellivue MP90 networked patient monitors, Datascope CS 100 intra-aortic ballon pumps, and Worldheart Novacor left ventricular assist sytem (think artifical heart) all have their own software. Some systems that use 3D modeling, like the Endocardial Solutions Ensite 3000 use SGI workstations and software.
Many of the CT and MRI scanners I see, patient monitors we put in, anesthesia carts we employ use non-Windows operating systems, not because Windows is considered unstable or insecure, but because medical IT is so far behind due to the years it takes to get FDA approval on new equipment. Many new systems do use Windows because it's easy to work with and easily networked. For instance, one cool new system (the company and name I don't know) allows an anesthesiologist (who monitors 3-4 CRNA's in as many OR's) to see blood gas waveforms and other vital signs on one of those little clear screens three inches in front of your eye. It uses Wi-Fi to transmit the data to a Windows embedded device in the doctor's fanny pack. It goes without saying that we have incredible signal strength on our wireless network all over the OR area; you wouldn't want a dropped connection there! All of our clinical workstations and every office computer is Windows NT or XP.
I cou
You even get this in embedded systems, where the vendor is supplying the entire system and the customer's never going to interact with the OS directly, and still the customer demands this or that particular OS. And these days that's generally Windows. It's nuts. It's like demanding you use a bubble sort instead of a shell sort. Five years ago you had customers telling you that they're glad you're not using this newfangled Windows stuff, now they're pushing Windows on you...
Preface: this is NOT a Microsoft/windows bash..
Why in the world are they using a desktop operating system of any kind on medical equipment?
I wouldn't care how stable it was, that doesn't belong in that market.. Embedded systems that are dedicated to the need are what should be used...
---- Booth was a patriot ----
I am in the middle of the largest medical center which has departments in the top 10 US News and World Reports. The IT system that everyone uses is, however, completely windows based. The systems we use to access patient labs, reports, etc are Windows based. Windows users, but not mac or linux users, can access the data from home/office using VPN technology. I can see MRI, CT, and radiology online but I am unable to look for the scans by anything other that those that are patient related - looking for scans I ordered or having a patient list for me is too complicated for these systems. Lab systems are the sameway. Incredible, there are no functions like tell me what labs are new, tell me my patient labs, how about a screen with all of todays labs.
As you can see, we are way behind in using computer technology. They will wake up to the benefits of different type of systems about 10 years from now.
Over the last 10 years, everyone's become accustomed to Windows. Everyone has Windows. Once everyone got Windows, they wouldn't use anything that didn't work on Windows. So, vendors began migrating everything to Windows. (I used to work for a software company and now work at a hospital). So now, all the vendor's software runs on Windows, and probably runs just fine... provided the Windows version remains the same as the one it was tested on, no patches are applied, and no other apps are installed onto the same machine. But, users are used to running everything they want on Windows. That, after all, is the point of Windows. Plus, Windows is way cheaper than other options. Not to mention training. So, we're stuck with Windows apps, and there's really no cheaper alternative out there. This would be fine and dandy, if the only problems with Windows were worms and viruses. But no, like regular windows, Windows breaks really, really easitly.
Even the few vendors I've seen who have balls enough to release a Linux version of their software are tied to specific distributions, specific kernels, etc.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
The real problem is not all about patching. Many of these medical devices that rely on Windows are running on default installs. It is nearly impossible to keep a machine with a default install of Windows from getting a worm or virus when attached to a large enterprise network. Worms travel too quickly. Vendors and IT shops are blindly applying patches without testing them.
If the folks building these machines would take the time to turn off unneccessary services, and do some basic hardening (there are several excellent hardening guidelines for Windows avaialble from SANS, NIST, and other places) many of the worms would not be as big a problem. Couple this with some firewalling, IDS, and logical network segregation (as mentioned in the article) and the patches become less relevant.
I work at a hospital and am working with teams developing FDA-compliant medical device software (much to my chagrin they are using Windows). The server build they have developed has been deployed in "the wild" for a couple of years without MS patches and without infection. Why? because they are only listening on one port and have taken the time to disable a bunch of unneccessary stuff.
We need to change the way we look at security flaws and build the machines right in the first place. We can't rely on patches as the sole means of securing systems from every worm that comes along -- especially not when the systems are providing medical care!
Seriously, is the REAL problem the OS? I think the REAL problem is insecure networks. Lets think for a second about all of the Windows/IE vulnerabilities in the past several months... how many of them matter if you're not connected to a network? Windows 2000/XP in my experience has been quite good, and when properly maintained (ie: no junk installed), provides a very stable platform. No one should be "surfing the web" from the deliberation machine, nor can I really see why it would need a serious network interface.... Let alone access anything on the internet! I think what hospitals REALLY need are security experts to take a good long hard look at their network and decide what SHOULD, and what SHOULDN'T be on the LAN... and if some level of network connectivity is needed (ie: the ability to monitor equipment from across the hospital), this should be on a totally separate VLAN with NO access to the internet.... Internal routing only, no exceptions. Computers connected to this LAN wouldn't have removable media bays, so the threat of worms, etc should be mitigated by general inaccessibility.
I know everyone on Slashdot would LOVE to blame the OS, but really... the fault is not with the OS as much as it is the networking admins, and even more likely, the administration for not providing the NAs with the support they need to make a properly secure network.
Medical device manufacturers may be required by law to do months of testing before their systems can be modified.
A long time ago (more than long enough to forget, or muddle the information), I did some research comparing ISO 9000 quality standards with FDA part (whatever it is) dealing with certification of devices for medical use.
Along with myriad QA requirements that would choke a fortune 500 company, one of the things you have to do to be licensed is certify any and every vendor on whom your device depends. This puts many companies in the position of having to certify that Microsoft's operating systems are reliable enough for medical applications in order to ever ship a product.
To me, it was a laughable yet frightening circumstance at the time, as I wouldn't have certified Windows of the era to be suited for any purpose at all, much less critical medical applications.
So the point is, those manufacturers may be required to do full testing on any change to their vendors code in order to retain their certification.
All of this may be total nonsense by now, these many years later - there may even be some who say it was never true. To those folks, I say - I read the specifications myself, and interpreted them to the best of my ability. Did you? Just because many people accepted the use of MS software in these applications doesn't mean the actual requirements weren't swept under the rug with a wink and a nudge. After all, what else were they going to use?
There is a case for cross-platform tools at the moment too. It is a case of mobility. Most doctors like to be able to review a patient's case online and advice on the phone when necessary. Many vendors provide web pages and applets for this but they often end up very unergonomic. But since the need is often information retrieval rather than data entry, they are accepted in the absence of the better alternative. XAML, XUL and J# browser controls may improve the situation..
Personally, I don't think the issue here is tools, it is design.
Separation of concerns as promoted by technologies like XAML and XUL is a Good Thing, but it doesn't amount to having good design. In fact to the degree it leads people to think that a good design can be bolted on to an application SoC is a Bad Thing.
RAD tools tend to produce mediocre results quickly. Since this is better than most outfits can manage on their own, RAD tools are a Good Thing. To the degree that some people need excellent user interfaces, RAD tools are a Bad Thing.
I've spent many years creating systems with bad, or mediocre user interfaces, some with RAD tools, some without. In general, they have been Good Enough. However, every so often there comes a problem that demands an excellent user interface. It's easy to tell when you need an excellent user interface: you get a nasty feeling in the pit of your stomach when you contemplate the characteristics of the user vs. what the system is supposed to accomplish. Here is what I have learned from dealing with those situations.
An excellent user interface has to balance competing interests. It's like designing a race car. The car must be extremely light so that it can accellerate quickly. It must also be stiff so the driver can control it and strong to protect him in a crash. The concerns of lightness and strength oppose each other, so the designer must make tradeoffs, using his knowledge of physics and racing to save weight where strength is less critical, and sacrificing weight where strength is more important. That is the essence of design: making shrewd decisions.
A mediocre interface is easy: you build a database design (for example) and you basically make the user manage the updates to the tables you have created. There is room for screwing up, for example creating visual noise by failing to balance whitespace or using color or fonts in a way that is distracting. This kind of screw up is easy to fix with SoC. However, there is very little room for improvement. I think this is way MVC is so seldom worth the trouble. It solves an impedance mismatch between task and state, but most applications have such crude models of the task they hardly justify such elegant engineering. They are better done quickly and set aside.
In designing an excellent user interface, you have to balance speed and convenience (lightness) to the accurately and precisely manipulating information (strength). In very demanding interfaces, you have to marry the normal and exceptional task flows to things like database table updates that reflect an alternate organization of reality that may have little meaning or significance to users (unless they ever happen to be wrong!). It amounts to managing two separate, complex domains that interact with each other in complicated ways. Neither of these domains can be perfectly stereotyped (e.g. invoice/detail), although it is conceivable something like a design pattern cookbook could be created.
In a highly task centric user interface, there is always room for improvement.
SoC is a kind of best practice, and technolgoies like XUL that promote it are in themselves a Good Thing. However, it is best practice in a very narrow aspect of system and user interface design, and to the degree people treat it as comprehensive solution to the problem of user interfaces (e.g. the concept of a bolted on interface) it can lead to harmful design practices. Separation is an imperat
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.