Major Update: Reporting by the Washington Post confirms just about everything I have been posting about Healthcare.gov. Their source – top administration officials:

President Obama’s top economic aides were getting worried. Larry Summers, director of the White House’s National Economic Council, and Peter Orszag, head of the Office of Management and Budget, had just received a pointed four-page memo from a trusted outside health adviser. It warned that no one in the administration was “up to the task” of overseeing the construction of an insurance exchange and other intricacies of translating the 2,000-page statute into reality. Summers, Orszag and their staffs agreed.

Not surprisingly, they were right.  But it get’s even better:

“They were running the biggest start-up in the world, and they didn’t have anyone who had run a start-up, or even run a business,” said David Cutler, a Harvard professor and health adviser to Obama’s 2008 campaign,

…

Soon, however, it became evident that the office — with more than 200 people — would not survive on its own. It lacked tools, such as the ability to award grants and outside contracts, that were vital to its mission,

…

The Medicaid center’s chief operating officer, a longtime career staffer named Michelle Snyder, nominally oversaw the various pieces, but, as one former administration official put it: “Implementing the exchange was one of 39 things she did.

…

That spring, CMS had begun writing specifications for the IT contracts to build the federal exchange, but the White House again insisted on caution. A larger number of states than expected were signaling that, under Republican pressure, they would refuse to build their own online insurance marketplaces and would rely on the federal one. The more states in the federal exchange, the more complex the task of building it. Yet, according to several former officials, White House staff would not let this fact be included in the specifications.

This last item is incredible in its incompetence. No surprise it came straight out of the White House – Incompetence Central.  How could you not specify the system you needed to win the political argument? Can we say “paranoid”!

Such delays were “a singularly bad decision,” said Foster, the former Medicare chief actuary. “It’s the president’s most significant domestic policy achievement,” he said, and the very aides who had pushed the law through Congress were risking bad implementation “for a short-term political gain.”

…

Inside CMS, meanwhile, some staffers were aware by late 2012 that the work of building the federal exchange was lagging, according to a former HHS official — a much earlier timeline than has been previously disclosed. Some employees in the main office involved with building the exchange repeatedly warned at meetings late last year and in January that so many things were behind schedule that there would be no time for adequate “end to end” testing of how the moving parts worked together, the former HHS official said.

…

A month earlier, on Sept. 5, White House officials visited CMS for a final demonstration of HealthCare.gov. Some staff members worried that it would fail right in front of the president’s aides. A few secretly rooted for it to fail so that perhaps the White House would wait to open the exchange until it was ready.

Yet on that day, using a simplified demonstration application, the Web site appeared to work just fine.

Much more here. And this is a must read.

As I wrote below before I read this – Healthcare.gov is an epic failure of activist government – end update

It is clear Healthcare.gov was not ready to “Go–Live” on October 1, 2013.  And those in government who either were ignorant of the problems or who willfully ignored them should be held accountable. This is one of the clearest cases of waste and fraud I have ever witnessed. While it was driven by lofty intentions, the end result is no different than any other case of wasting tax payer money and making false claims about the experience of the team and quality of its product.

If what we see today had been done by a private company under contract to the federal government, that company would have been fired and open to serious penalties. I have seen companies nearly go under for much less incompetence. There cannot be a dual standard here.  Whatever is proper punishment for a private contractor is proper for a government agency when they do much, much worse.

Here is what we have learned in the last few days:

• First, the system WAS NEVER properly tested.
• Second, the system WAS NEVER properly secured.
• Third, the system WAS NEVER properly designed.

All of these occurred because the project was epically mismanaged by HHS/CMS.  For these failures (and in some cases crimes if a government contractor was responsible), heads should role and careers ended. Plus some compensation must be made to all the victims of this (and the victims go beyond wast and fraud of tax payer funds, many are going to have their personal data exposed).

Let’s recap the evidence of lack of proper testing:

CBS News has learned the website failed with a small test pool of 200 to 300 people that included employees from the government and insurance companies. The government employees worked at their own computers and desks within the Centers for Medicare and Medicaid Services, which oversaw the health care implementation.

According to sources familiar with the process, CMS employees were provided fake personal information to enter into HealthCare.gov rather than their own data and were given a date that testing would begin. However, on that date, the employees were told it was being postponed.

When the testing finally took place in late September, the testers started trying to create an application. Just a couple of pages into the process, everything “ground to a stop,” said one source.

“It froze. It couldn’t go forward. It crashed,” the source said.

A couple of days later, testers tried again and had a similar outcome. They were never able to successfully browse plans for cost estimates.

“It was unequivocally clear from testing … this wasn’t ready,” said a source close to the testing.

Emphasis mine. CBS aired a damning news report on the matter:

Note this is HHS/CMS testing, and if anyone thinks the heads of HSS and CMS were not “in the loop” two weeks prior to ObamaCare’s roll they are just lying to themselves. I work these kinds of programs and launch date brings out ALL the big wigs. Errors, mistakes and failures percolate to the upper echelons with warp speed. Managers live and breathe every step in those last days. The fact is, the government employees would need to have charge codes and other authorizations (fake login IDs, etc) to do the testing. And who signed off on these fake IDs? Yep, top level people in CMS.

Contrary to Tavenner’s testimony, the pre-launch CMS test results were a clear sign of what would happen. Sure enough, it came to pass as we now see in meeting notes from the first few days of “Going Live”:

The website launched on a Tuesday. Publicly, the government said there were 4.7 million unique visits in the first 24 hours. But at a meeting Wednesday morning, the war room notes say “six enrollments have occurred so far.”

…

By Wednesday afternoon, enrollments were up to “approximately 100.” By the end of Wednesday, the notes reflect “248 enrollments” nationwide.

Same problem. barely anyone getting through the process. And I would wager those that did had errors. It get’s worse if we look at the details of the reporting from the very first morning, were we find major elements of Healthcare.gov just not functioning as they should:

• VA [Veterans Administration] system not connecting
• Experian creating confusion with credit check information
• residency issue has a script being developed for the 900 issues that occurred
• many agent-brokers have not signed up on the EIDM

These four items come from a single line in the status report. But each represents a major issue, something that should have been addressed way before “Go-Live”. For those not versed in these matters, let me expand on them.

The VA system is one of the many federal databases Healthcare.gov must integrate with. If there were problems connecting, it means the pre-launch testing was completely inadequate. And if VA was not connecting, it would suspend all applications as the system waited on the results that would never arrive.

Same thing with the Experian interface for credit checks. How could there be confusion if proper testing had been performed?

The ‘residency issue’ is huge. 900 problems identified! A properly designed and tested system would not be this bug-ridden at launch. The fact “a script” was all CMS thinks is required to fix this tells me the system testing was so lame that basic capabilities ended up being debugged post launch.

And why weren’t the agent-brokers signed into EIDM prior to “Go Live” (this is the new CMS identity management system, itself a huge endeavor and an indication of CMS taking on too much all at once)? This is a sign of incompetent management. We see more and more issues with the system not being fully configured or being mis-configured. One pre-launch check is to ensure all the necessary data is entered (i.e., agent-brokers have accounts and are able to access the system) and the data is entered correctly. Clearly, this was not done.

The status reports are riddled with examples like this, of ‘glitches’ that should have been dealt with at the design phase, the test phase, or the pre-launch check phase (known as the Operations Readiness Review). The issues popping up indicate to me HHS/CMS had no idea what it means to implement a program like this, and just failed over and over again.

Which brings me to the second clear issue with Healthcare.gov – securing personal information. It was discovered back in the summer, through a GAO report, that HHS/CMS had completely missed the mark on IT Security. Sadly, I have seen this scenario way too many times in Federal programs involving large computer systems and PII data.

Last summer (July) the GOA noted Healthcare.gov was way behind schedule, and trying to implement security way too late in the life cycle.

Federal watchdogs expressed concerns to lawmakers Wednesday about the security of information that will be traded through the Affordable Care Act’s (ACA) health insurance exchanges.

Federal tax information provided to the exchanges in order to determine benefit eligibility may not be adequately protected, an official from the Office of the Treasury Inspector General for Tax Administration said Wednesday.

…

“The lack of adequate testing could result in significant delays and errors in accepting and processing ACA applications for health insurance coverage,” Duncan said.

IT Security of PII data has to be designed in at the beginning. But this article (and others) clearly show HHS/CMS was trying to fold IT Sec onto Healthcare.gov after the design was done and at the last minute (August-September). Therefore it is not surprsing to find that CMS never made it through security qualification and the system went live on a ‘provisional’ basis

CBS News first found a Sept. 27 memo signed by Centers for Medicare and Medicaid Services Administrator Marilyn Tavenner stating that testing did not occur in a single environment and noting that applied patches meant the system wasn’t always stable over the course of testing.

That “exposed a level of uncertainty that can be deemed as a high risk,” the memo stated, although it noted that the FFM underwent three rounds of security control assessments.

But today’s headlines clearly show the warning flags of summer were spot on:

“I was in complete shock,” said Hadley, who contacted Heritage after becoming alarmed at the breach of privacy.

Hadley, a North Carolina father, buys his insurance on the individual market. His insurance company, Blue Cross Blue Shield of North Carolina, directed him to HealthCare.gov in a cancellation letter he received in September.

After multiple attempts to access the problem-plagued website, Hadley finally made it past the registration page Thursday. That’s when he was greeted with downloadable letters about eligibility — for two people in South Carolina.

…

After learning of the privacy breach, Dougall spent Friday evening trying to contact representatives from HealthCare.gov to no avail; he spent an hour waiting on the telephone and an online chat session was unhelpful. He also wrote to Senators Lindsey Graham (R-SC) and Tim Scott (R-SC), along with Representative Joe Wilson (R-SC).

“I want my personal information off of that website,” Dougall said.

This is a clear breach of PII data. And it is not the first one committed by HHS/CMS (see here and here). I am deeply concerned with the use of “Navigators” and other aspects of Obamacare. HHS/CMS is sending PII data to people, companies and organizations that probably have never been vetted for controlling PII. As a federal contractor myself, I have to commit to protecting PII and take measures to ensure we never release anything. Given how this disaster has been run, I would wager HHS/CMS never did the required due diligence on all the entities it is interfacing with on the behalf of people searching for insurance.

If CMS is telling Navigators to make sure they fax PII to the right phone number, they are not taking this responsibility seriously.

Which leads me to the final nail in the coffin. The system was never designed right. This article by someone in the business of developing large software systems (like me) makes a lot of salient observations. Specifically this one:

The bottom line is that those people who claimed that all would be well if HealthCare.gov had used an agile process are wrong.  The reality is that the developers did use agile, and the project failed miserably.

…

The process we are using begins with a detailed set of customer requirements that include both functional requirements (what the software should do) and performance requirements (metrics it should meet). This is painstaking work, as we analyze, debate, discuss and finally decompose hundreds of end-user requirements. … This is a robust process with dedicated and talented engineers that is working well. This will take a few months, but when it is done we will know exactly what we have to build.

…

A complex back-end data services hub — a piece of software with zero actual, living, breathing end-users — has to be described in terms of “user” stories. Does something sound off-key to you? It should, because user stories are great for user interfaces but poor, confusing and often misconstrued for non-observable behavior.

User Stories in the Agile Process are a vague, shallow descriptions of a complex system. It is akin to saying a car needs brakes to stop (duh) and does not address the engineering to include anti-lock braking, all-wheel disk brakes, etc. If your User Stories are vague and lack detail, the resulting system will be unable to handle all the technical details. They are important, because they describe the operations concept and flesh out how functions should interact. But they are never sufficient by themselves.

Worse than that, as I noted in my previous post, HHS/CMS decided that this huge, complex effort would best be served by skimping on the required technical design documents – a process called “tailoring”:

First and foremost you need to define all interfaces and get them on a coherent schedule.  Then you have to model all state and federal sources of data (i.e., define how each one labels common information and create a Rosetta stone to relate each existing label in those data sources to a common definition, like “first name”) and then you need to model all data products (each state and each insurer in the state has unique definitions for data as well).

…

And of course, data modeling and translation is one of those things HHS/CMS tailored out to save time. [In the above diagram] R = Recommended, which in tight programs means it won’t get done.

Leaving security to the last minute, skimping on design steps and artifacts, not vetting the consumers of the PII data Healthcare.gov collects from federal databases, sending PII to the wrong people, the lack of testing, the lack of operational readiness checks, the obvious lack of knowing what they were doing – all signs HHS/CMS has created one of the worst failures in government history.

The site should not have been authorized to Go Live, and those who did so should be held accountable.

I have been doing more research on the programmatic and technical management of the Healthcare.gov program, and have identified the main reasons ObamaCare’s roll out was such a disaster. Bottom Line: Too much scope in too short a time. And the root cause of that was government taking on more than it knew how to do and not delegating enough technical management to contractors.

But before I get into those details, I must address this idea that it was the contractors’ fault and not the fault of HHS and CMS.

Health and Human Services Secretary Kathleen Sebelius will tell a House committee tomorrow the site’s botched rollout was the result of contractors failing to live up to expectations – not bad management at HHS, as the contractors suggested.

It most definitely WAS the fault of the government, who mismanaged this thing from the beginning. Not only did they not understand what they were doing, they took on the technical lead role to design and specify the solution, then integrate and test it. From what I have seen their intentions and some strategies were OK, but their execution was naive and clumsy.

Of course, the Sebelius CYA effort begs the question: if these contractors screwed up, why did HHS/CMS just appoint one to take over for them as technical lead? Got an answer to that?

And as for the idea HSS/CMS was not aware of the problems as their amateur effort began to fall apart this summer, the evidence is clear this was not the case. I noted this a while back in documents from state exchanges who were growing more and more concerned that CMS was losing control of the situation.  From this initial post on the subject [click to enlarge] is this fascinating report from the Colorado Exchange on Sept 13, 2013:

The 3rd issue notes The [Federal Data Services] Hub had just completed stand alone testing! End to End testing was yet to begin – and this is Sept 13? They ran out of time, and that is poor technical management. And then they deployed anyway – and that is political stupidity.

But an even earlier risk assessment from the Washington State Exchange effort from Jul 2013 pointed to the sane problems:

This “urgent” risk notes the interfaces between the State Exchange and the CMS Federal Data Services Hub [FDSH]. The conclusion (or warning to everyone state and federal) was:

These interfaces and associated systems are critical to the ability of the [Washington State] Exchange to be operational on the October 1 Go-Live date. … HBE [Washington’s Exchange] application processing has a high dependence on the [CMS FDSH] interface. As we noted in our June month-end assessment, CMS (verbally) re-confirmed a mid-August delivery of fully operational FDSH services.

OK, stop right there. In June 2013 Washington State (and probably all the 25 other states with exchanges being deployed) were pushing HHS/CMS to ensure HHS/CMS could meet schedule.  HHS/CMS promised an August delivery of the Data Hub (FDSH).  But we now know from the report from the Colorado Exchange from September that promise was never met.

Washington State goes on to conclude:

HBE will not be able to conduct full end-to-end testing of services until CMS makes this delivery. The probability of an on-schedule delivery of all FDSH services is, at best, questionable – and worrisome.

Look, Washington State is not creating and documenting these risks in isolation. They are being passed to HHS/CMS as well. And they were predicting failure in July.

Conclusion: HHS/CMS knew about these issues and their ramifications.

The one piece of this mess that HHS/CMS defends as ‘working’ each and very time is their precious Data Hub. Sebellius goes out of her way to make it clear the Data Hub is working. But the Data Hub is clearly the problem most noted here! There is something about the Data Hub, it seems to be the HHS/CMS Holy Grail.

As can be seen in this schedule that came out on Sept 13 in that Colorado State report, the Hub was being patched and tested all the way up to “Go-Live”

The Data Hub is on the fourth row under “CMS Required Testing”. Click to enlarge and you will see FDSH testing going on in parallel with end-to-end (E2E) testing. This is a sure sign of a program heading for a crack up.  If you are doing E2E in parallel with stand alone testing of your center element, you are in serious trouble. And it is apparently during this period that this happened:

Days before the launch of President Obama’s online health ­insurance marketplace, government officials and contractors tested a key part of the Web site to see whether it could handle tens of thousands of consumers at the same time. It crashed after a simulation in which just a few hundred people tried to log on simultaneously.

…

The Centers for Medicare and Medicaid Services (CMS), the federal agency in charge of running the health insurance exchange in 36 states, invited about 10 insurers to give advice and help test the Web site.

About a month before the exchange opened, this testing group urged agency officials not to launch it nationwide because it was still riddled with problems, according to an insurance IT executive who was close to the rollout.

How can HHS/CMS credibly claim they had not clue about the situation? CNN has blown the lid off that excuse.

So why do they continue to insist the Data Hub is the one piece working well?

This recent reporting would indicate just the opposite:

Connecticut residents trying to sign up for subsidized health care coverage through Access Health CT, the state’s health insurance exchange, won’t be able to complete the process because of an outage involving the federal system used to verify applicant information, Access Health announced Sunday afternoon.

The system, known as the federal data services hub, is used by the exchanges to verify information including citizenship and income of applicants. Access Health said in a statement that it received notice of the outage from the Centers for Medicare and Medicaid Services, which oversees the systems used for people to enroll in coverage made available as part of the health law commonly known as Obamacare.

While Connecticut does not use the problematic healthcare.gov website to enroll people in its exchange, as 34 other states do, the state’s exchange must still use the federal data hub as part of its enrollment process.

“Customers will not be able to access Remote Identity Proofing, Social Security Administration or Advanced Premium Tax Credits also referred to as subsidies. As a result, consumers will not be able to complete the sign up process for Medicaid or Advanced Premium Tax Credit determinationsm,” the Access Health statement said.

It is so bad Alaska has just put the stop to the whole mess until HHS/CMS can get the damn thing to work right:

Enrollment is suspended until a major issue is resolved, said Tyann Boling, the chief operating officer of Enroll Alaska. The issue is that the premium subsidy calculator for the Alaska exchange is underestimating the amount of the federal government’s portion of the total premium payment made to the insurance companies.

…

Friday Boling said she received an email from Susan Johnson, Region X director for the DHHS saying that the government was working to fix the Alaska subsidy calculator.

The Department of Health and Human Services expects to have the site fixed by the end of November.

There are 51 state Medicaid/CHIP systems (add DC) to interface with, half a dozen federal data systems such as the IRS and SSA (to name two), and 26 state Exchanges each implementing a subset of the Federal Exchange. That totals about 85 major and complex interfaces to work the ‘glitches’ out of.  Not to mention the hundreds of insurance companies trying to get valid data out the back end. Medicaid enrollment data to the states does even not “Go-Live” until this week!

I would wager a lot of the recent crashes have been attempts to fix the Medicaid Enrollment piece – which are adding more ‘glitches’ at each attempt.

So now we get down to the core problem. The wonders of this precious Data Hub were laid out by its author, Henry Chao, Deputy Chief Information Office and the CMS Technical Architect for what has happened. In the initial documents (see here for a primary one) you see two things: this wondrous ubiquitous system seamlessly (never a good word to see in a spec) tying to together around 85 state and federal data systems, and from there producing tailored products (insurance applications) for individuals by state – easy as pie.

The arrogance of such an endeavor is mind boggling. Tie together 85 data systems that are all independently  developed and implemented? Just mapping the data model across these would take 2 years! Each data system uses some ID to identify some attribute (e.g., name, given name, first name,  etc). All this information has to be collated in the exchange so that it can be used to calculate what options each individual has. But of course, it is not just individuals, it is families too, so don’t think one individual per application.

The first step HHS/CMS took in trying to tackle this entire effort all at once – was to tailor their process and technical documents to try and squeeze this 10 year effort into a 3 year program (section 3, page 11):

Given the need to respond quickly to the health reform requirements of the Affordable Care Act, CMS will use the Exchange Life Cycle as a streamlined model to guide and coordinate the development and implementation of the Exchanges. Various organizations will be involved in developing the Exchange IT solutions. Toward those ends, the Exchange Life Cycle accommodates all forms of systems development methodologies. CMS encourages the use of agile systems development methodology and will accommodate agile processes in the Exchange Life Cycle stage gate reviews as appropriate.

Full stop.  This is an enormous undertaking with lots and lots of moving parts. Each of the external systems is under independent development, many are legacy systems. You cannot use an Agile SW Process to tackle this job.  First and foremost you need to define all interfaces and get them on a coherent schedule.  Then you have to model all state and federal sources of data (i.e., define how each one labels common information and create a Rosetta stone to related each existing label in those data sources to a common definition, like “first name”) and then you need to model all data products (each state and each insurer in the state has unique definitions for data as well). Just understanding the format for “DOB” or “Date Of Birth” in terms of whether the day or month comes first is tedious, time consuming work.  But it must be CHECKED and verified if you want to get it right from the applicant’s input through onto the insurance enrollment form.

And of course, data modeling and translation is one of those things HHS/CMS tailored out to save time [click to enlarge]:

R = Recommended, which in tight programs means it won’t get done.

If you look at the above diagram and process, you also need to mentally apply the timeline across the top to see how ridiculous this plan was/is. The source document is dated March 2011.  All four of the purple-colored phases have to be done by October 1 2013 – around 30 months.  And most of the time (more than half) was dedicated to Concept definition through Requirements and Design. Development (3rd phase) did not begin until what looks like 20 months in.  Give it a year at best.

85 interfaces to build and test in 12 months (not including insurance providers)? With no overarching data model to provide a managed Rosetta stone between applicant data, federal databases, state Medicaid/CHIP databases and State Exchanges?

HHS/CMS developed a fictional program, that’s the problem here. They threw in everything they could possibly think of, used the sure-to-fail big bang approach (all at once), shunned critical aspects of the waterfall approach over agile wanderings, and left no time for testing and tuning. Worse yet, I found statements were this was patchwork funded across state and federal programs. And there was no way to hold states to any schedule (says so in the Statement of Work).  From top to bottom this was a fantasy.

If Congress does not hold someone accountable, then all our tax money can and will be thrown down the toilet because even obvious monstrosities of ineptitude like this will go unchallenged. Congress needs to independently investigate what happened and document ALL the lessons unlearned (and ignored). They need to make an example of programs like this which fly on good intentions yet fail on incompetence.

Tags: Alaska, CMS, Healthcare.gov, HHS, Obamacare

The Congressional hearings yesterday went as usual – lot of hot air, lot of politicians posturing and nothing new.

Truth be told, the industry leaders who worked pieces of ObamaCare were 100% right and forthcoming when they testified. They do NOT deserve blame for this fiasco. This mess is ALL on the government organization responsible for developing and launching Healthcare.gov.

A technology effort that pales next to developing and launching a satellite within 3 years to explore the mysteries of our universe:

Discovery seeks to keep performance high and expenses low by using new technologies and cost caps. The cost for the entire mission (design, development, launch vehicle, instruments, spacecraft, launch, mission operations, data analysis, education and public outreach) must be less than $425 million. The development time from mission start to launch can be no more than 36 months. The intent is to have a mission launch every 12 to 24 months.

NASA has the technical resources to perform these kinds of missions on a 3 year development cadence for the same amount of money HHS had to spend on ObamaCare. And NASA does this on many fronts (see here for the Small Explorer Program Missions). So how is it we in the NASA world can build a satellite, its control center and its science data processing systems in three years (plus the website for the public to visit and see all the cool results) and HHS couldn’t launch a little website in the same time with the same money?

Simple:

Obamacare has survived years of political attacks. Most recently, Republicans shut down the federal government in an attempt to repeal it. Yet it turns out that the biggest threat to health reform is the administration’s own incompetence.

There are lots of naive people pointing fingers at the companies, but this mess is the result of government arrogance and ignorance. It is the result of people who feel because they are empowered to monitor an industry (like health care) they are somehow superior in knowledge, morality and overall skill.

It is the arrogance of government bureaucracy not understanding the complexities of large endeavors, and respecting the abilities of the private sector and those on Main Street who work there. Of course HHS could do this – they are the federal government – right? (And they can get you better healthcare for less, without impacting your current insurance and without any death panels).

Even NASA, which has an army of smart, experienced engineers and scientists to scope, monitor and direct its programs, relies heavily on an even larger army of private sector engineers and scientists to support them. Many of us ‘beltway bandits’ work FOR the tax payer, making sure those other, large private sector companies build what is needed on time and on schedule. It is a pool of expertise built up over 5 decades of space exploration.

This is not something you read in a book and then do.

HHS (and CMS specifically) failed because they tried to be something they were not.

They pretended to be a technology program Systems Engineer, Systems Integrator, Systems Test and Systems Operator. Where CMS got the idea they could do all this is beyond me.

And let’s be clear here – ObamaCare is NOT a large complex problem. It is not as complex as a dam, or a nuclear sub, or a fighter jet, or a suspension bridge, or a nuclear power plant, or a chemical processing plant, or a hospital, or an airport, or the power grid or…

You get the point. It was a simple SW system with a web front end.

Yes, you had to integrate information from databases across the federal government. But then you scope your efforts to do what you can and not try to do it all at once and throw it together in the last two weeks. Systems Engineering 101 – scope your work to your budget and schedule, not some pie-in-the-sky fantasy. Or worse, vague political hype.

Also, freeze your plan after detailed design and don’t let anyone make major changes without requiring the requisite schedule slip. Even a Petulant President stomping his foot at the last minute should be put back in his place. Program Management 101. Control the project, deflect outside forces.

I read somewhere the orders to change direction in the last month regarding when applicants had to fill in their information and sign up was supposedly sent to a tester in one of the companies via some word of mouth.

Technically, this is ILLEGAL. The only change to federal development contracts must be through the contracting change process. The government has to issue a Change Request, the company has to bid the impact, the government has to authorize the change through a contract action. No industry engineer can take direction from ANYONE in the government of this magnitude without due process.

I guess CMS just gave the nation a glaring example of why this is the law of federal contracting. So dip-stick decisions like we saw here don’t blow 100’s of millions of taxpayer money because someone panics.

Apparently when CMS testifies next week, someone is going find themselves in deep trouble. Because whoever directed this is in trouble.  And if there is no paper trail for the change, a company is going to get a black eye. I am betting there is a paper trail.

Another troubling confirmation in the hearings is how CMS is still, just now, putting in a testing capability. No wonder the progress has been so slow. They have no way to check fixes before going live. Until then, Americans in need of health insurance are the guinea pigs.

Anyway, you can be assured the heart of this fiasco is inside CMS. When I heard each of the larger contractors had tested their code and it worked (and I betcha they have the documents to back it up) we can safely rule them out. The fact the Exchanges fell apart when CMS tried to test a couple hundred applicants is the final weeks is the last bit of evidence we need to unravel the mystery being covered up at HHS.

The Systems Engineering by CMS had to be abysmal to fail so brilliantly. There are always tuning issues when you first integrate. But we are not seeing tuning issues here. Not in this case.  We are seeing deep and wide design mistakes.

What we are seeing, in the wise words of Ed Morrissey, is the best big government has to offer when it goes beyond its normal, limited reach:

In short, the ACA was the Obama administration’s own bid to prove that activist, large-scale government was superior in innovation and competency. Instead, it has become a signature example of the lack of accountability, incompetence, and rank dishonesty that activist, large-scale government creates and protects.  And that was just on performance.  Despite the 42 months lead time and the outlay of $400 million, the web portal failed immediately, and two successive weekends of repair couldn’t make it work.

The administration lied to us (and itself) when it claimed it could make-over the health care system in America. It lied to us (and itself) when it claimed over and over again everything was on track. It lied to us when it claimed the issues discovered when ObamaCare went live were small and would be fixed.

It lied because it cannot admit government is in over its head and probably has screwed up this nation’s health care for years to come.

Most of those enrollments aren’t in private insurance, CBS’ Jan Crawford reports, but in Medicaid.  The lack of sales in private insurance may mean a collapse of the entire reform program:

More here:

On Nov. 1, the health law’s malfunctioning enrollment system is supposed to send reams of data to states so they can begin placing thousands of people into Medicaid. But state officials say that transfer system has barely been tested and could be vulnerable to technical failures like those that have crippled the broader Obamacare sign-up process.

The people fighting their way through the mess that is Healthcare.gov are the very people who will crush the system financially. The poor, the sick and the elderly.  All the high cost individuals whose needs must be offset with premiums from those who are healthy and young.

Those same healthy young people who are unable to find full time, career oriented jobs after 6 years of liberal wasteful spending and economically destructive policies.

If it was not so horribly sad you would want to laugh at the geniuses who bankrupted the very demographics needed to pay for their signature, liberal debacle!

Tags: Exchanges, Healthcare.gov, Medicaid, Obamacare

Apparently the Administration’s BS blitz over the last 33 weeks is as successful as the ObamaCare roll out itself – in that it is not working. More and more Democrats are breaking ranks and calling for a delay in aspects of the individual mandate. And the same group of amateurs that brought us the failed Healthecare.gov ‘experience‘, and then the totally fictional ‘tech surge‘, are now touting a 6 week delay.

I am going to predict (safely) this 6 week number was pulled from the same place as all that rosy rhetoric on how well the roll out of ObamaCare was going to be, how the issues at roll out where just ‘glitches’, and how a bunch of the ‘best and brightest’ would turn this around in 2 weeks.

The  administration’s credibility is completely shot.

Today I am seeing some really intriguing and well crafted statements in the news. Hints of what is going on behind the curtain of secrecy. First up is Ezra Klein from the WaPo – former ObamaCare cheerleader

BL: … There are two sides to this coin. The numbers of people enrolling and then the problems in processing enrollment information between federal government and insurance companies. If I were spinning for the White House I would say enrollment is up 50 percent! But that’s because it’s up from like 10 a day to 15 a day. I haven’t talked to large insurers seeing more than 100 enrollments a day.

On the backdoor, the 834 connections, I had one client tell me they saw some improvement in the error rate, so I checked with three other clients, and they said they hadn’t seen any improvement.

…

EK: Let’s go back to the 834s for a minute. This sounds like it should be an easy problem to solve. The 834 standard is widely used. It’s not particularly complicated. What’s going wrong? 

BL: I don’t know. This process is decades old. Every union and every self-insured employer who contracts with an insurance company uses it. It’s like a 74 Ford pick-up truck. There’s nothing complicated about it. People in the industry are shaking their heads over the errors they’re getting. They’ve been using this process for many years. No one has ever seen these kinds of errors before. No one has any idea where they’re coming from.

Wow – that is pretty bad.  The system is broke on the inputs and on the outputs. Which means it is broke pretty much all the way through. The 834 messages FORMATS have been used before, I am sure of that. But I am also sure they have never been used in this manner. Too many keep popping out, as if they are being generated at multiple stages in the process. When you read about 5-6 messages coming out per applicant, enrolling, un-enrolling, etc what this tells me is different pieces of the overall system are triggering 834 messages depending on the feedback they are getting as the exchange is trying to build the applicant’s background record. It creates this record so it can identify which plans/options the applicant has to chose from. It goes back to this diagram of the overall exchange ‘architecture’ I found [click to enlarge]:

If different parts of the system are triggering these 834 messages with incomplete, partial or erroneous data, then the entire system architecture will have to be rebuilt from the ground up.

I would love to see what we in the industry call a stoplight chart on the above diagram. A stoplight chart colors each piece of the system red, yellow or green based on its health.

My guess is most of that chart is red. There are a lot of juicy details in the article, but here is the bottom line:

I think the administration needs to ask three questions here. Can they fix it on the run? Do they need to shut it down for a short period of time? Do they need to shut it down for a long period of time? That’s what the new czar is going to be asking.

The fact Obama is thinking 6 week delay in signing up tells me the stop light chart is all yellows and reds (with more reds) and that they have actually shut it down. One team will probably keep trying to make incremental changes, while another team goes ‘off line’ to perform major surgery. The more the system has to be redesigned, the longer the off line major surgery will take. And it will need real testing this time!

Here’s another great source of details from Time. It also has a clue to how ubiquitous the problems must be across the entire exchange architecture:

In mid-October, he went to Healthcare.gov to help a family member get insurance, only to find his progress blocked. When he investigated the cause, he discovered that one part of the website had created so much “cookie” tracking data that it appeared to exceed the site’s capacity to accept his login information.  That’s  the mark of a fractured development team.

In Layman’s terms each development team on each piece of code had to develop as if they were the only code talking to the applicants. Instead of an integrated design were ‘cookie’ tracking data was shared across all software elements, each team developed their own tracking data.

If you want a clear sign of how bad it is, this is it. It means the code is all ‘stove-piped’ – doing what it needs to do to function, ignoring (or ignorant of) overlapping information in other code. And if this code responds incoherently to the same information, then you get garbage out the back end.

Think of it as turn signals in traffic. If some drivers decided the turn signal meant the driver was going to go the opposite direction we would see collisions and endless traffic jams.

Given the size of the ‘cookie’ tracking data problem, just running through this will take weeks. It also means there was not enough detailed interfaces design work between the coders. This must be really ugly.

This next item is simply unforgivable – personal identifiable information being transmitted in the clear:

Even more alarming were the security flaws. An error message from the site relayed personal information over the internet without encryption, while the email verification system could be bypassed without access to the email account. Both security vulnerabilities could be exploited to hijack an account. “Because this is a huge system that people are mandated by law to use, the standard should be higher,” says Simo. “People are going to see it as a high value target.”

That is against the law and a firing offense. This leaves applicants open to identity theft.  When NASA had a breach like this recently they had to cover the people who were exposed with identity theft protection. It was a costly mistake.

Here is another good round up of details.

What strikes me as interesting is we always hear the Data Hub is functioning ‘well’ or doing its ‘basic’ function. The defense of the Data Hub is front and center all the time. Which tells me this was center piece of the system and is very special to CMS. As lead architect and integrator, the Data Hub was obviously someone’s brain child inside the government. Someone who is still trying to salvage their baby. Why else do we always get a rosy picture called out for the Hub and only the Hub?

It may be nothing, but my Spidy Sense is telling me the Hub is the nexus of most of these issues.

I will end this post with some great observations from Megan McArdle and 7 myths surrounding ObamaCare fixes:

4. Bringing in “the Best and the Brightest”: The White House’s use of this phrase to describe the outside help they were soliciting was unfortunate, since it was originally coined by an author describing how very smart, motivated idealists got us into a decade-plus quagmire in Vietnam. Also unfortunate, however, is the idea that the White House was trying to convey. Even if you could somehow assemble a dream team of crack developers and tech managers, and parachute them in to take over this operation, that wouldn’t magically enable the administration to fix this malfunctioning site by Nov. 15. In fact, it would pretty much ensure that the site didn’t get fixed in time. The new team would have to spend weeks figuring out how the site was put together, and who did what, and who they needed to talk to in order to purchase office supplies. And a developer friend, meditating on his brief experience as a consultant, points out that they would have to get all that information from people who in effect just received the following message: “You all suck, and we’re bringing in more expensive, better people to fix your crap. Please help them succeed.”

While outsiders may be valuable for small, concrete tasks and a fresh take on particularly tough problems, they can’t just come in and fix everything. If the contractors and HHS managers who built the federal exchange can’t fix it in the next month, then it’s just not going to get fixed in the next month. Or as the same developer friend put it: “Ramping up new people in a month? Hahahaha.”

Yeah, this one makes me laugh every time too.

Update: AllahPundit over at Hot Air has a good run down of the Democrats starting to panic, and the President 6 week delay trial balloon I mentioned in the post above.

Want to know how bad the ObamaCare website is doing? After House Democrats got a special insight briefing from the administration on the situation, the House Dems promptly freaked out!

“It’s screwed up,” Rep. Charles Rangel (D-N.Y.) said, summing up the whole situation.

…

House Democrats raised several concerns with Cohen, including whether the personal information going into the system is secure and what is being done to reach uninsured people who don’t have Internet access. And they demanded more specific answers to what’s wrong.

…

“If they have it, they’re not giving the number out,”said Rep. Michael Michaud (D-Maine). “We’re just tired of anecdotal answers to some of the problems.”

More here:

“I think the president needs to man up, find out who was responsible and fire them,” Rep. Richard Nolan, D-Minn., said after the briefing. He said Obama should tell Democrats when the problems will be fixed so they can prepare to move on. “You don’t get many second chances to get a good first impression.”

Nolan wasn’t the only one.

“Somebody should be held accountable,” said Rep. Xavier Becerra, D-Calif. “Absolutely.”

So clearly the briefing was not even close to Rosy and Happy. If so them Democrats would be preening and crowing!

And if the Obamacare news was marginal, Dems would have come out and put a happy face on the discussions.

But House Dems did neither. They are exhibiting barely controlled anger instead. They see the stakes. They see the low probability of pulling out of this tail spin. They see the ever increasing likelihood that the administration so botched this roll out it will be the one that puts the stake through Obamacare.

Why? Becuase more people are losing insurance than getting signed up!

House Speaker John A. Boehner predicted Wednesday that by the end of the month, more Americans will have lost their insurance by being kicked off existing health plans than the number who were able to sign up in the flawed online healthcare.gov website.

And the early numbers may back him up.

Color me unsurprised. I have been around too many of these hopelessly damaged federal programs. The fact is they cannot fix this mess in weeks, given it took years to create. Healthcare.gov was DOA on Oct 1. And so far all efforts at resuscitation have failed.

And will continue to fail. These high level managers called in are not going to be able to fix this until they scrap what they have and start over. Hell, it will take them weeks to just get up to speed, and to do so will divert those trying to work the fixes.

But one special wording I have seen over and over again tells me they are still just trying to understand what is going on.  They see the symptoms, but don’t understand the root issues. The wording I see [paraphrasing here] reflects the need to instrument, monitor and identify the problems. No one claims to have the major problems identified and work plans established. No one is even coming close to having an inkling of how long before it is fixed to some minimum baseline capability.

As long as a minimum baseline capability and milestone date are not forthcoming, you can assume they are still hopelessly lost.

This is not new to federal SW programs. CMS was in WAY over their heads, and demonstrated once again technical novices cannot manage large technical programs. They can write policy, but they cannot implement the systems to make them happen.

Why should I be surprised?

Update: Ouch – CNN calls for an ObamaCare Do-Over?

“Tech surge” or no tech surge, CNN reports that still more experts and computer engineers are piling on to the suggestion that fixing HealthCare.Gov’s major problems before the end of 2013 just isn’t a feasible task, and that rebuilding the system from scratch would be the administration’s easiest and safest bet:

President “Mulligan” should be quite used to this given how much golf he plays. But as I have been saying for weeks: this ain’t going to get right any time soon.

“We don’t even know where all of the problems lie, so how can we solve them?” Bhalla said. “It’s like a drive-by shooting: You’re going fast and you might hit it, you might miss it. But you can’t fix what you can’t identify.” …

Tags: Healthcare.gov, Obamacare Website

Apparently the disastrous launch of Obamacare, via the Big-Gov Botch-Job that is Healthcare.gov, has left an impression on the American public. A very bad impression:

Just 12% of people questioned in a CBS News poll released Tuesday say they think the process is going well, with nearly half saying it’s not going well and nearly four in 10 saying they can’t evaluate the signup process at HealthCare.gov.

…

Less than three-in-10 surveyed in a Pew Research Center poll released on Monday say the online exchanges are working very well, with 46% saying they are not.

…

An ABC News/Washington Post poll suggests that  major problems with the health care law’s website may just be an appetizer.

Fifty-six percent of those questioned in the survey, which was released Monday, say the website failures are a sign of broader problems to come, with four in 10 saying they are an isolated incident.

Well, if this is how ObamaCare does websites imagine what they will do with the care of your health!

We are definitely flirting with a tipping point, one that will bring on the dreaded “death spiral” were only the very sick sign up and much larger healthy population holds back – financially imploding Obamacare.

Tags: Dearh Spiral, Healthcare.gov, Obamacare

Update: Ed Morrissey calls BS on Obama and his lame excuses:

The story proves that the White House has spun a false narrative about the failures, an abjectly political spin that wants to take credit for demand on a site they made mandatory for tax compliance.  The failures exist even under the lightest traffic, which means it has nothing to do with traffic at all — as anyone with even a passing familiarity with web portals figured out on Day 1. Even yesterday, Obama held a pep rally to continue blowing smoke up the skirts of Americans rather than do something significant to protect Americans from the disaster.

Why do I get the feeling our President is still a teenager who can’t take responsibility for any of his mistakes, but only brags about his so called accomplishments? – end update

OK, this sad saga of the Gov-Run Botch-Job that is Obamacare’s website is turning out to be truly pathetic. Healthcare.gov was so badly managed and designed it failed to handle a tiny trickle of applicants in what little testing was performed before the Big Crash on Oct 1, 2013:

Days before the launch of President Obama’s online health ­insurance marketplace, government officials and contractors tested a key part of the Web site to see whether it could handle tens of thousands of consumers at the same time. It crashed after a simulation in which just a few hundred people tried to log on simultaneously.

…

The Centers for Medicare and Medicaid Services (CMS), the federal agency in charge of running the health insurance exchange in 36 states, invited about 10 insurers to give advice and help test the Web site.

About a month before the exchange opened, this testing group urged agency officials not to launch it nationwide because it was still riddled with problems, according to an insurance IT executive who was close to the rollout.

So we can now conclude the administration’s excuse it was the ‘unexpected high traffic’ that felled Healthcare.gov was complete BS.  This website was doomed.

Is doomed.

As is Obamacare.

This WaPO article exposes even more issues, more than I care to review here. As does the article at Fox News that provided the link, as does this New York Times piece also linked from Fox. Combine all these issues with the fact the Administration is in full panic and naively trying to throw bodies at the disaster (which will only add to the delays in fixing it) and it is clear we are witness one helluva Botch-Job.

And these are the people you want to manage your health and the health of your loved one’s?

People, wake up and smell the toasted electronics. This is Obamacare in all its glory.

Tags: Healthcare.gov, Obamacare Website

There is a rule of thumb in SW projects, which becomes a scientific law of physics when it is applied to large SW projects for the government. President Obama is about to repeat a huge mistake made by HHS/CMS on the Obamacare Website leading up to its disastrous debut.

Obama is going to throw a lot of bodies at a huge problem – and make matters ten times worse:

The Obama administration Sunday said it’s called on “the best and brightest” tech experts from both government and the private sector to help fix the troubled website at the root of the Obamacare enrollment problems.

Emphasis mine. The HHS statement is quite enlightening to those who know how the4se kinds of announcements are crafted:

Our team is bringing in some of the best and brightest from both inside and outside government to scrub in with the team and help improve HealthCare.gov.  We’re also putting in place tools and processes to aggressively monitor and identify parts of HealthCare.gov where individuals are encountering errors or having difficulty using the site, so we can prioritize and fix them.  We are also defining new test processes to prevent new issues from cropping up as we improve the overall service and deploying fixes to the site during off-peak hours on a regular basis.

Oh my.  The problems must be enormous., This proves the in-house CMS team that pretended to be the system integrator is still in over their head, and this will takes months to fix now that they had to bring outsiders.  [Hint: the best place to figure out what went wrong and how to fix it is to find all those disillusioned experts who left or were pushed out for being ‘too pessimistic’ prior to the debut – they were right you know]

This is all desperation by the administration. It is not the first time this stunt has been tried, but the result is ALWAYS the same. More delays. Bringing in an army of outsiders just added weeks and weeks to Obamacare fixes. The rule of thumb is called Brook’s Law:

Brooks’s law is a principle in software development which says that “adding manpower to a late software project makes it later”.

The same bush-league mistake was made by CMS during the end of the build up to the Healthcare.gov debut:

A Reuters review of government documents shows that the contract to build the federal Healthcare.gov online insurance website – key to President Barack Obama’s signature healthcare reform – tripled in potential total value to nearly $292 million as new money was assigned to the work beginning in April this year.

The increase coincided with warnings from federal and state officials that the information technology underlying the online marketplaces, or exchanges, where people could buy Obamacare health insurance was in trouble.

Did not help then, won’t help now. But one thing is for sure – this sign of desperation means Obamacare is in serious technical trouble. It is clear the incumbents (government and contractor) have not figured out what is wrong. I said days ago this would happen. The team that was so clueless as to implement this mess was never going to figure out how to fix it.

One of the most glaring indicators this is true is this line in the HHS statement:

We’re also putting in place tools and processes to aggressively monitor and identify parts of HealthCare.gov…

So, they are going to instrument the SW with logs to figure out where the problems are. I guess they don’t have run-time debug flags to capture performance data and interface data to decipher where the issues are. The fact we are weeks into this and they need to add monitoring tools (or points) is another bad sign of inexperience.

This monitoring capability alone will take weeks to put in place (and test), a week to capture data, and then weeks to analyze the logs to figure out where the problems are. That is 6 weeks easy.

Then add weeks to design some fixes, then more weeks to implement and test. Then a day or two to capture more data.

If all goes as these things always do, the first cycle will be a bust and it will be repeated.  I envision two months to get the first concrete corrections in place. But this will not be enough to get Healthcare.gov where it should be. This will address the first order ‘tall poles’, but then there will be the second order, third order, etc.  Something this bad should need 2-4 rounds of corrective action (each 3-4 months) to get to a decent baseline.

And all of this is before we add all these newbie ‘experts’.  As the logging instrumentation is being put in place, the experts will be reviewing technical documentation, collating findings, debating the issues and solutions, and then attempting to clean up the technical documentation to guide the new fixes. These outside experts need months of work just to get up to speed. And all the time this is happening, the government and industry incumbents will be pointing fingers and doing CYA. The outsiders will be presented a very confusing picture, all the while waiting for real log data. It will be a mess.

I have not even accounted for establishing the test capability mentioned by HHS (the ‘new’ test processes – in itself a major development effort). If they try and fix this by going ‘live’ each time they make a fix, they will consume any good will they have left and Obamacare will be DOA. So they need to set up a way to realistically test it off line.

As I  posted previously (here and here), this is as much depth as HHS/CMS had of their problem space back in March 2013:

Simplistic, naive – and why they had no clue they were in deep trouble. Worse yet, I understand Healthcare.gov is actually copied and distributed to 36+ sites, and is not really a single integrated system. Each state exchange will therefore exhibit different issues and problems, so trying to unravel why something breaks in one state and  then works in another will delay solutions in general.

This announcement is the last sign I need to predict  Obamacare will not meet its scheduled capabilities this calendar year. Which means Obamacare will have to be delayed before it goes into a death spiral.

This has now become Extreme Amateur Hour.

Update: Too funny:

“These aren’t glitches,” Klein said on Morning Joe on Monday. “The website, to a first approximation, simply isn’t working.”

He explained that the more fixable problem facing the website was dealing with traffic. The bigger problem, according to Klein, was whether the right information was being sent to insurers after users enroll, including messages that users hadn’t yet enrolled even if they had.

Update: WaPo poll shows obvious repercussions of failure on the Obamacare Website (Healthcare.gov) – Concern over medical services:

Fifty-six percent of Americans say the Web site problems are part of a broader problem with the law’s implementation while just 40 percent see the Web site problems as an isolated incident.

Yeah, well if you can’t build a website, why would we trust you to do something like diagnose a medical condition, administer medicine or do life critical surgery?

Tags: Healthcare.gov, Obamacare Website

Major Update At The End

In my last post I assessed the technical challenges and issues with the launch of Obamacare. In that post I presented the clear signs of a government program technically in over their heads. I pointed to this chart of the core information traffic cop (the Federal Services Data Hub) as a clear sign CMS was blissfully naive of the sheer complexity of what they were attempting: [click to enlarge]

This simpleton concept diagram completely glosses over the challenges in design and testing needed to make Healthcare.gov work. Screw this up and nothing can fix the problems without a complete restart. What I exposed previously was the technical truth hidden behind the child-like simplicity of this chart:

When I see diagrams like this I see a technical project in serious denial and headed for a crack up. As I noted before, the right side is really something like 50 state Medicaid/CHIP systems and the left is the 24 State Based Exchanges. The right side also has all those Federal systems the HUB has to query for each individual [applicant].  The Hub uses a mush of messages, emails and files to interact with these entities, adding to the impossible complexity. And it translates a lot of unstructured data between all these outside systems.

…They show 6 entities, but the reality is 26 SBEs on the left, 60+state and federal systems on the right, and millions of transactions coming in to build a file for each of the 17 million applicants.

The group inside HHS responsible for this debacle is CMS. And CMS is clearly not staffed or experienced enough to manage something of this complexity – if this is their view of the problem in March 2013. Less than a year before getting ready to Go-Live!

Continue Reading »

Tags: Healthcare.gov, Obamacare, Rollout

Buckle up Ladies and Gents – this is going to be a long post. I have been scouring the internet for clues to the ObamaCare debacle to see if I can figure out how bad it is, and how long it will take to fix. This is basically what I do in my day job. I come into troubled, large federal programs that are heavy on distributed computers (most times some of the computers are distributed in space around our planet or in our solar system, but in the end that is just a Honking Large Wide Area Network (HL-WAN)), and I uncover where the programs are malfunctioning. This allows the programs to focus on how to get right, which I help them do as well.

In the case of ObamaCare’s Healthcare.gov and its failure to launch (or even get off the pad), I am handicapped by the fact I don’t have the technical spec, schedules, test cases/results and other information I use to do my analysis. And usually in a situation like this, there are many versions of these as the program realizes they are going to smash into the wall. First by dumping capabilities (like corporate health care plans), then by dumping tests, and then by just plane old cutting corners and pretending every thing is all right! You can watch the entire thing spiral out of control through the updates made to these program artifacts.  But sadly I don’t have access to all of them, just some snippets

This tale spans many years, and inklings of what went wrong have been hinted at by the experts in recent reporting. One thing is for sure, if the price-shock cover-up was the catalyst to this meltdown, it opened a major wound on a system that was probable not very robust (i.e., stable) in the first place. Think of this panicked need to hide the premium and deductible costs from individuals as the last straw, not the sole or primary problem.

I understand the panic. If you do the math, you can figure out quickly that healthy, young people are going to be paying out the nose for those who are older and sicker – because that is the whole house of cards ObamaCare sits on. Income redistribution! Just wait until we have to cover all the illegal immigrants as well! Then ObamaCare’s roughly $10,000 annual deductibles for a family of four along, with nearly $12,000 dollars in premiums a year, will look damn cheap!

Can anyone figure out which is less? $22,000 a year for health insurance and co-pays, or paying a fine and sticking the $22K  in a CD? Even low interest is better than losing that much scratch!

So what happened?

Continue Reading »

Tags: Healthcare.gov, Obamacare, Rollout