Health Care Reform and 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.

• Become A Funded Futures Trader