Welcome to Our Forums. Once you've registered and logged in, you're primed to talk football, among other topics, with the sharpest and most experienced fantasy players on the internet.
Asking whether the Public Sector or the Private Sector is best suited to handle this problem avoids the question of whether it's even possible for one entity to actually do so. You can all argue back and forth for your one or the other, but, perhaps, the answer really is neither.
That really wasn't the reason. The Anonymous Shopper portion just got put on the back burner because it was lower priority than getting the actual enrollment piece up and running.
I'm not privy to the software development aspect of this, but you fail to consider that there are 50 states here which means the potential for 50 different sets of criteria. We have apps that have double/triple that lines of code total in our world today. We just garnered another 50,000 lines of code in a project that to the end user is a simple link to their 401K account. Describe what you mean by "process flow". I have only been able to register an ID and passwd and when I log in I get a blank white page with two tabs at the top that don't work, so I haven't even been able to get into the app. What makes it "look" like it wasn't planned properly?The requirements definitions went through 7 major revisions, I have no idea on the dates of those changes. On top of that from what I read each of these 55 contractors were running their own data models, I severely doubt there was any automated integration tests and if there was I bet the coverage was weak.
That person that wrote the article you posted is still a joke, 500 million lines of code
The process flow of the site is really bad, no idea what kind of architecture they are running behind the scenes but it looks like it was not planned properly. If they really spent 3.5 years and over 500 million dollars (a dollar a line!) this is one of the worst managed projects I have seen.
See my other post describing one bad design decision.
Your understanding is wrong. When someone signs up an 834 transaction is sent to the Issuer and they return a confirmation.
Each State was able to dictate their own Essential Health Benefits. It was the States that have different requirements not the Issuers.
So you are stating if a plan shows up for the user's county and they apply to that plan they can be rejected? If not then I am not wrong, you are only confirming what I wrote that there is a standard that can be sent to insurance providers.
That's all fine and dandy, collect all of that upfront and design the site appropriately, that's part of the design process, it should not impact the signup process at all, it's just something that needs to be appropriately designed and implemented in the UI prior to launch, this isn't rocket surgery.
That's what I thought....it's scary what kind of misinformation is out there. When people start in with the "well it should be easy enough to......" I usually tune out because they haven't a clue what is going on behind the scenes. Heck, even being in the industry it was difficult for me to accept that putting a link on a page took an additional 50,000 lines of code from various groups in our organization.
The user should never see a plan they are not eligible for. What you are wrong on is that there is no two way communication. The user sees plans they are eligible for. If/when the user decides to enroll in the plan an 834 transaction is sent to the Issuer with the details of the enrollment. The Issuer sends back a confirmation of the enrollment transaction.
Perhaps I should have clarified, there is no synchronous 2-way communication, there is no approval process, there is no confirmation that the user sitting at his desk in Idaho needs to wait for. I'm sure these 834 transactions can be queued up and processed offline. The fact that the site did not associate my (online) profile to the plan I signed up for until a week later hints that this was probably the case, and implemented poorly at that.It would have been a nice "feature" if I was given a confirmation page saying, thanks for applying through Healthcare.gov - the plan you selected will not show up in your profile until we complete processing your application, we'll send you an email to keep you updated. As it stands the only email I got was part of the signup process and that was it, no snail mail either from the insurance company telling me where to send my check for the first monthly premium either, maybe in another month someone will contact me.
As The Commish said we were dealing with the government and it wasn't as cut and dried as that. The final market rules didn't come out until March of 2013.
I.E. I just sent you some ####....did you get it?? Yes, I got your ####, let's move on.
I think you are buying their spin, it clearly was a design decision and there was no requirement to order the signup process to go through the expensive qualification process prior to viewing the plans (i.e. there was no filter placed on the plans due to qualification).
Would it be safe to assume whoever was in charge of this knew about the issues before they rolled it out? Or did they maybe ask for the wrong updates? I'm sincerely curious how this became such a bad roll out and everyone seems surprised about it.
His company had a hand in parts of the app. I'd take his word on this trainwreck over any of the nonsensical sites out there just guessing what happened and/or making up crazy political angles to feed the fray.
I'd be willing to bet a year's salary that they knew exactly what was going to happen and went with the deploy and pray method.
Except there's nothing crazy about the motivation in hiding the increase in premium costs and the plans aren't filtered based on input from the subsidy qualification process negating a reason to qualify prior to showing available plans.
Off the top of my head, I can't think of another website ive been to recently that didnt have an anonymous shopper option. If a site I ended up at didn't have it, I would leave immediately. I realize this situation is different, and I'm not doubting there's a chance it's true, but it is awfully suspicious.
Your transfixing political agendas onto a developer though...what's the point in that? I guarantee they were given a functional design doc or maybe a technical design doc and went by the requirements. As a developer you don't have the luxury of just changing requirements in the interest of app efficiency. You code the fastest solution to the requirement given. You can go off and harp on the politicians for making the requirement such, but that's where it should end.
Ummm, hello? I'm blaming the govt. The contractors have nothing to gain in hiding the increase in premiums particularly when it hurts the performance of the site.
Oh, yeah, they had to know some parts of this were going to be a bad thing. I can see the load testing getting past them (I've seen many, many rollouts get burned by overload), but basic items like logging in, creating an account, ensuring that data doesn't get corrupted through the site and to insurers. How could you possibly go live without having tested those?
This post fills me sadness because it is completely filled with ignorance.
Seems like something that might have made sense to customize to local needs at the state level rather than a one size fits all federal level. Did anyone thing of that option?
I was never laid off.Now that you're back to work shouldn't you be busy buying more $50 bullets or something?
Trust me, I know what is spin where this is concerned, probably better than this HHS spokeswoman.
States were offered large federal grants to design and build their own Exchanges. Many dragged their feet, hoping that the Supreme Court would strike down the ACA. When that didn't happen they were left scrambling and many decided just to go with the Federal Exchanges.
Just last week, I was saying to someone that it's been at least 10 years since I've heard an actual "busy signal". When was the last time anyone else got one? I think I saw it on one of those lists of "things teenagers have no idea about", along with blinking 12:00 on a VCR and how to load a typewriter ribbon.
I gave an electronic image optimization workshop at a higher education conference in Kentucky last week. On the fly, I brought-up healthcare.gov, grabbed six images off of their home page, and optimized them, properly, for on-screen display. Same dimensions, same quality of imagery (i.e. no additional "lossy" being applied to those .jpgs), etc. My computer did it for about three minutes while I did some Q&A. Once it was finished, we determined that if healthcare.gov would have used those six images in place of the six images live on their site (everyone agreed that the new, optimized image files looked identical to what is live), the healthcare.gov servers would have saved 248.3 GB in bandwidth. With a "g." In the first 24 hours the site was live. An average of more than 10 GB/hour of bandwidth NOT needing to be transmitted from their servers.I'm all for Barrycare but I work in large scale online hosting for gov't and the company that set all this up really did screw the pooch royally IMO. For starters I would guess they barely load tested at all, and I can almost guarantee their database architecture is complete ####.
Should have let me do it
Yep, that site was a total amateur job, $600 million my ###. 2002 called they want their code back.I gave an electronic image optimization workshop at a higher education conference in Kentucky last week. On the fly, I brought-up healthcare.gov, grabbed six images off of their home page, and optimized them, properly, for on-screen display. Same dimensions, same quality of imagery (i.e. no additional "lossy" being applied to those .jpgs), etc. My computer did it for about three minutes while I did some Q&A. Once it was finished, we determined that if healthcare.gov would have used those six images in place of the six images live on their site (everyone agreed that the new, optimized image files looked identical to what is live), the healthcare.gov servers would have saved 248.3 GB in bandwidth. With a "g." In the first 24 hours the site was live. An average of more than 10 GB/hour of bandwidth NOT needing to be transmitted from their servers.It's not a problem exclusive to (big) government. 99+ percent of web developers just say "send me the .jpgs" and have little/no clue how image files are actually constructed. And most graphic designers just do whatever Adobe's CS suite tells them to do in saving/exporting for the web. And Adobe couldn't care less about image file size or bandwidth consumption...as they've told me so to my face at another conference I presented at 3-4 years ago.I'm all for Barrycare but I work in large scale online hosting for gov't and the company that set all this up really did screw the pooch royally IMO. For starters I would guess they barely load tested at all, and I can almost guarantee their database architecture is complete ####.
Should have let me do it
Thumbs up their ###es...thumbs up their ###es. When something that would take most web hosts/developers under an hour to complete would probably save TBs of bandwidth from zipping around the planet every second. Racking up data consumption on our phones and tablets for n-o-t-h-i-n-g.
Wait, you mean the site is built by Canadians and the contract did not create American jobs?
You mean back when he had an unbreakable supermajority in both houses? When Democrats ran everything?
