Healthcare // Leadership
Commentary
12/4/2013
08:06 AM
David F Carr
David F Carr
Commentary
Connect Directly
LinkedIn
Google+
Twitter
RSS
E-Mail
50%
50%

How Would You Fix HealthCare.gov?

The Obamacare website launch was an embarrassment. Whether it's truly "fixed" is questionable. What actions would you take, IT pros, and what lessons have you learned?

The HealthCare.gov website, the IT centerpiece for implementing Obamacare, is said to be "fixed" now -- although there are still plenty of reports of site access problems and deeper glitches in the software.

Ever since the glitch-ridden launch of the site on October 1, IT experts of all stripes have been weighing in with their thoughts on what went wrong and why. InformationWeek last week conducted a series of interviews with experts in which we asked for a more prescriptive analysis: How do you recover from an IT disaster on the scale of HealthCare.gov?

I recap some of the common themes (and differences of opinion) below, but we'd also like your point of view. Have you ever been involved in a technology turnaround on a big, important project that failed at launch? Did you see that initial failure coming? What are the most successful strategies you've seen for reorganizing for success?

It's hard not to revert to the "blame game" -- pointing out what should have been done in the first place but wasn't -- and there's plenty more to say about that. But put yourself in the shoes of Jeffrey Zients, the man drafted to get the HealthCare.gov project on track. Would you have deployed additional manpower in a "tech surge?" Would you have shut the site down while making repairs? Would you have outsourced more (or fewer) functions? And when you report back to President Obama, which specific recommendations would you make about federal government procurement reform or IT project management strategies? How would you make those changes stick, so that the next president, Republican or Democrat, will be able to make big e-government promises and keep them?

[Read our complete coverage of the HealthCare.gov launch here.]

This exercise shouldn't be about what you think of the Affordable Care Act, a.k.a. Obamacare. Although the two issues have become intertwined, the performance of the website and the wisdom of the law are two different things.

Whether you're cheering for the success or demise of Obamacare, the facts are the facts, and the fact is this technology implementation undercut the policy implementation. I think the president and his top advisers made far too many assumptions about how easy it would be to launch a consumer-friendly insurance shopping website. They failed to comprehend how much bigger a job it is than fielding, say, a campaign website.

Martin Abbott and Michael Fisher, a couple of scalability consultants and authors we interviewed, said the government's mistakes weren't so different from the ones they've seen many private companies make when they misjudge the needed scalability and capacity of their Web systems. The one big difference they see is the partisan environment surrounding the project, where those trying to salvage HealthCare.gov and the programs it represents are competing for attention with those who want them to fail.

Here are a few key questions surrounding the HealthCare.gov failure:

Should it have been shut down?
One of the things that didn't happen but should have, according to one camp, was to shut down the website while it was being fixed, on the premise that it was launched prematurely and clearly wasn't ready. We've heard this line of thinking from computer security experts, both in interviews and Congressional testimony. The overall performance of the website doesn't inspire confidence in its security, and there's also evidence that warnings of security flaws were ignored during the site's construction.

The implication is that the Obama administration failed to shut down the site for "political reasons," because it would have meant admitting defeat and delaying implementation of the law.

Richard Spires, a former Department of Homeland Security CIO, said he would have recommended shutting down the site for repairs -- politics aside. "It takes a lot of energy to run the site," Spires said, and that energy needed to be diverted into fixing functionality and testing performance.

Abbott and Fisher disagree, saying the best way to fix an underperforming website is to make incremental changes and test them against real-world traffic, not against simulated load tests. Even security problems are better solved with a methodical approach rather than a panicked shutdown, they said.

Also, one of the original sins of the Healthcare.gov implementers was that they sent it live in a big bang, trying to bring the site up to full capacity in one day rather than having some sort of beta period or soft launch to gradually build capacity and test functionality. If the site were taken offline and relaunched, that approach would amount to a second big bang -- and, likely, big problems, Abbott and Fisher said.

Bryce Williams, the founder of Extend Health and now managing director of exchanges for Towers Watson, agreed that no going concern -- inside government or outside -- would willingly shut down its primary website. A business would be even more likely to keep an underperforming site operating while working to improve it.

What would you do? Shut it down, or not? Why?

Is this a job for government IT? 
Former Air Force Col. Mark Douglas, who as a military IT leader oversaw some technology turnarounds, acknowledged the limits of the government's capability to build complex systems on its own. "The US government is not the leader in commercial IT, nor should it be," he said. Government employees must focus on the inherently governmental aspects of a program, creating an efficient division of labor with private industry partners.

On the other hand, one of the villains in this story is the government's process for procuring IT services. David Blumenthal, a former director of the Office of the National Coordinator for Health IT, argues that managers most involved in an IT project's requirements often are kept at arm's length from the people who select contractors to deliver on those requirements, making for unnecessary dysfunction.

Extend Health's Williams suggested another way the government could partner with private industry, by letting private insurance brokers (such as his) handle more of the consumer enrollments. Under that scenario, the government would focus on services that only it can provide, like providing an online determination of eligibility for federal subsidies, while private firms would be responsible for providing "a spectacular user experience," something he doesn't see as a government core competency.

What parts would you outsource? What would you keep in government hands? And if services are to be outsourced, how must the contracting process change?

Does a "tech surge" make sense?
Drawing an analogy from military operations in Iraq, the Obama administration decided to address HealthCare.gov’s problems with a "tech surge" of additional manpower, effort, and oversight. The experts we interviewed were ambivalent about the value of such a surge, saying that it's difficult for new people, no matter how talented, to come up to speed on a mature IT project and figure out what needs to be done to fix it. On the other hand, the existing team members may know what needs to be done but aren't empowered to do it.

"On mega, custom-coded IT implementations that trip before the finish line, many organizations want to throw money at the problem in the form of outsider IT SWAT teams. Keep your money," Col. Douglas advised, "unless your program team is literally incapable of fixing the problems." He added that it's "extremely difficult, expensive, and time-consuming to bring in new people to work on custom code."

Abbott and Fisher said project leaders could put additional manpower to good use as long as they focus it on identifying and correcting problems -- the hundreds of bugs the developers have been fixing over the past couple of months.

What do you say? Surge or no surge? Keep the project team or throw the bums out?

Those are some of our key questions. We'd like your answers. Also, what are the questions we forgot to ask?

Follow David F. Carr on Twitter @davidfcarr or Google+. He is the author of Social Collaboration For Dummies (October 2013).

Though the online exchange of medical records is central to the government's Meaningful Use program, the effort to make such transactions routine has just begun. Also in the Barriers to Health Information Exchange issue of InformationWeek Healthcare: why cloud startups favor Direct Protocol as a simpler alternative to centralized HIEs. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 4   >   >>
Laurianne
0%
100%
Laurianne,
User Rank: Author
12/5/2013 | 11:03:15 AM
Re: Nothing to commend
Jen, it's not the total I question. It's how they select the contractors. The private sector learned long ago that using the lowest bid IT contractors often gets you what you pay for. The goverenment strings together dozens of such shops.
JohnD981
50%
50%
JohnD981,
User Rank: Apprentice
12/5/2013 | 10:10:08 AM
Does anyone even know what HealthCare.Gov is built on?
I confess I did not try very hard, but I found not a single statement anywhere telling us about the technology platform for HealthCare.Gov ...

Under the circumstances, I cannot imagine how anybody could comment constructively regarding what might be done to fix it.

 
Steve Naidamast
50%
50%
Steve Naidamast,
User Rank: Apprentice
12/5/2013 | 9:25:16 AM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
Re: David F. Carr

Compartmentalization has fallen out of favor with many youmger technical personnel as it seen as repetitive.  If so, why not simply make a generic\reusable component out of such code?

I have worked in such environments where this reduction in duplicate code is fostered and the end result is that the "reusable components" become such a mess in an attempt to satisfy all requirements that the woirk ends up being as bad as the worst messes you can imagine.

The other problem with such a paradigm is that of the "ripple effect".  You go into a component to modify it for one appliaction's use only to find that another is suddenly failing when it makes a similar call.

From these experiences I tend to promote compartmentalization of code no matter how repetitive because I will always know that the problems will stem from a single source, the application or system where a specific copy ofthe code is housed.

This is also why I receommended the development of state sub-sites since there are going to be differences between state requirements and the insurance companies that are going to sell there.  And true, in some cases, you would find quite a bit of code being redundant but so what?  All of the issues would be solely from the state-site being developed without any contagion from any other area of development.  And you could, under such circumstances, sucessfully outsourced the work to as many contractors as required since each state-site would have been develkoped by a single group of developers concentrating on their own set of requirements.

Of course, as several other people have already posted, even under more preferable development conditions, a strong, disciplined, management team on the government's behalf would have been required.  Unfortunately, from the responses I have been seeing in the press, I am under the impression that the original management team just didn't seem to be all that interested in seeing this project rolled out successfully but this is just my own impression...

 

 

 
James W
50%
50%
James W,
User Rank: Apprentice
12/5/2013 | 8:53:03 AM
Goal setting
My first action would be to determine exactly what is expected.  It is hard to "fix" if you do not know what a fixed system does...
HealthCareLove
50%
50%
HealthCareLove,
User Rank: Apprentice
12/4/2013 | 8:43:43 PM
Step back, change approach
The flow of the site has been improved. I echo the sentiment of simplifying the user experience so the tech team can focus on security and stability.

However, beyond that, we're still not addressing the fact that health insurance is cryptic to end users. For example the terms Bronze, Silver, Platinum, and Catastrophic do nothing to convey the meaning behind them. Instead of using arbitrary sounding plan levels why not immediately state what each level entails?

I suggest adding contextual education for the users. Use simple, concise language to explain the difference between copay and out-of-pocket expenses. Healthcare plans are complicated, but the site can be designed to make digesting all this data easier. The muddy information architecture compounds the perceived complexity of the site.

This education process should be part of the plan application - users should not have to read through multiple sites to be able to learn these things. People should come away delighted because they now understand what they're paying for and how the Affordable Care Act affects them. 

 
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:54:52 PM
Re: Fix HealthCare.gov with a new site that is highly compartmentalized...
The compartmentalization you describe sounds a lot like the cloud architecture pods / "swim lanes" suggestion of the scalability consultants and authors we interviewed. So I'm not sure it's an approach that has really fallen out of favor (or maybe there's a distinction I'm missing).
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:47:17 PM
Re: Simplify ... and don't reinvent the wheel
phadley068, Thanks for sharing your blog post. Good suggestions there. The only one I would question is the "remember people when they come back" suggestion. Yes, that's a common and recommended good usability trick, but I'd hesitate to recommend that they do anything too fancy with user identification right now, given that security is one of the outstanding issues with the site.
phadley068
50%
50%
phadley068,
User Rank: Apprentice
12/4/2013 | 5:35:08 PM
Simplify ... and don't reinvent the wheel
I agree with those that say the government should have leveraged existing health insurance marketplace frameworks.  It still isn't too late to simplify the front-end (read specific suggestions on my blog at http://wp.me/p3TMI1-1q) so the tech teams can really focus on information security and back-end integration.  Ultimately, a simplified initial user experience will go just as far as an improved backend to improve customer (user) satisfaction.
StevenJ13
50%
50%
StevenJ13,
User Rank: Strategist
12/4/2013 | 5:27:47 PM
Re: Bidding system
Lowest cost sometimes applies even you are even "in the club". A handful of companies have been providing this exact type of system (less the integrations) who would probably not even be considered if it was a so called "full and open" competition.  This isn't just this project but any government project.  It awards those who play the game the best – not those with the best solution.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
12/4/2013 | 5:26:09 PM
Re: Nothing to commend
If the signup form data was at least captured correctly, it might be possible to go back and fix enrollments that were not transmitted properly to the insurance provider. The worst thing would be if it turns out the data of those seeking coverage was lost or hopelessly scrambled behind the scenes, even as the front end seemed to show them everything worked fine.

I agree the uproar over not getting access to the website will be nothing compared with what will happen if enrollments were irretrievably screwed up.
<<   <   Page 2 / 4   >   >>
2014 US Salary Survey: 10 Stats
2014 US Salary Survey: 10 Stats
InformationWeek surveyed 11,662 IT pros across 30 industries about their pay, benefits, job satisfaction, outsourcing, and more. Some of the results will surprise you.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - July 22, 2014
Sophisticated attacks demand real-time risk management and continuous monitoring. Here's how federal agencies are meeting that challenge.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A UBM Tech Radio episode on the changing economics of Flash storage used in data tiering -- sponsored by Dell.
Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.