Do we know how bad HealthCare.gov really is yet?

For the past two and a half weeks – sadly partially silenced by the government shutdown and debt ceiling drama – Obamacare as an information system has been melting down since enrollment in the “exchanges” or “marketplaces” for health insurance went live at the HealthCare.gov website on October 1, 2013. It’s clear that the situation is bad, and is starting to alarm even the most forgiving to the President and his policies, as liberal Statist sites like The Huffington Post  publish articles with titles like “Obamacare Website Failure Threatens Health Coverage for Millions of Americans”.

The actual file name of that post is simply delicious: “obamacare-train-wreck_n_4118041.html”.

We’re starting to see lots of material being published about how HealthCare.gov came into being, and either baffled disappointment or a sense of “what else did you expect?” at how a web application project that as much as $634 million has been spent on can’t handle user loads, deliver simple web pages, or manage to correctly display drop-down list box contents, much less enroll millions of uninsured Americans for soon-to-be-universally-mandated health coverage.

It’s also been reported that of the people who have managed to actually not have HealthCare.gov error on them and get themselves enrolled that incorrect information has been passed to the insurers via the government’s website and that possible compromises of personal information (leaving enrollees vulnerable to identity theft) have both occurred.

I work in information technology, and while I’m not a software developer, I’ve got a very good handle on the architecture and design that multi-tier application systems employ, of which Obamacare’s HealthCare.gov certainly is one. For those who aren’t as familiar, multi-tier applications use “front ends” (a website through which you enter or view data, for example) and “back ends” (databases or other systems for storing and organizing data). In between the front end and the back end is normally “middleware”; software that analyzes or processes data as it is inputted into the front end or retrieves data from the back end and formats it for the front end user to see. Based on the common problems reported with healthcare.gov thus far, I think it’s obvious that inter-tier communications between layers of the application are responsible for many of the failures.

It’s not like multi-tier applications are anything new. I’ve been working on multi-tier application systems for over sixteen years. Well, it appears that some software developers might need some remedial education on the programming languages, development tools, and multi-tier systems they’re working with. It certainly seems that interfacing with government-produced, supplied, or owned software components designed specifically for information exchange between applications or application tiers are a challenge for some.

Michelle Ray (Twitter’s @GaltsGirl) drew my attention to a support forum post on the Java.net site from September 4, 2013. I’m pretty sure that the author of the thread-opening post is Srini Dhanam, who according to his page on LinkedIn works for a web site called GetInsured.com. They describe themselves as, “the nation’s easiest way to shop for health insurance. Since 2005, we’ve helped more than 2 million people find the health insurance policies that best fit their needs and their budget.” Sounds like they were a private sector (gasp!) health insurance “exchange” before government had the brilliant idea they had to be, uh, invented by the Patient Protection and Affordable Care Act (PPACA).

Mr. Dhanam is probably in the clear as far as the HealthCare.gov debacle goes for that site directly, but his support forum post indicates use of application code or programming objects that derive from government sources. One namespace URL referred to by the detailed error message he’s trying to get assistance with refers to “applicant-eligibility.ee.ffe.cms.gov” (don’t bother trying to access it; the name does not resolve). However, “cms.gov” is the Centers for Medicare and Medicaid Services, an agency within the Department of Health and Human Services (HHS) responsible for administering Medicare and working in partnership with state governments to administer Medicaid. I’m speculating that Mr. Dhanam’s problem could be related to difficulties getting the government’s systems in the multi-tier HealthCare.gov system to interface correctly with private insurers’ systems, which he could be working with or on.

From a data security/information assurance perspective, Dhanam’s use (as he says in his post) of version 7, Update 21 of the Java SDK and corresponding run time environment is also problematic. It expired on July 18, 2013. Version 7, Update 45 is the current release and includes many security fixes for vulnerabilities found in the earlier code.

Another identifiable organization within the post’s content is “NIEM”, the National Information Exchange Model (pronounced like “neam”). NIEM was created in 2005 as an inter-departmental panel to facilitate information sharing standards between government computer systems, and the primary cabinet-level departments who contribute to the organization are HHS, the Department of Justice (DOJ), and the Department of Homeland Security (DHS). Is anyone comforted that with an eight-year old developing standard for information sharing standardization between government departments in place, HealthCare.gov is having problems with…information sharing standardization between government departments and the private sector?

Doing some web searches on the “applicant-eligibility.ee.ffe.cms.gov” string led me to a different support forum post that includes it, plus additional references to NIEM. I tried through various approaches, but I couldn’t shed any light on the identity of that thread’s initiator, known by the handle “wbisantosh”. The first responder to his problem though, shed some interesting light on Mr. wibsantosh’s skills as a programmer (click to enlarge):

“Have you attended the training?…[S]eems you are in over your head.” Whether “wibsantosh” is involved in the coding of HealthCare.gov or one of the multitude of systems interfacing with it or not, that still seems like a fitting description of what has produced the horrific user experience of Obamacare thus far..

Lest anyone think a connection here to the actual HealthCare.gov site is tenuous, there’s one more thing I found. If you Google search for just the “ee.ffe” portion of the cms.gov string found from the support posts, the first item returned takes you to…drum roll, please…HealthCare.gov.

I think we’ve only scratched the surface of the technical disaster, from both information technology operational and security perspectives, that is the roll-out of Obamacare.

What do operations in the HealthCare.gov data centers or technical support centers look like? Probably something like this excerpt from the classic 1957 film starring Spencer Tracy and Katherine Hepburn, Desk Set: