Here’s why getting the Obamacare exchanges to work was so difficult
This week, the new health-care exchanges created by the Affordable Care Act, dubbed Obamacare, have come in for a lot of criticism. The sites cost millions — in some cases hundreds of millions — of dollars to create. And some of them weren't ready for the traffic they received on Oct. 1, the day Obamacare went into effect.
On Wednesday, I asked Robert Moss, an IT expert who has helped both states and insurance companies prepare for the launch of Obamacare, to take us behind the scenes. He explained to me why building the exchanges and keeping them running has proven so difficult. The transcript has been edited for clarity and length.
Timothy B. Lee: What kind of experience do you have with the implementation of Obamacare exchanges?
Robert Moss: I'm a software developer and software executive by background. Up to two years ago, I was vice president for products at a company called Benefit Focus. Even before Obamacare passed, we were watching and figuring out what to do. We backed away from it, decided not to go that route [e.g. bidding for work building an exchange]. In part because of the complexity of standing up large-volume Web sites.
Since then, I've been working for a firm called Optimity Advisors. In that context I've worked with both state governments as well as commercial insurance carriers to help them prepare. I've been behind the scenes. I've not led development, but I've helped them understand what to require and how to organize the project.
I've also worked with a lot of commercial insurance companies as they've tried to organize their operations to interact with the exchange. Once someone purchases their insurance, it has to get transmitted to the insurance companies. There's been a whole lot of work insurance companies have had to do.
Have you been surprised that many exchange sites have had problems in the first few days?
Everybody who's on the inside has really expected it to be pretty rocky at the start. It's a very large undertaking, and there are so many players involved. Such fixed deadlines. Everyone has expected it to be quite a challenge.
It's a "big bang" launch. On October 1, they're open for business. Their heaviest traffic, millions of hits, is going to come on the first couple of days after they're launched. When we've launched these types of systems in the past, we always direct [clients] to do a phased rollout strategy. Bring it out segment by segment or state by state. In the case of federal exchanges, it may not have been politically feasible. Had to open for business on a single day. Get this massive amount of traffic all in one day. That's a huge factor. The attempt to roll something out that fast, all at once, is bound to have these [problems].
But there are strategies for coping with a big initial burst of traffic, right?
There are many strategies for handling that kind of big burst of traffic, which is things that some of your larger companies, your Twitters, your Googles, your Amazons, these are things they do to be able to scale up, scale down their servers as needed to handle the traffic. I'm not exactly sure what's in place in terms of the federal government infrastructure if they have that kind of bursting capability or how they're able to add capacity dynamically. But certainly the behavior, this is exactly consistent with servers being overloaded.
So do you think these early hiccups are a sign of deeper problems with Obamacare's online infrastructure?
It remains to be seen obviously. If over the next few weeks, the exchanges can make adjustments to add the bandwidth they need, scale out, get the sites to work, this will all be forgotten at some point. [People will say] "it wasn't available the first couple of days, but eventually we got through." If traffic patterns follow what you expect, you should expect traffic falling off and capacity coming up. However, this is really just one piece of the story. There's many more steps to the whole process that could yet [cause problems].
What you're seeing right now is people going to Web sites and trying to select a plan. The next step is for data about the plans that shoppers pick to be submitted to insurance companies. I haven't heard back from contacts in the carriers if they've received orders yet. It's possible that will work, or there could be lots of errors in that data. Typically, there's a shaking-out period where there are problems or errors. They'll have to work on that.
Hopefully that will work well. If it doesn't, you'll see a lot of errors in the system. You buy a certain product from a certain insurance company, or you don't have it quite right. Any number of things that could go wrong. That would start showing up when people, around the beginning of the year, they go to the doctor or the pharmacy and find that there's no record of them having signed up.
And then there's the whole billing and payment aspect. That's a whole new wrinkle where if you go shopping, and you're eligible for a subsidy, you'll get an invoice in the mail from the insurance carrier. So there's the potential for things to go wrong with a field being incorrect. These are all just natural parts of the project where you're rolling out a large system and a complex system. You just have to go through those stages and shake out the bugs, shake out the kinks.
These Web sites cost a lot of money. [California's exchange, for example, reportedly cost $313 million to build.] Start-ups often build sophisticated Web sites for a tiny fraction of the cost. Why are these things so expensive?
There are lots of different reasons. Part of it is these are large IT projects being conducted by government agencies, by large contractors with large teams. There are a lot of layers of project management, of requirements, design, coding. It looks very different than your small start-up where you've got 10 people in the room working closely together and rapidly developing things.
Even though in this type of setting the development teams are using what you might call agile methods, there's still a huge layer of requirements and review and sign-off. There's lots of policy decisions that have to be made that shape ever step of the way. There's much more overhead involved in this sort of thing than if you're trying to have a small set of people developing the Web site.
The [bottom] layer is the Affordable Care Act, which laid out the parameters. Then on top of that are all the regulations that HHS issued over the course of two years. Then it goes to contractors who have to build it. If you look at the contract, there's usually a prime contractor and subcontractors. And I think that just adds to the complexity and adds to the number of parties involved. The state governments had to comply with CMS mandates and then work with their contractors. So it's a pretty complicated structure of trying to roll out. To design what you're trying to build and build it at a time where the regulations were being written.
If you're a commercial software start-up, you work very differently, you have an idea of what you want, develop quickly, roll it out, evolve on it, as opposed to trying to figure it all out in advance.
These sites handle a lot of sensitive data. Does that add to the complexity and cost?
These projects so big is that there is a very rigorous security oversight involved and layers of audit, layers of rules. The kind of thing that small start-up companies who are just winging it [don't deal with]. The Center for Medicare and Medicaid Services has been doing this for a long time in terms of the Medicare and Medicaid program. There's already a lot of rigor, security audits that have to be passed.
These exchanges also have to interact with a lot of government systems, right?
Yes, there's a thing called a federal data hub. The Internal Revenue Service is involved for tax reasons. The Department of Homeland Security is involved because of immigration status. The Social Security Administration is involved. Lots of agencies are involved to confirm eligibility for coverage and subsidies. Part of the challenge has been building a data hub to connect data from all of these agencies.
When you submit your application, they need to go out and validate whether the tax records show you're in the right income bracket for subsidies and all these other things. That's a massive amount of coordination, but there's a lot of complex system integration behind the scenes there.
Originally Posted by Copperfield
