Healthcare.gov Didn’t Have to Be a Disaster

Assigning blame for Healthcare.gov’s disastrous rollout has been about as entertaining as thrashing about in a room full of piñatas without a blindfold. So plentiful are the targets that some wonder whether failure was inevitable and, more generally, whether democracy is incompatible with technocracy. In both cases, the answer is no. The problems with Healthcare.gov were easily avoidable. And there is no reason that Americans should resign themselves to such failures, now or in the future.

There are dozens of examples in which the government has successfully imagined and deployed astonishing new technologies. The creation of GPS, the “stealth utility,” as Brad Parkinson, the U.S. Air Force colonel who spearheaded its creation, likes to call it, is the example everyone points to today. The core idea behind GPS -- attaching atomic clocks to low-power radio beacons, launching a constellation of those beacons into orbit, and receiving their signals anywhere on the planet -- was far-fetched and expensive. Only the government had the resources, the military need, and the patience to even attempt such a feat. Once it did, though, the public reaped the rewards as well. 

That is not to say that the government should attempt all innovative projects on its own. In fact, government involvement tends to work best when the public sector provides the will and the private sector provides the ingenuity and technical prowess. In the medical field, many projects are simply too expensive for any single company to fund without government support. Yet once government support is granted, the research can result in breakthrough technologies that bring vast profits for private firms -- and benefits for the public, besides. Another example is the Internet. Together, the private and public sectors collaboratively scoped, executed, and deployed a system that neither could have possibly created on its own. 

And that is where Healthcare.gov failed: the Web site was an engineering problem that was attached to a political program, Obamacare. Rather than solving it like engineers, though, officials tried to solve it like politicians. They hid the strategy (and the software) in the naïve belief that they were capable of delivering a complex system in a technical vacuum. This approach is toxic when it comes to large-scale implementation, where one wants more transparency. The political decision that wreaked the most harm was to insist that a massive social program could be rolled out across the country on a single day without experienced management, detailed reporting, comprehensive testing, and a workable plan for integrating the whole system.

Engineering problems require managers who know how to buy things, how to build things, how to test things, what to do when something breaks, whom to hire and fire -- and when and in what order. In both the public and private sector, the best-run projects have clear goals, sufficient resources, and someone in charge who is unceremoniously replaced if the project goes off the rails. None of that is secret, which makes Healthcare.gov’s failures all the more perplexing.

The good news is that the Web site’s technical problems can be fixed, precisely because they are only that: technical problems. The systemic problem -- the government’s relationship to technology -- can be overcome as well. That must start at the top with a simple change of policy for picking the vendors that undertake projects like Healthcare.gov.

Traditionally, the government follows a “choose once, choose wisely” procurement approach. It assumes that it knows everything about the final product it desires, has perfect insight into all competing vendors, and can choose “the one” based on quoted speed, cost, and performance. The “choose once” approach works fine when the vendor is supplying is pencils, penicillin, or spreadsheet jockeys who support ongoing programs -- goods and services the government has purchased thousands of times before. It utterly fails when the service is something unprecedented, say Healthcare.gov, for which the final specifications were, by the very nature of the program, only vaguely understood at the outset. 

The government’s current procurement strategy puts too much power into the hands of the vendors, in a way that can’t be easily reversed and without the necessary checks and balances that measure progress along the way. Government staff won’t know whether a contractor’s work is satisfactory until the end of a project and after a lot of trial and error.

The government can and should allow for more competition. For new information technology systems, it can insist on an open architectures that lets the public examine a project’s major components and how they are connected, open standards that enable the development of modular plug ins, and broad voluntary participation. Far from being a security risk, open-source systems are measurably more secure than proprietary ones.

To understand the benefits of openness, compare two responses to another major technology fiasco: the rollout of new software designed to modernize and connect electronic health records between the department of Veterans Affairs and the Department of Defense. When the initiative -- which by now has cost more than Healthcare.gov -- launched in 2009, it was riddled with problems.

To address some of them, the VA broke new ground in 2011 by establishing the so-called open source custodian, which makes the computer software that the department uses to run its hospitals available for free to the public. Anyone can download, evaluate, install, and use it. More important, anyone can extend and fix it, and therefore contribute back to VA. Developers have already identified a security hole, corrected it, and delivered working code to the government for free.

By contrast, the Department of Defense has doggedly declined to use openly developed, standards-based, and modular systems, even though it committed to that approach in 2011. That has set back its side of the project by at least three years and added billions of dollars to the project’s price tag. (The VA’s approach has cost just three percent of the amount the Department of Defense has already spent on its new health record system -- the one it has not even started to build.) To the extent that the Department of Defense ultimately chooses a closed, customized, and proprietary alternative, it will lead to an inferior result.

The solution to the United States’ technical problems is not less democracy -- for example, the hiring of information technology contractors who work in secrecy. It is more democracy. Open-source procurement leads to wider choice, lower price, and better performance. It won’t work very well for some things. After all, it is best to keep the goals, mission, and designs of aircraft carriers secret. But it would work for pretty much every kind of network-centric technology program, because complex modern software is a living ecosystem that dynamically adapts to users and their evolving requirements.

Opening government technology to public examination also invites broader participation and use. Again, the example of Parkinson’s GPS is instructive. In response to the destruction of a civilian airliner that accidentally flew into Soviet territory, President Ronald Reagan took the historic step in 1983 of making GPS, which was then run by the Air Force, available for nonmilitary use. President Bill Clinton subsequently granted the Federal Aviation Administration authority to augment the system for safety-critical air navigation. The commercial benefit has been astounding. And the social benefits have been incalculable.

The technical component of the Obama’s administration’s signature achievement was grossly mismanaged. Period. As the Washington Post reported on November 3, there is a big difference between the skills required to pass legislation and the skills needed to implement it -- especially when implementation is technical. The same goes for fixing technical problems when they arise: the government has to let people with the knowledge to understand the problems see what’s going on. It’s doing that now, but it took a crisis to get to this point.

To its own detriment, the U.S. public allows its leaders to keep the implementation of public policy secret. Some of its more ideological members take the position (against all evidence and data) that Healthcare.gov’s problems aren’t just the results of disastrous implementation, which they are, but that the problems are endemic to the U.S. political system, which they aren’t. In the real world, people get paid for performance, and have their work checked constantly. Those in charge of building large systems like Healthcare.gov should live in the real world of accountability, transparency, and broad participation. It will work so much better when they do.