Obamacare's back end

In a previous blog post, I wrote about what I fear are the most significant problems facing the Obamacare system, namely, potential weaknesses in its business model and back-end business processes.

When customers fill in data, click on buttons, and so on, in the Obamacare portal, backend business processes will be set in motion. It is one thing for software to capture data in a form, send that data over a wire, and store that data as a transaction in a database. It is quite another thing for the backend business processes to make sense of and reconcile all this data, to take appropriate actions based on the data, and, to operate in such a way that all the transactions taken together aggregate and add up to a net benefit to users. In short, once a user has enrolled in a policy, the entire lifetime of that policy, including premium billing over the long term, must be administered in a consistent, auditable way.

Now, Jon Kingsdale, who oversaw the Massachusetts health insurance exchange from 2006 to 2010, reports on some of the challenges in these back-office processes:

The first [challenge] is to get enrollment, billing and premium collections working smoothly. In 2006, when we launched the Massachusetts Health Connector, which became the prototype for insurance exchanges under the ACA, my team encountered start-up problems. Tracking billing and collections was a much bigger challenge than getting our Web site to work.

Here’s why: Enrollees are not covered until their first month’s premium is received. In the individual insurance market, premium billing and collection is difficult to track. Folks frequently pay late or in weekly installments, or send too little or even too much. And when they stop paying, they often do not notify the insurer; the company must determine whether it is an intentional termination, an oversight, or a lost or late payment. Unlike most of today’s 15 million direct enrollees, who pay premiums on their own, an estimated 27 percent of those who will be eligible for tax credits under the ACA do not have checking accounts. So they must use cash, money orders or prepaid debit cards to pay their share of monthly premiums.

Under the health-care law, premium billing and tracking will be even tougher. There are hundreds of prices across each of the thousands of plans in the federal marketplace. Having enrollees pay partial premiums, and the IRS issue tax credits for the rest, means twice as much billing. Calculating subsidies based on personal income tax filings also creates security issues: In addition to the problems with verifying consumers’ identities online, which have created delays on HealthCare.gov, tens of thousands of unlicensed “navigators” are fanning out across the country to help folks enroll. Many of these people don’t have to submit to thorough background checks, although they will gain access to personal financial information. And consumer protections for low-income enrollees who miss payments require complex notifications over 90 days before an insurer can end coverage. ...

In Massachusetts, we received about 100 visits to the site for every one enrollment. If the tens of millions of hits for the federal exchange in October eventually translate into millions of customers, the accuracy of the enrollment data — and insurers’ ability to correctly split premium billing between millions of enrollees and the IRS; track premium remittances; and chase, reconcile and report on accounts receivable — will be tested under the pressure of high volume. If insurers cannot track and collect premium dollars each month, the extra work of doubling back with customers and insurers will frustrate consumers and delay coverage. And a mounting backlog could eventually compromise the fiscal integrity of the exchange. [emphasis added]

To think that all of these back-end business processes are going to be working by December 1 is sheer fantasy. And, if they are not working, then, as Mr Kingsdale mentions and I have also pointed out in other blog posts (for example, here and here): "a mounting backlog could eventually compromise the fiscal integrity of the exchange." That is, a poorly functioning exchange will create more and more data that must be revisited and manually corrected until the amount of reworks will simply overwhelm the system.