The Problem with Software

Phillip Longman has an article on health care information systems with the provocative title, “Code Red: How software companies could screw up Obama’s health care reform” (hat tip Ezra Klein). The argument of the article goes something like this. One, the health care cost problem is largely caused by overtreatment. Two, the answer is software: “Almost all experts agree that in order to begin to deal with these problems, the health care industry must step into the twenty-first century and become computerized.” Three, software implementation projects can go horribly, horribly wrong. Four, the solution is open-source software.

I have no argument with point one. And I agree wholeheartedly with point three. Anecdotally (but I have seen a lot of anecdotes), the median large-scale corporate software project goes way over budget, is delivered years late, is just barely functional enough to allow the executives involved to claim they delivered something, and is hated by everyone involved. But I’m not sold on points two and four.

On point two, I’d like to see some evidence, or at least an argument, that computerization actually leads to less overtreatment. I can buy that it reduces errors, and that it reduces the costs of delivering health care a tiny bit. But to help with the health care cost problem, software would have to somehow cause physicians to prescribe less of the sorts of tests and procedures that drive up costs in this country. And there I think that incentives (the more procedures you do, the more money you make) win out over technology any day.

On point four, Longman gives a standard argument for why open source software is good and “proprietary” software is bad. He contrasts Midland Memorial Hospital, which installed an open-source system developed at the VA and had great results (although there is no mention that overtreatment was actually reduced), with Children’s Hospital of Pittsburgh, which installed a proprietary system and had catastrophic results. But then he jumps ahead to his conclusion: “While many factors were no doubt at work, among the most crucial was a difference in the software installed by the two institutions,” and he focuses on the fact that one was open-source and the other was not.

I am a huge believer that some software is great and some software sucks. However, Longman believes two things I do not believe. First, while good software is an important ingredient of a successful project, it is only one ingredient among many. I would put an experienced team, effective decision-makers, a flexible, realistic implementation approach, and a culture of quality up there along with good software. Most software projects fall victim not to bad software, but to the coordination problem – of having dozens of people working together on a single, intangible, unstable product – compounded by the motivation problem.

Second, I don’t believe that whether software is open-source or proprietary has much of an impact on whether it is great or it sucks.  Open-source software is not necessarily easier to implement; for an analogy, compare getting a printer driver to work on Linux vs. Windows. 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). Nor is it necessarily cheaper, since software license costs are typically a very small fraction of total software project costs; by far the largest component is usually the manpower necessary to configure, integrate, and test the software. Some open source software is great, although most of it is at the platform layer (operating system, database management system, application server, web server, development tools) rather than the application layer; some no doubt sucks.

For the record, all things being equal, I always go for open-source software, and the two computers I own (but not my company computer) run Linux. But it is far from being the future of computing, as Longman claims:

Once the province of geeky software aficionados, open-source software is quickly becoming mainstream. Windows has an increasingly popular open-source competitor in the Linux operating system. A free program called Apache now dominates the market for Internet servers. The trend is so powerful that IBM has abandoned its proprietary software business model entirely, and now gives its programs away for free while offering support, maintenance, and customization of open-source programs, increasingly including many with health care applications. Apple now shares enough of its code that we see an explosion of homemade “applets” for the iPhone—each of which makes the iPhone more useful to more people, increasing Apple’s base of potential customers.

IBM abandoned proprietary software because their proprietary software wasn’t very good. The main business software companies, the ones who actually make big piles of money – SAP, Oracle, and Microsoft – are not planning to open-source their software anytime soon. And Apple has historically been the exact opposite of open-source. They are simply doing what Microsoft has always done – exposing enough of an interface layer so that third-party developers can write applications that run on Apple operating systems.

All that said, Longman may be right that in the health care delivery sector, the VA system, which happens to be open source, is better than any of the proprietary systems out there. In particular, once any system – open-source or proprietary – establishes a leading position in the market, it benefits from network-like effects that help it increase its lead on the competition. Simply because the VA system has been implemented hundreds of times, it should be cheaper and lower-risk than the alternatives. And the open-source development approach can lead to higher quality.

Longman is also right that proprietary technology vendors will typically have more marketing money and lobbying muscle to get their way, since open-source projects generally don’t have major financial interests behind them. This could lead to an outcome where the industry ends up using software that sucks instead of great software.

But I’m not sure the answer is to simply defer investment in software, as Longman proposes. The basic problem – that a lot of software sucks, that most buyers have difficulty finding software that doesn’t suck, and that most projects fail – is not going to go away. Maybe some of the money should be used to invest in new software startups to serve health care providers, although that’s hardly a guarantee of good software. Or maybe, if the VA system is so good, some of the money should be used to give it some marketing muscle, something like what the Mozilla Foundation is for Firefox. After all, on a level playing field, the best solution should win out.

Ultimately, though, I think it’s best not to pin too many hopes on software. As I said earlier, it’s not going to change physician incentives on its own. And getting a software project right is very, very hard, even with the best software. There’s no magic bullet here.

Update: One of our readers, who happens to be a VA physician, wrote in to say that one of the reasons he works there is “an impeccable IT system, the likes of which have not yet seen a rival.” So perhaps the VA system really is better than anything else in the industry. If so, the government should be pushing providers to implement it. If the problem is that the VA system doesn’t have the marketing clout to compete with the private software vendors, then that’s the problem that should be fixed. I know a few former software people who might be willing to help, if it really is that good.

By James Kwak

48 thoughts on “The Problem with Software

  1. Absolutely true, but also a complete red herring. Health care providers do not want the data online because it would make it much easier for the government to take over. Much easier for them to say there are technical limitations which preclude effective implementations.

  2. The biggest advantage of open source software is that it avoids vendor lock-in.

    The “Microsoft tax” may be small for any single person or corporation, but across the whole economy, it is enormous. And merely having the ability to modify the code — or to pay someone else to do it for you — has significant advantages. No matter what your problem is with an open-source product, there will always be a competitive market full of people you can hire to solve it for you.

    90% of all software cost is maintenance.

  3. I too do not believe software is a magic bullet. Software is *hard* to get right and meet a customer’s requirements. Most software projects founder on getting the last 5% of the requirements right. A better approach is to build systems which are modular and flexible and can change when a customer’s requirements change and does not necessarily meet all the requirements on day one of the rollout.

  4. Welp, I have a dog in this fight, since I slave away in the java salt mines for a living, but here’s my take:

    The unique characteristic of most enterprise software is that it involves lots and lots and lots and lots of annoying, irreducible conditional branches in it, often due to annoying “laws” made by “human” “beings”. To do this kind of software well requires the sort of soul-crushing-this-isn’t-hard-but-man-is-it-tedious non-technical work that absolutely saps any enthusiasm that can lead to good free software. This is why there are no good open source insurance systems, but there are a bajillion half-implemented open source CRM systems and that there are a quadrillion open source web development frameworks.

    I think that if people expect decent software for our friends in the medical community, they should expect to have to pay for it. Open source zeal alone will not keep the programmer at the terminal in the 11th hour of testing the MediCal/MedicAid billing integration module.

    To be honest, the problem is so big I question whether decent software can be built to deal with it, even by a private company with a solid team. There are so many moving parts and interested parties that it’s pretty much guaranteed to be a disaster. Better to focus on a single under-served niche within the system, get a good team together and kill that, than to attempt to solve the whole problem at once.

    Sound familiar James?


  5. I think an overtreatment argument is this:

    Many people see a handful of healthcare providers who do not communicate with one another. Therefore,

    Computerization of a person’s records (and, importantly, creation of a unique record for an individual) would allow provider A to see what treatments have already been ordered by providers B, C, and D.

    There may be others, but this, for me, is the most compelling reason to digitize patient records.

    That, and Steve’s point about making it easier for a new provider (e.g. the Man) to step in and drive costs down…

  6. Thanks for that clarification – it is the integration of patient records into a common database – vs. disparate systems – that would make it much easier for government intervention – although they will dress it up to sound nicer. And that is why the providers will resist, and provide red herrings, as to why it can’t be done. None of that is to say that this integration actually makes any economic or medical sense.

  7. Any discussion of computerized medical record systems has to take into account the massive achievement of Kaiser Permanente. I am not sure whether this program is national, but within the Northern and Southern California groups all information is available anywhere in the system. My personal experience is that this leads to greater continuity in treatment – – that is, a doctor can easily reacquaint herself or himself with what has been said, diagnosed and prescribed previously, and can do it very quickly. I don’t think that it is particularly relevant that this is running on a Microsoft platform (Windows 2000, by the way, at least at the workstation level;) instead the thing to focus on is that this is the result of years of work, and even though it had shaky moments, the dividends have started to roll in. So I think success in the medical/software area has more to do with persistence and a single-minded focus within the organization that undertakes this enormous task.

  8. Nemo has it right. The “easier to modify” argument is about having a competitive market of people who can modify it for you. It’s not about you having to do the modifications yourself (although you could, if you were so inclined and had the right skills).

    But really, who is this “you” that we’re talking about? Hospitals can (and almost certainly will have to) hire programmers to customize a system to their specific needs. Using an open-source system means that there’s a low-transaction-cost way for all those programmers in all those hospitals to cooperate with each other.

  9. As to point two, the problem that I ran into time and again in trying to “computerize” certain business processes at the public company I used to work at is that almost everybody expected that the software solutions selected would obviate the need for independent judgment, that the software would work “out of the box” to make decisions for them that they could not manage to make with existing, unautomated business processes. As a result, the projects took too long to complete, if they ever were completed, and came in way over budget even if they were not.

    As to point four, when it comes to medical treatment decisions that could involve life and death, don’t expect the open source community to take on that kind of liability. Open source can provide a wonderful platform that squeezes out some of the recognizable costs of development, the enterprise has to put even more effort into developing a system tailored to their needs, which yields higher opportunity costs: those doctors could be helping patients instead of VARs and their development partners understand their specific needs.

    Open source is different, not necessarily better. Proprietary software can be better if the developer has invested in making the “out of the box” solution much closer to the client’s needs. Reasonable examples of this phenomenon are Lexis and Westlaw, who employed a lot of former lawyers to design the databases and the interface. Where is the “open source” alternative to Lexis and Westlaw? And don’t say Google. :-)

  10. Part of the argument for a reduction in overtreatment comes form the data-mining possible from computerized records. Right now any research on whether a particular treatment has lasting benefits requires a lot of manual trawling through files and phoning patients. If instead I can query for treatment X in a database, query for treatment Y for people with the same condition, and then compare the follow-on costs for each, I can decide which is more effective in a matter of days or even hours.

  11. Open source and open standards are not necessarily the same thing. It seems a major issue with electronic systems in the medical area is cross application integration. Imagine the world prior to standard network protocols; HTML versus add-ons, etc. I follow many of these arguments and rarely see any pointers to health standards, for example, Health Information Technology and Health Data Standards at NLM

  12. “On point two, I’d like to see some evidence, or at least an argument, that computerization actually leads to less overtreatment.”
    Well, it could certainly make it easier to pinpoint areas (geographic or medical) where things appear to be trending most heavily towards overtreatment, which one would think should make solving the overtreatment easier. I could also see it being a valuable tool for physicians to compare treatments for similar symptoms, although whether any accrued knowledge is actually used to reduce overtreatment would rest heavily with the individual physician.

    “On point four {MS, Apple, etc} ”
    I think this analogy is a little strained since you’re talking about guys that write the operating systems, where the proprietary stakes are higher. Whatever they implement (if anything) will most likely be running on Windows. While I can see issues with a pure open source solution, I think at the very least its something where the source could and should probably be made public if we’re talking about some kind of ubiquitous hospital software. (something even MSFT has been pretty open to this with everything down to their framework code)

    I’d also just like to say I really love your blog. I only follow economics out of a sense of necessity and you really make the reading informative and enjoyable.

  13. As someone with ties to the medical industry and who has spent their whole career in the software salt mines, I’m very much in this story.

    I agree with point one, that the health care cost problem is one of overtreatement, but there is no reason to believe that point two, computerizing the health care industry, will decrease costs. (Sure worked well for finance. Let’s copy that model!)

    I would argue the opposite. Computerization is like paving the cow path. It makes it easier and quicker for cows to move around. And if they move quicker, won’t they get more treatment?

    Someone’s sick or in medical facilities for a certain period of time. If medical records and information flow freely and quickly, the person can be treated by fifty people as opposed to five. Computerization will increase treatment, not decrease it.

    Point three I totally agree with, though to be honest, I have made a lot of money from this problem. Someone has to pay those people to keep working on those systems. And many of those people are paid handsomely by the hour.

    Open source is great for the implementors, but not for anyone else. Why do companies buy applications from MSFT, Oracle, SAP and others? Because if something doesn’t work, you can go to the company, yell loud enough, and they’ll find someone to solve your problem. Who do you yell at with open source?

    With open source, you’re dependent upon the implementors. They not only know what you’re trying to do, they know and have tweaked the “open source” in ways only they know about. Their code commenting and documentation is most useful for themselves.

    Open source should be called what it truly is, a tar-baby.

  14. So if the VA system is so great, which it is, why don’t we just adopt the entire VA system and apply it to the United States?

    That way, the entire US would have single payer, instead of just Veterans.

    Of course, that does have the downside the the insurance companies go away, along with their campaign contributions. There’s that.

    * Actually, it doesn’t amaze me. At this point, I expect it.

  15. That assumes that the data mining is for medical CARE and not insurance company BILLING codes.

    A very, very dangerous assumption that may be lethal. GIGO.

  16. I enjoy your blog — keep up the good work.

    On this blog entry I have a few comments:
    1. As a citizen stakeholder I want the government to pick the best overall solution. This may be open source or proprietary or some mix of both. More important than the system itself is the need to insure that MY health data remains MY property.

    2. The quote from Longman has at least one thing backwards. Companies didn’t just recognize an opensource trend and respond to it — they helped drive the trend. A large amount of open source software (even most??) is developed in corporations by employees drawing a paycheck from that corporation. This is done for many reasons, but, often because its a good way to shake up a market with an entrenched and dominant player.

    3. I leave it to you and their customers to assess the quality of the various products offered by the companies you mention in your post. But, as a matter of fact, IBM is very much in the software business. As a shareholder, it’s important to me that almost half of their profit comes from various software products… as an investor, I’m very interested in the mix between high margin software revenue and lower margin services revenue.

  17. Before debating the software issue, would it be appropriate to investigate whether the “race to the bottom” has also affected software?

    If the phenomenon reduces the value of expensive shoes…….

  18. This an excellent article – thank you. My only skin in this game is as a 60 year old patient that will continue to increase my need for medical services as I age. Unfettered capitalism is not the answer to all democratic challenges, common sense work’s ok too. As the financial meltdown showed us, we need a smart Government that is in control of the standard’s of society. This applies to our nations health care. I have a twin brother, both of us are veterans but he was hit in Vietnam and is disabled. I use the private market. Hands down, he get’s better fundamental health care than I do. He has to put up with the VA system which is slow at times particularly for non-emergency surgery but as far as emergencies and continuing care the VA is far more sophisticated and caring. We no longer have the luxury of waiting for a private capital market to sort out the winners from the loosers in the IT health care game. We already paid for the VA IT system why pay for it again? I’m tired of all the noise, let the US Government be in control of the IT standard’s and allow the open source innovation to make it better. I can live with that and I believe most Americans can as well. Give us some credit – if it looks like the government is getting in the way we will let everyone know.

  19. The problem with software is dysfunctional organizations. Sometimes the developer organization is dysfunctional, but more often the customer organization is the problem. They don’t really know what they want, their organizational politics won’t allow a solution, there are key people with interests in seeing the project fail, they have no buy-in from their user community or from management, etc.

    The nice things about large, outside packages are that they force people to accept an external product which other organizations have adopted, management can claim (often correctly) that this is a world-class product and anyone who can’t work with it is incompetent, and they usually (the better when they do) require organizations to adopt the model of the software rather than rewrite the software to fit a dysfunctional model.

    It doesn’t really matter if the software is proprietary or open-source; whether the software will succeed or fail is so often a function of the organization it’s being installed in.

    KEW and Carson have it right; the people, AKA the government, should force all parties to agree first to open standards and open processes. Then the developers don’t have to waste their lives filling in arcane business rules for every medical facility in the country. Then we have a competition (AKA the marketplace) between all comers to write the best software solution that meets the standards.

    Does that solve the cost problem? No, the software doesn’t, but the open standards and open processes actually help a lot. Once there’s a standard way to record and track diagnoses and prescriptions, we can start to easily see the quacks and shills and boot them. Then we can see how the Kaiser Permanente’s of the world keep costs down with better outcomes and make it harder for groups that don’t follow suit. That’s 30-40% of the solution. For the rest of the problem, we need to defang the AMA.

  20. I’m a Java programmer working in Pharmacy. In my experience a law will never get the industry to adopt technology, the only way you will get things going in the technological direction is direct financial incentives.

    For example, all PBM’s (Prescription Benefit Managers) are required to submit their explanation of benefits, sort of an itemized list of what medications they are paying for and at what rate, via the ANSI 835 electronic format. This is mandated by HIPPA. Well of all our providers (hundreds) about 8 actually comply. Why? because there is no financial reason for them to provide electronic 835’s when paper will work just fine.

  21. One last note regarding open standards and processes. When transmitting a prescription electronically to an insurance carrier from a pharmacy for adjudication there’s an ANSI format called NCPDP 5.1.

    Well, not all carriers follow the spec. When we call them to say “you have to change your system, our pharmacies cannot transmit to you because you’re not following the spec” they say “well, this is what we do, if you don’t like it don’t transmit to us”. A pharmacist can’t exactly tell a sick patient that their insurance company refuses to modify their software to comply so we’re forced to modify ours. We have dozens of little tweaks here and there to correct for bad implementations out in the insurance carriers.

  22. Actually debating open source vs. closed source is in this case, missing the point. It’s *really* about open standards, which vendors would be forced to implement — and correctly if people demand it (apropos chad’s comments).

    This helps to level the playing field — if I can be confident that I can change system vendors with less pain (relatively, big migrations are often painful), then I can force vendors to compete for my business. In fact, I would hope that the government passed legislation that anyone wanting to get paid by medicare/medicaid would have to implement those standards.

    Open standards are the best way to force competition into vertical markets.

  23. Actually, open source is when you’re *not* dependent upon the implementers. It is the equivalent of the scientific peer-review model for software. Ever called Microsoft’s help line? Were they helpful?

  24. The cost reductions gained by the introduction of competition via a public option alone will reduce costs dramatically as it will simply come out of profits —

    Software and supply/service chain efficiencies will follow as firms will need to work harder to extract profits from reduced margins.

    In the end, care will have to be rationalized, can’t strive for a utilitarian ideal without willingness to accept this cost.

  25. It is hard to argue in principle against high tech answers to our social probelms – especially those associated with information technology. In practice, there are good grounds for skepticism. The claims of software specialists as discussed here and of high tech afficionados like Obama put a fine point on the issue.

    1. Do we have examples of drastic savings of the sort foreseen in the medical sphere in any other sphere from a mere improvement (promised) in information retrieval and transfer? I don’t know of any outside of industrial engineering.

    2. Is it correct that those countries with far more Efficient health care delivery systems than ours (just about ever other country in the world)perform better due to superior communications software? I know of no such evidence. It certainly is not the case in the two countries of which I have direct knowledge – France and Tunisia.

    Most of this is classic avoidance behavior. Any reasonably objective analyst knows what are the prime problems with the American non-system. We also know that supposed panaceas like medical software can make only a marginal difference (which, as with all such technical innovations, carries drawbacks we usually won’t anticipate).

    Michael Brenner

  26. My internists over several decades have done this as a matter of routine. They pick up the phone, talk to the specialist (who usually was their referal in the first place), have any records sent over (electronically, carrier pigeon or whatever) and then assesses them. The problem today is attitude and the quality of general practitioners. The inept ones simply will use the new IT to discover another test/procedure they don’t understand to try on the patient. Really, if we observe the world around us, this is obvious.

    Michael Brenner

  27. Mitch (Above) and Pat C make very good points about the real advantages of open source software in the context of a large industry like our health care system, which go directly to the point James makes about implementation being a larger piece of the cost of ownership than software licenses.

    We’re always going to need talented IT staff at our major medical institutions. They are going to be the ones ultimately responsible for making the software fit the hospital and its needs. What open source software does is give them a) the opportunity to actually see how the software works and chase bugs or features as far into the program as they need to go, and b) allow them to join together as a community across hospital and state lines to share knowledge and code, reinvesting the money and effort we’re already paying into the code for everyone’s benefit.

    When you expand that effort to all the hospitals treating non-veterans, you quickly have the resources to build some impressive software infrastructure.

  28. “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)”

    But, I think that particular statement glosses over the fact that when modifying the behavior of closed source software you have all of those obstacles PLUS:
    1. a complete lack of documentation aimed at you and developers like you
    2. the absence of a helpful developer community
    3. no access to the implementation’s details and design

    Modifying open source software may be hard, but modifying closed source software is even harder.

    I don’t understand why you would make a comment like that.

  29. This might be a situation where giving docs more time with each patient is what leads to the biggest plus, not the further mechanization and de-personalization of medicine.

  30. If everything was computerized then data mining and auditing could be performed on the data which in theory would lead to reductions in overtreatment, new forms of treatment, etc.

    Regarding Open Source. To put it in more general terms, do you want a large corporate entity focused solely on profits involved in your healthcare or do you want a Not For Profit that is focused more on your healthcare? If you are fine with the former than proprietary software is fine. If you prefer the latter than Open Source is obviously a much better fit.

    There are other advantages too, such as making the healthcare software more affordable for smaller entities and the code can always be forked if a split occurs within the community (XFree86 vs. is a perfect example of this) or if a buyout results in closed source new releases.

  31. Excellent point about the dysfunctions of organizations and how internal business politics is reflected in models and outcomes.

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

  32. Open source is ideal for healthcare admin because, as you point out, providers are not incented to invest in IT. However, it is in society’s best interest that they do, so it will only be done at govt behest. If govt is spending the money, as in this case, then the value should not accrue mainly to (possibly well connected) software providers. The end product of this spending should be made available to all, which means open source.

  33. garbage in garbage out.

    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.

  34. While I tend to agree that vendor-owned proprietary code is not the way to go here, I want to highlight an earlier comment:

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

  35. Yay! A boondoggle for Google! Meanwhile, the Democrats converge on a health care reform system that mandates people buy junk health insurance, and subsidizes it. Priorities!

  36. I agree with everything you said, and I am not a nerd, but I have a brother who write base level code, and he agrees and has explained his rationale to me in a comprendable way.

    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.

  37. I literally cringe whenever non-experts talk about EMRs. Electronic Medical Records is one of the most complex software to design and implement CORRECTLY.

    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.

  38. A brief correction:

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


  39. “Open-source software is not necessarily easier to implement; for an analogy, compare getting a printer driver to work on Linux vs. Windows.”

    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.

  40. Just a quick FYI. I work in Information Technology at the Department of Veterans Affairs in a Medical Center. I spent 10 years of my IT career as a developer of the VA’s hospital information system (called VISTA now, but DHCP in the old days). It may be called open source, but it is really the highest quality product in it market place with a 100% electronic patient medical record that includes images, lab tests, doctors notes, orders… It is not your typical open source product and is used all over the world. There is even an organization (World VistA) dedicated to helping NGO’s adopt and use it.

    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.

  41. I don’t think open-source software is necessary but open-architecture, unencumbered, non-proprietary data formats and protocols are essential. For example, the Web’s broad adoption can arguably be attributed to its free and open data format (HTML) and protocol (HTTP).

    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.

  42. Even OSS requires competence in healthcare informatics to implement, maintain and evolve. I do agree, however, that the mix of commercial software and the shrinkwrapped COTS MIS software personnel that inhabit most hospital IS departments are a perfect recipe for disaster.


  43. I did not read the original article and only skimmed the comments to this post, so if I am repeating what has already been said, I apologize.

    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.

Comments are closed.