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

Should I just filter Cliff stories out?

[Anonymous Coward]

I mean, c'mon. This is beginning to look like a retread of the April 1 selection.

Sigh

[QuantumG]

"Open Source languages", "algorithms proprietary", some people really shouldn't string words together.

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

Re:Linux Medicine How-to

[SgtChaireBourne]

If you see any problems with the how-to, let me know and I will fix it.

Cool, a colleague has been asking about something like this. How about links to the tar ball? Or cross links between the one-chapter-per-page version and the the monolithic version?

My work style may change again, but for right now having a monolithic version for easy download is a big bonus. Not much use getting on the train, boat, airplane and discovering that I only got a portion of the material and probably won't make time later to try again.

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.

Re:OpenEMR

[BoomerSooner]

How is it HIPAA compliant?

Do you care to elaborate?

HIPAA compliance is really not something that can be said about software. It can be non-compliant (ie, no user tracking, no admin logs, etc..) but the implementation is beyond software capabilities (generally, unless it's using biometric devices to verify users). So a office may be HIPAA compliant or not regardless of whether they use this software.

Re:OpenEMR

[bentfork]

All that I know is

HIPAA = Health Insurance Portability and Accountability Act

If anyone knows anything about complience I would be interested.

Re:OpenEMR

[peacefinder]

It might be better to talk about "HIPAA Capable" or "HIPAA Ready". As another poster said, HIPAA compliance is a much more complicated matter than just software. It is no more correct to say that a piece of software is "HIPAA compliant" than it is to say it is "ISO-9000 compliant". Both are broad standards that cover a range of practices well beyond the scope of any possible software.

HIPAA has three sections: Transactions, Privacy, and Security. I'm more familiar with the Privacy and Security regs than Transaction standards... but I think it might be possible for y'all to claim that the software "fully supports HIPAA compliant transactions".

You'll have to do some research on the final rules.

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.

advice

[bersl2]

Test the software very well, especially if anyone's life might depend on the output.

Just making sure...

Um...

[ObviousGuy]

Forgive me if this is covered somewhere on your site, but why do you use PHP to implement this?

If your server goes down, the tool is completely useless.

If, OTOH, you had used Javascript to process all this locally, then the webpage could be kept on a local machine and have the results immediately instead of having to load a second page.

As far as your program goes, you need to label the text boxes with the units measurements.

Re:Um...

[abrotman]

I dont know the algorthm for this .. but JavaScript sucks .. i mean .. like bad .. worse than VB. Just doing simple string manipulation can be a bear in javascript. PHP also has many functions built into the language.

Re:Um...

[ObviousGuy]

Javascript must be able to perform simple multiplication and division. That's all that is required.

From the site: "The formula for calculating the Fick Cardiac Index is: BSA / (1.36 * Hgb * (Oxy. Sat. - Oxy Hemoglobin))"

This program could be implemented in just about any language in an hour by someone who is reading their first programming language book. Less for most programmers. And for VB programmers, maybe 5 minutes with a slick UI to boot.

Re:Um...

[Gabey]

Yes, that's why he said JavaScript....

Reading comprehension...it's a good thing.

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

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

[SteamedPenguin]

Since I wrote the app for my own edification I don't see how the FDA gets involved. At best I have no control over who uses the application.

Most importantly though: a Cardiac Index can be calculated by hand or by using a pocket calculator. Does the FDA regulate pocket calculator outputs in hospitals?

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

[hymie3]

this is not the kind of thing you can knock up in your back room
Not to be pedantic, but I believe that the phrase used to describe hurriedly putting something together is "knock out".

Although, I'm certain that there is quite a bit of knocking-up done in back room medical settings...

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

[dheltzel]

Bzzzzt! Wrong!

I work for a pharma company and I do know CFR 21 Part 11, and you are wrong.
Developers can write anything they want, it's the implementation that must be validated. If a company says their software is CFR 21 Part 11 certified, they are lying. If you write software for a regulated industry, you won't be sued or shut down no matter how crappy it is. The company that implemented and used your software won't be so lucky, but it's up to them to perform the needed due diligence, not the SW dev.

Now, if you want your software to be used and appreciated, you should pay attention to the regs, which are quite voluminous and complicated (imagine that from our government). But common sense will get you very far in this if you consider that the regs are intended to make the companies accountable. Digital signatures, auditable logs, robust validation checks are all very good (the technical term is "non-repudiation"). If your software can be implemented in a way that makes it impossible for a single user to alter data "after the fact" without leaving an accountability trail, then it will be better than most of the commercial SW being sold into this market. The key phrase here is "can be implemented". The best software, poorly implemented, won't comply; so be sure the implementation and validation docs are good also.

In fact, document the thing to death and things will go well for you. It almost seems like quality is measured by the volume of documentation, the more the better.

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

[robtheauditor]

21CFR11 is relevant to systems used for documenting drug development, but really does represent good practices fo any software. However, there is actually no such specific standard for general health care. Hipaa Privacy, and soon, hipaa security, cop out to vaguely defined, non specific quasi standards that give way too much wiggle room. They took the teeth even out of electronic signatures in the final version. Writ your software, sell it for millions, don't worry: the eula promises nothing to the customer, anyway. FOSS at least delivers moer than its cost!

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.

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

[RMH101]

nope. i work for a pharma company too, and i design, implement and support networks used for clinical data capture, trial submission data and dosage control. we use 3rd party software and they *do* have a due diligence they have to do. you can't consider your whole implementation validated without doing your own exhaustive tests, but the vendor *does* need to be audited and shown to be compliant, using version control and formal system tests. this is just The Way It Is.

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

[SteamedPenguin]

Why would I want to sell it? It is an algorithm not written by me. My only effort was a simple implementation in PHP and XHTML.

You say the FDA would regulate pocket calculator output. Ok fair enough, I'll bite. Calculators are used on a daily basis for clinical data submission. Tabulating I&Os, figuring out dosages, etc.

What about PDAs? Are they to be regulated as well?

What about the choice of software you use in your computer systems? Some hospitals use Windows in a clinical setting. As an insecure Operating System that readily allows the installation of spyware, adware, and other malware, how can one be sure of any input on such a system?

Sure, the application might have all these supposed checks, but if the underlying system has holes you can drives truck convoyes through then how much good does that do you?

Working in hospitals, in a clinical setting, is what I do for a living. I don't doubt your experience, or your words, but I don't see how the FDA fits into a simple implementation of a calculation that some doctor called Fick came up with. Anybody with mathematical skills of a fifth-grader can double check the mathematics of Cardiac Index Calculator.

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

[RMH101]

i'm not getting at you personally, but from professional experience, you have to be 100 percent nailed on it.
sure, we use windows, but we validate it right down to the little rubber feet on the bottom of the PC. exact patch levels, precise build instructions with no permitted deviations...

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

[dheltzel]

Yes, but *you* audit them, not the FDA, and then the FDA audit you. This is a big distinction and removes (fortunately) the liability from the developer and places it on the implementor. This is fortunate because on the implementing company can asses the fitness ofthe software within their environment.

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

[RMH101]

...agreed (we're getting a bit geeky, here, aren't we ) - we audit the software company to make sure they're supplying the audited software in a way which is in itself compliant (in the UK, ISO 9001 for starters, can demonstrate ER/ES compliance, auditing, document control, etc) then you can use their system without having to completely reverse engineer it to show repeatability.
if the developer *couldn't* show this level of assured quality - say they don't use any version control or make any alterations to their code via formal, wet-ink change control procedure - then we couldn't afford to risk using them, unless we took on the responsibility of doing all of this for them - which isn't all that easy unless you're prepared to reverse engineer the whole lot, or work from the source code up.
in much the same way (although i'm personally a bit dubious about this), you can use an OS like Windows 2000 on the grounds that it's a standard, it's proved by use in millions of places world wide, and provided you lock it down and don't patch it without retesting, you can consider it acceptable for clinical use.
Our systems even specify exact driver versions, BIOS firmware, hardware revisions etc. to ensure full compliance.

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

[dheltzel]

Our systems even specify exact driver versions, BIOS firmware, hardware revisions etc. to ensure full compliance.

Yup, and we often reject critical security patches as too much trouble to apply and re-validate.A convoluted change management process means less work for me also, because the paperwork is so daunting, most users give up and work around the existing bug or mis-configuration. Seems kind of silly and conter-productive, but I would rather do silly for a salary, than elegant for the unemployed.

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

[RMH101]

you know, i thought i was the only person on here who had to deal with all this kind of stuff.
currently wading through a stack of paper around 3 feet high to prepare our preprod boxes for user acceptance testing, and it's *hell*. still, as you say, it pays the mortgage.

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

[dheltzel]

Yeah, this week I've gotta write an IQ for a new Solaris box. The system it will run is not to be validated, but every bit of HW going into our server room must be IQ'd. Why? I think my boss just feels more comfortable when surrounded by stacks of white binders full of 3 hole punched printouts no one will ever read.

I must continually fight the temptation to include stuff like a page that says "This page intentionally left blank to see if anyone ever reads this stuff" or "Help, I'm trapped in this printer by an evil Vorgon who is making me change toner for food!!!"

Medical Manager

[i.r.id10t]

A few of my former coworkers and fellow students now work for this little company called Medical Manager. Last I spoke with one of the people doing programming, they do like to use various OSS tools and languages, like Python.

As far as F/OSS software itself, dunno. Like others have posted, there is TONS of testing to do when someones life or lab results are on the line.

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:Because I like PHP was: Um...

[brulz]

I think this calculator would work best by using a java applet. Or even a small flash program using actionscript. The problem with these solutions is that they need client plugins, but the computers should hane these plugins easy.

Re:Because I like PHP was: Um...

[SteamedPenguin]

I absolutely refuse to use Flash. It could be the best thing since sliced bread, but I don't give a rats ass.

Java is only marginally better, neither Java nor Flash are Open Source and as such I don't care to learn them unless I specifically get paid for it.

More importantly though, I don't know if hospital terminals have Java support or Flash support. In any case, I do not consider it acceptable that terminals that are supposed to be secure have secondary software installed just for a small application like a Cardiac Index calculator.

Let me ask though, why do you think doing this in Java or Flash is a better solution than a server-side solution?

More importantly, you have the algorithm right there on the Web site, you can implement the calculator in whatever language you want.

Re:Because I like PHP was: Um...

[runderwo]

neither Java nor Flash are Open Source and as such I don't care to learn them unless I specifically get paid for it.

Sounds like you need to check out OpenSWF, Kaffe, SableVM, GNU Classpath, GCJ, etc etc.

Re:Because I like PHP was: Um...

[SteamedPenguin]

well, since you know so much about both Java and Flash, I suggest you run along and implement. :)

Linux-Medicine-HOWTO Lists Almost All Apps

[wehe]

You may find an almost complete list of Open Source and of commercial Linux applications for different medical purposes in the Linux-Medicine-HOWTO.

Be careful!!

[HeyLaughingBoy]

Be careful trying to use what you design in the USA. Some software is classified as a medical device in the US and needs FDA approval before it can be used. Outside USA, other countries have their own approval procedures.

Replacing LyTEC

[hackus]

I am in the middle actually, of replacing a application called LyTEC, rebuilding it using a Java Tomcat MySQL.

-Hack