January 29, 2014

What the Creators of Healthcare.gov Could Have Learned from Cornell Information Science Classes

Print More

By SUSIE FORBATH

Since last fall, my fellow Canadians have been in the American media for some pretty cringeworthy reasons. It seems like every commentary mocking Toronto’s crack-smoking mayor is followed by a news report on the abysmal state of healthcare.gov, the U.S. federal website launched last October to provide Americans with a comparison shopping tool for healthcare plans. Although the site is for Americans, the U.S. government initially contracted the Montreal-based CGI Federal to create its back-end.

Even though the Obama administration terminated its contract with the inept CGI Federal earlier this month, the website is still plagued by a myriad of issues. Users have had more trouble navigating through the site than they would trying to cross the Canadian tundra in a bikini and flip-flops. There have been reports of people being unable to create accounts, shown erroneous healthcare subsidy calculations, and stuck in infinite loops within the site. One woman was purportedly told to “please be patient” forty times before corresponding with a live chat representative.

President Obama has acknowledged the site’s technical failures, admitting, “There’s no sugar coating: the website has been too slow, people have been getting stuck during the application process and I think it’s fair to say that nobody’s more frustrated by that than I am.” But if some basic lessons from the Cornell Information Science courses had been applied to the development of healthcare.gov, would some of the initial problems plaguing the site have been mitigated?

INFO/CS 1300: Introduction to Web Design and Programming

If Information Science students learn this fundamental tenet of web development during the second week of their freshman year, why didn’t CGI Federal employ it after receiving a government contract? The ability for users to fully complete the healthcare.gov sign-up process had not been tested until less than a week prior to the website’s public release. What’s more, the site’s capability to handle tens of thousands of users’ requests simultaneously was only tried out a few days before it went live and crashed. Instead of following the words of Destiny’s Child, “I don’t think you can handle this,” the contractors should have known whether the site could handle users’ requests well before the site’s launch date. As a TA, I would have given them an F (but I may have been more lenient if they had self-referentially included that Destiny’s Child lyric).

INFO/COMM 3450: Human-Computer Interaction Design

Beyond suffering from a myriad of back-end problems, healthcare.gov has some fundamental user experience issues. Jakob Nielsen’s heuristics are widely used to evaluate whether a web site is usable. Unfortunately, healthcare.gov failed to adhere to a majority of these rules at its initial launch and some of these problems still persist today. Users are shown complex diagrams on the site, there are poorly marked exits, and there are vague error messages. By tweaking these usability issues from the start, a user may not have repeatedly tried and failed the same action, which could have alleviated some of the serious problems on the back-end.

Dykstra-Erickson and Cheri: “An Open Source Primer”

from INFO/STS 4240: Designing Technology for Social Impact

Proponents of open source development have attributed healthcare.gov’s woes to a lack of transparency of its back-end code. The chief information officer of GitHub, a popular repository for open source code, aptly remarked, “I would personally like to see the government default be open source. It makes sense, given that government isn’t about making money; it’s supposed to be about serving the people.” Even the Department of Defense – a paragon of security – uses open source software. So why wasn’t such a strategy implemented for healthcare.gov? Had an open source model been adopted, then the open source community could have identified and improved upon the flaws in the code.

What can we learn from the disastrous rollout of healthcare.gov?

What is correct in theory may not always play out in practice. Maybe the healthcare.gov website can be used as a case study in future iterations of these courses. By learning from failings of the past, students can avoid making the same mistakes in their future professional lives.