“834 Errors” still dog Healthcare.gov
One of the issues regarding the technical troubles with the healthcare.gov website that has received some attention in recent weeks, and even more so over the last few days, has been that of errors in 834 files.
These are the files transferred to insurance carriers that contain pertinent data on the enrollees. (For a better understanding of what the 834 form is, the Washington Post has this good backgrounder).
Some of the files have reportedly contained data that was incorrect – for instance, the names of children appearing as spouses – while others have contained duplicate data, or there was no file at all. Without an accurate 834 form for an enrollee, an insurance carrier essentially cannot complete their enrollment.
While the numbers regarding the issue have reportedly improved, reporters have recently tried to obtain more specific information about the problem.
Obama administration officials have been getting angry questions from reporters by refusing to even try to estimate how many enrollment forms are going out, or how many of them are right.
HealthCare.gov and the enrollment sites for state-based public exchanges are supposed to send out “834 Initial Enrollment Notification” transaction notices when consumers enroll.
Carriers have reported a high percentage of the 834s seem to be inaccurate, because of problems with the information consumers have entered, information from other sources, or programming errors.
The issue boiled over into Thursday during a White House press briefing, when a reporter told White House Press Secretary Jay Carney, “CMS, in these daily calls, is still very opaque.”
That reporter was Major Garrett, National Journal Correspondent-at-Large and Chief White House Correspondent for CBS News.
Garrett pressed Carney about the reported issues with 834 forms and the challenge it presents for enrollees who may think they’ve signed up for coverage but might not actually have been enrolled. Garrett was trying to get some more precise figures on the rate of such errors, noting that CMS has not been offering any detailed information in its daily conference calls. “CMS, in these daily calls, is still very opaque,” Garrett said.
The remainder of that exchange is below.
(Relevant video clip starts at 35:40 and ends at 41:58)
There’s no question that since the launch of healthcare.gov on October 1st there have been a number of different types of problems with 834 forms, as there were problems with other aspects of the site, and we believe that many of these were the result of initial technical problems with the site and have been fixed with our improvements and upgrades over the past several weeks. Our priority is understanding results that issuers are getting, because of the fixes put in place, and fixing any remaining bugs that are causing problems, and working to make sure that every 834 form, past and present, is accurate. You know, because what’s most important is working to insure that those who want insurance starting in January can enroll and begin their coverage. So CMS, as I think I said the other day, will be reaching out directly to consumers by email and by phone who’ve already selected a plan to let them know to be in touch with their plan and to pay their first premium.
So there’s a lot of effort going into insuring that whatever issues there were and whatever bugs remain with 834 forms are resolved in time for insurance to kick in on January 1st. As I think I hinted the other day, the universe, when you talk about the early problems with the backend, there were so many problems with the website that, unfortunately, but we’ve acknowledged this, not that many people were able to enroll in October, and so the universe of the people who in their enrollment had issues with their 834 forms or the backend is not all that large, which is actually an inadvertent or unexpected positive out of a very negative situation in October. So what we know is that the fixes that have been put in place over the past several weeks, including some major fixes over last weekend, have brought about a significant improvement across the board on the site, including with the 834 forms. We are working with issuers regularly to look at the results of those fixes and also to address the remaining bugs that exist.
The language you just used was very general. Just as it was in the early stages of the website’s problems. You’ve now become more specific about error rates, time, improvements on the front end of the website – CMS in these daily calls is still very opaque, asked directly what is the magnitude of the problem, what are the error rates you’re seeing in 834s, no information whatsoever.
I think they’re working with issuers on the specific problems and data but I think you have to understand it’s not like one…[crosstalk]…the answer I think broadly is yes, and we know without a fact [Ed. Note – I think he meant either “for a fact” or “without a doubt”] that the problems that existed on the backend have been diminished greatly, no question, with the fixes that have been put in.
Then why not have the same transparency about tabulating that, as you have with some of these other issues?
When you talk about finding out specific percentages, it’s not, these are bugs that affect individual aspects, so to collect data on it is not necessarily as simple as ‘what’s the error rate for this broad array of or series of small problems that may have affected 834 forms.’ What we know is that there were significant problems with the whole website including the backend and that over the course of the time that the teams were in place to make improvements to the site through software fixes and hardware upgrades that those problems have abated although have not been completely eliminated. I think, Major, as those who’ve noted, we’ve been pretty candid about the self-inflicted problems that have been created and we’re candid about the fact that even though we hit our goal for November 30th and the site is functioning as we hoped it would that there are still problems and we need to address those.
But the challenge, the transparency, is to work on behalf of people who may assume that they’ve enrolled and they have fallen into a category that insurers are now commonly referring to as “ghost enrollees,” people who believe that they’ve enrolled but they’re not in.
Sure, and Major, what I can tell you is that we know every person who has enrolled, or believes he or she has enrolled, we – the CMS and others, and every one of them is being contacted and making sure that their enrollment is accurate and that they will, if they sought to enroll and have insurance on January 1st, that they will have it.
A spokeswoman for the Centers for Medicare & Medicaid Services has since provided some expanded information on the numbers related to the 834 forms issue, according to BenefitsPro.
[Julie] Bataille came back today [Friday] with a few more numbers and an explanation for the lack of better numbers.
CMS believes that about 25 percent of the forms sent from Oct. 1 through Nov. 30 had errors, and that about 10 percent of the forms now going out have errors, Bataille said.
“This analysis is preliminary,” Bataille said. “We do not have precise numbers at this point.”
Getting the data is difficult, because CMS and its contractors have to go over the transaction data with each plan issuer to come up with the numbers, Bataille said.
The New Republic argues that the 834 issue may not be freak out material, citing several industry experts who have noted the improvements in the relevant errors.
“The enrollment files continue to get better and the new process they put in place this week to deal with the back end issues is making a difference,” says Robert Zirkelbach, spokesman for America’s Health Insurance Plans. Bryce Williams, who is Managing Director of Exchange Solutions for Towers Watson, says “We are hearing reports from insurers that the quality of the 834s being sent from Healthcare.gov is getting better—for example, fewer cases of children showing up as spouses.” But, he adds, “there are still backend enrollment issues to be fixed.”
But the pressing issue is that as more and more people enroll, now that the front-end of the website has been improved, the number of those affected might continue to be of significant concern.
In the end, the CMS spokeswoman suggested that those who believe they’ve enrolled for coverage should contact their insurers to make their payment and to make sure they receive welcome plan information.
(Featured image credit: 12/5 WH Press Briefing video)
Donations tax deductible
to the full extent allowed by law.
Any person is perfectly within reason to doubt any and all numbers, stats, claims, etc., made by this administration.
From a blog post at KevinMD: “Do they think that big customer service issues come January, if the “834″ back-end enrollment are not fixed by then, will be blamed on the insurance industry and not the administration?”
Of course they do!
I hope the big insurers who funneled tens of millions of dollars Obama’s way enjoy the view from under the bus!
ProgrammerBoy here – this is why you don’t roll out big projects to millions of users on day one !
Any time you have an input form being filled out, on paper or computer, by literally hundreds of thousands or millions or many millions of people, either totally untrained (actual enrollee) or minimally trained (‘navigators’), you are going to open up a universe of input errors you never dreamed of.
You need an architecture that is designed from day one for extensibility, like adding error traps / validation tests / handling. As you see data coming in where there is a second current spouse, and his/her name is Spot, and his/her age is 3, you trap that shit.
But what’s really scary about all this is, this whole ACA thing is the biggest data collection tool ever thought up by the control freaks in DC. The way it forces the user to help integrate data from DHS (what ? for health insurance ?), SS, IRS, and a soup of other agencies, state and federal, is scary scary stuff. Count on it that the NSA is capturing every byte of it ‘on the fly’ and storing it.
That’s what competent designers/programmers would have done. But you are making an incorrect assumption here. Competence is nowhere to be found in or around obamacare.
The more I think about it, the more sense the following scenario makes to me:
There was never a real obamacare website.
We are talking about the most basic data validation, folks. And even THAT is missing.
The developers figured, like any half-brained, minimally common-sense-endowed person would, that the law would never survive, so there was no need to really finish the job.
They put up a mock front-end with no back end at all and pocketed the money.
All of this is leading to the ultimate solution… Single Payer where all will be subject to the whim of the little puppet emperor…
Single Payer has been the plan from Day One.
ACA was designed from the ground up to make private insurance impossible, and bankrupt those who tried.
They couldn’t do it overnight like they wanted to, so they came up with a ten year plan.
Are we talking about the same government responsible for programming target coordinates for our nuclear missiles?
Xanax needs to be marketed in salt lick form.
These people are no longer trying to correct this system for the American people, they are trying to shore up Obama’s legacy. When people have mediocre qualities it is necessary to set low standards. With a regulated press trumpeting these low ideals and principles, it gives the allusion of success and allows them to feel superior to the rest of us.
Yep! It’s all about Barry’s ego!
Is it just me, or does it seem increasingly ridiculous that this administration, most specifically Carney and Obama, have to constantly read their responses? They’re always looking down at some paper, I guess. I don’t remember this happening all the time in other administrations. Someone should call them on it. Way too orchestrated. Call me naive.
Speaking as a professional web development project manager, with lots of experience as a developer behind me, I can think of 5 or 6 ways this sort of error can happen. All are easily predictable and easily caught when validating data either before entering it into the long term database, or after it is pulled from the db and while it is being formatted for the 834 output.
Validating user input is literally web development 101 level stuff. Obviously, good (or even mediocre) testing and code reviews were lacking both originally and after they started “fixing” the site.
This site needs to be flushed before even worse failures start to show up. Hypothetical example: A total db dump is done for backup purposes and the db ceases to exist (DROP healthCareGov.*).
This is bad and pretending it just needs a few more little patches and all will be well is crazy.
I wouldn’t be a tiny bit suprised if they send raw SQL straight from the web page to the database(s) without ANY validation.
I’d give you at least even money that the whole thing has already been hacked. And BIG odds that it WILL be.
I wouldn’t be suprised if the hackers already have a nice big FTP ‘sploit in place that lets them send MYFTPCOLLECTORHACK.PHP to every server in the entire food chain. With that name. And hundreds of people have seen it, and ignored it.
Can you say ‘Select * from InsuredPersons’ ?
‘BACKUP’ ? Wassat ?
Isn’t that in the phase 3 specs, scheduled to roll out in 2015 ? Which we won’t get to until 2017 ?
LOL….I thought “Only 834 errors? Really? I don’t believe it is that few.” not realizing that was the back end process form.