News
10/25/2013
03:20 PM

Private Sector Rides To Rescue Of HealthCare.gov

Handful of Web insurance brokers will start enrolling people in HealthCare.gov plans within a month, but backend coding problems could continue to delay completion of policy purchases.



 7 Portals Powering Patient Engagement
7 Portals Powering Patient Engagement
(click image for larger view and for slideshow)

The private sector is riding to the rescue of HealthCare.gov, the troubled federally operated health insurance exchange. Five Web insurance brokers that signed a deal last Julywith the Centers for Medicare and Medicaid Services (CMS) are expected to start enrolling subsidy-eligible people in plans that participate in HealthCare.gov within the next month.

That should go a long way toward easing the pressure on the front end of HealthCare.gov, which has encountered significant technical problems in enabling people to sign up for plans. But less-publicized difficulties in sending enrollment data to insurance companies' backend systems could still delay the process for some time to come, a leading expert warns.

At an earnings conferencewith security analysts on Thursday, Gary Lauer, CEO of eHealth, which operates ehealthinsurance.com, one of the leading online insurance agencies, announced, "We continue to work with the federal government to launch enrollment capabilities for subsidy-eligible individuals in the 36 states where the federal government is operating an exchange. eHealth has received the necessary information for implementation of this capability from CMS … But we received this later than expected. We are currently in the process of operating and testing. Assuming the federal exchange is operable, we hope to be able to provide eHealth consumers access to subsidy-eligible plans during this open enrollment period in time for the Jan. 1, 2014 effective date of coverage."

[ Why is HealthCare.gov a mess? Read HealthCare.Gov Woes: Lack Of Testing. ]

In an interview with InformationWeek Healthcare, Sam Gibbs, president of government systems for eHealth, said that the company anticipates going live with that capability "within the next few weeks. A handful of other Web-based entities will be launching at some point. My guess is in the next month you'll see other companies begin to offer subsidy-eligible plans and do the subsidy calculations through the FFM [Federally Facilitated Marketplace], and we'll be one of those."

Besides the national Web insurance brokers who signed up with CMS last summer, Gibbs believes the agency is enlisting additional regional and statewide agencies to help enroll people in the federally run exchange.

A CMS spokesperson told InformationWeek, "We’re still signing agreements on a rolling basis with these parties and will have a more complete list to share soon."

Since Oct. 6, eHealth has been offering Affordable Care Act-qualified health plans to customers who are ineligible for government subsidies because of their income, Gibbs noted. These plans are being sold independently of the FFM and the state-run exchanges in 14 states. But they meet all of the qualifications for a plan that is offered on one of these exchanges, and the premiums charged to customers for a particular plan are the same whether they're available in an exchange or not.

To enroll people who are eligible for subsidies -- the vast majority of those interested in purchasing exchange plans -- eHealth and the other four brokers must connect to the CMS data hub to verify applicants' incomes and calculate the amount of subsidies they can receive. eHealth is still testing its ability to get that information and to link with other FFM systems. "We didn't get the test environment until Sept. 30," Gibbs explained.

When eHealth is ready to begin enrolling subsidy-eligible individuals in the FFM plans, it will do so on its own. "We'll do our own marketing to our own customer base, and if one of our customers wants a subsidy, we'll take them through our site and help them pick a plan," Gibbs said. "When they're ready to enroll, we'll send them to the federal exchange for enrollment completion, and then the exchange will send that enrollment to the carrier."



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 Healthcare.gov. 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 Healthcare.gov, 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."

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
RSS
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service