Since my original impression that the debut of the Healthcare.gov web site was a technological disaster, I’ve contended that the website could be created for much cheaper, and be much easier to use than the mess that was delivered.
There finally seems to be progress in this direction according to today’s New York Times article, HealthCare.gov Is Given an Overhaul. I was quoted by Robert Pear:
“Instead of being user-friendly, the original website was user-hostile”
Basics of Data Entry Systems
We at FMS have created countless database systems where data entry played an important role. Unlike fancy graphics filled systems that look nice, data entry systems must be designed with a focus on ease-of-use by the end-user to enter, review, and update their information. If there are many questions and complex relationships, users need to be able to see as much of that on one screen as possible. If multiple screens are required, being able to move back and forth between screens without losing data and having changes in one screen reflected on others is critical for an efficient and intuitive user experience.
Data Entry Systems Should Target Users with Large Screens
For complex tasks such as writing a paper or working on a large spreadsheet, computers remain the preferred platform for getting work done where people can have one or multiple large screens. Serious data entry applications should target that user.
Mobile Apps Have a Role, but Not for Serious Data Entry
While mobile applications have a place, it’s not appropriate for complicated data entry since one question per screen is very inefficient. Not being able to see previous entries and pressing Next and Back for each question drives users crazy. The original designers of the Healthcare.gov web site designed it as if it were a simple, consumer mobile app meant to be filled out with a few finger clicks. They were either paid by the screen or just clueless about what a business data entry system requires.
Initial Request for Information Should be Anonymous
The purpose of the public facing Healthcare.gov website should be focused on helping prospects with the buying process. People need to quickly browse the health insurance options that are available to them in their state and cost estimates. The initial data entry should be the minimal anonymous information necessary to produce those results such as gender, age, zip code, family size, etc. Nothing personal such as names, social security numbers, email address, etc.
Automating a Paper Form
Only after customers have made a decision to buy should they be required (and expect) to provide more detailed information. This application feature is the core of the public facing Healthcare.gov website and is simply the automation of a 12 page paper form. It shouldn’t be that difficult.
We at FMS have automated paper forms for decades. Recently, we did this for a series of paper documents at the National Archives. The cost of doing this was in the tens of thousands of dollars, not the hundred of millions that Healthcare.gov cost.
Separating Data Entry from Complex Validation
A high volume, data entry system like Healthcare.gov should be designed to collect the user’s information as quickly as possible without trying to validate everything with other government systems in real-time. The cross-validation of information against IRS, HHS, Homeland Security, and other databases should happen in a background process that can withstand slowdowns or down times of dependent systems. This separates the complexity and risk of linking multiple systems together, manages the load on the other systems, and lets the user get done quicker. If a problem is detected later, an email can be sent to the user to fix the mistake or invalidate their application. Regardless, none of that needs to happen while the user is entering their data. After all, it’s not as if they were going to get insurance immediately upon pressing Submit.
Taxpayer Abuse
It remains shocking to me that it cost taxpayers hundreds of millions of dollars initially for the broken Healthcare.gov site, and hundreds of millions dollars afterwards to the same contractors to fix it. The procurement process and incentives are completely inverted for creating and delivering quality software. It’s outright theft, but no one seems to be held responsible for it, and lots of people profiting mightily from it.
Conclusion: Data Entry Systems Aren’t Difficult If You Know What You’re Doing
I’ve contended that we at FMS could have created the public facing Healthcare.gov site for $1 million. Some people scoff at that, but in our world and that of our customers, $1 million still goes a long ways. We created an international humanitarian relief logistics system for the United Nations for half that amount, and it supports full language localization as it’s deployed in 80+ countries. Healthcare.gov didn’t even support Spanish when it debuted, and that was one of its original requirements.
Creating a good data entry system is not rocket science. This is not something that needs to be done in Silicon Valley. What’s needed is a team who’ve done it before and know what they’re doing. Creating this type of solution requires a solid database foundation, understanding the user needs, creating an intuitive user experience, and building it so that it’s maintainable over time. It’s not something that can be created by people on their first paid programming job, but it’s not a rare skill. I’m proud that my development team at FMS have been with me for decades and continue to deliver systems that just work.
How Could the Federal Government Spend So Much and Get So Little?
The government contractors in the Healthcare.gov project continue to make fortunes after delivering a technical disaster. Unfortunately, this is common among IT projects delivered by large government contractors. Each year the government spends billions for poorly designed or non-functional systems that never even get deployed.
When I wrote my original blog post about Healthcare.gov, I thought the web site was created by incompetent people. Now I believe that in addition to being incompetent or inexperienced, decisions were made to maximize contractor profits.
This is philosophically different from the way we think at FMS. We always want to deliver functional systems on-budget and on-time. We take pride in creating solutions that don’t require additional work to fix them. As a small firm, we’re held accountable for our deliverables. If we fail, we would never be invited back. For large government IT contractors, it’s a totally different world.
Blame Others
Over the years, many large IT government contractors have abused taxpayers so often that they forgot the public would actually use Healthcare.gov and judge their performance. Even now, with their legions of lawyers and media spin, they are deflecting the story to blame government officials, other contractors, etc. without taking any responsibility. I agree there were problems with other parties, but that’s in addition to their own behavior.
Charge Extra for What Should be Included
Government contractors are experts at adding change orders and generating more revenues for features that should be already included. For instance, we are now hearing about problems with data security for the Healthcare.gov site. Security should be implemented from the beginning. Anyone with any experience collecting personal information such as social security numbers and birthdays knows that. However, the government contractors who won these contracts based on “past performance” suddenly suggest others are to blame for not specifying it earlier. That’s like buying a car and discovering brakes were an add-on. No, it should be included without asking for it. Storing data requires doing it securely.
Too Big to Fire
Given the awful work delivered on October 1, there’s no chance that the same team can be trusted to deliver a functional system. They already showed the world what they considered shipping quality, yet they remain. Unfortunately, our existing procurement system keeps these large government contractors because they are simply Too Big to Fire.
No Accountability for Large Technology Contractors
A small government contractor that performed so badly would not be allowed back into these agencies. The large ones can deflect the blame and legally challenge any attempt to hold them accountable. They never issue refunds, and in fact, profit from their mistakes with awards of new contracts and change orders. They are effectively not held accountable for their awful past performance, so the disasters repeat themselves whether it’s at HHS, FBI, Air Force, IRS, etc. The federal government is littered with expensive projects that were never used or functional, but highly profitable for the contractors.
Our Government Contracting System Encourages This
What happened with Healthcare.gov is exactly what our system encourages contractors to do. Had the contractors finished on time and properly, they would have made less money than delivering a flawed system. The government has tried to privatize its services by using outside contractors. Unfortunately, these government contractors are specialists at getting government contracts and milking taxpayers more than their technical ability. They would never survive in the private sector.
Policy Makers Now Have Political Risk for Technology Decisions
This is the first time an administration has paid such huge political cost for mismanaging technology. Prior to this, Presidents understood they were responsible for the economy, jobs, wars, terrorism, crime, responding to natural disasters, etc. They never realized there was political risk with technology. President Reagan wasn’t blamed for the Space Shuttle exploding, but this administration has become responsible for this web site disaster.
Contractor Goals and Values Do Not Align with Policy Makers
Frankly, I don’t think the politicians have any better handle for designing rockets or web sites. They relied on contractors and these contractors misled them. The policy makers don’t realize the goals and values of the contractors differ from theirs. Watching our leaders say the self-serving things their contractors tell them is even more embarrassing. Those contractors are not your friends!
Lobbying and Post-Retirement Jobs Drive Business
Some government officials are swayed by promises of post-retirement jobs at the contractors they supervise. Look at all the former program managers, contracting officers, Congressmen, admirals and generals at these government contractors and their lobbyists to understand how business is done.
Contractors get on contracting vehicles like the IDIQ for Healthcare.gov (termed “Licenses to Hunt”), then send in their well connected people to get contracts directly or wire contracts by “helping” draft requests for proposals (RFPs) favoring their organization. Perfectly legal. Not taxpayer friendly.
Bipartisan Reform Required
This is a bipartisan issue because unless IT government contracting is reformed, this is going to bite future politicians/policymakers of both parties. They do not have the training or experience to manage these technology projects. Especially when the contractors are run by used car salesmen who say, “You should get the undercoating” and the government people are technically unqualified to say “No”.
Technology Accountability Office (TAO)
We need the creation of a Technology Accountability Office (TAO), similar to the GAO to help agencies properly manage and buy these solutions, or an agency that manages large IT projects so the Best Practices are dispersed across the agencies. Right now, politicians have no clue whether a project should cost $1 million or $100 million, and whether it can be done in 3 months or 3 years. It’s total chaos and taxpayers are paying the tab.
Related Resources
Here are a few opportunities where I’ve spoken about these issues.
November 30: Fox & Friends Live Interview with Clayton Morris
A one-on-one interview with Clayton Morris for four minutes discussing how large government contractors profit from delivering systems that don’t work: “If we follow the money, we’ll see the stink in the system…Too Big to Fire”
November 26: On the Record with Kimberly Guilfoyle
Greta van Susteren is on vacation, so I chatted with Kimberly who was in New York City while I was on Greta’s studio in Washington, DC.
“Over time, I’m beginning to see that these government contractors who took over this project have essentially made every decision that favors them as much as possible – to maximize the cost to taxpayers, to maximize their profits.”
I’ve unexpectedly become a national technical “expert” on the problems plaguing the Healthcare.gov web site for the Affordable Care Act (Obamacare). By documenting the problems from my experience trying to use the site on the first day, I was among the first to warn that the problems were VERY serious. Much more serious than the initial suggestions that crashes were due to too many users. Based on my software development experience and how awful Healthcare.gov is, I sensed the site was created by people who may have never created a scalable, database web site before. My blog posts went viral:
“It’s poorly designed,” said Luke Chung, the president of a database company in Virginia who has publicly criticized the site in recent days. “People higher up are given the excuse that there are too many users. That’s a convenient excuse for the managers to pass up the chain.”
IT developer Luke Chung, who supports the health law, blogged scathingly about his experience logging into healthcare.gov. “To deliver such low quality results requires multiple process breakdowns. It just proves you can create bad solutions independent of the choice of technology…it wouldn’t pass a basic code review. It appears the people who built the site don’t know what they’re doing, never used it, and didn’t test it.”
“It wasn’t designed well, it wasn’t implemented well, and it looks like nobody tested it,” said Luke Chung, an online database programmer.
Chung supports the new health care law but said it was not the demand that is crashing the site. He thinks the entire website needs a complete overhaul.
“It’s not even close. It’s not even ready for beta testing for my book. I would be ashamed and embarrassed if my organization delivered something like that,” he said.
October 9: CNN Situation Room with Wolf Blitzer
I was featured in an article on CNN entitled Obamacare glitches known ahead of time? Brian Todd came by the office to learn more about the challenges I encountered and the web site actually crashed while I was showing it.
“It’s written as if it were created by people who had never created a database web application before…This can be fixed in a very short period of time, and it wouldn’t necessarily be that expensive”
October 11: KABC Radio Los Angeles (AM 790): McIntyre In The Morning
Luke Chung comes on to talk about the root cause of Obamacare’s website hick-ups… (7 minutes)
October 11: Ross Fire Show on KIRO Radio Seattle
Here’s my interview with Dave Ross of Ross Fire on KIRO Radio, a CBS Radio station in Seattle:
Database expert Luke Chung has suddenly become an expert on the failings of the Obamacare computer system, all because it kept crashing as he tried to get a quote. Dave Ross and Luke go in depth on what Luke found after he dug into it (stunning ineptitude) and how he could fix it easily for a fraction of the cost. Whether you’re a geek or not, you’ll enjoy this fascinating conversation.
It’s my most in depth interview on the HealthCare.gov website. It includes my experience meeting with the House Energy and Commerce Committee staffers on Thursday, ways to improve the system, and how the Affordable Care Act can help FMS and other small businesses. I also suggested at the end of the show that our consulting team could rebuild the site for $1 million, and that I’d be embarrassed to accept so much. I think I can stand by that, but I probably should have checked with my managers first. 🙂
Two weeks after the government’s healthcare exchange website was launched , it is receiving intense criticism from Americans trying to sign up, former White House staffers, and even a software programmer, who says the site looks like “amateur hour.”
At 1:36: Tom Costello asks, “When you see this as a software programmer, what does it say to you. Luke replied: “Amateur Hour. It looks like it was created by someone who has never delivered commercial software before….A user should never see this. This would barely make beta testing.”
2:07: Experts say a lot of work needs to be done: “If they don’t change management, this project is doomed. Because we’ve already seen what the existing management considers ready for shipping, and it’s not.”
October 17: NBC Nightly News with Tom Costello
I also appeared on the evening news with a different clip from the same interview:
The company that built the botched website where people are supposed to sign up for the Obama’s health care exchanges has spent millions of dollars developing Healthcare.gov, but people are still having trouble signing up. NBC’s Tom Costello reports.
At 1:54: Tech experts say the problems with the US web site are serious. Luke says: “It doesn’t work. It’s supposed to get you a quote. It doesn’t do that.”
Luke Chung owns a software database company. If this was your product, what would you say? “I’d be embarrassed, and I’d use language with my development team that couldn’t be on the air. This is ridiculous.”
I’m on at 1:12 discussing the unnecessary complexity of the system and ways to improve it.
October 18: Sean Hannity Radio Show
A nice conversation with Sean Hannity helping him understand the technical problems with the Healthcare.gov web site. About 15 minutes.
Sean liked the conversation so much, he invited me to appear on his TV Show next week.
October 18: Al Jazeera America
Interviewed by Joie Chen on Al Jazeera America shot at their studio located in the Newseum. This was my first live broadcast. I don’t think anyone saw it, so it was good practice.
“It’s just an awful website…As I was using it, the system kept crashing on me. And as soon as it started crashing, I was like ‘Oh, my God, this system is not ready for prime time.’ The types of crashes I was experiencing had nothing to do with too many users. It was just bad…They had developers who I sensed had never been paid to create software before. It was really amateurish. It looks like it was their first job…The programming was really bad; it looks like it wasn’t tested, and even if they had programmed it properly and tested it, the design was wrong. So it really didn’t matter whether they did it right…They haven’t thought through the buying process…$200 million at $200 an hour is a million man hours, 500 man years. How did they have time to use 500 man-years? Or triple that, 1500 man years..This is just filling out a paper form and getting a subsidy…It shouldn’t be that complicated.”
October 24: MSNBC Chris Jansing Show
A relatively lengthy eight minute interview where I evaluate the existing system and point out the problems with federal contractors. Chris Jansing does a nice job challenging some of my conclusions: “It’s just an awful web site”
Healthcare.gov to ‘work smoothly’ by end of November
White House economic advisor Jeff Zeints has said that by the end of November — just five weeks away — the federal healthcare website will be working smoothly for the vast majority of users. NBC’s Tom Costello reports.
Starting at 1:50, I make a few comments:
“Every time I come to my application, it says it’s incomplete…It’s extremely difficult to take over someone else’s code, figure out what’s wrong with it, and fix it. Sometimes you have to throw it away and start from scratch.”
Tom Costello concluded from my comments that I didn’t believe the new team would be able to fix the site by the end of November. While I believe that will be a challenging deadline, my contention all along is that this website is not that difficult to implement. With the proper design and development team, they could create a functional version of Healthcare.gov in five weeks. Their families, however, shouldn’t expect to see them much over Thanksgiving weekend.
October 26: Fox & Friends interview by Clayton Morris
This interview was focused on how the Healthcare.gov site could be designed properly with graphics of my recommendations based on my blog post: Creating a Healthcare.gov Web Site that Works
Unfortunately, I haven’t received a clip of the episode. Will post it if/when we receive it.
November 5: Sean Hannity Radio Show
Discussing the Healthcare.gov mess, what to do about it, and how the government contractors charged so much and delivered so little. Begins with Congressional inquiries of the CGI Federal contractors before my interview starts. I start a bit after the 2 minute mark (total 10 minutes)
Luke Chung, president and founder of FMS, a software development firm based in Virginia, suggested the contractors should not try “to fix something that’s bad.”
“It’s like polishing a turd. Either way, you still have a turd,” Chung said bluntly.
He criticized the design of the site, and said it didn’t need to be so complex.He said a much simpler site would serve its purpose better, make it easier for the public to use and would likely only take a month to build.
Not my classiest quote, but you never know what a reporter will use after an extended interview. Here are the recommendations I’ve made for a better design and simpler implementation of the web site: Creating a Healthcare.gov Web Site that Works
“When I visited HealthCare.gov on October 1, that was the worst piece of software I’ve ever experienced in my life,” said Luke Chung, founder and CEO of the software company FMS. “It had nothing to do with too many users. It couldn’t serve one user.”
Chung, who is testifying in front of the House Oversight committee today, said these technical issues are the most frustrating.
“I have contended all along that this is not that difficult of a project,” he said. “It doesn’t provide health care, it doesn’t even provide insurance. It’s just a form to apply for a subsidy to get health insurance. It’s automating a paper form. It shouldn’t be that hard.”
“Technically, this is not that difficult,” Chung added. “It shouldn’t cost more than $10 million. And it should be something that can be done in a couple of months.”
“The idea that it would be perfect is never. All systems are never perfect. It’s never perfectly secure or functioning,” Chung said. “If you discovered hundreds of bugs on the initial launch, there are hundreds more or multiples of that that haven’t been discovered yet.”
November 13: House Homeland Security Committee
I was invited to testify before the House Homeland Security Committee. I provided a written testimony and gave a five minute opening statement before answering questions from Chairman McCaul.
Quoted in this article based on my testimony yesterday before the House Homeland Security Committee.
“You would assume that for hundreds of millions of dollars it would be a secure site”
Was interviewed by the article’s authors on November 18th for additional research into how the contractors took advantage of taxpayers.
November 14: Sean Hannity Radio Show
My third appearance on Sean Hannity’s radio show. I’ve become his “technical expert” and we discussed how the Healthcare.gov government contractors abused taxpayers in addition to being inept. Also discussed how the website could be designed properly and how we created the Logistics Support System for the United Nations, deployed in 80 countries, for under $500K. And that platform can be localized in any language while Healthcare.gov was supposed to also be in Spanish and they don’t even have that.
In the month and a half since Healthcare.gov debuted, I think everyone has finally accepted how technically awful the website is. Maybe this will be the end of my media attention.
November 22: CNN Situation Room by Brianna Keilar and Wolf Blitzer
While attending a week-long conference at Microsoft, I was asked to comment on the need for anonymous shopping on the Healthcare.gov website. I was taped from their Seattle studio, hence the Space Needle backdrop:
I appear at 1:50 for a short quote in this 4:30 story:
“This is something people expect when they visit any web site to not disclose any personal information until they’re at a point where they want to make a commitment to buy.”
November 26: On the Record with Kimberly Guilfoyle
Greta van Susteren is on vacation, so I chatted with Kimberly who was in New York City while I was on Greta’s studio in Washington, DC. We discussed how these contractors are “Too Big to Fire”
“Over time, I’m beginning to see that these government contractors who took over this project have essentially made every decision that favors them as much as possible – to maximize the cost to taxpayers, to maximize their profits.”
I’ve been a technical resource for Robert Pear of the New York Times since he quoted me in an article that kicked off all this media attention on October 8th.
Yesterday we chatted about how a web site needs to be built to support maximum volume which will come on the deadline date. Quite a challenge since they can’t even support the early volume. His article appears on the front page:
Luke Chung, the president of FMS, a database company in Virginia, said building the website to handle 50,000 simultaneous users was “not unreasonable.” But he said the government must be prepared to handle much larger numbers at peak times like Dec. 23, just as the Internal Revenue Services does at the tax filing deadline in April.
After confirming I wasn’t involved with the Healthcare.gov project, I was interviewed by Leigh Ann Caldwell about the new rollout while trying to board to flight at BWI:
Luke Chung, president and founder of Virginia-based software development company FMS Inc., said success for the website would be determined by both the number of users as well as how long they are in the system. He compared it to a highway, noting that 50,000 people traveling 60 miles per hour is smooth traffic while the same number going 10 miles per hour is a jam…Chung cited December 23 as the most significant deadline, noting that demand would be “huge” because people by nature wait until the last minute to act.
The Obama administration has just one day to get its Healthcare.gov website running more efficiently, but officials are already trying to limit expectations once again.
Taped from sunny Sarasota, FL over Thanksgiving weekend, this was the lead story of the evening news. Thought a beach shoot would be better but they said they’d have to explain that. Starting at 0:45, I make a few comments in response to Secretary Sebelius’ comments that people should use the new Healthcare.gov web site during off-peak hours:
“It tells me the system isn’t full baked. This system should be able to accommodate as many people who want to get on as possible.”..cut to President Obama…”50,000 is not a number that’s unheard of for websites to be able to support at one time. So I think the challenge is not just the number of users, but whether there are still bugs in the system that will prevent the process from running smoothly.”
November 30 Today Show with Kristin Welker
A portion of my taped interview yesterday was also included in the following morning’s Today Show at 1:06:
“The system either works or it doesn’t work….the 50,000 number that they’ve put out is a little ambiguous because what one wants to know is how many people per hour can get through the system.”
November 30: CNN with Tory Dunnan
Tory Dunnan had a Skype call with me to better understand the capacity of the relaunched Healthcare.gov site. I now know that I need better lighting for a Skype call. This interview was cut into multiple stories that aired all day long. Here’s one of them appearing at 1:30:
“So the challenge isn’t how many lanes do you have on the highway, but it’s how fast the cars can go down the highway. Because if there’s any breakdown, you can have a big traffic jam and pile up behind you.”
A one-on-one interview with Clayton Morris for four minutes discussing how large government contractors profit from delivering systems that don’t work: “If we follow the money, we’ll see the stink in the system…Too Big to Fire”
Featuring Sarasota Bay behind me.
December 2: MSNBC News Nation with Tamron Hall
I appeared on a panel with three others for a live interview discussing the relaunched Healthcare.gov web site. Tried to explain how software works to better understand the expected 1% error rate since software either works or doesn’t.
Do they expect 1% of the people to crash for unknown reasons or do they know certain situations will always crash and only expect 1% of the people to do that. Frankly, I don’t understand how anyone develops software with expected failure rates like this.
The contract for the Healthcare.gov site has moved from CGI Federal to Accenture, but Accenture doesn’t really have a better team to put in place. In the typical large government contractor world, the winner of a contract simply hires the existing team and moves them to their payroll. The people who do the work remain and change their business cards. Do we really expect significant improvements from a team that created the original site and thought it was ready for the public?
“This appears to be a typical government contract shuffle,” Luke Chung, the president of FMS, a software development company in Vienna, Va., said of the handoff. “A new company wins the contract and hires many of the old people. It happens all the time in government.”
Due to the media attention I’ve attracted on Healthcare.gov, I’ve been invited by the US House of Representatives Committee on Homeland Security to testify about the website. This committee is responsible for all security issues on .GOV web sites.
The hearing is at the Cannon House Office Building and starts at 10 AM on November 13, 2013. This is a formal testimony that I provide under oath.
There will be two panels providing testimony. In the first panel are:
Ms. Roberta “Bobbie” Stempfley
Acting Assistant Secretary
Office of Cybersecurity and Communications
U.S. Department of Homeland Security
Ms. Soraya Correa
Associate Director
Enterprise Services Directorate
U.S. Citizenship and Immigration Services
U.S. Department of Homeland Security
I will be on the second panel with one other person: Waylon Krush, CEO of Lunarline, Inc. We will each have an opportunity to provide a five minute statement, followed by questions from the Congressmen that will switch between Republicans and Democrats.
Additionally, we provide written testimony for the public record. I have submitted these files:
The event is open to the public with limited seating on a first-come, first-serve basis.
Testimony
The testimony took place in the committee chambers.
The first panel took over two and a half hours. By the time my panel was called, all the Congressmen had left with the exception of Chairman McCaul.
My testimony is split between two video files. Panel 2 starts with Chairman McCaul’s introduction at 2:44, and my testimony at 2:45:20 for five minutes. The other speaker gives his statement, and the Chairman asks questions at 2:56:18 (Video 1)
Here’s a clip of Chairman McCaul’s introduction of me.
The testimony continues in Video 2 with some questions from Chairman McCaul and I describe how government contractors take advantage of taxpayers.
Background on the Healthcare.gov Technology Problems
My blog post on October 1st, Healthcare.gov is a Technological Disaster, described my experience using the Affordable Care Act’s Healthcare.gov website on its first day. Based on my experience, I could tell the Obamacare site was a technical mess independent of the number of users on the system. However, “Too many users” was a convenient and politically positive excuse the contractors and administration attributed to the failure of the website. It took about a week before the press began to understand that wasn’t the case. Because of my blog post, I ended up in a New York Times article, the national broadcasts of CBS, CNN and Fox News, and a few radio shows (links are in my prior blog post). I was also invited by the House Energy and Commerce Committee staffers on Capitol Hill to meet them to help them better understand what was and wasn’t working and why.
Solutions for Improving Healthcare.gov
I dislike complainers who don’t offer solutions, so I feel obligated to offer some constructive ideas for creating a functional Healthcare.gov website. I’m not being paid to work on the Healthcare.gov web site and don’t have the actual specifications of what needs to be created, but based on my experience building database solutions and understanding load balancing, I offer the following ideas to consider.
Understanding the Buying Process for Health Insurance
It’s important to understand what the web site should do. The primary mistake the designers of the system made was assuming that people would visit the web site, step through the process, see their subsidy, review the options, and select “buy” a policy. That is NOT how the buying process works. It’s not the way people use Amazon.com, a bank mortgage site, or other insurance pricing sites for life, auto or homeowner policies. People want to know their options and prices before making a purchase decision, often want to discuss it with others, and take days to be comfortable making a decision. Especially when the deadline is months away. What’s the rush?
The existing process acts as if a retail website asked for your credit card number before showing what you could buy and their prices. Almost all sites let you browse without creating a user name. Retailers want you to see what’s available as quickly and easily as possible. People often visit multiple times before buying. Only after making a purchase decision should personal information be collected to complete the transaction.
The web site needs to reflect this and support a more common buying process.
Conceptual Overview
Here’s an overview showing three distinct processes that flow into each other (or people buy a policy at their step and leave the system). A critical part is offering a comparison matrix at each level so consumers can quickly see the differences between the insurance policies.
(click for larger image)
The first one gives policy options and non-subsidized quotes. People can click to purchase the policy from the insurance company. If so, they leave Healthcare.gov and the government is no longer involved.
The second provides a subsidy estimate and uses the same display as the first but with and without subsidized prices. People can also click to buy the policy without a subsidy and leave the system, or they can officially apply for a subsidy.
The third is the actual application for the subsidy and the only path which collects Personally Identifiable Information (PII). Higher security is necessary for this.
The first two do not require PII and would not require high security. That means a commercial cloud service such as Microsoft Azure could be used to host the site and adjust to high traffic loads. It would support people shopping and browsing multiple times before buying without the need to invest in hardware or bandwidth.
With this improved design, only a small portion of the site’s traffic would be in the final subsidy application portion. That can be isolated with high security and for much lower volumes of users since people would only apply once. Hassling people at this stage with lots of personal questions is acceptable since people are serious about purchasing.
User Experience Goals
These are some objectives for creating a great user experience:
Quickly get the unsubsidized insurance rate quotes and policies (no login required)
Easily compare among insurance policies based on features and price
Easily select and subscribe with an insurance company without a subsidy
Quickly receive an estimate of a subsidy without having to provide personally identifiable, confidential information
Easily compare among insurance policies based on features and subsidized prices
Do not ask unnecessary questions such as race that don’t impact plans, prices, or subsidies
Formally apply for the subsidy (login and personal information required)
Select a subsidized policy and pass the appropriate information so the insurance company can validate the subscriber’s information and receive the subsidy
Once policy options are offered, allow users to create a login to save their inputs, and get back into the system to recover their work-in-progress. This would be required with the formal subsidy application but not necessary for the other options.
Technical “Back Office” Goals
Performance: The system should move people through the process as quickly as possible.
Collecting Information: It should not ask for any information that’s not required for generating the policy options and prices.
Fewer Screens: Rather than having one screen per question, multiple questions should be asked in as few screens as possible. People know how to scroll. Extra screens should only be added if they depend on answers from previous screens.
Data Security: The first part of data security is to NOT collect sensitive information. Sensitive information should only be collected from people actually applying for the subsidy.
Data Integrity: All database changes need to be in transactions with commitments and rollback on failure. Situations where accounts are partially created with a valid user name and no account details should never occur.
No Other Connections During Data Entry: The system should not be connecting to other data sources while the user is entering data. Just collect the data.
Offline Processing: Once the user enters all their data for a subsidy quote, a separate system processes the applications and interfaces with the other systems to validate the data and calculate the subsidy. By separating this process from the user’s online experience, problems with connections to other systems do not impact the user.
Email Notification: Once a subsidy is calculated, an email is sent to the user inviting them to log into the system to see their options
Notification to Insurers: Web pages and web services to allow real-time views of the status of applications selecting the insurer’s policies.
Commercial Cloud Hosting: Using a commercial cloud platform would provide automatic scalability to meet fluctuating levels of users without having to make hardware purchases. By eliminating the need to collect and store sensitive user data for most of the website, commercial cloud hosting and its benefits are available without security concerns.
Oversight Goals
Management and interested parties should have system dashboards:
Real-time Displays: Monitor user progress with summary tables and graphs showing the status of people moving through different stages of the system.
Basic Business Intelligence: Summary and drill-down details by state, date, hour, etc.
System Transparency: Provide a public view of some data in a cached mode (updated daily or hourly, but not real-time).
Design Overview
Here is how the goals could be implemented for the Healthcare.gov web site:
The initial form asks people to select their state. If the visitor is in a state that has their own system, ship them to those sites, otherwise proceed with the next step in the federal system
Collect the information necessary to create the unsubsidized options. I was told there were five or so pieces of information necessary to generate the unsubsidized rates (e.g. gender, year of birth, family status, smoking status, etc.)
Display the available plans with options to compare and filter them easily based on plan level (gold, silver, bronze, etc.), provider, price, etc. Should be similar to retail web sites like Best Buy or Staples showing different products and their features in a matrix comparison, with buttons to get more details and a button to select one to buy. One would expect users to come to this site multiple times over multiple days to learn about their options before making a purchase.
An option to save the inputs. This would be the first time to create a simple account to collect user information (which does not include things like social security numbers, birthdates, or names). A simple user name (email address) and password, with a standard email confirmation that doesn’t have a time limit. This would allow users to get back to the previous screen without re-entering their data.
An option to get a subsidized price estimate. If the person chooses this option, they create a simple account because highly sensitive information will not be collected. The account is simply to retrieve the user’s entries. The user provides the information necessary to calculate the prices without having to lookup data from government sources. The user can enter their values for income and whatever other factors impact generating a subsidy estimate. Just like bank web sites let you enter basic information to get a mortgage or car loan rate before you apply, Healthcare.gov should do the same. This would allow the site to create quotes quickly without having to bog down or wait for the other sites such as the IRS, Experian, etc. This minimizes the impact of too many users. Once the estimated subsidies are calculated, a display similar to #3 above would show the options.
Finally, applying for the subsidy. Once someone decides they want a particular policy, they can officially apply for a subsidy. This is the first time personal data needs to be entered. The system should collect the data as quickly as possible without having to validate the information while the user is entering it. Once all the data is collected, the user is informed via email when the subsidy calculation is ready.
A separate background process calculates the subsidy requests and looks up the necessary data from the different sources. If any of those linked systems is unavailable, it’s no big deal since it doesn’t impact the user on the web site. The user is already gone and waiting for an email. Once the calculation is generated (or if it couldn’t be generated), the user is notified via email and they can view the results by logging back into their account.
For management, there should be dashboards with tables and graphs showing what’s happening. No more excuses of not knowing how many people are in each phase of the process, how many have received quotes or enrolled, etc. For transparency, some of this information should be publicly available updated at least daily.
Conclusions
I’m not sure whether the people designing and developing the site will find these suggestions helpful. There’s obviously lots of details not included in my proposal, but I’m confident my basic design is a significant improvement over the original site. It would provide a better user experience, be much easier and faster to develop, easier to test, and more scalable and secure. Was it that tough to envision earlier?
Let’s remember, this website remains the automation of a paper form. It’s not as hard as providing healthcare.
From the previously published rates for Virginia, the cost of insurance premiums for individuals and families was considerably lower than what FMS currently pays for our group plan. Business plans aren’t available yet, but the individual plans should be a good indicator. I wasn’t interested in the subsidies; I simply wanted to know the prices for the different plan options.
Applying for Coverage
So I went online to Healthcare.gov around 5:30 AM to apply for my family and see what it would cost. As expected, you create a login with email confirmation, and fill out a Wizard to select the options. It’s similar to many other instances I’ve applied online for credit cards and other forms of insurance. How tough could it be? Technically, it’s a very simple data entry application that should generate a quote at the end.
What a Mess!
Unfortunately, what should be a simple process is a complete software technology disaster. The logical flow of the application to register, login, and fill out the data for a family was horrendously inefficient. It seemed like the person who designed it, had never used it. Or maybe didn’t have a family which required filling out the same information for each member of the family.
Just the initial process of creating a login required multiple secret questions and other unnecessary data for getting a quote. Sure that may be necessary for the final acceptance, but it’s a complete waste of time and web resources initially. The system should expedite the process as much as possible to get people a quote without subsidies, then ask for more information to calculate the subsidies if desired. Since I later discovered it never generates a quote, it may not really matter anyway. What were the designers thinking?
Overly Complex Data Entry
As for my family, I not only had to identify my spouse, my two kids, their relationship to me, but also their relationship to my wife, and even their relationship to each other! What? Given the prior information, obvious defaults could be offered. The selection of race was also more complicated than it should be. Here’s an idea that may not have occurred to the designers: Maybe the kids should default to inherit their parents’ races. That’s how inheritance works. And does race impact pricing? If not, why ask?
The system crashed several times for me and had problems when I logged back in. It seemed like the system wasn’t even tested. Here are some screenshots:
Screenshot 1: Gibberish
(click the graphic to see an enlarged version)
What the hell is that? How could that get through testing much less production?
Screenshot 2: Error form with no data
Having error handling to catch unexpected crashes is a Best Practice in application development. It should tell the user what went wrong, what to do next, and gracefully exit the system. This page does none of that. The error message and error number are blank. Who knows what went wrong? Useless and amateurish. They do have a Live Chat button. I wonder what I would chat with them about with this crash.
Screenshot 3: Cascading errors
In this screenshot a series of errors appear to be triggered without meaningful explanation. Embarrassing.
Logging Back in and Repeating
If anything, I’m persistent. I not only had my original goal to see the premium prices, I was now intrigued to discover how poorly designed, developed and tested this application was. Eventually, I was able to finish. Took about an hour.
However, rather than receiving a quote immediately, it’s now being “processed”. For what? It shouldn’t be held up for pre-existing conditions which ACA eliminates. I would expect it to be some mathematical, logical formula that would generate the results. I presume it’s because that part of the application isn’t built yet. Although my application is submitted, given the crashes, I’m not sure what data it has. We’ll see.
In hindsight, it appears the authors have a philosophical bias toward OpenSource and “people power.” That’s all fine and dandy if it works, but this site doesn’t. To deliver such low quality results requires multiple process breakdowns. It just proves you can create bad solutions independent of the choice of technology.
Technical Software Conclusions
What should clearly be an enterprise quality, highly scalable software application, felt like it wouldn’t pass a basic code review. It appears the people who built the site don’t know what they’re doing, never used it, and didn’t test it.
I actually experienced many more problems than the screenshots I captured. Had I known I was performing a Quality Assurance assignment, I would have kept better documentation of typos, unclear directions, bad grammar, poorly designed screens, and other crashes. My bad!
It makes me wonder if this is the first paid application created by these developers. How much did the contractor receive for creating this awful solution? Was it awarded to the lowest price bidder? As a taxpayer, I hope we didn’t pay a premium for this because it needs to be rebuilt. And fixing, testing, and redeploying a live application like this is non-trivial. The managers who approved this system before it went live should be held accountable, along with the people who selected them.
I know what’s involved in creating great software, and this ain’t it. Healthcare.gov is simply an insurance quote system. As a software developer, I’m embarrassed for my profession. If FMS ever delivered such crap, I’d be personally inconsolable. This couldn’t pass an introductory computer science class.
Overall Conclusions
This is going to be a huge public relations mess that could doom the whole initiative. Maybe they can blame the problems on too many users even if that weren’t the real cause, but it’s not going to be fixed with a few weekend tweaks and throwing more hardware at this. The application process asks too many unnecessary questions and repeatedly crashes. Since 9 AM and as of this evening, the site no longer lets you apply. I presume it got overloaded or someone finally discovered how broken it is and pulled the plug. Given what I experienced, it needs to be offline until it’s corrected. Meanwhile, I’d be highly concerned about the security of the data people enter given all the crashes I encountered.
Of course, software problems with the application process are not the reason to abandon healthcare reform. As a small business owner, we face the highest premiums for the lowest coverage. I applaud the efforts to reform health insurance and look forward to working in a constructive, rather than destructive, manner to improve this. I presume once these issues are resolved, I’ll have more options for my company and employees than I did before. In the big picture, this website is much easier to fix than health insurance. We’ll see.
I thought I’d give it a new try on October 5th to see if my initial impressions were wrong. I decided to create a new account to start all over. I had forgotten how difficult it was to simply create a login.
First it requires an overly complex login name that: “must contain a lowercase or capital letter, a number, or one of these symbols _.@/-“, which is confusing based on how you apply the OR clause. A clearer and simpler instruction would be to say: “must contain letters AND at least one number”. The unclear instructions cannot be blamed on too many users.
Then, it required three secret questions just to create the login. Not sure why any would be necessary. On Day 1, I got an email to confirm my login. Today, I got this screen after the last screen: Your account could not be created at this time. The system is unavailable
It lost all the data I entered. This is a clear web interface and database design problem if they didn’t store any of my information from multiple screens prior to the Finish button. A basic rule in database applications is to never lose data. Maybe you can lose data if the current screen crashes, but there’s no excuse for losing data from previous screens….unless of course, you haven’t thought about it before.
Another Attempt on October 7
I must be a glutton for punishment. I went back in to create my login. Unlike two days ago, I didn’t get the system unavailable message. It told me it was sending an email to confirm my login information, and I actually received the email. Woohoo!
Unfortunately, because I’m trying to run a business, I didn’t respond to the email until 30 minutes later. When I clicked on the link, I got this Oops. You didn’t check your email in time message:
Are you kidding me? It would have been nice to mention that in advance. Did they really invest programming resources to design and implement a feature that requires a response to the email confirmation right away? How user hostile can we get? Most sites would offer at least 24 hours or FOREVER to respond since nothing secure has been entered yet. I need to re-enter everything again. This just adds to their user load.
Application Status
FYI, my submission on the Healthcare.gov site on October 1st remains IN PROGRESS. No price quote, no email. Nothing. Just the same status online:
October 15th: I visited the site again and saw the same screen. I didn’t realize it, but if you click on the text to the left of the status, it’s a hyperlink that brings you to another page:
Imagine my shock to read “Your application is incomplete”. Darn! Could I have missed something on the first day that required me to re-enter or add more information? I don’t consider “Incomplete” the same as “In Progress”. It should have emailed me if it needed more information and certainly shown it on that screen.
I clicked on the “Continue Application” button to see what was missing. It turns out the same irrelevant, time consuming questions were asked for myself and each family member. I also found a few more bugs with problems going backwards, and selecting the address of each family member from a growing list of identical addresses. I also encountered new questions asking whether I am a Native American, and some strange question about my children’s relationship to each other (asked for each child) that I still don’t understand:
Can I get a sponsor for my child? I didn’t bother to investigate the definition of each of those terms before selecting “None of the above”, but it was bizarre and confusing. I definitely don’t remember answering this before. Eventually, I got to the end and was able to submit the completed application with a digital signature page I didn’t recall before. So maybe my application is going to be processed now. I went back to the status form and saw that I was “In Progress” again.
Then I clicked on the hyperlink next to the left of the Status and discovered the same “Your application is incomplete” screen. Did anything change? I think the message should say “Our application is incomplete”. Ugh!
Update for October 28th
My application is still “In Progress” but also incomplete. I went through the process again. Some bugs appear to be fixed since the last visit (duplicate lists of addresses are gone along with misnumbering family members). Still had many unnecessary screens that were shown but could not be edited (for instance, relationship between family members).
The administration has announced that the system will be fixed by the end of November. My belief has been that if the right team were in place and they could control the end-to-end process and design, this system could be built in a month. I hope they get it right and their families understand why they won’t see them over the Thanksgiving weekend. Good luck!
Without stepping into a political quagmire beyond this topic, I just wanted to share our experience at FMS related to the Affordable Care Act, better known as Obamacare.
Background
I’m sure small businesses can do much more with that money than padding the pockets of the executives and shareholders of the big insurance companies. We still see healthcare costs rising, but it’s good to know the rise is tied to actual increases in services being provided rather than profit margins. We look forward to the insurance pool that Virginia is creating for local businesses. From my contacts in our Republican governor’s office, Virginia is not resisting this initiative like some other red states and is moving forward with ways to reduce our cost of doing business here. Practical decisions like this keep Virginia business friendly.
Overall Impact
For companies like FMS that already provide health insurance to its employees, the obligations created by the new legislation don’t impact us since we were already doing them. We also don’t qualify for the small business tax credits which are targeting firms with lower compensated employees. I really like the lifting of the lifetime cap because after all, that’s when you really need insurance and it wasn’t an option previously available to us. I dreaded the idea that one of our employees would have faced a terrible health problem with financial ruin even though they were insured. I also like the moves to reduce the number of healthy people who choose not to buy insurance, yet end up using healthcare services we subsidize. Overall, it’s looking like a win-win for FMS and our employees. It certainly doesn’t solve everything, but it’s a good first step from our experience.
Since my original impression that the debut of the Healthcare.gov web site was a technological disaster, I’ve contended that the website could be created for much cheaper, and be much easier to use than the mess that was delivered.
There finally seems to be progress in this direction according to today’s New York Times article, HealthCare.gov Is Given an Overhaul. I was quoted by Robert Pear:
Only after customers have made a decision to buy should they be required (and expect) to provide more detailed information. This application feature is the core of the public facing Healthcare.gov website and is simply the automation of a 12 page paper form. It shouldn’t be that difficult.
I’ve contended that we at FMS could have created the public facing Healthcare.gov site for $1 million. Some people scoff at that, but in our world and that of our customers, $1 million still goes a long ways. We created an international humanitarian relief logistics system for the United Nations for half that amount, and it supports full language localization as it’s deployed in 80+ countries. Healthcare.gov didn’t even support Spanish when it debuted, and that was one of its original requirements.
Background on the Healthcare.gov Technology Problems
