Data Template: Claims Processing
Your Claims Processing Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance for Guidewire ClaimCenter
Claims Processing Attributes
| Name | Description | ||
|---|---|---|---|
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 | |||
Claims Processing Activities
| Activity | Description | ||
|---|---|---|---|
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 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 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 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 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 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 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 Capture Identify the 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 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 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 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 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 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 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 Capture Identify the creation of a payment or transaction record in a pre-approved status. Event type inferred | |||
Extraction Guides
Steps
- Prerequisites Verification: Confirm you have the necessary permissions and credentials to access the Guidewire DataHub / InfoCenter data mart database with read privileges. Ensure the ETL jobs that populate the claims data mart are running successfully and the data is up-to-date.
- Database Connection: Use a standard SQL client (such as DBeaver, SQL Server Management Studio, or similar tools) to establish a connection to the data mart database server.
- Schema Exploration: Before running the full query, familiarize yourself with the data mart schema. Identify the primary tables for claims, exposures, activities, and financial transactions. Key tables are typically named with suffixes like
_dim(dimension) and_fact(fact). This will help you validate the placeholder table and column names in the provided script. - Prepare the SQL Query: Copy the complete SQL script provided in the
querysection into your SQL client's query editor. - Customize Placeholders: Carefully review the script and replace all placeholder values. This includes the database/schema name (e.g.,
[YourDataMart]), date range parameters ('[StartDate]','[EndDate]'), and any system-specific configuration values (e.g., activity patterns, status codes). - Query Execution: Execute the modified SQL query against the data mart. The execution time may vary depending on the selected date range and the volume of data in your system.
- Initial Data Review: Once the query completes, inspect the first few hundred rows of the result set. Check that the columns
ClaimID,ActivityName, andEventTimeare populated as expected and that different activity types are present. - Export to CSV: Export the entire result set from your SQL client to a CSV file. Name the file descriptively, for example,
guidewire_claimcenter_event_log.csv. - Format for ProcessMind: Ensure the CSV file is saved with UTF-8 encoding. Verify that the file has a header row matching the column aliases in the SQL query. The file is now ready to be uploaded to ProcessMind.
Configuration
- Data Source: Guidewire DataHub/InfoCenter Claims Data Mart. This is a pre-aggregated, dimensional database designed for reporting and analytics, separate from the live ClaimCenter production database.
- Required Authorizations: Read-only access to the SQL database hosting the data mart. You will need a username, password, and connection details (server address, database name).
- ETL Job Status: The accuracy of this extraction depends on the successful and timely execution of the Guidewire ETL jobs that populate the data mart. Verify the last successful run time to understand the data's freshness.
- Date Range Filtering: The provided query includes
WHEREclauses with'[StartDate]'and'[EndDate]'placeholders. It is recommended to start with a limited date range (e.g., 3-6 months) to manage performance. The date filter is applied on theCreateTimeof the claim. - Configuration-Specific Values: Guidewire is highly configurable. You must adjust values in
WHEREclauses to match your organization's setup. This includes:ActivityPatternnames (e.g., 'fnol', 'investigation', 'Request additional information')ClaimStatus,ExposureStatus, andCloseReasoncodes (e.g., 'denied', 'closed')TransactionStatuscodes (e.g., 'pendingapproval', 'approved', 'issued')
- Performance: Querying large history or audit tables can be resource-intensive. Executing the query during off-peak hours is recommended for very large datasets. Ensure the
ClaimIDorClaimNumbercolumns are indexed on the relevant tables.
a Sample Query sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';Steps
- Prerequisites Verification: Confirm you have the necessary permissions and credentials to access the Guidewire DataHub / InfoCenter data mart database with read privileges. Ensure the ETL jobs that populate the claims data mart are running successfully and the data is up-to-date.
- Database Connection: Use a standard SQL client (such as DBeaver, SQL Server Management Studio, or similar tools) to establish a connection to the data mart database server.
- Schema Exploration: Before running the full query, familiarize yourself with the data mart schema. Identify the primary tables for claims, exposures, activities, and financial transactions. Key tables are typically named with suffixes like
_dim(dimension) and_fact(fact). This will help you validate the placeholder table and column names in the provided script. - Prepare the SQL Query: Copy the complete SQL script provided in the
querysection into your SQL client's query editor. - Customize Placeholders: Carefully review the script and replace all placeholder values. This includes the database/schema name (e.g.,
[YourDataMart]), date range parameters ('[StartDate]','[EndDate]'), and any system-specific configuration values (e.g., activity patterns, status codes). - Query Execution: Execute the modified SQL query against the data mart. The execution time may vary depending on the selected date range and the volume of data in your system.
- Initial Data Review: Once the query completes, inspect the first few hundred rows of the result set. Check that the columns
ClaimID,ActivityName, andEventTimeare populated as expected and that different activity types are present. - Export to CSV: Export the entire result set from your SQL client to a CSV file. Name the file descriptively, for example,
guidewire_claimcenter_event_log.csv. - Format for ProcessMind: Ensure the CSV file is saved with UTF-8 encoding. Verify that the file has a header row matching the column aliases in the SQL query. The file is now ready to be uploaded to ProcessMind.
Configuration
- Data Source: Guidewire DataHub/InfoCenter Claims Data Mart. This is a pre-aggregated, dimensional database designed for reporting and analytics, separate from the live ClaimCenter production database.
- Required Authorizations: Read-only access to the SQL database hosting the data mart. You will need a username, password, and connection details (server address, database name).
- ETL Job Status: The accuracy of this extraction depends on the successful and timely execution of the Guidewire ETL jobs that populate the data mart. Verify the last successful run time to understand the data's freshness.
- Date Range Filtering: The provided query includes
WHEREclauses with'[StartDate]'and'[EndDate]'placeholders. It is recommended to start with a limited date range (e.g., 3-6 months) to manage performance. The date filter is applied on theCreateTimeof the claim. - Configuration-Specific Values: Guidewire is highly configurable. You must adjust values in
WHEREclauses to match your organization's setup. This includes:ActivityPatternnames (e.g., 'fnol', 'investigation', 'Request additional information')ClaimStatus,ExposureStatus, andCloseReasoncodes (e.g., 'denied', 'closed')TransactionStatuscodes (e.g., 'pendingapproval', 'approved', 'issued')
- Performance: Querying large history or audit tables can be resource-intensive. Executing the query during off-peak hours is recommended for very large datasets. Ensure the
ClaimIDorClaimNumbercolumns are indexed on the relevant tables.
a Sample Query sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';Steps
- Prerequisites Verification: Confirm you have the necessary permissions and credentials to access the Guidewire DataHub / InfoCenter data mart database with read privileges. Ensure the ETL jobs that populate the claims data mart are running successfully and the data is up-to-date.
- Database Connection: Use a standard SQL client (such as DBeaver, SQL Server Management Studio, or similar tools) to establish a connection to the data mart database server.
- Schema Exploration: Before running the full query, familiarize yourself with the data mart schema. Identify the primary tables for claims, exposures, activities, and financial transactions. Key tables are typically named with suffixes like
_dim(dimension) and_fact(fact). This will help you validate the placeholder table and column names in the provided script. - Prepare the SQL Query: Copy the complete SQL script provided in the
querysection into your SQL client's query editor. - Customize Placeholders: Carefully review the script and replace all placeholder values. This includes the database/schema name (e.g.,
[YourDataMart]), date range parameters ('[StartDate]','[EndDate]'), and any system-specific configuration values (e.g., activity patterns, status codes). - Query Execution: Execute the modified SQL query against the data mart. The execution time may vary depending on the selected date range and the volume of data in your system.
- Initial Data Review: Once the query completes, inspect the first few hundred rows of the result set. Check that the columns
ClaimID,ActivityName, andEventTimeare populated as expected and that different activity types are present. - Export to CSV: Export the entire result set from your SQL client to a CSV file. Name the file descriptively, for example,
guidewire_claimcenter_event_log.csv. - Format for ProcessMind: Ensure the CSV file is saved with UTF-8 encoding. Verify that the file has a header row matching the column aliases in the SQL query. The file is now ready to be uploaded to ProcessMind.
Configuration
- Data Source: Guidewire DataHub/InfoCenter Claims Data Mart. This is a pre-aggregated, dimensional database designed for reporting and analytics, separate from the live ClaimCenter production database.
- Required Authorizations: Read-only access to the SQL database hosting the data mart. You will need a username, password, and connection details (server address, database name).
- ETL Job Status: The accuracy of this extraction depends on the successful and timely execution of the Guidewire ETL jobs that populate the data mart. Verify the last successful run time to understand the data's freshness.
- Date Range Filtering: The provided query includes
WHEREclauses with'[StartDate]'and'[EndDate]'placeholders. It is recommended to start with a limited date range (e.g., 3-6 months) to manage performance. The date filter is applied on theCreateTimeof the claim. - Configuration-Specific Values: Guidewire is highly configurable. You must adjust values in
WHEREclauses to match your organization's setup. This includes:ActivityPatternnames (e.g., 'fnol', 'investigation', 'Request additional information')ClaimStatus,ExposureStatus, andCloseReasoncodes (e.g., 'denied', 'closed')TransactionStatuscodes (e.g., 'pendingapproval', 'approved', 'issued')
- Performance: Querying large history or audit tables can be resource-intensive. Executing the query during off-peak hours is recommended for very large datasets. Ensure the
ClaimIDorClaimNumbercolumns are indexed on the relevant tables.
a Sample Query sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';