您的索赔处理数据模板
您的索赔处理数据模板
- 建议收集的属性
- 建议跟踪的关键活动
- Duck Creek Claims数据提取指南
索赔处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 事件时间为理赔周期中记录的每项活动提供准确的日期和时间,是绩效分析的重要依据。 分析时,可使用此时间戳计算活动之间的周期时间、识别等待时间、衡量案例总时长,并分析不同时段的流程绩效。它是所有基于时间的流程指标的基础。 重要性 此时间戳对于计算周期时间和时长等所有时间指标至关重要,可用于分析绩效并识别瓶颈。 获取途径 这是Duck Creek Claims事件日志或交易日志中的标准时间戳字段。请查找“CreateDate”“Timestamp”或“EventDate”等字段。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 活动名称 ActivityName | 理赔案件在特定时间发生的业务活动或事件名称。 | ||
| 说明 此属性描述理赔流程中执行的具体步骤或任务,例如“理赔已提交”“已分配理赔员”或“款项已支付”。每项活动都代表理赔周期中的一个独立节点。 分析这些活动的顺序和频率是流程挖掘的核心。借此可以发现流程模型、识别瓶颈、检测返工循环,并分析流程与标准模型之间的偏差。 重要性 活动名称定义了流程中的各个步骤,是发现、分析和监控理赔流程的基础。 获取途径 通常可从Duck Creek Claims中的事件日志、交易名称或状态变更记录中获取。可能需要将多个源字段或表映射到此属性。 示例 理赔已提交已分配理赔员调查已开始款项已支付理赔已结案 | |||
| 理赔ID ClaimId | 单个保险理赔案件的唯一标识符,也是主要案例标识符。 | ||
| 说明 理赔ID是关键标识,用于关联单个保险理赔从提交到结案的所有事件和活动,确保能够连贯地跟踪理赔的整个周期。 在流程挖掘分析中,此属性对于构建案例视图至关重要。分析人员可以据此追踪每个理赔案件的完整过程、衡量端到端周期时间并分析流程变体。 重要性 这是关键的案例ID,用于关联流程中的所有相关事件,从而完整呈现理赔的整个周期。 获取途径 这是Duck Creek Claims主理赔实体或表中的主键。具体表名和字段名称请参阅系统文档。 示例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| 已分配理赔员 AssignedAdjuster | 在某项活动发生时,负责处理理赔案件的理赔员姓名或ID。 | ||
| 说明 此属性用于标识执行活动的用户或资源。随着案件在不同理赔员或团队之间交接,此属性可能在理赔周期中发生变化。 此属性对于分析资源绩效、工作量分配和交接情况至关重要。关注理赔员处理量、工作量差异和瓶颈的仪表板,通常会大量使用此属性,以了解工作如何分配给个人并由其处理。 重要性 可用于分析资源绩效、工作量平衡和协作模式,帮助识别瓶颈和培训需求。 获取途径 请参阅Duck Creek Claims文档。在与理赔任务、事件或主理赔实体相关的表中查找用户、所有者或受派人字段。 示例 约翰·史密斯简·多伊罗伯特·布朗adjuster_1138 | |||
| 损失金额 LossAmount | 索赔中申报损失的预估金额或实际金额。 | ||
| 说明 此属性表示与索赔相关的初始预估损失金额。这是一项重要的财务指标,通常会影响索赔的分派、严重程度和所需调查级别。 分析时,可按损失金额对索赔分组,了解财务影响与流程表现之间的关系。例如,高金额索赔可能经过不同的流程路径,或需要更长的周期时间。该属性为运营流程数据提供重要的财务背景。 重要性 为索赔提供财务背景,便于分析索赔金额如何影响处理路径、时长和结果。 获取途径 请查阅Duck Creek Claims文档。这是索赔中的核心财务字段,通常称为“申报损失”或“初始准备金”。 示例 1500.0025000.50125000.00 | |||
| 理赔严重程度 ClaimSeverity | 对理赔案件财务或运营复杂程度的分类,例如低、中或高。 | ||
| 说明 理赔严重程度用于表示理赔案件预期的影响或复杂程度。该属性可根据初始损失估算、事故性质或其他预定义业务规则确定。 此属性对于绩效分析至关重要,因为严重程度较高的理赔通常需要更多步骤、更长的处理时间和专业资源。按严重程度细分KPI,有助于设定切合实际的绩效目标,并了解复杂程度对流程效率和结果的影响。 重要性 有助于按复杂程度细分理赔案件,从而更细致地分析绩效,并为周期时间和成本设定切合实际的基准。 获取途径 请参阅Duck Creek Claims文档。此属性可能是专用字段,也可能根据初始损失准备金金额推导。 示例 低中等高灾难性 | |||
| 理赔类型 ClaimType | 理赔案件的类别,例如汽车、财产或责任理赔。 | ||
| 说明 理赔类型根据业务险种或损失性质对理赔案件进行分类,是细分和分析理赔数据的基本维度。 此属性用于比较不同类型理赔的流程绩效。例如,“汽车-全损”理赔与“财产-水损”理赔的流程和KPI可能大不相同。按理赔类型分析可以提供背景信息,支持更有意义的绩效比较和有针对性的流程改进。 重要性 这是分析细分的重要维度,因为不同理赔类型通常有各自的流程、服务级别协议(SLA)和复杂程度。 获取途径 请参阅Duck Creek Claims文档。这是主理赔记录中的核心属性。 示例 个人汽车-碰撞商业财产-火灾工伤赔偿一般责任 | |||
| 索赔状态 ClaimStatus | 索赔在某个时间点的整体状态,例如未结、待处理或已结案。 | ||
| 说明 索赔状态表示索赔在整个生命周期中的当前状态,可概括索赔在整体流程中的进展。 此属性适用于查看索赔库存概况和筛选案例。它对于识别索赔的最终结果尤为重要,例如“已结案-已赔付”或“已结案-已拒赔”,有助于分析结果并了解拒赔率。 重要性 呈现索赔的当前状态和最终结果,对于结果分析和案例筛选至关重要。 获取途径 请查阅Duck Creek Claims文档。这是索赔主记录中的基础字段。 示例 未结待处理-等待补充信息已结案-已和解已结案-已拒赔 | |||
| 部门 Department | 在特定时间负责处理活动或理赔案件的部门或团队。 | ||
| 说明 此属性用于指定处理理赔案件的职能组或部门,例如“初始受理”“调查部门”或“结算团队”,为流程提供组织架构背景。 按部门分析对于了解整体流程绩效至关重要,有助于识别部门间的瓶颈、衡量团队效率,并了解工作如何在组织内流转。 重要性 支持按职能领域分析绩效,突出显示跨部门交接和团队特有的瓶颈。 获取途径 请参阅Duck Creek Claims文档。此信息通常与受派用户的个人资料或队列、工作组分配相关联。 示例 汽车理赔财产理赔-重大损失特别调查部门付款处理 | |||
| 保单号 PolicyNumber | 提交索赔所依据保单的唯一标识符。 | ||
| 说明 此属性将索赔关联到对应的保险保单,提供与索赔相关的保障范围、条款和客户信息。 保单号不一定直接用于流程路径分析,但对于丰富索赔数据很有价值。您可以将其与保单和客户数据关联,分析不同客户群体、保单类型或保单年限下的流程表现,从而获得更全面的业务视角。 重要性 将索赔关联到客户和保单,以便进一步分析流程表现对不同客户群体或保单类型的影响。 获取途径 请查阅Duck Creek Claims文档。这是索赔主实体中的标准参考字段。 示例 PA-987654321CP-123456789WC-555444333 | |||
| 最近数据更新时间 LastDataUpdate | 源系统最近一次刷新数据的时间戳。 | ||
| 说明 此属性表示数据集最近一次更新的时间,可作为判断所分析数据新鲜度的参考。 在仪表板和分析中,此属性用于告知用户洞察所依据的数据更新时间,帮助用户判断流程视图是否包含最新交易。 重要性 告知用户数据的新鲜度,这对于解读分析结果和及时决策至关重要。 获取途径 此时间戳由数据提取、转换和加载(ETL)流程生成,通常存储在数据集的元数据中。 示例 2024-05-21T02:00:00Z | |||
| 和解金额 SettlementAmount | 双方最终商定用于解决索赔的金额。 | ||
| 说明 此属性记录经计算并获准支付的和解金额。对于获得赔付的索赔,这是重要的结果指标。 此属性对于财务分析以及“付款授权与发放时间”等仪表板至关重要。您可以将其与初始“损失金额”进行比较,分析准备金估算的准确性,并据此了解索赔流程的财务结果。 重要性 体现索赔的关键财务结果,是财务报告和分析初始损失估算准确性的必要数据。 获取途径 请查阅Duck Creek Claims文档。此信息通常存储在与索赔关联的财务交易表或付款相关表中。 示例 1450.7522000.00115800.20 | |||
| 拒赔原因 RejectionReason | 索赔被拒绝或驳回的具体原因。 | ||
| 说明 索赔决定为拒赔时,此属性用于记录拒赔的根本原因。通常从预设的代码或说明列表中选择。 分析拒赔原因对于“索赔决定与拒赔洞察”仪表板至关重要。这有助于发现提交材料中的常见问题、潜在欺诈模式,或保单条款表述不清之处。相关洞察可用于改进受理流程或核保规则。 重要性 说明索赔被拒的原因,为改进受理流程、减少无效提交和发现培训机会提供可行的洞察。 获取途径 请查阅Duck Creek Claims文档。索赔状态变为“已拒赔”或类似状态时,通常会填写此字段。 示例 不属于承保风险保单已过期重复索赔疑似欺诈 | |||
| 是否按时解决 IsOnTimeResolution | 计算得出的标记,用于指示索赔是否在目标解决日期当天或之前结案。 | ||
| 说明 此布尔属性通过比较索赔的“索赔结案”活动时间戳与“ResolutionTargetDate”得出,并将每项索赔标记为按时(true)或逾期(false)。 此属性直接支持“按时解决索赔率”KPI。它便于在仪表板中汇总和呈现SLA达成情况,也支持下钻分析,帮助识别逾期索赔的常见特征,例如特定索赔类型、部门或流程路径。 重要性 直接衡量单项索赔的SLA达成情况,便于筛选逾期索赔并分析根本原因。 获取途径 这不是源系统字段,而是在数据准备期间通过比较最后一项活动的时间戳与“ResolutionTargetDate”字段计算得出。 示例 truefalse | |||
| 是否自动执行 IsAutomated | 布尔标记,用于指示活动是否由系统自动执行且无需人工干预。 | ||
| 说明 此标记用于区分人工用户完成的任务和系统自动执行的任务,例如自动通知、初始数据验证或直通式处理步骤。 分析此属性有助于了解索赔流程的自动化程度、衡量自动化举措的影响、发现进一步自动化的机会,并确保自动化步骤按预期运行且不会引发后续问题。 重要性 有助于衡量自动化对效率和成本的影响,并发现实现直通式处理的机会。 获取途径 此信息可能根据事件关联的“用户”推断得出(例如“SYSTEM”或“BATCH”),也可能来自事件记录中的专用标记。 示例 truefalse | |||
| 是否返工 IsRework | 计算得出的标记,用于指示活动是否属于返工循环。 | ||
| 说明 如果索赔在发生其他不同活动后再次执行某项活动,此布尔属性将设为true。例如,流程从“损失评估”返回到“开始调查”。 此属性对于量化和分析返工至关重要。它支持“索赔返工率”KPI和“索赔返工与重新处理模式”仪表板,便于直接筛选并突出显示涉及返工的活动和案例,从而帮助发现流程中的低效环节和质量问题。 重要性 在活动层面量化返工,便于衡量、呈现和分析流程低效的原因及影响。 获取途径 这不是源系统字段,而是在数据准备期间通过算法检测案例中重复的活动序列计算得出。 示例 truefalse | |||
| 源系统 SourceSystem | 提取事件数据的系统。 | ||
| 说明 此属性用于标识理赔数据的来源应用。在此场景中,来源始终为“Duck Creek Claims”。 如果所有数据都来自同一系统,此属性看似多余,但对于数据治理、追溯数据来源以及未来整合多个系统的数据都至关重要。它能说明数据的来源和结构。 重要性 提供必要的数据血缘信息和背景,对于数据治理和故障排查至关重要,尤其是在集成多个系统的环境中。 获取途径 通常在数据提取和转换过程中添加静态值,用于标记数据来源。 示例 Duck Creek索赔 | |||
| 目标解决日期 ResolutionTargetDate | 根据服务级别协议(SLA)或内部目标,预计解决索赔的目标日期。 | ||
| 说明 此属性用于记录索赔结案的截止日期。该日期通常由监管要求、服务级别协议(SLA)或内部关键绩效指标(KPI)确定,也可能因索赔类型或严重程度而异。 此日期是计算“按时解决索赔率”KPI和支持“索赔解决目标达成情况”仪表板的依据。您可以据此主动监控可能违反SLA的索赔,并确定工作优先级。 重要性 用于衡量服务级别协议(SLA)和内部目标的达成情况,这会直接影响客户满意度和合规。 获取途径 请查阅Duck Creek Claims文档。此字段可能是专门的SLA日期字段,也可能根据索赔提交日期和业务规则计算得出。 示例 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| 结束时间 EndTime | 表示活动完成时间的时间戳。 | ||
| 说明 此属性记录活动的完成时间。StartTime表示活动开始时间,EndTime则提供计算该任务持续时间所需的另一端时间点。 在流程挖掘中,同时记录活动的开始和结束时间,可以更深入地分析流程表现。这样便能准确计算“处理时间”(任务的实际工作时间)和“等待时间”(任务之间的耗时)。区分两者对于准确识别瓶颈至关重要。 重要性 可准确计算活动处理时间,区分实际工作时间和空闲或等待时间,这对于准确开展瓶颈分析至关重要。 获取途径 事件日志中可能有单独的时间戳字段,也可以将同一案例中顺序流里的下一项活动的StartTime作为结束时间。 示例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
索赔处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已获授权 | 表示已正式批准支付计算出的结算金额。这通常是一个独立步骤,由经理或其他授权人员完成,并作为明确的审批交易记录。 | ||
| 重要性 这是付款前的关键控制点,也可能成为瓶颈。“理赔决定已作出”到此节点之间的时长由“平均理赔审批时间”KPI衡量。 获取途径 通常,工作流或财务模块会明确记录此事件,由拥有特定权限的用户批准付款。相关记录可在审批日志中查找。 采集 工作流或交易日志中记录的明确审批事件。 事件类型 explicit | |||
| 款项已支付 | 此活动标志着理赔付款交易已执行。通过支票、电子资金转账(EFT)或其他方式发出付款时,系统会生成明确的事件记录。 | ||
| 重要性 这表示已履行获批理赔的财务义务。从“付款已获授权”到“款项已支付”之间的时间,反映了财务部门的处理效率。 获取途径 可从Duck Creek Claims的财务交易表中获取,该表会记录所有对外付款的交易代码和时间戳。 采集 处理付款时会生成一条独立的财务交易日志记录。 事件类型 explicit | |||
| 理赔决定已作出 | 此活动表示已对理赔作出正式决定,例如“已批准”“部分批准”或“已拒绝”。通常可根据状态变为最终决定状态推断这一关键里程碑。 | ||
| 重要性 这是一个关键决策里程碑。到达此节点所需的时间和决定结果,是流程分析与效率评估的核心内容。 获取途径 可根据专用的“理赔决定”或“理赔状态”字段变为“已批准”或“已拒绝”等终止状态推断,并记录状态变更的时间戳。 采集 可根据理赔主要状态字段或决定字段的更新推断。 事件类型 inferred | |||
| 理赔已拒绝 | 此活动表示流程以另一种方式结束,即理赔被正式拒绝。理赔最终状态设为“已拒绝”或“不予受理”时会记录此事件。 | ||
| 重要性 这是需要单独分析的关键结果。了解理赔被拒的原因和时间,有助于改进受理流程并管理合规。 获取途径 可根据理赔实体表中最终状态变为“已拒绝”“不予受理”或“未付款结案”的时间戳推断。 采集 可根据理赔最终状态为拒赔原因推断。 事件类型 inferred | |||
| 理赔已提交 | 这是第一个事件,表示保险公司已收到首次损失通知(FNOL)。通常,代理人或投保人将初始理赔信息录入系统时,系统会记录一笔明确的交易。 | ||
| 重要性 此活动标志着整个理赔周期的开始。分析此事件与后续事件之间的时间,对于了解总处理时长和受理效率至关重要。 获取途径 Duck Creek Claims中首次创建理赔记录时,通常会在理赔或FNOL日志表中明确记录此事件。 采集 创建新理赔记录时记录的事件。 事件类型 explicit | |||
| 理赔已结案 | 这是最后一个活动,表示付款完成或理赔结算后,理赔档案已完成行政结案。最终状态更新为“已结案”时会记录此事件。 | ||
| 重要性 此活动标志着流程顺利结束,是计算“端到端理赔平均周期时间”等关键时长指标的终点。 获取途径 可根据理赔主数据表中最终状态变为“已结案”或“已结算”的时间戳推断。 采集 可根据理赔最终状态设为“已结案”推断。 事件类型 inferred | |||
| 初步审核已完成 | 表示分配的理赔员已完成对理赔案件的首次全面审核。通常可根据分配后理赔状态的变化推断,例如从“已分配”变为“审核中”或“调查中”。 | ||
| 重要性 此里程碑有助于衡量理赔员首次采取行动所需的时间,并发现其工作量中可能存在的积压。这是首个重要的人工处理节点。 获取途径 可根据理赔状态字段的变化推断,例如变为“初步审核完成”或“等待信息”。使用该状态变更的时间戳。 采集 可根据分配理赔员后理赔状态字段的变化推断。 事件类型 inferred | |||
| 已分配理赔员 | 此事件记录理赔员或经办人被分配至已登记理赔案件的情况。系统会记录这次分配,明确交接节点,并确定理赔案件整个周期的负责人。 | ||
| 重要性 此事件对于分析资源分配、理赔员工作量和理赔分配延误至关重要。这是一个关键交接节点,可能造成等待。 获取途径 可通过主理赔数据表中“已分配理赔员”字段的更新进行跟踪。该字段的历史记录或审计日志可提供时间戳。 采集 理赔员字段填写或变更时,系统会在审计轨迹中记录。 事件类型 explicit | |||
| 已收到补充信息 | 表示已收到所请求的信息,理赔处理因此可以继续。理赔员可能会手动记录此事件;如果信息通过数字门户提交,系统也可能自动记录。 | ||
| 重要性 从“已请求信息”到“已收到信息”之间的时间是一个关键等待阶段。分析这段时间有助于发现外部依赖和沟通瓶颈。 获取途径 此事件可以来自文档管理系统集成,也可以是理赔员收到文件后手动记录的日志条目或状态变更。 采集 上传文件或理赔员手动录入时记录的事件。 事件类型 explicit | |||
| 已请求补充信息 | 理赔员认为需要更多信息,并向投保人或第三方发出请求时,会发生此活动。通常,系统的通信或往来函件模块会明确记录此事件。 | ||
| 重要性 此活动频繁发生,可能表明初始数据收集流程存在问题。它还会造成较长的等待时间,影响整体周期时间。 获取途径 可从外发通信日志(如信函、电子邮件)或Duck Creek Claims中的特定“信息请求”交易记录中获取。 采集 生成信息请求函件或任务时记录。 事件类型 explicit | |||
| 损失金额已评估 | 此里程碑表示根据调查结果设定或更新财务准备金,反映对理赔财务影响的估算。录入或调整准备金金额时会记录此事件。 | ||
| 重要性 这是流程中的关键财务检查点。分析此事件的发生时间,有助于了解财务评估的速度和准确性。 获取途径 Duck Creek Claims中的理赔财务交易日志或准备金历史表通常会明确记录这笔财务交易。 采集 设定或更新理赔准备金时记录的财务交易。 事件类型 explicit | |||
| 理赔已登记 | 表示已正式受理并登记提交的理赔,此时系统会分配唯一的理赔ID。数据初步验证后,系统通常会自动记录此事件。 | ||
| 重要性 此事件正式标记理赔流程的开始,并触发后续流程,例如分配理赔员。提交到登记之间的时间可能反映初始数据质量问题或系统负载情况。 获取途径 可根据主理赔实体表中生成主理赔ID的时间戳,以及理赔状态从“待处理”或“已提交”变为“处理中”或“已登记”的记录推断。 采集 可根据主理赔记录的创建时间戳,或状态变为“处理中”的记录推导。 事件类型 inferred | |||
| 结算金额已计算 | 批准理赔后,此活动表示已计算最终结算金额或付款金额。这可能是一个明确步骤,也可以根据系统财务模块中付款金额的最终确认情况推断。 | ||
| 重要性 此活动对于衡量“结算返工率”KPI至关重要。同一理赔案件多次发生此事件,可能表明结算阶段存在效率低下、错误或协商。 获取途径 可通过明确的交易日志条目记录,也可根据理赔财务数据中“结算金额”字段的更新推断。该字段的审计日志是主要数据来源。 采集 计算并保存最终付款金额时记录的事件。 事件类型 explicit | |||
| 调查已完成 | 表示调查活动结束,所需事实均已收集。通常可根据理赔状态从“调查中”变为“待决策”等决策状态推断。 | ||
| 重要性 调查完成是一个重要里程碑,可为决策和理赔结算阶段扫清障碍。此处的延误会对后续环节造成显著影响。 获取途径 可根据理赔状态从“调查”变为“审核”或“决策”状态的时间戳推断。 采集 可根据表示调查活动结束的理赔状态变更推导。 事件类型 inferred | |||
| 调查已开始 | 此活动表示理赔正式调查阶段的开始。通常可根据理赔状态变为“调查中”或类似状态推断。 | ||
| 重要性 这标志着一个资源投入较多的阶段开始。衡量调查时长是计算“平均调查时长”KPI的关键,也有助于管理流程中的重要环节。 获取途径 可根据主理赔状态字段中状态变为“调查进行中”或“等待查勘”的时间戳推断。 采集 可根据表示调查活动开始的理赔状态变更推导。 事件类型 inferred | |||
数据提取指南
步骤
- 访问Duck Creek Data Hub配置工具:登录Duck Creek环境并打开Data Hub应用。您需要具备创建或修改数据导出配置的相应权限。
- 创建数据导出作业:在Data Hub工具中启动新建导出作业流程,并为作业设置易于识别的名称,例如ProcessMind_Claims_Event_Log_Export。
- 定义数据源:将作业配置为连接主Data Hub SQL数据库。您需要填写服务器名称、数据库名称,以及对相关架构具有读取权限的用户凭据。
- 输入提取查询:打开导出作业中的查询定义部分,将下方查询部分的完整脚本复制并粘贴到查询编辑器中。
- 设置查询参数:在配置中找到参数部分,为查询中的@StartDate和@EndDate参数设置值,以指定所需的数据提取日期范围。例如,'2023-01-01'和'2023-12-31'。
- 映射输出列:配置输出文件设置,确保SELECT语句中定义的列(ClaimId、ActivityName、EventTime等)正确映射到输出文件中的列。输出文件的表头必须与这些名称完全一致。
- 配置输出文件:将输出格式设为CSV,分隔符设为逗号(,),字符编码设为UTF-8,以确保与ProcessMind兼容。
- 定义目标位置:指定生成的CSV文件要保存的文件路径或网络位置,并确保系统对此位置具有写入权限。
- 安排导出作业:配置作业计划。初次分析时可以手动运行;如需持续监控,可设置定期计划(例如每天或每周运行)。
- 运行作业并获取文件:运行作业以生成事件日志文件。完成后,从第8步指定的位置获取CSV文件。
- 准备上传:上传到ProcessMind之前,打开CSV文件进行最终检查。确认表头正确、日期格式统一(YYYY-MM-DD HH:MI:SS),且数据符合预期。
配置
- 前提条件:需要能够访问Duck Creek Data Hub模块。运行导出作业的用户或服务账户必须对Data Hub底层数据库表具有读取权限(例如[DataHubSchema].[FactClaimTransaction]、[DataHubSchema].[DimClaim]、[DataHubSchema].[DimStatusHistory])。
- 日期范围配置:查询使用@StartDate和@EndDate参数,必须设置这两个参数以定义提取时间范围。首次分析建议选择6至12个月,以涵盖足够数量的已完成和进行中案例。
- 筛选:查询的公用表表达式(CTE)中包含占位行/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */。取消该行注释并修改内容,即可筛选特定业务线(例如'Personal Auto'、'Commercial Property'),减少数据量并聚焦分析范围。
- Data Hub刷新周期:请留意Data Hub的数据延迟。数据并非实时更新,通常按计划刷新(例如每晚刷新)。提取的数据截至最近一次成功刷新时。
- 输出格式:导出作业必须配置为生成扁平文件,建议使用CSV。文本限定符应设为双引号("),以正确处理数据字段中的逗号。
查询示例 sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; 告别理赔积压:立即优化理赔处理流程
实现70%的直通式处理,降低成本并减少延误。
免费试用14天,无需信用卡。