数据模板:理赔处理

FINEOS Claims
数据模板:理赔处理

您的理赔处理数据模板

此模板提供了一种结构化方法,用于收集有效理赔流程分析所需的基本数据。它概述了要跟踪的核心属性和关键活动,并提供了从source systems提取此信息的实用指导。使用它来准备您的event log,加速实现理赔处理优化。
  • 详细分析的推荐属性
  • 需追踪的关键索赔处理活动
  • 实用的数据提取指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

理赔处理属性

为了对您的理赔流程进行全面分析,我们建议在事件日志中包含以下数据字段。
5 必填 8 推荐 10 可选
名称描述
事件时间
EventTime
指示特定活动或事件发生时间的精确时间戳。
描述

事件时间记录了理赔处理活动发生的具体日期和时间。这些按时间顺序排列的数据对于正确排序事件、理解整个理赔过程的时间线至关重要。

在分析中,此时间戳用于计算不同步骤之间的持续时间、流程周期以及等待时间。它是识别延迟、衡量SLA(服务水平协议)绩效并了解流程时间规律的重要基础。

为何重要

此timestamp提供了event的时间顺序,这对于计算所有基于时间的metrics(如cycle time)和识别瓶颈至关重要。

获取方式

此信息通常以创建或更新timestamp的形式,与FINEOS Claims中每个event或状态记录相关联。

示例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
活动名称
ActivityName
在理赔流程某一点发生的特定业务事件或任务的名称。
描述

属性描述了理赔流程中的某个单独步骤或里程碑,例如 'Claim Submitted'、'Initial Review Performed' 或 'Payment Issued'。每项活动代表了对理赔采取的独特行动。

分析这些活动的顺序和频率是流程挖掘的基础。它揭示了实际的流程,有助于识别工作积压的瓶颈,并突出理赔遵循的常见或例外路径。

为何重要

它定义了流程中的各个步骤,从而实现流程图的可视化,并能分析工作流模式及偏差。

获取方式

通常派生自FINEOS Claims系统中的event logs、任务状态变化或审计追踪。

示例
理赔登记损失已评估付款已授权理赔结案
理赔ID
ClaimId
单个保险理赔的唯一标识符,作为流程分析的主要案件标识符。
描述

理赔ID是贯穿理赔生命周期,连接所有活动、事件和数据点的基本键。它确保从最初提交到最终结案的每一个触点,都能作为单个案件被统一追踪。

在流程挖掘中,此属性对于重构每个理赔案件的端到端旅程至关重要。它支持分析流程流、计算总解决时间,并识别不同理赔案件处理方式的差异。

为何重要

这是将所有相关event连接到单个Process instance的核心identifier,使得理赔生命周期的end-to-end分析成为可能。

获取方式

这是FINEOS Claims中主要理赔案件管理表中的primary key。

示例
CL-2023-001234CL-2023-005678CL-2024-009101
最后数据更新
LastDataUpdate
指示此event数据最后一次从source system更新的timestamp。
描述

此属性提供了数据最近一次提取或更新的日期和时间。这对于理解所分析数据的时效性和现时性非常重要。

此信息对数据治理至关重要,并能帮助用户了解他们所查看的是否为最新流程数据。它有助于管理对数据延迟的预期,并且对于报告准实时流程至关重要。

为何重要

表明数据的时效性,确保用户了解分析涵盖的时间周期以及上次刷新时间。

获取方式

此timestamp通常由数据提取或ETL tool在数据加载作业结束时生成并存储。

示例
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
源系统
SourceSystem
识别提取数据所使用的IT系统。
描述

此属性指定了流程数据的来源。对于本次分析,它将始终为“FINEOS Claims”,但在多系统环境中,它对于追踪数据血缘和确保数据质量至关重要。

在更广泛的分析背景下,它有助于区分可能跨越多个系统的流程,并确保基于数据来源进行正确的数据解读。

为何重要

它提供了关于数据来源的关键背景信息,这对于数据治理、验证以及与其他系统集成至关重要。

获取方式

这通常是在数据提取过程中添加的一个静态值,用于标记dataset的来源。

示例
FINEOS ClaimsFINEOS Claims v11.2
指派理赔员
AssignedAdjuster
负责该活动的理赔员或用户的姓名或ID。
描述

此属性标识了在理赔流程中执行特定任务的个人或团队,是将流程活动与人力资源关联起来的主要方式。

通过“指派理赔员”分析数据,对于理解工作量分配、个人绩效和资源效率至关重要。它可以突出显示负担过重的理赔员,通过比较绩效来识别培训机会,并支持更好的资源分配策略以平衡工作量。

为何重要

此属性将流程步骤与执行人员关联起来,从而能够进行工作量分析、资源效率评估和绩效比较。

获取方式

请查阅 FINEOS Claims 文档。此信息通常存储在与理赔事件相关的任务所有权或用户分配字段中。

示例
约翰·史密斯Emily JonesADJ-4561
提交渠道
SubmissionChannel
理赔最初提交的方式或渠道。
描述

此属性记录了理赔案件的接收方式,例如通过在线平台、电子邮件、纸质邮件或代理人。不同的提交渠道可能对数据质量和初始处理时间产生显著影响。

基于提交渠道分析流程,有助于确定某些渠道是否能带来更快的处理速度、更高的返工率(例如由于信息缺失)或更好的结果。这些洞察可以指导渠道优化方面的投资,例如改进在线表单以减少错误。

为何重要

有助于确定不同的受理渠道是否会带来更高效的处理或更高的返工率,从而为渠道战略和投资提供决策依据。

获取方式

请查阅 FINEOS Claims 文档。这通常在理赔接收流程中获取,并存储在主理赔记录上。

示例
在线门户邮件经纪人电话
理赔严重性
ClaimSeverity
对理赔复杂性或潜在财务影响的分类(例如:低、中、高)。
描述

理赔严重性是衡量理赔案件复杂程度、紧急程度或财务风险的指标。严重程度高的理赔案件可能需要更多步骤、专业审查或更长的处理时间,而严重程度低的案件则通常流程相对简单,处理时间更短。

通过按严重程度分析流程,有助于了解资源分配和流程设计是否与不同复杂度的理赔案件相匹配。这能揭示严重程度高的理赔案件是否存在不成比例的延误,或严重程度低的案件是否被过度处理,从而实现更优的流程细分和资源管理。

为何重要

按严重程度进行细分有助于检查流程是否正确优先处理高影响理赔,并识别特定复杂程度是否会导致流程瓶颈。

获取方式

请查阅 FINEOS Claims 文档。这可能是一个专用字段,或从其他属性(例如预估损失金额)派生而来。

示例
复杂
理赔状态
ClaimStatus
事件发生时理赔案件当前或历史状态。
描述

理赔状态表示理赔案件在其生命周期中的所处阶段,例如“开放”、“待补充信息”、“已批准”、“已拒付”或“已结案”。此属性可随时提供理赔案件的即时状态。

在流程分析中,状态变化通常直接对应于流程活动。追踪状态对于理解理赔结果、识别理赔案件长期停滞在某一状态的瓶颈,以及分析“拒付”或“结案”等最终结果的原因至关重要。

为何重要

此属性对于理解理赔结果、筛选进行中或已结案的案件,以及识别理赔案件停滞的阶段至关重要。

获取方式

请查阅 FINEOS Claims 文档。这是主理赔记录上的一个基本字段,其生命周期内会持续更新。

示例
已登记审核中待付款已结案 - 已赔付已结案 - 已拒绝
理赔类型
ClaimType
保险理赔的类别,例如伤残、财产或责任险。
描述

理赔类型根据保单性质或损失情况对理赔案件进行分类。不同类型的理赔案件通常遵循不同的流程变体,具有不同的监管要求,并需要专门处理。

这是进行对比分析的关键维度。通过按理赔类型筛选或细分流程视图,分析师可以发现特定类型的瓶颈,比较不同类别之间的绩效,并根据每种理赔类型的独特需求定制流程改进方案。这有助于回答某些理赔类型是否天生处理效率较低的问题。

为何重要

这有助于对流程进行细分,以便对比绩效,发现不同类型索赔间的差异,从而实现更有针对性的改进。

获取方式

请查阅 FINEOS Claims 文档。这是理赔的核心属性,通常在登记时设置,并存储在主案件表中。

示例
短期伤残长期残疾人寿保险意外死亡
结束时间
EndTime
指示特定活动或事件完成时间的精确时间戳。
描述

“结束时间”属性记录了活动结束的精确时刻。结合“开始时间”(EventTime),它可以精确计算每个步骤完成所需的时间(即其处理时间)。

在分析中,这对于区分主动处理时间和空闲等待时间至关重要。它有助于创建详细的瓶颈分析,显示哪些具体活动耗时最长以及步骤之间何处形成积压。

为何重要

能够精确计算每个 activity 的 processing time,这对于识别 inefficient steps 和 measuring resource utilization 至关重要。

获取方式

请查阅 FINEOS Claims 文档。这可能在 event logs 中可用,或可从后续 event 的开始时间推导得出。

示例
2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T17:00:00Z
解决目标日期
ResolutionTargetDate
根据SLA或法规,预计理赔解决的目标日期。
描述

此属性代表了完成理赔流程的截止日期,该日期由服务水平协议 (SLA) 或监管要求定义。它作为衡量实际绩效的基准。

此日期对于监测SLA合规性至关重要。通过比较实际理赔结案日期与“结案目标日期”,可以计算SLA合规率,识别有SLA违约风险的理赔案件,并分析导致不合规的延迟根本原因。

为何重要

这是衡量SLA合规性的基准。它有助于识别逾期理赔并分析延迟原因。

获取方式

请查阅 FINEOS Claims 文档。此日期通常根据理赔提交日期和类型,通过业务规则计算得出。

示例
2023-11-15T23:59:59Z2024-01-30T23:59:59Z
部门
Department
负责处理该活动或理赔的业务部门或单位。
描述

此属性指定了负责特定活动或在特定阶段拥有理赔案件的组织单位,例如“初步受理”、“调查部门”或“支付部门”。

按部门分析流程对于理解跨部门协作移交至关重要,这些移交是常见的延迟来源。它有助于识别哪些部门存在瓶颈,衡量部门效率,并支持对整个组织资源分配的分析。

为何重要

允许按组织单位进行绩效分析,突出显示部门间交接延误和部门内部瓶颈。

获取方式

请查阅 FINEOS Claims 文档。此信息可与指定理赔员的用户档案或任务分配到的队列相关联。

示例
接收与注册特别调查组付款处理中医疗审查
SLA 状态
SLAState
一个计算得出的状态,指示已完成的理赔是否达到其解决目标日期。
描述

此属性为每笔理赔案件提供了明确的SLA绩效分类状态。它是通过比较“理赔结案”日期与“结案目标日期”,并将结果分类为“按时”或“超期”来得出的。

这简化了SLA合规性的报告和分析。分析师无需处理原始日期数据,可以直接使用此简单类别来创建显示SLA合规率的dashboard,筛选所有超期理赔以分析其共同特征,并随时间监测SLA绩效趋势。它直接支持SLA合规性dashboard和KPI。

为何重要

为每个案例提供清晰、简洁的SLA绩效指标,从而轻松衡量和分析SLA合规率。

获取方式

这是一个计算字段,通过比较最终活动的timestamp与每个case的“ResolutionTargetDate”得出。

示例
准时逾期
保单号码
PolicyNumber
提出理赔的保险保单的唯一标识符。
描述

保单号是承保该理赔的保险合同的标识符。它将理赔与特定客户、保单条款和承保详情关联起来。

尽管它并非直接的流程属性,但它提供了重要的业务背景。它允许按保单或客户汇总理赔数据,这对于分析理赔频率、客户体验以及识别产生大量复杂理赔的保单非常有用。

为何重要

提供关键业务背景,将理赔与特定客户合同关联起来,并支持以客户为中心的流程分析。

获取方式

请查阅 FINEOS Claims 文档。这是在理赔登记时获取并存储在主理赔记录上的一项基本数据。

示例
POL-987654321POL-123456789
处理时间
ProcessingTime
在一项活动上实际投入工作的时间长度。
描述

处理时间是一个计算指标,衡量活动从开始到结束的经过时间。它代表了“实际操作时间”,即资源积极参与任务的期间。

这是绩效分析的基本指标,可区分实际工作和空闲等待时间,更准确评估资源效率,识别耗时活动。它也是计算运营成本和理赔员利用率的关键依据。

为何重要

衡量各项活动中的实际“接触时间”,这有助于查明哪些具体任务最耗时,并准确衡量资源效率。

获取方式

这是通过用活动的EndTime减去其StartTime计算得出的。

示例
2 hours 30 minutes3 days 4 hours15 minutes
客户地区
CustomerRegion
理赔人或保单持有人的地理区域或所在州。
描述

此属性指示与理赔案件相关的地理位置,可以基于索赔人的地址或损失发生地。

地理分析可以揭示理赔类型、频率和处理效率方面的区域差异。它有助于识别某些区域办事处是否比其他办事处表现更好,或者是否存在影响理赔流程的特定地理因素(例如法规、天气事件)。这使得管理和资源分配更具针对性。

为何重要

允许地理区域细分,以识别区域绩效差异、合规性差异或特定地理位置的瓶颈。

获取方式

请查阅 FINEOS Claims 文档。此信息通常来源于系统中存储的保单持有人或索赔人的地址详情。

示例
东北部加利福尼亚州中西部FL
拒绝原因
DenialReason
解释理赔被拒原因的代码或描述。
描述

当理赔结果为“拒绝”时,此属性提供了该决定的具体原因。原因可能包括“不在保单范围内”、“疑似欺诈”或“信息不完整”。

这是理赔拒绝根本原因分析的关键属性。通过分析不同拒绝原因的频率,组织可以识别提交流程中的常见问题、客户对保单覆盖范围的混淆点,或理赔员的潜在培训需求。这些洞察可以促使组织采取措施,降低拒绝率并提升客户满意度。

为何重要

对失败流程的根本原因分析至关重要,有助于识别减少理赔拒绝和提高接收质量的机会。

获取方式

请查阅 FINEOS Claims 文档。这通常是在执行“理赔拒绝”活动时选择的结构化字段或代码。

示例
保单除外责任未提供信息重复理赔涉嫌欺诈
损失日期
LossDate
触发保险理赔的事件发生日期。
描述

“损失日期”指明了实际事件(例如事故、伤害)发生的日期。这与理赔提交日期不同,是理赔验证和处理中的一个重要因素。

此属性提供了有价值的背景信息。损失日期与“理赔提交”日期之间的时间差(报告延迟)可以是一个关键绩效指标。分析此延迟可以揭示报告流程中的问题及其对整个理赔生命周期的影响。

为何重要

提供重要背景,并允许计算报告延迟(从损失发生到提交理赔的时间),这可能影响理赔的复杂性和结果。

获取方式

请查阅 FINEOS Claims 文档。此日期是在“首次损失通知”或理赔登记流程中获取的标准字段。

示例
2023-10-152023-09-012024-02-20
损失金额
LossAmount
与损失相关的预估或预留财务金额。
描述

损失金额代表索赔的初步估算或预留的财务准备金。该金额会随着索赔的调查和评估而更新。

这些财务数据对于索赔的细分至关重要,有助于理解财务影响与流程行为之间的关联。例如,它能帮助回答诸如:高价值索赔是否需要更长的处理时间或更多的返工?它也是财务预测和风险管理的关键输入。

为何重要

为流程提供财务背景,从而分析理赔价值如何影响处理时间、复杂性和流程路径。

获取方式

请查阅 FINEOS Claims 文档。此信息通常位于与理赔关联的财务或准备金相关表格中。

示例
5000.00150000.00250.50
支付金额
PaymentAmount
实际支付的理赔金额。
描述

赔付金额是指索赔结算和批准后最终支付的款项。对于涉及多笔付款的索赔,这可能代表单笔支付交易。

该属性对于财务对账和分析流程的财务结果至关重要。它有助于比较最初估算的损失与最终赔付额。在流程分析中,它能帮助理解不同流程变体或决策所带来的财务影响。

为何重要

跟踪流程的财务结果,这对于衡量财务绩效和分析理赔价值至关重要。

获取方式

请查阅 FINEOS Claims 文档。此数据位于与理赔案件关联的支付交易表中。

示例
4850.00145000.000.00
是否返工
IsRework
一个布尔标志,指示某项活动是否为重复或返工。
描述

此计算属性会标记代表返工的活动,例如同一理赔案件的第二次“请求额外信息”事件。它通常通过检测流程中的重复活动或回溯循环来识别。

明确标记返工简化了侧重于效率低下的分析。它使得返工率(一个核心KPI)的量化变得容易。Dashboards 可以利用此标记来可视化返工的频率和影响,帮助精确定位这些低效循环的根本原因。

为何重要

直接标记出低效的流程循环,方便计算返工率并分析重复工作的驱动因素。

获取方式

这是在Process Mining分析过程中,通过识别同一case的重复活动而得出的。例如,标记“Investigation Started”的第二次出现。

示例
重新开启原因
ReopenReason
解释已结理赔为何被重新开启的代码或描述。
描述

此属性记录了理赔案件从“结案”状态重新变为活动状态的原因。常见原因包括收到新信息、索赔人上诉或错误纠正。

分析重启原因,是衡量流程质量和终结性的直接方式。大量重启的理赔案件,特别是出于某些特定原因的重启,表明最初的结案存在缺陷。此数据可以精确指出调查或决策阶段的薄弱环节,为流程改进提供明确目标,以确保理赔案件首次就能正确结案。

为何重要

直接洞察因理赔过早或错误结案而导致的流程失败,突出提高首次解决率的机会。

获取方式

请查阅 FINEOS Claims 文档。此原因通常在用户在系统中执行“重新开启理赔”操作时被记录。

示例
提起申诉收到新的医疗证据文书错误修正需要调整付款
必填 推荐 可选

理赔处理活动

这些是您事件日志中需要捕获的关键流程步骤和里程碑,以便准确进行流程发现和瓶颈识别。
6 推荐 9 可选
活动描述
付款已发出
标志着款项实际处理并发送给索赔人或服务提供商的时刻。在FINEOS中,这通常由与财务系统的集成触发,并记录为交易日志或最终支付状态更新。
为何重要

这对客户而言是一个关键的“真相时刻”。分析从授权到签发的时间有助于简化支付流程并改善客户体验。

获取方式

这可以是来自FINEOS内部支付交易日志表中的明确事件,或来自集成的应付账款系统。状态变为“已支付”也是一个可能的来源。

捕获

使用支付分类账中的交易日期或状态变为“已支付”的时间戳。

事件类型 explicit
付款已授权
代表对计算出的结算金额进行支付的正式批准。这通常是独立于理赔决策的一个步骤,需要经理或特定团队授权付款。这通过“批准付款”等状态更改来捕获。
为何重要

此活动对于“付款授权周期”这一KPI至关重要。决策到授权之间的延迟,可能是一个影响客户满意度的重要隐性瓶颈。

获取方式

可从理赔状态历史中,状态变更为‘待付款’、‘准备付款’或‘付款已授权’的时间戳推断。

捕获

状态变为“Approved for Payment”(批准付款)或类似状态的timestamp。

事件类型 inferred
理赔决定已下达
一个关键里程碑,保险公司在此正式决定批准、部分批准或拒绝理赔。这几乎总是作为 FINEOS 中明确的状态变更(例如“Approved”、“Denied”或“Settled”等状态)被捕获。
为何重要

这是一个决定后续流程路径(支付或结案)的主要里程碑。它对于衡量决策时间和分析理赔结果至关重要。

获取方式

可从理赔状态历史表中对应最终决策状态(如‘已批准’、‘已拒绝’、‘已驳回’)的时间戳推断。

捕获

状态变为“Approved”(已批准)或“Denied”(已拒绝)的timestamp。

事件类型 inferred
理赔提交
标志着组织首次接收到索赔的时间,通常通过门户网站、电子邮件或信件等多种渠道。这是理赔流程的起点,通常在损失首次通知 (FNOL) 被录入暂存区或直接录入FINEOS时捕获。
为何重要

此活动是流程的主要开始事件。分析从提交到注册的时间,有助于识别数据录入和理赔初始化中的延迟,从而影响整体周期时间。

获取方式

可能从FINEOS系统中初始索赔通知记录或FNOL条目的创建日期捕获。这可能是一个明确的事件日志,或根据与索赔ID相关的最早时间戳推断得出。

捕获

使用损失首次通知(FNOL)或初始理赔记录的创建时间戳。

事件类型 inferred
理赔登记
代表在FINEOS系统中正式创建理赔记录。此时,会正式分配一个唯一的理赔ID,并正式开启案例进行处理。此事件通常从主要理赔对象的创建时间戳中捕获。
为何重要

这是一个关键里程碑,它将理赔从简单的通知转变为一个活跃的case。它作为衡量内部处理生命周期的可靠起点。

获取方式

源自 FINEOS 数据库中主理赔案件 entity 的创建 timestamp。大多数核心系统对象都为审计目的跟踪“创建日期”。

捕获

使用主要理赔案件记录的创建时间戳。

事件类型 explicit
理赔结案
标志着索赔在系统中所有活动(包括支付或拒绝)完成后的最终终止状态。当FINEOS中索赔状态更新为“已关闭”或“已最终确定”时,会捕获此事件。
为何重要

此活动是流程的主要结束事件。从“理赔提交”到“理赔结案”的时间是衡量整体流程绩效和效率的核心KPI。

获取方式

可从理赔状态历史日志中,最终状态变更为‘已关闭’的时间戳推断。这是成功完成理赔的最后一次状态更新记录。

捕获

最终状态变为“Closed”(已结案)或“Finalized”(已完结)的timestamp。

事件类型 inferred
初步审查已执行
表示理赔员或处理人员已完成对理赔有效性、详细信息和所需文件的首次评估。这通常可从FINEOS中的状态变更推断,例如从‘新建’或‘已注册’状态变为‘审核中’或‘已分配’状态。
为何重要

跟踪此步骤的完成有助于衡量首次行动时间,并识别初始分类和分配阶段的积压。此处的延迟会显著延长整个理赔生命周期。

获取方式

可从理赔状态变更为表示审核完成的状态(如‘初审完成’、‘待处理信息’、‘调查中’)的时间戳推断。这些数据通常存储在理赔状态历史表中。

捕获

识别从‘新建’或‘开放’状态变更为审查后状态的时间戳。

事件类型 inferred
损失已评估
表示理赔的财务影响已计算并记录。这可能涉及评估损害赔偿、医疗费用或其他责任。此事件通常在FINEOS中填写并保存了特定的财务评估字段时被捕获。
为何重要

这是一个关键的财务里程碑。调查完成后评估损失所需的时间,可以作为评估团队的绩效指标。

获取方式

很可能根据系统首次填写或最终确定财务准备金或损失估算字段的时间戳推断。这可能不是一个独立的流程状态,而是一个数据录入事件。

捕获

使用财务评估或准备金相关数据字段的“最后更新”时间戳。

事件类型 inferred
收到补充信息
标志着所需文件或信息的接收,从而使理赔处理得以恢复。当索赔状态从“等待信息”更新回“正在审查”或“待评估”等活动状态时,通常会推断出此事件。
为何重要

衡量请求和接收信息之间的时间,能揭示外部延迟。它也标志着内部处理的重新启动,这对于分析等待时间和流程停滞至关重要。

获取方式

可从理赔状态从‘待处理’状态变更为‘活跃’或‘进行中’状态的时间戳推断。相关联的文档上传事件也可能提供特定的时间戳。

捕获

状态从“Pending Information”(待补充信息)变为活跃处理状态的timestamp。

事件类型 inferred
理赔拒付
代表未获批付款的理赔的最终结果。当理赔状态明确设置为“拒绝”或“驳回”时,会捕获此事件。这是流程的一个替代终点。
为何重要

此活动是流程中的一个关键终点。分析导致拒赔的路径,可以深入了解理赔受理质量、保单解读或潜在的欺诈模式。

获取方式

可从状态历史表中,理赔最终状态被记录为‘已驳回’或‘已拒绝’的时间戳推断。

捕获

最终状态变为“Denied”(已拒绝)或“Rejected”(已驳回)的timestamp。

事件类型 inferred
理赔重新开启
当之前已关闭的索赔因上诉或新信息而被重新激活以进行进一步审查或处理时发生。此事件通过状态从“已关闭”或“已拒绝”更改回“正在审查”等活动状态来捕获。
为何重要

跟踪重新开启的理赔对于理解流程异常和故障至关重要。它能突出显示首次未能正确解决的case,从而影响效率和运营成本。

获取方式

可从状态从终结状态(如‘已关闭’)变更为非终结的活跃状态(如‘已重新开启’、‘审核中’)推断。这需要分析状态随时间变化的序列。

捕获

识别状态从关闭变回开放状态的时间戳。

事件类型 inferred
结算已计算
在批准决定之后发生,根据保单限额、免赔额和评估损失计算出确切的支付金额。当在FINEOS中录入并确认最终支付或和解金额字段时,很可能捕获此事件。
为何重要

此活动将计算步骤与审批和付款授权步骤区分开来,有助于分析财务团队在最终确定付款金额方面的效率。

获取方式

根据索赔的最终和解或支付金额在系统财务记录中录入或更新的时间戳推断。

捕获

使用最终结算金额字段的“最后更新”时间戳。

事件类型 inferred
请求补充信息
当理赔员确定需要索赔人或第三方提供更多信息才能继续时,会发生此活动。在FINEOS系统中,这通常通过将状态更改为“待补充信息”或记录特定的对外沟通事件来捕获。
为何重要

这是一项用于分析返工和流程循环的关键活动。此event的高频率表明初始数据收集存在问题,并可能是导致延迟的主要原因。

获取方式

可从理赔状态变更为‘待处理信息’或类似状态推断。也可能是在系统生成请求信息的函件时记录的明确事件。

捕获

状态变为“Pending Information”(待补充信息)或信息请求信函/电子邮件日志条目的timestamp。

事件类型 inferred
调查已完成
标志着所有必要的调查活动已完成,理赔案件已准备好做出最终决定。这通常通过状态从“调查中”变为“待定决策”或“待评估”等后续状态来推断。
为何重要

此活动标志着证据收集阶段的结束。分析从“调查开始”到此点的时间,有助于识别裁决流程本身的瓶颈。

获取方式

可从理赔状态从‘调查中’变更为表示接下来是决策或评估阶段的状态的时间戳推断。

捕获

理赔状态从“Under Investigation”(调查中)变为“Ready for Decision”(待决策)的timestamp。

事件类型 inferred
调查已开始
代表理赔正式调查或裁决阶段的开始。通常在理赔被分配给调查员,或其在FINEOS中的状态明确更改为“调查中”时捕获此信息。
为何重要

这一里程碑标志着流程中可能漫长而复杂部分的开始。跟踪其启动时间对于衡量调查阶段的持续时间和效率至关重要。

获取方式

可从状态变更为‘调查中’或‘裁决中’的时间戳推断。也可能与理赔调查员角色分配的日期相关联。

捕获

理赔状态变为“Under Investigation”(调查中)的timestamp。

事件类型 inferred
推荐 可选

提取指南

如何从FINEOS Claims获取数据

该流程的提取方法正在验证中。请稍后回来查看或 联系我们 寻求帮助。