Medical Open Source Boot Camp

Executive Summary

The Open Source Movement is about source code. People who can't program should get out of the way.

[Note: Real Programmers are experienced programmers that are 100 times more efficient than average programmers. Think Carl Lewis vs Roseanne. ]

Let's break it down this way:

1) You are a real programmer and you want to start a project from scratch. Go read ESR's papers. You need a working program that's useful to you first. No one can tell if you are a real programmer if you don't have code. In fact, you can't be a real programmer without the code to prove it.

Your goal is not to get people to follow you and write your software. People don't like being exploited. People will follow you if you are already going somewhere and doing something useful. [ Proof: Stand up in a crowd and say "I want to be your leader and you should all follow me." Wonder why people followed Ghandi, but not you. ]

When you are a project leader, people will add to your program and send you the results. Your job is NOT to incorporate them all. Your job is to evaluate them. If it's a good feature and it's good code, then you incorporate the code. If the code is bad, you can rewrite it yourself, or send it back to the author. If your criticisms are valid, the author will be happy to rewrite it the way you want it. After all, the author wants to feel useful. If a contribution is accepted, that means the author is trustworthy, and you should incorporate him in the project decisions. You may even break off a piece of the project and give him responsability for it. If there are disputes, they are settled in the 'pecking order'. You are at the top, the others are valued according to their contributions.

2) You are a computer novice and/or you think you can program. Of course, you want to start a project from scratch because it's no fun following others. You assume that real programmers will tell you what to do to make the project better. The problem is that you can't tell a real programmer from a self-inflated poser windbag. You will get good suggestions and bad suggestions, but you won't have the experience to know which are which. Even worse, real programmers will instantly detect that you don't know what you are doing and leave. They can detect you, but you can't always detect them. [ Proof: Build a house without plans. Try to detect which of the passers-by are expert builders. See how many expert builders detect that you aren't one of them. ]

Your best bet is to join an existing/established project and contribute as best as you can. Even as a novice programmer, you can point out errors in the documentation, write a FAQ, ask intelligent questions, find bugs, etc. If you have valuable contributions, you will be recognized as one of the contributors to the project, and you will gain experience and be allowed leadership. Only after you have experience can you consider yourself a real programmer. Warning: Not everyone who wants/likes to program can become a good programmer. If a project leader dumps on your ideas, remember that they are experienced, and you are not. [ Proof: A Zen student wants to "hurry up and figure out what this Zen thing is already". The master laughs. Should the student resent the master? ]

3) You are a doctor and you want to help out. First, admit that you are not a programmer, and you couldn't tell a real programmer from a dorky kid with glasses. Don't try to program any more than you would try to rebuild your car's engine. You don't have the tools or the expertise, and you will make a mess that even an expert wouldn't touch.

Next, recognize that the medical profession isn't likely to drive breakthroughs in technology. (Sometimes, as with MRIs, they do, but not real often.) When it comes to computers, doctors are way behind. [Proof: Go to a hospital ward or outpatient clinic and count the number of staff with and without a computer. Go to a 'conservative' bank and try to find an employee without a computer. ]

You have heard about these ".coms" doing "e-business" and making everything computerized and you want a piece of the new-fangled action. But recognize that all that glitz was built on 10-30 year-old technology (TCP/IP, UNIX, e-mail, Databases, perl, the Web). [Note: The first 3 were started in the 60's. Perl was written in the mid 80's. The Web was invented in 1989. Great, now I feel old. ] Ignore the latest buzzwords -- they are for the computer people, not for you.

If you want to help, do some thinking and write down what you want. Remember, Thinking Is Hard. Writing down the first thing that pops into your mind won't help ("I think it should be user friendly"). Don't tell programmers what to do ("It should be done in Java and XML because I hear those buzzwords a lot"). Be pragmatic and practical (Would you have a highly skilled nurse do data entry? What if it increased the accuracy of the information?) Recognize that almost no vendors have a useful EMR system, and the few places that have one can't replicate it elsewhere. [ Quiz: What do Motorola, Intel, Kodak, 3M, Bell & Howell and Siemens have in common? They all have health care divisions, and most are churning out useless software like there's no tomorrow. None are known for their good programming. Few are likely to attract good programmers, when good programmers can go work for .coms. They all have enough money to write junk and just 'see what sticks'. ]

Your best bet is to give a dose of reality to programmers. Programmers assume that everyone can type, everyone knows how to navigate a file system, etc. If you have experience with an EMR, write up your thoughts, both good and bad. Is it unrealistic to ask for exact hospitalization dates because few patients remember them? Is it more useful to have large friendly icons for navigation or an information-packed control panel that shows at a glance what you need know? What information do you need on the screen at all times? Would you rather see a list of 100's of tests performed on the patient, or a short clinically relevant summary? Would you rather have items sorted by date (episode) or by type (type of test)? (hint: neither is right.) Do you want to enter a lot of data so you can see it later (the computer is just like a chart), or do you want to enter a little data so it can help you track and manage your patients (the computer can do more than a chart ever could)?

Writing a program isn't hard, but making a program useful is. (In exactly the same way that firing a gun is easier than aiming a gun.) Ok, this is degrading into a rant because I've run out of useful things to say. [ Proof: Try to find my last point. ] Here's some tips:

• Do fund open source software developers. No, don't stuff cash in an envelope. Hire some random techies to investigate open source software. See if you can devote a departmental server to be a source code mirror. Donate old hardware to promising projects. Grill your software vendors on interoperability issues ("Does your software work on my mac and my daughter's Linux box?")
• Don't try to start a programming project. Leave the programming to the programmers and we won't try to see your patients. Thank you.
• Don't try to control an existing project either. You can make suggestions, but don't get angry if no one follows you.
• Do start a web page, but recognize that it won't help much with writing software. It may help people doing google searches.
• Don't try to co-opt open source by doing something that doesn't involve source code. The "Source" in "Open Source" refers to source code, not some abstract 'source of all that is good in the universe'. You can label it "Open Wishful Thinking" or something. [ Tip: I hear that the "Power" and "Active" buzzwords are under-utilized this week. ]
• Do understand that sarcasm rules the net.
• Do accept that programmers look down on techie doctors in exactly the same way that doctors look down on patients who say "But I just read about a new experimental drug that they got to work on lab rats once."
• Do download software and send e-mail to the authors with suggestions. But be aware that some software tries to solve issues that you don't understand yet (but will).
• Don't write anything without the net in mind. The GUI wars are over. The Web has won. Things that are not web applications better have a darn good reason for doing so. Things that do not store their data in a database should be taken out back and shot. Hint: My/mSQL are not real databases.
• Don't think "Programming can't be that hard". Any attempt to dumb it down (e.g. Visual Basic) should be looked at with the same disdain as a "Do-It-Yourself Surgery Kit" or attempts to "fix" the fact that people drop out of med school. Programming is hard in exactly the same way that saving someone's life is hard.
• Do investigate wireless. 802.11b is your friend. [ Hint: All the cards are really made by Lucent. ]
• Don't think that a PalmPilot would be the perfect tool if only it had decent medical software. Graphitti is slow, carrying around a keyboard sucks, the screen is too small, it has a proprietary OS and the handspring port is proprietary. Don't hold your breath for WinCE either.

Signed,

A Real Programmer (TM) sick of all the useless "follow me, I'm clueless and I've got a plan" projects.

<  |  >