05-14-2019 10:57:15 AM -0700
05-09-2019 02:01:30 PM -0700
05-09-2019 10:41:48 AM -0700
04-18-2019 07:46:35 AM -0700
04-18-2019 07:18:40 AM -0700
It looks like you've previously blocked notifications. If you'd like to receive them, please update your browser permissions.
Desktop Notifications are  | 
Get instant alerts on your desktop.
Turn on desktop notifications?
Remind me later.

The Plight of the Navigator

The rollout of Obamacare -- the proximate cause of the of "shutdown" -- has become a headline in itself. The touted health care exchanges were experiencing highly publicized difficulties all over the country. A rollout of this size was never going to be easy in the best of circumstances, but in this case many of the problems experienced were the direct consequence of the length of the law and its attendant regulatory complexity.

These regulations are often called "business rules," and they have to be implemented in software. The Obamacare ruleset is now reportedly eight times the length of the Bible and still growing. This has had unavoidable results. How the IT personnel at Oregon approached the problem, as described by InformationWeek, gives a sense of the hurdle. Chris Murphy writes:

To understand the challenge, I spoke with Aaron Karjala, CIO of Cover Oregon, which runs Oregon's health insurance marketplace, and Carolyn Lawson, CIO of Oregon Health Authority and Department of Human Services, which started the exchange project before state lawmakers created Cover Oregon. Here's a look inside some of the challenges facing Oregon's more than two-year effort.

Presenting a product -- an insurance policy -- isn't the hard part. The hard part is figuring out which federal and state programs and tax credits a person or family is eligible for. Getting that part right takes creating an extremely complex rules engine.

About 1,700 individual rules affect eligibility for health insurance subsidies in Oregon. Children might qualify under different rules from their parents, or half-siblings might have different eligibility based on their parents' income. In Oregon, writing the eligibility rules engine took 12 people nine months. Confirming eligibility requires integration with multiple outside data sources, such as confirming income and citizenship with federal sources, and that process is what separates it from ecommerce sites.


"The policies and rules came to us a little at a time," Karjala says. "It was constantly emerging requirements." For example, the Federal hub that state exchanges connect to for verifying income and citizenship was completed this summer. That timing helps explain why exchanges are doing so much testing down to the deadline.

The solution, says Lawson, was "ruthless incrementalism. We had to build in an agile fashion and build what we know, and then put the pieces together like Legos."

And that's just Oregon. It was a difficult, possibly insuperable job under the best of circumstances, but the problem was compounded by the incompetence described by Scott Gottlieb and Michael Astrue in the Wall Street Journal:

There are two key technological flaws in ObamaCare. First is the "hub" -- the software to link servers at the Treasury Department, the Internal Revenue Service, Homeland Security and state agencies to verify the income and health-insurance status of enrollees and ensure that they are eligible for subsidies. The other flaw is the "portal" -- the federally run IT platform that is supposed to let consumers compare health plans and select one that best suits their needs.

In planning ObamaCare's IT infrastructure, the Centers for Medicare and Medicaid Services (CMS) dawdled for more than a year under Administrator Donald Berwick until Marilyn Tavenner took over in December 2011. Even then the agency was slow to outsource key contracts and turned to what insiders say were not top-quality programmers. CMS did not sign a contract for a backstop system to process paper verifications and do paper verifications of online applications until July.

The Health and Human Services Department did not begin testing the chief pieces of this IT system until August. The testing found that states couldn't consistently link to the federal portal (a problem that persists in some states), and that the hub couldn't reliably verify if a person is eligible for a subsidy, or accurately calculate how much the applicant is eligible to receive.

But Gottlieb and Astrue mention the biggest problem last -- the consequence of the architecture of the system:

The biggest risk involves data security. The Obama administration created unnecessary opportunities for fraud with the White House's pork-minded insistence on funding favored community groups to employ "navigators" to solicit applicants and help them input their personal information, such as income and Social Security numbers.