The comparisons made between open-source and proprietary systems in this example are faulty.

A better comparison would have been both the VA and a proprietary system at either hospital.

The VA system was installed at what appears to be a community, general hospital. not extremely complex and very much like most VA hospitals.

The proprietary system was installed at a children’s hospital. These are not much like general, adult-oriented, general hospitals. They have lots of special needs requiring lots of customization.

Was the failure the fault of the proprietary system, or the lack of preparation on the part of the hospital and its consultants? We can’t say from the information provided but pinning all the blame on the vendor or type of system is not reasonable.

See http://www.tinyurl.com/hit-misadventure

Institutional and enterprise software largely still retains an incentive to be less-than-cooperative when it comes to agreeing on a data standard. Not doing so elicits vendor lock-in and the proliferation of their product. The potential life-or-death liability of a misinterpretation of health care data, in particular, would further cement the incentive.

Open-source software could be used as a wedge to drive interoperation into that industry, there’s no doubt, but the most important element I foresee will be everyone being able to understand each other.

It is well documented, runs very efficiently on small computers, saving adopters lots of money and is very flexible (if you’ve seen one VA medical center, you’ve seen one VA medical center), having been set up to be parameterized in many ways to occomodate all the different VA Medical Centers that run it.

And, it will continue to be supported for many years because the VA isn’t going away any time soon.

Oops, bad example. Printing on a modern Linux desktop distribution is so transparent, end users don’t even see a driver being installed. You just plug in the printer, give it a minute or two, and print. Drivers are automagically installed and configured for you in the background. Nothing for you to download, no CD to load.

“Nor is it easier to modify, unless you happen to be highly skilled at developing in the language of the source code (and not even then, since modifying source code is inherently complex and risky).”

Ease of modification is irrelevant. You can modify open source. You can’t modify closed source. Without access to the source code, you aren’t modifying the application, period.

Eric

If you want to know everything that can go wrong, and what it takes to get it right, read this series of posts written by Dr. Scott Silverestein, a real medical informaticist teaching at Drexel U in Philadelphia.

It is an eye opener, in more ways than one.
http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-idiots-part-1.html

The one thing I would say, it that the health service community could benefit from a good base program, and strong legislation which limits doctors in some ways that could be tracked through a system like a national patient database.

Also, on a more global basis, it would make cost tracking so reliable that it would be easy to identify abuses, which could, in fact, result in some pretty substantial savings.

“I think that if people expect decent software for our friends in the medical community, they should expect to have to pay for it.”

See, the thing is, this is true EITHER WAY. Where a lot of projects based on free or “open source” software go south is the expectation that it will be, well, free. Or at least cheap cheap cheap.

If you want good software, put your money where your developers are. The advantage that you *can* get from open source is much like that of “public option” insurance: you don’t have to pay for marketing and sales and all the other overhead of for-profit software vendors. (Well. If you hire consultants, for sure you’re paying for *some* marketeers. But nothing like as much.)

However, this is government we’re talking about. So low expectations are in order. Plus if this all has to be implemented on Windows at the sharp end, there’ll only be so much that can be done to help.

coordination of care requires a telephone and a primary care physician who is paid to coordinate care. software is not a substitute. software will do nothing to stop the fact that you have a bunch of subspecialists ping ponging their patients back and forth so each can do their own over priced procedures….and then send the patient along to their buddy for more overpriced procedures.

the problem requires confronting the financial interests of the procedurally based physicians, the hospitals who make money off high cost procedures, and the equipment makers. no real primary care physician being paid for coordination, no solution. for policy makers, software is the cowards answer to health care costs.

http://www.emrandhipaa.com/emr-and-hipaa/2009/01/24/details-of-obamas-emr-stimulus-package/

Do you suppose that if one got the standards and processes, that the problem could be solved without the software ever being used?