Politics

The Hardest Part of Setting Up ObamaCare's Health Exchanges

It's been clear for a while that the most difficult part of building ObamaCare's health exchanges will be setting up the systems to determine benefit eligibility.

|

It's been clear for a while that the most difficult part of building ObamaCare's health exchanges will be setting up the systems to determine benefit eligibility.

As I noted back in Reason's October 2010 issue, the exchanges — whether they are run by the states or the federal government — will have to be able to verify someone's family income as well as a number of other determining factors. And to do that, they'll have to play nice with an array of government I.T. systems. The Washington Post has some additional details on the challenges involved:

After people become aware of benefits, the health exchange faces its biggest challenge: Figuring out who is eligible for what. In many states those who earn less than 133 percent of the Federal Poverty Line are eligible for Medicaid — except if the state has already extended benefits to an even higher level, as 35 states have for children. 

"There may be different family members eligible for different programs," says Sam Gibbs, vice president of sales at eHealthInsurance. "There needs to be a technology system that can support that activity, and look at multiple programs for multiple people."

A state can't figure out how much an individual earns on its own. For that, it needs to ping a federal data hub that does not yet exist.

The federal government recently contracted with the healthcare IT firm QSSI to build that data hub, and they plan to make it available to both the exchanges that states run and those that the federal government sets up. It will determine whether individuals are eligible for Medicaid, subsidies or no benefit at all.

The challenge here is for states, which may have complex Medicaid rules or old computer systems, to actually plug into the federal hub. 

"In many states, the Medicaid system is the best technology that the 1980s could offer," says Bruce Caswell, who runs the health-services segment of Maximus, a firm that works on large government data systems. "As a consequence, they might have brittle interface capabilities."

An old Medicaid system, for example, may only have the capacity to send large batches of data each night. That was fine back in the 1980s, when most applications happened by mail. It's less desirable when you have a law that would like to see real-time application processing. 

These systems are going to have to work with a high degree of accuracy: It's going to be a big problem if the exchanges are routinely assigning people higher or lower subsidies than they qualify for, or doling them out to people who don't qualify for them at all.

Yet that's exactly what researchers worry could happen. A Health Affairs study by a researcher at the Vanderbilt University School of Medicine published earlier this year estimated that, due to the complexities of calculating an individual's income for the purposes of subsidy distribution, a non-trivial number of exchange enrollees are likely to get the wrong subsidy. Incomes fluxuate unexpectedly. The time frames used to judge income are too small. The databases used to verify individual income are incomplete. yet the exchanges are going to have be able to make relatively swift judgements about income levels and subsidy qualifications anyway. 

How are the exchange designers going to manage this? The answer is: It's going to be very, very complicated. So complicated, in fact, that they may not get it done on time. States were originally supposed to inform the federal government this week of their decision to either build an exchange or let the federal government try to do it for them. That deadline has been extended. But it may already be too late. "These are systems that typically take two or three years to build,"  Kevin Walsh, who manages insurance exchange services at Xerox, told the Post. "The last time I looked at the calendar, that's not what we're working with."