I must admit I have not devoted any time to understanding the real technical issues behind healthcare.gov. What little I know is from interpolating and extrapo

I must admit I have not devoted any time to understanding the real technical issues behind healthcare.gov. What little I know is from interpolating and extrapolating what I read here and elsewhere. One impression I got is that this $600+ million dolar website's authors tried to do it all. I don't get that at all. So, here's what I would have done. This is completely sit-of-the-pants. I'm sure it has holes. Nothing that couldn't be sorted out by applying real thought to the problem beyond this quick and admittedly faulty definition: My approach would have been to first develop a specification for an API all insurers would have to implement. They would be required to have a full implementation of this API in order to participate in the service. Now you have hundreds of teams working for you. This would cost almost not taxpayer money. The next step would be to develop an automated test suite to test for API compliance. Open source it and release it. Setup a method through which this API could be used to certify compliance. Perhaps this would be an insurer's portal in healtcare.gov. Upon certification they would receive an expiring token identifying the plans submitted as being fully compliant with the API. More on this later. Now everyone knows what they have to do to communicate their plans and how to make sure their API is fully compliant. No tokens. No participation. Each plan has a token. The token is also the GUID for each plan. Unit and regression testing are your friends. Insurers would do their own testing and they would be forced to continue to guarantee compliance by means of the tokens expiring at preset intervals (a year?). Next the API would be released for anyone interested to implement health insurance browsing sites. Yup, let entrepreneurs battle it out for best-in-class discovery services. You would have hundreds of sites pop up with all kinds of really good solutions. You would then publish another API anyone could use to actually communicate with government servers and "book" insurance. Now you have a potential of tens of thousands of people working for you. And still virtually zero cost to taxpayers. If that's too open, perhaps the plan browsing sites simply redirect you to a government site for the actual booking. They pass the token for the plan that was selected and a secure government site takes it from there. Not done yet. I would also hold a pre-release contest with cash prizes in the range of $1,000 to $100,000 for faults found during penetration testing of the government booking site. Release the code to the .gov site and let hackers mount massive attacks from every angle. Do this until top hackers agree the site is pretty damn hard. Give the top ten contributors cash as well as some kind of a presidential recognition at the White House. In other words, make it very public and very prestigious. Money and time well spent. Once there, load test for something in the order of a million simultaneous users. The site must be built with elastic capacity as it will have to be able to manage insane traffic for a few months and then scale down to a more reasonable baseline. Then open the doors. However. This does not happen all in one shot. Segment the population around data centers. Perhaps a couple of states on the east coast and a couple on the west. Announce it across all media. Schedule additional population segments across a period of a few months in order to average out a reasonable load on the system. All independent browsing sites would have API access to the schedule. They could then save your selection and email/sms you when your turn comes up. In other words, decouple the act of browsing and researching plans from actually booking it. And, at the same time, utilize a mechanism through which the rate of booking per unit time might be controlled. The browsing sites would simply not be able to forward to healthcare.gov unless it is your time slot. Now you have a situation where you simply can't have a hundred million people hitting healthcare.gov. One could further segment booking by implementing time slots based on other criteria. For example, the last digit or two digits of your SSN. Yet another approach would be to offer a limited number of booking time slots per hour. Browsing sites, through the API, would have access to this information. This means they could provide a virtual appointment system where you pick the time and date that is most convenient for you to actually book your plan. If a slot is available you are in. Otherwise you are offered alternatives. With this you could easily throttle the number of people who hit healtcare.gov per unit time. Again, healthcare.gov would NOT be a browsing site. You'd have to go through private sites for plan discovery. Once booked, healthcare.gov would --via a pre-published API-- forward a completed and validated application to the insurance company. I am sure further checks and balances would be required. And, as I said above, this game-plan surely has holes. It is seat-of-the-pants, I am coming up with it as I type. No way it is perfect. However, there is one thing I know: The general idea here is to leverage the free market and private enterprise in order to delivery a massively better product. I realize this goes counter to the ideas the current administration must have about how a country ought to be run. However, if this healthcare disaster has done anything at all for all of us is to potentially prove, once and for all, that central planning and management by government is a horrible idea. This is exactly how everything is done in government. We simply don't get to see it and experience it in daily life. With the ACA there was no way to hide it. This has been and continues to be a very unique opportunity for the American public to really see how bad government is about specifying, planning, managing and executing anything at all. If this makes people understand the fallacies in that school of thought this could very well have been the best $600 million we ever spent.