The problems plaguing the federal health insurance exchange website can be blamed on everything from poor coding to political pressures, according to three private technology firms interviewed this week by Healthcare IT News.

While all three identified inadequate pre-launch testing as a major source of the technical woes, they disagreed on whether the Obama Administration's call for outside help is the best course of action.

"Bringing in a host of third parties makes me worry that the problems weren't a function of website traffic, but instead were issues fundamental to systems architecture," says Kev Coleman, head of research and data at HealthPocket, a site the compares and ranks health insurance plans and which recently conducted a comparison of health insurance exchanges.

While Coleman acknowledges that "we can only speculate" about the architectural issues, he does have theories.

"We know this system is interacting with legacy systems from the Social Security Administration, the IRS and the Veterans Administration," he says. "This presents additional challenges if those systems were not designed to deal with the high number of connections that would be achieved on their sites through Healthcare.gov."

[See also: Healthcare.gov rush job, builders claim.]

Coleman says the fact that some health insurance companies have reported getting inaccurate or incomplete data from Healthcare.gov points to "data mapping problems or some other issue with the transmission of data from the host system."

But the root of the site's early failures may run even deeper than interoperability problems and data transmission glitches, he says.

"There may also be issues surrounding the actual software development model implemented by Healthcare.gov.," he says. "There have been rumors from programmers off the record who have worked on this project that requirements were constantly changing. That becomes a real problem if you're using a waterfall methodology where you begin with the requirement process, then move to coding, then move to testing, then release an entire system."

Coleman says he believes the "government is doing the right thing" by having outside parties come in to audit code.

"Based upon the analysis of the written code, load testing, performance testing, there'll have to be decisions made regarding whether subsystems within Healthcare.gov need to be modified or wholly rewritten," he says. "The problem with software programming is, depending on how code is written, it could be quicker to rewrite a portion of the code rather than go through the process of trying to fix it."

Andreas Grabner, an Austria-based technology strategist for performance software vendor Compuware, blogged this week about his company's analysis of Healthcare.gov using tools to "analyze how web pages and third-party objects are rendered within real end-user browsers."

While Compuware's analysis identified many coding issues – including third-party content slowing down page load times and failure to merge CSS and JS files on the site's registration page – Grabner tells Healthcare IT News that problems plaguing the federal government's health insurance exchange website extend beyond code.

"Multiple things went wrong across the board," Grabner says. "I guess under time constraints they tried to pull together all the different elements that would make their lives easier, but never thought about the big picture and the load they were expecting."