Just What Is An 834 Transaction? Why Is It Holding Up Obamacare? How Long Will This Take To Fix?
Jumat, 12 Oktober 2018
Health Insurance Reform,
Insurance Exchanges,
Obamacare,
Patient Protection and Affordable Care Act
Edit
You have probably already heard that Obamacare has as many backroom problems as problems with the front end consumer web enrollment portal.
Insurance companies participating in the new health insurance exchanges are receiving detailed enrollment information for each of the very few people who have successfully enrolled through the 36 federally run health insurance exchanges.
But the masalah is that this enrollment is coming from the government with a very high rate of errors––way beyond anything they can handle manually once the real enrollment volume comes in.
So long as each insurance company is receiving only 10 or 20 enrollments a day––that is what they are receiving now––the high error rate enrollments can be fixed with lots of hands-on effort. If the Obama administration fixes the consumer portal before fixing the 834 problem, the insurance companies could begin receiving thousands of enrollments with high error rates every day. That would bring the insurance company information technology departments to their knees. It would mean lots of new policyholders could have problems getting their bank accounts properly debited, their claims held up, or health care providers refusing to treat them because they aren't on the list of covered people.
So this is a very big deal.
An 834 transaction is technical term for exactly how enrollment information is exchanged, in this case, between the federal government and the health insurance companies.
The 834 transaction represents a computer "benefit enrollment and maintenance document." It is commonly used by employers, unions, government plan sponsors (Medicare Part D, for example), and insurance marketing organizations to enroll members in a health benefit plan. This current version developed out of the 1996 Health Insurance Portability and Accountability Act (HIPAA). So, it has been around for many years.
This process is where the federal government's backroom has come off the rails and is in need of an urgent fix.
To better understand all of this, I called a good friend and longtime colleague in the industry, Daryl Chapman, who has a lot of experience working with large employer and union plans receiving and transmitting health care eligibility information both before and after implementation of the 834 standards.
I asked him a few questions in an attempt to figure out just how big a masalah it will be to fix.
RL:
Are you surprised at what a mess this is?
DC:
During the last two weeks the various media outlets have asked a number of questions, "How could this have been so hard?" "Why couldn't they have used the same people that managed the election's technology?" "How hard can sending files be, we have had the standard file format [the 834] since the passage of HIPAA?"
This just reflects the naivete' surrounding how complex this really is. In terms of the website and shopping experience I am as flabbergasted as anyone that Amazon, an approved CIA cloud storage contractor, wasn't part of the mix when it comes to a shopping experience. Who better in the world?
RL:
But isn't the 834 transaction pretty straightforward?
DC:
It makes sense the government would choose this as the standard for the Affordable Care Act (ACA). The masalah here is that just about everyone uses their own variation of the standard. The law allows carriers to create their own guidance for how they use the standard. Large self-insured plans for example, are not governed by HIPAA standards that created and mandated the 834. There is a cottage industry of firms that translate data for plan sponsors and health plans using different variations of the standard.
It was widely reported that the preliminary standards for the 834s set out by the federal health insurance exchange were first released this spring and that the akibat version wasn't released until summer without adequate time to test. If the feds were truly using the standard 834 transaction, testing and compliance would have been easy. But they created something far more complex, released it late, and didn't adequately test it.
RL:
Aren't having a lot of variations in a standard a little bit of an oxymoron?
DC:
One would think so, but it has been the norm for some time.
RL:
So, really the feds are using a variation of the 834 and they essentially dumped this standard on the health insurance industry late and inadequately tested? That would certainly create lots of data communication issues.
DC:
Right.
RL:
And, I suppose it gets even more complicated?
DC:
Receiving this data isn't as simple as getting an address card from someone via email. You don't get it, click it, and save it. There are lots of data elements and a lot of field variables. Because of this complexity, no one takes a file straight into a production system––too risky. There are variations on the process but every company has some type of validation process. Generally, the 834 goes through an acceptance process, which scans the file and checks for errors. If it passes the data check it uploads to some kind of "model office" where it is tested again and then, if it passes, it goes to production. Although most of that is automatic there are several chances for the file to "error out." Once in production, the file drives the payment system, claim system, and is the source for the list of doctors and hospitals they need to confirm the person is eligible for benefits.
Files still have lots of opportunity to trigger false reports in each of these systems if they aren't accurate.
For example, member data is not the same as payment or cash data (member payments in this case come from two sources; the subscriber and the government). Poor quality data can lead to lots of problems trying to reconcile who the health plan was paid for and who they have on their eligibility system. Very few systems ever connect cash to belly-buttons and even fewer have debit and credit carry forward accounting capability making reconciliation on the fly very difficult.
If the member data is a mess then the cash becomes a mess. When the subsidy cash goes to the carrier from the federal government, the carrier doesn't just get you; they get thousands of member cash files. If there isn't a match, the claim paying process has to be suspended until people with green eyeshades figure it out.
And out in the world where doctors and hospitals live if the data isn't clean doctors and hospitals may not treat you if the carrier file doesn't say you are covered. They may demand payment upfront from the patient until things are straightened out or balance bill if claims aren't reimbursed. That is a particular masalah here because so many of these people will presumably be low-income.
RL:
I suppose the unique nature of the government subsidy system creates a whole other set of headaches since about every person will have different hard dollar subsidy?
DC:
In the case of the ACA, the health plan will use the member data transmitted from the government to bill the member and presumably will invoice the government for the subsidy component. This "split bill" scenario has been a common requirement in programs retiree medical programs and is the hardest thing we do in the industry. The dynamic nature of the subsidy means this invoice amount can change throughout the year. If the member or government remittance isn't what the health plan has on its rolls, the carrier system will suspend eligibility and not pay claims.
The member to cash reconciliation is hard when the data is pristine. With all of the problems occurring in just getting accurate data to the carriers, if cash starts flowing before this is pretty tightly locked down that toothpaste won't go back in the tube easily.
RL:
Did Obama administration officials not understand how hard this really is?
DC:
We talk about the health care system like it really is a system. The decision to build the ACA on top of the Rube Goldberg contraption we call a system was either very naive or a case of using the system you have not the system you want.
RL:
If lots of enrollment starts coming through before we have improved the system to an acceptable data error rate (very close to zero) it is going to be catastrophic for consumers and the health plan's customer service reputation.
So, how long will it take to fix the 834 masalah such that we have an acceptable error rate?
DC:
At least a year.
Earlier today a reporter emailed me the following: "In testimony today, CGI [the primary government contractor for the health law's system] claimed that the problems of insurers receiving bad data was 'isolated' and not a widespread issue. On a conference call with the press, a CMS spokeswoman said the same thing."
Given what we just learned from Daryl, it begs a question: Did no one in HHS or the 55 contractors on this job ever really think this system, that had literally been assembled over a few months and had not been thoroughly tested before launch, was ever going to work?
Given the CGI and CMS comments just today, do they still not understand?
Where were the people like Daryl Chapman when this thing was being built?
Insurance companies participating in the new health insurance exchanges are receiving detailed enrollment information for each of the very few people who have successfully enrolled through the 36 federally run health insurance exchanges.
But the masalah is that this enrollment is coming from the government with a very high rate of errors––way beyond anything they can handle manually once the real enrollment volume comes in.
So long as each insurance company is receiving only 10 or 20 enrollments a day––that is what they are receiving now––the high error rate enrollments can be fixed with lots of hands-on effort. If the Obama administration fixes the consumer portal before fixing the 834 problem, the insurance companies could begin receiving thousands of enrollments with high error rates every day. That would bring the insurance company information technology departments to their knees. It would mean lots of new policyholders could have problems getting their bank accounts properly debited, their claims held up, or health care providers refusing to treat them because they aren't on the list of covered people.
So this is a very big deal.
An 834 transaction is technical term for exactly how enrollment information is exchanged, in this case, between the federal government and the health insurance companies.
The 834 transaction represents a computer "benefit enrollment and maintenance document." It is commonly used by employers, unions, government plan sponsors (Medicare Part D, for example), and insurance marketing organizations to enroll members in a health benefit plan. This current version developed out of the 1996 Health Insurance Portability and Accountability Act (HIPAA). So, it has been around for many years.
This process is where the federal government's backroom has come off the rails and is in need of an urgent fix.
To better understand all of this, I called a good friend and longtime colleague in the industry, Daryl Chapman, who has a lot of experience working with large employer and union plans receiving and transmitting health care eligibility information both before and after implementation of the 834 standards.
I asked him a few questions in an attempt to figure out just how big a masalah it will be to fix.
RL:
Are you surprised at what a mess this is?
DC:
During the last two weeks the various media outlets have asked a number of questions, "How could this have been so hard?" "Why couldn't they have used the same people that managed the election's technology?" "How hard can sending files be, we have had the standard file format [the 834] since the passage of HIPAA?"
This just reflects the naivete' surrounding how complex this really is. In terms of the website and shopping experience I am as flabbergasted as anyone that Amazon, an approved CIA cloud storage contractor, wasn't part of the mix when it comes to a shopping experience. Who better in the world?
RL:
But isn't the 834 transaction pretty straightforward?
DC:
It makes sense the government would choose this as the standard for the Affordable Care Act (ACA). The masalah here is that just about everyone uses their own variation of the standard. The law allows carriers to create their own guidance for how they use the standard. Large self-insured plans for example, are not governed by HIPAA standards that created and mandated the 834. There is a cottage industry of firms that translate data for plan sponsors and health plans using different variations of the standard.
It was widely reported that the preliminary standards for the 834s set out by the federal health insurance exchange were first released this spring and that the akibat version wasn't released until summer without adequate time to test. If the feds were truly using the standard 834 transaction, testing and compliance would have been easy. But they created something far more complex, released it late, and didn't adequately test it.
RL:
Aren't having a lot of variations in a standard a little bit of an oxymoron?
DC:
One would think so, but it has been the norm for some time.
RL:
So, really the feds are using a variation of the 834 and they essentially dumped this standard on the health insurance industry late and inadequately tested? That would certainly create lots of data communication issues.
DC:
Right.
RL:
And, I suppose it gets even more complicated?
DC:
Receiving this data isn't as simple as getting an address card from someone via email. You don't get it, click it, and save it. There are lots of data elements and a lot of field variables. Because of this complexity, no one takes a file straight into a production system––too risky. There are variations on the process but every company has some type of validation process. Generally, the 834 goes through an acceptance process, which scans the file and checks for errors. If it passes the data check it uploads to some kind of "model office" where it is tested again and then, if it passes, it goes to production. Although most of that is automatic there are several chances for the file to "error out." Once in production, the file drives the payment system, claim system, and is the source for the list of doctors and hospitals they need to confirm the person is eligible for benefits.
Files still have lots of opportunity to trigger false reports in each of these systems if they aren't accurate.
For example, member data is not the same as payment or cash data (member payments in this case come from two sources; the subscriber and the government). Poor quality data can lead to lots of problems trying to reconcile who the health plan was paid for and who they have on their eligibility system. Very few systems ever connect cash to belly-buttons and even fewer have debit and credit carry forward accounting capability making reconciliation on the fly very difficult.
If the member data is a mess then the cash becomes a mess. When the subsidy cash goes to the carrier from the federal government, the carrier doesn't just get you; they get thousands of member cash files. If there isn't a match, the claim paying process has to be suspended until people with green eyeshades figure it out.
And out in the world where doctors and hospitals live if the data isn't clean doctors and hospitals may not treat you if the carrier file doesn't say you are covered. They may demand payment upfront from the patient until things are straightened out or balance bill if claims aren't reimbursed. That is a particular masalah here because so many of these people will presumably be low-income.
RL:
I suppose the unique nature of the government subsidy system creates a whole other set of headaches since about every person will have different hard dollar subsidy?
DC:
In the case of the ACA, the health plan will use the member data transmitted from the government to bill the member and presumably will invoice the government for the subsidy component. This "split bill" scenario has been a common requirement in programs retiree medical programs and is the hardest thing we do in the industry. The dynamic nature of the subsidy means this invoice amount can change throughout the year. If the member or government remittance isn't what the health plan has on its rolls, the carrier system will suspend eligibility and not pay claims.
The member to cash reconciliation is hard when the data is pristine. With all of the problems occurring in just getting accurate data to the carriers, if cash starts flowing before this is pretty tightly locked down that toothpaste won't go back in the tube easily.
RL:
Did Obama administration officials not understand how hard this really is?
DC:
We talk about the health care system like it really is a system. The decision to build the ACA on top of the Rube Goldberg contraption we call a system was either very naive or a case of using the system you have not the system you want.
RL:
If lots of enrollment starts coming through before we have improved the system to an acceptable data error rate (very close to zero) it is going to be catastrophic for consumers and the health plan's customer service reputation.
So, how long will it take to fix the 834 masalah such that we have an acceptable error rate?
DC:
At least a year.
Earlier today a reporter emailed me the following: "In testimony today, CGI [the primary government contractor for the health law's system] claimed that the problems of insurers receiving bad data was 'isolated' and not a widespread issue. On a conference call with the press, a CMS spokeswoman said the same thing."
Given what we just learned from Daryl, it begs a question: Did no one in HHS or the 55 contractors on this job ever really think this system, that had literally been assembled over a few months and had not been thoroughly tested before launch, was ever going to work?
Given the CGI and CMS comments just today, do they still not understand?
Where were the people like Daryl Chapman when this thing was being built?
