The Affordable Care Act, otherwise known as Obamacare, goes into “full effect” on January 1, 2014. Neutered, truncated and complicated as it is, its time has arrived.
No doubt, you’ve heard a thing or two about the nature and quality of the program’s birth. The Obamacare rollout has been labeled a disaster by every side. Deadlines have been blown. Deadlines have been moved — surreptitiously. Requirements have been changed. Every update on the program’s rollout exposes more ineptitude. Health care reform in America is supposed to be a great equalizer for members of every generation. In time, it may be. For now, <heavy sigh>.
Having spent some time in my career working on the inside of a governmental agency with deep-rooted dependency on Internet, networking and Web technology, I have some insights on just how a “disaster” like the Obamacare rollout can come about.
The first problem is that the “new” Web interface is a lot less “new” than it really should be. Here’s why.
Ooh, I’ll do it!
Big, fat government contracts are good. They are the holy grail of “gets” for technology contractors. Bidders push hard for government contracts. Unfortunately — and this is true for private enterprise as well — new technology implementations do not occur in a vacuum. Rather, the birth of a new system or even a simple Web interface like Healthcare.gov, is given the often impossible task of meshing with years of built-up systems (emphasis on the plural) that have been cobbled together over time and need.
As you can imagine, this type of patchwork-over-time building and implementing does not make for a seamless fit. Your imagination is correct. Very correct. Many long-held, government network systems are byzantine, duct-taped mountains of servers, wiring, systems, software and hardware that have been forced to evolve over time, due to changing demands.
Penny-pinching government entities make the best call they can at every juncture to deliver what they’re mandated to deliver. Varying levels of competence come into play here, certainly. When taxpayer dollars are calling the shots, it is not easy to sunset existing systems until they prove repeatedly that the system is insufficient to meet its mandate. In other words, good luck trying to employ forward thinking to head off a technology failure.
The most common scenario is OK systems become sub-standard systems over time. Good people work hard to try to keep the systems working. Multiple failures occur, causing frustration and poor delivery. It takes these failures to move a government agency to petition for funding for a new system. At this tipping point, it’s too late and too expensive for a wholesale new solution to an identified problem.
It’s like the theory of comedy: tragedy + time = comedy. In this case, the comedy is Healthcare.gov. It’s just not funny.
Accurately predicting the future demands and effectively lobbying for taxpayer dollars to future-spend on said projected demands? Well, you’re usually talking above the pay grade of whoever is actually charged with keeping the damn machines running. You can talk to them about it when they come back for their next shift.
Whoops
What, to the outside, may look like a whole lot of personnel and equipment doing very little, is often a case of a whole lot of personnel and equipment frequently coming together to react to the latest crisis caused by system failures. This is more common than you know. We, as end users, do not experience every single outage or system failure. We sure do get our undies in a bunch when it happens to us, however. Keep in mind that when it does happen to us, it’s happening to usually thousands + of others at the same time, and probably on top of another system failure that preceded it — one you did not happen to experience.
To be clear, my take on this rollout is not from any insider knowledge of the actual Healthcare.gov rollout. You cannot pin this on me. Rather, this is just how government technology is forced to work: cheap systems built up over time, reacting to changing demands, priorities and unforeseen crises. The namesake of the Obamacare website is now painfully aware of this reality: “… our I.T. systems, how we purchase technology in the federal government is cumbersome, complicated and outdated,” President Obama said in November.
Start over
So, you want a whole new website for Obamacare? No problem. But it’ll cost ya.
That’s the spiel, anyway. If only it were as simple as throwing money at the problem. In reality, the birth of a whole new Web interface for the healthcare exchanges is dependent upon the spidery network of often decades of insufficient and failing or ready-to-fail systems. The Healthcare.gov website is the tip of the iceberg. It is merely the front end of the entire system.
The problems with Healthcare.gov do not lie with the website or Web interface itself. The site is a fairly simple design that a college freshman could build. The problems lie in the back end systems.
The back end is the crux of the issue.
When a contractor (or in this case, an unsynchronized collection of contractors) takes on a project like the Healthcare.gov site, they are given a set of specifications from which they are to build the new interface. The current, in-house and also externally hosted systems are a tangled web that must be managed successfully in order to have a chance at creating a new working monster. Some work better than others. Some talk to other systems better than others. The contractors are given the task of making it work — probably with a few misrepresentations of how well the current systems (upon which the new systems will depend) are working.
Make a better one or keep it working?
You’re a computer user. You know that operating systems change over time. Microsoft debuts new operating systems every few years or so, in between new fixes and releases to adapt to changing demands. Apple, Android — all of them do the same. They react and engage proactively because they have an overriding profit motive, among other drivers. Your government agency is in the same world, but they have no profit base from which to reinvest to ward off technology failures. Private enterprise is motivated to make a better mousetrap for competitive reasons. Government agencies are under a “keep it running” prime directive.
Do contractors always ask the right questions? Do contractors get all the information they need? Do contractors sometimes overreach their capabilities to snag a juicy government contract? Do government agencies always make the best choice? Do government agencies always have the option to choose the best, most qualified contractors or are they mandated to choose the lowest bid? Is it possible to fix an ailing, patchwork system (Federal government, I’m looking at you) with a new, glossy interface? Is it possible to burn the whole thing down and start over?
You tell me.
Are we all in this together or are we the U.S. Congress?
The ideal scenario for rolling out a multi-faceted beast like Healthcare.gov is to start fresh. Once that idea got laughed out of the room, the die was cast. Rather, the plan was to hand over the (almost certainly) messy mass of data and systems to the winning bidders, with promises of cooperation pledged.
Your eager winning bidders then got to work and realized (maybe even before they got started) that the systems wouldn’t support the expected volume. When it became more clear that a train wreck had left the station, did the contractors and the agencies work even more closely to solve their problems? Or did they cover their hind quarters and keep focused on their own deliverables? Did anyone have the ability to put a halt to the critical path, when it became clear that this highest of high-profile launches couldn’t deliver on its critical mandate: make health care shopping feasible (let alone affordable) for all potential buyers (not just the expensive and desperate buyers, who would be determined to obtain health insurance coverage no matter the obstacles)?
From the Obama administration’s point of view, this is the worst part of the rollout debacle. The desperate buyers will still buy. Because in America, you can lose your entire present and future to a debilitating health crisis, unlike other modern societies like Canada, England and France. The needy (i.e., expensive) will find a way to get insurance, now that it is possible for them with Obamacare.
To make the program remotely self-supporting, the insurance must also be purchased by young and/or healthy buyers, who will not burden the health care system with their annoying health care demands. The healthy are expected to cover the costs for the sick. You know — insurance. The on-the-fence young and/or healthy — the money side of the Obamacare equation — were pushed out of the proscribed buying spree by virtue of the technological failure.
Oops.
So what happened? I believe we have our answers. This is a failure of project management, obviously. But does the blame fall on the project managers or on the situation that led to it, regardless of human foibles? It is hardly a surprise for anyone that has worked for the Federal or a state government that this rollout was botched. Did it have to be this bad? No. But we do get what we pay for. Just because a great big idea like Obamacare comes along, it doesn’t mean we — the government, the people — are ready for it.
Read our blog for more on how WiseTribers feel about health and wellness. Join us to contribute your ideas!
You should jump in here. Like it? Not so much? Have something to say about it? Let us know by adding a comment. This is your community.
Julian Rogers is a contributor to WiseTribe, Oregon Sports News, OregonLive (the Oregonian), Comcast Sports Net, ProFootballNetworks.com, Androsform.com, and other websites. He is a native Washingtonian who spent six years in Alaska. He still does not understand the appeal of hockey or dog sled racing. He has made an uneasy peace with social media and can be found on LinkedIn, Facebook, Twitter, Google+ and WordPress. He has two beautiful children and one tolerant wife, who is also beautiful.
