Data Template: Claims Processing

Guidewire ClaimCenter
Data Template: Claims Processing

Your Claims Processing Data Template

Welcome to your dedicated resource for optimizing claims processing. This template outlines the essential data attributes to collect, the critical activities to track, and provides clear guidance for data extraction. Use it to ensure you capture all necessary information for comprehensive process analysis.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance for Guidewire ClaimCenter

Claims Processing Attributes

These recommended data fields are crucial for building a complete event log to analyze your claims processing workflows effectively.
3 Required 4 Recommended 15 Optional
NameDescription
Activity Name
ActivityName
The name of the business activity or event that occurred at a specific point in the claim lifecycle.
Description

This attribute describes a specific step or milestone in the claims process, such as 'Claim Created', 'Investigation Started', or 'Payment Issued'. The sequence of these activities for a given Claim ID forms the process flow.

Analyzing the sequence, frequency, and duration between activities is the core of process mining. It allows for the discovery of process models, identification of bottlenecks, detection of rework loops, and analysis of process deviations.

Why it matters

It defines the steps of the process, enabling the visualization of process maps and the analysis of process flow and bottlenecks.

Where to get

This is typically derived from event tables or audit logs in ClaimCenter, often by mapping specific system events or status changes to standardized activity names.

Examples
Claim CreatedLiability Decision MadePayment IssuedClaim Closed
Claim ID
ClaimID
The unique identifier for each insurance claim, serving as the primary case identifier.
Description

The Claim ID is the cornerstone of claims process analysis, uniquely identifying each case from submission to closure. It links all associated activities, documents, payments, and communications, ensuring a complete and coherent view of a claim's lifecycle.

In process mining, every event in the dataset is tied to a Claim ID, allowing for the reconstruction of the end-to-end process flow. This is essential for analyzing cycle times, identifying process variants, and tracking a claim's journey across different departments and adjusters.

Why it matters

It is the fundamental key that connects all related events, making it possible to trace and analyze the entire journey of a single claim.

Where to get

This is a primary key in Guidewire ClaimCenter, typically found as Claim.ClaimNumber or a similar field in the core Claim entity.

Examples
000-123-45678000-987-65432001-456-11223
Event Time
EventTime
The precise date and time when the activity occurred.
Description

This timestamp marks the exact moment an activity was recorded in the system. It is fundamental for all time-based process analysis.

The chronological ordering of EventTime for a single Claim ID allows for the reconstruction of the process flow. The time difference between consecutive events is used to calculate cycle times, waiting times, and processing times, which are critical for performance analysis, bottleneck identification, and SLA monitoring.

Why it matters

This timestamp is essential for ordering events, calculating cycle times and durations, and identifying delays in the process.

Where to get

Found alongside event or activity data in Guidewire ClaimCenter's history or audit tables, often as a 'CreateTime' or 'UpdateTime' field.

Examples
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Assigned Adjuster
AssignedAdjuster
The name or ID of the user assigned to handle the claim or a specific activity.
Description

This attribute identifies the individual claims adjuster responsible for a claim at a given point in time. An adjuster may be assigned to the entire claim or to specific tasks within it.

Analyzing by Assigned Adjuster is critical for workload balancing, performance management, and identifying training opportunities. It helps answer questions like: 'Which adjusters have the highest caseload?', 'Are there performance variations between adjusters?', and 'Is work distributed evenly?'.

Why it matters

Tracks user involvement, enabling workload analysis, performance comparison, and identification of resource-related bottlenecks.

Where to get

Available in the Claim or Exposure entity in ClaimCenter, often linked to the User object (e.g., Claim.Assignee).

Examples
j.doem.smiths.jones
Cause of Loss
LossCause
The specific reason or cause of the loss event (e.g., Collision, Fire, Water Damage).
Description

This attribute provides detailed context on why the claim was filed. The cause of loss often dictates the required investigation steps, the type of experts needed, and the overall complexity of the claim.

Analyzing the process by Cause of Loss can reveal hidden patterns. For instance, claims related to 'Water Damage' might have a higher rate of rework or require more specialist involvement compared to 'Theft' claims. These insights help in creating more specialized and efficient handling procedures.

Why it matters

Provides context on the claim's nature, enabling analysis of how different loss causes impact process flow and duration.

Where to get

This is a standard field on the Claim entity, typically called 'LossCause'.

Examples
CollisionFireWater DamageTheft
Claim Status
ClaimStatus
The overall status of the claim at the time of the event (e.g., Open, Closed, Denied).
Description

This attribute reflects the high-level state of the claim. Key statuses include 'Open', 'Closed', 'Denied', and 'Reopened'. The final status of a claim is a critical outcome metric.

Tracking changes in Claim Status helps define key process milestones and outcomes. It is used to identify the final resolution of a claim, calculate rejection rates, and analyze the frequency of claims being reopened after closure, which often indicates process issues or customer dissatisfaction.

Why it matters

Indicates the outcome of a claim, which is essential for analyzing rejection rates, closure patterns, and claim reopening frequencies.

Where to get

This is a core field on the Claim entity, typically named 'State' or 'Status'.

Examples
OpenClosedDeniedReopened
Claim Type
ClaimType
The category of the insurance claim, such as Auto, Property, or Liability.
Description

Claim Type is a fundamental categorization of a claim based on the line of business or the nature of the loss. Different claim types often follow distinct processes, have different complexity levels, and are subject to different regulations.

Segmenting the process analysis by Claim Type is essential for meaningful insights. It allows for comparing process performance across different lines of business, identifying type-specific bottlenecks, and tailoring process improvement initiatives to the unique characteristics of each claim category.

Why it matters

Allows for segmentation of claims, as different types (e.g., Auto vs. Property) often follow different processes and have different performance targets.

Where to get

Derived from the Policy or Claim entity in ClaimCenter, often based on the Line of Business (LOB) code.

Examples
Personal AutoCommercial PropertyGeneral LiabilityWorkers Compensation
Claimed Amount
ClaimedAmount
The total monetary amount initially claimed by the policyholder.
Description

This attribute represents the value of the loss as reported by the claimant. It is often an initial estimate that may change as the claim is investigated and reserves are set.

Analyzing the Claimed Amount helps in segmenting claims by financial impact. High-value claims often follow a more rigorous, complex process than low-value ones. Comparing the process for different value bands can reveal opportunities to streamline handling for smaller claims or apply more stringent controls for larger ones.

Why it matters

Allows for segmenting claims by financial value, as high-value claims may follow different, more complex processes.

Where to get

This information might not be a single field but could be derived from the initial loss estimates recorded on exposures.

Examples
5000.00150000.00750.50
Date of Loss
LossDate
The date on which the incident or loss that triggered the claim occurred.
Description

The Date of Loss is the date of the actual event (e.g., car accident, property damage) for which the claim is being made. This is distinct from the date the claim was reported or created.

The time lag between the Date of Loss and the 'Claim Created' activity (known as reporting lag) is an important KPI. Analyzing this can provide insights into customer behavior and the effectiveness of first notice of loss channels.

Why it matters

Provides crucial context about the claim's origin and helps analyze reporting lag (time from incident to claim submission).

Where to get

This is a fundamental date field on the Claim entity, often named 'LossDate'.

Examples
2023-05-102023-04-202023-05-28
Department
Department
The business unit or department responsible for handling the claim activity.
Description

This attribute indicates the department or team to which the assigned adjuster belongs, such as 'Auto Claims', 'Property Claims', or 'Special Investigations Unit'. It provides an organizational context for the process.

Analyzing by Department is crucial for understanding process performance at an organizational level. It helps identify inter-departmental hand-off delays, compare efficiency between teams, and allocate resources more effectively across the claims organization.

Why it matters

Provides organizational context, allowing for performance analysis across different teams and highlighting inter-departmental hand-off issues.

Where to get

This information is typically associated with the assigned user's or group's profile within ClaimCenter.

Examples
Auto Claims DivisionProperty Claims UnitSpecial Investigations Unit (SIU)
End Time
EndTime
The timestamp indicating when an activity was completed.
Description

The End Time marks the completion of an activity, especially for tasks that have a measurable duration, like 'Investigation' or 'Document Review'. While many process mining activities are instantaneous (StartTime is sufficient), activities with a distinct start and end are better represented with both timestamps.

This attribute allows for the precise calculation of activity processing time, distinct from waiting time. It helps in identifying which specific tasks are time-consuming, rather than just observing long delays between different steps.

Why it matters

It enables the precise measurement of how long an activity takes to complete, separating processing time from waiting time.

Where to get

This may need to be derived by finding a subsequent event that logically concludes the activity (e.g., status change from 'In Progress' to 'Completed').

Examples
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Is Automated
IsAutomated
A flag indicating whether an activity was performed automatically by the system or by a human user.
Description

This boolean attribute distinguishes between activities executed by a system (e.g., automatic reserve creation, system-generated correspondence) and those performed manually by an adjuster.

Analyzing this attribute is key to understanding the level of automation in the claims process. It helps identify manual intervention hotspots, measure the effectiveness of straight-through processing initiatives, and find new opportunities for automation by pinpointing repetitive, rule-based tasks currently performed by humans.

Why it matters

Distinguishes between system-driven and human-driven activities, which is key for automation analysis and identifying manual bottlenecks.

Where to get

This often needs to be derived. For example, events logged by a generic 'system' user can be flagged as automated.

Examples
truefalse
Is Rework
IsRework
A flag indicating if an activity represents a rework loop, meaning a return to a previous process stage.
Description

This calculated attribute flags activities that are part of a rework loop. For example, if the process moves from 'Investigation Completed' back to 'Investigation Started', the second 'Investigation Started' activity would be flagged as rework.

Identifying rework is fundamental to uncovering process inefficiencies and quality issues. The Rework and Rejection Frequency dashboard relies on this metric to quantify how often claims deviate from the ideal 'happy path'. Analyzing the causes of rework can lead to significant improvements in process quality and speed.

Why it matters

Highlights process inefficiencies and quality issues by explicitly flagging activities that are part of a rework loop.

Where to get

This is calculated within the process mining tool by analyzing the sequence of activities for each case.

Examples
truefalse
Jurisdiction State
JurisdictionState
The state or jurisdiction governing the claim, which dictates regulatory requirements.
Description

This attribute specifies the legal jurisdiction (e.g., the US state) under which the claim is being handled. Insurance regulations can vary significantly between jurisdictions, impacting required process steps, communication timelines, and documentation.

This is a vital attribute for compliance monitoring. Analyzing the process by jurisdiction ensures that state-specific regulatory requirements are being met. It can also explain variations in cycle times or process paths that are driven by legal constraints rather than operational inefficiency.

Why it matters

Crucial for compliance analysis, as different jurisdictions have different regulations that affect the claims process.

Where to get

A standard field on the Claim entity, typically named 'JurisdictionState'.

Examples
CANYTXFL
Last Data Update
LastDataUpdate
The timestamp indicating when the data was last refreshed or extracted from the source system.
Description

This attribute provides the timestamp of the most recent data pull from the source system. It is a metadata field that is essential for understanding the freshness of the analysis.

Dashboards and analyses should display this information prominently so that users are aware of the data's currency. It helps in assessing whether the insights reflect the current state of operations or are based on older data.

Why it matters

Indicates the freshness of the data, ensuring users understand how current the process analysis is.

Where to get

This value is generated and stored during the ETL process, representing the timestamp of the data load.

Examples
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Payment Amount
PaymentAmount
The actual amount of money paid for a payment activity.
Description

This attribute records the value of each individual payment made against a claim. A single claim can have multiple payments over its lifecycle.

This is essential for financial analysis within the process mining context. It can be used to track the total payout per claim, analyze payment approval times based on amount, and link process inefficiencies to financial outcomes. For example, claims with long cycle times might correlate with higher total payments.

Why it matters

Tracks the financial transactions within a claim, enabling analysis of payment values and their relation to process activities.

Where to get

Found in Payment-related entities linked to the claim, often in a transaction or check table.

Examples
4500.00125000.00500.00
Policy Type
PolicyType
The specific type of insurance policy under which the claim was filed.
Description

Policy Type provides a more granular classification than Claim Type, detailing the specific insurance product, such as 'Homeowners', 'Commercial Auto', or 'Cyber Liability'. This level of detail can reveal process variations tied to specific products.

Analyzing the process by Policy Type helps uncover product-specific inefficiencies. For example, claims for a newly launched policy might follow a less mature process, leading to delays. This analysis can inform product design and process standardization efforts.

Why it matters

Enables process analysis for specific insurance products, helping to identify variations in handling based on policy specifics.

Where to get

This information is located in the Policy entity, which is linked to the Claim.

Examples
Homeowners Multi-PerilCommercial Auto LiabilityInland Marine
Processing Time
ProcessingTime
The duration spent actively working on an activity.
Description

Processing Time measures the time an activity is actively being worked on, calculated as the difference between its End Time and Start Time. This is distinct from cycle time, which includes waiting periods.

This calculated metric is vital for performance analysis as it isolates the true effort required for a task from idle or wait time. It helps to accurately identify which steps are genuinely time-consuming and where efficiency gains can be made through training, better tools, or process redesign.

Why it matters

Measures the active work time for an activity, helping to distinguish value-added time from waiting time.

Where to get

Calculated field: EndTime - StartTime. Requires both timestamps to be available in the source data.

Examples
PT8HPT15MP2D
Repeated Info Request
RepeatedInfoRequestFlag
A flag that indicates if 'Additional Info Requested' has occurred more than once for the same claim.
Description

This boolean flag is set to true if a claim has more than one 'Additional Info Requested' activity. This scenario often points to inefficiencies in the initial information-gathering phase.

This attribute directly supports the 'Repeated Info Request Rate' KPI. It helps quantify the problem of incomplete initial fact-finding, which can lead to significant delays and customer frustration. Analyzing claims with this flag can help improve checklists and procedures for adjusters to ensure all necessary information is requested at once.

Why it matters

Identifies inefficiencies where information gathering is not done completely the first time, leading to process delays and rework.

Where to get

Calculated within the process mining tool by counting the occurrences of the 'Additional Info Requested' activity per case.

Examples
truefalse
Resolution Target Date
ResolutionTargetDate
The date by which the claim is expected to be resolved according to internal or regulatory SLAs.
Description

The Resolution Target Date is a deadline set for claim closure, often determined by factors like jurisdiction, claim type, and policy terms. It serves as a benchmark for measuring performance and compliance.

This attribute is critical for building SLA adherence dashboards and KPIs. By comparing the actual 'Claim Closed' date to this target date, the analysis can automatically flag late claims, measure on-time performance rates, and identify which types of claims or departments are struggling to meet their targets.

Why it matters

This is the benchmark for measuring Service Level Agreement (SLA) adherence and identifying claims at risk of being late.

Where to get

This may be a custom field or derived based on business rules configured in ClaimCenter, possibly related to specific claim metrics.

Examples
2023-06-142023-07-202023-08-28
SLA Status
SLAState
Indicates whether the claim was closed within its resolution target date.
Description

This calculated attribute provides a categorical status of SLA adherence for each closed claim. It is derived by comparing the 'Claim Closed' activity's timestamp with the 'Resolution Target Date'.

This attribute directly supports the 'Claim Resolution Target Adherence' dashboard by simplifying the analysis into clear categories like 'On Time' or 'Late'. It allows for easy filtering and aggregation to calculate the overall SLA adherence rate and to drill down into the reasons for delays.

Why it matters

Provides a clear, categorical outcome for SLA adherence, making it easy to filter, aggregate, and analyze on-time performance.

Where to get

Calculated field: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late').

Examples
On TimeLate
Source System
SourceSystem
The system from which the data was extracted.
Description

This attribute identifies the origin of the event data. In a modern enterprise landscape, claim-related events might originate from multiple systems, such as a core system like Guidewire, a document management system, or a customer portal.

Specifying the source system is crucial for data governance, troubleshooting data inconsistencies, and understanding the technological landscape of the process. It helps differentiate between core process steps and supporting activities from peripheral systems.

Why it matters

Identifies the data's origin, which is crucial for data governance and for analyses involving multiple integrated systems.

Where to get

This is typically a static value added during the data extraction, transformation, and loading (ETL) process.

Examples
Guidewire ClaimCenter v10Customer Portal APIDocumentum
Required Recommended Optional

Claims Processing Activities

These are the key process steps and significant milestones to capture in your event log for precise claims process discovery and analysis.
7 Recommended 7 Optional
ActivityDescription
Claim Closed
Marks the successful closure of a claim after all activities and payments are complete. This is the primary successful end event, inferred from a change in the claim's main status.
Why it matters

As the primary end event, this activity is essential for calculating end-to-end cycle time and measuring SLA adherence. It signifies the completion of the claim lifecycle.

Where to get

Inferred from a change in the State field of the cc_claim table to 'Closed'. The event timestamp is the CloseDate on the claim record.

Capture

Identify when the claim's master status field is updated to 'Closed'.

Event type inferred
Claim Created
This activity marks the first notice of loss (FNOL) and the official creation of a new claim record in Guidewire ClaimCenter. It is captured explicitly when a new Claim entity is saved to the database for the first time.
Why it matters

As the primary start event, this activity is essential for measuring the end-to-end claim cycle time. It provides the baseline for all subsequent performance and duration KPIs.

Where to get

This is an explicit event captured from the CreateTime of the cc_claim table. The creation of a new record with a unique Claim ID serves as the event trigger.

Capture

Identify the creation timestamp of the new record in the base Claim entity table.

Event type explicit
Claim Denied
Represents the final decision to deny a claim, serving as a terminal endpoint for the process. This event is inferred from the claim's status changing to a closed state with a reason of 'Denied'.
Why it matters

This is a critical outcome event. Analyzing the frequency, reasons, and process paths leading to denials helps identify issues with claim intake, investigation, or policy interpretation.

Where to get

Inferred from a change in the State field of the cc_claim table to 'Closed', combined with the CloseReason field being 'Denied' or a similar value. The event timestamp is the CloseDate.

Capture

Filter for claim status changes to 'Closed' where the reason code indicates denial.

Event type inferred
Exposure Created
This activity signifies the creation of an exposure, which represents a specific potential liability or type of loss under the claim (e.g., vehicle damage, injury). This is an explicit event in Guidewire.
Why it matters

Exposures are fundamental to claim segmentation and analysis. Tracking their creation helps understand process variations based on claim complexity and type of loss.

Where to get

Captured from the CreateTime of a new record in the cc_exposure table. Each record is linked back to a single Claim ID.

Capture

Identify the creation timestamp of a new record in the Exposure entity table.

Event type explicit
Initial Reserve Set
Marks the creation of the first financial reserve transaction for an exposure, estimating the potential cost of the claim. This is a critical financial event and is captured explicitly.
Why it matters

This milestone is key for financial analysis and understanding how quickly potential liability is assessed. Delays can impact financial planning and reporting.

Where to get

This event is captured from the creation of the first cc_reserveline record associated with an exposure on the claim. The transaction's CreateTime is the event timestamp.

Capture

Find the minimum creation timestamp of all reserve lines for a given claim's exposures.

Event type explicit
Payment Approved
Represents the formal approval of a settlement payment. This is a critical audit event and is explicitly captured when a user with authority approves the transaction.
Why it matters

This key milestone unblocks the final payment step. Analyzing time before and after this activity helps isolate delays caused by approval workflows or manager availability.

Where to get

This is often an explicit event logged in the cc_history table related to a cc_check or cc_transaction entity, recording a status change from 'Pending Approval' to 'Approved'.

Capture

Track the status change event to 'Approved' for a specific payment transaction.

Event type explicit
Payment Issued
This activity marks the final step in the payment process, where the payment is officially issued and sent to the financial system. This is an explicit, logged financial transaction.
Why it matters

This activity is crucial for measuring the efficiency of the payment dispatch process. It helps differentiate between approval delays and delays in the actual issuance of funds.

Where to get

Captured from the IssueDate or a status change to 'Issued' or 'Submitted' on the cc_check or cc_transaction entity. This is often an explicit timestamped event.

Capture

Identify the IssueDate or the timestamp of the status change to 'Issued' on the payment record.

Event type explicit
Additional Info Received
Marks the completion of a request for additional information. This is captured when the corresponding 'Activity' (task) for information request is marked as 'Completed'.
Why it matters

This is the endpoint for the 'Additional Info Gathering Cycle Time' KPI. Long durations between request and receipt are common sources of delay in the claims process.

Where to get

Captured from the CloseTime of a cc_activity record where the ActivityPattern relates to an information request. The status of the activity must be 'Completed'.

Capture

Identify the completion timestamp of a task for requesting external information.

Event type explicit
Additional Info Requested
Represents a request sent to the claimant or a third party for more information or documentation. This is typically captured as an explicit 'Activity' (task) created in ClaimCenter.
Why it matters

This activity is the starting point for measuring the 'Additional Info Gathering Cycle Time' KPI. Frequent occurrences can signal incomplete FNOL processes or inefficient information gathering.

Where to get

Captured from the CreateTime of a cc_activity record where the ActivityPattern is related to requesting documentation or information from an external party.

Capture

Identify the creation of a task for requesting external information.

Event type explicit
Claim Assigned
Represents the assignment of a claim to a specific user (adjuster) or group for handling. This is typically inferred by monitoring changes to the assignment fields on the Claim entity.
Why it matters

Tracking assignments is critical for analyzing adjuster workload, identifying routing bottlenecks, and measuring the time-to-first-action by the assigned handler.

Where to get

Inferred from the cc_history table by tracking changes to the AssignedUser or AssignedGroup fields associated with a specific Claim ID. The timestamp of the change indicates when the event occurred.

Capture

Monitor audit logs or history tables for updates to the claim assignment fields.

Event type inferred
Claim Reopened
Represents a claim being moved from a 'Closed' state back to an 'Open' state to perform additional work. This event is inferred from a specific status change sequence.
Why it matters

This activity signifies rework. High volumes of reopened claims indicate issues with initial settlement, missed damages, or other process failures, leading to increased costs and inefficiency.

Where to get

Inferred from the cc_history table by identifying a change in the State field of the cc_claim entity from 'Closed' back to 'Open' or another active state.

Capture

Monitor the claim's master status field for a transition from a closed state to an open one.

Event type inferred
Investigation Started
Indicates the formal beginning of the investigation phase for a claim or exposure. This is often inferred from the creation of the first investigation-related 'Activity' (task) in Guidewire.
Why it matters

This activity marks the start of a key, often lengthy, phase. Analyzing the time until investigation starts and the duration of the investigation itself reveals major bottlenecks.

Where to get

Inferred from the CreateTime of a cc_activity record where the ActivityPattern is related to investigation (e.g., 'Initial Investigation', 'Contact Witness').

Capture

Identify the first creation of a task with an investigation-related pattern or subject.

Event type inferred
Liability Decision Made
Signifies the point at which a decision on liability or fault has been determined for an exposure. This event is typically inferred from a status change on the Exposure entity.
Why it matters

This is a critical decision milestone that gates the settlement and payment phases. Analyzing the time to this decision helps identify bottlenecks in the investigation and assessment stages.

Where to get

Inferred from the cc_history table by tracking a change in the State or a custom liability status field on the cc_exposure entity. The timestamp of the history record indicates the event time.

Capture

Monitor audit logs or history tables for updates to the exposure's state or liability status.

Event type inferred
Settlement Calculated
This activity represents the point where a settlement amount has been determined but not yet approved for payment. It can be inferred from the creation of a payment in a 'Pending Approval' state.
Why it matters

Marks the transition from assessment to payment. It's the starting point for measuring the 'Payment Authorization Lead Time' KPI, revealing delays in the approval chain.

Where to get

Inferred from the CreateTime of a cc_check or cc_transaction record where its initial status is 'Pending Approval' or a similar state before 'Approved'.

Capture

Identify the creation of a payment or transaction record in a pre-approved status.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from Guidewire ClaimCenter