您的理赔处理数据模板
您的理赔处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Duck Creek Claims数据提取指南
理赔处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 表示特定活动或事件发生时间的时间戳。 | ||
| 说明 Event Time提供理赔生命周期中每项活动的准确日期和时间。这些时间信息对于绩效分析至关重要。 在分析中,该时间戳用于计算活动之间的周期时间、识别等待时间、衡量案件总时长,以及分析不同时段的流程绩效。它是所有基于时间的流程指标的基础。 为什么重要 该时间戳对于计算周期时间和时长等所有基于时间的指标至关重要,可支持绩效分析和瓶颈识别。 获取位置 这是Duck Creek Claims事件或交易日志中的标准时间戳字段。请查找“CreateDate”“Timestamp”或“EventDate”等字段。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 活动名称 ActivityName | 理赔在特定时间点发生的业务活动或事件名称。 | ||
| 说明 该属性描述理赔流程中执行的具体步骤或任务,例如“Claim Submitted”“Adjuster Assigned”或“Payment Issued”。每项活动都代表理赔生命周期中的一个独立节点。 分析这些活动的顺序和频率是流程挖掘的核心。它有助于发现流程模型、识别瓶颈、检测返工循环,并分析流程相对于标准模型的偏差。 为什么重要 Activity Name定义流程顺序中的各个步骤,是发现、分析和监控理赔流程的基础。 获取位置 通常来源于Duck Creek Claims中的事件日志、交易名称或状态变更记录,可能需要对多个源字段或表进行映射。 示例 提交理赔分配理算师开始调查发放付款关闭理赔 | |||
| 理赔ID ClaimId | 单笔保险理赔的唯一标识符,也是主要案件标识。 | ||
| 说明 Claim ID是关联单笔保险理赔从提交到关闭期间所有事件和活动的基础键,确保能够连贯地跟踪理赔的完整生命周期。 在流程挖掘分析中,该属性对于构建案件视图至关重要,可帮助分析人员追踪每笔理赔的完整历程、衡量端到端周期时间并分析流程变体。 为什么重要 这是连接流程中所有相关事件的核心Case ID,可提供理赔生命周期的完整端到端视图。 获取位置 这是Duck Creek Claims主理赔实体或表中的主键。具体表名和字段名请参阅系统文档。 示例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| 已分配理算师 AssignedAdjuster | 在特定活动中负责处理理赔的理算师姓名或ID。 | ||
| 说明 该属性用于标识执行活动的用户或资源。在理赔生命周期中,案件可能在不同理算师或团队之间交接,因此该属性可能发生变化。 它对于分析资源绩效、工作量分配和交接情况至关重要。关注理算师处理量、工作量差异和瓶颈识别的仪表板,通常高度依赖该属性,以了解工作如何分配并由个人处理。 为什么重要 支持资源绩效、工作量平衡和协作模式分析,帮助识别瓶颈和培训需求。 获取位置 请参阅Duck Creek Claims文档。查找与理赔任务、事件或主理赔实体相关表中的用户、负责人或受派人字段。 示例 John SmithJane DoeRobert Brownadjuster_1138 | |||
| 损失金额 LossAmount | 理赔中报告的预计或实际损失金额。 | ||
| 说明 该属性表示与理赔相关损失的初始估算价值,是常用于影响理赔路由、严重程度和所需调查级别的关键财务指标。 在分析中,损失金额用于细分理赔,并了解财务影响与流程行为之间的关系。例如,高价值理赔可能遵循不同路径或具有更长周期时间。它为运营流程数据提供重要的财务上下文。 为什么重要 为理赔提供财务上下文,支持分析理赔价值如何影响处理路径、处理时长和结果。 获取位置 请参阅Duck Creek Claims文档。这是理赔中的核心财务字段,通常称为“Reported Loss”或“Initial Reserve”。 示例 1500.0025000.50125000.00 | |||
| 理赔严重程度 ClaimSeverity | 对理赔财务或运营复杂度的分类,例如低、中或高。 | ||
| 说明 Claim Severity用于表示理赔预期影响或复杂度,可根据初始损失估算、事故性质或其他预定义业务规则确定。 该属性对于绩效分析非常重要,因为高严重程度理赔通常需要更多步骤、更长处理时间和专业资源。按严重程度细分KPI,有助于设定合理的绩效目标,并了解复杂度如何影响流程效率和结果。 为什么重要 帮助按复杂度细分理赔,从而进行更细致的绩效分析,并对周期时间和成本开展更合理的基准比较。 获取位置 请参阅Duck Creek Claims文档。它可能是专用字段,也可能根据初始损失准备金金额推导。 示例 低中高灾难性 | |||
| 理赔状态 ClaimStatus | 理赔在特定时间点的整体状态,例如Open、Pending或Closed。 | ||
| 说明 Claim Status表示理赔生命周期中的当前状态,以高层视角概括理赔在整体流程中的位置。 该属性适合用于创建理赔库存的高层视图和筛选案件。它对于识别理赔最终结果尤为重要,例如“Closed - Paid”或“Closed - Denied”,这也是分析结果和了解拒赔率的基础。 为什么重要 提供理赔当前状态和最终结果的快照,对于结果分析和案件筛选至关重要。 获取位置 请参阅Duck Creek Claims文档。这是主理赔记录中的基础字段。 示例 开放待处理-等待信息已关闭-已结算已关闭-已拒赔 | |||
| 理赔类型 ClaimType | 保险理赔的类别,例如汽车、财产或责任。 | ||
| 说明 Claim Type根据业务线或损失性质对理赔进行分类,是细分和分析理赔数据的基础维度。 该属性用于比较不同理赔类型的流程绩效。例如,“Auto - Total Loss”理赔与“Property - Water Damage”理赔遵循的流程不同,KPI也不同。按Claim Type分析可以提供上下文,支持更有意义的绩效比较和有针对性的流程改进。 为什么重要 这是细分分析的关键维度,因为不同理赔类型通常具有不同的流程、SLA和复杂度。 获取位置 请参阅Duck Creek Claims文档。这是主理赔记录中的核心属性。 示例 个人汽车-碰撞商业财产-火灾工伤赔偿一般责任 | |||
| 部门 Department | 在特定时间负责该活动或理赔的部门或团队。 | ||
| 说明 此属性指定负责处理理赔的职能组或部门,例如'Initial Intake'、'Investigation Unit'或'Settlement Team',为流程顺序提供组织背景。 按部门分析对于从整体层面了解流程绩效至关重要。它有助于识别跨部门瓶颈、衡量团队效率,并了解工作如何在组织内流转。 为什么重要 支持按职能领域分析绩效,突出跨部门交接和团队特有的瓶颈。 获取位置 请参阅Duck Creek Claims文档。此信息通常与受派用户的个人资料或队列、工作组分配相关。 示例 汽车理赔财产理赔-重大损失特别调查部门付款处理 | |||
| 保单号 PolicyNumber | 提交理赔所依据保险保单的唯一标识符。 | ||
| 说明 此属性将理赔关联回其所属的原始保险保单,提供与理赔相关的保障范围、条款和客户信息。 虽然Policy Number不一定直接用于流程顺序分析,但它对于丰富理赔数据非常有价值。通过将其与保单和客户数据关联,可以分析不同客户群体、保单类型或保单年限下的流程绩效差异,从而获得更全面的业务视角。 为什么重要 将理赔关联到客户和保单,支持更广泛地分析流程绩效如何影响不同客户群体或保单类型。 获取位置 请参阅Duck Creek Claims文档。这是主理赔实体中的标准参考字段。 示例 PA-987654321CP-123456789WC-555444333 | |||
| 最后数据更新时间 LastDataUpdate | 源系统最近一次刷新数据的时间戳。 | ||
| 说明 该属性表示数据集最近一次更新的时间,为所分析数据的新鲜度提供参考。 在仪表板和分析中,它用于告知用户洞察数据的时效性,帮助用户判断流程视图是否包含最新交易。 为什么重要 告知用户数据的新鲜度,这对于正确解读分析结果和及时作出决策至关重要。 获取位置 该时间戳在数据提取、转换和加载(ETL)过程中生成,通常存储在数据集的元数据中。 示例 2024-05-21T02:00:00Z | |||
| 拒赔原因 RejectionReason | 理赔被拒绝或驳回的具体原因。 | ||
| 说明 当理赔决定为拒赔时,该属性提供作出该决定的根本原因。通常从预定义的代码或描述列表中选择。 分析拒赔原因对于“Claim Decision & Rejection Insights”仪表板至关重要,有助于识别提交中的常见问题、潜在欺诈模式,或保单条款表述不清的领域。这些洞察可以推动受理流程或核保规则改进。 为什么重要 说明理赔被拒的原因,为改进受理流程、减少无效提交和识别培训机会提供可执行洞察。 获取位置 请参阅Duck Creek Claims文档。理赔状态变为“Denied”或类似状态时,通常会填充此字段。 示例 不属于承保风险保单已过期重复理赔疑似欺诈 | |||
| 是否按时解决 IsOnTimeResolution | 用于标记理赔是否在目标解决日期当天或之前结案的计算标记。 | ||
| 说明 此布尔属性通过比较“理赔结案”活动的时间戳与该理赔的“ResolutionTargetDate”得出。每笔理赔都会被标记为按时(true)或逾期(false)。 此属性直接支持“按时解决理赔率”KPI。它便于在仪表板中汇总和可视化SLA遵循情况,也支持下钻分析,以识别逾期理赔的常见特征,例如特定理赔类型、部门或流程路径。 为什么重要 直接衡量每笔理赔的SLA合规情况,支持对逾期理赔进行高效筛选和根因分析。 获取位置 这不是源系统字段,而是在数据准备阶段通过比较最终活动的时间戳与“ResolutionTargetDate”字段计算得出。 示例 truefalse | |||
| 是否自动执行 IsAutomated | 用于标识活动是否由系统在无人干预的情况下自动执行的布尔标志。 | ||
| 说明 此标记用于区分由人工用户完成的任务与由系统自动化执行的任务,例如自动通知、初始数据验证或直通式处理步骤。 分析此属性是了解理赔流程自动化程度的关键。它有助于衡量自动化举措的影响、发现进一步实现自动化的机会,并确保自动化步骤按预期运行,不会引发下游问题。 为什么重要 有助于衡量自动化对效率和成本的影响,并发现直通式处理机会。 获取位置 此信息可能来自与事件关联的“user”(例如“系统”或“批处理”),也可能来自事件记录中的特定标记。 示例 truefalse | |||
| 是否返工 IsRework | 用于标记活动是否属于返工循环的计算标记。 | ||
| 说明 如果某项活动在其他不同活动已经发生后再次出现在同一笔理赔中,此布尔属性将设为true。例如,流程从“损失评估”返回“调查开始”。 此属性对于量化和分析返工至关重要。它支持“理赔返工率”KPI和“理赔返工与重新处理模式”仪表板,可直接筛选并突出显示涉及返工的活动和案例,帮助定位流程中的低效环节和质量问题。 为什么重要 在活动层面量化返工,便于衡量、可视化和分析流程低效的原因及影响。 获取位置 这不是源系统字段,而是在数据准备阶段通过检测案例中重复出现的活动序列计算得出。 示例 truefalse | |||
| 源系统 SourceSystem | 提取事件数据的系统。 | ||
| 说明 该属性用于标识理赔数据的来源应用。在此场景中,其值始终为“Duck Creek Claims”。 即使所有数据都来自同一系统,该属性看似多余,但对于数据治理、可追溯性,以及未来可能合并多个系统的数据场景仍然至关重要。它为数据来源和结构提供上下文。 为什么重要 提供必要的数据血缘和上下文,对于数据治理和问题排查至关重要,尤其适用于包含多个集成系统的环境。 获取位置 通常是在数据提取和转换过程中添加的静态值,用于标记数据来源。 示例 Duck Creek理赔 | |||
| 目标解决日期 ResolutionTargetDate | 根据SLA或内部目标,预计应解决理赔的目标日期。 | ||
| 说明 该属性存储理赔关闭期限。此日期通常由监管要求、服务级别协议(SLA)或内部关键绩效指标(KPI)确定,并可能因理赔类型或严重程度而异。 这是计算“On-Time Claim Resolution Rate”KPI和支持“Claim Resolution Target Adherence”仪表板的基础。它支持主动监控可能违反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 | |||
| 结算金额 SettlementAmount | 为解决理赔而最终协商确定的金额。 | ||
| 说明 该属性记录已计算并获授权支付的结算金额,是每笔产生付款的理赔的关键结果指标。 该属性对于财务分析以及“Payment Authorization & Issuance Time”等仪表板至关重要。它可以与初始“Loss Amount”进行比较,以分析准备金准确性,也是理解理赔流程财务结果的基础。 为什么重要 表示理赔的关键财务结果,对于财务报告和分析初始损失估算的准确性至关重要。 获取位置 请参阅Duck Creek Claims文档。此信息通常存储在与理赔相关的财务交易表或付款表中。 示例 1450.7522000.00115800.20 | |||
理赔处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 作出理赔决定 | 此活动表示对理赔作出正式决定,例如“Approved”“Partially Approved”或“Denied”。这是根据状态变为最终决策状态推断出的关键里程碑。 | ||
| 为什么重要 这是关键决策里程碑。到达该节点所需的时间以及决策结果,是流程分析和效率评估的核心。 获取位置 根据专用“Claim Decision”或“Claim Status”字段变为“Approved”或“Denied”等终止状态的变更推断,并记录该变更的时间戳。 采集 根据理赔主要状态或决策字段的更新推断。 事件类型 inferred | |||
| 关闭理赔 | 这是最终活动,表示付款发出或理赔结算后,完成理赔档案的行政关闭。通常通过最终状态更新为“Closed”记录。 | ||
| 为什么重要 此活动标志着流程成功结束,是计算“Average End-to-End Claim Cycle Time”等关键时长指标的终点。 获取位置 根据理赔主数据表中最终状态变为“Closed”或“Settled”的时间戳推断。 采集 根据理赔最终状态设为“Closed”推断。 事件类型 inferred | |||
| 发放付款 | 此活动标志着执行理赔付款交易。通过支票、EFT或其他方式发出付款时,系统会生成清晰明确的事件。 | ||
| 为什么重要 这表示已批准理赔的财务义务完成。“Payment Authorized”到“Payment Issued”的时间可以反映财务部门的处理效率。 获取位置 从Duck Creek Claims财务交易表获取,该表使用特定交易代码和时间戳记录所有对外付款。 采集 处理付款时创建一条独立的财务交易日志记录。 事件类型 explicit | |||
| 拒绝理赔 | 此活动表示流程以理赔正式拒赔作为另一种结束方式。当理赔最终状态设为“Denied”或“Rejected”时记录。 | ||
| 为什么重要 这是需要单独分析的关键结果。了解理赔被拒的原因和时间,有助于改进受理流程并加强合规管理。 获取位置 根据理赔实体表中理赔最终状态变为“Denied”“Rejected”或“Closed without Payment”的时间戳推断。 采集 根据理赔最终状态为拒赔原因推断。 事件类型 inferred | |||
| 授权付款 | 表示正式批准支付已计算的结算金额。通常,这是由经理或其他独立授权人员参与的独立步骤,并以明确的审批交易记录。 | ||
| 为什么重要 这是付款前的关键控制点,也可能成为瓶颈。“Claim Decision Made”到此节点的时长由“Average Claim Approval Time”KPI衡量。 获取位置 通常,这是工作流或财务模块中的明确事件,由具有特定权限的用户批准付款,并记录在审批日志中。 采集 工作流或交易日志中记录的明确审批事件。 事件类型 explicit | |||
| 提交理赔 | 这是第一个事件,表示保险公司收到First Notice of Loss(FNOL)。通常,当代理人或保单持有人将初始理赔信息录入系统时,系统会将其记录为明确的交易。 | ||
| 为什么重要 此活动标志着整个理赔生命周期的开始。分析该事件与其他事件之间的时间,对于了解总处理时长和受理效率至关重要。 获取位置 通常,这是Duck Creek Claims中创建新理赔记录时,在理赔或FNOL日志表中记录的明确事件。 采集 创建新理赔记录时记录的事件。 事件类型 explicit | |||
| 分配理算师 | 此事件记录向已登记理赔分配理算师或处理人员。系统会记录该分配,形成清晰的交接节点,并明确理赔生命周期的负责人。 | ||
| 为什么重要 对于分析资源分配、理算师工作量和理赔分配延误至关重要。这是可能引入等待时间的关键交接节点。 获取位置 通过主理赔数据表中“Assigned Adjuster”字段的更新进行跟踪。该字段的历史记录或审计日志会提供时间戳。 采集 理算师字段被填充或变更时,在审计轨迹中记录。 事件类型 explicit | |||
| 完成初次审核 | 表示分配的理算师完成对理赔的首次全面审核。通常可根据分配后的理赔状态变化推断,例如从“Assigned”变为“Under Review”或“Investigation”。 | ||
| 为什么重要 这一里程碑有助于衡量理算师首次采取行动所需的时间,也可以反映其工作量中潜在的积压。这是首个重要的人工处理检查点。 获取位置 根据理赔状态字段的变更推断,例如变为“Initial Review Complete”或“Pending Information”。使用该状态变更的时间戳。 采集 根据理算师分配后理赔状态字段的变更推断。 事件类型 inferred | |||
| 完成损失评估 | 此里程碑标志着根据调查结果设定或更新财务准备金。它表示对理赔财务影响的估算,通常在录入或调整准备金金额时记录。 | ||
| 为什么重要 这是流程中的关键财务检查点。分析其发生时间,有助于了解财务评估的速度和准确性。 获取位置 通常,这是Duck Creek Claims中理赔财务交易日志或准备金历史表记录的明确财务交易。 采集 设定或更新理赔准备金时记录的财务交易。 事件类型 explicit | |||
| 完成调查 | 表示调查活动结束,所有必要事实均已收集。通常可根据理赔状态从“Under Investigation”变为“Pending Decision”等决策状态推断。 | ||
| 为什么重要 完成调查是解除决策和结算阶段阻塞的重要里程碑。此处延误会对后续流程产生显著影响。 获取位置 根据理赔状态从“investigation”状态变为“review”或“decision”状态的时间戳推断。 采集 根据表示调查活动结束的理赔状态变更推导。 事件类型 inferred | |||
| 开始调查 | 此活动表示理赔正式调查阶段开始。通常可根据理赔状态变为“Under Investigation”或类似状态推断。 | ||
| 为什么重要 这标志着资源投入密集阶段的开始。衡量调查时长是“Average Investigation Duration”KPI的关键,也有助于管理流程中的重要环节。 获取位置 根据主理赔状态字段中理赔状态更新为“Investigation in Progress”或“Pending Inspection”的时间戳推断。 采集 根据表示调查活动开始的理赔状态变更推导。 事件类型 inferred | |||
| 收到补充信息 | 标志着收到所请求的信息,理赔处理可以继续。理算师可能手动记录该事件;如果信息通过数字门户提交,系统也可能自动记录。 | ||
| 为什么重要 “Information Requested”与“Information Received”之间的时间是关键等待期。分析该时长有助于识别外部依赖和通信瓶颈。 获取位置 可以是文档管理系统集成产生的明确事件,也可以是理算师收到文件后手动添加的日志条目或状态变更。 采集 文件上传或理算师手动录入时记录的事件。 事件类型 explicit | |||
| 登记理赔 | 标志着已提交理赔获得正式受理和登记,此时系统会正式分配唯一的Claim ID。通常,这是初始数据验证后的自动系统事件。 | ||
| 为什么重要 该活动使理赔正式生效,并触发理算师分配等后续流程。提交与登记之间的时间间隔可以反映初始数据质量或系统负载问题。 获取位置 根据主Claim ID生成的时间戳,以及主理赔实体表中理赔状态从“pending”或“submitted”变为“open”或“registered”的时间推断。 采集 根据主理赔记录的创建时间戳,或状态变更为“Open”的时间推导。 事件类型 inferred | |||
| 计算结算金额 | 作出批准决定后,此活动表示计算最终结算或付款金额。它可以是明确步骤,也可以根据系统财务模块中付款金额的最终确定情况推断。 | ||
| 为什么重要 此活动对于衡量“Settlement Rework Rate”KPI至关重要。同一理赔多次发生该事件,通常表明结算阶段存在低效、错误或协商。 获取位置 可以是明确的交易日志条目,也可以根据理赔财务数据中“Settlement Amount”字段的更新推断。该字段的审计日志是主要来源。 采集 计算并保存最终付款金额时记录的事件。 事件类型 explicit | |||
| 请求补充信息 | 当理算师确定需要更多信息,并向保单持有人或第三方发出请求时,会发生此活动。通常,这是与系统通信或函件模块关联的明确事件。 | ||
| 为什么重要 该活动频繁发生,可能表明初始数据收集流程存在问题。同时,它会引入较长的等待时间,影响整体周期时间。 获取位置 从外发通信日志(如信函、电子邮件)或Duck Creek Claims中的特定“Request for Information”交易中获取。 采集 生成信息请求函件或任务时记录。 事件类型 explicit | |||
提取指南
步骤
- 访问Duck Creek Data Hub Configuration Utility:登录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模块。运行导出作业的用户或服务账户必须拥有底层数据库表的读取权限,例如[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的数据延迟。数据并非实时更新,通常按计划刷新,例如每晚刷新。提取数据的时效性取决于Data Hub最近一次成功刷新。
- 输出格式:导出作业必须配置为生成扁平文件,最好使用CSV。确保文本限定符设置为双引号("),以处理数据字段中的逗号。
a 示例查询 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天,无需信用卡。