Reporters provide insight into causes of insurance marketplace glitches

Joanne Kenen

About Joanne Kenen

Joanne Kenen, (@JoanneKenen) the health editor at Politico, is AHCJ’s topic leader on health reform and curates related material at She welcomes questions and suggestions on health reform resources and tip sheets at Follow her on Facebook.

Image by kelp via flickr.

As one of my colleagues emailed me the other day: “Life’s a glitch.”

We know we’ll be hearing A LOT more about the health care marketplace glitches, including testimony at some upcoming Congressional hearings.

I have not read every article that has come out about the technical problems but here are some that I think are particularly useful right now; there are going to be a lot of developments in this story so whatever I write now will soon be outdated soon.

The Wall Street Journal, on Friday, had what is probably the most detailed description (in plain English) about what the “glitch” is. As we suspected, it has to do with the volume of data involved with verifying people’s information. Reporters Christopher Weaver and Louise Radnofsky also explained the pros and cons of having people create accounts – which is the system that the contractors used – versus letting them window shop.

In Politico, my colleagues Brett Norman and Jason Millman talk about what else can go wrong – and  advocates and tech experts think a whole lot of things can go wrong. Once the upfront account creation system is smoothed out, it doesn’t mean that other choke points can’t and won’t emerge, such as calculating tax credits or transmitting the information to the insurance companies.  This could pose an additional layer of challenges if people can’t sign up in time to avoid getting hit by the mandate tax. The Washington Post also reported on the problems with getting the information to the insurers.

On Sunday, The New York Times offered a timeline of who got worried when – and gives a taste of the finger pointing that we can expect to come, particularly if the problems aren’t fixed fast.

An aside: AHCJ member Norman Bauman wrote a post on the AHCJ discussion list (he gave me permission to use it here) back on Oct 5 – in those first few days when we  were trying to figure out what had gone wrong and how bad it was.  He summarized some of the conversation going on among developers posting  at a tech site – and translated i. Looking back a week later, I still find it useful, particularly the comments about load on day one versus a typical day. He brings up a lot of points that keep coming back over and over again – and are being discussed in our newsroom. Here’s what he had to say:

There is a fascinating discussion at Slashdot about the web site. Many of the people in the discussion have developed or worked on similar web sites themselves, so they have first-hand experience. They know what a user interface, for example, is supposed to do.

Some of their comments are straightforward, but others are technical because they go deep into the details of designing a system like this. If you have some development background (more than I do), it’s even more insightful.

For example, they have to design a system like this to handle the expected load, but the load differs with time. They could expect the first day’s load to be enormous, but they’ll never have a load like this again. You could build it to handle the first day’s load, but the cost would also be enormous, so it’s inevitable to have the servers overloaded on the first day.

One of the standard quality control procedures is to test the load of a system before you roll it out – but it may not be possible to do a realistic test of a system with this huge number of users.

It has to be coordinated with other systems, like the IRS database. They have to confirm citizenship. One question is what else they use this data for; HIPAA allows medical records to be used for law enforcement purposes.

There are some programming procedures which would have been much faster, but they couldn’t use them because of security constraints.

There’s a debate about whether the government should have met the reliability standards of Google or Amazon – or whether the reliability standards of Amazon are really that high.

They seem to have problems with the user interface. For example, every user name must have a number (because there are so many people with the same name), but the UI doesn’t tell you that. People report logging in many times, reaching a failure, and not getting an error message about why they failed or what they have to do differently when they start over and go through the same procedure from the beginning.

Some people said that the main design was contracted out to a Canadian company, which has a history of problems. There is a debate about whether the price was appropriate. In big computer contracts, there’s always the question of exactly what the contractor is responsible for doing by deadline. Did they meet the deadline? Some people thought that the government was outsourcing too much, when some of the work could have been done internally by their own people.

Leave a Reply