The lessons of Healthcare.gov

Posted by on March 16, 2015 3:41pm
bigstock-Healthcare-In-The-Unted-States-1719657 In the fall of 2013, the newly launched Healthcare.gov website buckled under the weight of a crush of people trying to sign up for affordable health insurance. Although the site reportedly cost more than $500 million to build, it wasn’t adequately tested for high volumes, and what was to have been a celebrated milestone became a bit of a fiasco. That incident really highlighted for everybody that scale is not something that can be taken lightly.

This year we’ve just passed the second deadline to sign up for healthcare under the Affordable Care Act, and while the enrollment process generally went a lot more smoothly, it didn’t go off without a hitch. As a February 15 deadline neared, the site suffered a six-hour outage due to a glitch in connecting to an outside site for income verification.

The good news this year was that the glitch was quickly addressed and people who were not able to make the deadline as a result of the disruption were offered extensions to complete their enrollments.

But the nature of this year’s briefer outage, and the resulting consequences offer some other important insights about what it takes to test a website performance thoroughly, and what happens if you don’t:

Websites and applications are becoming more and more complex.

It’s telling that the nature of this year’s glitch on Healthcare.gov was a problem connecting to an outside site required to verify enrollees’ income levels. How frustrating must this have been for developers who believed they’d addressed all the problems from the year before? The fact is, it’s pretty common for multiple services to be involved in a simple consumer transaction. To test properly, you must ensure not only that individual sites and services are running as designed, but that they also interact smoothly without performance issues.

There’s the front end and then there’s the back end.

While the disruption to the public-facing side of Healthcare.gov was relatively short this year, there were reportedly many more ongoing problems on the back end. ‘The front end hummed but the back end hiccupped,’ according to one report that described a clunky network of workarounds and manual spreadsheets that were pieced together to help ensure users were assigned to the correct health plan after they signed up. Here at Nouvola, we talk a lot about testing the complete application end-to-end ahead of time so that users are not disappointed, and backend problems can be costly and time-consuming.

Even hiccups can be costly.

When Healthcare.gov crashed, traffic to supporting call centers surged with wait times surpassing ten minutes. Not only is this a very expensive backup strategy, it’s one that’s likely to further alienate users if they have to wait some more for a resolution.

Don’t count on a captive audience.

While the Affordable Care Act requires all adults and their families to have health insurance, there’s no law requiring consumers to buy merchandise, play games or consume information from your website. People in the market for health insurance may have had no choice but to wait for the site to come back up, but that’s the exception. In a world of abundant options and fierce competition, users will not stand for a poorly performing website. They’ll just go elsewhere.

Get DiveCloud & Start Testing

\