Note: written October 2nd, 2013 (CGI rumor reference added Nov 7th)
Why is healthcare.gov such a disaster? The short answer is that the people who were charged with making the exchanges work faced a problem somewhat akin to disentangling a herd of klingon porcupines in full up Vulcan pon farr mode: thousands of players, hundreds of personal agendas, truly torturous approval processes, conflicting agendas at the top, and an almost total disconnect between the real complexities of the system and the beliefs of those managing the procurement, development, and implementation processes.
Boil away all of the technology and competence issues and what you're left with is the core problem: a fundemental lack of clarity about what the exchanges were actually supposed to do. Everyone involved below the very top of the political pyramid was consistently told that the exchanges were about increasing consumer choice while reducing consumer cost, but from the first RFI (pre-qualification requests for information from bidders) onward everyone involved in the process had to work with directives whose most obvious effects seemed to be the opposite of this.
Similarly all involved during the initial vendor selection processes were consistently told that the deadlines for product delivery were legislated and corespondingly inflexible, but those with real experience understood that the stated deadlines could not be met and that some accomodations would inevitably have to be reached.
One immediate result was that companies whose collective experience qualified them to bid on the work generally understood where these conflicts would lead and that, combined with persistent rumors that the fix was in for CGI, pushed most to either pass on the opportunity or offer only pro forma time and materials bids with no fixed deliverables -thereby leaving only those more willing than capable to pursue the business.
Once the key players were in place the dominoes started falling. Both HHS staff and vendors had their expectations confounded when major decisions on how the exchanges would work, who they would serve, and how hundreds of conflicting rules would be resolved were withheld until after the 2012 election - and when these rulings came down in early 2013 they generally confounded the design assumptions made by lower level staff feeding briefings and other materials to the higher level people actual attending the project's promise meetings.
As a result a pattern of increasing disconnect developed between those charged with doing work and those nominally responsible for project delivery - while the people at the very top of the decision making process directed major business process change without legislative referal and were given, in turn, wildy over-simplifed and optimistic briefings by senior staff selecting both what they wanted to hear and what they wanted to pass on from below.
Some early powerpoints stress, for example, the magical role of something called MOM - message oriented middleware. MOMs are software that stores extensive information about the data formats and related protocols used by each of a list of sources and then uses that information to accept data from each source, reformat it to a central standard for storage, and reformat it again to the standards required by those using it - basically MOMs speak Manderin to Chinese and Russian to Russians while storing intermediate translations in English.
Thus many of those attending early promise meetings (mostly senior HHS, procurement, and vendor officials) seem to have thought MOMS magical - and they are, provided that your project is run by wizards and takes place in Wonderland. In reality, this is one tool among many, critical to operations but sufficiently standardized to be unimportant amid the human and process complexities characteristic of the design and implementation phases.
Unfortunately the filtering processes through which a few hundred pages of briefing notes compiled by technical people at the bottom of both the buyer and seller's organizational structures had been distilled into a few pages of notes on one side and a handful of powerpoints on the other, selected both what one side wanted to hear and what the other wanted to sell - thereby misrepresenting a massive business change problem as a relatively minor software development excerise.
The actual software development and implementation for the exchanges should indeed have been relatively simple - had the developers chosen to use an entirely server based system all might have been well with this aspect of the process. Unfortunately they didn't - chosing, instead, to make the project roughly two orders of magnitude more difficult, costly, and time consuming to build and operate by adopting the windows client-server model under which users download applets to their PCs which then interact with remote servers to collect and process the information needed.
To get some idea of how utterly stupid this choice was for a busines environment in which no two policies are the same, no two users are the same, no business rule is either universal or cast in stone, and everything involved: users, policies, players, business rules, and third party software can change without warning, consider that a centralized system is largely unaffected by third party changes and internally generated change is tested and applied in one place to one piece of software - while the client server approach requires applet customization and maintenance for each combination of browser, OS, and release level in common usage, and every change on either the client or server side of the transaction triggers a new round of applet adaptation, testing, and downloading.
Thus the much publized exchange failures occuring during the first week were largely the result of the complexities induced by the client-server decision. Basically it turned out that the servers couldn't handle the downloading at the rate required for the typical Microsoft PC to retain the connection, the typical home or office PC couldn't handle either (or both) the volume of applets downloaded and/or the load they put on the system, and the applets themselves often failed due to software incompatibilities on either the client PCs or third party servers.
The software issue was, however, the easy part of the business of getting the exchanges going - the business components are both much harder and much costlier - what we can expect, therefore, is that the connection and service failures will quickly die out of the headlines only to be very gradually replaced by much more serious reports of people who thought they had bought insurance but didn't, people whose insurance bills don't match expectations, people who experience misapplied and miscalculated subsidies, and, above all, people whose insurance claims are rejected because what they thought they bought isn't what they bought.
When the exchanges first opened there were heated claims that the main technology contractor had parlayed a $93 million contract into $634 million in billings - a roughly seven fold multiplier that has since been widely repudiated but is probably in the right ballpark for total contractor billings. Unfortunately, however, this guess covers only billed federal costs - the real costs, to HHS, to the states, to the insurers, and to the health care services industry are far higher.
Much of the insurance industry still uses 1970s COBOL code held together with layers of change, decades of patches, whole orchestras of standards, hundreds of quickee PC applications, and utterly inflexible data processing policies - $200+ million dollar data centers employing 300+ professionals are dirt common in the business. All of these organizations received "thou shalt" letters as part of the exchange implementation effort - and their collective cost in understanding and meeting these demands will have easily exceeded CGI's real take, whatever it was, from their federal contract.
The same thing is true, albeit to a lessor extent, of everybody else in the system - from the relatively minor software and process adaptations imposed on individual practitioners to the major change and co-ordination efforts expected from the medicaid, medicare, and VA administrations the data flows offered by the exchanges imposed massive costs on everyone else.
To really get a handle on total direct cost would require sending out hundreds of interviewers to ask thousands of businesses to find time to make good estimates of their costs - but the nearly universal experience of large organizations facing this level of business process change is that technology costs represent an almost negliable part of the total. A typical $100 million SAP installation at a Fortune 1000 company will, for example, produce 2- 3 billion in lost, written off, or postponed sales and another billion in manpower and reorganization costs as the business re-aligns.
In business undertaking this kind of trauma can be worthwhile if there's a reasonable expectation that three to five years out the company will have exceeded its original sales and be humming along with better decisions and lower operating costs driving greater profitability. In the case of the Obamacare exchanges, however, it's difficult to see how anyone cynical and experienced enough to reach the senior levels of government could ever have thought the process they embarked on would produce either technical or business success. In fact, had the political level set out to impose a process designed to produce both expensive failures and mass confusion on consumers, on the health care and insurance industries, and on affected federal and state agencies from the IRS and INS to the FBI and HHS, they could hardly have done better.
Paul Murphy, a Canadian, wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.
- Log in to post comments