I don't need to rehash the stories about the problems that have been occurring for the folks trying to register for coverage under the Affordable Care Act. No doubt you've seen people asking how an Administration that has been as tech-savvy as this one could have blown it so badly, especially considering how well they used the Internet for two campaigns.
The reason, I suspect, is two-fold.
First, the Obama 20082/2012 campaigns were free to choose whoever they wanted to set up and run their web-based part of their operations. They had all of the flexibility of any other private organization. In contrast, the rollout of the Obamacare website was done by a government contractor working for a government agency. You need look only to other government computer messes, such as the FBI's decade-long fucked-up attempts to modernize its computer system, to see how well the feds do at new computer systems. Or, for that matter, the VA.
(The ACA webiste is so screwed up that one might assume that LockMart was running it. Apparently, it's a bunch of The Canadian Usurper's fellow countrymen. But I digress.)
Those comparisons might not be totally fair, though. The FBI and the VA have been trying to revamp and introduce upgrades to their operations while doing what they do, which is akin to changing sparkplugs on an airplane in flight. The ACA system wasn't being used by anyone.
The second reason is that I suspect that the developers thought that the Obama Administration would cave in the shutdown fight and they'd have six months to a year more to get things ready. They had no idea that President Obama and the Senate Democrats would grow a spine and stand up to the hostage-taking goons in the GOP. They were caught flat-footed. They had to rush their system into use and it just wasn't ready.
Subscribe to:
Post Comments (Atom)
4 comments:
I'm actually working in IT, and talked to someone who has done work on health care web sites including defining the protocol that health insurers use to accept policy and claims data. He is surprised that the web site is working as well as it is, given that it didn't even start integration testing until 3 weeks before it was scheduled to deploy. He characterizes its state as late alpha and says it should be working right within three to six months, depending upon how good the team is that's working on it.
The core problems were: 1) It was supposed to interface with the IRS and HHS to determine Medicaid and subsidy eligibility. IRS/HHS computers are even more fucked up than the ACA site, you just don't see them because only government workers have to deal with them. 2) There wasn't even supposed to be a national web site at all. The states were supposed to run their own exchanges that then talked to a central hub to determine eligibility etc., until June 28, 2012 changed all that thanks to the Supreme Court. It then took six months to let a contract to build the web site, which means it didn't even get contracted out until the beginning of this year. At that point it went into interminable specifications writing -- the specifications were not even finalized until early May of this year. Leaving five months to actually write the bloody thing before it was supposed to be rolled out. Not doable. Not for production quality, anyhow. We usually take four months just to *beta test* things in the industry. And to top it all off, they kept making spec changes all along -- for example, six weeks before supposed release, HHS told them to not allow people to "window shop", meaning forcing everybody to register in order to see plans. Well, that's not how it was designed to work. They hacked/kludged it in. That's no way to do things!
My guess is that in six months time it'll actually be quite usable. Of course, by then everybody will have forgotten about it and moved on to the next "outrage"...
Another piece of this is that healthcare.gov was shoehorned into the CMS Medicare administration because there was no funding for the IT built into the bill, and apparently the Dems were (justly) afraid that the Right would try to kill it by defunding its administration
Thank you BradTux for getting to the real root of the problem. The contractor didn't mess this up. All fault lies with the Government. They were in charge and had no plan and an unrealistic roll out date based purely on political considerations.
And by-the-way... the Government cannot "Buy American" unless there is a compelling national interest in doing so. Civilian programming will rarely meet the criteria.
BSquared, they originally had a plan, and then the plan got derailed by the Supreme Court. Unfortunately government moves at the speed of, well, government. Back in April I noticed a housing authority in Florida putting out for bid some servers for their video surveillance camera farm. That bid was finally awarded last week. That's six months. That's just how it's done in gov-land.
Regarding the "Buy American" thing, the Canadians only did the front end. Other contractors did the back end (well, to say "back end" is a misnomer, the "back end" is a hub that is connecting together parts written by literally a HALF DOZEN contractors), and the back end is where most of the problems lie, because the back end is what is so slow that the front end times out and errors out. That said, there are well known techniques for dealing with the situation of a slow back end, and those techniques are going to be applied. It just takes time. Time they didn't have between the time that they got to connect to the actual back end (rather than their apparently much faster simulation) and when the software was supposed to go live.
All in all, I'm surprised that it works at all, given the short time span they were given to get this very complex system up and going. Of course, we all know that if Congress had simply passed Medicare for All, this would all be moot -- the Medicare sign-up site works fine, after all. But that would have been too easy. SIGH!.
Post a Comment