---
title: Triage insurance claims
description: Evaluate the severity of an insurance claim in order to triage it effectively.

---

# Triage insurance claims {: #triage-insurance-claims }

This page outlines a use case that assesses claim complexity and severity as early as possible to optimize claim routing, ensure the appropriate level of attention, and improve claimant communications. It is captured below as a UI-based walkthrough. It is also available as a [Jupyter notebook](claims.ipynb) that you can download and execute.

{% include 'includes/triage-insurance-claims-include.md' %}

### Data preparation {: #data-preparation }

The example data is organized at the claim level; each row is a claim record, with all the claim attributes taken at FNOL. On the other hand, the target variable, `Incurred`, is the total payment for a claim when it is closed. So there are no open claims in the data.

A workers’ compensation insurance carrier’s claim database is usually stored at the transaction level. That is, a new record will be created for each change to a claim, such as partial claim payments and reserve changes. This use case snapshots the claim (and all the attributes related to the claim) when it is first reported and then again when the claim is closed (from target to total payment). Policy-level information can be predictive as well, such as class, industry, job description, employee tenure, size of the employer, whether there is a return to work program, etc. Policy attributes should be joined with the claims’ data to form the modeling dataset.

### Data evaluation {: #data-evaluation }

Once the modeling data is uploaded to DataRobot, [EDA](eda-explained) produces a brief summary of the data, including descriptions of feature type, summary statistics for numeric features, and the distribution of each feature. A [data quality assessment](data-quality) helps ensure that only appropriate data is used in the modeling process. Navigate to the **Data** tab to learn more about your data.

#### Exploratory Data Analysis {: #exploratory-data-analysis }

Click each feature to see [histogram](histogram) information such as the summary statistics (min, max, mean, std) of numeric features or a histogram that represents the relationship of a feature with the target.

![](images/insurance-claims-1.png)

DataRobot automatically performs data quality checks. In this example, it has detected outliers for the target feature. Click **Show Outliers** to view them all (outliers are common in insurance claims data). To avoid bias introduced by the outlier, a common practice is to cap the target, such as capping it to the 95th percentile. This cap is especially important for linear models.

#### Feature Associations {: #feature-associations }

Use the [**Feature Associations**](feature-assoc) tab to visualize the correlations between each pair of the input features. For example, in the plot below, the features `DaysWorkedPerWeek` and `PartTimeFullTime` (top-left corner) have strong associations and are therefore "clustered" together. Each color block in this matrix is a cluster.

![](images/insurance-claims-2.png)

## Modeling and insights {: #modeling-and-insights }

After modeling completes, you can begin interpreting the model results.

### Feature Impact {: #feature-impact }

[**Feature Impact**](feature-impact) reveals the association between each feature and the model target&mdash;the key drivers of the model. **Feature Impact** ranks features based on feature importance, from the most important to the least important, and also shows the relative importance of those features. In the example below we can see that `InitialCaseEstimate`is the most important feature for this model, followed by  `ClaimDescription`, `WeeklyRate`, `Age`, `HoursWorkedPerWeek`, etc.

![](images/insurance-claims-3.png)


This example indicates that features after `MaritalStatus` contribute little to the model. For example, `gender `has minimal contribution to the model, indicating that claim severity doesn't vary by the gender of the claimant. If you create a new feature list that does not include gender (and other features less impactful than `MaritalStatus`) and only includes the most impactful features, the model accuracy should not be significantly impacted. A natural next step is to [create a new feature list](work-with-feature-lists#create-a-feature-list) with only the top features and rerun the model. DataRobot automatically creates a new feature list, "DR Reduced Features", by including features that have a cumulative feature impact of 95%.

### Partial Dependence plot {: #partial-dependence-plot }

Once you know which features are important to the model, it is useful to know how each feature affects predictions. This can be seen in [**Feature Effects**](feature-effects) and in particular a model's partial dependence plot. In the example below, notice the partial dependence for the `WeeklyRate` feature. You can observe that claimants with lower weekly pay have lower claim severity, while claimants with higher weekly pay have higher claim severity.

![](images/insurance-claims-5.png)

### Prediction Explanations {: #prediction explanations }

When a claims adjuster sees a low prediction for a claim, they are likely to initially ask what the drivers are behind such a low prediction. The [**Prediction Explanation**](pred-explain/index) insight, provided at an individual prediction level, can help claim adjusters understand how a prediction is made, increasing confidence in the model. By default, DataRobot provides the top three explanations for each prediction, but you can request up to 10 explanations. Model predictions and explanations can be downloaded as a CSV and you can control which predictions are populated in the CSV by specifying the thresholds for high and low predictions.

The graph below shows the top three explanations for the 3 highest and lowest predictions. The graph shows that, generally, high predictions are associated with older claimants and higher weekly salary, while the low predictions are associated with a lower weekly salary.

![](images/insurance-claims-6.png)

### Word Cloud {: #word-cloud }

The feature `ClaimDescription` is an unstructured text field. DataRobot builds text mining models on textual features, and the output from those text-mining models is used as inputs into subsequent modeling processes. Below is a [**Word Cloud**](word-cloud) for `ClaimDescription`, which shows the keywords parsed out by DataRobot. Size of the word indicates how frequently the word appears in the data: `strain` appears very often in the data while `fractured `does not appear as often. Color indicates severity: both `strain` and `fractured` (red words) are associated with high severity claims while `finger` and `eye` (blue words) are associated with low severity claims.

![](images/insurance-claims-7.png)


## Evaluate accuracy {: #evaluate-accuracy }

The following insights help evaluate accuracy.

### Lift Chart {: #lift-chart }

The [**Lift Chart**](lift-chart) shows how effective the model is at differentiating lowest risks (on the left) from highest risks (on the right). In the example below, the blue curve represents the average predicted claim cost, and the orange curve indicates the average actual claim cost. The upward slope indicates the model has effectively differentiated the claims of low severity (close to 0) on the left and those of high severity (~45K) on the right. The fact that the actual values (orange curve) closely track the predicted values (blue curve) tells you that the model fits the data well.

![](images/insurance-claims-4.png)

Note that DataRobot only displays lift charts on validation or holdout partitions.

## Post-processing  {: #post-processing }

A prediction for claim severity can be used for multiple different applications, requiring different post-processing steps for each. Primary insurers may use the model predictions for claim triage, initial case reserve determination, or reinsurance reporting. For example, for claim triage at FNOL, the model prediction can be used to determine where the claim should be routed. A workers’ compensation carrier may decide:

* All claims with predicted severity under $5000 go to straight-through processing (STP).
* Claims between $5000 and $20,000 go through the standard process.
* Claims over $20,000 are assigned a nurse case manager.
* Claims over $500,000 are also reported to a reinsurer, if applicable.

Another carrier may decide to pass 40% of claims to STP; 55% to regular process; and 5% get assigned a nurse case manager so that thresholds can be determined accordingly. These thresholds can be programmed into the business process so that claims go through the predesigned pipeline once reported and then get routed appropriately. Note that companies with STP should carefully design their claim monitoring procedures to ensure unexpected claim activities are captured.

In order to test these different assumptions, design single or multiple A/B tests and run them in sequence or parallel. Power analysis and p-value needs to be set before the tests in order to determine the number of observations required before stopping the test. In designing the test, think carefully about the drivers of profitability. Ideally you want to allocate resources based on the change they can effect, not just on the cost of the claim. For example, fatality claims are relatively costly but not complex, and so often can be assigned to a very junior claims handler. Finally, at the end of the A/B tests, you can identify the best combination based on the profit of each test.


## Predict and deploy {: #predict-and-deploy }

You can use the DataRobot UI or REST API to deploy a model, depending on how ready it is to be put into production. However, before the model is fully integrated into production, a pilot may be beneficial for:

* Testing the model performance using new claims data.
* Monitoring unexpected scenarios so a formal monitoring process can be designed or modified accordingly.
* Increasing the end users’ confidence in using the model outputs to assist business decision making.

Once stakeholders feel comfortable about the model and also the process, integration of the model with production systems can maximize the value of the model. The outputs from the model can be customized to meet the needs of claim management.

### Decision process {: #decision-process }

Deploy the selected model into your desired decision environment to embed the predictions into your regular business decisions. Insurance companies often have a separate system for claims management. For this particular use case, it may be in the best interest of the users to integrate the model with the claims management system, and with visualization tools such as Power BI or Tableau.

If a model is integrated within an insurer’s claim management system when a new claim is reported, FNOL staff can record all the available information in the system. The model can then be run in the background to evaluate the ultimate severity. The estimated severity can help suggest initial case reserves and appropriate route for further claim handling (i.e., STP, regular claim adjusting, or experienced claim adjusters, possibly with nurse case manager involvement and/or reinsurance reporting).

Carriers will want to include rules-based decisions as well, to capture decisions that are driven by considerations other than ultimate claim severity.

Most carriers do not set initial reserves for STP claims. For those claims beyond STP, you can use model predictions to set initial reserves at the first notice of loss. Claims adjusters and nurse case managers will only be involved for claims over certain thresholds. The reinsurance reporting process may benefit from the model predictions as well; instead of waiting for claims to develop to very high severity, the reporting process may start at FNOL. Reinsurers will certainly appreciate the timely reporting of high severity claims, which will further improve the relationship between primary carriers and reinsurers.

### Decision stakeholders {: #decision-stakeholders }

Consider the following to serve as decision stakeholders:

* Claims management team
* Claims adjusters
* Reserving actuaries

### Model monitoring {: #model-monitoring }

Carriers implementing a claims severity model usually have strictly defined business rules to ensure abnormal activities will be captured before they get out of control. Triggers based on abnormal behavior (for example, abnormally high predictions, too many missing inputs, etc.) can trigger manual reviews. Use the [performance monitoring capabilities](monitor/index)&mdash;especially service health, data drift, and accuracy to produce and distribute regular reports to stakeholders.

### Implementation considerations {: #implementation-considerations }

A claim severity model at FNOL should be one of a series of models built to monitor claim severity over time. Besides the FNOL Model, build separate models at different stages of a claim (e.g., 30 days, 90 days, 180 days) to leverage the additional information available and further evaluate the claim severity. Additional information comes in over time regarding medical treatments and diagnoses and missed work, allowing for improved accuracy as a claim matures.


### No-Code AI Apps {: #no-code-ai-apps }

Consider building a custom application where stakeholders can interact with the predictions and record the outcomes of the investigation. Once the model is deployed, predictions can be consumed for use in the [decision process](#decision-process). For example, this [No-Code AI App](app-builder/index) is an easily shareable, AI-powered application using a no-code interface:

![](images/claim-severity-app-1.png)

### Notebook demo {:#notebook-demo}

See the notebook version of this accelerator [here](claims.ipynb).
