My pal Ed Lyons, an IT project professional, (known by some here as RMG poster “edfactor”) writes an extensive autopsy of the Health Connector failure. I advised him to use a less opinionated tone but he said it’s not intended to be a magazine article but as a resource document for a wide range of people, including the press, and he wanted to express his outrage. His ultimate goal is better government, especially when it comes to IT issues. He feels, based on our local high tech economy, that Massachusetts should have the best government IT infrastructure in the country. The failure of this project not only wasted a lot of taxpayers dollars, but harmed people that needed help.
It’s a monster read, but very interesting.
Please share widely!
that messed up healthcare.gov, which basically failed on the same day – October 1? In the case of healthcare.gov, the GAO has concluded that the federal government failed, among other things, to adequately plan and oversee the website or its launch. The GAO report noted that the website was “plagued by undefined requirements, the absence a required acquisition strategy, confusion in contract administration responsibilities, and ineffective use of oversight tools.” In other words, bad planning and management all around.
Will read Ed Lyons’ report about the MA Health Connector. It’s fascinating that so many of the same things apparently went wrong with both of these websites.
I agree that the Lyons report might have been more effective had it adopted a less polemical tone. It is, nevertheless, a significant accomplishment. However, the report doesn’t include anything like sufficient technical detail for a reader to judge whether this was a routinely failed software project, or whether incompetence or malfeasance played a role.
Large software projects can and do fail. Not every Hollywood movie is either an artistic or a financial success. Not every surgical operation succeeds as planned. Software development frequently requires original research, research sometimes goes awry, and our collective knowledge of large-scale software development is limited. The project should not have failed, but failure (or late delivery, which in this case amounts to the same thing) would be far from unprecedented.
There’s simply not enough technical meat in this report to understand what went wrong. What substance there is — notably, the number of coding standard violations — is suspect. This density of coding standard violations strongly suggests that things like indentation and bracket placement disagree with the standard. These coding standards are easy to measure but are often inconsequential.
Consider, for example, two students who have turned in term papers to their teacher. The assignment said that each essay should be neatly typed, with 1″ margins, and should be five pages long. Student A hands in a very neat paper, laser printed, but she used 3/4″ margins because that’s what she usually uses and she forgot to reset them in the final version. Student B hands in a splotchy mess with coffee stains, hand-written insertions, and many folds and creases. Neither student has followed the assignment correctly, but clearly student A has done a reasonable job, and student B has not.
As it happens, software developers in general — and Java coders specifically — become attached to formatting customs that resemble Student A’s margins. For them — especially when time is tight — it may be better to adhere to their customary format in the initial code and to reformat mechanically for delivery, rather than to get into the habit of the customer’s coding standards. That’s not a big deal, and enforcing the contrary is (a) chickenshit, and (b) inefficient. Enforcement is a good way to alienate your coders, and with tight deadlines you really cannot afford to lose people. (Replacing people late in a software project is seldom an option; this is one important way in which software development differs from heavy construction.)
On the other hand, if you’ve got very junior people, or a motley crew that doesn’t really know what they’re doing, they may throw together a pile of code with no particular plan or structure. This is something you can still get away with in small projects and in school, but it can lead to disaster in a big project. There’s a clear suggestion in the report that this was the case here, but there’s no actual evidence that I can see.
Show us the code, explain what’s wrong with it, respect that some of us have technical expertise too, and *then* we can castigate appropriately.
I wonder how much Java code Jean Yang knows.
Other states managed to get it right.
Our state messed up in a major way.
nt
And I appreciate Ed Lyons as a true moderate Republican counterweight over at RMG, and invite him to join us at BMG (where he will likely get a less hostile reception!).
I also think it is a report written in a readable way that is accessible to the layman, though I would agree a technically specific diagnosis would’ve been nice as a footnote or add on. While it doesn’t delve too deeply into the cause of the initial problems, it asks a lot of important questions about the contracting process, the failure of our government information officials to quickly address it, and the failure of the Gov. or Legislature to approve a fix in time to secure the site. The broader questions about which IT professionals we use, and how our state, the hotbed of technical innovation, can get outplayed by Kentucky on usability and consumer satisfaction in the implementation phase are incredibly important.
The usability of healthcare coverage via a functional website is a key component of our state based and national reforms, I had few issues with the IL website, but can sympathize with a lot of people who were in desperate need of getting coverage and had to jump through hoops to get it. Obviously single payer is the overarching ‘solve’ for that problem, even though I am shocked few politicians up to the President recognize it’s simplification is it’s greatest asset. During my brief tenure as a health care industry consultant we found that people were overwhelmed by choices, choice was the last thing they wanted, they needed a navigator, a real live person to walk them through enrollment, which Kentucky eagerly provided leading to this deep red state hostile to the President and ‘Obamacare’ loving it’s ‘KY Connect’ program by overwhelming majorities. We should look to other contractors and other models, and finding a way to better utilize local assets in the IT realm to make a more usable government. The easier government is to use, the more often it’s services will be appreciated, the better it is for government in the long run. But the party of government should be dedicated to governing well, not in the sloppy fashion we did here, denying problems, and failing to appreciate the needs of our main consumers.
“Large software projects can and do fail. Not every Hollywood movie is either an artistic or a financial success. Not every surgical operation succeeds as planned.”
Wrong analogies. Artistic and medical pursuits are working in an environment filled with unpredictable variability. Software “engineering” is named as such because it is so predictable. Like building physical structures according to standardized building practices, tools and outcomes are able to be well-defined and before a project gets underway. This is why it is incredibly rare for buildings and bridges to fail (putting aside unforeseen outside ruptures like earthquakes). But if they do fail, you can certainly castigate based on poor results. A mother who loses her child in a bridge collapse does not need to know the precise point of failure. Everyone saw the damn thing go down (I experienced a fatally buggy UI in the first months of the rollout). You’re demanding Lyons give more technical details, when he sacrificed countless hours to create the only comprehensive timeline of how this software project disintegrated in terms of management, realism, intra-departmental communications, and public relations, and so on. Thank you Mr. Lyons!
It doesn’t sound to me as though you’ve spent much time building or cleaning up after enterprise-scale systems like this.
With all due respect, and as someone who has been paid to be a “software engineer”, “senior software engineer”, “principal software engineer”, “consulting software engineer”, and several other variants over the past 30 years or so (I was a hardware engineer first, and I have a BSEE), I want to most graciously correct your apparent misunderstanding.
The “engineer” in software engineer has about as much meaning as its counterpart in the title “sanitation engineer”. A software engineer is a PROGRAMMER. No more, no less.
The work needed for a project like the failed health connector is NOT predictable. Let me offer a simple example. When a bridge is being designed, especially using an approach that has never been done before, the structural engineer nevertheless has a deep reservoir of theory and practice to draw on. The properties of the materials are well-understood. The physics are well-understood. Since various factors like traffic and wind loads are hard to estimate, a substantial safety factor is engineered into the new bridge. THAT is why it is incredibly rare for new buildings and bridges to fail.
There is NO comparable theory for software that plays the role of physics and chemistry in building bridges. NONE. You won’t find an analog to even simple equations like F=MA. There are NO comparable analogs to all those manuals full of material specifications. One shop says “Java”. Another shop says “Python”. Another says “C++”. If you think there is some objective turn-the-crank analysis process that results in, for example, the choice of implementation language, then you are mistaken.
A far better analogy is music. A large-scale system is more like creating and performing a symphony for a large orchestra — in a setting where the performance hall must be designed and built, the orchestra recruited and rehearsed, the music written, charts composed, everything practiced, the publicity created, tickets sold — the whole kit and kaboodle.
Projects like this frequently fail.
I agree with you that more details about the code probably won’t help change the things that need to change. It doesn’t matter what language the code is written in, if the CUSTOMER doesn’t understand what the provider means when the provider says something like “there is not time to write or perform unit tests” or “the interconnection of these two subsystems has not been exercised”, that is the fault of the customer.
The provider is not likely to write “the current system doesn’t work”. The provider is more likely to write “the desired behavior of the current system has not been demonstrated.”
These projects failed because they were improperly specified, managed, and overseen.
The Health Connector failure is, probably justifiably, the Titanic of our state’s IT disasters. But also worthy of mention are the recent misadventures at the Department of Revenue and the Department of Unemployment Assistance. These led the Senate Committee on Post-Audit and Oversight to take a hard look at how the state procures its IT systems. Maybe Ed Lyons has some thoughts about these as well.
is that coding by government deadline is sort of asking software developers to put a square peg in a round hole — it’s not the typical standard they operate under.
Most big software companies don’t have the sort of hard deadlines that the government does — and instead would only release the product when it was ready, or at least a whole lot more functional.
It may make sense to craft legislation in the future that involves major software creation in a way that sets deadlines based on when projects are finished rather than a hard deadline set by legislation.
no requirement in the Affordable Care Act that the federal healthcare.gov website go live on Oct. 1, according to testmony before the House Oversight Committee. The decision to launch that site on Oct. 1 was apparently made by the White House and was based on political considerations, even though testing showed the site had numerous problems.
Deadlines in software development are always a difficult issue, but they’re not uncommon.
First, as here, the software may be a component in a larger system, and that system may need to ship on a fixed date. The computer in your 2015 model car has software, and that software simply has to be ready in time for the 2015 model year. If you’re writing a patch for a grocery store’s cashier software, that patch had better be ready at 7am tomorrow when the store opens; if it isn’t, you’ve got long lines and unhappy managers. If you’re writing an application to print badges for the MA Dem Convention, you really need to get those badges printed before the convention! Apple sells a lot of phones over the holidays; if your team is updating (say) the Calendar application, it’s got to be ready for the holiday season.
Finally, lots of people use deadlines simply to manage projects and personnel. We may not care very much whether the new payroll system gets going in April or waits for June, but we do care that it gets finished eventually — and so we write a contract with a bonus for delivery before April 15 and a penalty for delivery after June 30. None of these dates really matter in themselves; they’re objectives. (Once the contract is finished, of course, the dates take on real if completely synthetic importance.)
What DOES need to be considered, but appears not to be the case here, is technical risk. Sometimes, you negotiate a contract and everyone looks at some step — say “have the Web server get the current price from this other system” — and everyone says, “oh, that’ll take a couple of days.” Then you start to write it, and you suddenly realize, “Wait: that’s not going to work at all!” Perhaps the system you need to talk with only speaks Greek. Perhaps it’s really slow — and your system can’t wait. Perhaps it’s only right 99.99% of the time: if it’s handling 20 customers a day, you can live with that, but if you’re handling a million customers in the two weeks before launch, you’re going to have a lot of unhappy people.
So, sometimes a project blows up the schedule because some unexpected technical issue turns out to be much harder to solve than anyone anticipated. That doesn’t appear to have been an issue here (although, apparently, it WAS an important issue in many healthcare.gov launch woes).
Software deadlines are always artificial, sometimes absurd, and almost always a pain in the neck. But they’re part of the landscape.
A later comment from Lyons:
there are deadlines with software, but the issue with many parts of the ACA is the implementation timelines and a normal software development cycle is vastly different. Often times new products are piloted with partners for a year+ to work out the kinks. Internal QC efforts alone would take months. The October 1 implementation date falls squarely on the project managers and maybe they had enough pressure that they had little choice.
is actually coding by contract. I presume we have a contract with this group and all of this – deadlines, deliverables, expectations, scope, etc should be in the statement of work. Most big software companies have hard deadlines. If you don’t have deadlines – nothing gets finished.
…to subliminally advocate for Don Berwick in your diary title? I couldn’t help but notice that for a diary about health coverage, an issue with which he is strongly associated, you came very close to saying all means all!:)
One of the things I find vexing with political discussion is that very complicated issues are too often boiled down and given short answers. Health Connector doesn’t work? “Oh, CGI mucked it up and no one told us.” If no one really questions that, the story moves on. I thought Ed did a great job getting down a lot of facts and supporting sources.
It is the changes in scope which presumably doomed the project, but I’m having a hard time understanding what these changes were and what was the reason. The coding violations statistics (“increased by 53% during the past month”) are not believable, they are likely the result of an automated code scanner, and these kinds of scanners are simply not very good at giving a true scale of the correctness of the code.
The report is however pretty credible where it talks about who was in charge, and where the responsibility lies, management-wise.
1. They were late in starting the project. Lyons makes a good case that the wrong vendor was chosen and the wrong governance for the project too.
2. The Commonwealth hired an audit firm to track this project because they knew they lacked the expertise to track progress on their own, but the audit firm started screaming from the second month of the project that it was in trouble. They continued screaming until the end. No one listened.
3. CGI, the vendor, announces in January 2013 that it cannot make the October 2013 delivery. So the schedule is changed and an easier-to-build-but-not-as-good health connector is then agreed to. However, the vendor again announces in April 2013 that they cannot even do that.
4. Management is a mess here. The UMass Medical School is mostly managing this but clearly don’t know what they’re doing. IT professionals within the Health Connector working for the state (Devonshire, Hetherington, and Lemoine) don’t seem to have done much about the mismanagment.
5. The project is rolled out in a manner guaranteed to fail:
Lyons explains this well, I think:
Managing software is hard, designing software is hard, building software is hard.
Specifying WHAT a complex system is supposed to do, providing concise and consistent examples of “use cases” — “When I do this, the system should respond as follow …”, providing reasonable priorities, understanding that a given amount of money can generally buy either functionality or schedule but not both, and understanding that it takes nine months to make a baby even if nine women are involved — these are extraordinarily difficult responsibilities that fall on the CUSTOMER of any complex system like this.
I am not surprised that our state government found itself unable to meet these responsibilities. Massachusetts has been dismantling state government for decades. We have long since tossed out the “gray-beards” who have the combination of management expertise, technical chops, and scar-tissue to effectively manage the design and deployment of complex enterprise-scale systems like these. Those rare men and women have long been able to command far higher compensation packages and have far more freedom to actually do the right thing for a very long time now.
It doesn’t help that a certain very powerful Democrat attempted to bypass at least some of this in order to line his own pocket, was indicted, convicted and imprisoned, and is still being defended by Democratic Party players as a victim who was treated unfairly. Any manager who has the political smarts to successfully deliver projects like this also, by construction, has the insight to recognize that the corrupt party machine that holds both the power and the purse will greatly complicate the effort. Nearly all conclude “life is too short”. The impact of our pervasively corrupt state government goes well beyond sheer dollars and cents.
I am more surprised that ANY of our state IT projects work AT ALL.
Software being hard, it is the failure of management here that is even more outrageous. If something can fail, you keep your eye out for that failure and get ready with Plan B. For example, if the site wasn’t going to work at all — and, by April 2013 that was pretty obvious — then Massachusetts was going to need to staff up a non-automated means of enrolling people in health insurance.
That didn’t happen.
(This is one of the reasons I’m allergic to hope-over-data approaches to the world:
I have to agree with Lyons that the executive branch had multiple failures here. The timeline section of his piece (section 6, I believe) is worth reading for that. I had the impression, as I was reading, that he wrote it in a manner that you could read just one part of his report without reading the others. So maybe readers who are daunted by the huge size of his report could consider hopping to the time line.
Years ago (late 70’s) I was studying poli sci and the discussion was on blame. In democracies other than the US, leaders (at various levels) said “it’s my fault” and resigned or otherwise suffered consequences. Already 30+ years ago we saw the emergence across the US of the blame-free government official (other sectors, including business have this as well). This has evolved today where not only is there no acceptance of responsibility, there isn’t even a requirement to tell the truth, apparently because that would mean actually accepting responsibility.
Might this have to do with our contentious, adversarial, two-party system? Any admission of fault is immediately seized upon by the other party as a failure in ideology.
So in other words, Democrats in MA admit that they screwed up in implementing the health care software, so this obviously means that we should reduce unemployment benefits, get rid of gun laws, and eliminate the corporate income tax.
…How did we get this far?
I do not think that the two party system is adversarial either by design or in fact: If anything the Democrats are not adversarial enough… being not adversarial at all… And the GOP are only adversarial.
So, adversariality (izzat a word) is part of it, but not, I think as a result of being a two party system. I think it a result of hard hitting dumbasses in the GOP (Brown, Rmoney, etc…) having no other successful approach.
I think they forgot that our health care reform was already popular and widely supported, so popular that every statewide Republican from Brown to Baker has to say ‘Obamacare is the problem, Massachusetts has a good system already”. So, perhaps it was a defensiveness on the part of the laws backers to deny the problem was happening, but, in doing so, that just made it worse, and now it is lumped into the broader problems that Obamacare had with it’s launch.
Something progressives have to wrap their heads around, while Ezra Klein, Hayes, and Maddow can make sophisticated arguments praising the great design of the policy, if the website doesn’t work, if it’s hard for people to use, and if it prevents people from getting covered-than the policy isn’t working properly. As the part of government we should be willing to admit when we make mistakes, demonstrate a willingness to actively face them and fix them, and then make sure they are actually fixed. We can’t restore trust is we feel that the need to defend the policy actually outweighs the need to admit there are problems with it. Stating, the website didn’t work or the implementation was flawed is very different from stating the law was a bad idea.
Technically our MA Congressional delegation could have been opposed to Obamacare on the grounds that our state was already there. While there is an argument that they were thinking of people in other states, MA has paid a very high price for that vote.
Note that we’re only talking (here) about people needing insurance and $$ so far. I went to a presentation from AIM on employer issues and all the MA issues have been fixed in the years since implementation. Obamacare undoes all that and a lot of legislation is going to need to be passed (good luck with that) to fix issues that affect (and by that I mean are disincentives to desirable behaviors) business.
We’re not even talking an election cycle here. If the problems were in 2012, sure, push it under the rug. Completely understandable, but why in 2013?
As Lyons points out, this left a lot of people who needed care, operations, procedures, and drugs hanging for months. It is not a good thing. And as Grossman pointed out in the debate, the progressive agenda demands excellent management. We liberals are the ones claiming government can do good. If government fucks up instead, liberal initiatives become a very hard sell.
I’d feel much better about this if the Patrick Administration came clean about it.
They haven’t. I’m disappointed.
And no, blaming CGI does not cut it. The state government should have known months ahead of time that this project risked going off the rails.
*
I suspect you haven’t read Lyons’ work. It’s really worth taking a look at along with the audit reports that are also available. Vox wrote about this a couple months ago too.
I’m not asking that question to imply that the government shouldn’t provide a health care exchange; I’m asking it to explore the idea that we have so thoroughly gutted government that we are completely at the mercy of the private sector – we have no knowledge, no basis of comparison. Private contractors sucking on the government have been found, time and time again, to be focused 100% on their profits.
How does a homeowner make a decision as to which company to give you a new roof? How does a homeowner know if the roofing company has done things right, other than if there is an immediate leak? One way is to look at past performance – but with government projects, there is no past performance. Another way is to have a general contractor review the roofer’s practices – but with government projects, the general contractor is often a faceless corporation with no reputation to stand behind and no responsibility for failure.
Imagine that you’re a small business owner and you want someone to write you an app for your business. How would you go about doing it? How would you know, up-front, that you won’t fail? How would you know, up-front, that the job is being done on-time and is being done right? It’s a puzzling situation to be in, especially if you have no knowledge of the technical details.
If the state is going to hire private contractors to do custom work, shouldn’t the state have longtime employees who are qualified in the subject area being contracted?
… the government to adjudicate legal cases? Judges and prosecutors navigate seriously tricky legal terrain on a daily base and, for the most part, succeed. Even during the worst of Jim Crow the argument wasn’t that the government was incompetent but rather that the finest efforts, best arguments and highest caliber legal minds in fact existed but were determinedly denied to a subset of the population.
How different is “IT” from jurisprudence? The legal system has shown that excellence, by and large, can happen in government…. Why is this a difficult transfer to “IT”?
as well as the delivery of the service is different. What if all traffic citations were handled online? I bet that would break as well.
I don’ t know what the answer is- there are clearly organizational issues (is there a statewide CIO?), budget issues, experience issues, procurement issues. It starts with a good plan however. The Health Connector did not.
Most large cities have law departments which have in-house expertise at litigation, both as plaintiff and defender. Our District Attorneys offices are responsible for prosecuting criminals. I don’t see how that comparison is valid.
The comments are painful
https://www.facebook.com/healthconnector
… on the governmental decision making involved but it is not an ‘autopsy’ on the technical details of the Health Connector project.
The report itself suffers from the same defect as the project (as far as I can tell) in that it pointedly fails to define what ‘it’ is, settling for ‘website’ as shorthand without ever going into detail about the longhand. GSI and UMASS seem singularly unable to produce but I’m hard pressed to think of anybody who would be capable.
It’s not just a website. If it was only just a website I, or any of the several dozen other “IT” professionals who post here often, could have a working one up in an hour. Give us a week and it’ll look sleek and have all the bells and whistles… From what I can tell It is supposed to be a website that connects to several, perhaps several dozen, different databases spanning the insurance industry, the medical industry, the CommonWealths existing efforts and the Federal Governments nascent attempts at a passive-aggressive effort to avoid single-payer. All of these databases use different standards, regulations and practices and some are cutting edge, while others, I’m sure, use show stopping legacy equipment that was old when Obama got his first pimple. They each, also, each have to be accessed and made use of, I’m assuming, under the auspices of HIPPA and/or other layers of privacy protection… all in the context of governmental promises, backroom dealings and shifting alliances.
It may, in point of fact, be an example of the most complex and complicated project ever undertaken not just in scope but an in context also. “Panama canal” ain’t in it. “Just software” ain’t the half of it. The java-monkeys who wrote the code probably don’t understand the law. The legal flunkies who know the law probably don’t know from databases. And that’s BEFORE you get to the holy wars of code and compile…The gorillas who built the separate databases probably thought the other DBA’s truly were actual gorillas. The grad student at UMASS who, at the time, was in the process of dumping PERL to use Ruby (a web programming framework) probably thought that coders at GSI who used PHP (another web programming framework) was for chimpanzees. The PHP chimps probably thought all Ruby practitioners had a secret crush on the Java monkees, who (almost by definition) disdain all others. Meanwhile, most of the actual work was likely done by a lone C programmer in one 39 hour stretch… and all the remaining efforts went towards re-factoring the C code to, first, C++ then Java and then bolting the web framework du-jour to that… to no good effect….
… OK. I’m back. I’m ok now. Just had a flash-back to previous projects which had one or more aspects of the above… I cannot imagine a project that had them all… Yrrcchh…
The banking industry went through some wholesale integration that had some of these same issues. Those old enough to remember the names Shawmut, BankBoston, Fleet and BayBank might be surprised to know they still all exist under the umbrella of Bank of America. And when I say they still exist, I mean that (in most cases) literally: the computers and accounting systems were only incompletely merged and the present BankAmerica isn’t a single seamless entity but a collection of the older systems uneasily co-existing. It is for this reason that Bank of American has a real problem trying to collect and in some instances foreclosing upon homes for mortgages they either do not own or were completely paid off. It’s the banking iteration of the joke… “You had one job…”
The point is that, even in the ‘free market’ integration of separate systems is often thought of as more easily done than it, in truth, turns out to be.
That’s one answer.
was a fundamental misunderstanding of the actual complexities involved in what the Exchanges had to do, especially given the needed interaction with the IRS database (to verify correct income subsidies) and INS to prove citizenship. Heard much talk about how this would be like shopping at Expedia or Amazon by the higher level politicians selling the exchanges. Of course, when you click on the “Buy Now” link on your Amazon shopping cart, Amazon processes your payment and away you go. What Amazon isn’t doing before checking you out is tapping into the IRS tax return database to make sure that your income is sufficient to make the purchase, and then tapping into INS to make sure that you’re a citizen of the US. My gut feeling was that these little “details” were glossed over by people who had no idea how complex it is to actually tap into a bunch of separate legacy databases NOT set up to get millions of outside hits. Kind of like that computer illiterate boss that we’ve all had who just thinks you “push a button” and the answer pops out.
the number of users who would be attempting to access the site at one time on Oct. 1, according to the testimony to the House Oversight Committee of one of the top IT officials with the federal Centers for Medicare and Medicaid Services. The website was designed to be used concurrently by 50,000 to 60,000 users. On Oct. 1, 250,000 people tried to get onto the site simultaneously.
It’s kind of stunning that the possibility of high usage of the site was so grossly underestimated by the planners and managers, given that the Affordable Care Act was arguably the top initiative of the Obama administration.
Ed Lyons must have put a huge amount of time into this investigation, and I certainly appreciate the view of someone with this level of expertise. However, I think somervilletom’s comment above is better at answering what to me is the key question:
If Massachusetts and Connecticut were both involved in the original collaboration, why did their site work when ours didn’t?
In a bit of related news, it was just announced that the CEO of the Connecticut project will be moving to CMS to supervise healthcare.gov.
I also remember reading some of these stories and feeling my blood boil when hearing about providers turning sick patients away, or telling them to go “get your MassHealth straightened out.” Somehow I get the feeling that if he were still in private practice, Dr. Berwick would not have been one of those people!
Ed, after looking into all of this, do you support single payer health care? This whole mess with the exchanges surely makes it look way more attractive to me.
caused me extraordinary angst as I spent tens of hours online and on the phone trying to buy health insurance, including before and immediately after major surgery and while in rehab. It could not process my application and when I called to say please withdraw my it so I can just buy insurance I was told they couldn’t withdraw it and the only way to buy insurance was through the system.
I ended up being put on MassHealth which has meant that I could not get the healthcare I wanted or see the providers I wanted to see. And, as it happens, it has been a challenging year for me health-wise. I’m facing another surgery and had to find someone to take MassHealth.
Our healthcare system has become a competitive business except with more complexity, waste and inefficiency than any competitive business could run with. If I wan’t convinced that single payer — Medicare for all — was the way to go the failure of the healthconnector and what it has cost personally and in dollars to the state — e.g. everyone — has convinced me.