Private Sector Rides To Rescue Of

Handful of Web insurance brokers will start enrolling people in plans within a month, but backend coding problems could continue to delay completion of policy purchases.
This is where things get sticky. It has been widely reported that insurance carriers have had trouble getting enrollment data from FFM, and to a lesser extent the state-run exchanges, because files were either missing or corrupted. One reason for these problems, according to an article in Modern Healthcare, is the federally run exchange's use of the HIPAA-mandated 834 specification for transmitting enrollment data electronically. Many health plans are not used to receiving 834s because they get enrollment data mostly from employers that are not HIPAA-covered entities. So their backend systems can't accommodate this format.

Another explanation is offered by Daryl Chapman, a consultant to employers and health plans, on Bob Laszewski's Health Care Marketplace and Review blog. Chapman notes that although the 834 standard has been around for decades, there are a lot of variations in how it's used. So middlemen are needed to "translate" enrollment data that employers send to health plans in the 834 format.

This pretty much squares with the experience of providers and plans during the transitions to the HIPAA 4010 and 5010 transaction sets. The plans' backend systems couldn't receive the data perfectly in the specified format without some tweaking before it reached them.

Laszewski told InformationWeek Healthcare that the arrival of the private Web brokers to help the federally run exchange is "great news." However, he said, "HHS [Department of Health and Human Services] needs to fix its backend problems before it allows thousands or millions of applications to begin pouring through. The backend enrollment problems -- the so-called 834 problems -- are so significant that the health plans are not now able to process any volume of applications. Without a fix to that problem we are just going to see tons of enrollments hit a brick wall and, worse, create all sorts of serious customer service problems for the health plans."

It took eHealth years to create all of the necessary interfaces to send enrollment data to the health plans because of all the disparate and outdated systems they used, Gibbs noted. Moreover, he said, many carriers are still not geared up to receive 834 transactions directly. But despite all of these barriers, he believes that CMS and its contractors can get most of the backend transactions "ironed out in the next few months for the vast majority of plans."

Meanwhile, eHealth is talking to the state-run exchanges about letting it enroll people in those states as well, he added. Maryland and Washington State have been receptive, he said. By year end, he expects a handful of states to be aboard, and he predicts the rest will make deals with private Web brokers by the next open enrollment period.

Gibbs also offered a couple of interesting insights into what went wrong with In 2010 he recalled, eHealth was the original contractor on the government's Health Plan Finder, which was designed to be part of FFM.

"We had 62 days to implement our site," he recalled. "We made the date and it worked flawlessly. We mostly just borrowed our existing technology. But CMS eventually wanted to own the technology and we didn't want to give it to them, so they shifted the contract over to CGI."

In the run-up to the Oct. 1 launch of, he said, "There was no testing involved. The code was complete, there was some unit testing done, but there was never any heavy system testing. And what the public is seeing now is the system testing, and it's going to take a couple of months to get the kinks worked out."