Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

6 software development lessons from Healthcare.gov's failed launch

Matthew Heusser | Nov. 19, 2013
The problems that plagued the launch of Healthcare.gov in the U.S. will someday fill a book. For now, developers can apply these six lessons from Healthcare.gov's very public failure to their own software projects.

We know this smaller scope could have worked because it does work. A tiny company called Opscost took that spreadsheet and implemented a website doing just that in few than two person-weeks. The site is thehealthsherpa.com (shown below).

This comparison of six person-days to hundreds of millions of dollars is obviously unfair. HealthCare.gov had to do more, including end-to-end enrollment. Healthcare.gov customers were supposed to be able to sign up on a government Webform and have the transaction automatically flow into an insurer's system.

Instead of an 80 percent system for a fraction of the cost, the customer insisted on 100 percent by force of law. Lacking the capability to actually develop such a system, the contractors made their best attempts and shipped whatever they had on the end date. The results, while tragic, aren't exactly a surprise.

George Kalogeropoulos, customer support at OpsCost, says the company's biggest surprise while validating the market was that a huge number of customers wanted to window shop. They wanted a quote without giving up personal information such as phone number or Social Security Number.

At go-live, Healthcare.gov worked on the opposite model, forcing personal information before allowing users to see a quote. (This policy has since changed.) That allowed Healthcare.gov to force users to agree to terms of service, and to connect to backend servers at the IRS, Homeland Security and other agencies. Those are great features for the end of the process, but when your users want to window shop, perhaps less so.

6: Threat Modeling Matters
Ben Simo isn't a black-hat hacker. He doesn't spend his time trying to "crack" things. He's a developer/tester who knows how to view source code and use the developer tab to look at back-end Web transmissions, mostly RESTful services. That's exactly what Simo did with Healthcare.gov: Look at how his family's information was transmitted as he tried to sign up.

Simo didn't succeed in signing up but he did find a site that transmitted his username and email in plain text, loaded insecure resources and could reveal user IDs and email addresses through login notification messages.

Perhaps worst of all, the password reset feature results in data combinations that could enable phishing attacks. An attacker logged in as you can get personal information from REST service responses, including name, address, date of birth and Social Security number. That's exactly the kind of information identity thieves can use to get false credit cards or gain access to bank accounts.

It appears that Ben Simo was more concerned about personal information appearing on the Web than the people who made Healthcare.gov.

Simo's analysis has been quoted in TIME, on CNN and during HHS Secretary Kathleen Sebelius' Congressional testimony. Simo is a former president of the Association for Software Testing, and I've served on its board of directors. We're regular humans. How did one of us find not a single defect but a systematic mess?

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.