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
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.
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.
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
Same with an automated clinic analyzer that does a dozen blood enzymes in one pass.
Some of these are connected with a satellite dish on the roof, but a lot are plugged in to a POTS.
Hell, even those Fuji photo minilabs at Walmart are plugged in to the net. And it's all Windows, all the time.
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.
This attitude is absolutely endemic across the IT industry and in no way is restricted to ISVs and VARs who use Windows.
We castigate OS manufacturers and writers endlessly for failing to produce patches quickly enough or indeed writing OS that have serious flaws in the first place but forget that the application writers:
A) Also write insecure software
B) Rarely follow best practice when writing their software thereby ensuring that when OS manufacturers patch their OS, THEIR APP. BREAKS.
I've lost count of the number of times I've run a snapshot, patched, checked it worked and run with an application rather than wait until the manufacturer gave me the say so.
They generally ask you to feed back the result to them. I do it, but extremely grudgingly as I'm doing the bastards testing work for them.
Other particular favourites are:
"no you can't run Anti Virus"
"no you can't run a software FW"
Anti Virus is especially annoying, particularly from vendors of media packages whose files I DON'T BLOODY WELL SCAN!
I wonder how many slashdot users know what endemic means?
Used to have a Slashdot account but have long forgotten both the name and password (gSePnAtMo!o@arseKYOMUfeck.org - work it out if you're interested).
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.
I have first hand experience with medical CT scanner development, and can honestly say that operator console techs browse the web on the operator console machine (running windows 2000) between patients. Pretty scarry. As if windows isn't bad enough, being on the web while controling a machine that doses a patient with xrays is crazy.
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.
Ryan is right. I work for GE Medical Systems. I've been here 23 years. None of our critical equipment has shipped on Windows (or other MS OS) in the time I've been here.
The FDA has put itself in charge of computer security. Drug manufacturers now have to comply with 21 CFR part 11. http://www.fda.gov/ora/compliance_ref/part11/
21 CFR 11 does not apply to medical devices discussed in this article--medical devices usually have a much lower standard of QA than do drugs. I expect that there is a similar regulation for medical devices.
I think that this regulation is so vague and general that it cannot be complied with. If you take it literally, it would be extremely expensive to comply. Most of the drug companies that I know are pushing ahead with doing the best they can, but they are spending piles of money with little or no improvement of drug quality, safety, etc.
Warnings are a very gray are of law. Regardless, all medical equipment manufacturers sell their equpiment with a "If this breaks, doesn't work, or even kills someone, we can't get in trouble. Use at your own risk and hope it works." kind of agrrement with the buyers. Otherwise everytime a defibrillator didn't save someone's life, or wasn't charged properly, or was placed on the wrong section of the body, or (insert some bad scenario here), the manufacturer would get sued. This saves their ass, including from software crashes and virus/worm infections. Once they sell, they no longer have any worries, although they will support it and provide maintenance. That's why a hospital may only buy from certain trusted suppliers and you'll see the competetion trying to assure them that they could have a superior product for cheaper if they switched. But many hospitals would rather stick with what works and who they trust.
Regards,
Steve
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.
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
Speaking of a radiation therapy machine with software bugs.....
/. a while back: An Investigation of the Therac-25 Accidents
This was posted to
Well, apparently Microsoft think they can do operating systems for medical applications. Personally, I can think of more suitable operating systems for the task...
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!
Seems to be the only solution that makes sense though. Fuck the doctors, they can surf pr0n at home! Seriously, why does the whole hospital network need to be left attached to the public Internet? Have a few stand-alone surf-stations available in the building so they can go look up stuff they need to. Though really, if my doctor *has* to go check something on the internet before he can figure out what to do with me, I'll just stay home, thanks. And if that's not what he needs the net for, he can do that shit at home.
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.
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
No, lets be fair.
It's far easier/convenient to work with a TCP/IP stack. So you simply hardwire the IP into the OS. Now, every single machine has the same private IP and can't be put on a network. Everything must be admined from a laptop with a crossover cable. This helps with it being easily administered and useable with some jockey with a windows laptop.
It's slightly off-topic since it's a industrial system instead of a medical one, but I have seen dozens of machines - generating RF radiation, pumping chemicals, electricity, etc...
... so there's some pretty toxic chemicals out there.
And every single one that I have seen - with one exception - has run some variation of Windows.
Incidentally, this plant manufactures memory
I'd say that I'm not worried, the systems will simply not pump chemicals if the OS shuts down... if I hadn't seen that they haven't even fully implemented a system that shuts a line down if there's a leak (on HF)...
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
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.
We have to spend a lot of effort making things work on Windows. Both on the instrument server level (because Windows programmers are "easier to find" and "cheaper") and on the user interface level (because customers are supposedly "used" to Windows, it's "just like at home" and therefore easier to operate - never mind the fact that we write a complete custom UI with custom controls).
Also, our instruments are used to generate images, which are usually assembled into reports (PowerPoint presentations, etc.). Of course, we strictly forbid the end user to install anything else but our own software on the machines, but it's with a big meaningful wink, and they usually do it regardless.
That also means that the instrument controlling PC ends up in the company (or hospital) network, so that images can easily be transported to the operator's desk when (s)he gets back after using the instrument.
That also means that the company's (or hospital's) IT department decides which updates get pushed onto the controller PC.
The fact that many popular virus scanners think it's so damn important what they do that they can run their scan at high priority, meaning the computer can't do much else, doesn't help either.
It's just a matter of time before somebody dies because the machine that was supposed to be scanning him instead was scanning itself for viruses. Oh the irony!
17 months ago, when my wife went in to give birth to our son, she was hooked up to a fetal monitor. It was a brand new piece of hardware (Dell I think, and I believe it was from GEMS), that was running Windows NT 4.0!!! I seriously wonder how they managed to get NT 4.0 to even support the hardware!
Just as she started giving birth, the monitor crashed. No one knew what to do, and I a Unix person, ended up having to get the monitor back up and running for them.
Sure. General description should suffice. While its true that the CT (and MR) scanners had a power PC in them, that power PC was NOT running windows...its been running VxWorks from day one. I should know I build the software for the damed thing...
Speaking from first hand experience here. The good IT folks setup all the machines concerned with patient care and treatment planning (radiation oncology & diagnostics in this example) on a seperate network from the general building LAN. This seperate network is secure, has no gateway defined and can't talk to the outside world except via a linux box that serves as a go between (for file transfers of various types)and is physically disconnected from the secure network when it's not needed. This works fine and dandy until one day a DOCTOR realizes that the new treatment planning laptop is faster than his office PC and demmands to be able to surf the intarweb with the better computer.
It might be different in a large corporate hospital but in smaller privately owned clinics the merest whim of a doctor trumps anything the IT manager has to say about the situation. So that's how the secure, private network get's compromised. Bunch of arrogant twits think that they're masters of the fucking universe just because they went to med school.
"Listen: We are here on Earth to fart around. Don't let anybody tell you any different!" - Kurt Vonnegut
I work in the Notwork&Suckurity-Deparmtent of a 10k-employees, 13-hospitals, employer.
Normally, medically important systems MUST NOT be connected to any notwork. This is good practice, and reduces the impact of your average exploit by around 99.(much 9s) percent.
The problem, though, is that all those great gadgets (and they're seen as such by the medical stuff) are even more sexy when you can get at their data remotely. Which is why we're pressured into connecting them to, at least, the infernal notwork.
And those "sexy" reasons are usually medically important, too, like, for example, looking at blood analysis data whilst having the patient open, surgically.
Add interdependencies that are so that you CAN NOT just build (n) gazillion networks, they all have to be interconnected in some way. And that way's called TCP/IP, alas. Add to that the need for suppliers to have remote access for support work, and you have those systems connected to the Big Bad 'net.
And don't forget that the actual apps are develolped in controlled, isolated, environments, and you can imagine that RPC-like communications are "secure" by comparison, so you won't have any luck with port-/IP-based firewalling, either.
That battle's lost, frankly. The next big worm'll show that. The argument always goes like "with this $gadget active (read: connected to the notwork) we could've saved $patients life". And, like it or not, that's a real-life KILLER argument. And you don't want to be the killer (BTDT).
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.
They billed my insurance company $300.
Okay, something doesn't add up. If this was your PCP and you had a traditional PPO policy or HMO policy, your doctor gets nothing for that visit unless he performed a procedure. Under 90% of plans out there your PCP gets a montly capitation fee that covers all your Level I visits. This varies by location, but $20 would be a big payment. That means he gets that $20 plus your co-pay (if you have one/paid one). The reasonable maximum he would collect would be $40. Which after significant overhead isn't unreasonable by any measure.
The other alternative was that it was a specialist. Right. That means they collected probably between $120 and $180 on that bill, not more. You probably paid a $20 co-pay, if that. That means they collected somewhere in the $150-200 range. During that time I can guarantee he looked at your chart to look for certain symptoms or signals. He did a brief exam. Chances are it was billed as a Level II or higher consult. (Level I is basically a very low-level visit.. cold, sore throat, etc). So okay. Level II or higher (it goes up to III, IV, V, etc) require documentation. That means he takes notes, and someone in his office or a contractor transcribes his verbal notes or written notes. Someone in his office then takes the piece of paper he used (sometimes called a voucher, encounter form, whatever), and enters that into their billing system. From here, it was probably sent to your insurance company dead-tree mail on a HCFA 1500 form. Six to eight weeks go by and a check is issued, and mailed back to your doctor, in a package with a hundred other checks. Someone has to open those, enter each one into their system, and write off the balance (since by law they usually can't bill you for that). Then, someone in his office has to assemble all the checks and bring them to the bank and fill out an asslong deposit ticket. Sometime in the next 6 to 12 months the insurance company will review automatically claims, and the office may be whacked for any errors that may have been made along the way. If for any reason the insurance company paid an unexpected amount, or rejected the claim, an office worker has to manually follow-up with the insurance company and find out why, and correct hte problem. Usually be re-mailing a slighly different HCFA 1500 form, and waiting another 6-8 weeks. Given that anywhere from 3%-10% of claims to 3rd party insurance companies are rejected, this is a significant part of any medical billers day. Often time claims are rejected at the end of a month or beginning of a quarter as a cost saving measure. You just get the run-around until the money crunch passes.
By the time your whole visit takes place, that doctor has spent no more than 30 minutes on your specific visit, yet, his staff has likely spent another 30 minutes of time, and possibly up to a few hours, to get paid on that claim. Not to much phsyical resources like software, paper, postage, phone time, and frustration.
If this was your PCP, and it's a single family practice, he's probably clearing between $80,000 and $120,000 a year. Up to $150,000 if he's been in practice for a long time or is in an affluent area. If he is a specialist, he's earning anywhere between $50,000 and $500,000 a year.
Either way, a single doctor requires between 3 and 5 office staff and a host of technology to properly execute a profitable practice. At the end of the month you collect between 33% and 50% of what is billed. It requires a minimum of 7 years formal education, and possibly 1 month a year in continuing education.
Unfortunately, the stakes here could be human lives.
Of course, if they don't patch, it could be security intrusion resulting in patients dying, protected patient data being accessed, etc., anyways.
I would think that a lawyer would have fun with the hospital in that case, for essentially they will have done nothing and said, "it's the HW manufacturer's fault". Isn't that known as lack of due dilligence? The suing lawyer is probably not going to add the hardware manufacturer to the lawsuit at that point. The HW manufacturer would just point their [middle] finger (and lawyers) right back at the hospital.
They never mentioned "embedded systems." The systems that they talked about are the most tightly integrated healthcare systems in the world. They're all about connectivity and information display and analysis. In short, they're all about that "office PC" in healthcare terms.
And GEMS and others are doing their best to treat that "office PC" as a specialized instrument, and telling hospitals "don't use it for surfing the internet! Make your network secure!" And the IS guys in the hospital say, "It's easier to just install the patch!" because all they understand is general purpose computers. That's what this article is about. It's not about pacemakers, it's about doctors' desktop systems, which run specialized applications for doing analysis and diagnosis.
P.S. The hospital IS guys are the ones who demanded Windows in the first place, for the office PC. Of course, forgetting that a doctor uses his office PC for things like running software that saves lives.
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.
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.
If you kill the plants through your cost-saving measures nobody is left without a mother, father, sister, brother, friend, or spouse. Nobody cares about the plants all that much. But human lives are different. So to hell with the plants, fine with me--but I sure as hell care about the patients.
By comparing the two, you are implying that human lives are no more valuable than the life of a few lobby plants. Perhaps a few nuts would agree with that, but personally I am disgusted by the thought.
I couldn't care less how often my local hospital cuts the grass. That doesn't affect my healthcare. But when they start cutting too many corners in the X-ray department I will look elsewhere.
The Cheese Stands Alone.
Agreed. From what I've seen, health diagnostic systems typically run QNX.
This whole thing reminds me of when I worked for a small engineering firm that was developing a new device for the blood product industry. They wanted to migrate away from the tried and trust analog systems to digit. The CPUs available at the time were 8080A, 6800 and COPS. They decided to hire two "experts" and use the COPS devices.
The "experts" developed a system that met the decided functionality. But, regardless of what they tried, the systems eventually locked up and had to be powered off. After spending thousands of dollars, the asked me (a lowly Co-Op) to see what I can do with it. I wrote a COPS 400 cross compiler and emulation system. Then, I went to work. Several days later, I had removed most of the bugs in the software. The system would still lock up, it just took a lot longer.
Frustrated, we called National and spoke with an engineer who was intimately familiar with the devices. When we told him what was going on, he asked why we were using that CPU. Then, he told us that that chip series was never intended for mission critical systems - they were designed for electric car seats and talking teddybears.
Meeting the standards necessary for mission critical or life saving equipment is a costly proposition. Vendors have to choose their hardware and software carefully. And, they have to certify all components in order to meet FDA guidelines. I would venture that most diagnostic equipment companies use proved components and proven OSs such as QNX or even OS/2 - It improves reliability and eases the certification process.
The fact that ANY medical diagnostic company would develop mission critical / life saving equipment using Windows scares the hell out of me. It's like the Navy deciding to build their new DDX class using Windows NT as the OS that drives all systems. Yup, like I'd want to be on a such as ship during combat and suffer a software failure -- Adds a whole new meaning to "Blue Screen of Death".
RD
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?
I also work in healthcare IT and appreciate much of what you say. While I am primarily IS/IT, I work very closely with our entire clinical informatics department and have learned so much valuable information about the general patterns and methods on how clinicians interact with patients and the clinical systems.
That being said, I would never have a clinician only person designing anything about a clinical system, data design, or have final say in a UI. They far too often will sacrifice security and authenticity in favor of being easier for them to work. They often just don't appreciate the risk in their suggestions from a system integrity view. Often they will do anything to avoid even logging into clinical systems personally. Their input is valuable but must be checked against a sane system design. Note, currently we do not have CPOE but it is on the horizon. We have systems from GE as well as many other vendors which have Windows used primarily as the front end (although GE uses it as the back-end also, which is a concern to me). The way these "front ends" are often designed, however, pushes most of the logic to the application layer meaning that a workstation compromise could affect the back-end DB (at least theoretically).
I have often looked at how these systems present a UI to the user and been confounded by how complex and error prone the interfaces seem to be. And I have dealt with too many clinical users who have tripped up on these very things so I know it isn't just my interpretation as a non-clinical IT person.
The more Windows is used strictly as a front end UI the safer I feel. Conversely, the more it is involved in the logic and "integrated" into the back-end functions the more I am concerned about these systems being compromised and a host of other related concerns.
With HIPAA and all the concerns IT industry wide about security, I believe the landscape is going to have a rapid change in the next few years. I think if MS (and other vendors) don't secure their software soon they will find themselves in the scrapheap because people's attitudes are going through a drastic re-alignment in priorities right now. In healthcare things change much slower (implementations take years and multiple phases, decisions are made to cover decades not months or years), but I believe they will change because no one will be willing to continue to take the risk that the vendors should have been taking from the start (a.k.a. we are not to blame for anything style EULAs).
I previously worked in software design so I understand the vendor's side of things to a point, but too many areas are much too sensitive to keep the status quo.
My $0.02 worth...
I very much appreciate your comments. I do not believe that a clinician without some understanding of the technology is a good person to get feedback from if I gave that impression. I actually had unpleasant experiences in 2 cases when I was blissfully ignorant of the EMR complexities and tried to build them single handedly for a couple of small clinics.
Most departments in here have at least 1 physician who is quite tech savvy and generally champions technology. Others usually listen to him. So it is nice if you can work find someone like that
I agree with the point that physicians try to circumvent security for convenience but can we blame them? I recently came across one such system that would encourage this behavior. The system has a backend and 2 front ends. Neither front end displays the full data set and only allows a user to login in only 1 session. So the user has to logout, login to the other front end, get the data, logout and login back again. If they made me do this several times during the day, I would find a way to circumvent this (Cache password in the browser based front end, have the nurse or somebody leave a session always open). The problem is, we have too many independent systems each with their own authentication. It really gets in the way of a busy day's work. Till we have integrated system, this problem may not go away. I often like to joke, monopolies may be a bad thing but at least for now in health care, we need one so we can interchange data more freely.
Many current health care software providers also disregard open standards. They use their custom data storage schemes making the prospect of migration a scary one. Nobody is up at arms at vendor lock down on niche systems.
I like to see health care systems to be highly adaptable since their need to be so is greater than an average business application. I would like to see Agile programming practices to create solutions based on service oriented architecture running on open standards on a proven to be secure server. The UIs then can be whatever physicians want.
I agree with your point about CPOE UIs. The UI of some of the special purpose software our clinicians use on the workstations looks as if they were authored by some one who just learned GUI design without any knowledge of the existence of user interface guidelines of the OS vendors. The text boxes have non-standard sizes, buttons have poignant colors. Microsoft and Apple have made excellent documents available on how UIs should be standardized and they appear to be disregarded in many clinical software. Business software is typically more adherent. I am doing my PhD and the role of user interface guidelines in CPOE interest me a lot. I may choose it as my dissertation topic. There should be a set of guidelines for CPOE UIs drawing from existing HCI work.
I will make a quote that may invite flames in a Slashdot board. I don't recall the name of the person who actually said this (I heard this second hand) but "Open Source has not proven itself in niche markets". And I can agree with it. In OS, browser, developmental tools etc when the path has been well tread, open source has proven that it can improve quality. In niche markets, the vendor can get very protective about the product. The product by itself is not often revolutionary in terms of technology and the vendor can easily be displaced if a worthy competitor shows up. I can't at the top of my head think of any niche markets when an open source solution dominates or is at least a sensible alternative even when proprietary solutions compete. Perhaps the reason is the lack of large enough communities in these markets to start a public project.
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.