Explore Claims Product Modeling

Learning Objectives

After completing this unit, you’ll be able to:

• Describe the role of a root product and child specs in the claims process.
• Explain how power attributes enforce the terms and conditions of the policy.
• Define the role of a claim product and other claim specs in the claims process.

The Claim Model

The module Insurance Quoting Foundations introduces the concept of product specifications (specs), which form the basis for quotes and policies. 

Let’s briefly recap. When modeling an insurance product, you create it as a root product with coverage specs, insured party specs, and insured item specs. Attributes are components that define each spec. The configuration of these specs and attributes forms a product model.

In the same way, product administrators rely on a claim model to define the claim.

How do these components relate to one another? 

The product model (1) forms the basis for a given insurance policy record (2). Essentially, the insurance policy is a specific configuration of the product model that contains all the information about the insured items, insured parties, and coverages.

This insurance policy record then combines with the claim model (3) to define a specific claim record (4). This record contains all the policy information relevant to the claim, which comes from the policy record. The claim record also contains details about the property and injuries involved in the claim, which come from the claim model.

So, to understand claims, you need to understand both the product model and the claim model. They’re the foundation that everything builds on, after all. 

Claim Specs and Attributes

A claim product model describes the property and injuries involved in the claim. The model also includes the rules that automate aspects of claim processing.

Just like a root product model, a claim product model has different product specs.

These claim specs include:

• Claim Product Spec (1), which is analogous to the root product in a product model. You add the other claim spec types to the claim product, just as you add other specs to the root product. The claim product spec is also where you define rules for the claim.
• Claim Injury Spec (2), which defines the injuries incurred by a person.
• Claim Property Spec (3), which defines the damage to a property.

Compared to root product models, which sometimes contain over a dozen specs, claim product models are generally leaner, with only a few specs. Typically, you only need to collect information about the injuries and property damage. Everything else needed for the claim comes from the policy. 

Let’s see a simple claim product model for an auto claim.

The Auto Claim (1) claim product spec contains two child specs.

• A claim injury spec, Injury (2), that stores information about any injuries.
• A claim property spec, Involved Vehicle (3), that stores information about damages to involved vehicles.

You add attributes to these specs. Remember, attributes store the details that define the specs. 

Let’s take a look at some sample attributes for an Involved Vehicle claim property spec. 

The two attribute categories, Auto Vehicle and Claim Item, each contain attributes.

• The Auto Vehicle category (1) contains attributes that provide identifying details about any involved vehicles. While the insurance policy already stores information about insured autos, it doesn’t hold details about other involved vehicles, so the claim stores these identifying details here.
• The Claim Item category (2) contains attributes that store specific information about any damage to the involved vehicles, including severity, drivability, and loss estimates.

During the first notice of loss, the claims system collects information about the accident, and dedicated claims services automatically populate the claim record with the relevant information. 

Claim Rules

Claim product rules set conditions for altering the default behavior of a claim. Product rules are a simple, powerful way to automate critical aspects of the claim process. 

When claim product rules evaluate to true, they automatically trigger actions, such as opening a claim coverage or setting a reserve amount. Rules also determine how a claim moves across its lifecycle. You set conditions that move the claim to different states, such as adjuster review, investigation, or closure. 

Typically, you define claim product rules on the claim product itself.

Claim product rules usually reference attributes in their rule expressions. 

In the example screen below, this rule sets conditions for automatically opening a Rental Car coverage. The rule references the claimDrivable attribute on the Involved Vehicle claim property spec.

During the first notice of loss, a service evaluates whether the claimDrivable attribute is set to no. 

• If true, the Rental Car claim coverage automatically opens, and the claim transitions from draft to open.
• If false, the claim coverage doesn’t open, and the claim doesn’t transition.

Modeling Policies to Support Claims

Remember, claims use the claim product model and the policy together. This modeling approach ensures the integrity of the end-to-end digital insurance process. To ensure that the policy terms and conditions work seamlessly with claims, you need to make holistic modeling decisions.

When modeling the product, you create coverage specs that define what the policy can actually cover. 

For example, an auto policy typically contains multiple coverages that cover the policyholder against different types of losses.

• Collision covers damage to a policyholder’s own car due to an accident with another vehicle or object.
• Bodily Injury & Property Damage covers costs related to another person’s injuries and property damage.
• Comprehensive covers losses related to damage from covered perils such as theft, fire, or vandalism.

Depending on the policy, these coverages can be optional or mandatory. When a policyholder purchases a policy, they choose the coverages and terms they want.

When a policyholder makes a claim, these policy coverages are then available to open as claim coverages.

• If the policyholder gets into a collision, they can open a Collision claim coverage.
• If another person is injured in the accident, they can open the Bodily Injury & Property Damage claim coverage.

These claim coverages store specific details about the claimed loss. 

This close integration between the policy and claim means it's really important to design coverage specs to account for the claims process, especially when it comes to policy terms, such as limits and deductibles. Let’s learn how these term definitions play a particularly important role in claims.

Power Attributes

When processing a claim, the claims system must flexibly enforce policy terms like limits and deductibles. Some terms may apply for each incident or for each person, while other terms must aggregate across all claims. For example, the deductible on an auto policy typically applies to each claim.

To support these varied requirements, Claims Management employs super-powered attributes called power attributes. You create them just like regular attributes and then power-enable them by adding properties that control how they work during claims. 

The two most important properties for power attributes are attribute class and attribute scope. 

Attribute Class

Attribute class defines the type of policy term. Several classes are available.

During the financials and adjudication stage, the claims system automatically applies the appropriate logic for each class.

• If a claimed amount exceeds a limit threshold, then the system prevents the payment.
• For deductibles, the system calculates the adjustment amount and sets it on the payment detail.

The flexibility and simplicity of attribute class is a pretty nifty capability that saves time and reduces human error.

Attribute Scope

It’s also important to consider an attribute’s scope, which defines how broadly to track a term. 

Let’s say you have a deductible. If it’s an annual deductible, you need to decide whether it applies to each insured person or to the policy as a whole. And if the deductible applies to individual claims, you have to specify if it applies to each claim coverage that opens or to the claim as a whole.  

Defining the scope allows the claims-management system to handle sophisticated term configurations with ease.  

Four types of scope are available.

Once you create a power attribute for a policy term and apply it to your product model, each new claim or claim coverage instantiates the policy term standings. When financial activity occurs on the claim, transactions log into the policy terms tracking entry ledger. Then, claim handlers can easily review limits and deductibles from their Claims Adjuster’s Workbench.

Now you have a nice grasp on the foundational components of a claim. Head to the next unit to learn all about how the first notice of loss collects data about the claim and turns the information into a claim record.

Resources

• Trailhead: Insurance Quoting Foundations