Slashdot Mirror
Salon.com on Open Source Medical Software
mke writes "Life or death software; new medical programs show the strengths of open-source coding -- and its weaknesses." One of the biggest weaknesses mentioned in the article is that there's no software company to sue if something in the code kills or injures a patient. Another problem, at least in the U.S., is that FDA approval for medical software costs millions. The question is, can these problems be overcome, or will proprietary software continue to be the norm in critical medical applications?
I too work writing medical device software. First, forget liability. The issue is staying out of jail. The FDA rules are criminal rules, not civil. Your warrantee exclusions are utterly irrelevant. In fact, they are probably evidence of an intent to violate the law if they attempt to avoid responsibility for device safety.
For over 60 years the law has been that devices must be safe. Manufacture, distribution, or sale of unsafe devices is a potentially criminal offence. People do go to jail, although usually only for blatantly extreme violations. For example, one company that sold unsterilized used pacemakers (harvested from corpses) mislabeled as new got a number of jail terms. More normal penalties are business closures and fines.
There is no law against Open Source per se. I have participated in several open source like efforts to encourage the use of new technologies by distributing free working software to illustrate how the technologies worked. But since we were also experienced in the law, we carefully labeled everything as educational material not for use in a clinical environment. This did work. The technologies are being accepted and the open source software is the basis for a number of products.
The key failing of open source in this environment is not in the free source access. Free access to source is fine. Delivery of source is fine. The FDA has no problems with that. The problem is that you absolutely must maintain strict change control, strict verification procedures, strict validation procedures, and strict recordkeeping.
Change control is needed so that at any time, now or in the future, you know exactly what software is in any particular device. If a problem is found this lets you fix it or notify the right people. It also lets you know which verification and validation that device went through, what facilities it provides, what uses are approved, etc.
Verification and validation are much much more than testing. The FDA recognizes the value of open code review. In fact, you can easily lose your approval to sell medical devices if all you use is testing. Code reviews and other modern techniques are expected. This is quite in agreement with the Open Source model.
The problem is Open Source's explicit refusal to permit change control. You cannot both restrict unauthorized modifications and comply with the Open Source terms. You cannot permit uncontrolled change and stay within the FDA safety regulations. So medical devices cannot be Open Source.
If Open Source were to permit selective change restrictions, then you could legally use open source software in a medical device. This would also be commercially viable, because many medical applications are sold on a service fee basis and not a purchase basis. The restriction needed could be quite simple: no changes permitted when in use as a medical device except by organizations that have obtained all the necessary legal approvals to manufacture and market medical devices. These approvals are issued by regulatory agencies. In the US these would be the FDA's 510(K), PMA, and similar authorizations to manufacture and sell medical devices.
By the way, selling or distributing a medical device without the necessary approvals is one of the more blatant and easy ways to get a jail sentence. The civil disobedience route to changing this law could be unpleasant. And you will have a hard time persuading the general public that selling unsafe, untested medical devices is a good idea. The FDA was created because the public didn't like what happened when there were no laws against selling unsafe medical devices.
Take a looke a http://www.fda.gov They have placed most of the relevant regulations together with lots of educational advice for software developers online.
Certainly with closed source you are only left with one source for corrections, but in fields this specialized are you left anything better with open source, really?
Anyone can work on a code for a text editor - everyone knows what a text editor is supposed to do - and if they break it, no one dies. Far fewer people know how machines that administer anasthesia or x-rays work, and the real time constraints these machines must satisfy.
The intersection of people who possess both the specific technical knowledge to maintain such software without breaking it, *and* the programming skill to maintain software at all must be vanishingly small. How many people will you be able to turn to if something goes awry?
Silly me, I thought all those university professors doing research and publishing their results in peer-reviewed journals were the original template of "open source". Seriously -- what I see here is massive confusion about what the term "open source" means. It doesn't mean "software written by unpaid volunteers".
Yes! It would. One of the most critical parts of the procedure that your wife had was the selection of the target(s), the selection of the collimator, and the dose. You want to really zap the target, but spare nearby important structures. These decisions are often made by "educated guess" - paramters are entered, and the display shows the dose delivered and the dropoff of the radiation as it relates to surrounding structures. If this was a Gamma Knife machine, several spherical targets were chosen (since the device is roughly spherical) in order to approximate the desired target. This is a nontrivial problem that is not yet automated and optimized. If an open source project to choose the optimal parameters was created (using genetic algorithms, simulated annealing, or whatever), the treatment plan can still be modeled and directly compared to the best "educated guess" solution to see which one delivers more radiation to your tumor and less radiation to your optic nerves - before pushing the button.
Open source works better when there is a large developer base.
But there potentially is a large developer base. Several very important medical advancements were made by nonmedical people who had an affected loved one. Often they didn't perfect their inventions in time to save their loved one, but many others benefitted. Everyone will have a loved one get sick and/or die. Medical charities are common. Many people donate money to help advance medical research or to buy medical treatment for those who cannot afford it. If someone is going to donate their coding skills for open source projects anyway, why not donate their coding skills for such a noble cause.
The systems themselves use various RTOS's (which I'm not sure policy let's me mention). However, ouside of the devices themselves, we use everything from Solaris to NT to BSD to Linux. We have used off the shelf testing software, but ended up with our own custom system based on Perl.
A Government Is a Body of People, Usually Notably Ungoverned
Free Software has nothing to do with the Bazaar development model, that was just ESR's observation of some open source project structures.
Here is what Free Software is about: when you buy something, it becomes yours.
When you buy a car, it is yours. You can keep it as-is, you can paint it a new color, you can soup it up, you can give it to someone else, you can crash it into a police station in your quest to kill Sarah Connor. You buy the car, the car is yours. It no longer belongs to Ford, it belongs to you.
Proprietary software doesn't work that way. You buy the software, but you can't change it. You can't give it to someone else. You can't modify the software. You can't use it to hack into a police station's computers in your quest to kill Sarah Connor. You buy the software, but it doesn't belong to you.
Folks on this discussion who don't think that a chaotic development model would fit life-or-death software are right. But chaotic development models are something peripheral to free software, not integral to it. (ESR has emphasized this development model; but ESR is, in this capacity, a salesman, albeit a very insightful one.)
The point is, once you buy a piece of software, you should own it (IMHO). Once a hospital buys some equipment, they should own it, and its software.
"Whatever happened to fair use?"
-- Duff-Man
I think the programmer, and the company she works for, could be held liable, even with a GPL license. You can put all the disclaimers you want in a file, but if you write it at work, with company approval, and that company distributes your open source software, and has advertising claiming it is "robust" or "reliable", the right combination of attorneys, judge, state, trial and jury would nail their butt to the wall.
The liability question, at least as put above, is naive. There are some things you can do, notwithstanding even express contractual disclaimers in negotiated and executed agreements, that under certain circumstances cannot be disclaimed -- and conduct leading to personal injury can lead to such liability.
(Think about it -- if liability for medical malpractice could be disclaimed, would there be a doctor or hospital in the world who wouldn't make you sign away your rights as a condition of treatment?)
Accordingly, publishing OSS medical software probably is a risk -- although most publishers (in their individual capacity are likely to be relatively judgment proof compared to the size of most such claims.
But the interesting observation here is the suggestion that open software must be orphaned from regulatory approval for failure of a company to pay for such approval. In my view, that objection is highly overstated and takes perhaps a naive view of the economics of the situation.
Indeed, the company never really pays for the software's approval -- at least at the end of the day. Nor do they pay for the outrageous liability insurance. Customers do. Proprietary medical software that is highly regulated or requires elaborate insurance is expensive, in part, because of these expenses.
If truly good OSS medical stuff were out there, approval might arise in time by the marketplace that intends to use it, either through grants, communal conduct by the marketplace, or "new economy" ideas such as websites soliciting voluntary contributions to support worthy quasi-commercial work.
Those notions should work, that is, unless you believe the "free rider" problem precludes such benefits to society, in which case the arguments for strong IP were right after all. . .
...took CS courses from a guy at the University of Ohio-Miami (can't remember his name) who allegedly wrote the control code for the U.S. military's nuclear missiles.
He brought this up in class as an example of why programmers should be aware of the purpose of their code and the consequences if it doesn't work.
His thoughts: "OK, there are five billion people on this planet. If I fuck this up, they're ash."
J.
damned vulpine http://sb.drtwister.com/
Gotcha. I've not had to deal with that one. Seems like a pretty dumb ass way of doing things from FDA's point of view (yes.. I know). The assumtion should be the other way around -- Everything is experimental unless explicitly labeled as OK for clinical use and signed off by someone that can give the user a "get out of jail" card.
Someone can bring a freakin' bicycle into an operating room and use it because it wasn't explicly labeled as experimental and not for clinical use?
garyr
-- your Web browser is Ronald Reagan
This is somewhat reminiscent of the geodesic markets I've seen promoted on cypherpunks. Part of the notion is that senders and/or receivers would pay routers for traffic, and hard-working routers would buy clones of themselves, putting appropriate extra capacity on high-demand routes.
Yes, I think the answer it simple -- Guarantors. If the product is free so people don't trust it, then it can be tested, the people testing it can make certain guarantees of its reliability for which they take out insurance.
I don't see how the open source standard conflicts with the idea of validation and verification. I don't believe anyone in the future will purchase a pacemaker and upload the latest version of Linux Pacer onto it. The manufacturers of the devices will benefit by being able to use a standardized hardware base for each device, and by not needing to write new code from scratch. Validation of the hardware is necessary in any case, with fewer chances of the softwares' tripping up the testing procedure. Should a fault be found in the software during testing, well, then the change is fed back into the system, and the new software version is used to validate new hardware. Egregious bugs for already utilized hardware can also be better spotted.
There are some markets where open source, end user applications just won't go. Medical software, Nuclear power plants, Military apps, etc. It's not like, say, the Gimp, where you can get several thousands, or even tens or hundreds of thousands of people to use it and sniff out the bugs. The "noone to sue" argument is irrelevant. The scale by which open source offers any benefit doesn't exist.
...), considering what the buyers are willing to pay for it, and considering that the target market for such software is so small.
Also, the consequences of failing software in these instances are potentially high. This is not software where if it fails, the worst that happens is a core dump takes up some space on your hard drive. Even a forced reboot that leaves dirty filesystems does not compare to the potential for thermal nuclear meltdown, or radiation overdose.
This is software that is reviewed line for line by independent auditors. Software where each individual change to the code is justified by at least a few paragraphs of design review, which include required documentation changes, and all manner of approvals and signoffs. I've been that auditor, and programmer, and documentor, and I even have a few KSLOC running in several of our nuclear power plants.
I don't see these people downloading "ReactorMonitor-0.3.1" and performing the task of documentation necessary to qualify the software for mission critial, safety of life applications. Not going to happen this lifetime. What you're paying for when you purchase such a program is the 6 foot stack of documentation that justifies the accuracy of every line of code in the program. If I were to perform that task of documentation (and I have), I would be reluctant to give it away (i.e. license by GPL or BSD or
However, an application based on an open source OS or open source libraries may be employed in such an environment, pursuant to the requesite code reviews and documentation, of course.
On a more promising note, one of the guys I used to do nuke work for told me, and I quote, "You'll never see Microsoft Windows of any kind in my control room." Linux was just barely on the map back then, so I never got his impression of it, but if any non-embedded OS came into his control room, it was guaranteed to be unix-based. =)
How's my programming? Call 1-800-DEV-NULL
Great post. I do similar work and was thinking I'd have to post this same info myself. Thanks for saving me the time.
...fine. My changes are not under your control, it's true. So? If I were crazy enough to crack the case on your device and put my new "improved" firmware in it I have shifted the entire validation burden onto my shoulders. If someone dies I am to blame, not you.
I don't follow you on "Open Source's explicit refusal to permit change control". What refusal? Say (for the sake of the argument) that you wanted you burn a modified linux kernel into the ROM of your device. You've changed the kernel and you've redistruted it so you will also release the source of your mods. Where does change control become an issue?
If I later come along and make further changes to the software
FDA requires *you* to have adequate change control. You would have to be sure that the
device that you are shipping does not have my unvalidated mods in it. you would need to take reasonable steps to make sure that your customers can't apply mods without understanding the consequences (encase ROM and seat in plastic like cable tv boxes or at least a big nasty seal on the box). If it were a plain old piece of software that you were selling, something as simple as an MD5 checksum would do the job (this is not the software we sold you, we are not responsible for it).
I don't see the issue you are raising here.
gayr
-- your Web browser is Ronald Reagan
Arandir wrote:
But opening the code makes it a hell of a lot easier to determine if the code works at all. I'm not saying we should all sit down and start writing a GPL replacement for all the hospital firmware out there--frankly, I have better things to do and you probably do too. But think of it this way: we all know that open code works better, and that peer review is the world's best debugging process. Shouldn't our most mission critical applications have that security?
Now, there are a few ideas in that last statement that need to be expanded a bit. I think we can all realistically say that there won't be a flock of programmers rushing over to write hospital software, so let's think about how open source ideas can be implemented here.
To me it looks like it is in the best interests of the medical community to regulate itself, following the above guidelines. It's the classic case of the private sector taking up regulation for both the benefit of itself and the benefit of the customer (with the side benefit of taking up some of the responsibility that the government once assumed).
OK, just my opinions of course. And I just rolled out of bed...
-k
if (!two_digit_year)
{
start_meltdown();
}
Give me a fucking break. Why would dates be included in a fission reactor? Can somebody please tell me the correlation? I'm an embedded software engineer, the only time I've used dates are for user interface.
This is just plain hysteria. When we finally hit the year 2000 it will be over. Until everybody starts flipping out about time(&_32_bit_integer) since when it becomes negative, Unix time screws up. Hopefully I'll be dead by then, because I don't want to go through this bullshit ever again.
It's the Y2037 Bug! We're all going to DIE!!!!
Geesh. Can't we talk about something more earth shattering? Why not just go on and on and on about Star Wars? Lord knows we can never get enough of a mass merchandised movie like Star Wars. Two more to go. joy. Maybe it won't be a bad thing if we all die in the year 2000, at least I can avoid they hype - it seems to be the only way in modern society.
Like another poster here, I've written software for a medical device company. We used a large open source component in the device. I'm not at liberty to comment on specifics.
The whole liability question is easy to answer: the device manufacturer bears responsibility for the whole device. For example, if they store data in a file system and then use that data to control patient treatment, and the file system gets corrupted, the manufacturer of the device is liable, whether they bought the file system from Microsoft, bought the file system from Red Hat, downloaded it from the network, or wrote it themselves. So the device manufacturer has to choose which means of procuring a file system will give them a file system which will harm the fewest patients, because they will have to pay for that harm.
Again, as another poster mentioned, the FDA does criminally prosecute people who are negligent. They don't just regulate the industry -- they can walk into any company, any time, ask to see any records, and suspend or shut down the operations of any company at any time.
The FDA has extensive documents on software requirements for medical devices:
http://www.fda.gov/cdrh/comp/swareval.html
My experience is that medical software is somewhat higher quality than non-medical commercial software, but not as good as the best open source software. Peer review works.
...That little chunk of code that controls traction in your new car can kill you with the same efficiency as the code in your heart pacer.
IMO, the best thing to do is to require that ALL software code used in ALL life critical applications is disclosed and open for audit. Companies can find other ways to protect IP - hardware design, just having the best quality etc.
<^>_<(ô ô)>_<^>
When an unexpected blizzard stops business, damages property, and takes lives, you don't see a whole rash of lawsuits against meteorologists for not warning of the danger
Russian meteorology Center was sued by the Moscow government for fialing to predict some strong winds. I will bet something like that should have happened in US - gee, people sue for much smaller things...
<^>_<(ô ô)>_<^>
Yeah, and of course all the software produced by the clued-up people that use these great controls, audits and oversights works perfectly and never causes any trouble. Get it into your thick head that "design methodologies for high reliability software" don't work because no one really understands what causes the problems in complex software production. TWW
Okay, I wrote a pretty huge DICOM3.0 implementation for the university and I was thinking what license to go. As I thought over and over, I realized that medical software simply costs too much and an open source model could keep software solutions with a very limited budget.
In my case, this might mean that many hospitals could be provided with low-cost and highly-available medical imaging workstations. Linux boxes with internet connection would be the way to go.
So I say GPL it. It will work very good at least for the non-ultra-critical kind of medical software. And who says that free software can't do it. I think my lib surpasses most of the commercial DICOM implementations, and it's gonna be truly free.
--exa--
I'm getting pretty sick of hearing that if your code isn't Open Source, then it's full of bugs. I can point you to a pile of applications that have been developed by individuals and companies that are efficient, reliable, and robust. For a group that keeps screaming that people should have an open mind, some have pretty narrow views about commercial software development.
On top of the FDA certifications costs, there's this little thing called domain understanding that need to be taken into consideration. You just can't put source code on the net, and ask everyone to take a look. Applications such as anesthesiology monitors require years of medical training and experience to write, and you can't expect an expert in OSes to be able to take a look at it and make it significantly better. He may catch semantic errors, but not logic errors, which is the most likely place an error will occur.
Like everything else, Open Source is a great concept, and it's great for application that are used by a large number of people, since it's large user base have an understanding of the application, and they can contribute to making it better. But it's better to let experts deal with specialized applications.
But they are an attempt at producing good software. Design methodologies do remove some stupid bugs, and when it is a matter of life and death for someone, you do want to remove some bugs, even if you don't remove all of them. Besides you said "causes the problems in complex software production", and it is part of the design methodology, and embedded systems common knowledge, to, when possible, reduce the complexity of the software (by discarding the accessory functions for the core of the software).
My company runs web frontend servers on Windows NT and backend servers that acquire various pieces of data on Solaris. They're all smart enough to agree that Linux would be a more reliable way to run the frontends than NT, (Solaris is prohibitively expensive for us) but Windows guarantees Y2K compliance, and if it turns out they are wrong, we CAN sue them. We couldn't sue Linus Torvalds. And that's the reason why we use inferior proprietary software - we need accountability.
grep -ri 'should work'
Change control and open source go together just fine.
Suppose I needed a TCP/IP stack in an EEG monitoring machine. I could:
(1) write my own
(2) buy a commercial off-the-shelf stack
(3) buy an open source stack (e.g. from Caldera)
(4) download an open source stack
In all four cases, who bears responsibility for validating the software? I do!
In all four cases, what happens if the original author (me, Wind River Systems, Joe Open-Source Author) changes the source code? Answer: I am responsible for the version of code that I choose to include in the device. Just because Joe O.S. Author, or Jane New Contributor, puts up a new version of the TCP/IP stack doesn't mean I'm going to blindly stick it in my ROMs.
Open-source peer review is not a substitute for the giant stack of paper, code review, and testing which the FDA requires. But if I start with an open-source product then I am going to have fewer bugs to deal with and access to the source code, which is going to reduce my validation effort.
BTW the change logs and deltas for open-source projects are usually far more accurate than the equivalent artifacts maintained by closed-source third-party software vendors.
If anyone's interested in starting an open-source, consortium-based clinical information system, send me some mail. If there's enough interest, I'll start up a mailing list.
-Bill
-----
Bill.McGonigle@hitchcock.org / FAX: (419) 710-9745
Dartmouth-Hitchcock Medical Center Clinical Computing
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I hope for my own sake that medical software continues to be developed under more controlled conditions. The LAST thing I need is to be on life-support and have the machine be controlled by code written by some high-school student that nobody knows. THAT is not acceptable. Even if it WAS written by such a person, I would certainly expect it to be under controlled conditions, and very carefully reviewed and tested. And as for the idea of the "software is responsible".... I don't mean to flame, but... ARE YOU ON CRACK? The person responsible is the programmer or development company that created the software. If I were in the medical profession, I would NEVER allow my equipment, etc... to run software the "disclaims responsibility" from the programmers, etc. I would not use software that is released under ANY of the current popular open-source licenses. They ALL disclaim responsibility. Responsibility lies with the CREATOR of the program. The program is NOT a living being, capable of thinking on its own. Computers are NOT living beings, capable of thinking on their own. They can do ONLY WHAT HUMANS TELL THEM. This is not the HAL9000 here. Besides, we all know what happened there...
Well, I believe that the software itself would be liable. We, in the Open-Source community create software that is akin to a living being. It exists of its own accord, and is not controlled by anyone. As we allow these self-controlling programs to essentially create themselves, we have to become accustomed to the fact that any flaws are the fault of the program itself, and no person. I realize that this sounds a bit weird, but as far as I can tell, we are moving toward a system where software wills itself into existence, using the work of Open-Source developers to manifest itself. The software must be made, and we are there to do its work. It's a strange concept, but it makes sense if you really think about it.- ----------
--------------------------------------------
If you need to point-and-click to administer a machine,
. . . but I fear thet the FDA's historic dedication to corporate profits over health will torpedo the project.
Which brings me back to the basic question on the FDA: why do we have a government agency ruling by fiat on matters that should be resolved within the _open_ scientific community?
---- "When I grow up, I'll know far less"
In a way, this reminds me of the debate over sattellite phones. Since the FBI doesn't know how to listen in, they want us to not use the phones. The attitude seems to be: In this case, since our litigation happy society won't know who to sue, let's use some buggy, proprietary software. So what if a few people die, we'll be able to sue Microsoft for big bucks.
This is stupid reasoning, people need to get it into their minds that sometimes when bad things happen there just isn't anybody to sue. My brother has a congenital heart defect, who is he supposed to sue, God? If he did, where will he connect the money from.
It would be tragic if some had to people die because open source is too radical for the medical establishment.
All the creatures will die, And all the things will be broken. That's the law of samurai. (Jubai, 1605)
Mind you, I'm not an expert on this type of thing. Anyone have any details on when the last time a software company was sued because of failure of their product?
BTW: There's a harsh thunderstorm going on and my router's still up! Maybe MS should buy a Netopia
AC
Whether this is a good thing or a bad thing, the computer industry has a long tradition of not being accountable for software (even commercial) killing people.
In a computer ethics book (don't have the title handy) I read, there were some articles about a software controling the doses of radiation applied to cancer patients in therapy. Apparently, the software was buggy enough that it would often give the wrong dosage. Sometimes, the patient would get no radiation and in a few cases, patients were zapped with something like 100 times the amount of radiation they were supposed to get. There were a few deaths, but I don't believe the software manufacturers were ever held responsible.
I don't see why open source systems should held accountable when commercial products aren't.
In this case, very complex software like Linux and Windows CE and various other things *cannot*be*used*. As good as the software may be, it isn't infallible - and if anything has to be bug-free, it's medical firmware (well, and military firmware, stuff in plans and the like). Releasing the software as Free Software, freely available, probably wouldn't do much for you - after all, how many people will have this sort of equipment?
That being said, there's no inherent problem with releasing the firmware code of a medical appliance. You could probably get *some* improvements. But I don't want my heart being driven by software that is potentially not completely and utterly tested to the fullest extent. I just don't think that someone not being paid would be willing to do that.
Seems to me like freedom from a chain of responsibility is just what we need. Besides, it's not so radical a concept to have nobody to blame. Think "act of god." When an unexpected blizzard stops business, damages property, and takes lives, you don't see a whole rash of lawsuits against meteorologists for not warning of the danger, or the state and local authorities for not providing enough emergency support to prevent catastrophes. Nobody sued the builders of I-880 for building on sand that could liquify in an earthquake.
I know that's not exactly analogous to open-source, which is much more human-implemented. But it's useful to think of open-source software as a sort of natural resource, like sunlight. For Joe User, it might as well be the same thing, cause there's no ownership attached and it's infinitely renewable. And, much like the sun, you have to be careful when you use it. Test things out. Extensively. Convince your (suable) corporation/hospital that the product is sound. Then use it. And if it fails? Yeah, they can sue you for not testing it more thoroughly.
Here's a still different analogy that may work. Let's say all the tobacco manufacturers are being sued for giving people cancer caused by their cigarettes (I'm ignoring the whole adding-addictivs-and-carcinogenic-chemicals-with-f ull-knowledge argument for the moment). The tobacco companies can't turn around and sue the tobacco. They knew there were risks associated with using it. But they marketed cigarettes as a safe product. So the burden of error is on their shoulders.
This is a JOKE! Almost every license for proprietary software removes your right to sue for damages. I ran the Microsoft Windows Refund Day newsletter, and I've read many a EULA now (though I've still never used their software). The rights you sign away by using proprietary software are mind-boggling.
Just remember: open source licensing takes away fewer of your rights as the software user. This is a demonstrable fact.
--
I noticed
--
I noticed
It's getting about time to leave everywhere
How can you get the necessary source code audit without open source?? And if you aren't auditing the source code, you're going by guess and by golly.
-russ
Don't piss off The Angry Economist
One of the bugaboos which keeps raising its head whenever we advocate the use of Open Source Software is the question of who to blame when something fails. In a very real sense, most of us can laugh this off because the potential for dire consequences is so low: if some weird confluence of events causes my Apache httpd process to go belly up... so what? There are ten of them running, and if they all go down, I can just restart the server. The odds of something really bad happening - say, losing all of the documents in the docroot - due to a glitch in the software are remote enough to not be worth thinking about.
But how would we react if it actually happened? Personally, I'd stand around looking dumb for a few minutes, then catch a plane for Argentina before my boss caught me. And in that situation, no one winds up dead. (Unless said boss catches me.)
I think, however, that the "what's it gonna take" question is pretty easy to answer, at least in the medical field the article discussed. What it's going to take is a dedicated group of programmers and engineers, willing to incorporate and put out a product which runs on Linux, but for which the company is responsible. In the same way that I would hold Penguin Systems liable if they sold me a server which was defective (not that this has ever happened), the manufacturer of the system would have to shoulder the responsibility for faulty design of its own systems.
So, what do you think? Could this be made to work?
Having no one to sue is not a problem with open source. It's a matter of having someone accepting liability. Accepting liability is a responsibility that someone can assume in exchange for a fee, same as any other responsibility, like the responsibility to provide tech support.
This liability thing should be a non-issue.
If I tell you that I'm not guaranteeing a particular function for anything (or even the entire program), then I have explicitly removed myself from any liability.
If some dummy were then to use that program and somehow be harmed by it, that would be their problem.
This will lead to companies that *could* guarantee their product. It would also lead to certification companies that could take on the liability as part of their business model.
Or the consumer could just suck it up and use the program anyway after deciding that they didn't want to pay for a certified version.
As for the Open Source vs Closed Source question, the same thing would apply. The author could explicitly say he is liable for his particular version, or after the software is produced it could be certified, where the certifying agency would take on the liability.
One thing they were afraid of was that users would be slipping in the newest and latest bug fix which could crash the machine. Er? And why could this not happen with a closed source model? Obviously, if the vendor was responsible for slipping in the new release, they'd be responsible (or the certifier). Unless they perhaps set rules, such as that the machine could only be upgraded when a patient wasn't on it. Then whoever did the upgrade would be liable.
I just don't see where Open Source would be a problem in any of these cases. Even if the Uniform Computer Information Transactions Act doesn't pass, it should be implicitly obvious that there are no guarantees about the software, except those stated by contract.
Ger
Be free and multiply.
On the other hand, if the staff are familiar with the package, have checked to see if it'll run on their computers, and are comfortable using it, then you might expect them to compare the results they get with those they expect.
If the hospital is confident the software behaves as it's supposed to, and the staff are confident in it's use, then the chances of there being any accidents to sue over become sufficiently remote to make it stupid to make that a deciding factor.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Hey, software is just as much a part of devices today as any other. Why should there be different standards?
If I produce a valve for the Narcomed6000, don't test it adequately and it fails (killing the patient), I'm responsible. If my company produces jet engines that fail in flight and cause a crash, I'm responsible. In both cases I'll get sued. How is writing code that fails to sound an alarm or screws up a HUD any different?
There's a good reason why it costs millions to get a device FDA approved, ditto getting a plane in the air. I used to work for a drug company- it's in the 10-100s of millions there for a single drug. Why? Because people will die if you don't.
Open Source is no magic panacea. Bugs just don't go away- you need extreme levels of testing for products like these. If you can't pay for that level of testing as well as afford the insurance on such a product, then don't play. There's a good reason why there are no Open Source drug companies, and there never will be.
"Seven Deadly Sins? I thought it was a to-do list!"
..write code for nuclear powerplant after a meeting... ;)))
<^>_<(ô ô)>_<^>
Whether or not medical software is open or closed doesn't matter to much. What does matter is that it works 100%. The anesthesiologist doesn't care if it's Morally Superior(tm) Free Software, or Evil Capitalistic Proprietary Software, just as long as the decisions it makes won't kill his patient.
I work in the Medical Hardware/Software industry. When the FDA discovers a bug in the software, you MUST fix it. You don't have the luxury of hoping some other hacker might figure out a solution. You don't have the luxury of pondering what to do. You WILL fix it, and you WILL fix it by a certain date, or your software will no longer be used.
The FDA doesn't care if your license announces the lack of warranty. Neither does the anesthesiologist. Neither does the patient. It will be demonstrated to work right the first time it is used in a clinical setting, or it won't be used at all.
Because of these "rules", some Open Source project models won't work at all with medical software, and the typical "release it as GPL and post it on the net" is one of them. However, something similar to Apache's "gather a group of experts and limit membership" model would work. The FSF be damned when it comes to a patient's life! I don't want medical software to be "free"! I want the software under the developer's shackles and chains! I only want experts working on it. I don't want something that's Joe Schmoe's weekend hobby. If the developer needs to use a proprietary libary, I want him to have a license that lets him do it. Ditto for air traffic control software.
I'm sure that there's a Free Software development model that will work for such projects. And I am sure that there will be several such project. However, no proprietary closed source software that saves people's lives will ever be Evil in my book, ever.
A Government Is a Body of People, Usually Notably Ungoverned
I believe that things like medical software do not include a disclamer of liability. So yes in that case you *COULD* sue if you wanted to.
Just for the record many avation related things would have the same problem. You can't install anything in an aircraft without it being aproved by the FAA. For more or less the same reasons. This could cause some problems for Open Source General aviation Software. Which is annoying as I had been thinking about writing some.
Erlang Developer and podcaster
Open Source is already being used in at least one major International Pharm. where FDA audits are a regular and accepted thing. The argument for using it revolves around accepted risk, the same kind of accepted risk you have when using software from a defunct company, or distributed by the gov., or, ultimately, bought from a company whose lawyers have made an airtight escape clause from any and all responsibility. The company in question performed it's own QA on the software, made documentation for it's SOPs and then used it. In other words, it accepted liability for it (though it does help that Samba is used by many other major companies). There was less risk in using Open Source then using in-house because the level of testing and feedback from the Open Source community is so much higher than in-house. And anyway, the precedent is already set in most companies that use any kind of UNIX and use any of the Free Software that comes with it (sendmail, vi, etc). It all comes down to accepted risk (and if the FDA is involved, documentation stating you are aware of the risk, have analyzed it, and accepted it for these many good reasons).
One last note, the FDA does seem to distingish between device/embedded code and other types of code. The critical functionality is probably the reason. Although even a little wordprocessor problem, say one that moves a decimal point, is just as lethal the FDA is less worried about that. An arythmic heart machine vs. misrepresented dosage... I'd hate to have to make those decisions.
I work as a programmer for a Medical Imaging company (InSight Therapeutics), and I feel exactly as you are.
Before a medical device is FDA approved, it has to go through a lot of testing, the fact that millions of users COULD HAVE tested it is not enough. There has to be defined testing schemes/plans, and extensive documentations of the testing results, bug reports, bug fixes, etc...
Each new component has to go through a design review before implementation, and then an extensive code review. If either of those reviews is not satisfactory, you'll have to redo your work. Those reviews are not easy, and a lot of time a programmer has go back and reimplement some part of the code.
All the work has to be documented for regulatory porpuses, incl. all the formal/informal meetings, and we even have to save our notebooks. How will you collect all this information from the harddrives of 10s of the people that helped that OpenSourced project? How will you enforce them to save all the papers they sketched on?
Moreover, the workers should have a lof of knowledge in computer science, mathematics and physics. My boss interviews 100s of job applicants a year, but we only accept one new member in few months. In OpenSourced project you cannot check the background of every new programmer/alg. designer and confirm that he/she knows what he/she is doing.
We spend a lof of time talking to M.Ds, trying to understand their needs, going to operations, and trying to invent new MMI components that will work best in ORs. I'm afraid that OpenSource members won't be able to reach those Doctors. I'm not saying that it will be impossible, or that people that participate in OpenSourced projets are not as intelligent as people who work for software companies (hell, most of them do work at a software company), only that I'm not sure whether the doctors will work with them.
I KNOW that if I had to set the meetings with the M.Ds myself, I would not have met anyone since I don't have the time for all the administrative work needed to perform those meetings.
Before working for InSight Therapeutics I worked as a system programmer/administrator for Unix machines, and used a lot of open sourced software and helped some too. I just do not think that medical software is the right niche for OpenSource.
I am a big OpenSource fan, my home computer has only Linux (Debian) installed, and most of the programs I use (all but two) are OpenSourced.
Half a year ago we had to choose the platform for our next product. I enthusiastically offered Linux, and after a long discussion it was decided not to use it since the FDA might not approve the product.
BTW, is there an FDA approved product that works on Linux (I'll be able to use it as an argument for the next time we have this discussion).
Anyway, there are a lot of opensourced projects that need more help. If you have some time on your hands help those instead of statring new ones.
Lets hope that none of us will have to actully see the devices I work on in OR...
Enjoy (healthy) life,
Liran.
For example, how many of you know what DICOM is?
There are a lot of other examples, but I don't want to waste your time...
Liran.
...well, UCITA would free software developer from liabilty, as developer could put in his license, "if used for medical purposes, developer will not be held liable for any problems resulting from the use, misuse, malfunction, error, etc. that might be incurred by using this software". Lessee... SoftwareX w/o this waiver costs 10x more than software Y with it. Guess which gets bought. Think that if Clinicomp could get away wtih putting this in their license (under UCITA) that they would? It would mean they have to carry much less insurance or front much less bond money...it could be worth it for CliniComp to do that (under UCITA).
Somehow I don't think medical software is going to get a good push from the open source community. Making a big medical application/database is not exactly "fun" work akin to open source developemnt. Most successful open source projects are for productivity/desktop apps that the developers have fun with and will actually end up using in the end. I don't see that happening with a piece of software that tells a nurse when to give a patient their medicine.
"The voices in my head say crazy things"
It is important to supply open information regarding:
1/ Specification methods used
2/ How the software was validated and verified
Aircraft software is far more complex than medical software and many more lives depend on just a few computers. Sure it's incredibly expensive... But let's apply rigorous CS methods to life-depending software before releasing the code and all data as open source.
Later on, I found out how lucky we were to have the software running on Unix; there are stereotactic radiosurgery systems running under NT, which gives a whole new meaning to "blue screen of death".
Anyway, the question is this: would open source development benefit software that controls radiation machines? I don't think it would. Open source relies on the ability to make mistakes and correct them; medical software relies on not making them at all on live patients. That's why medical software goes through highly formal testing before it's released, and why open source software goes through alpha- and beta versions. However, that's not the whole story.
Especially in America, people are prepared to pay big bucks for anything related to health care. And the systems in use are reliable enough. Since open source development competes on the "cheap and reliable" ticket, I don't think it's going to make anything any better. However, it is definitely useful in two areas:
Bottom Line: Open source works better when there is a large developer base. I don't think that's the case for medical software, and I don't think it would work. I wish Stefan Harms all the best -- and he's chosen a project with a better than average chance of success -- but I don't think the medical profession would benefit from open source software.
GPL'd software comes with no warranty. However, this does not prevent a company selling GPL'd software and including a warranty. This is just one of the ways that one can make money selling Free Software. If you are able to provide some kind of accoutability for your customer, and that is what they are looking for, you can do that.
(assuming you are talking about GPL software, otherwise refer to your appropriate license)
I would mention how this compares to proprietary software but it has already been discussed.
As someone who working in the Medical Industry, I can tell you the 'closed source' stuff is more buggy than 'open source' stuff.
Lots of FUD in the comments going on here...
With closed source, I'm stuck relying on the single source for fixes. Whoever that might be.
With open source, if need be, I can hire someone to fix the problem, or get the fix for free, because everyone watches out for the problems together.
I'd trust my life to something GPLed with far more confidence to something with a EULA like Microsoft's. Ever notice that anything with Java isn't safe for use in Nuclear Plants, Medical equipment, or other 'dangerous' environs?
Help achieve Liberty in your lifetime - join the Free State Project - http://www.freestateproject.org
... then I will read the code. Yes. I am interested, I can understand it, and I presume you can, too.
You are misreading my statement. Look at the noun phrases : "medical software", "non-medical commercial software", and "best open-source software". Yes, I am comparing across domains. But medical software has configuration parameters, data storage, user interfaces, and (these days) TCP/IP networking, there are plenty of overlapping sub-domains to compare.
You, and a lot of other people here, are also confusing "open source" -- software whose source code is available to everybody -- with "volunteer software" -- software written by unpaid people.
I am looking forward to the next red herring, where someone compares "medical company tests its software" to "open source volunteers review the software. That's a false comparison. The real comparison is "medical company tests its software" versus "medical company tests its software PLUS independent volunteers review the software". In other words: A + B > A, if B is positive.
I used to work as a software tester for Win32 applications. I was wondering what OS/platform your company uses for your medical software? What kind of test tools do you use? Did you use off-the-shelf test tools or custom tools? My team had access to cool tools like Purify and BoundsChecker, but nobody (but me) cared about the results. Part of the whole "Let's just ship this sucker" attitude.
cpeterso
Check out The Case of the Killer Robot.
(Note. I'm biased. The author is my advisor.)