Medicine And Open Source?

A reader writes: "The British Medical Journal (BMJ) has an editorial on Linux and open source (BMJ 2000;321:976). Also available online." There's been a lot of attention about medical usage of open source software, but not for the typical free reasons, but because when lives are on the line, you want to be able to depend on software not to crash, and open source has a well-deserved reputation for stability.

Comments

And I thought...

[Trinition]

...this was going to be about open source medicine, not open source software used by the medical community. Not nearly as eye opening.

Re:And I thought...

[Anonymous Coward]

W2K running a heart-lung machine would be eye opening, for a few moments at least.

Re:And I thought...

[systmc]

Could open source medicine actually work, given the costs involved with research and the resources it demands...?
---

Re:And I thought...

[Soruk]

W2K running a heart-lung machine would be eye-opening...

Windows has detected the user wishes to exhale. Proceed?

[ Yes ] [ No ] [ Exit Program ]

Re:And I thought...

[Weirdling]

Here, here. An open-source medicine that I could just pop down to the druggist and acquire the drugs I believe I need based on my investigation of my symptoms would really improve my life.

Open source...the best medicine?

[Anonymous Coward]

Got a machine infected with some version of the MS virus? Screw McAffee. Think Linux.

Irony

[clinko]

I'll probably spent my whole life behind a computer destroying my body. But i get to write the program that will keep my pacemaker going later. That would suck if my heart Segfaulted.

More OSS propoganda

[Misfit]

Ha, my pace maker is running WinCE and it's been working wonderfully since they put it in last week. I think all of you OSS biggots need to reign...ugh, what the....BEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEP

Re:More OSS propoganda

[Guido del Confuso]

That wasn't funny. It was a lame jab at MS. Not at all funny, sorry.

Now, if you'd quoted or even paraphrased Monty Python, that might have been at least funny enough to offset the total lack of humor of that comment. I am, of course, referring to the scene in Holy Grail involving the Castle AUUUUGGGGHhhhhhhh.

hmm....

[august70]

I would still be worried about the level of support that a commercial company offers over what a part time hacker offers.

Re:hmm....

[Nos.]

And what hospital or other medical facility is going to hire a "part time hacker" as their support? Realistically, they're going to hire (or contract) a large firm with lots of people with lots of experience. Not some high school kid knows how to write a "hello world" program in 20 different languages.

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.

Let's be prudent about this...

[AFCArchvile]

...don't start open-sourcing cadavers without their pre-mortem consent. Also, stay away from the morphine, you'll OD for sure. And put on some OR scrubs while you're in here! Your presence here might give the patients infectious diseases!

I'm sorry, madam

[Anonymous Coward]

your husband died during surgery. The anesthesiologist was using 2.0.38, but the surgeon was trying out 2.4.3. The good news is the incompatibility has been fixed in 2.4.4.

I feel bloated

[Sharkey [BAMF]]

The Blue Screen of Death® never held more meaning. Sharkey
www.bamf.com

I wonder...

[CMiYC]

I hate posting knee-jerk reactions (did not read the article yet, sorry) but this idea just popped into my head.

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.

---

Re:I wonder...

[vsync64]

I think I'd probably be okay with it, but I'd want to know ahead of time, so I could put a lot more effort into the layout and double-checking of my code. If I had already written something and I got a message telling me it was being used in a hospital, I'd probably go back and take a good hard look at things. If I didn't understand something, I'd be disposed to do a clean rewrite of that piece, taking copious notes.

It's not my skills I'm worried about, just my normal less-than-perfect coding habits.

Re:I wonder...

[kyz]

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?

You could save yourself from those considerable worries if you remember to mount a scratch monkey 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.

Re:I wonder...

[Artichoke]

Hmmn... two points:

i) OS doesn't mean that every joe can hack on it, just that the source-code is made available with the product so that the customer has access and rights to it. If specifically medical applications (i.e. patient records s/w) was OSS, it would still be niche market, and hence in reality developed by companies selling the package.

ii) Original article is about GNU/Linux and free s/w in general being useable by medical institutions. Stuff like Linux and StarOffice.

Just my ha'pennth

-~ ~- -~ ~-

Emergency Monitoring Software

[Psiolent]

I work for a company that develops software for emergency call systems and for security applications. These are enormous systems monitoring fire alarms, burglar alarms, freezer alarms, and emergency call devices, like wireless pendants and wall switches. We also do some cool stuff like CCTV control and Text-To-Speech alarm annunciation over hand held radios, but that's not the point.

We've found that open source software is definitely the way to go when your hardware and software must be fail-safe (since lives are on the line). We originally had all our embedded boards running an embedded version of DOS, but we're in the process of switching over to an open-source OS. Our central computer software is written for Windoze (sorry) but we are considering doing a complete re-write just so it will run on an open-source OS.

I can say from experience that when lives depend on your software, you'd better run it on an open-source OS. I suppose there may be fail-safe commercial OS's out there, but nothing we've found that is mainstream enough to provide the necessary development tools. I'm glad to hear that the medical profession is moving towards open-source. It is a step in the right direction.

-----

Re:Emergency Monitoring Software

[adion]

Another thing to consider is thet fact that the NHS in England is hugely underfunded. Given that open source software is cheaper, reliable, and more easy to adapt, surely using it makes sense.

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.

I can think of one problem.

[b0z]

What happens when there is a problem with the software? Let's say for example, it is something that does critical calculations to determine how much of a certain painkiller a patient can recieve. Let's say that the calculations are slightly off, and that it causes a problem in a patient. The hospital is going to want someone to hold responsible for this. If it is open source, they can't take all the developers to court, as the hospital should have looked over the source code itself if it was concerned about it.

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.

Re:I can think of one problem.

[gunner800]

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.

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!

Re:I can think of one problem.

[foistboinder]

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:I can think of one problem.

[Wiggin]

that's what places like Lloyd's of London are for.

Re:I can think of one problem.

[gmhowell]

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....

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.

Re:I can think of one problem.

[b0z]

I agree that I have not seen any software without the standard "Use at your own risk" EULA, but I would think (and hope) that none of the medical, air traffic controller, etc. software could have that. They probably do say something to limit their liability to the software and that they are not responsible for hardware problems (unless both hardware and software come from one company, which is an even better situation.) I don't know though. IANAD (I Am Not A Doctor) and have never used any software in which uptime was critical enough that lives depend on it. I am interested to find out how that works though.

Re:I can think of one problem.

[Shotgun]

Let's see? Do I want to go to the hospital where:

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:I can think of one problem.

[foistboinder]

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:I can think of one problem.

[jekk]

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.

I'm glad to hear that this was your former job.

-- Michael Chermside

Re:I can think of one problem.

[alprazolam]

anything the government buys can be specified to work in a certain way. the government doesn't generally sues its contractors because it is a waste of money. instead it makes them pay a million extra $ or so and sends the broken stuff back to get fixed

Re:I can think of one problem.

[DebtAngel]

"there is a 1% chance I'll die from bad software and 100% chance that I can sue someone somewhere if I do die. "

Actually, I do believe there would be a 0% chance chance of *you* suing a hospital if you die of bad software, at least when done correctly. Unless God is a lawyer, of course.

Re:I can think of one problem.

[Nick Driver]

Air traffic control software is all written internally by the FAA. None of it is purchased from vendors... except the operating systems of the computers upon which it runs. Guess what hardware it runs upon? IBM big iron, that's right, mainframes. Seems only that the FAA-written software ever fails, though. The IBM mainframe OS software has legendary stability, owing to its maturity level.

Re:I can think of one problem.

[kingsquab]

...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.)

That's the problem. Why should the hospital assume this risk? They're not in the software business, nor do they want to be. They certainly do not want to become expert, at a code level, with every in-house application. If they are anything less than expert, how can they be sure their review was productive?

Re:I can think of one problem.

[bockman]

Let's say you are an engineer designing a critical system for the local hospital. You got a set of requirements (including safety and reliability reqs) and now you have to define you architecture.

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.

Lends a whole new meaning to...

[ackthpt]

The Blue Screen of Death

Nurse! Nurse!
SHE CANNOT HEAR YOU
Well why not?
HAVE A LOOK AT YOUR MONITOR
It's all blue, so?
COME ALONG


Sorry for the reference to non-Discworld readers.


--

Re:Lends a whole new meaning to...

[rgmoore]

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.

Re:Lends a whole new meaning to...

[adb]

Of course, when the patients watch "ER"...

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:Lends a whole new meaning to...

[Chris Mattern]

> Regardless, medical weenies know what you mean
> when you say "$patient is coding".

Whereas a Linux weenie would say, "Well, who
let him have a laptop?"

Chris Mattern

Proven, rather than open

[NineNine]

I have to disagree. I think that the premise of Open Source being reliable is wrong. It MAY be more reliable than certain more traditional closed-source products, true. But I'd much rather rely on a product that has been around for many years and has been hammered on by countless people, irregardless of whether it's Open Source. I would never run an Open Source database, when you have dinosaurs like Oracle around, that has been proven countless times over. If I want reliable, why would I risk relatively new Linux, when I could use, say, HP-UX instead?

Re:Proven, rather than open

[bmongar]

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:Proven, rather than open

[NineNine]

Of course you can still get support on Oracle 7! Do you think that companies with terabyte+, mission-critical databases just 'upgrade' every time a new version comes up? That's my point. We're not talking about a weekly Open Source build of MYSQL. We're talking about a product that has been in use for years, and currently supports I'm sure, many mission-critical apps already.

Re:Proven, rather than open

[sheldon]

Umm, Oracle is still supporting Oracle 7 up til the end of this year. If you give them more money they'll help you out next year as well.

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:Proven, rather than open

[vsync64]

MySQL? That's a bit unfair.

I'd feel reasonably safe if my hospital used PostgreSQL, though, since it supports transactions and such, and operates in full write-through mode by default.

Re:Proven, rather than open

[TheCodeFoundry]

Has there been any scientific studies done on stability with regards to Open versus Closed source products?

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.

scenes from an ER...

[subtraho]

Doctor: Now, we must be very careful with this incision, a slight mistake could cost the patient use of his body.

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

[ewanb]

I like the article. The more of these sorts of
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

[benshutman]

even better, open source formulas. most drugs can be put in one pill, instead its diluted so they can sell you more. imagine core recipes being public knowledge...hmmm....


NEWS: cloning, genome, privacy, surveillance, and more!

(OT)GNU icon used on "open source" stories

[yerricde]

Rob, if you're going to use the GNU icon, please make the headline match the philosophy behind the GNU icon ("Free Software" instead of "Open Source"). RMS gets kind of ticked when the two movements are confused.

Re:(OT)GNU icon used on "open source" stories

[MochaMan]

Was just about to write the same thing. Though it was Hemos, not Rob who screwed up. I would have thought that the GNU icon would be used for stories specifically related to GNU or the FSF, not just anything open source related -- that would cover 90% of what's posted here...

Potentially Dangerous

[karma_policeman]

What is aboundingly clear to me, is that software used in critical applications like medicine, should be written by professionals.

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:Potentially Dangerous

[vsync64]

I believe software for these critical applications should be written by [...] people who have sworn to obey a code of ethics[, not] a bunch of long-hair idealists.

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.

Re:Potentially Dangerous

[karma_policeman]

You seem to be missing the entire point. I want professional software engineers who have sworn oaths just like doctors. If I'm being treated by professional doctors, why should I want the software to be created by non-professionals? That creates a weak link in my treatment.

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.

Re:Potentially Dangerous

[GypC]

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:Potentially Dangerous

[MGodfrey]

>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

I don't beleive Software Engineers are licensed.
At least they are not in the UK.
Maybe it's different in the US???

-- And let there be light... so he fluffed the light spell

Re:I Can't Stop

[vsync64]

Here is an article from American Scientist. I suspect the information it has might help you.

Medical Open Source

[zpengo]

Medical usage of open source software has been shown to have beneficial effects, but it should only be used with a prescription and under a doctor's supervision. Recreational (i.e., non-medical) open source usage has been shown to result in neurological damage, increased appetite, and a lack of sexual potency.

Amen

[gmhowell]

The cost isn't an issue. (well, it is, with falling reimbursement rates, decreasing margins, etc. But that is a different story/rant.) But the ability to intermix systems and fix something is of great importance. The company I work for is now mired down with two systems, neither of which is remotely open source. Both companies take forever to respond and update. And given the fact that we pay fees for service...

And these two companies are typical of the (US) medical IT companies. None have a clue about how to achieve stability or have an idea that open (or Open, or Free) is the way to achieve widespread growth, HL7 compliance, etc.

Unfortunately, we get these products, because they are available now. It is not an option to wait. Something IS better than nothing (you should see the amount of paper we have to shuffle. Without a computer, it would be impossible.)

While sites like Linux Med News and openmed.org showcase products and ideas that are promising, nothing is quite ready for prime time yet.

Blame must be placed squarely in three areas:

First are practicing doctors. By and large, they are techno-phobic. At least when it comes to computers. Yes, when it comes to diagnostic tools and so forth, many want to be right on the cutting edge. But for billing and charting, most don't care. When a product fails, they are not surprised.

Second are docs to be. Docs in med-school do all sorts of nifty things and have neat toys to play with. Guess what? They cost money, and take time. Things like that don't work in the real world. In the real world, Dr. Romano (from ER) has some good points: if we don't stay in business today, we can't help anyone tomorrow.

Third, and perhaps most powerful, are the insurance companies. The problem with insurance companies are not that they deny care (on the contrary, they specify what they will PAY for. You can pay for yourself anywhere) but rather that each one has their own set of rules and requirements. This goes from the mundane (what drugs will be paid for for a given illness) to the absurd. The absurd lies in their billing and insurance eligibility. For the first, there exists a simple government form, a HCFA-1500 that contains anything you could possibly want to know about a charge for a visit. So why is there no comparable electronic form? Each company has their own electronic submission routine, some requiring a dial-up, some over the internet, some through a third-party intermediary. And the stream of information to each is DIFFERENT! Even sending a standard form to a third party results in different results. The second, time-consuming aspect is insurance eligibility. If your insurance is no good, you have to pay. Or else go to the doctor that YOU selected. To verify insurance requires a phone call. Or, we could use a card swiper to swipe a patient's insurance card. Problems are: not every insurance has a magstripe code. Each insurance requires their own mag stripe reader (which is truly difficult if you take 20-30 insurance plans) or their own web interface or their own phone number. Then there is the fact that only about 75% of the insurance companies out there are automated. For some, we have to wait for a human being to verify someone's eligibility.

Despite the public misconception that the AMA is a powerful lobby, it is not. It is also divided into at least two camps: primary care (internists, pediatricians, family practitioners, etc) and specialty care (surgeons, ENTs, radiologists, cardiac specialists, etc.) with their own agendas. Rural and urban groups can further splinter this.

There are only two entities with enough cohesion to make any changes. The first is the insurance companies. Problem is, they make money on the inefficiencies in the system. If a claim or chart is incorrect, they don't pay. But they still charge the patient their premium.

The second entity is the government. We can go on all day long about whether or not (and to what degree) the federal government should be involved in the health care industry. But the bottom line is that they are perhaps the only group that *might* have the patients' interests in mind when developing policy. However, neither of the major party candidates seems to have enough understanding of the issues. Ditto their likely surgeon generals, few of whom have ever been practicing doctors, and are usually teachers first, doctors second.

That should cover the billing side. The other side is diagnosing and charting. Rather than go on again at length, I will simply say that I place blame for this about 60% on the doctors and 40% on the federal government. The doctors refuse to go along with a low human-capital intensive electronic charting scheme, and the government has been screwing around for years to develop a common interface. Luckily, since these two camps have proven so incompetent, the insurance companies have not had to intervene to slow down the process and make it more inefficient.

Rather than my above email address, if you want to discuss this post:

ghowell@nospam.familyhealthcarepa.com

Linux Med News

[Tetsujin28]

Here's a site devoted to news & discussion of Linux and Open Source medical software:

LinuxMedNews


--------------------
WWW.TETSUJIN.ORG

A possible solution just occured to me.

[b0z]

I don't really know what type of software they would be using, but let's say that they are talking about diagnostic programs rather than embedded systems. With all the advances and new information that they get in this industry, it would make sense to have everything completely data driven. What it sounds like they would possibly need would be more along the lines of a scripting language for physicians. Of course, I think that it would be better to have something that is more along the lines of a gui, but to make it simpler to understand, we'll just say a scripting language.

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

[gunner800]

A few people have pointed out that using OSS leaves you with nobody to sue in case of a problem. Hospitals get sued constantly and would like someone to hold accountable.

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!

Too scary to contemplate

[Junks Jerzey]

Perhaps the scariest things about open source software being used in critical applications are:

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:petition to remove ugly ads

[gimpboy]

actually i think that thinkgeek is part of the valinux horde. plus i think that rob still has some say about the ad's.

john

Translucent scalpels

[karzan]

Considering generally the first thing open source advocates tend to add to software is translucent windows and huge pictures of scantily clad women, I would suspect that open source medical tools would include translucent scalpels and medicine bottles with bikini-clad women on them. And they should make Matrix-like sounds every time you move them about.

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.

[Ndog]

Here's an actual reported case involving BSOD.

Can't you just see it...

[Mike1024]

Hey,

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?

[mrbuckles]

One thing I would think that purchased software offers over open source software is easily identifiable accountability. I know that companies I've worked for -- whose systems do not mean the difference between life and death -- shy away from open source software because there is no one to blame problems on. While open source may be more reliable, there's no credible promise that can back this up.

Are hospitals willing to take the risk?

Anti-Obsolescence

[Zachary DeAquila]

It seems to me that the main benefit of an Open Source-based product has to a large institution like a hospital or government is its longlivedness... the source isn't going to go away or become obsoleted by the next rev of features they dont need. It's not going to never get ported to the latest fastest machine. The company that supports it isn't going to go bankrupt and turn their investment worthless.

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

[maddogsparky]

A lot of hospitals use some version of a MS GUI in their nursing stations to run administrative programs, etc. To my knowlege, you couldn't really call any the Windows versions failsafe.

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

[Imabug]

Another barrier, particularly for software written for diagnostic or therapeutic applications is that the FDA requires 501(k) clearance before the software can be used on patients, and this requires ex(t/p)ensive testing and trials.

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

[sheldon]

I'll probably be modded down as a troll, but that's ok I've been karma whoring for a while now. :)

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:Reliability

[Mandomania]

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

OS software not perfect for medical situations...

[brianvan]

While I do believe that open source software is very reliable and stable, and that it would be appropriate in a medical setting, I don't think it will happen anytime soon.

First of all, major vendors spread all kinds of FUD around, and you don't know what independent corporate salesmen/consultants are saying to doctors who know very little about computers. While this doesn't mean that open source software is any worse in that environment, admittedly it doesn't have much of a presence currently. That means there's few examples for OS advocates to present when recommending OSS.

More importantly, open source software is generally produced by a undefinable group of people... not one company. However, if something goes wrong with the software, there needs to be someone to be held liable. The main disadvantage of OSS in this environment is that generally NO one can be held liable if something does go wrong - sadly, whether it's the software's fault or not... because the equipment manufacturers can just blame the software in cases of hardware failure and no one would figure out the real cause nor would anyone defend the software. At least with a company being contracted for the software, there's someone to point a finger at.

That's another issue... these things have to be contracted out, and obtained on a set budget. The medical industry isn't going to look on Freshmeat for their critical applications, they're going to call a contractor or a consultant who will give them a definite recommendation for a software solution. And as far as I know, there are currently few medical-use open source applications, and there's virtually no incentive for anyone to write them. (other than the "challenge")

It's a chicken and egg problem, one that won't be avoided because a couple of hard working medical software companies will get generous one day and simply release the source code to programs that happen to make a lot of money for them already. The advantage of having thousands of people test and fix the software instead of a small in-house team is very tempting... but ultimately, the concept of OSS needs to gain more widespread popularity overall before it starts really reaching into these very specialized, mission critical, lucrative markets.

No offense guys. OSS will probably work better, but that's gonna be down the line.

For some stuff it's ok.

[scott1853]

I live in a small town (6,000 people) and whenever I go to the hospital, they always have to call over to the "other" buildings to get the paper records. I wouldn't see any problem using open source software to access patient records in a database. It's just doing a query against a DB. It would be more effecient. And if the server went down (they should have a backup anyways) then you could go to the paper.

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?

Gives a whole new meaning to

[jszep]

the Blue Screen of Death...

Here's a little reality.

[mwalker]

Here's a little bit of reality, try not to chew it too hard.

Linux isn't a real-time operating system. It makes a great real-time controller, but it just doesn't have the granularity to do real time.

As far as embedded medical software goes, there's only one name. And it's not vxworks, the microsoft of real-time embedded, either. That's the stuff that crashed the mars explorer.

ALL medical embedded stuff runs OSE by Enea systems. It comes in three kernel sizes, and it has the best error handling and inter-process communication constructs ever built, from a reliability standpoint. There are OSE systems out there with 10 years of uptime. In addition, OSE can make the interesting claim that it is impossible to crash the OS. This type of reliability is found in a field called "safety-critical systems", and ENEA nearly owns the market. Take a look at the data sheets on their web site.

Here's a great quote: "it is impossible for user processes to corrupt the OSE kernel."

And they're not kidding.

Open Source is a truly wonderful model, but keep in mind that a closed group of true experts can also make great software.

Re:Here's a little reality.

[DaveHowe]

Here's a little bit of reality, try not to chew it too hard.
Linux isn't a real-time operating system. It makes a great real-time controller, but it just doesn't have the granularity to do real time.
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.
--

Re:Here's a little reality.

[Just Some Guy]

Here's a great quote: "it is impossible for user processes to corrupt the OSE kernel."

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.

Re:Here's a little reality.

[mwalker]

Apparently, Enea has implemented "The Halting Problem"

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.

Re:Here's a little reality.

[mwalker]

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,

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.

[Kaufmann]

Well, I don't quite believe that by impossible Enea means "actually and provedly impossible" (instead of the usual meaning, "really damned unlikely") either.

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.

Re:Here's a little reality.

[Just Some Guy]

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.

[Just Some Guy]

Heh, ok, your sarcasm is appreciated.

Thanks. Its intent was light-hearted. :)

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.

But... The only way to prove that is to either:

1. Implement "halts(*program)" which can tell that either a program is well-behaved or not without actually running the program, or
2. Generating every possible combination of inputs (including code!), and test every one of those combinations to see whether each one can or cannot crash the machine, which still involves our "halt()" function.

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...

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.

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.

[Kaufmann]

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.

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:Here's a little reality.

[Bj�rn Stenberg]

ALL medical embedded stuff runs OSE by Enea systems.

Yeah, right. I happen to be working on "medical embedded stuff" right now, for one of the major players in life support systems. And we aren't using OSE anywhere. Not linux either.

Here's a great quote: "it is impossible for user processes to corrupt the OSE kernel."

It's called "marketing", ever heard of that? Don't believe everything you read in glossy brochures.

Re:Here's a little reality.

[rho]

won't be executed - not in userland, anyway

I dunno why, but I find that term, "userland", to take on a completely different meaning when you're talking about pacemakers and heart monitors. "We put the user back in userland".

I think I've been working with Oracle too long today -- my sanity is beginning to slip.

No, there is no point to this post.

Re:Here's a little reality.

[Listen Up]

Has anyone here on Slashdot heard of QNX? They have been making an OS for real-time and HA medical equipment for a long time. Linux on my heart monitor or pace maker? Are you fucking kidding me? Yeah, here on /. Linux is made out to be a god, but it is in ABSOLUTELY NO WAY stable enough to bet my life on it. OSE sounds neat, but if I was going to write software for something as critical as a pace maker or life support system I would write ASSEMBLY code SPECIFICALLY for the hardware and job function at hand. Keep it simple...debug it, debug it, debug it, debug it and certainly not make it do anything else except the job at hand.

Re:Here's a little reality.

[Arandir]

Well, I work on the number one ultrasound machine in the world. Its OS is LynxOS. There's more to embedded medical devices than just pacemakers...

Re:Here's a little reality.

[DaveHowe]

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.
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.....
--

The plaintiff bar would love it

[Vassily Overveight]

This would open whole new worlds of possibilities for the U.S. trial lawyers. Imagine having a universe of open-source contributors to sue into oblivion. ("Now tell the court, Mr. Fleenman, just why you decided not to unroll the loop at this point in the routine ...").

This is just talking about vanilla IT

[update()]

Did anyone read the article? Anyone? It's talking about plain old "information systems" used in a health care setting. The article is extremely short on specifics, but it's certainly not arguing for the use of open-source products in specialized medical devices. Mostly it's the usual Introduction To Open Source boilerplate.

Re:This is just talking about vanilla IT

[Artichoke]

Did anyone read the article? Anyone?

<joke>Hell no</joke>, and I'm the reader who posted the (somewhat overblown, but now trimmed down and non-attributed (harrumph)) submission.

Shocking idea. Just where do you think you are, expecting people to read the original article. :)

-~ ~- -~ ~-

Closed source allows blamed to be pinned

[Fervent]

One aspect of closed source software that really hasn't been discussed is the potential "advantage" of having a responsible party for lawsuits.

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.)

Re:Closed source allows blamed to be pinned

[Graymalkin]

Why the fuck would a pacemaker need an OS in the first place? It has extremely primitive functions and doesn't need any messages or calls passed between one set of hardware to another. At the VERY VERY VERY most you might need a microcontroller to regulate the pulse output. In which case you would only need a BASIC stamp or something even smaller. You don't need TCP/IP on a pacemaker.

I can hardly wait

[pac4854]

The day I'm forced to choose between a pacemaker running WinCE or one running RedHat, I'm going to ask the kind doctor for a prescription for 250 secobarbitol. And a refill won't be necessary.

Re: Make medicine open source

[slickwillie]

Well, pharmeceuticals to be specific. I would love to get my hands on the "source code" for a few things.

Comments from clinicians

[VSarkiss]

After reading the article, take a look at the high-quality discussion on this page.

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.

It's about the model

[Tyndareos]

Reading all these comments I just had to get this of my chest: using open source software in the field of medicine is not about running existing open source projects on medical appliances, but using the power of the open source model.

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.

Re:It's about the model

[Cap'n enigma]

Thank you for an intelligent comment. Reading through all the comments it is evident that most of these people here either did not put much thought into their answers or they have very little imagination.

I think that medicine should heal open sores

[joshv]

Definitely this a very good application of medicine.

-josh

A Sigh of relief.

[wackysootroom]

Its a good thing that the medical field is looking at open source. I would hate it if the last thing I saw in my life was a blue screen on my vitals monitor and a doctor hitting CTRL-ALT-DEL.

Re:A Sigh of relief.

[wackysootroom]

Looks like someone didnt get a cookie in thier lunchbox today.

Re:petition to remove ugly ads

[_xeno_]

Hemos has said in the past (and in the Slashdot IRC chat) that about the only control they will exercise (and not nec. may) is to prevent Java applets/Flash shows from being served. Other than that, any GIF that's standard-size is fair game ad-wise.

Re:Life support

[locoluis]

AC Wrote:
> 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

[drivers]

I was thinking there would be some benefits of creating an open source interface engine (a program which translates and routes HL7 messages) The current ones are not the best technology, but most of all when you buy them you get stuck with a single vendor's support argeements (and excessive rates), you have to pay for any extra functionality, and all the usual disadvantages of closed source software (which need not be repeated here). This sounds like it might even be feasible considering if the software was good enough, a vendor (or vendors) could still sell support.

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.

Why Open Source makes sense for Medicine

[Cap'n enigma]

From reading the comments the consensus seems to be that this would be a bad thing, but, I disagree. I think it makes perfect sense. My response to the objections raised:

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.

Linux has been used in medicine since day one..

[cowmix]

Medweb has been using Linux in their distributed telemedicine systems since 1992. (www.medweb.com)

Medical and opensource philosophies don't mesh

[Anne Marie]

That's a generalization, of course, but it's a necessary starting point for discussion. Currently in the US, medicine is the province of an elite cabal of practitioners protected from competition by rigorous liscensing requirements imposed by states. Open-source software is the province of a diverse field of programmers, excluding no one who applies for admittance. The barrier to entering the medical community is more than a decade of higher education and several years of apprenticeship (my friends call it slavery). The barrier to entering the open-source community is merely a demonstrably useful piece of code or a neat project idea. Achieving status within the medical community confers the title of "Doctor". Achieving status in the open-source community, if you're lucky, conveys the title of TLA (RMS, ESR, etc).

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:Medical and opensource philosophies don't mesh

[Cap'n enigma]

Since almost all medical knowledge is open and available to all, I would argue that the philosophies mesh wonderfully well. Even if they did not mesh it wouldn't matter. As an example look at China, possibly the most closed system in the world, but they are embracing open source.

anesthesia and open source

[macnigel]

An excellent article found here http://www.salonmag.com/tech/feature/1999/08/05/an esthesia/index.html An anesthesiologist I worked with loved the idea of open sourcing anesthesia software, the only reason he didnt use it was *if* the software is at fault, he would be liable. There's always a catch.. More information relating to medicine and open source, for those interested can be found here, http://gasnet.med.yale.edu/lamdi/

no it isn't

[Anne Marie]

Since almost all medical knowledge is open and available to all

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:no it isn't

[shilly]

Sorry to state the obvious here, but the reason why the supply of doctors is limited, and why there are such things as "qualifications" is because YOUR LIFE IS IN THEIR HANDS. you might dismiss this now, but i'll bet that if you ever need a CVS or some other technical procedure you'll want as qualified a person as possible carrying it out.

Read the rapid response reponses

[Hoo00]

The journal has a lot of good comments about the article. Some of the comments deserve more +5 moderation than the /. posts here.

Of course, these do not include RMS's GNU/LINUX comment there, which still gave me nightmares at night.

RMS: you said the wrong name! Bang!

Re:Bottom Line?

[SecretAsianMan]

Let us assume your comment is true for a bit. Then, it's quite a sad fact that us hippie, amateur coders produce better software than most of the other, truly gifted programmers. What's wrong with them? Why can't they get their act together?

</SARCASM LEVEL=BITING>

Nah, backup

[Cap'n enigma]

What you are talking about is the barriers to getting licensed to apply that knowledge. The knowledge itself is there for anybody and everybody.

And who will pay for certification ?

[Megasphaera Elsdenii]

This, unfortunately, won't work all that easily. A while ago, this pharmacist developed Linux software for automatically administering drugs on a drip so as to keep the drug at some level.

IIRC, the problem1 were 1) who is liable and 2) who will pay the certification costs for it to be approved by the FDA (because without FDA approval, you're nowhere).

Read the story here. (I believe this was once on /.)

OSS and Medical Software

[Arandir]

Do the archetypical benefits of Free/Open Source fit medical software? When you look at the "big" projects in OSS, you see GIMP, Linux, Perl, Apache, etc. All fun and exciting projects to work on. And software that ordinary developers can use and tinker with.

I work for a company that produces medical software (for medical equipment). I keep asking myself who those "thousand eyes" inspecting the software for bugs will be. Strangely, the name "J. Random Hacker" does not come to mind. In fact, the only people I can think of that would be interested in this stuff are our competitors.

Other than medical administration software, and *boring* DICOM communication protocols, most medical software is written for very expensive equipment, or equipment that is very expensive to install (as in a chest cavity). I don't know any hackers that have a spare MRI in their basement, and the number of them that could even afford one is miniscule.

And who wants to mess around with pacemaker software? Show me a hobbyist that wants to tinker with that, and I'll show you someone lacking common sense.

There are many good reasons to Open Source medical software. But a "bazaar" development model, a thousand scrying eyes, and user-submitted bugfixes are not them.

stability does not follow from open source

[h4x0r-3l337]

The reason for the stability of some (not all) open source software is that it is tested by a zillion people under real-world conditions during development. This is impractical for medical applications because lives are at stake. Would you want to be the guy that gets an overdose of chemotherapy, even if it means finding that nasty bug? Sure, the bug will be fixed due to the "test", but meanwhile you'll be dead. Open source is good for a number of things, it is not the ultimate solution to everything.

Re:offtopic; what would make slashdot better

[Graymalkin]

This is a Tacocracy, not democracy.

Punching a nun

[Graymalkin]

This article is not about trying to stick Linux on a microcontroller that runs a heart monitor. This is about using Open Source for the information systems in hospitals. Lots of institutions are paying a premium for their IS systems because they are forced to go with proprietary vendors who charge as much as they can and hold the reins with their licenses. I think though that dispite using an open (read free) OS they would still use commercial applications as to have a source of support were something to go wrong or they merely need help doing something.

External auditing for safety-critical software?

[Goonie]

It's been well-covered in this thread and elsewhere that bazaar-style development makes absolutely no sense for safety-critical embedded software such as the kind that runs on medical radiation machines, because a) relying on the possibility that somebody *might* check the code ain't good enough, and b) the development and test environment ain't exactly widely availble. However, one thing that open source does make possible, and projects like OpenBSD demonstrate the value of, is external auditing of code. Presumably writers of safety-critical systems like these are subject to extensive auditing.

What kind of auditing procedures is this software (or, really, the entire system) put through?

Lot of orthogonal arguments here

[Chris Johnson]

This is weird- of course the idea with OSS medical software isn't to get 10,000 teenage hackers debugging it. That's an absurd notion (though there could probably be a code base with reusable components that have been proven reliable).

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:OS software not perfect for medical situations.

[mazur]

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.

That's as may be, but apparently they are failing more and more in getting to be believed. Read the article of this story to see what I mean.

Stefan.
It takes a lot of brains to enjoy satire, humor and wit-

Re:Pro Linux Troll ?

[Psiolent]

The company is my father's. Because of this, I have worked here since I was 15 years old. I am now 22. For the first several years, I worked as an apprentice to a senior software engineer (being the boss's son is cool) and eventually started working on projects of my own.

So, no this is not a Linux troll. And yes, I have gained that much experience even though I am still a college student.

-----

Liability is the key

[GodOfHellfire]

hospitals won't ever want to use open source software, and here's why: liability.

let's say that the hospital is using an open source documentation product. dumb-employee-who-thinks-he-is-god's-gift-to-codin g (everybody knows somebody like this) tweaks the code to make something faster. little does he realize that now the interface with the blood pressure monitor is now broken - bp is charting much lower than it actually is. the physician reads the chart, sees that the bp is too low, and prescribes medication based on that. the medication kills the patient.

the patient's wife will sue and who is liable? the hospital. for a lot of money, too.

if this happened in a close sourced prodct from a vendor, the vendor is now liable, not the hospital.