Healthcare.gov’s Identity Problem

Identity management poses the most important and most striking problem for the new healthcare exchange site. Identity management remains one of the great, unsolved issues of our times and uniquely displays the anti-capitalist postures of some of the biggest technology businesses that exist.

That something as basic to any and every service as identity remains a closely guarded commodity shows that many major companies do not wish to compete on an even playing field. They would rather draw straws amongst themselves for the userbase pie, based on lock-in and turf wars, than to actually free their own markets. But while that general malignance runs rampant throughout virtually every industry, why in gods’ names should it infect government projects?

Indeed, inevitably the government will create a single sign-on or other universal identity mechanism for its Internet services. But in the meantime we all suffer. Everyone includes the government, with all of the bad press the new website received post-shutdown. Finger-pointing from the contractors, calls for resignations, and general what-the-fuckery from most of the attempted users of the site.

But a rough guess would get you the answer that at least half of the problems with the site center on identity when you include:

  • The initial sign-up process (username, password, e-mail verification)
  • The identity verification process (document submission, phone verification integration)
  • Family member and employee identification process

The site, like any government services site, relies on identity for so much of what it does. Handing off to other databases for things like subsidy requirement verification and other eligibility requirements.

A whole swath of inefficiency in government, much less in this one site, vanishes if the government merely gets its identity house in order.

But instead the government pays a high premium to build a monstrosity. Of course, that same argument bears against the Affordable Care Act itself with equal keenness (that a simpler system like single-payer would have saved far more money and woe both in the short term and long term).

What else could have eased the creation of the site? Some say that management of such a large-scale project requires a so-called quarterback. Others say you want a catcher. Some say you really need a good goalie, or a head chef, or even a Benevolent Dictator for Life (BDFL).

Nah. New projects suffer the most pain from the code they use for the first time. Like a new idea, fresh in your mind, or a fresh stone broken off a larger stone. Still sharp, cuts your hand, not yet smoothed by time and trial. Full of mealy worms wriggling waiting to grow into full-fledged bugs.

A QB will screw up a new play the first time through just like the rest of us. The most-needed piece of kit in software? Reuse. Use something that already gets used a ton, that does not have bugs because it gets used all the time.

The site broke because too much of the code and the way the code got used had not been proven. The databases had not been proven for their loads.

Testing a new project does help you sand the code smooth, but building from smooth code to begin with sounds smarter.