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. 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 with a brand new touch-screen operating system that spawned
a slew of competitors and has now fundamentally reshaped the
handheld market (as well as the daily life of millions) in its
image—cost
about $150 million to develop
before its release in 2008.

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

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. 

from Hit & Run http://ift.tt/1oEzdVV
via IFTTT

Leave a Reply

Your email address will not be published.