Why HealthCare.gov Failed

Experts say a lack of consumer-centric development and user testing led to the disastrous rollout of the government's Obamacare portal.

Alex Kane Rudansky, Associate editor for InformationWeek Healthcare

October 24, 2013

4 Min Read
InformationWeek logo in a gray background | InformationWeek

10 Mobile Health Apps From Uncle Sam

10 Mobile Health Apps From Uncle Sam


10 Mobile Health Apps From Uncle Sam (click image for larger view and for slideshow)

President Obama's speech Monday addressing Healthcare.gov's let-down of a debut was full of emotion. Obama is angry. He's requesting patience. He's faithful the glitches will be fixed.

Although those sentiments are nice to hear, the speech noticeably lacked any specific details on what went wrong and how exactly the government will address problems, other than a team working overtime "24/7".

The marketplace's failure lies in the lack of a consumer-centric approach, experts say. The system was tested prior to its launch, but not at the scale it needed to be.

"You have to generate voice and data traffic simulating interaction, flow and length of interaction," said Tim Moynihan, VP of marketing at Empirix, a network performance company that provides testing and monitoring services for Web systems. "These things combined at volume begin to affect one another."

[ What did state online marketplaces do to help ensure their success? Read Obamacare Health Exchanges: How Oregon Got It Done. ]

About a third of the 3.7 million Americans who attempted to register the first week after the marketplace's Oct. 1 launch were successful. Seven million Americans are expected to be insured under the Affordable Care Act, and they must enroll using the marketplaces by Dec. 15 in order to have coverage start on Jan. 1.

Administration officials estimate the number of health insurance applications received through the exchanges at 476,000. To date, Healthcare.gov has been visited nearly 20 million times, Obama said.

"Amazon handles more traffic in a few hours than Healthcare.gov handled at its highest point," said David Lloyd, CEO of IntelliResponse, a customer service technology provider. "Obama says the product is good. You can have the best product in the world, but if no one can buy it, it really doesn't matter."

The first step shouldn't be engagement, it should be education, Lloyd said. Basic features such as the search box didn't function as intended, with search queries returning irrelevant results. Much of the educational material about different coverage options could be accessed only after registering. This is a major roadblock not only because it prevents easy access to information, but because registration failed for millions due to glitches in the system.

The failure (and resulting political storm) is exacerbated by the lack of options out there—Healthcare.gov is all that's offered. Consumers are locked in. When you have a single option for a large marketplace, its failure is that much worse and hits that much harder.

Obama offered two alternatives to registering through the site: phone hotlines and in-person consults. These aren't bad options, considering the ease of picking up the phone -- an in-person application process is another story. But they're also last resorts. There's no way around it: The Healthcare.gov blunder is embarrassing and could have been avoided.

"When building a site of any scale, you must create and emulate the customer experience as closely as possible," Moynihan said. "You have to look at it from a customer experience point of view. You must understand how it works and appears from the customer side of the equation, not the inside, IT side of the equation."

Continual testing, not just pre-launch evaluations, is needed to ensure continued success of any site. This can be accomplished by installing a monitoring package on the live system that provides alerts for traffic or data surges, Moynihan said.

There are various "low-hanging fruits" the developers could have picked up on to prevent some of the problems, said Steve Tack, VP at Compuware APM, an application performance management company. Optimizing bandwidth could have been achieved with the merging and minifying JavaScript and CSS files, as well as compressing images. Implementing a CDN or additional Web performance optimization rules also could have saved bandwidth and round trips to improve the user's experience. All of these fixes can enhance application delivery across the infrastructure without a code update, Tack said.

"High-performing applications are not just something nice to have," he said. "Businesses can be halted without them."

About the Author

Alex Kane Rudansky

Associate editor for InformationWeek Healthcare

Alex Kane Rudansky is an associate editor for InformationWeek Healthcare. Her work has appeared in The Washington Post, the Chicago Sun-Times, The Boston Globe and The Miami Herald, among others. She is a graduate of Northwestern University's Medill School of Journalism.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights