The Story

The case for automation was good – thousands of claims needing audits, overwhelming a team of claims experts, but where over 90% of audits found nothing wrong. The machine learning task was a straightforward supervised learning exercise: we had the results of 100,000 audits as labeled data; given those results and the underlying claims, could we predict which audits were worth doing?

Our first project was a great success. We had a proof of concept in a month and a full model and a robust production system in a couple more. We calibrated the model and graphed the trade-off between the number of audits saved and the potential reduction in savings based on audit results. Once the client understood that, they picked a threshold, yielding a 50% reduction in the number of audits required with a negligible decrease in issues discovered. System integration was simple; the insurer sent us claims data each morning, and our server sent back a list of audits to skip and a prioritized list of the rest, which they fed into their audit assignment system. The audit team could finally keep up with the mandated audits, and even shift some experts to more valuable work.

At my company, the project breathed life into the shrinking commercial side of the business. Most of the work was re-usable, and sales quickly signed up a second client. After six months, the new client had bailed, disappointed with the results, and the promise of new commercial business faded. A few months later, our company abandoned commercial markets to focus on government business, and laid off the data scientists and support staff who worked on the commercial side.

What made the difference?

The original client had a rule mandating audits for high-dollar claims (above a certain monetary threshold), regardless of whether the claims showed any signs of something wrong. That was why most audits found nothing. The initial approval or denial, like at any health insurer, was automated based on a mess of thousands of rules; denials were explainable, but claims which were not denied were unexplained. As a result, the auditors had no clues other than dollar amounts to prioritize which claims to audit first.

The second client was different; they were selecting claims to audit based on several tools, some internal and some from other vendors. Those tools were black boxes too, and their results were not reliable enough to deny claims outright, so they still had thousands of claims requiring audits. However, those claims were not random, but rather biased towards claims with issues. No one consulted the data scientists during pre-sales, but that might not have made a difference. By the time we started the project, the data scientists on the team knew all this, but weren’t too worried. We thought you could get automation from both tails of the distribution – not auditing claims which were likely valid or quickly rejecting claims which were overwhelmingly likely to be rejected during audit. Plus, rejected claims are subject to appeal, incurring additional administrative costs. Given appeals records, we could train a model to avoid rejections likely to be overturned on appeal.

What did we miss?

Our model was focused on ranking claims by probability. Given that ranking and a threshold, automatically accepting claims is simple; just send the notice and pay the bill. Rejecting claims is complicated; you have to document the basis of the rejection, write a letter explaining the decision, and then deal with appeals. Even partial automation (say gathering supporting evidence) requires a more sophisticated model. A 45% probability of missing information plus a 45% probability of incorrect information adds up to 90% chance the claim should be rejected, but the rejection letter has to specify which. And more importantly, you need to integrate your system with multiple existing processes, both manual and automated, internal and 3rd-party. No one had talked to the client about what work that would entail or what it would cost, and it was too late to start. When your client has already spent money and not gotten the savings they expected, it’s not the ideal time to make a new business case.

Our company was in the business of providing information services to health insurers, so we were intimately familiar with these business processes. We could have anticipated the problem. Data scientists, like all scientists, know the value of skepticism, but fresh off an initial success, we didn’t apply that skepticism to the business case.

What are the lessons?

1. Don’t be content with a successful model. Understanding why your model was (or was not) a success yields much more insight, and successfully applying data science or machine learning in business depends as much on business factors as on technical ones.
2. Don’t stop being skeptical outside your expertise. Data science thrives on information, so our quantitative tools won’t give clear evaluations for prospective business deals with more unknowns, but that doesn’t mean you have to discard your entire scientific framework.
3. Make sure to get data science input on potential data science projects at the pre-sales stage. New and repeat business both rest on a record of customer satisfaction, and properly qualifying sales leads is an essential first step. Good salespeople know how to make sure the client’s budget is adequate, how to figure out who actually has the authority to make a decision, etc. but don’t leave them guessing about post-sales risks.
4. Don’t forget the flip side. Business people who are used to doing things a certain way may miss opportunities that a data scientist, coming from a different background, might see.