HealthCare.Gov Woes: Lack Of Testing

Tech contractors are confident they can fix the problems over time, but pass the buck to CMS.

7 Portals Powering Patient Engagement

(click image for larger view and for slideshow)

Four tech contractors who testified before a House Energy and Commerce Committee Thursday said the main reason the government's Healthcare.gov registration website failed during launch was a lack of time and rigor in fully testing the systems and software connections. The underlying message, however, was inadequate coordination and last-minute design changes led to the troublesthat continue to plague the website.

Representatives of CGI Federal, Quality Software Services Inc. (QSSI), Serco, and Equifax -- four of the prime contractors and data processors among a total of 55 contractors that had a hand in building Healthcare.gov -- all defended the performance of their companies. All four identified the Center for Medicare and Medicaid Services (CMS) as the entity serving as the prime contractor and whose schedule and project demands ultimately determined the project's rollout.

One major shortcoming in developing the website was insufficient time for testing. Part of that lack was structural -- the Oct. 1 launch date was a hard deadline, one that the contractors told committee members they did not question, even though changes in the site design were being incorporated as close as two weeks before the launch date.

Another problem was an apparent lack of rigor in requiring testing throughout. For instance, despite the complexity, CMS' contract with CGI did not require independent validation and verification (IV&V), according to Cheryl Campbell, senior VP of the company.

"Do you think [IV&V] would have been justified?" asked Rep. David McKinley (R-W.Va.).

"At the start of the program it could not have hurt," Campbell acknowledged.

All four companies laid responsibility on CMS for end-to-end testing of all the components working in concert. Three of the executives testified that their companies were only responsible for testing and making fixes to their specific elements of the program.

The sole exception was QSSI, which did undertake evaluation of code written by other vendors on the project, said Andy Slavitt, group executive VP of Optum, the division of UnitedHealth Group that owns QSSI.

But Slavitt offered a caveat: His company evaluated discrete portions of code from other contractors, not of the end-to-end process, he said. Nor did QSSI fix any errors it found. "We reported the results back to CMS and the relevant contractor, who in turn was responsible for fixing coding errors or making any necessary changes," he said. "We informed CMS that more testing was necessary."

All four testified that their companies' tests had shown their individual components worked; only when all the components were knitted together did problems emerge.

They also testified the agency was responsible for the decision to disable a browsing function that would allow users to "window-shop" and compare insurance alternatives without setting up an account. When the program was unveiled on Oct. 1 and almost immediately crashed, Campbell said, it was because it was overwhelmed by so many users trying to create new accounts.

Many of the problems users have encountered on the website have to do with volume, the witnesses claimed. They all expressed confidence that the situation is improving every day and that anyone who wishes to enroll in a health insurance plan will be able to do so in the coming months.

Besides the question of volume, there are software problems leading to insurers receiving duplicate or invalid information, such as multiple spouses, children listed as spouses instead, or duplications of records.

"There's bad information going to the insurance side," said Rep. Adam Kinzinger (R-Ill.) "It's easier to cope with right now because insurers can review each application, but what happens when [the website] is up to scale?"

CGI's Campbell said those problems are not widespread. "It's part of our normal defect-build process; when it comes into the contact center, we look at the trouble ticket, it's assigned a priority [to fix], and we make code changes."

Rep. Joe Barton (R-Texas) grilled Campbell about language buried in the code that advised users they should have no reasonable expectation of privacy for the information they were providing. He asked all the witnesses if their companies are familiar with HIPAA privacy requirements, and challenged the language, holding CMS responsible for such an apparent violation.

In perhaps the most directly confrontational exchange of the day, Rep. Frank Pallone (D-N.J.) accused Barton of trying to scare people away from the website by sowing doubts about privacy protections. "HIPAA doesn't apply," Pallone said, because it covers health-related information. The website does not require any such confidential information, since insurers cannot reject applicants for preexisting conditions, he said.

Lawmakers asked the contractors for many documents; every time, the contractors said that under the terms of their contracts, they need permission from CMS to provide the information. Rep. Fred Upton (R-Mich.), chairman of the committee, finally reminded the witnesses of all the documents they had promised to try to provide.

"Secretary Sebelius will be testifying next week," he reminded them. The members of the committee need time to review the documents in advance of her appearance, he said.

There's is a lot of chatter about the failure of management here, and where the CIO was in all this. That this was a management failure is indisputable. Whether it was the CIOs failure is less clear.

Many projects in government are led by program managers Gă÷ call them the business owners Gă÷ who frequently have greater authority, and are often under pressure to defend that authority, making it much harder than it would seem for a CIO to have an impact on the architecture and technology recommendations on a project, especially ones that ties together so many players. This is why governance Gă÷ having defined roles and ground rules Gă÷ for dealing with competing interests in a shared project is so important.

The question here is not so much where was the CIO (though it does need to be asked), but where were the leaders who oversaw the program manager? Where were the governance controls that might have given stronger advisory roles by the CIO Gă÷ or CIOs from the playersGăÍ whose systems were being connected together behind Healthcare.gov?

The battle of expertise and authority between program leaders and IT leaders within a federal agency or department are epic, and the source of continuing debate in Congress as to whether the CIO has the authority necessary to control agency IT projects. With few exceptions, they donGăÍt.

The internal reports are starting to surface like this one from the House Oversight and Reform Committee. It shows that CGI sent a punch list of open items to CMS and warned that insufficient time was available to fully test everything, raising security concerns. http://oversight.house.gov/wp-...

No different than any other major government contract. Now you should understand better why military contracts often cost far more than the original contract price. The government doesn't have the ability to define adequately what it really wants and add to that "feature creep" and you have we have with healthcare.gov.