One Lesson of Obamacare: The Government Isn't Good at Developing Software
One all-too-apparent lesson from the launch of Obamacare's health insurance exchanges last year is that the government isn't very good at building software technology.
The federal health exchange portal, HealthCare.gov, was essentially unusable for two months after launch last year, despite repeated outside warnings that the project was in trouble and repeated administration assurances that all was under control. The biggest issues on the consumer side of the system were at least temporarily patched by December, but much of the back end that communicates with and pays insurers remained—and remains today—incomplete. Insurers are using imprecise manual workarounds instead. Last week, the Inspector General for the Department of Health and Human Services reported that there were 2.9 million "inconsistencies"—situations in which the data hub was not able to verify submitted information, mostly regarding citizenship and income—in the applications sent to the federal exchange. The vast majority, about 2.6 million, remained unresolved.
It's not just the federal government. The state exchanges remain a mess. Some were never functional and had to be scrapped. And even those being held up as model systems, like Covered California, have problems. As The Wall Street Journal reports, thousands of people who purchased health coverage through state exchanges "still don't have coverage due to problems in enrollment systems. In states including California, Nevada and Massachusetts, which are running their own online insurance exchanges, some consumers picked a private health plan and paid their premiums only to learn recently that they aren't insured."
The experience overall with the exchanges has not been good. As The L.A. Times reports, even highly educated, tech-savvy young adults had serious difficulties using the site. In a study, researchers found that people between the age of 19 and 30 were often stymied by the system. When asked how it could be better, they said they'd like it to be more like commonly used, privately developed websites and applications—things like Yelp or TurboTax.
Obamacare's exchanges were not inexpensive projects, built on the cheap with skimpy resources. As of February, the federal health agency had budgeted about $834 million for the exchange. By the end of the year, it is expected to have spent $1 billion. That's relatively cheap compared to the price tag for all the state exchanges, which cost some $4.7 billion.
In contrast, the first iPhone—a marvel of usable, accessible design which, in addition to its hardware, included a brand new touch-screen operating system that spawned a slew of competitors and has now fundamentally reshaped Apple's business, the handheld device market, and millions of daily lives in its image—cost about $150 million to develop before its release in 2007.
This is obviously not a perfect comparison: Apple was building a consumer gadget, not a highly regulated, health-focused, government-run shopping portal; Apple wasn't coordinating and connecting multiple government agencies and insurer computer systems, nor was it relying on an army of outside contractors; and Apple was not building a product that, by law, had to launch and had to have certain specifications.
Even still, those difference are not quite so extreme as they might sound: Apple's project required coordinating with mobile carriers, first AT&T and then others, and, in the year after the first generation phone launched, building a unique platform (the app store) for a wide array of mobile software to sell their wares. And while Apple was not bound by law to complete the iPhone and make it a success, it had spent so much on development that it would have destabilized the entire company. It too was bound to complete its product. (And it's worth remembering that former HHS Secretary Kathleen Sebelius explicitly compared Obamacare's exchanges to the iPhone during the early days of the rollout.)
And at the same time, those differences also suggest the inherent advantages of the private sector. It's less restricted by bureaucracy and regulations, more flexible in terms of deadlines and partnership decisions, and able to do its work quickly and effectively in house. It is motivated by competition and by consumer demand. It's also, as a market leading company, able to hire the most productive and innovative workers, and pay them more. (One of the reasons why military R&D is generally more successful is that it takes place in a lab-like environment where project deadlines and specifications, not to mention political pressures, aren't always as restrictive as on a big domestic-policy project like the exchanges.)
These advantages are built in, and while it's certainly possible and desirable to improve tech management and administration in the public sector to some extent, those advantages are never going to go away. It's never going to be a level playing field.
The trick, then, isn't to determine, as we have, that the government isn't very good at software development and put a lot of energy into trying to make it better. It's to recognize the government's limited capabilities and built-in disadvantages, accept them, and work to avoid project and programs that might require the government to play software developer.
