Slashdot Mirror
Medicine And Open Source?
A reader writes: "The British Medical Journal (BMJ) has an editorial on Linux and open source (BMJ 2000;321:976). Also available
online." There's been a lot of attention about medical usage of open source software, but not for the typical free reasons, but because when lives are on the line, you want to be able to depend on software not to crash, and open source has a well-deserved reputation for stability.
I'll probably spent my whole life behind a computer destroying my body. But i get to write the program that will keep my pacemaker going later. That would suck if my heart Segfaulted.
I work for a company that develops software for emergency call systems and for security applications. These are enormous systems monitoring fire alarms, burglar alarms, freezer alarms, and emergency call devices, like wireless pendants and wall switches. We also do some cool stuff like CCTV control and Text-To-Speech alarm annunciation over hand held radios, but that's not the point.
We've found that open source software is definitely the way to go when your hardware and software must be fail-safe (since lives are on the line). We originally had all our embedded boards running an embedded version of DOS, but we're in the process of switching over to an open-source OS. Our central computer software is written for Windoze (sorry) but we are considering doing a complete re-write just so it will run on an open-source OS.
I can say from experience that when lives depend on your software, you'd better run it on an open-source OS. I suppose there may be fail-safe commercial OS's out there, but nothing we've found that is mainstream enough to provide the necessary development tools. I'm glad to hear that the medical profession is moving towards open-source. It is a step in the right direction.
-----
Now, on the other hand, if there is Micro$oft Dr. Bob or something, and it crashes all the time and such, then Micro$oft can be held responsible, and both the hospital and patients can sue them for making crappy software. Even though this product would be less reliable, it is better from a legal standpoint as they could shift the blame to someone else rather than the hospital.
I know that it sucks this way, but it's the way economics works, as software in this type of situation is more of a service than an end product. I've seen it happen in the business world all the time. When we had a problem at my old job, my former boss was more concerned with who's fault it was rather than how do we fix it.
Also, you would think that (hopefully) accountability would cause the software vendor to make a better project so they don't end up losing money in court. I dunno, that's just my opinion. Feel free to prove me wrong.
Mas vale cholo, que mal acompañado.
The Blue Screen of Death
Nurse! Nurse!
SHE CANNOT HEAR YOU
Well why not?
HAVE A LOOK AT YOUR MONITOR
It's all blue, so?
COME ALONG
Sorry for the reference to non-Discworld readers.
--
A feeling of having made the same mistake before: Deja Foobar
Got Rhinos?
The cost isn't an issue. (well, it is, with falling reimbursement rates, decreasing margins, etc. But that is a different story/rant.) But the ability to intermix systems and fix something is of great importance. The company I work for is now mired down with two systems, neither of which is remotely open source. Both companies take forever to respond and update. And given the fact that we pay fees for service...
And these two companies are typical of the (US) medical IT companies. None have a clue about how to achieve stability or have an idea that open (or Open, or Free) is the way to achieve widespread growth, HL7 compliance, etc.
Unfortunately, we get these products, because they are available now. It is not an option to wait. Something IS better than nothing (you should see the amount of paper we have to shuffle. Without a computer, it would be impossible.)
While sites like Linux Med News and openmed.org showcase products and ideas that are promising, nothing is quite ready for prime time yet.
Blame must be placed squarely in three areas:
First are practicing doctors. By and large, they are techno-phobic. At least when it comes to computers. Yes, when it comes to diagnostic tools and so forth, many want to be right on the cutting edge. But for billing and charting, most don't care. When a product fails, they are not surprised.
Second are docs to be. Docs in med-school do all sorts of nifty things and have neat toys to play with. Guess what? They cost money, and take time. Things like that don't work in the real world. In the real world, Dr. Romano (from ER) has some good points: if we don't stay in business today, we can't help anyone tomorrow.
Third, and perhaps most powerful, are the insurance companies. The problem with insurance companies are not that they deny care (on the contrary, they specify what they will PAY for. You can pay for yourself anywhere) but rather that each one has their own set of rules and requirements. This goes from the mundane (what drugs will be paid for for a given illness) to the absurd. The absurd lies in their billing and insurance eligibility. For the first, there exists a simple government form, a HCFA-1500 that contains anything you could possibly want to know about a charge for a visit. So why is there no comparable electronic form? Each company has their own electronic submission routine, some requiring a dial-up, some over the internet, some through a third-party intermediary. And the stream of information to each is DIFFERENT! Even sending a standard form to a third party results in different results. The second, time-consuming aspect is insurance eligibility. If your insurance is no good, you have to pay. Or else go to the doctor that YOU selected. To verify insurance requires a phone call. Or, we could use a card swiper to swipe a patient's insurance card. Problems are: not every insurance has a magstripe code. Each insurance requires their own mag stripe reader (which is truly difficult if you take 20-30 insurance plans) or their own web interface or their own phone number. Then there is the fact that only about 75% of the insurance companies out there are automated. For some, we have to wait for a human being to verify someone's eligibility.
Despite the public misconception that the AMA is a powerful lobby, it is not. It is also divided into at least two camps: primary care (internists, pediatricians, family practitioners, etc) and specialty care (surgeons, ENTs, radiologists, cardiac specialists, etc.) with their own agendas. Rural and urban groups can further splinter this.
There are only two entities with enough cohesion to make any changes. The first is the insurance companies. Problem is, they make money on the inefficiencies in the system. If a claim or chart is incorrect, they don't pay. But they still charge the patient their premium.
The second entity is the government. We can go on all day long about whether or not (and to what degree) the federal government should be involved in the health care industry. But the bottom line is that they are perhaps the only group that *might* have the patients' interests in mind when developing policy. However, neither of the major party candidates seems to have enough understanding of the issues. Ditto their likely surgeon generals, few of whom have ever been practicing doctors, and are usually teachers first, doctors second.
That should cover the billing side. The other side is diagnosing and charting. Rather than go on again at length, I will simply say that I place blame for this about 60% on the doctors and 40% on the federal government. The doctors refuse to go along with a low human-capital intensive electronic charting scheme, and the government has been screwing around for years to develop a common interface. Luckily, since these two camps have proven so incompetent, the insurance companies have not had to intervene to slow down the process and make it more inefficient.
Rather than my above email address, if you want to discuss this post:
ghowell@nospam.familyhealthcarepa.com
Jesus was all right but his disciples were thick and ordinary. -John Lennon
I wouldn't do this. It might keep normal people alive, but think what would happen if an open-source person was on life support...
Heart monitor: beep... beep... beep... beep...
Patient: Cool, Linux
Heart monitor: beep
Nurse: Ah, you're awake. How are you feeling?
Heart monitor: beep
Patient: (Blatently ignores nurse) Say, did you bring my bag in? it should have a floppy disk in marked 'Emergency boot floppy'.
Heart monitor: beep
Nurse: Um... okay, here you are sir. What are you going to do?
Heart monitor: beep
Patient: Nothing.
Heart monitor: beep
Nurse: Okay. You concentrate on getting better now. (Leaves)
Heart monitor: beep
Patient turns over heart monitor.
Heart monitor: beep
Patient: Hmm... no floppy drive.
Heart monitor: beep
Patient reaches into bedside cabinate and pulls out a bag. Rummages through it for a few minutes, then comes out holding an fdd.
Heart monitor: beep
Patient: Bingo!
Heart monitor: beep
Patient pulls out a Leatherman multi-tool and unscrews teh back of te heart monitor, then pulls out a ribbon cable, which he plugs into the fdd.
Heart monitor: beep
Doctor: (Enters) Ah, you've recovered. As you can see, the tripple heart bypass went according to plan. You see that machine you're holding? That's the new heart monitor. That's just programming your new pacemaker over a wireless LAN connection. Whatever you do, don't deactivate it.
Heart monitor: beep
Patient: Do me a favour? Unplug it and plug it back in again.
Heart monitor: beep
Doctor: Oh. Okay. (Does)
Heart monitor: beep
Patient: Thanks.
Heart monitor: beep
Doctor: What are you doing?
Heart monitor: beep
Patient: I'm reprogramming this linux box to work as an MP3 player. I've got few hours of MP3s on this CD-R...
Heart monitor: beep
Doctor: Careful, if you stop it working, your pacemaker might not install properly.
Heart monitor: beep
Patient: Don't worry, I can always restore the data from a backup I have here.
Heart monitor: beep
Doctor: Well, you're the expert.
Heart monitor: beep
Patient: Okay, if I put this CD in, it should play the MP3s I recorded onto it this morning...
Heart monitor: beep
Doctor: Say, it does still do the pacemaker thing doesn't it?
Heart monitor: beep
Patient: What pacemak...
Heart monitor: beeeeeeeeeeeeeeeeeeeeeeeeeeeeeep
Remember, everyone: Don't try to get a root prompt on hospital property. Or a shell prompt. Or a even a KDE session.
Michael
...another comment from Michael Tandy.
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
While I do believe that open source software is very reliable and stable, and that it would be appropriate in a medical setting, I don't think it will happen anytime soon.
First of all, major vendors spread all kinds of FUD around, and you don't know what independent corporate salesmen/consultants are saying to doctors who know very little about computers. While this doesn't mean that open source software is any worse in that environment, admittedly it doesn't have much of a presence currently. That means there's few examples for OS advocates to present when recommending OSS.
More importantly, open source software is generally produced by a undefinable group of people... not one company. However, if something goes wrong with the software, there needs to be someone to be held liable. The main disadvantage of OSS in this environment is that generally NO one can be held liable if something does go wrong - sadly, whether it's the software's fault or not... because the equipment manufacturers can just blame the software in cases of hardware failure and no one would figure out the real cause nor would anyone defend the software. At least with a company being contracted for the software, there's someone to point a finger at.
That's another issue... these things have to be contracted out, and obtained on a set budget. The medical industry isn't going to look on Freshmeat for their critical applications, they're going to call a contractor or a consultant who will give them a definite recommendation for a software solution. And as far as I know, there are currently few medical-use open source applications, and there's virtually no incentive for anyone to write them. (other than the "challenge")
It's a chicken and egg problem, one that won't be avoided because a couple of hard working medical software companies will get generous one day and simply release the source code to programs that happen to make a lot of money for them already. The advantage of having thousands of people test and fix the software instead of a small in-house team is very tempting... but ultimately, the concept of OSS needs to gain more widespread popularity overall before it starts really reaching into these very specialized, mission critical, lucrative markets.
No offense guys. OSS will probably work better, but that's gonna be down the line.
Here's a little bit of reality, try not to chew it too hard.
Linux isn't a real-time operating system. It makes a great real-time controller, but it just doesn't have the granularity to do real time.
As far as embedded medical software goes, there's only one name. And it's not vxworks, the microsoft of real-time embedded, either. That's the stuff that crashed the mars explorer.
ALL medical embedded stuff runs OSE by Enea systems. It comes in three kernel sizes, and it has the best error handling and inter-process communication constructs ever built, from a reliability standpoint. There are OSE systems out there with 10 years of uptime. In addition, OSE can make the interesting claim that it is impossible to crash the OS. This type of reliability is found in a field called "safety-critical systems", and ENEA nearly owns the market. Take a look at the data sheets on their web site.
Here's a great quote: "it is impossible for user processes to corrupt the OSE kernel."
And they're not kidding.
Open Source is a truly wonderful model, but keep in mind that a closed group of true experts can also make great software.
--
What happens when you outlaw guns
Did anyone read the article? Anyone? It's talking about plain old "information systems" used in a health care setting. The article is extremely short on specifics, but it's certainly not arguing for the use of open-source products in specialized medical devices. Mostly it's the usual Introduction To Open Source boilerplate.
Do the archetypical benefits of Free/Open Source fit medical software? When you look at the "big" projects in OSS, you see GIMP, Linux, Perl, Apache, etc. All fun and exciting projects to work on. And software that ordinary developers can use and tinker with.
I work for a company that produces medical software (for medical equipment). I keep asking myself who those "thousand eyes" inspecting the software for bugs will be. Strangely, the name "J. Random Hacker" does not come to mind. In fact, the only people I can think of that would be interested in this stuff are our competitors.
Other than medical administration software, and *boring* DICOM communication protocols, most medical software is written for very expensive equipment, or equipment that is very expensive to install (as in a chest cavity). I don't know any hackers that have a spare MRI in their basement, and the number of them that could even afford one is miniscule.
And who wants to mess around with pacemaker software? Show me a hobbyist that wants to tinker with that, and I'll show you someone lacking common sense.
There are many good reasons to Open Source medical software. But a "bazaar" development model, a thousand scrying eyes, and user-submitted bugfixes are not them.
A Government Is a Body of People, Usually Notably Ungoverned