Data Template: Claims Processing

This attribute describes a single step or milestone within the claims process, such as 'Claim Submitted', 'Initial Review Performed', or 'Payment Issued'. Each activity represents a distinct action taken on the claim.

Analyzing the sequence and frequency of these activities is the foundation of process mining. It reveals the actual process flow, helps identify bottlenecks where work queues up, and highlights common or exceptional pathways that claims follow.

It defines the steps in the process, allowing for the visualization of the process map and analysis of workflow patterns and deviations.

Typically derived from event logs, task status changes, or audit trails within the FINEOS Claims system.

The Claim ID is the fundamental key that links all activities, events, and data points throughout the lifecycle of a claim. It ensures that every touchpoint, from initial submission to final closure, can be cohesively tracked as part of a single case.

In process mining, this attribute is essential for reconstructing the end-to-end journey of each claim. It allows for the analysis of process flows, the calculation of total resolution times, and the identification of variations in how different claims are handled.

This is the core identifier that connects all related events into a single process instance, making end-to-end analysis of the claim lifecycle possible.

This is a primary key in the main claims case management tables within FINEOS Claims.

Event Time records the exact date and time that a claims processing activity took place. This chronological data is critical for ordering events correctly and understanding the timeline of a claim.

In analysis, this timestamp is used to calculate durations, cycle times, and waiting times between different steps. It is fundamental for identifying delays, measuring performance against SLAs, and understanding the temporal dynamics of the process.

This timestamp provides the chronological order of events, which is essential for calculating all time-based metrics like cycle time and identifying bottlenecks.

This information is typically available as a creation or update timestamp associated with each event or status record in FINEOS Claims.

This attribute provides the date and time when the data was most recently extracted or updated. It is important for understanding the freshness and currency of the data being analyzed.

This information is critical for data governance and for users to know if they are looking at the most current process data. It helps manage expectations about data latency and is vital for reporting on near-real-time processes.

Indicates the freshness of the data, ensuring users understand the time period covered by the analysis and when it was last refreshed.

This timestamp is typically generated and stored by the data extraction or ETL tool at the end of a data loading job.

This attribute specifies the origin of the process data. For this analysis, it will consistently be 'FINEOS Claims', but in a multi-system environment, it is crucial for tracing data lineage and ensuring data quality.

In a broader analytics context, it helps differentiate processes that may span multiple systems and ensures that data interpretation is correct based on its source.

It provides crucial context about the data's origin, which is essential for data governance, validation, and integration with other systems.

This is typically a static value added during the data extraction process to label the dataset's origin.

This attribute identifies the individual or team who performed a specific task in the claims process. It is the primary way to link process activities to human resources.

Analyzing data by Assigned Adjuster is critical for understanding workload distribution, individual performance, and resource efficiency. It can highlight overburdened adjusters, identify training opportunities by comparing performance, and support better resource allocation strategies to balance workloads.

This attribute connects process steps to the individuals who perform them, enabling workload analysis, resource efficiency evaluation, and performance comparisons.

Consult FINEOS Claims documentation. This information is typically stored in task ownership or user assignment fields associated with claim events.

Claim Severity provides a rating for the claim's complexity, urgency, or financial exposure. High-severity claims may require more steps, specialized review, or longer processing times compared to low-severity ones.

Analyzing the process by severity helps to understand if resource allocation and process design are appropriate for different levels of claim complexity. It can reveal if high-severity claims are disproportionately delayed or if low-severity claims are being over-processed, enabling better process segmentation and resource management.

Segmenting by severity helps to check if the process correctly prioritizes high-impact claims and identifies if certain complexity levels cause process bottlenecks.

Consult FINEOS Claims documentation. This may be a dedicated field or derived from other attributes like the estimated loss amount.

Claim Status indicates the state of the claim in its lifecycle, such as 'Open', 'Pending Information', 'Approved', 'Denied', or 'Closed'. This attribute provides a snapshot of where the claim stands at any given point.

In process analysis, changes in status often correspond directly to process activities. Tracking status is crucial for understanding claim outcomes, identifying bottlenecks where claims get stuck in a particular status for long periods, and analyzing the reasons for final outcomes like 'Denied' or 'Closed'.

This attribute is key for understanding claim outcomes, filtering for active vs. closed cases, and identifying stages where claims stagnate.

Consult FINEOS Claims documentation. This is a fundamental field on the main claim record that is updated throughout its lifecycle.

Claim Type classifies claims based on the nature of the policy or the loss. Different claim types often follow distinct process variations, have different regulatory requirements, and require specialized handling.

This is a critical dimension for comparative analysis. By filtering or segmenting the process view by Claim Type, analysts can uncover type-specific bottlenecks, compare performance across categories, and tailor process improvement initiatives to the unique needs of each claim type. It helps answer whether certain claim types are inherently less efficient to process.

It allows for segmentation of the process to compare performance and identify variations between different categories of claims, leading to more targeted improvements.

Consult FINEOS Claims documentation. This is a core attribute of a claim, typically set upon registration and stored in the main case table.

This attribute specifies the organizational unit, such as 'Initial Intake', 'Investigation Unit', or 'Payments Department', that is responsible for a particular activity or owns the claim at a certain stage.

Analyzing the process by department is crucial for understanding cross-functional handoffs, which are common sources of delay. It helps identify which departments are bottlenecks, measures departmental efficiency, and supports analysis of resource allocation across the organization.

Allows for performance analysis by organizational unit, highlighting inter-departmental handoff delays and departmental bottlenecks.

Consult FINEOS Claims documentation. This can be associated with the assigned adjuster's user profile or the queue to which a task is assigned.

The End Time attribute records the precise moment an activity concludes. Paired with the Start Time (EventTime), it allows for the exact calculation of how long each step took to complete (i.e., its processing time).

In analysis, this is crucial for distinguishing between active processing time and idle waiting time. It enables the creation of detailed bottleneck analyses, showing which specific activities consume the most time and where queues form between steps.

Enables the precise calculation of processing time for each activity, which is key to identifying inefficient steps and measuring resource utilization.

Consult FINEOS Claims documentation. This may be available in event logs or can be derived from the start time of the subsequent event.

This attribute represents the deadline for completing the claim process, as defined by service level agreements (SLAs) or regulatory requirements. It serves as a benchmark against which actual performance is measured.

This date is essential for monitoring SLA compliance. By comparing the actual claim closure date with the Resolution Target Date, it is possible to calculate the SLA compliance rate, identify claims at risk of breaching their SLA, and analyze the root causes of delays that lead to non-compliance.

This is the benchmark for measuring SLA compliance. It allows for the identification of late claims and the analysis of reasons for delays.

Consult FINEOS Claims documentation. This date is often calculated by business rules based on the claim submission date and type.

This attribute records how the claim was received, for example, through an online portal, via email, by physical mail, or through an agent. Different submission channels can have a significant impact on data quality and initial processing times.

Analyzing the process based on the submission channel helps to determine if certain channels lead to faster processing, higher rates of rework (e.g., due to missing information), or better outcomes. These insights can guide investments in channel optimization, such as improving online forms to reduce errors.

Helps determine if certain intake channels lead to more efficient processing or higher rework rates, informing channel strategy and investment.

Consult FINEOS Claims documentation. This is typically captured during the claim intake process and stored on the main claim record.

This attribute indicates the geographic location associated with the claim, which could be based on the claimant's address or the location of the loss.

Geographic analysis can reveal regional variations in claim types, frequencies, and processing efficiency. It can help identify if certain regional offices are performing better than others, or if there are location-specific factors (e.g., regulations, weather events) that impact the claims process. This enables more targeted management and resource allocation.

Allows for geographical segmentation to identify regional performance differences, compliance variations, or location-specific bottlenecks.

Consult FINEOS Claims documentation. This information is typically derived from the policyholder or claimant address details stored in the system.

When a claim's outcome is 'Denied', this attribute provides the specific reason for that decision. Reasons could include 'Not Covered by Policy', 'Fraud Suspected', or 'Incomplete Information'.

This is a vital attribute for root cause analysis of claim denials. By analyzing the frequency of different denial reasons, the organization can identify common issues in the submission process, areas of customer confusion about policy coverage, or potential training needs for adjusters. This insight can lead to initiatives that reduce denial rates and improve customer satisfaction.

Crucial for root cause analysis of failed processes, helping to identify opportunities to reduce claim denials and improve intake quality.

Consult FINEOS Claims documentation. This is typically a structured field or code selected when the 'Claim Denied' activity is performed.

This calculated attribute flags activities that represent rework, such as a second 'Additional Information Requested' event for the same claim. It is typically identified by detecting repeated activities or backward loops in the process flow.

Explicitly flagging rework simplifies analysis focused on inefficiency. It allows for easy quantification of the rework rate, a key performance indicator. Dashboards can use this flag to visualize the frequency and impact of rework, helping to pinpoint the root causes of these inefficient loops.

Directly flags inefficient process loops, making it easy to calculate the rework rate and analyze the drivers of repeated work.

This is derived during process mining analysis by identifying repeated activities for the same case. For example, flagging the second occurrence of 'Investigation Started'.

Loss Amount represents the initial estimate or the financial reserve set aside for a claim. This value can be updated as the claim is investigated and assessed.

This financial data is crucial for segmenting claims and understanding how financial impact correlates with process behavior. For example, it helps answer questions like: Do higher-value claims take longer to process or require more rework? It is also a key input for financial forecasting and risk management.

Provides financial context to the process, enabling analysis of how claim value impacts processing time, complexity, and pathways.

Consult FINEOS Claims documentation. This information is typically found in the financial or reserve-related tables linked to the claim.

The Loss Date specifies when the actual incident (e.g., accident, injury) took place. This is distinct from the date the claim was submitted and can be an important factor in claim validation and processing.

This attribute provides valuable context. The time lag between the Loss Date and the 'Claim Submitted' date (reporting lag) can be a key performance indicator. Analyzing this lag can reveal issues with reporting processes and its impact on the overall claim lifecycle.

Provides important context and allows for the calculation of reporting lag (time from loss to submission), which can impact claim complexity and outcomes.

Consult FINEOS Claims documentation. This date is a standard field captured during the 'First Notice of Loss' or claim registration process.

Payment Amount is the final sum disbursed upon claim settlement and approval. For claims with multiple payments, this may represent an individual payment transaction.

This attribute is essential for financial reconciliation and for analyzing the monetary outcomes of the process. It allows for comparisons between the initial estimated loss and the final payout. In process analysis, it helps to understand the financial impact of different process variants or decisions.

Tracks the financial outcome of the process, which is critical for measuring financial performance and analyzing the value of claims.

Consult FINEOS Claims documentation. This data is located in the payment transaction tables linked to the claim case.

The Policy Number is the identifier for the insurance contract that covers the claim. It links the claim to a specific customer, policy terms, and coverage details.

While not directly a process attribute, it provides essential business context. It allows for aggregating claims data by policy or customer, which can be useful for analyzing claim frequency, customer experience, and identifying policies that generate a high volume of complex claims.

Provides critical business context, linking the claim to a specific customer contract and enabling customer-centric process analysis.

Consult FINEOS Claims documentation. This is a fundamental piece of data captured at claim registration and stored on the main claim record.

Processing Time is a calculated metric that measures the elapsed time between the start and end of an activity. It represents the 'touch time' or the period when a resource was actively engaged with the task.

This is a fundamental metric for performance analysis. It helps distinguish active work time from idle waiting time, allowing for a more accurate assessment of resource efficiency and the identification of activities that are intrinsically time-consuming. It is a key input for calculating operational costs and adjuster utilization rates.

Measures the active 'touch time' for activities, helping to pinpoint which specific tasks are most time-consuming and to measure resource efficiency accurately.

This is calculated by subtracting the activity's StartTime from its EndTime.

This attribute captures the reason a claim was moved from a 'Closed' state back into an active one. Common reasons include the receipt of new information, an appeal from the claimant, or the correction of an error.

Analyzing reopen reasons is a direct way to measure process quality and finality. A high volume of reopened claims, particularly for certain reasons, indicates that the initial closure was flawed. This data can pinpoint weaknesses in the investigation or decision-making stages, providing clear targets for process improvement to ensure claims are closed correctly the first time.

Provides direct insight into process failures where a claim was closed prematurely or incorrectly, highlighting opportunities to improve first-time resolution.

Consult FINEOS Claims documentation. This reason is typically recorded when a user executes the 'Reopen Claim' action in the system.

This attribute provides a clear, categorical status on SLA performance for each claim. It is derived by comparing the 'Claim Closed' date to the 'Resolution Target Date' and classifying the outcome as 'On Time' or 'Late'.

This simplifies reporting and analysis of SLA adherence. Instead of working with raw dates, analysts can use this simple category to create dashboards showing the SLA compliance rate, filter for all late claims to analyze their common characteristics, and monitor trends in SLA performance over time. It directly supports the SLA Adherence dashboard and KPI.

Provides a clear, simple indicator of SLA performance for each case, making it easy to measure and analyze the SLA compliance rate.

This is a calculated field derived by comparing the final activity's timestamp with the 'ResolutionTargetDate' for each case.