数据模板:理赔处理
您的理赔流程数据模板
- 建议收集的属性
- 需追踪的关键活动
- Duck Creek Claims 的提取指南
理赔处理属性
| 名称 | 描述 | ||
|---|---|---|---|
事件时间 EventTime | 指示特定活动或事件发生时间的时间戳。 | ||
描述 事件时间记录了理赔生命周期中每项活动的精确日期和时间。此时间信息对于绩效分析至关重要。在分析中,此时间戳用于计算活动之间的周期时间、识别等待时间、衡量案件总持续时间,以及分析不同时间段内的流程绩效。它是任何基于时间的流程指标的基石。 为何重要 这个时间戳对于计算所有基于时间的指标(例如周期时间和持续时间)至关重要,有助于进行绩效分析和瓶颈识别。 获取方式 这是Duck Creek Claims中与 event 或交易日志关联的标准 timestamp 字段。请查找诸如“CreateDate”、“Timestamp”或“EventDate”之类的字段。 示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
活动名称 ActivityName | 在索赔的特定时间点发生的业务活动或事件的名称。 | ||
描述 此属性描述了理赔流程中执行的特定步骤或任务,例如“理赔提交”、“理赔员分配”或“款项发出”。每个活动都代表了理赔生命周期中的一个独特节点。 分析这些活动的序列和频率是流程挖掘的核心。它有助于发现流程模型、识别瓶颈、检测返工循环,以及分析与标准模型存在的流程偏差。 为何重要 活动名称定义了流程中的步骤,这对于索赔流程的发现、分析和监控至关重要。 获取方式 通常源自Duck Creek Claims中的 event logs、交易名称或 status change records。这可能需要从多个源 fields 或 tables 进行 mapping。 示例 理赔已提交理赔员已分配调查已启动付款已发出理赔已结案 | |||
理赔ID ClaimId | 单个保险理赔的唯一标识符,作为主要的案件标识码。 | ||
描述 索赔 ID 是连接单个保险索赔从提交到结案所有事件和活动的基本键。它确保了索赔的整个生命周期能够被连贯地跟踪。 在流程挖掘分析中,此属性对于构建案例视图至关重要,它允许分析师追踪每个索赔的完整历程,衡量端到端周期时间,并分析流程变体。 为何重要 这是核心 Case ID,它连接了 process 中所有相关的 events,从而实现了对理赔生命周期的完整端到端视图。 获取方式 这是Duck Creek Claims系统中主要理赔实体或表格中的 primary key。具体表格和 field name 请查阅系统文档。 示例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
指定理赔员 AssignedAdjuster | 在特定活动中负责处理索赔的理赔员姓名或 ID。 | ||
描述 此属性用于识别执行活动的用户或资源。在整个理赔生命周期中,随着案件在不同理赔员或团队之间进行移交,此属性可能会发生变化。 这对于分析资源绩效、工作量分配和工作交接至关重要。专注于理赔员吞吐量、工作量差异和识别瓶颈的仪表盘,通常会严重依赖此属性来了解工作是如何分配并由个人处理的。 为何重要 有助于分析资源绩效、工作量平衡和协作模式,从而识别瓶颈并发现培训需求。 获取方式 请查阅 Duck Creek Claims 文档。在与理赔任务、事件或主要理赔实体相关的表格中查找用户、所有者或经办人字段。 示例 John SmithJane DoeRobert Brownadjuster_1138 | |||
损失金额 LossAmount | 索赔中报告的估计或实际损失金额。 | ||
描述 此属性代表与理赔相关的初始估算损失价值。这是一个关键的财务指标,通常会影响理赔的流转路径、严重程度以及所需的调查级别。 在分析中,损失金额可用于对理赔进行细分,并理解财务影响与流程行为之间的关联。例如,高价值理赔可能遵循不同的处理路径或具有更长的周期时间。它为运营流程数据提供了关键的财务背景信息。 为何重要 为索赔提供财务背景,从而能够分析索赔价值如何影响其处理路径、持续时间和结果。 获取方式 请查阅 Duck Creek Claims 文档。这是理赔中的核心财务字段,通常被称为“报损金额”或“初始备付金”。 示例 1500.0025000.50125000.00 | |||
理赔严重性 ClaimSeverity | 对索赔财务或操作复杂性的分类,例如低、中或高。 | ||
描述 理赔严重性指标,用于衡量理赔的预期影响或复杂程度。它可基于初始损失估算、事件性质或其他预定义的业务规则来确定。 此属性对绩效分析至关重要,因为高严重性理赔通常需要更多步骤、更长的处理时间以及专业资源。根据严重性划分关键绩效指标(KPI),有助于设定切合实际的绩效目标,并了解复杂性如何影响流程效率和最终结果。 为何重要 有助于根据复杂程度对索赔进行分类,从而能进行更细致的绩效分析,并为周期时间与成本提供更切实际的基准。 获取方式 请查阅 Duck Creek Claims 文档。这可能是一个专用字段,或根据初始损失准备金金额得出。 示例 低中高巨灾 | |||
理赔状态 ClaimStatus | 索赔在特定时间点的总体状态,例如开放、待处理或已关闭。 | ||
描述 理赔状态表示理赔在其生命周期中的当前阶段,提供理赔在整个流程中所处位置的概要信息。 此属性有助于创建理赔清单的高级视图并筛选案件。它对于识别理赔的最终结果(例如,“已结案 - 已支付”、“已结案 - 已拒绝”)尤为重要,这对于结果分析和理解拒赔率至关重要。 为何重要 提供索赔的当前状态和最终结果,这对于结果分析和案例筛选至关重要。 获取方式 请查阅 Duck Creek Claims 文档。这是主要理赔记录中的一个基本字段。 示例 未结待处理 - 等待信息已结案 - 已理赔已结案 - 拒绝 | |||
理赔类型 ClaimType | 保险索赔的类别,例如汽车险、财产险或责任险。 | ||
描述 理赔类型根据业务线或损失性质对理赔进行分类。这是细分和分析理赔数据的基本维度。 此属性用于比较不同类型理赔的流程绩效。例如,“车险 - 全损”理赔与“财产险 - 水损”理赔遵循的流程和关键绩效指标(KPI)大相径庭。按理赔类型进行分析能够提供背景信息,从而实现更有意义的绩效比较和量身定制的流程改进方案。 为何重要 这是进行分段分析的关键维度,因为不同类型的理赔通常具有截然不同的流程、服务水平协议(SLA)和复杂程度。 获取方式 请查阅 Duck Creek Claims 文档。这是主要理赔记录中的一个核心属性。 示例 个人汽车 - 碰撞险商业财产 - 火灾工伤赔偿综合责任 | |||
部门 Department | 在特定时间负责活动或索赔的部门或团队。 | ||
描述 此属性指定了负责处理理赔的职能组或部门,例如“初步受理”、“调查部门”或“结案团队”。它为流程流提供了组织层面的上下文信息。 按部门进行分析是理解总体流程绩效的关键。它有助于识别跨部门瓶颈,衡量团队层面的效率,并了解工作如何在整个组织中流转。 为何重要 支持按职能区域进行绩效分析,明确跨部门协作中的交接点和各团队的特定瓶颈。 获取方式 请查阅 Duck Creek Claims 文档。此信息通常与指定用户的档案或队列/工作组分配相关联。 示例 车险理赔财产理赔 - 大额损失特别调查组支付处理中 | |||
保单号 PolicyNumber | 该理赔所关联保单的唯一标识符。 | ||
描述 此属性将理赔关联至原始保单。它提供了与该理赔相关的承保范围、条款和客户的上下文信息。 尽管在流程流分析中并非总是直接使用,但保单号对于丰富理赔数据而言极其宝贵。它允许将理赔数据与保单和客户数据进行连接,进而分析流程绩效如何因客户细分、保单类型或保单年限而异,从而提供更全面的业务视图。 为何重要 将理赔关联到客户和保单,从而能够更广泛地分析流程绩效对不同客户细分或保单类型的影响。 获取方式 请查阅 Duck Creek Claims 文档。这是主要理赔实体上的一个标准参考字段。 示例 PA-987654321CP-123456789WC-555444333 | |||
处理时间 ProcessingTime | 针对特定活动的实际工作时长,计算方式为结束时间减去开始时间。 | ||
描述 处理时间,也称为活动时间或操作时间,衡量资源在特定任务上实际工作了多长时间。它通过从活动的 EndTime 中减去 StartTime 来计算。 此指标是绩效分析的核心组成部分。它有助于区分由长时间运行的任务(高处理时间)导致的效率低下,与因等待资源或信息(高等待时间)导致的延迟。这对于查明瓶颈的真正来源至关重要。 为何重要 衡量一项活动的实际工作时间,有助于在瓶颈分析中区分低效任务和长时间等待时间。 获取方式 这不是一个源系统 field。它是在 data preparation 阶段,通过将每项 activity 的“StartTime”从“EndTime”中减去而计算得出的。 示例 360086400300 | |||
拒绝原因 RejectionReason | 索赔被拒绝或驳回的具体原因。 | ||
描述 当做出拒绝理赔的决定时,此 attribute 提供了该决定的根本原因。这通常是从 predefined list of codes 或 descriptions 中选择的。 分析拒绝原因对于“Claim Decision & Rejection Insights” dashboard 至关重要。它有助于识别提交中常见的 issues、潜在的 fraud patterns,或 policy language 可能不明确的 areas。这些 insight 可以驱动 intake process 或 underwriting rules 的 improvements。 为何重要 解释理赔被拒绝的原因,提供可操作的见解,以改进受理流程,减少无效提交,并识别培训机会。 获取方式 请查阅 Duck Creek Claims 文档。当理赔状态变为“已拒绝”或类似状态时,此字段通常会被自动填入。 示例 非承保风险保单已过期重复理赔疑似欺诈 | |||
数据最后更新时间 LastDataUpdate | 源系统最近一次数据刷新时间戳。 | ||
描述 此属性指示了数据集上次更新的时间。它为所分析数据的新鲜度提供了参考。 在仪表盘和分析中,此属性用于告知用户洞察的时效性。它有助于管理用户预期,明确最新的交易是否已被纳入流程视图中。 为何重要 提示用户数据的新鲜度,这对于解读分析结果并及时做出决策至关重要。 获取方式 此 timestamp 是在 data extraction、transformation 和 loading (ETL) 过程中生成的,通常存储在 dataset 的 metadata 中。 示例 2024-05-21T02:00:00Z | |||
是否按时结案 IsOnTimeResolution | 一个计算标志,表明索赔是否在其目标解决日期或之前关闭。 | ||
描述 此布尔属性是通过比较“理赔结案”活动的时间戳与该理赔的“ResolutionTargetDate”(目标解决日期)得出的。它将每个理赔标记为按时(True)或延迟(False)。 此属性直接支持“按时理赔解决率”KPI。它允许在仪表盘中轻松进行SLA合规性的聚合和可视化,并支持下钻分析,以识别延迟理赔的共同特征(例如,特定理赔类型、部门或流程路径)。 为何重要 直接衡量每个理赔案件的SLA合规性,实现对逾期理赔案件的强大筛选和根本原因分析。 获取方式 这不是一个源系统 field。它是在 data preparation 阶段,通过比较最终 activity 的 timestamp 和“ResolutionTargetDate”字段计算得出的。 示例 真否 | |||
是否自动化 IsAutomated | 一个布尔标志,表明该活动是否由系统自动执行而无需人工介入。 | ||
描述 这项标记区分了由人工完成的任务和由系统自动化执行的任务,例如自动通知、初步数据验证或直通式处理步骤。 分析此属性对于理解理赔流程的自动化水平至关重要。它有助于衡量自动化举措的影响,识别进一步自动化的机会,并确保自动化步骤按预期运行且不会产生后续问题。 为何重要 有助于衡量自动化对效率和成本的影响,并发现直通式处理的优化空间。 获取方式 此信息可从 event 关联的“user”(例如“SYSTEM”或“BATCH”)或 event 记录上的特定标记中推断得出。 示例 真否 | |||
是否返工 IsRework | 一个计算标志,表明一项活动是否属于返工循环的一部分。 | ||
描述 如果某项索赔中的某个活动,在其他不同活动已发生后再次重复,此布尔属性将被设置为“真”。例如,当流程从“损失评估”退回“开始调查”环节时。 该属性对于量化和分析返工情况至关重要。它通过允许直接筛选和高亮显示涉及返工的活动和案例,支持“索赔返工率”KPI和“索赔返工与再处理模式”仪表板。这有助于发现流程中的效率低下和质量问题。 为何重要 量化活动层面的返工情况,从而易于衡量、可视化并分析流程效率低下的原因和影响。 获取方式 这不是一个源系统 field。它是在 data preparation 阶段,利用算法检测 case 中重复的 activities 序列而计算得出的。 示例 真否 | |||
源系统 SourceSystem | 提取事件数据的来源系统。 | ||
描述 此属性用于识别理赔数据源自的应用程序。在此应用场景下,它将始终是“Duck Creek Claims”。 尽管当所有数据都来自同一系统时,此属性可能看似冗余,但它对于数据治理、可追溯性至关重要,尤其是在未来可能需要合并来自多个系统的数据时。它为数据的来源和结构提供了必要的上下文信息。 为何重要 提供必要的数据血缘和背景信息,这对于数据治理和故障排除至关重要,尤其是在多个集成系统环境中。 获取方式 这通常是在数据提取和转换过程中添加的静态值,用于标记 data 来源。 示例 Duck Creek Claims | |||
结束时间 EndTime | 指示活动完成时间的时间戳。 | ||
描述 此属性标志着活动的完成时间。StartTime(开始时间)指示活动何时开始,而EndTime(结束时间)则用于界定该特定任务持续时间的终点。 在流程挖掘中,同时拥有活动的开始时间和结束时间,有助于对绩效进行更深入的分析。它能够精确计算“处理时间”(任务上的实际工作时间)与“等待时间”(任务间耗费的时间)。这种区分对于准确识别瓶颈至关重要。 为何重要 能够计算精确的活动处理时间,区分实际工作时间和空闲/等待时间,这对准确进行瓶颈分析至关重要。 获取方式 可能作为事件日志中的一个独立时间戳字段可用,或者可以从同一案件中下一个活动的 StartTime 派生得出。 示例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
解决目标日期 ResolutionTargetDate | 根据 SLA 或内部目标,索赔预期解决的截止日期。 | ||
描述 此属性存储了理赔结案的截止日期。此日期通常由监管要求、服务级别协议(SLA)或内部关键绩效指标(KPI)决定,并可能根据理赔类型或严重程度而有所不同。 它是计算“按时理赔解决率”KPI以及支持“理赔解决目标达成度”仪表盘的基础。它有助于主动监控有违反SLA风险的理赔,并协助工作优先级的设定。 为何重要 能够衡量对照服务水平协议 (SLA) 和内部目标的绩效,这直接影响客户满意度和合规性。 获取方式 请查阅 Duck Creek Claims 文档。这可能是一个特定的SLA日期字段,或根据理赔提交日期和业务规则计算得出。 示例 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
赔付金额 SettlementAmount | 为解决索赔而商定的最终财务金额。 | ||
描述 此属性记录了已计算并授权支付的赔付金额。对于每个涉及支付的理赔而言,这是一个关键的成果导向指标。 此属性对于财务分析以及“支付授权与发放时间”等仪表盘至关重要。它可以与初始“损失金额”进行比较,以分析准备金的准确性,并且是理解理赔流程财务结果的基础数据。 为何重要 代表索赔的关键财务结果,对财务报告和分析初始损失估算的准确性至关重要。 获取方式 请查阅 Duck Creek Claims 文档。此信息通常存储在与理赔相关的财务交易或支付表格中。 示例 1450.7522000.00115800.20 | |||
理赔处理活动
| 活动 | 描述 | ||
|---|---|---|---|
付款已发出 | 此活动标志着理赔款支付财务交易的完成。当款项通过支票、EFT(电子转账)或其他方式发出时,会生成一个清晰明确的事件。 | ||
为何重要 这标志着已批准理赔的财务义务完成。从“Payment Authorized”到“Payment Issued”的时间,揭示了财务部门的效率。 获取方式 从Duck Creek Claims中的财务交易表中捕获,该表记录了所有带有特定交易代码和时间戳的对外支付。 捕获 支付处理时,将创建一个单独的财务交易日志记录。 事件类型 explicit | |||
支付已授权 | 表示对已计算的赔付金额进行正式批准。这通常是一个独特的步骤,涉及经理或单独的授权,并被记录为明确的批准事务。 | ||
为何重要 这是支付前的一个关键控制点和潜在瓶颈。从“做出理赔决定”到此环节的持续时间,由“Average Claim Approval Time”KPI 来衡量。 获取方式 这通常是 workflow 或财务模块中的一个明确 event,由具有特定权限的 user 批准 payment。它会记录在审批日志中。 捕获 工作流或交易日志中明确记录的审批事件。 事件类型 explicit | |||
理赔决定已做出 | 此活动代表对理赔的正式决定,例如“批准”、“部分批准”或“拒绝”。这是一个关键里程碑,通常是从最终决定状态的变更中推断出来的。 | ||
为何重要 这是一个关键的决策里程碑。此前的耗时以及决策结果,对于流程分析和效率提升至关重要。 获取方式 从专门的“索赔决定”或“索赔状态”字段变为“已批准”或“已拒绝”等终结状态时推断得出,并记录此次变更的时间戳。 捕获 根据索赔主状态或决策字段的更新推断。 事件类型 inferred | |||
理赔已拒绝 | 此活动代表流程的一种替代性结束:理赔被正式拒绝。当理赔的最终状态被设置为“拒绝”或“驳回”时,此事件即被捕获。 | ||
为何重要 这是一个需要单独分析的关键结果。了解理赔被拒绝的原因和时间,有助于改进接收流程并加强合规管理。 获取方式 根据索赔实体表中,索赔的最终状态变更为“已拒绝”、“已驳回”或“未付款结案”的时间戳推断。 捕获 根据索赔最终状态为拒绝原因推断。 事件类型 inferred | |||
理赔已提交 | 这是首个 event,代表保险公司收到 First Notice of Loss (FNOL)。通常在代理人或投保人将初步理赔信息输入 system 时,作为一项明确的交易被捕获。 | ||
为何重要 此活动标志着整个理赔流程的起始。分析该事件与其他事件之间的时间差,对于理解整体处理周期和案件接收效率至关重要。 获取方式 当在Duck Creek Claims中首次创建新的理赔记录时,这通常是在理赔或FNOL日志表中记录的一个明确 event。 捕获 新建理赔记录时记录的事件。 事件类型 explicit | |||
理赔已结案 | 这是最终 activity,标志着在付款已发出或理赔已结清后,理赔档案的行政结案。它通过最终 status 更新为“Closed”来捕获。 | ||
为何重要 此活动标志着流程的成功结束。它是计算“平均端到端理赔周期”及其他关键时长指标的终点。 获取方式 根据索赔主数据表中最终状态变更为“已结案”或“已和解”的时间戳推断。 捕获 根据索赔最终状态被设置为“已结案”推断。 事件类型 inferred | |||
初审已完成 | 表示指定理赔员完成了对索赔的首次全面审查。这通常可以从索赔状态在分配后发生变化时推断出来,例如从“已分配”变为“审查中”或“调查中”。 | ||
为何重要 这一里程碑有助于衡量 adjuster 的首次行动时间,并可能预示其工作量存在潜在积压。这是第一个主要的人工驱动检查点。 获取方式 从索赔状态字段的状态变更推断得出,例如,状态变为“初审完成”或“待补充信息”。以此次状态变更的时间戳为准。 捕获 根据理赔员指派后索赔状态字段的变化推断。 事件类型 inferred | |||
损失已评估 | 这一里程碑标志着根据调查结果设定或更新财务准备金。它代表着对理赔财务影响的估算,并在准备金金额被输入或调整时捕获。 | ||
为何重要 这是流程中的一个关键财务检查点。分析其发生时间,有助于深入了解财务评估的速度和准确性。 获取方式 这通常是Duck Creek Claims中理赔财务交易日志或准备金历史表中记录的一项明确的财务交易。 捕获 用于设置或更新理赔准备金的金融交易记录。 事件类型 explicit | |||
收到补充信息 | 标志着已收到所请求的信息,这使得理赔处理得以继续。这可能由理赔员手动记录,或者在信息通过数字门户提交时自动记录。 | ||
为何重要 “信息请求已发送”到“信息已接收”之间的时间是一个关键的等待期。分析此持续时间有助于识别外部依赖和沟通瓶颈。 获取方式 这可以是一个来自文档管理系统集成的明确事件,也可以是理赔员在收到文件后进行的手动日志记录或状态变更。 捕获 在文档上传或理赔员手动录入时记录事件。 事件类型 explicit | |||
理赔员已分配 | 此事件捕获了将理赔员或处理人分配给已注册理赔的过程。系统会记录此次分配,从而创建一个清晰的交接点,并明确该理赔在生命周期中的责任归属。 | ||
为何重要 对于分析资源分配、理赔员工作量以及识别理赔分配中的延误至关重要。这是一个可能导致等待时间的关键移交点。 获取方式 通过对主要理赔 data 表中“Assigned Adjuster”字段的更新进行跟踪。该 field 的 history 或 audit log 提供 timestamp。 捕获 当理赔员字段被填写或更改时,在审计追踪中记录。 事件类型 explicit | |||
理赔已注册 | 标志着提交的理赔被正式接受和登记,此时会正式分配一个唯一的 Claim ID。这通常是初始数据验证后的自动化系统事件。 | ||
为何重要 此活动正式启动索赔流程,并触发后续如理赔员指派等环节。提交与登记之间的时间差,可反映初始数据质量或系统负载是否存在问题。 获取方式 根据主索赔实体表中,主索赔 ID 生成且索赔状态从“待处理”或“已提交”变为“开放”或“已登记”的时间戳推断。 捕获 来源于主要理赔记录的创建时间戳或状态变更为“开放”。 事件类型 inferred | |||
请求补充信息 | 当理赔员确定需要更多信息并向投保人或第三方发送请求时,会发生此活动。这通常是一个明确的事件,会与系统的通信或函件模块关联。 | ||
为何重要 此环节若发生频率过高,可能预示着初始数据收集流程存在问题。这还会导致大量的等待时间,进而影响整体周期。 获取方式 从外发通信日志(例如信件、电子邮件)或Duck Creek Claims中特定的“信息请求”交易中捕获。 捕获 当生成请求信息的函件或任务时记录。 事件类型 explicit | |||
调查已启动 | 此活动标志着理赔正式调查阶段的开始。它通常从理赔状态变更为“正在调查中”或类似状态中推断得出。 | ||
为何重要 这标志着资源密集型阶段的开始。衡量调查持续时间对于“Average Investigation Duration”KPI 至关重要,并有助于管理 process 中的关键部分。 获取方式 根据主索赔状态字段中,索赔状态更新为“调查中”或“待检查”的时间戳推断。 捕获 来源于理赔状态变化,表明调查活动已开始。 事件类型 inferred | |||
调查已完成 | 表示调查活动已结束,所有必要事实均已收集。这通常可以从索赔状态从“调查中”变为“待定决策”等决策状态时推断出来。 | ||
为何重要 完成调查是关键里程碑,为后续的决策和理赔阶段扫清障碍。此环节的任何延误都将对后续流程产生重大影响。 获取方式 根据索赔状态从“调查中”更新为“审查中”或“待决定”状态的时间戳推断。 捕获 来源于理赔状态变化,表明调查活动已结束。 事件类型 inferred | |||
赔付已计算 | 在审批决定后,此活动表示对最终结算或支付金额的计算。这既可以是明确的步骤,也可从系统财务模块中支付金额的最终确定推断得出。 | ||
为何重要 此活动对于衡量“结案返工率”KPI至关重要。此事件在单个理赔中多次发生,表明结案阶段存在效率低下、错误或协商情况。 获取方式 可以是明确的交易日志条目,也可以根据理赔财务数据中“结算金额”字段的更新推断得出。该字段的审计日志是主要数据来源。 捕获 在计算并保存最终赔付金额时记录事件。 事件类型 explicit | |||
提取指南
步骤
- 访问 Duck Creek Data Hub 配置工具:登录 Duck Creek 环境并进入 Data Hub 应用程序。您需要具备创建或修改数据导出配置的相应权限。
- 创建新的数据导出任务:在 Data Hub 工具中,开始创建新的导出任务。为其指定一个描述性名称,例如 ProcessMind_Claims_Event_Log_Export。
- 定义数据源:配置任务以连接到主要的 Data Hub SQL 数据库。您需要提供服务器名称、数据库名称以及具有相关架构读取权限的用户凭据。
- 输入提取查询:进入导出任务的查询定义部分。复制下方 query 部分的完整脚本,并将其粘贴到查询编辑器中。
- 设置查询参数:在配置中找到参数部分。定义并设置查询中引用的 @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]') */。取消注释并修改此行,以筛选特定业务线(例如:“个人汽车险”、“商业财产险”),从而减少数据量并让分析更集中。
- Data Hub 刷新周期: 请注意 Data Hub 的数据延迟。数据并非实时,通常按计划(例如:每晚)刷新。抽取的数据将与最后一次成功的 Data Hub 刷新保持同步。
- 输出格式: 导出任务必须配置为生成平面文件,最好是 CSV 格式。请确保文本限定符设置为双引号("),以正确处理数据字段中的任何逗号。
a 查询示例 config
`config
-- 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;
`