The Affordable Care Act Ain't Broke: So Let's Fix Healthcare.gov (Quickly, Please)

X Facebook Email Flipboard Pinterest Print Reddit

The healthcare.gov website has been online for 2 weeks. It works, but must be improved.

There has been an overload of political and media focus and furor about the problems of the Healthcare.Gov website. The unfortunate first two weeks of the public face of the Affordable Care Act (ACA) has obscured that this Internet site is working, but it is not perfect. Even with all the technical problems, 115,000, and most likely many more, have signed up for health insurance in its first two weeks. It is estimated that there were 8.6 million unique visitors in the first week of operation, 225,000 requests for live online chats, and 406,000 call center calls. And you still can buy health insurance outside of the state healthcare exchanges.

It is estimated that there are approximately 100 software code problems (i.e. bugs) that must be fixed. Hundreds of millions have been spent on this project to date. Three years of work by four top software development/systems integration companies have produced a major achievement, but it still has “glitches”.

To my friends on the right, that there were technical problems was to be expected, and I’ll explain why. To my friends on the left, political mistakes have been made, and I’ll explain those, too. The technical decisions caused political problems. The political decisions caused technical problems.

The overall healthcare.gov site is a large scale development project, the information technology equivalent of building the Golden Gate Bridge or Empire State Building.

But there is one very important difference. Designing and building the bridge and the skyscraper did require having a vision and a specific goal, a tremendous engineering challenge. The public could see the progress of these structures being developed and have a sense of the enormity of what was being undertaken. Like creating the bridge and building the skyscraper, these multi-year software development and program implementation projects occur not very often. When they have, projects, like Social Security, Medicare and Medicare Plan D, had similar start-up problems.

Developing software is technological writing. Writing involves creating a series of words, in a specific language, that must be in the correct sequence to convey a specific intent and meaning. Writing a software program involves creating a series of words, in a computer specific language, that must be in the correct sequence to convey a specific intent and meaning. Placing one word in the wrong place creates the incorrect intent and meaning, it causes the software to malfunction or crash. Writing software that works properly is 10 to 1000 times more difficult because semiconductors do not forgive mistakes.

Writing tens, which become hundreds, which become thousands, which became tens of thousands of lines of software code that must work coherently together is a huge c3 (command, communications and control) undertaking. It is the technical equivalent of fighting a war – a war being fought on many different fronts; federal and state, political, medical, and business, simultaneously.

Even the smallest and mundane decisions add up. For example, how do you process telephone numbers and in the age of cell phones, how many and which numbers do you store? Each number has to be checked for being in a valid format, in keeping with the area code numbers assigned to each state and being consistent to the phone numbers already on file.

The four major software engineering/information systems integration companies leading this project have very good reputations and large scale software development project experience. With millions of dollars, reputations, careers, and livelihoods at stake, they needed a successful outcome. They are the easiest to blame, because the results of their work are he most obvious. But they are not to entirely blame – the federal and state politicians involved are.

The overall design was based upon having all or the majority of states participating in the Affordable Care Act. According to The Kaiser Foundation, only 25 out of the 50 states are expanding their Medicare coverage. Only 22 states have implemented or are implementing their own health insurance exchanges, independently our in partnership with Health and Human Services. The other 28 states’ exchanges are being run by solely Health and Human Services. It’s no surprise that the Kaiser Foundation’s Implementation Map looks very similar to the results of the last Presidential election. The surprising major difference between the maps is Texas, which has 1/4 of the nation’s uninsured. There are 49 interfaces to federal and each state’s systems involved, including Social Security, Medicare, state and local geographic and various private health insurance plan data. All of the interfaces had to work and work quickly and flawlessly, in real time.

The number of program servers and communications network capacity involved should have simply been increased, but politics got in the way. That only 22 states did meant that there would be more logins and information access on the federal servers and networks. Having a major design change, moving the process to access to insurance policy information after collecting the individual’s enrollment data., was made two weeks before the start date. This change alone caused major problems because all of the hardware, software and interfaces processing changed. Unexpectedly, 2,800,000 people accessed the healthcare.gov site on the first day slowing down the information gathering, retrieving and processing programs to an ultimate halt. Fortunately, there were backup plans in place. The enrollment could be, and still can be done, by calling an 800 number or sending e-mail to the addresses listed on the website.

While design changes are made and testing occurs throughout the software development process, the changes have to be stopped during the final testing process. Trying to test a “moving target” can produce false positives, the overall system works properly; or false negatives that the overall system, or parts thereof, do not work. This is where having an overall program manager with authority is critical. Someone has to say no more major changes, even if it was the President making the requests. This is where the political and technical imperatives collide.

A major part of the problem was that there was no one overall software development program manager. That problem is being fixed. Why there was not an overall program manager from the start or brought in at the first sign of problems is a legitimate question that needs to be asked and answered in full. That answer is important to keep the goal, a fully functional national health insurance enrollment system, now and in the future.

That there were going to be technical problems before and during start-up should have been anticipated. There should have been plans in place on how to quickly resolve the resulting political problems. These plans should have included the option of delaying the implementation, however politically difficult it would be. Given the widespread political and personal impact of this project, greater communication to the public and Congress about the overall design and transparency about the status of the project was and is still needed.

Should the President have insisted the start date be pushed back under the circumstances? We don’t know how much he knew in detail about and how frequently he was advised on the program status. Given that it was his administration’s biggest achievement, he was going to be criticized for pushing the start date back or not. He showed his commitment to the program by not caving in to the political demands to cut $200 million from it, resulting in the 16 day government shutdown standoff.

The decision whether to push the implementation back should have been made earlier than it was. The President did authorize a development “surge”, and the surge did not fix all the problems. He had already authorized the delay of the business part of ACA implementation for one year, due to design problems and an overabundance of paperwork involved.

Based upon what I do know, would I have made the decision to delay the start date of healthcare.gov?

If the fixes and the testing were going to take one month or less, I would have delayed it. If they were going to take more than one month, I would have gone ahead and started the implementation, but warn the public that there would be glitches, fixes, and work arounds being made. Most of the site did work properly. The importance of having the uninsured being able to obtain health insurance, and all of the human, economic and political consequences involved, was the greater priority. It is estimated that 16 million more people will have health insurance by 2014 . But 4.8 million still will not.

It is easy to second guess decisions that have been made, especially when you don’t have all the information involved. Healthcare.gov will be fixed. I am very sure of that. It’s just a matter of when.