Medicine And Open Source? 124
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.
And I thought... (Score:1)
Open source...the best medicine? (Score:1)
Irony (Score:4)
More OSS propoganda (Score:1)
hmm.... (Score:1)
Let's be prudent about this... (Score:1)
I'm sorry, madam (Score:1)
I feel bloated (Score:2)
www.bamf.com [bamf.com]
I wonder... (Score:2)
Would you really be comfortable working on an open source project that was medically involved? I ask that because of the liability factor. Just look through some datasheets on TTL stuff sometime... on every single datasheet will say something along the lines of "not be used in the medical field." Why? Because companies want a better degree of product going into the medical field.
(I am not saying open source is not a "better degree" I am saying that if a company is going to be liable they want to be liable biased on product X and not product Y)
I don't know if I'd be comfortable to know that a section of code I wrote went into a heart monitor. What if I screwed something up and the monitor failed to alert the nurse of a problem?
Okay, so maybe I won't be sued... but I might not be able to sleep at night.
---
Emergency Monitoring Software (Score:3)
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.
-----
I can think of one problem. (Score:3)
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.
Lends a whole new meaning to... (Score:3)
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.
--
Re:I can think of one problem. (Score:4)
Uhm, have you read an EULA lately? I've yet to see *any* software (proprietary or free) that doesn't disclaim all liability for this sort of situation. The patient would just sue the hospital for not only using unreliable software, but for doing so with no guarantee of its quality.
My mom is not a Karma whore!
Proven, rather than open (Score:1)
Re:And I thought... (Score:1)
scenes from an ER... (Score:1)
Med Student: Use of his body? Wouldn't that mean death?
Doctor: Precisely. Now, my hands are much too shaky to make the incision myself due to my raging coke habit, so we'll let the computer control this one. *presses a button*
Computer: *starts moving the knife, but starts moving it erratically, slicing the patient*
Doctor: *quickly turning around* What the hell?
Med Student: (from behind keyboard, visibly shaken) Hey, what's a "General Protection Fault"?
Doctor: Lord, I need a drink.
-fin!-
Open source for genome data (Score:2)
articles that are around the easier it is for
people like me to make an impact.
BTW - on topic here somewhat - if you want to see
an open source genome management system, take
a trip over to
http://www.ensembl.org/
for your open source project
even better (Score:1)
NEWS: cloning, genome, privacy, surveillance, and more! [silicongod.com]
Re:And I thought... (Score:1)
---
Re:I wonder... (Score:2)
It's not my skills I'm worried about, just my normal less-than-perfect coding habits.
Re:I can think of one problem. (Score:1)
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.
One problem with this - Microsoft's license states that they can in no way be liable for any damage that may occur when using their software.
Has Microsoft ever been sued for producing faulty software?
Re:Proven, rather than open (Score:1)
Oracle 9 isn't too proven very new as a matter of fact. So you going to use oracle 7, it's been around a while. Though you can't get support?
Re:I wonder... (Score:1)
You could save yourself from those considerable worries if you remember to mount a scratch monkey [tuxedo.org] when testing your software. But, seriously, the more important a medical device is, the simpler it's made. From what I see, most of the medical applications of software are for patient record databases, schedulers, AI-based data mining for research, etc. There are also programs to take data from patient monitors and jazz it up, but it's not the case of having a desktop PC running your life support machine.
(OT)GNU icon used on "open source" stories (Score:1)
Potentially Dangerous (Score:2)
I like Linux, I run it at home. I like the OSS movement as a whole. But you can't just assume that since Linux is popularly believed to be more stable than Windows (and probably is), that OSS is ideal for medical applications.
I believe software for these critical applications should be written by professional, licensed software engineers, people who have sworn to obey a code of ethics. I don't want to put my life in the hands of a bunch of long-hair idealists. If you think about this, I believe you'll come to agree with me.
Sure, you be all rah-rah about OSS, but when lives are in the balance, it's another thing. Do you really want to score points for OSS at the risk of someone dying? As the saying goes, it's all fun and games till someone gets hurt.
Re:I Can't Stop (Score:1)
Re:Proven, rather than open (Score:1)
Medical Open Source (Score:3)
Amen (Score:4)
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 [linuxmednews.com] and openmed.org [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
Linux Med News (Score:1)
Here's a site devoted to news & discussion of Linux and Open Source medical software:
LinuxMedNews [linuxmednews.com]
--------------------
WWW.TETSUJIN.ORG [tetsujin.org]
A possible solution just occured to me. (Score:2)
Let's say we want to determine the normal white blood cell count in a person's blood, and have some equation to help with this that takes into consideration various things like height, weight, sex, etc. Rather than hard coding it in there, release your medical software with generic scripts that take this stuff into account. The main point of the software is to make scripting easier for physicians, but you also release certain scripts that will already contain a lot of what they want.
An example of this approach is database applications and the databases themselves. The open source solution would be like a database, it would be open source so the engine could be more reliable, but, other people could release open and closed source scripts that sit on top of this database and are only useful because they contain the information the doctors would want. On the other hand, it should be easy enough that any doctor could be a computer neophyte and take a class that lasts for a week, then be able to sit down and build these scripts himself so they have it completely customized.
There's a lot of stuff out there like this already, CRM applications like PeopleSoft, Remedy, etc. are examples for the financial and helpdesk industries. I think we need something like that for the medical industry as well.
Liability (Score:1)
But all software I ever seen, free or proprietary, comes with a notice that there are no guarantees. IIRC, it's even a part of the GPL. The main difference between OSS and proprietary stuff is that for proprietary software, the disclaimer is usually part of the EULA.
Hospitals using Windows have probably "signed" a EULA stating that they acknowledge that Windows may or may not work at all. For other software, they may have even agreed to pay for the developer's legal defense costs!
With OSS, maybe hospitals can hope that the GPL will be wholly invalidated and they can sue after all. We can use the questionable legality of the GPL as a marketing tool to sell to organizations who like to sue people.
My mom is not a Karma whore!
Re:I can think of one problem. (Score:1)
Too scary to contemplate (Score:2)
1. A majority of it seems to be written by newbie programmers, or at least programmers at the beginnings of their careers without significant 'real project' experience behind them.
2. Almost no open source programs have regression test suites.
If you've ever been involved in software engineering for the telecom, medical, or aerospace industries, you know that they're much, much more hardcore about testing than any open source project. The outlook that an experienced embedded system programmer has is very different from that of a desktop app programmer.
Re:Proven, rather than open (Score:2)
The current version of Oracle is 8i(aka 8.1.6), and has been out for quite some time and has proven relatively solid.
I don't know if Oracle 9 is currently shipping? I know Ellison announced it a couple of weeks back.
Re:petition to remove ugly ads (Score:1)
john
Re:Proven, rather than open (Score:1)
I'd feel reasonably safe if my hospital used PostgreSQL [postgresql.org], though, since it supports transactions and such, and operates in full write-through mode by default.
Re:I can think of one problem. (Score:1)
FWIW, the question of when software becomes a medical device (and thus subject to the FDA) is a bit of a burning question that is currently stifling a lot of innovation in the industry.
Translucent scalpels (Score:1)
Seriously, who is best equipped to design software that life depends on--someone with NASA-style mission critical development practices or some pimply teenager sitting in his bedroom at 3 AM hacking away and chugging coffee? I don't think I'd want to trust my life to the pimply teenager, but I might well trust my life to the NASA-like developers.
BSOD documented. (Score:2)
Here's [bbspot.com] an actual reported case involving BSOD.
Re:Lends a whole new meaning to... (Score:3)
This is especially amusing when you realize that a standard hospital code for a cardiac arrest is "Code Blue". This is one of those weird medical things. In order to avoid panic among patients, certain potentially dangerous situations are given color codes that the staff are supposed to know but that won't spook patients. So when I hear that there's a "Code Yellow" I know to start looking carefully for bombs.
Can't you just see it... (Score:3)
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.
Whom to sue? (Score:1)
Are hospitals willing to take the risk?
Anti-Obsolescence (Score:1)
Instead, since the institution has the source, they can contract out for people to add features they want or need, or to have it ported or whathaveyou. There will always be programmers willing to (for a price) make the system do just about anything desired; think any company can guarantee that in 100 years their software will still be supportable? I thought not.
As for quality guarantees, well, having someone to sue doesn't bring people back to life. And were I administering a hospital, I think it would be comforting to know I had direct control over the quality of the software being used there (by hiring good people to work on it) - up to and including the ability to inspect the source code personally!
failsafe os (Score:1)
I do remember seeing an HP machine running the baby monitor for my wife when she was having premature labor. That was really comforting (to me anyway), knowing that the BSOD was not going to show up in such a stressful situation.
Is Linux the right OS? I think it is for administrative programs. Health care costs are rising fast and hospitals are hard-pressed to keep rates reasonable.
For monitors, I think it can be a good choice if a company is willing to set up a distro. There are big companies out there like IBM, Intel, and RH that are supporting it. Besides, it's much easier to bug-proof an embedded system then a PC with many unknowns.
Other barriers (Score:1)
Recently, one piece of software commonly used to calculate radiation doses to patients from nuclear medicine procedures was yanked because it could potentially be used in determining doses for therapeutic treatments.
Imabug
Reliability (Score:2)
I'm a little bit concerned about this comment "well deserved reputation for reliability". Is this really true?
There are good and bad products out there, some commercial some free. Overall I wouldn't be so quick to say that free software has a better reputation for reliability. Overselling a product is what Microsoft is routinely accused of and I think it is a dangerous proposition especially when you are talking life critical applications.
For all the joking that goes on about MS, I still encounter Unix installations where they have BIND setup to restart in daily cron jobs, for example.
I call that a kludge, not an example of reliability.
Now it is a workaround that gives the perception that the system in it's entirety is stable. But as a programmer it doesn't give me the perception the code is better written.
Another really good example, I was playing around with RedHat 6.2 a couple of weeks ago and it's default Apache installation. The Apache config file is set by default to kill and start a new httpd process after fulfilling 100 requests because of known issues with memory leaks. (supposedly on the SPARC platform according to the docs, but still... that's ridiculous.)
Re:Potentially Dangerous (Score:1)
Yeah, like those crazy doctors with their Hippocratic oath and all. If I were injured, I would prefer my operation to be performed by professionals, not long-hair idealists who swear idealistic oaths to do no harm.
Thank you.
OS software not perfect for medical situations... (Score:3)
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.
Re:I can think of one problem. (Score:1)
For some stuff it's ok. (Score:1)
Obviously you can't allow the general public to play around with source code for monitoring systems or regulators.
Of course, I must admit that if I had to endure an extended stay at a hospital, it might be fun to jack my laptop into my monitoring equipment and get an on-screen read out. Maybe make some graphs and setup a website for it. Is there a bed-pan-cam.com out there yet?
Re:hmm.... (Score:2)
It doesn't matter what your OS of choice is. There are companies out there who offer Linux support at a commerical, mission critical level. If I were in charge of finding support for this, I wouldn't be asking for resume's, I'd be asking for bids. 24/7 support, senior people with at least five years hard linux experience, not just installing a copy and setting up a web server.
Re:Proven, rather than open (Score:1)
What is the basis for the statement "...open source has a well-deserved reputation for stability."? I'm not slamming open-source projects, but is the above a valid, factual statement, or merely an opinion.
I'm not understanding the correlation between open source and stability. just because hundreds or more people have access to the source, doesn't mean the software is more stable than a project in which the programmers have a vested interest in its success. at least, imho.
Gives a whole new meaning to (Score:2)
Here's a little reality. (Score:5)
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 [enea.com]. 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.
The plaintiff bar would love it (Score:1)
Re:I can think of one problem. (Score:2)
a) there is a 1% chance I'll die from bad software and 100% chance that I can sue someone somewhere if I do die. The chances of my estate actually recieving any substantial money are very low, since the lawyers will eat up all the settlement pointing fingers at each other.
-OR-
b) the software that runs the equipment has be inspected by dozens of different hospitals, each of which is putting their own pocketbooks on the line (there's no one else to point a finger at. They have the code, the should review it before using it.) The chances of death are nearly null. The chances of my estate actually receiving any substantial settlement are also nearly null (hospital argues that the use of the software is standard practice and has been proven safe in the past).
All other things being equal, I'd trust dozens of front-line reviewers with their own asses on the line, rather than a few unknown reviewers with unknown motivation.
Re:Lends a whole new meaning to... (Score:1)
Also, at least one hospital I know uses "Code 99" for cardiac arrest. Regardless, medical weenies know what you mean when you say "$patient is coding".
Re:Potentially Dangerous (Score:1)
The type of OSS people I'm talking about have not sworn any oaths to do no harm and uphold professional ethics. They have ideals, but they are questionable, and of no value when it comes to ensuring my life.
Would you rather be treated by holistic 'doctor' who has spent the last 15 years on a commune in Oregon, or by a doctor who went to John's Hopkins and has received the best training. Additionally, the holistic doctor has sworn no oaths, and his only ideals are that people should share everything and magically get along; whereas, the medical doctor has sworn to uphold professional ethics and the Hippocritic Oath.
Think about it.
This is just talking about vanilla IT (Score:3)
Closed source allows blamed to be pinned (Score:2)
Say (God forbid) someone decides to run a pacemaker off the kernel for WinCE. If the system crashes, you have a ready party who is responsible for the operating system. This is one of the reasons why Apple makes their "This software is not meant to be used in nuclear poewr stations, air traffic control, etc."
With open source you have noone to blame a potentially life-threatening crash on. A pacemaker with a Linux kernel dies. Who do you place the legality on? Linus?
(Further, and as a sidebar, I can't imagine any traditional OS [Unix, Windows, MacOS, BeOS] being viable for a medical device. Most are proprietarily written in assembly within the device, and rightfully so. When reaction times are so key, any operating system with priorities, threads, or even basic multitasking could be disastrous.)
I can hardly wait (Score:2)
Re:And I thought... (Score:1)
Windows has detected the user wishes to exhale. Proceed?
[ Yes ] [ No ] [ Exit Program ]
Re:Lends a whole new meaning to... (Score:2)
> when you say "$patient is coding".
Whereas a Linux weenie would say, "Well, who
let him have a laptop?"
Chris Mattern
Re:I can think of one problem. (Score:1)
If something intervenes in treatment (ie, calculates dosages automatically) it is a medical device, and subject to FDA regulation. Contract or no, the FDA can kick Bill's ass. And, if there is action against Bill, that should be a tolerable defence in a malpractice case. And since Bill has more money than any doc I know....
In that case, the liability would be with the manfacturer of the device - So Bill's of the hook, unless Microsoft gets into the medical equipment business (a scary thought).
Re:Emergency Monitoring Software (Score:1)
Having family members work in the NHS, I have seen this first hand. The staff have the computer equipment, but they (the pharmacy staff) seem the find the software restrictive. I'm sure morale would be increased if they weren't being held back by something that is supposed increase their productivity.
Another hope is that perhaps the staff and the patients will get an input into the software, making it more efficiant and saving valuable time.
Re: Make medicine open source (Score:2)
Comments from clinicians (Score:2)
Some of the same issues raised here are discussed there, but by physicians and other people in medicine (what about support, whom do you blame when it fails, and so on). The author of the article also posts some clarifications by RMS.
Re:Reliability (Score:1)
For all the joking that goes on about MS, I still encounter Unix installations where they have BIND setup to restart in daily cron jobs, for example.
Well, while I've never seen a name server where BIND mysteriously dies on a consistent basis, I have yet to see an NT server that can run DHCP without the CPU utilization reaching 100% within 20 min and the machine dying within another 40...
As far as I know, Apache 1.3.14 has no such memory problems (I've never installed the Apache that came with RedHat 6.2, so I don't know the version number). That's the real strength of open source projects. Any (serious) problems that arise are addressed in an amazingly short amount of time. I'm still waiting for a decent DHCP server for NT (Perferably one that can serve more than 8 addresses at a time. If it would use the machine's subnet mask as well would just be frosting on the cake).
--Mando
It's about the model (Score:1)
Since medicine is largely goverment funded there is no need to exclusively use existing open source software. There's money available. People can be _hired_ to create open source software. This way all the benefits of open source still apply plus the extra benefit of support. It would just be a requirement that software used in medical environments needs te be open source, so more eyeballs can potentially catch problems and not a requirement that the software is created by individuals who have no experience in designing (almost) failsafe/bugless software.
I think that medicine should heal open sores (Score:1)
-josh
Re:Here's a little reality. (Score:2)
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.
Certainly true - but not actually important. The main usages of computer software would be in patient record keeping, drug prescription advice (and interactions/side effects) and "expert system" style software, both for self-triage and as a backup check at the data entry stage (example - patient is suddenly prescribed a lethal dosage of drugs; certainly warrants a "are you sure you want to do this" box).
Odds of any OSS software being developed that require real-time interrupt support are almost non-existent - such software will continue to come bundled with the hardware it controls, and the best you can hope for is the ability to download treatment information into it in a common format.
--
A Sigh of relief. (Score:1)
Re:petition to remove ugly ads (Score:1)
Re:Life support (Score:1)
> I sure as hell would not trust Linux, *BSD or any jack-of-all-trades OS to run my life support.
I sure as hell would not trust any closed source, secretive and unstable OS to run my life support.
> Trust only specialized, embedded and formally right proven systems.
Like what?
--
Luis González
Open Source Hospital Software (Score:2)
I have heard that Microsoft is beginning to show a lot more interest in this field lately. The next version of HL7 is going to be XML based, and what is BizTalk server but an XML translator/router.
This comment is not the opinion of my employer.
Re:I can think of one problem. (Score:1)
-- Michael Chermside
Re:Here's a little reality. (Score:2)
Cool! There was a related discussion a couple of weeks ago about theoretical computing. Apparently, Enea has implemented "The Halting Problem" in their operating system, because they're able to conclusively state that no input data (read: program code) is capable of making the machine stop.
Wish I would've known about that before I wasted all that time studying Turing's theorems.
Why Open Source makes sense for Medicine (Score:1)
I would still be worried about the level of support that a commercial company offers over what a part time hacker offers.
This will not be accomplished by part time hackers. It would have to be driven by the medical community, probably through the AMA. The AMA would define the requirements and then have the work contracted through an organization like SourceXchange. I believe that this is the future of open source software, communtities such as the medical communtity defining a common set of software needs and then contracting with the open source community to have that itch scratched.
I sure as hell would not trust Linux, *BSD or any jack-of-all-trades OS to run my life support.
1. Any equipment used for medical use has to be certified and this would certainly be true of any open source equipment. I myself would have more trust in a system that was open for inspection then one that wasn't.
2. Why do you assume that medical software = life support. How about hospital management, Doctors office management, patient records, billing, etc.
The benefits as I see them:
1. The ability for the medical community to get a common pool of software developed specifically for their needs.
2. The cost savings from having this common pool of free software will mean lower medical costs, which benefits everybody.
Re:Potentially Dangerous (Score:2)
I don't think the article was about embedded life-control systems or anything like that, just IT software in a medical setting. Billing, scheduling, that sort of thing.
Don't get your panties in a wad.
I work with medical IT software everyday and most of it is utter crap... thank God it's not a life-support system.
"Free your mind and your ass will follow"
Re:It's about the model (Score:1)
Re:Here's a little reality. (Score:2)
Heh, ok, your sarcasm is appreciated.
But you either didn't understand Turing, or you didn't understand me.
No, they haven't solved the halting problem. It's REALLY EASY to write a program that crashes under OSE. I do it all the time. All they're saying is that it can't corrupt system memory. The halting problem does not forbid true protected memory. OSE is just really good at sensing a crashed application, ending it, and restarting it. So if your pacemaker crashes, it can restart the "pace" process very, very quickly.
A handy thing.
That aside, it's an interesting statement to say that your OS can never crash. The interesting thing about it, as you point out, is that you can't prove it on paper.
It would be more accurate to say that OSE has never crashed. Ever. The Halting Problem only means that you can't prove that something will never crash. It does not, however, exclude the possibility that such code exists.
Medical and opensource philosophies don't mesh (Score:2)
Open-source software might help lower costs or improve the quality of health-care, but there are big social and philosophical barriers that must first be overcome. With current political clamorings for unionizing and liscensing among programmers, I fear we may meet on their terms, not ours.
Re:Here's a little reality. (Score:2)
For the purposes you describe, I agree, Linux makes a wonderful fit. I still assert, however, that my original comment has a place in this discussion, given all the posts about people's pacemakers crashing and life support systems going into microsoft blue-screen mode. My point was that neither microsoft nor linux should ever find their way into true safety-critical applications like the ones i just mentioned.
I agree that for non-realtime stuff such as the applications you mentioned, linux probably makes a much better fit than microsoft, especially since it is so much easier to network.
Re:Here's a little reality. (Score:2)
But it is possible for OSE to make sure that user processes can't corrupt the kernel. The first technique that comes to mind: you assume that the OS just runs program code as is. While traditionally that may be a reasonable assumption, it may not be the case. Perhaps OSE uses a PCC (Proof-Carrying Code) system; maybe they just won't run precompiled binaries, but force programs to be written in a high-level language which is then run by a security-minded interpreter or dynamic compiler.
In either case (and others), OSE would be able to guarantee that user processes can't corrupt the kernel, without violating any of Turing's work.
no it isn't (Score:2)
No, it isn't, as I asserted in my root post. To gain access to it, you have to pay more than a third of a million dollars for more than a decade to one of a very small number of "qualified" institutions. The high rate of failure among those seeking admittance both to medical school and within medical school itself ensures that the supply of practitioners will always be restricted.
In contrast, open-source software exists in super-abundance. Anyone can replicate it and provide for her or his own software needs. It's an entirely different approach and philosophy.
Re:Here's a little reality. (Score:2)
But you're still arguing that it's provably possible to ensure that there does not exist a set of statements that can cause the kernel to segfault or panic or do something else nasty. I just don't believe that's possible, unless they have in fact generated every string that can be represented by the OS's storage facilities and tested all of them.
I'm certainly not saying that they haven't written a stable and robust platform. Frankly, I never heard of it before today, so I can't give you a detailed argument. However, on general principals, I'd be disinclined to believe that they've created a truly "bulletproof" system.
Re:Here's a little reality. (Score:2)
Thanks. Its intent was light-hearted. :)
But... The only way to prove that is to either:
Also, how can you tell that an application is crashed? I guess you could set a watchdog timer that the app has to trigger, and re-spawn the program whenever the timer elapses...
So, if it exists, it's undetectable? In that case, they also need a Heisenburg API in there somewhere. :)
Re:Here's a little reality. (Score:2)
No, I'm arguing that it's provably possible to ensure that such statements won't be executed - not in userland, anyway - either by checking the validity of an existing proof to that effect or by only executing a language whose statements are already provedly safe.
unless they have in fact generated every string that can be represented by the OS's storage facilities and tested all of them.
But you don't have to do that - you just prove it by structural induction.
However, on general principals, I'd be disinclined to believe that they've created a truly "bulletproof" system.
As am I - especially since even the methods I talked about depend on the kernel code itself being correct, which is a wholly different issue - but you have to concede that what they're claiming is actually possible.
Re:I can think of one problem. (Score:2)
OSS and Medical Software (Score:3)
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.
stability does not follow from open source (Score:2)
Re:Here's a little reality. (Score:2)
Re:offtopic; what would make slashdot better (Score:2)
Re:Closed source allows blamed to be pinned (Score:2)
Punching a nun (Score:2)
External auditing for safety-critical software? (Score:2)
What kind of auditing procedures is this software (or, really, the entire system) put through?
Lot of orthogonal arguments here (Score:2)
The point of OSS in a medical context is this: using OSS, you cannot be held hostage by a commercial vendor with lives at stake.
There's too many cases on record already of faulty (commercial) medical software killing people (high-powered scanners and the like) and too many cases of commercial companies foot-dragging and refusing to admit problems because debugging and fixing them would cost money and be a publicity stain. On the other hand it would be a winning strategy for a commercial medical software company to (say) do an upgrade or better still find and fix a potentially dangerous bug- and then charge a really BIG amount for the upgrade/bugfix. That's being held hostage, and that would be less of a risk with OSS developed by a competent medical software developer. Ideally the software should be a matter of public record- so that if the primary developer isn't available another competent one can be found, and so that if there are subtle bugs, some unrelated person could make a claim that there's a bug and offer a fix- and the claim and fix could be audited by third parties.
I don't see where this requires 10,000 script kiddies- but it does make a case that ownership of such important software should rest with the user and not be reserved for the supplier. Can you imagine if the .NET model caught on with medical software?!? "Okay, the old rental rate was $500, but there's been an adjustment- the new rate is $60,000 and a 10% interest in the hospital. Or, you can choose not to pay, and we'll flip this switch and 72 people die..."
Re:I can think of one problem. (Score:2)
Case 1 : you choose an open source solution. Your system fails. YOU are f*ked.
Case 2 : you choose a proprietary solution. Your system fails. YOU are f*ked. Can you take 'revenge' on the software vendor? Not with most commercial software, AFAIK (which is not far).
In both cases you are the responsible that your system meets its requirements. It's your responsibility to pick up the right components. There is no difference in responsibility wether you choose open-source or proprietary software.
Open-source gives you more control - provided that you have the skills and the budget to excercise that control, which include *qualifying* any component before deployment in critical systems. Note that you shall qualify your system even in case you use proprietary solutions - but in that case you can only rely on black-box analysis, not having the source at hand.
If you don't have the skills or the budget to qualify your system - well, better do your business where a failure does not mean loss of life.
DISCLAIMER : luckily for me, I don't do critical systems.
Re:Here's a little reality. (Score:2)
Yep, the usual avalanche of users who don't read the links (or even the full post) and just type away at whatever the title suggests to them. I am suprised we didn't get some discussion of open-sourcing $DRUG for making them at home with a Junior Chemistry set.....
--