IT Is One of Obamacare's Weakest Links
During the design and passage of the Affordable Care Act, its architects and supporters described a fantastic new system for buying insurance. You would go onto a website and enter some simple information about yourself. The computer system would fetch data about you from various places -- it would verify income with the Internal Revenue Service, check with the Department of Homeland Security to ensure that you were a citizen or legal resident, and tap a database of employer coverage to make sure that you were not already being offered affordable coverage (defined as 9.5 percent of your income or less) by your employer. Provided you passed all those tests, it would calculate what subsidies you were eligible for, and then apply that discount automatically to the hundreds of possible policies being offered on the exchange. You would see the neatly listed prices and choose one, buying it as easily as you buy an airline ticket on Travelocity.
Before I went to business school, I used to work in an IT consultancy, and setting up this system sounded like an enormous job to me -- a five- to eight-year job, given government procurement rules, not a three-year rush special. But Obamacare's stewards seemed very confident, so I assumed that they must have it covered.
As time wore on, the administration has steadily stripped major components out of the exchanges and the data hub behind them as it became clear that they couldn’t possibly make the Oct. 1 deadline when all of this was supposed to be ready. The employer mandate was delayed, and then it was announced that at least some of the exchanges would be relying on self-reporting of income, rather than verifying with the IRS. This greatly reduced the complexity of the implementation challenge, because now they wouldn’t be verifying subsidy qualification; they’d be calculating the subsidies based on whatever information was supplied. I thought they might make the deadline after all. Last week, however, the Wall Street Journal reported that there are still pricing glitches with the federal exchanges; the software is not calculating the subsidies correctly (no word on whether the calculations are too low, which would probably discourage people from participating; too high, which would cost the government a lot of money and lead to a debacle next March when the IRS seizes tax refunds from those people; or both). As of this writing, what is going to happen when the exchanges are open next week is unclear.
How did we get to this point? The exchanges were the core selling point of Obamacare. (The Medicaid expansion was actually a bigger part of the coverage expansion, at least until the Supreme Court ruled that the administration couldn't force states to take part, but it tended to be downplayed, because no one’s exactly a huge fan of Medicaid.) They were going to introduce competition to a fragmented and distorted marketplace, and make it easy for middle-class people to buy affordable coverage from a bevy of insurers. How can it be that one week before the deadline for opening, no one’s really sure the exchanges are going to work?
There are a lot of answers to these questions. Here are my leading candidates, in no particular order:
1. They didn’t expect Republican opposition. Here is how Democrats mapped out the future in March 2010: Law passes on party-line vote, using slightly sketchy but hardly unprecedented parliamentary maneuver. Public gets excited about finally having affordable, easy-to-access, high-quality coverage. Obama, Democratic legislators, greeted with flowers when they attend public meetings in advance of midterms. All right, maybe that doesn’t happen, but the bill is growing more popular, and people are starting to ask uncomfortable questions of Republicans who didn’t vote for it, and besides, everyone hates Republicans. Hopefully 60-vote Senate majority is regained in 2010 midterms, but even if not, given the growing public support, Republican minority has to start cooperating with Democrats to fix all the weaknesses in the law, which, after all, was a draft bill that was never supposed to pass as-is.
Here’s what actually happened: Bill didn’t get more popular. Democrats who had voted for it were punished at the polls, and they lost their House majority. Republicans who were enraged at the party-line vote and the procedural maneuvering repeated the smug brush-off they’d been given by the president: “Elections have consequences.” They refused to help Democrats repair the gaping holes in the bill, or appropriate extra money for the rollout.
2. The architects fundamentally misunderstood the difficulty of what they were proposing. Republican opposition hasn’t helped, obviously, but I don’t think they can take that much of the blame for the problems in the exchanges, because computer programming is not one of those things where adding lots of bodies solves the problem. Although more appropriations might have helped, they wouldn’t have solved the fundamental problem, which is that the people who were describing this amazing system seemed to think that if something could be easily described in English, it must not be that hard to do. I asked a couple of people who should have known how this was all going to work shortly after the bill had passed. They were quite certain that everything was under control -- of course there might be a few bugs on the first day, because that happens, but there would be no serious issues with the IT side.
This is a common tendency among even very smart people -- I once had the president of a German bank tell me that his voice recognition software obviously wasn’t working, because he wanted it to be like the computer on "Star Trek: The Next Generation." I had to gently explain that that "computer" was in fact an actor.
People tend to think that computers doing things they couldn’t do must be very smart and advanced, while computers doing things they can easily imagine -- like making a Travelocity-style website for health insurance -- must be basically pretty simple. After all, any clerk or insurance agent with the right security clearances could do basically what the exchanges were supposed to do, minus one shiny interface. So why would it take longer than three years? Startups build websites in a few months!
But as any developer will tell you, it’s more likely to be the opposite. Teaching a computer to calculate a ballistic trajectory, which is something that people have difficulty doing quickly, is pretty easy; that’s why NASA could launch the Apollo 13 missions with computers much less powerful than your laptop. But it’s really hard to teach a computer to recognize faces, which is something that you do instantly, hundreds of times a day, without thinking about it. Computers are incredibly specific -- every little thing has to be broken down for them just so. Moreover, when you’re trying to put different computers together, all those very specific instructions begin to clash. Suddenly you realize that one computer thinks that dogs are an example of “pets” and one computer thinks that dogs are an example of “animals” and how do you get them to talk about dogs without accidentally telling one computer that a crocodile is a pet?
What the exchanges were supposed to do was actually very, very hard. Unfortunately, if you’re not an IT project manager, it sounded very easy, because you could train a file clerk to do it in a few hours.
3. IT was not central to the process. There’s no cabinet-level IT position -- a mistake, in my view. When your processes depend heavily on information technology, your IT policy is your policy. Hedge funds get this, and corporations are starting to. But too many organizations don’t. They set goals and expectations without a voice in the room who can tell them what is realistic, and what isn’t.
4. All major IT implementations take longer than you think. Go back to the specificity: You don’t know how long something takes until you’ve broken it down into tiny little parts. As I saw one developer point out online recently, if you’ve done something a bunch of times, someone will already have automated that process. So big new jobs definitionally involve a sizable number of relatively novel problems, which means that you definitionally don’t really know how long it will take. Because people are biased toward optimism, the natural result is that most projects slip their deadlines.
5. They set an aggressive legal deadline. Politically, this made sense: They didn’t want to risk letting Republicans get into office and screw with their historic law. But that left them with no authority to set more realistic deadlines for the exchanges to go live. In a private-sector implementation, someone would have gone to the client last year and told them that they needed to push back a year, or more. For all I know, this did happen, but this was politically DOA.
6. They left development too late. It was crazy to let states wait until early 2013 to declare whether they’d run an exchange. It was a desperate play for political legitimacy that got them little and cost them much-needed time in the states. Decisions like this are why I say that IT did not have nearly enough of a seat at the table.
7. Government procurement rules are dumb. I’ve banged this drum before, but it’s a tune worth playing again: We are obsessed with the price of government contracts and the process of putting them out to bid, and we therefore ignore little things like the quality of the contractors, or getting things done in a timely fashion. In a system like this, where you’ve already set an unrealistic deadline that can’t really be changed, this is disastrous. We should trust our government agencies more, and then fire people who are caught hiring their brother-in-law at inflated prices.
Now, it’s entirely possible that there will be a few little glitches on Oct. 1, and by Oct. 15 all will be smooth sailing. In which case maybe this doesn’t make a good case for reform.
On the other hand, given the magnitude of the difficulties, it’s also possible they’ll be struggling to make these systems work well into November or even December. In which case, maybe we need to sit down for a fundamental rethink of how this was done.