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.

The real reveal, however, comes from the 175 pages of war room notes from the early release of the website. The notes focus entirely on dealing with trouble tickets that occur in the field. There's no connection to testing. At no point in the document nowhere does anyone go back and say, "Here's the list of things deferred at go-live as known issues."

The entire process is firefighting. Testing wasn't seriously considered. If testing actually occurred and real testing, not fake testing it failed to make any meaningful connection to operations or support or project management. Testing failed to recommend a no-go decision.

If testing can't impact the schedule or product in any way, it's just waste. Better to eliminate it altogether.

(After repeated phone transfers, no one from QSSI was available to comment on its testing of Healthcare.gov.)

4. Do It Manually Before You Automate
After a great deal of failure and public fallout from Healthcare.gov, customers started to use the paper application process as an alternative. Sounds reasonable until you realize the paper applications would be mailed to a customer service center using the same Web-based technology to determine eligibility.

In other words: If you give up on Healthcare.gov because you can't purchase insurance, you can mail a paper application to a processing center where a human will try to enroll you manually in Healthcare.gov. That doesn't work.

Neither the federal government nor any known contractor has any way of ensuring eligibility manually. If they had an 800-number to the IRS, and another to the Department of Homeland Security, the agencies could hire an army of temps to manage the order processing. (That idea's not that farfetched; it's essentially how the federal government conducts the census every 10 years.)

If you have a large-scale adoption and have to flip the switch, make sure you have a way to flip it back and can execute manually.

5. The System Had to Be Perfect, By Law, But It Wasn't
Healthcare.gov must verify a would-be applicant's eligibility from Homeland Security, IRS and Social Security systems, in real time, plus enroll members electronically to any registered insurance company in any of the 34 states that don't have their own state health insurance exchange.

Information needs to be completely accurate, so every request needs to run-submit information, over Web services, to an insurance company. That means users click Submit, then wait for a back-end Web services call, and wait and wait and &

All this because the system had to work in "real time," or synchronously. Except it didn't.

Turns out that HHS created a spreadsheet with the basic rate table information. Healthcare.gov could have been a very simple process, then: Type in zip code, click Submit, select age and family factors, get quote and get number to call purchase insurance.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.