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 of the technical woes, they disagreed on whether the Obama Administrations call for outside help is the best course of action.
Bringing in a host of third parties makes me worry that the problems werent 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 sites 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 youre 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, therell 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 companys analysis of Healthcare.gov using tools to analyze how web pages and third-party objects are rendered within real end-user browsers.
While Compuwares analysis identified many coding issues – including third-party content slowing down page load times and failure to merge CSS and JS files on the sites registration page – Grabner tells Healthcare IT News that problems plaguing the federal governments 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.
Grabner identifies design and scalability as the greatest challenges for Healthcare.gov.
The goal is to enable users to do what they want with the application as fast as possible, minimizing the steps required to get from logging onto the page to finding their life insurance, he says. It seems they basically made it harder than necessary by adding more steps and features to the site in order to offer users more flexibility. But in the end, most users just want to go through the process as fast as possible and get results. They want to open their browsers, go to the website and get their insurance.
The problem, Grabner says, is that system architects made decisions under time constraints and selected frameworks they thought would help them, but while they helped push this out as fast as possible, they didnt help their scalability goals.
For his part, Grabner says the White Houses all hands on deck reaction to Healthcare.govs woes may be counterproductive.
Typically war rooms are not the most efficient way to solve a crisis like this, he says. It makes more sense to have a smaller group of people look at the big picture and say, Where are our bottlenecks, where are our major problems? I dont think it makes sense to put 100 people in a room and fire them up by telling them this problem needs to be solved as soon as possible and putting a lot of pressure on them.
Meanwhile, a high-ranking executive for a healthcare software company that serves as a subcontractor to some state health insurance exchanges tells Healthcare IT News that the federal site appears to be a victim of politics and bureaucracy.
Big IT projects are difficult to do, but if you look at how people get big IT projects done, they use agile, iterative approaches to build a little bit of software, get it to work, then scale it, he says. Thats how Apple or Google brings a product to market. They get something out quickly, then they iterate from there, and they make sure it performs operationally. And you could argue that the federal government took exactly the opposite approach.
That approach was being driven by politics, he argues.
I think they caved into the political pressures and tried to do too much overall in too short a time frame, he says. Theyve got all these health plans, they got all these different constituents, and in the process of trying to listen to these constituents they ended up with an unwieldy set of overall system requirements. Then they tried to bring that to the market in sort of a big bang.
Beyond that, the executive says, Healthcare.gov appears to have fallen victim to classic government mismanagement.
The second issue, as far as I can tell, is that HHS tried to be its own systems integrator, he says. Everyone keeps talking about CGI, but the actual prime contractor was the federal government. And I think there are a lot of signification questions about whether the federal government, in the form of HHS, has the skills to manage a project of that complexity.
The executive says the administrations initial response to the problems plaguing Healthcare.gov may be counterproductive.
Youve got (HHS Secretary Kathleen) Sebelius and Obama basically saying, Were beating up our contractors and getting them to work 24/7,\' he says. When what you really want to be doing is having honest, candid conversations with your contractors.