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

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.

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.

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.

-----

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.

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

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

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

[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

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

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

[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"

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

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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