Data Template: Claims Processing

The Activity Name describes a specific step, task, or event within the claims processing lifecycle. These activities represent the work being done, such as 'Claim Registered', 'Investigation Started', or 'Payment Issued'. Each activity is a distinct point in the process captured in the event log.

For process mining analysis, activities are the building blocks of the process map. Analyzing the sequence, frequency, and duration of these activities reveals the actual process flow, common pathways, bottlenecks, and deviations from the standard procedure. Clear and consistent activity naming is crucial for creating an understandable and actionable process model.

Activities form the core of the process map, defining the steps and tasks whose sequence and duration are analyzed to understand process performance.

Typically found in event logs, audit trails, or transaction records within the claims management system.

The Claim ID is a unique key assigned to each insurance claim upon its registration. It acts as the central thread that connects all related activities, events, and data points throughout the claim's lifecycle, from initial submission to final closure.

In process mining, the Claim ID is fundamental for reconstructing the end-to-end journey of each claim. By grouping all events with the same Claim ID, the software can visualize the process flow, identify variations, and calculate case-level metrics. It ensures that every action, from adjuster assignment to payment issuance, is correctly attributed to the specific claim it belongs to, enabling a coherent and accurate process analysis.

This is the essential case identifier that links all related events together, making it possible to trace the end-to-end journey of each claim.

Typically found in the header or primary record of a claim file or claim management system transaction.

The Start Time is a precise date and time marker indicating the moment an activity commenced. It is a critical piece of data for each event in the process log, providing the temporal context needed for performance analysis.

In process mining, Start Time is essential for ordering events chronologically to reconstruct the case journey accurately. It is the basis for calculating key performance indicators such as cycle times, waiting times, and processing times. Analyzing timestamps helps identify delays between steps, measure adherence to service level agreements (SLAs), and understand the temporal dynamics of the claims process.

This timestamp is essential for ordering events correctly and calculating all time-related metrics, such as cycle times and bottlenecks.

Typically recorded in event logs, audit trails, or transaction data, often labeled as 'event time' or 'creation date'.

Last Data Update indicates the last time the event log data was refreshed from the source systems. This timestamp provides context on the freshness of the data being analyzed, ensuring that stakeholders are aware of the data's currency.

In any process analysis, knowing the timeliness of the data is critical for making informed decisions. This attribute helps users understand if they are viewing a near real-time process or a historical snapshot. It is particularly important for ongoing monitoring dashboards and for ensuring that any conclusions drawn are based on relevant and up-to-date information.

Provides crucial context on the timeliness of the data, ensuring that analysis and decisions are based on up-to-date information.

This is typically metadata generated during the data extraction, transformation, and loading (ETL) process.

The Source System attribute identifies the specific IT application or platform where the activity was originally recorded. In complex environments, claims processing data may come from multiple systems, such as a core claims platform, a document management system, or a customer relationship management (CRM) tool.

Understanding the source system is valuable for data validation and for analyzing process fragmentation. It helps in tracing data quality issues back to their origin and can reveal inefficiencies caused by manual data transfers or work handoffs between different systems. This analysis can highlight opportunities for better system integration and automation.

Identifies the origin of event data, which is crucial for data validation and for analyzing process execution across multiple IT systems.

This information may be part of the data extraction logic or stored as a field in the event logs of integrated systems.

The Assigned Adjuster identifies the individual employee or user who performed a specific activity or is responsible for the claim at a certain point in time. This attribute links process steps to the human resources executing them.

Analyzing data by adjuster is crucial for workload management, performance evaluation, and identifying training needs. It allows managers to compare performance across team members, ensure equitable distribution of work, and spot high-performers or those who may require additional support. This resource-level view is key for dashboards related to team performance and workload balance.

Links process activities to the individuals who perform them, enabling analysis of workload, team performance, and resource allocation.

Found in transaction records, audit logs, or user assignment fields within the claims management system.

Claim Severity provides an assessment of the claim's complexity, urgency, or potential financial cost. This classification helps in prioritizing claims and routing them to adjusters with the appropriate skill level. Severity can be determined by factors like the estimated loss amount, the nature of the incident, or the presence of litigation.

Analyzing the process based on Claim Severity is critical for understanding if handling procedures are appropriately tailored. For example, high-severity claims might be expected to have longer cycle times but should follow a more rigorous investigation path. This attribute helps verify that complex claims receive the necessary attention while simple claims are processed quickly, optimizing resource allocation and customer satisfaction.

Helps differentiate between simple and complex claims, enabling analysis of whether process execution is appropriately tailored to claim complexity.

Often determined by business rules at claim intake and stored as a field in the main claim record.

Claim Type is a classification that categorizes claims based on the line of business or nature of the loss, such as 'Auto', 'Property', 'Liability', or 'Disability'. Different claim types often follow distinct process paths and have different complexity levels and SLAs.

Segmenting the process analysis by Claim Type is a fundamental technique for gaining meaningful insights. It allows for the comparison of cycle times, costs, and process conformance across different categories. This analysis can reveal that a process that is efficient for auto claims may be inefficient for property claims, guiding targeted improvement efforts. This attribute is essential for the 'Performance by Claim Category' dashboard.

Allows for segmentation of claims to compare processes and performance across different business lines, revealing category-specific issues.

A standard field in the main claim record, typically set when the claim is first created.

The Department attribute specifies the organizational group responsible for a claim at a particular stage in its lifecycle. Examples include 'First Notice of Loss', 'Investigation Unit', or 'Payments Department'.

This information is vital for understanding handoffs and collaboration between different parts of the organization. Analyzing the process from a departmental view can reveal delays that occur when a claim moves from one team to another. It helps identify inter-departmental bottlenecks and is essential for assessing team-specific workloads and performance, supporting KPIs like Adjuster Workload Balance and dashboards on Team Performance.

Helps analyze process handoffs between teams and identify inter-departmental bottlenecks, supporting organizational performance analysis.

Typically stored in the claim record, often associated with the assigned user or the current process stage.

The End Time is a precise date and time marker indicating the moment an activity was concluded. When available alongside a Start Time, it allows for the exact measurement of how long an activity took to complete.

This attribute is extremely valuable for detailed performance analysis. The difference between Start Time and End Time provides the 'processing time' or 'activity duration', a key metric for identifying inefficient steps. Analyzing processing times helps pinpoint which activities consume the most resources and where efforts to streamline operations should be focused. It is fundamental for creating dashboards related to process bottlenecks and team performance.

Enables the precise calculation of activity processing times, which is critical for identifying bottlenecks and analyzing resource efficiency.

Typically found in event logs or audit trails alongside the start time. It might need to be derived if only change events are logged.

The Resolution Target Date, or due date, is the deadline set for completing the claims process. This date is often dictated by regulatory requirements or internal service level agreements (SLAs) designed to ensure timely customer service.

This attribute is fundamental for compliance and performance monitoring. By comparing the actual claim closure date with the target date, organizations can measure their SLA Adherence Rate. Process mining can highlight which process steps or variants are most likely to cause SLA breaches. This enables proactive management of deadlines and helps prioritize improvements that have the greatest impact on timely resolution, directly supporting the 'SLA and Deadline Adherence' dashboard.

Enables the measurement of on-time performance against SLAs or regulatory deadlines, a critical measure of process effectiveness.

Typically calculated based on business rules when a claim is created and stored in the main claim record.

The Settlement Amount represents the total monetary value paid out to settle a claim. This is a critical outcome metric that reflects the financial impact of the claim. It is typically determined after the loss has been assessed and a decision has been made.

In process mining, this attribute is essential for cost-based analysis. It allows for the calculation of KPIs like 'Average Cost per Claim' and enables investigation into how process variations affect financial outcomes. For instance, analysis might show that claims with certain rework loops or longer cycle times tend to result in higher settlement amounts. This provides a direct link between process efficiency and financial performance, underpinning the 'Claim Cost Analysis' dashboard.

This is a key outcome metric that directly links process behavior to financial impact, enabling cost-benefit analysis of process improvements.

Located in the financial or payment records associated with the claim, finalized upon claim closure or payment.

Claim Status indicates the state of the claim within its lifecycle at the time of an event. This status provides a high-level summary of where the claim is in the process, for example 'Under Investigation', 'Awaiting Information', or 'Settled'.

While process mining reconstructs the detailed flow from activities, the Claim Status attribute offers a valuable contextual layer. It can be used to validate the process flow (e.g., does a 'Payment Issued' activity correctly move the status to 'Closed'?) and to analyze the duration claims spend in particular states. This helps in understanding how long cases remain pending and can highlight systemic delays or inefficiencies.

Provides context on the state of a claim at any given time, helping to analyze time spent in different stages and validate the process flow.

A core field in the main claim record, which is updated as the claim progresses through its lifecycle.

The Claimed Amount is the initial estimate of the loss or the amount requested by the claimant at the start of the process. This value may be revised later during the investigation and assessment phase.

This attribute is useful for several types of analysis. It can be used to set an initial severity level for the claim and to track the variance between the initial claim and the final settlement amount. Analyzing this variance can provide insights into the accuracy of initial estimates and the effectiveness of the cost control measures within the claims process. It is a key input for financial forecasting and reserving.

Represents the initial financial scope of the claim, useful for severity assessment and for analyzing the variance with the final settlement amount.

Captured during the initial claim filing process and stored in the financial section of the claim record.

The Denial Reason is a code or text description that explains why a claim was not paid. Reasons can range from issues with coverage under the policy, fraudulent activity, or failure to provide required documentation.

Analyzing denial reasons is crucial for identifying opportunities to improve both internal processes and customer communication. For example, if a large number of claims are denied due to missing information, it may indicate a need to improve the intake process. Root cause analysis on denial reasons can lead to clearer policy language, better customer education, and reduced administrative effort spent on claims that will ultimately be denied.

Provides insight into why claims are not paid, enabling root cause analysis to improve customer communication and front-end processes.

Selected from a predefined list or entered as text by an adjuster when a 'Claim Denied' activity occurs.

The Loss Date marks the actual date of the event (e.g., car accident, property damage) that led to the claim. This is distinct from the date the claim was reported or registered in the system.

The difference between the Loss Date and the claim registration date is known as the 'reporting lag'. Analyzing this lag is important for understanding customer behavior and identifying potential fraud risks (e.g., unusually long delays in reporting). It provides a more complete timeline of the entire claims experience, from incident to resolution, offering a broader view than just the internal processing time.

Establishes the date of the actual incident, allowing for analysis of reporting delays and the full timeline from event to closure.

Provided by the claimant during the 'First Notice of Loss' and stored in the main claim record.

The Policy Number is the unique reference for the insurance contract that covers the reported loss. It links the claim to a specific customer, policy terms, coverage limits, and other contractual details.

While not always directly used in the process flow analysis itself, the Policy Number is a crucial piece of contextual information. It allows for aggregating claim data at the policy or customer level, which can reveal patterns such as frequent claims by a single policyholder. It also enables enrichment of the claims data with policy-level details (e.g., policy type, coverage amount) for more advanced segmentation and analysis.

Links the claim to the specific insurance contract, enabling enrichment with policy data for deeper, more contextual analysis.

A fundamental piece of data captured at claim intake and stored in the header of the claim record.

The Submission Channel identifies how a claim was first reported to the company. Common channels include an online customer portal, a mobile app, an agent, a broker, or traditional mail.

Analyzing the process by submission channel can reveal important differences in data quality, efficiency, and customer experience. For example, claims submitted through a digital portal may have fewer data entry errors and faster initial processing times compared to those submitted by mail. These insights can inform strategic decisions about which channels to promote and where to invest in automation and process improvement.

Helps analyze how the intake channel impacts process efficiency, data quality, and overall cycle time.

Typically captured during the 'First Notice of Loss' (FNOL) process and stored in the main claim record.