— About 550,000 people in Oregon do not have health insurance, and Aaron Karjala is confident the state's new online insurance exchange will be able to accommodate them when enrollment under President Barack Obama's health care reform begins on Oct. 1.
What Karjala, the chief information officer at Cover Oregon, does worry about, however, is what will happen if the entire population of Oregon — 3.9 million — logs on that day "just to check it out," he said. Or if millions of curious souls elsewhere, wondering if Oregon's insurance offerings are better than their states', log on, causing Cover Oregon to crash in a blur of spinning hourglasses and color wheels and an epidemic of frozen screens.
Multiply that by another 49 states and the District of Columbia, all of which will open health insurance exchanges under Obamacare the same day, and you get some idea of what could go publicly and disastrously wrong.
Obamacare, formally known as the Patient Protection and Affordable Care Act, could fail for many reasons, including participation by too few of the uninsured and a shortage of doctors to treat those who do sign up. But because its core is government-run marketplaces selling health insurance online, the likeliest reason for failure at the opening bell is information technology issues, say experts who are helping with the rollout.
Although IT is the single most expensive ingredient of the exchanges, with eight-figure contracts to build them, experts expect bugs, errors and crashes. In April, Obama himself predicted "glitches and bumps" when the exchanges open for business.
"This is a 1.0 implementation," said Dan Maynard, president of Connecture, a software developer that is providing the shopping and enrollment functions for several states' insurance exchanges. "From an IT perspective, 1.0's come out with a lot of defects. Everyone is waiting for something to go wrong."
Two states that intended to build their own exchanges, Idaho and New Mexico, announced this spring that because of the tight timeline and daunting challenges they would have the federal government operate their IT systems.
"Nothing like this in IT has ever been done to this complexity or scale, and with a timeline that put it behind schedule almost before the ink was dry," said Rick Howard, research director at the technology advisory firm Gartner .
The potential for problems will begin as soon as would-be buyers log on to their state exchange. They'll enter their name, birth date, address and other identifying information. Then comes the first IT handoff: Is this person who she says she is?
To check that, credit bureau Experian will check the answers against its voluminous external databases, which include information from utility companies and banks on people's spending and other history, and generate questions. The customer will be asked which of several addresses he previously lived at, for example, whether his car has one of several proffered license plate numbers, and what color his old Volvo was.
It's similar to the system that verifies identity for accessing personal Social Security information. If someone gets a question wrong, he will be referred to Experian's help desk, and if that fails may be asked to submit documentation to prove he is who he claims to be.
The next step is determining whether the customer is eligible for federal subsidies to pay for insurance. She is if she is a citizen and her income, which she will enter, is less than four times the federal poverty level. To verify this, the exchange pings the "federal data services hub," which is being built by Quality Software Services Inc under a $58 million contract with the Centers for Medicare & Medicaid Services.
The query arrives at the hub, which does not actually store information, and is routed to online servers at the Internal Revenue Service for income verification and at the Department of Homeland Security for a citizenship check.
The answers must be returned in real time, before the would-be buyer loses patience and logs off. If the reported income doesn't match the IRS's records, the applicant may have to submit pay stubs.
These federal computer systems have never been connected before, so it's anyone's guess how well they'll communicate.
"The challenge for states," said Jinnifer Wattum, director of Eligibility and Exchange Solutions at Xerox's government health care unit, is that they have to build "the interfaces needed with the federal data services hub without knowing what this system will look like." That makes the task akin to making a key for a lock that doesn't exist yet.
CMS's contractors are working to finish the hub, but "much remains to be accomplished within a relatively short amount of time," concluded a report from the Government Accountability Office, the investigative arm of Congress, in June. CMS spokesman Brian Cook said the hub will be ready by September, and that the beta version had been tested for its ability to interact with the exchanges Oregon and Maryland are building.
The federal hub has to verify even more arcane data, such as whether the insurance offered to a buyer through his job is unaffordable, in which case he may qualify for federal subsidies, and whether the buyer is in prison, in which case she is exempt from the mandate to purchase insurance.
If someone's income qualifies him for Medicaid, or his children for the Children's Health Insurance Program, software has to divert him from the ACA exchange and into those systems. Many of the computers handling Medicaid and CHIP enrollment are, as IT people diplomatically put it, "legacy systems," meaning old, even decades old.
Many are mainframes, lacking the connectivity of cloud computing. They typically process eligibility requests in days, not seconds.