Writing Open Source Medical and Nursing Apps?

SteamedPenguin asks: "I am writing a Fick Cardiac Index calculator. It isn't quite finished, but it is almost done. I am bitten by the bug. Writing software, even simple software, in the health care field is fun. I see a good number of Slashdot readers who are either health care practitioners, or claim to be, so I am curious if there are are other nursing and medical tools out there that are written using Open Source languages, and/or are Open Source themselves. Google gives a good number. I am specifically interested in Open Source applications though. I am also interested to hear from people who are writing such software. Can these applications be released under the GPL? Are the algorithms proprietary? What resources are there for people who want to implement these small helper applications?"

Comments

Linux Medicine How-to

[peripatetic_bum]

Being one of authors, I will plug a good resource. Call the Linux Medicine How to. If you see any problems with the how-to, let me know and I will fix it.

It can be read at Linux Medicine How-to

Comments are appreciated

OpenEMR

[bentfork]

I have some MD friends, and I help them with their softwhere on occasion. A couple weeks ago I came across OpenEMR.

It is a OpenSource ( I couldn't find the license, but probably its GPL'd) Electronic Medical Record system. It looks great, I will probably be demoing it for some Doctors in the near future. ( once I get some time to install it myself, check the code etc... )

from the site: www.openemr.net
OpenEMR is a Free, Open Source medical clinic practice management and electronic medical record application. OpenEMR offers

• 1. Practice Management features for patient scheduling, patient demographics;
• 2. Electronic Medical Records, creating an on-line record of your encounters;
• 3. Ability to enter CPT and ICD codes at the end of a patient encounter;
• 4. Advanced reporting capabilities with phpMyAdmin, which is now packaged with OpenEMR;
• 5. Prescription writing capability with ability to email or print prescriptions;
• 6. HL7 support to parse HL7 messages; and
• 7. HIPAA compliance.

Freemed

[BrynM]

Freemed is good. You'll have to dedicate a machine to running it, but all of the people in the office use it from a web browser. It's also heading torward FULL HIPAA compliance. Good luck.

Re:Sigh

[s88]

Exactly what, pray tell, do you think is wrong with the phrase: "Are the algorithms proprietary?"? Proprietary algorithms are fairly prevalent in the medical community.

And yes, there certainly is such a thing as an "Open Source Language" (Perl) and a non-open source language (C#).

linux med news

[Cyn]

Linux Med News covers just about everything you're wondering about in this area - check them out, you'll find enough material to chew on for a while searching their archives. I'm sure more happens in the field than they track, but they centrally track more than I've seen elsewhere.

http://www.linuxmednews.com/

open Source Health

[Karora]

Open source has some amazing examples in the medical field.

"Vista" is the system used to run a couple of hundred hopsitals - particularly the veteran's administration. It's open source (public domain), and nowadays can run on a completely open-source (GPL) stack, as well.

Or there's Care 2000 (probably Care 2k by now) which runs a few European hospitals.

Debian has a sub-distribution for Medical software (debian-med) which includes more "focused" stuff.

And, as someone else points out, linuxmednews will give you regular gossip for the sector.

Be happy! Be healthy!

What about freshmeat?

[WSSA]

Freshmeat has an entire section of medical apps:

http://freshmeat.net/browse/266/

DO NOT DO THIS UNLESS YOU'RE DOING IT PROPERLY

[RMH101]

...for any system that records electronic records of patient data, you're required by law to document, validate and formally test it to within an inch of its life. i do this for a living - this is not the kind of thing you can knock up in your back room and use in a medical setting for very long without getting sued/closed down by the FDA/etc.

If you don't know what 21CFR-11, validation, ER/ES etc are, then you should not be doing this.

Re:DO NOT DO THIS UNLESS YOU'RE DOING IT PROPERLY

[Anonymous Coward]

No. But if your tool is being used to decide treatment/diagnosis, and it has a flaw which can cause inappropriate treatment/diagnosis to be made, you can and will be held responsible.

If the doctor makes a math error in doing the calculation, it's their responsibility. If they trust your tool not to make math errors, it's yours. If you don't do thorough testing and documentation, distribute your app at your own risk.

Re:DO NOT DO THIS UNLESS YOU'RE DOING IT PROPERLY

[RMH101]

well, you can't sell it. trust me on this, this is what i do for a living. and yes, the FDA would regulate pocket calculator output if it was being used for clinical submission data. seriously.

Because I like PHP was: Um...

[SteamedPenguin]

I am never sure if the IT department is going to turn JavaScript off at the terminals. Most importantly though, I use PHP because I like it, and to teach myself. I am generally not disposed to learning languages that I can turn off at the browser and whose implementations vary from browser to browser. It is bad enough with markup languages. If the server goes down the Nurses can calculate the Fick CI by hand as they usually do. This is is just a calculator. At some point it is likely that the application is going to be implmented on our stations' intranet in which case I might not be able to use PHP anymore in which case I have two options: rewrite using JavaScript or ASP. If the former then we'll have to make sure JavaScript remains turned on, if the latter then it is my employers problem not mine. I'll add the unit measurements. The nurses hadn't mentioned it so it slipped my mind.

Re:Um...

[peacefinder]

Server-centric operation will be helpful for compliance with the HIPAA security standard. (Not required, just helpful.)

The less you need to transmit Electronic Personally-identifiable Healthcare Information, the simpler your security problem will be.

Storing ePHI on the local machines raises all sorts of complications regarding physical security of (and data destruction upon) the point-of-use devices that are a real pain in the arse. If the end user gets the ePHI through a browser, it's a much simpler matter to ensure that sensitive data doesn't persist... just make sure the browser cache time is really short. :)