Claim Files Are Evaluated Using A Form Of Root Cause Analysis So Why Not Do The Same When Evaluating The Department?

By Marc Lanzkowsky – March 5, 2013

Assessing operational ills requires the same skill needed to evaluate a claim file

We have heard the mantra time and time again about how treating the symptom of a problem doesn’t do anything to cure the cause of the problem. As one of my favorite bloggers Seth Godin recently wrote in Signals vs. causes, “A fever might be the symptom of a disease, but artificially lowering the fever (ice bath, anyone?) isn’t going to do anything at all to change the illness.”

Assessing a claim file is like doing a Root Cause Analysis.  Looking at the damages and paying the claim may move a file but it doesn’t tell you whether the claim should be paid in the first place.  Analyzing a claim file is learning to know the what, why and how an event happened which is essentially what Root Cause Analysis is.

Root causes are specific problem or faults that create a breakdown in an operation or process. Claim files are a result of some event that causes a claim to arise (i.e. an accident, malpractice, property damage). It is the claims professionals primary job to assess these events and determine what happened and why prior to paying a claim. In general, root causes can be defined as an event that is:

1. Underlying to the problem
2. Reasonably identifiable
3. Within managements control to correct
4. When corrected will be effective in preventing recurrences

Despite Root Cause Analysis being a core skill in handling a claim file, claims management doesn’t always approach departmental issues with same type of evaluative assessment.  Using the same techniques in assessing the root cause of a claim, management can assess operational problems.

Since the techniques are already in use for claims analysis why not use them for operational assessments?

Doing a Basic Root Cause Analysis: The 5 Whys

Similar to a claim file analysis, operational problems require an assessment as to what happened, how it happened, how could it have been prevented, who was at fault, what’s it going to cost to fix the claim and are there any lessons learned.  For example, let’s say payments are being delayed resulting in fines being assessed against the department. If one looks at the fines as a claim one would want to determine what caused the fine? how did it happen? and how can it be corrected? An analysis of the “claim” needs to take place prior to making any decisions.

A great technique for getting to the root cause of a problem is to ask the question “Why” question five times.  “By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. Very often the ostensible reason for a problem will lead you to another question. Although this technique is called “5 Whys,” you may find that you will need to ask the question fewer or more times than five before you find the issue related to a problem.” (Determine the Root Cause: 5 Whys – from www.isixsigma.com)

Going back to our example of a payment delays causing fines, and using the 5 “whys” technique,  one could assess the problem this way:

• Why are we being fined?
• Because payments are being delayed by 5 days
• Why are payments being delayed 5 days?
• Because they were delayed in getting to finance
• Why were they delayed in getting to finance?
• Because they were not in the outgoing tray for approved payments
• Why were the not in the outgoing tray?
• Because they were sitting on a manager’s desk for signature and the manager was on vacation
• Why was there no plan to have another manager cover the vacationing manager’s desk?
• Because there was not procedure in place

The example above is simplified but it truly demonstrates that similar types of issues can be explored with a series of basic questions. Getting to the root cause is essential to moving a problem to a solution.

What are other techniques used for assessing a claim file can be used to assess the operation?