At a very raw level, given how late in the game it was before the programmers were able to get started (obviously not their fault when CMS (sic, should be CMMS but isn't') took on the integrator role), obviously the project is going to copiously burn money. Pity the other constraints caused it burn quality (going by the old "pick two of time, money and quality").
"but thinking about it this morning I realized that they probably had to integrate with the systems of (every|many) major existing healthcare provider in the country to actually make this work as desired. I can see now where that wouldn't be cheap."
Actually, that's one part that shouldn't have been expensive for the government, except in support services. As in they should have standard, sane input formats for policy details and output for enrollees that any participating insurer could adapt their systems to. IT must be a core competency for a successful insurer, since everything? they do aside from marketing is IT mediated.
There's been some reported troubles with getting the policy details right, although I think what I heard was about one or more state exchanges---with guaranteed issue and community rating it's rather more simple than normal, but then again a customer's FICO score can and I gather generally/always is used in the pricing. At the other end the insurers aren't reporting trouble in getting and parsing the data, just in it being self-evidently incorrect, e.g. some customers being reported as enrolling and canceling several times. Which they're addressing, while the volume is so low, by calling them up (everyone wants to complete the circle anyway).
On the other hand, you know it took a while for everyone to hammer out those formats, especially the input one. The output should be pretty simple, just needs to have all the particulars correct. E.g it would be a bad sign if an insurer was getting people enrolled in a policy they didn't offer.
I feel that this integration effort is probably exactly where most of the expense came from. There's more to it, of course, but I can see where that one part was probably the large heap of their troubles.
I was not thinking rationally about this whole issue when it first came up and thus didn't measure my previous experience when I was thinking about the issue, but I actually have worked with healthcare systems integration before. Even with all government inefficiency/management aside (we were a private company), interfacing with healthcare providers is an extremely complicated and painful business.
For instance, there is a HIPAA standard interface protocol for things like Eligibility and Benefits and Claim Submission, and most (though still not all!) health care plans have some sort of system through which you can interface for that information - though often it's hidden behind miles of red tape and fundamentally different implementations for various custom fields, and different interpretations of the meaning of many fields. That alone is painful, and that part is supposed to be "standardized".
I can't even imagine the state of healthcare provider's policy estimation systems, particularly when it comes to interfacing with them. It's speculation on my part, but I imagine that each healthcare provider would likely have to have their estimation systems tied into. I wonder how many even had it exposed in such a way at the start of this project that you could tie into it, and how many of them had a wide variety of custom inputs to take into account in their estimating. Though you are right that perhaps the new law allowed/forced them to simplify this estimation process, in which case each of these providers likely had to modify the ruleset of their ancient systems before the integrators could actually work with it. Yeah, I could see even a simplified ruleset for policy pricing and eligibility as being a major factor in slowing down this process.
I certainly wouldn't have wanted to be a software developer on this project, thinking more about how bureaucratic and inefficient both the government and healthcare providers are. I still feel like, even then, 500 million is a dubious number - and I'd like to see where that money went. (how many people were employed on the project and for what cost, what were they being charged for hardware and datacenter(s), etc...) But as a software engineer, I would certainly not have enjoyed working on such a doomed project regardless of whether the money was as well spent as possible or if it was lining the pockets of those further up the chain.
"but thinking about it this morning I realized that they probably had to integrate with the systems of (every|many) major existing healthcare provider in the country to actually make this work as desired. I can see now where that wouldn't be cheap."
Actually, that's one part that shouldn't have been expensive for the government, except in support services. As in they should have standard, sane input formats for policy details and output for enrollees that any participating insurer could adapt their systems to. IT must be a core competency for a successful insurer, since everything? they do aside from marketing is IT mediated.
There's been some reported troubles with getting the policy details right, although I think what I heard was about one or more state exchanges---with guaranteed issue and community rating it's rather more simple than normal, but then again a customer's FICO score can and I gather generally/always is used in the pricing. At the other end the insurers aren't reporting trouble in getting and parsing the data, just in it being self-evidently incorrect, e.g. some customers being reported as enrolling and canceling several times. Which they're addressing, while the volume is so low, by calling them up (everyone wants to complete the circle anyway).
On the other hand, you know it took a while for everyone to hammer out those formats, especially the input one. The output should be pretty simple, just needs to have all the particulars correct. E.g it would be a bad sign if an insurer was getting people enrolled in a policy they didn't offer.