CN113228077A - 在协调响应于在政策下进行承保的请求的服务和/或支付中用于自动质量管理和识别错误、遗漏和/或偏差的系统、方法和平台 - Google Patents

Abstract

在说明性实施例中，用于监视保险索赔的系统和方法包括基于预定的监视频率识别针对漏洞检测处理识别的保险索赔。可以从索赔的数据文件中提取漏洞检测特征，这提供对可能造成索赔泄漏的索赔处置缺陷的指示。能够使用经训练的漏洞检测数据模型来检测提取的漏洞检测特征内的索赔处置漏洞，其中每个漏洞可以包括该漏洞导致索赔泄漏的可能性。漏洞检测数据模型可以用针对每个索赔向相应的保险提供者定制的数据集进行训练。能够基于检测到的索赔处置漏洞针对索赔计算指示索赔泄漏的总体可能性的漏洞分数。可以在远程计算设备的用户界面屏幕内呈现指派给用户的索赔的漏洞分数。

Description

在协调响应于在政策下进行承保的请求的服务和/或支付中 用于自动质量管理和识别错误、遗漏和/或偏差的系统、方法 和平台

对相关应用的交叉引用

本申请要求于2018年12月27日提交的标题为“Systems,Methods,and Platformsfor Automated Quality Management and Identification of Errors,Omissions and/or Deviations in Coordinating Services and/or Payments Responsive to Requestsfor Coverage Under a Policy”的美国临时专利申请序列No.62/785,539的优先权，该申请通过引用整体并入本文。

发明内容

对说明性实施方式的前述一般描述及其以下详细描述仅仅是本公开的教导的示例性方面，并且并非限制性的。

在一些实施例中，用于监视保险索赔的系统和方法包括基于预定的监视频率识别应用于漏洞检测处理的保险索赔。可以从索赔的数据文件中提取漏洞检测特征，这提供了对可能造成索赔泄漏的索赔处置缺陷的指示。可以使用经训练的漏洞检测数据模型在提取的漏洞检测特征内检测索赔处置漏洞，其中每个漏洞可以包括导致索赔泄漏的漏洞的可能性。可以用向每个索赔的相应的保险提供者定制的数据集来训练漏洞检测数据模型。可以基于检测到的索赔处置漏洞针对索赔来计算指示索赔泄漏的总体可能性的漏洞分数。可以在远程计算设备处的用户界面屏幕内针对被指派给用户的索赔来呈现漏洞分数。

在一些实施例中，索赔监视系统可以包括反馈机制，该反馈机制允许提供自动监督以跟踪对索赔中已识别的漏洞的解决方案，并为索赔处置者(handler)生成可以由监管者使用的表现信息。在一些实施例中，反馈机制可以增加由于先前检测到的漏洞而被识别为具有高泄漏风险的开放索赔的漏洞检测处理的频率。在一些示例中，与具有中等或低泄漏风险的索赔相比，具有高泄漏风险的索赔被更频繁地处理并进行漏洞评估。

附图说明

结合在说明书中并构成说明书一部分的附图图示了一个或多个实施例，并且这些附图与本描述一起解释这些实施例。附图不一定是按比例绘制的。在所附的曲线图和图形中示出的任何值维度仅用于说明目的，并且可以表示或可以不表示实际或优选的值或维度。在适用的情况下，一些或全部特征可以不被示出以帮助描述底层特征。在附图中：

图1是索赔监视系统的示例环境的框图；

图2A是用于生成用于监视索赔质量的数据分析模型的工作流的框图；

图2B是用于从与用于训练漏洞检测数据模型的特征集相关联的损失数据和索赔损失数据中识别目标变量的工作流的框图；

图3是索赔监视系统的有针对性的索赔特征的表；

图4是用于检测与索赔泄漏相关联的漏洞的漏洞度量类别的表；

图5-12图示了用于向保险提供者提供检测到的索赔漏洞信息的用户界面屏幕；

图13A是用于生成经训练的漏洞检测数据模型的示例方法的流程图；

图13B是用于识别用于训练漏洞检测数据模型的目标变量的示例方法的流程图；

图14是用于检测保险索赔内的漏洞的示例方法的流程图；

图15是用于处理向保险提供者进行的索赔漏洞反馈的示例方法的流程图；

图16是示例计算系统的框图；以及

图17是包括云计算环境的示例分布式计算环境的框图。

具体实施方式

下面结合附图阐述的描述旨在描述所公开主题的各种说明性实施例。结合每个说明性实施例描述具体特征和功能；但是，对于本领域技术人员显而易见的是，可以在没有那些具体特征和功能中的每一个的情况下实践所公开的实施例。

在整个说明书中对“一个实施例”或“实施例”的引用意味着结合实施例描述的特定特征、结构或特性被包括在所公开主题的至少一个实施例中。因此，在整个说明书的不同地方出现的短语“在一个实施例中”或“在实施例中”不一定指代相同的实施例。另外，特定特征、结构或特性可以在一个或多个实施例中以任何合适的方式进行组合。另外，所公开主题的实施例旨在覆盖其修改和变化。

必须要注意的是，在说明书和所附权利要求中使用的单数形式“一”、“一个”和“该”包括复数形式，除非上下文另有明确规定。即，除非另有明确规定，否则本文所用的词语“一”、“一个”、“该”等具有“一个或多个”的含义。此外，应理解的是，诸如可在本文中使用的“左”、“右”、“顶部”、“底部”、“前”、“后”、“侧面”、“高度”、“长度”、“宽度”、“上部”、“下部”、“内部”、“外部”、“内”、“外”等之类的术语仅仅描述参考点，而不必将本公开的实施例限制到任何特定的朝向或配置。此外，诸如“第一”、“第二”、“第三”等之类的术语仅仅标识如本文所公开的多个部分、组件、步骤、操作、功能和/或参考点中的一个，并且同样不必将本公开的实施例限制到任何特定配置或朝向。

此外，术语“近似”、“大约”、“邻近”、“微小变化”和类似术语一般是指包括在20％、10％或在某些实施例中优选为5％(以及它们之间的任何值)的余量内的识别的值的范围。

除非明确说明或者特征或功能与附加实施例不兼容，否则结合一个实施例描述的所有功能旨在适用于下面描述的附加实施例。例如，在结合一个实施例明确描述但开放合替代实施例明确提及的给定特征或功能的情况下，应当理解的是，发明人意图可以结合替代实施例部署、利用或实现这些特征或功能，除非这些特征或功能与替代实施例不兼容。

保险提供者聘请质量保证管理者和一线管理者来监视其组织内的保险索赔(insurance claim)处置方式，以减少发生的索赔泄漏(leakage)的量(由于未能遵守与索赔处置相关的现有政策和规程造成的索赔管理效率低下而损失的金钱)。但是，这些管理者中的每一个常常在他们的监督下有成百上千的索赔，这使得不可能对所有开放(open)索赔进行彻底审查。因此，管理者只审查开放索赔的小样本，从而使提供者容易受到未经审查的索赔的影响。另外，执行手动审查的管理者依靠他们的直觉来检测索赔中的漏洞(vulnerability)和缺陷，这可能无法准确反映索赔泄漏的真正原因。此外，对关闭的(closed)保险索赔执行审计既费时又费力(大约6-8周)。因此，不经常进行关闭索赔文件审计，这延迟了可以通过从如何识别索赔的泄漏和处置不当的根本原因中吸取的经验教训来创造的价值。

本公开的各方面针对用于监视保险索赔以识别可能造成索赔处置过程低效的漏洞的计算系统和方法。在一些实施方式中，保险公司的索赔处置人员与计算系统交互以提供与保险索赔相关联的文档，该文档可以包括结构化数据和非结构化数据。例如，结构化数据可以包括直接输入到系统的数据(例如，保险单(insurance policy)信息、联系索赔人的日期和时间、官方医疗诊断)，这些数据可以被组织并存储在关系数据库中。非结构化数据可以包括来自多种格式的复杂数据源的存储的任何信息(例如，关于与索赔人、医疗专业人员、执法专业人员或车辆检查者进行的任何通话或交互的记载(note)、收据、警察报告、医疗记录、针对汽车保险索赔的汽车检查报告)。因为索赔监视系统可以通过高效地从多种格式的数据源中定位并提取有针对性的特征而从结构化和非结构化索赔数据中提取有针对性的特征，所以系统识别索赔泄漏的能力显著提高，这是因为数据不仅限于结构化数据。

基于所提供的信息，在一些示例中，索赔监视系统可以处理开放索赔的文档和数据，以识别索赔处置过程中可能导致索赔泄漏的弱点或漏洞，该索赔泄漏是由于未能遵守与索赔处置相关的现有政策和规程而造成的索赔管理效率低下而损失的金钱的量。在一些示例中，来自索赔管理效率低下的金钱损失表现为诉讼成本(如果已经遵循适当的索赔处置过程则本可以减轻这些诉讼成本)，或者表现为由于索赔处置服务不佳而引起的客户损失。可能导致索赔泄露的漏洞问题的示例是：未能及时呼叫索赔的一方、未能识别可能的承保(coverage)问题、未能在适当的时间将索赔提交给律师，以及未能获得针对索赔的适当文件。在一些示例中，索赔监视系统还可以处理关闭索赔以识别关闭索赔内的漏洞，计算系统可以使用这些漏洞来自适应地学习索赔的哪些特性导致了造成泄漏的负面结果。

在一些实施方式中，索赔监视系统使用一个或多个数据集来训练用以识别索赔漏洞的机器学习数据模型，这些数据集已针对客户自己的业务实践和与顾客进行的索赔处置交互被定制。在一些示例中，系统处理客户的关闭索赔，从而提取与客户如何处理索赔相关的特征以生成客户数据集。在一个示例中，客户数据集被归一化并与来自多个数据源的历史数据融合以产生针对客户的定制数据集。在一些示例中，系统用针对特定客户的融合数据集和与主动识别索赔漏洞相关的有针对性的加权训练变量的集合来训练数据模型。在一些示例中，基于每个变量对识别特定类型的索赔泄漏的相对重要性对训练变量进行加权。

在一些实施例中，系统通过将经训练的数据模型应用于提取的开放索赔的特征来识别开放索赔集合的漏洞。在一些实施方式中，经训练的数据模型向系统提供关于如何从保险索赔的非结构化数据中提取有价值的特征的经学习的机器知识。例如，基于经训练的模型，索赔监视系统可以识别由索赔处置者、医疗专业人员、执法人员、车辆检查者和提供索赔文档的其他人使用的关键短语，这些关键短语可以被用于基于相对于关键特征使用它们的方式来识别与潜在漏洞相关的索赔特征。在一些示例中，索赔监视系统可以使用经训练的数据模型，基于开放索赔的识别的特征来预测一个或多个漏洞问题已经发生的可能性。系统还可以基于每个开放索赔发生泄漏的可能性对开放索赔进行评分。在一些实施例中，系统在识别出漏洞时向索赔处置监督者发出通知，使得索赔处置者可以在索赔泄漏发生之前纠正任何识别的漏洞。

在一些实施方式中，索赔监视系统还可以包括闭环反馈回路，该回路对已识别的索赔漏洞的解决方案执行过程中验证。例如，系统可以增加对由于先前检测到的漏洞而被识别为具有高泄漏风险的开放索赔的漏洞检测处理的频率。在其它示例中，系统可以基于在指派给保险公司的每个索赔处置者的索赔或索赔集合内检测到的索赔漏洞的数量或百分比来对相应的索赔处置者的表现进行排名或评分。在一些示例中，每个索赔处置者可以相对于与保险公司相关联的其它索赔处置者或相对于在组织内具有类似经验或资历的索赔处置者进行排名。在一些示例中，索赔监视系统可以增加处理被指派给其表现(如表现分数或排名所证明的)低于组织中的其他索赔处置者的表现(或低于具有相似经验的其他索赔处置者的表现的索赔处置者的索赔的频率。

本文提供的本公开的实施方式是对索赔监视的手动、常规方法的显著改进，并且必然植根于计算机技术。常规的索赔监视系统依赖于质量保证和一线管理者的手动文件审查。因为这些管理者中的每一个都常常在他们的监督下有成百上千的索赔，所以他们不可能对所有开放索赔进行彻底审查。因此，管理者只审查开放索赔的小样本，使提供者容易受到未经审查的索赔的影响。另外，执行手动审查的管理者依靠他们的直觉来检测索赔中的漏洞和缺陷，这可能无法准确反映索赔泄漏的真正原因。本公开的实施方式通过提供对人工审查方法的显著改进来提供对技术问题的技术方案，因为本公开的系统和方法可以在整个索赔期间周期性地对提供者的所有开放索赔执行实时审查。另外，因为系统使用向各个保险提供者定制的经训练的漏洞检测数据模型来检测索赔漏洞，所以使用标准化的、经校准的漏洞检测度量而不是人类直觉中的不一致、主观和盲点来处理索赔。

因为对关闭的保险索赔执行审计既费时又费力，所以不经常进行关闭索赔文件审计，这延迟了可以通过从如何识别泄漏和索赔处置不当的根本原因中吸取的经验教训来创造的价值。本公开通过提取由机器学习算法识别的非结构化索赔数据文件中的有针对性的漏洞检测特征来为根植于计算机技术的技术问题提供技术方案。通过持续(例如，每天、每周、每月或每当识别出新的关闭索赔时)更新用于训练提供者的漏洞检测数据模型的数据集，索赔监视系统可以持续地充分利用从关闭的保险索赔中学到的知识来识别开放的保险索赔中的漏洞。

图1是索赔监视系统108的示例环境100的图。该图说明了用于采集、生成、组织、存储和分发信息的关系、交互、计算设备、处理模块和存储实体，该信息是主动检测与处置保险索赔的方式相关的潜在问题(称为漏洞)并提供有关如何解决问题以防止或减少索赔泄漏的建议所必需的。在一些实施方式中，用于保险提供者的索赔管理者102a和处置者102b(统称为保险提供者102)可以使用漏洞检测和解决信息来有效地评估索赔处置者的表现并通过系统108的反馈机制向索赔处置者提供训练，这增加了对检测到的漏洞的索赔的监视频率以确定漏洞的根本原因是否已得到解决。

在某些实施例中，保险提供者102可以经由分布在范围可以是国家或国际的大型网络的多个计算设备连接到索赔监视系统108。保险提供者102的网络可以分离和独立于索赔监视环境100中的其它实体(诸如外部实体104)相关联的网络。此外，保险提供者102所处置和存储的数据可以采用与损失确定环境100的其它实体所处置和存储的数据不同的格式。在一些示例中，保险提供者102可以包括经纪人、保险/再保险公司，或通过执行与索赔处置和监视相关的动作而与索赔监视系统108交互的任何其他人。例如，提供者102可以包括保险公司员工102a(他们确保从报告保险索赔的时间到做出最终索赔决定和对应的支付的正确索赔处置)，以及监督索赔处置者102a表现的保险公司的管理者102b。

在一些示例中，索赔处置人员102a经由一个或多个分布式计算设备与保险索赔的各方(例如，对于车祸而言为执法人员、医疗专业人员、乘坐损坏的汽车的每个司机或人、车辆检查者)交互并向系统108提供与这些交互相关联的输入。与给定索赔相关联的任何数据都作为索赔数据112存储在数据储存库110中，该索赔数据112可以包括结构化数据和非结构化数据。在一些示例中，索赔数据112可以包括开放索赔和关闭索赔的数据。在一些实施方式中，索赔处置者102a可以将数据直接输入到系统108中，这些数据被组织成关系数据库并被存储为结构化数据(例如，保险单信息、索赔识别代码、联系索赔人的日期和时间、官方医学诊断)。索赔处置者102a还可以向系统108提供与索赔相关的其它文档，这些文档作为多种格式的非结构化数据被存储在数据储存库110中。在一些示例中，索赔处置者102a可以通过从数据源(例如，收据、警察报告、医疗记录、汽车保险索赔的汽车检查报告)扫描、上传或下载来向系统提供文档。非结构化数据还可以包括索赔处置者直接输入到系统的自由文本记载(free text note)(例如，关于与索赔人、医疗专业人员、执法专业人员或车辆检查者进行的任何通话或交互的记载)。在一个示例中，相应的索赔组合的索赔数据112包括与相应的索赔相关联的文档文件和数据表条目的组合。此外，系统108可以在数据储存库110中存储每个保险提供者102的索赔数据112。

在一些实施例中，保险提供者102还可以包括保险公司的索赔处理管理者102b，其监督保险公司组织内的索赔处置者的组的表现。在一些实施方式中，索赔监视系统108可以向索赔处置管理者102b提供关于在他或她的审查下的索赔处置者102a的表现以及在管理者的权限下的任何索赔内的任何检测到的漏洞的信息。在一些示例中，系统108在仪表板界面屏幕内向管理者102b提供索赔处置信息，管理者可以通过在界面屏幕处提供登录凭证来访问该界面屏幕。

在接收到管理者登录凭证后，系统108向关联的计算设备提供仪表板界面屏幕，其具有在管理者102b的监督下被指派给索赔处置者102a的每个索赔的概要视图(参见图5A-5C)。在一些示例中，仪表板界面屏幕内的概要视图显示审查的优先级(图5A中的显示字段504)，其与在相应的索赔内检测到的一个或多个漏洞将导致泄漏的可能性相对应。例如，与审查优先级为“低”或“在正常进行(on track)”的索赔相比，具有高审查优先级的索赔检测到的漏洞更有可能导致泄漏或与泄漏相关的成本更高。索赔监视系统108还为管理者102b提供了查看和深入了解索赔漏洞的细节的机会，该细节可以包括系统108检测到的每种类型的漏洞、与可能导致索赔泄漏的漏洞相关联的问题、基于检测到的漏洞的问题发生的可能性，以及问题的一个或多个潜在根本原因(参见图10)。在一些示例中，管理者102b可以与由系统108呈现的用户界面屏幕进行交互以提供关于检测到的漏洞的问题解决的信息或者标记一个或多个检测到的漏洞以供日后跟进。

在一些实施方式中，外部实体104包括分布在范围可能是国内或国际的大型网络上的多个计算设备。外部实体的网络可以分离和独立于与损失确定环境100中的其它实体(诸如保险提供者102)相关联的网络。此外，外部实体104所处置和存储的数据可以采用与索赔监视环境100中的其他参与者所处置和存储的数据不同的格式。外部实体104可以包括与索赔监视系统108接口以提供与处理索赔相关的数据的任何类型的外部系统，诸如医疗设施计算系统、执法计算系统和检查者计算系统。在一些示例中，外部实体104可以直接将索赔文档上传到系统108而无需索赔处置者102a的干预。例如，医疗专业人员可以将涉及开放索赔108的患者的医疗记录上传或传输到索赔监视系统108并与索赔数据112内的适当索赔相关联。

在一些示例中，外部实体104还可以包括其它索赔监视系统、政府或组织的计算系统，这些计算系统提供与保险索赔和由于索赔处置方式而导致的任何泄漏相关的历史数据。在一些实施方式中，系统索赔监视108将从外部实体104接收的数据连同从与系统108交互的保险提供者102收集的数据作为历史数据116存储在数据储存库110中。在一些实施例中，索赔监视系统108用历史数据116和特定于提供者的产生数据的组合(其被称为融合数据118)来训练用于检测索赔内的漏洞的机器学习数据模型。

在一些实施例中，索赔监视系统108可以包括一个或多个引擎或处理模块130、132、134、136、138、140、142、146，这些引擎或处理模块执行与针对漏洞来监视开放的保险索赔相关联的处理，这些漏洞可能导致索赔泄漏和保险提供者102的潜在可防止费用。在一些示例中，由索赔监视系统108的引擎执行的处理可以被实时执行以提供对系统输入的即时响应，该系统输入诸如索赔处置管理者102b查看在管理者102a的监督下正由索赔处置者102a处置的所有开放索赔的状态的请求。此外，还可以响应于处理触发器而自动执行处理，处理触发器可以包括特定的日期或时间，或者对来自数据提供者(例如，外部实体104之一，诸如医疗提供者或执法人员)、索赔处置者102a之一、管理者102b之一或另一个处理引擎的数据的接收。

在一些实施方式中，索赔监视系统108可以包括用户管理引擎130，其可以包括与提供界面以与索赔监视环境100内的一个或多个用户(例如，被保险提供者102雇用或以其它方式与保险提供者102相关联的个人，诸如索赔处置者102a和管理者102b)交互相关联的一个或多个处理。例如，用户管理引擎130可以经由在保险提供者102的一个或多个外部设备158处的认证界面来控制保险提供者102对索赔监视系统108的连接和访问。在一些示例中，外部设备170可以包括但不限于个人计算机、膝上型/笔记本计算机、平板计算机和智能电话。在一些实施方式中，用户管理引擎130控制向哪个系统用户显示哪些系统数据。例如，用户管理引擎130将每个索赔处置者102a和管理者102b与开放和/或关闭的保险索赔的集合相关联，并且仅显示与该索赔集合和/或其它授权信息相关联的信息以供特定用户基于接收到的身份认证凭证进行查看和编辑。

在一些实施方式中，索赔监视系统108包括索赔处理引擎146，其从由系统108监视的每个保险索赔(无论是开放的还是关闭的)的存储的索赔数据112中提取关键漏洞检测特征。当处理来自保险索赔的非结构化数据时(例如，针对汽车保险索赔为关于与索赔人、医疗专业人员、执法专业人员或车辆检查者进行的任何通话或交互的记载、收据、警察报告、医疗记录、汽车检查报告)，索赔处理引擎146可以将自然文本检测算法应用于非结构化数据文件以提取文件的文本特征。在一些示例中，索赔处理引擎146使用学习到的机器知识来确定索赔中的结构化数据和非结构化数据两者的哪些特征适用于索赔漏洞检测。例如，学习到的机器知识可以包括由在汽车保险索赔的上下文中的索赔处置者、医疗专业人员、执法人员、车辆检查者和提供索赔文档的其他人使用的特定短语，这些短语可以被用于基于相对于关键特征使用它们的方式来识别与潜在漏洞相关的索赔的特征。

在一些实施方式中，索赔处理引擎146从关闭的保险索赔中提取关键漏洞检测特征，其称为客户产生数据129。在一个示例中，漏洞检测特征可以基于相应的提供者的业务规则和索赔处置处理而特定于各个保险提供者102。除了一个或多个默认特征之外，分析训练引擎134还可以使用机器学习算法基于特定提供者102的索赔之间的共享特性来随时间学习附加的特定于提供者的漏洞检测特征。在其它示例中，提供者102可以直接向索赔处置系统108提供他们的业务规则和索赔处置特性。在一些示例中，分析训练引擎134使用客户产生数据129结合历史数据116来训练机器学习数据模型以检测可能造成索赔泄露的开放索赔内的漏洞。

在一些实施例中，索赔处理引擎146还从开放的保险索赔中提取关键漏洞检测特征，漏洞检测引擎138使用这些特征来识别开放索赔中的泄漏漏洞。在一个示例中，索赔处理引擎146将从每个开放的保险索赔中提取的关键漏洞特征组织成特征向量，这些特征向量作为索赔特征向量114被存储在数据储存库110中。在一些实施例中，漏洞检测引擎138通过将经训练的数据模型应用于开放索赔特征向量114的提取的特征来识别开放索赔集合的漏洞。在一些实施方式中，漏洞检测特征可以包括与一个或多个漏洞度量相关联的任何信息(参见图4)。例如，漏洞检测特征可以包括与保险索赔相关联的每一方的联系日期、每一方的未接来电的日期、来自与每一方的对话的概要的摘录(例如，关键词、短语、句子)、保险单的承保信息、有关移交给管理层或法律顾问的信息、调查行动计划信息、各方陈述的概要、损失信息和责任分析信息。

在一些示例中，索赔监视系统108还可以包括数据管理引擎132，其组织、存储和控制对数据储存库110中的数据的访问。例如，响应于接收到与保险索赔相关联的文档的上传，数据管理引擎132基于共用的识别特性(例如，索赔编号、索赔报告日期、事故日期、受影响的各方的姓名和/或出生日期)将该文档与特定索赔链接起来并将链接的文档存储为索赔数据112。另外，在从索赔处置者102a或管理者102b接收到关于对检测到的漏洞的解决的任何更新后，用户管理引擎132更新索赔数据112。

在一些实施方式中，数据管理引擎132还从历史数据116和客户产生数据129生成融合数据集。在一些示例中，数据管理引擎132将由索赔处理引擎146针对相应的提供者102生成的客户产生数据129规一化以与历史数据116兼容并且将规一化的客户产生数据129、历史数据116融合为向相应的提供者102定制的单个融合数据集118。

例如，图3图示了针对历史数据116、客户产生数据129、融合数据118和/或开放的保险索赔的索赔特征向量114的索赔特征302的表300。包括在表300内的索赔特征302并不意味着是详尽的列表，而仅仅是系统108可以用来检测与索赔泄露相关联的漏洞的特征的示例。在一些实施方式中，索赔特征302可以包括：索赔识别信息，索赔开放的日期，指派的索赔处置者，索赔的类型，损失描述，与赔偿、医疗、准备金和救助相关的损失金额，是否已经进行了法律诉讼，以及监督者识别代码。此外，索赔特征302还可以包括外部理算员是否参与索赔评估处理的指标、诉讼状态指标、索赔是否涉及救助项目和救助项目的总金额，以及索赔是否为有资格代位(subrogation)。每个索赔特征302具有由数据管理引擎132使用的对应的规一化方法304，以规一化客户产生数据129的索赔特征以便与存储的历史数据116兼容。例如，归一化方法304可以包括将特征映射到特定值(例如，是/否)、将特征转换成浮点值、去除缩写或转换成另一预定格式。在一些示例中，索赔特征302可以与由分析训练引擎134用来训练如图2B中所示的漏洞检测数据模型的、提取的特征226和/或目标变量228相对应。

返回图1，在一些实施方式中，索赔监视系统108还包括分析训练引擎134，其训练使用受监督的和/或不受监督的机器学习算法与系统108交互的每个提供者102的漏洞检测数据模型。因为每个融合数据集118是向个体提供者102定制的，所以分析训练引擎134可以生成也是向个体提供者102定制的经训练的数据模型。在一些示例中，分析训练引擎134用来自针对提供者102的对应的融合数据集118和与主动识别索赔内导致索赔泄漏的漏洞相关的有针对性的加权训练变量124的集合的数据，来训练针对该提供者102的漏洞检测数据模型。在一些示例中，训练变量和权重124是手动提供给系统108并存储在数据储存库110中的默认值。在一个示例中，分析训练引擎134可以随着机器学习知识库的增长而自动更新训练权重和变量124(例如，随着在图6-7中所示的UI屏幕600和700处从用户接收到反馈、突出显示和评价)。在一些实施方式中，训练变量与融合数据集118的索赔特征和索赔特征向量114相对应。

在一些实施例中，分析训练引擎134在周期性的基础上为提供者102发起定制的漏洞检测数据模型的训练以并入已经关闭的索赔的附加数据，这是因为漏洞检测数据模型先前被训练为确保经训练的数据模型可以利用来自所有关闭索赔的知识。例如，如果分析训练引擎134通过将与针对提供者102的经训练的漏洞模型相关联的日期与作为索赔数据112存储在数据储存库110中的提供者102的索赔关闭日期进行比较，确定经训练的模型不包含最近关闭的索赔数据，则其发起用于训练相应的漏洞检测数据模型的处理(参见图13A中的方法1300)。

图2A图示了索赔监视系统108如何训练针对每个提供者102的漏洞检测数据模型的工作流200。在一些实施方式中，索赔处理引擎146从提供者102的关闭的保险索赔204中提取与历史损失运行数据202相结合的特征，这些特征被用于训练针对每个提供者102的整体漏洞检测数据模型212。在一些实施例中，索赔处理引擎146包括损失描述特征提取器206，其从与索赔的可量化损失特性相关的关闭索赔数据中提取特征214。例如，损失特性可以包括赔偿损失、医疗损失、储备损失和总损失的损失量、损失类型和救助总额。在一些实施例中，在索赔文档中没有提供损失描述的情况下，损失描述特性提取器206可以从所有的索赔记载中导出对损失的描述。在一些实施方式中，损失描述特征提取器206从索赔文档中提取关键词以生成对索赔的损失描述。

在一些示例中，数据管理引擎132将与损失描述特征提取器206所识别的可量化损失特性相关联的特征214与历史损失运行数据202融合以形成第一融合数据集，其由分析训练引擎134用来训练诊断数据模型210。在一些实施方式中，可以训练诊断数据模型210以输出在保险索赔处理的每个阶段中发生索赔处置违规或其它漏洞的概率。例如，诊断数据模型210的输出以概率方式表示索赔处置过程中可能具有违规或其它漏洞的阶段。

在一些示例中，索赔处理引擎146还包括索赔记载特征提取器208，其使用自然文本检测和其它非结构化数据处理技术从索赔记载(例如，关于与索赔人、医疗专业人员、执法专业人员或车辆检查者进行的任何通话或交互)以及与索赔相关联的其它非结构化数据(例如，针对汽车保险索赔为收据、警察报告、医疗记录、汽车检查报告)提取一个或多个相关特征216。在一些实施方式中，索赔记载特征提取器208通过将特定规则集应用于索赔记载来提取特征。例如，索赔记载特征提取器208可以应用联系检测规则来检测索赔处置者何时与索赔的一方进行联系的实例。在一些示例中，索赔记载特征提取器208可以将自然文本检测算法应用于非结构化数据文件以提取文件的文本特征。

在一些示例中，索赔处理引擎146使用学习到的机器知识来确定索赔中结构化数据和非结构化数据的哪些特征适用于索赔漏洞检测。例如，学习到的机器知识可以包括在汽车保险索赔的上下文中的索赔处置者、医疗专业人员、执法人员、车辆检查者和提供索赔文档的其他人所使用的特定短语，这些短语可以被用于基于相对于关键特征使用它们的方式来识别与潜在漏洞相关的索赔的特征。在一个示例中，由索赔记载特征提取器208提取的特征216可以包括与司机、乘客或证人的初始和后续联系的日期和时间、索赔处置者与保险索赔的各方进行通信时使用的关键短语、使用这些短语的调查和上下文(例如，在电话呼叫或电子邮件中)、承保分析信息损失和误工费文档信息。

在一些实施方式中，由索赔记载特征提取器208提取的特征216与诊断数据模型210和历史损失运行数据202的输出218融合，并被用于训练整体漏洞检测数据模型212。在一些实施方式中，因为提取的索赔记载特征216与诊断数据模型210的输出融合，所以通过从自个体提供者102接收的数据中去除偏差而改进了整体漏洞检测数据模型212的输出并且还放大了用于训练整体漏洞检测数据模型212的数据集。

图2B图示了用于从与用于训练针对每个提供者102的漏洞检测数据模型的特征集相关联的损失数据和索赔损失数据来识别目标变量的工作流220的示例。在一些示例中，像漏洞检测数据模型这样的受监督学习算法可以使用与目标变量链接的特征/预测器的集合来训练数据模型。在一些示例中，目标变量可以与由经训练的漏洞检测数据模型识别的漏洞度量对应。在一些实施方式中，当用于训练漏洞检测数据模型的学习算法的数据集没有关于目标训练变量的正确枚举的和标记的信息时，会出现困难。在一些示例中，当从开放索赔数据和关闭索赔数据两者中提取索赔记载数据224和历史损失运行数据222时，会出现这种类型的困难，这是因为提取的数据是非结构化和未标记的。在一些实施方式中，索赔监视系统108可以被配置为使用模式识别技术来识别提取的数据中的模式以检测用于准确训练漏洞检测数据模型的目标变量。此外，目标变量可以表示一种可以被检测的漏洞或可以从一组提取的索赔特征中得出的结论。

例如，索赔监视系统108的漏洞检测数据模型可以被用于检测针对特定的索赔人是否需要记录的陈述(R/S)。如果基于检测到的特征的各方面而需要记录的陈述并且该记录的陈述没有出现在提取的索赔数据224中，那么可以检测到与索赔泄漏相关联的漏洞。在这个示例中，是否应当采用记录的陈述可以被认为是模型要识别的目标变量。因此，分析训练引擎134可以扫描提取的历史索赔数据，以获取记录的陈述是否被采用的证据连同其它与确定获得记录的陈述的必要性相关联的特征。在这个示例中，训练漏洞检测数据模型的学习算法可以应用来自历史损失运行数据、责任分析和索赔人信息(例如，年龄、性别和其它人口统计信息)连同目标变量信息(例如，是否采用记录的陈述)的数据特征来训练漏洞模型。但是，因为理算员在他们的索赔记载中使用自然语言来记录是否采用了记录的陈述，所以可能无法正确识别记录的陈述的目标变量信息以供受监督学习算法使用。

为了解决这个困难，在一些实施方式中，分析训练引擎134和/或索赔处理引擎146可以在机器学习步骤之前应用文本抓取或其它类型的信息提取来具体地识别和提取目标变量228和索赔记载数据224和/或历史损失运行数据222内相关联的特征数据226。在一些示例中，当检测和提取目标变量(228)时，分析训练引擎134可以被配置为检测某些单词模式是否出现在记载中并且使用该模式来创建用于训练漏洞检测数据的目标变量模型。例如，在索赔记载的集合中，如果分析训练引擎134识别短语“R/S with John Doe(Doe的R/S)”，那么引擎134可以将“是”应用于用于记录的陈述训练变量的目标变量。在一些实施例中，一旦分析训练引擎134检测到训练变量是否存在于索赔记载数据和损失运行数据中的结构化数据和非结构化数据两者中，检测到的特征和训练变量被链接230。在一些示例中，链接的目标变量和特征数据可以被用于漏洞检测数据模型232的训练。识别非结构化索赔数据和损失运行数据228中的目标变量并将提取的目标变量链接到可能并不总是提供显式变量识别的相关联特征230的这个过程为从非结构化的自然语言索赔记载数据和历史损失运行数据检测和生成结构化的目标变量的技术问题提供了技术方案，其可以被用于训练针对每个提供者102的定制的漏洞检测数据模型。另外，因为每个链接的目标变量和特征的集合特定于特定的提供者，所以进一步定制经训练的漏洞检测数据模型以检测针对每个提供者102的索赔漏洞，即使提供者102在将索赔记载输入到系统108时可以使用不同的记录惯例。在一些示例中，链接的目标变量和相关联的特征与被用于训练针对每个提供者102的漏洞检测数据模型的索赔特征向量中的条目对应。

返回到图1，在一些实施方式中，索赔监视系统108还包括漏洞检测引擎138，以实时地识别可能导致索赔泄露的正在处置索赔的方式的问题。因为分析训练引擎134生成向每个提供者定制的训练数据模型，所以漏洞检测引擎138可以实时地检测与特定于个体提供者102的索赔泄漏相关的漏洞。例如，每个提供者102可以具有与特定于个体提供者102的公司政策和规程相关联的索赔处置度量，并且漏洞检测引擎138可以识别反映提供者102的特定索赔处置度量的漏洞。

在一些示例中，漏洞检测引擎138通过将针对提供者102的经训练的漏洞检测数据模型应用于提供者的开放索赔的提取的特征来识别开放索赔集合的漏洞。在一些实施例中，基于由漏洞检测数据模型识别的索赔处置缺陷的模式，漏洞检测引擎138输出在索赔中检测到的一个或多个漏洞，这些漏洞对应于与索赔泄漏相关联的一种或多种类型的漏洞度量121。在一些示例中，索赔监视系统108在数据储存库110中存储漏洞度量121的集合，经训练的漏洞检测数据模型使用该集合来检测索赔内的漏洞。

例如，图4是示出漏洞度量类别402和针对每个类别402的对应的总体泄漏可能性404的表400，该总体泄漏可能性404指示了每个漏洞度量类别402相对于预测索赔泄漏的相对重要性。在一些实施方式中，每个漏洞度量类别402具有一个或多个对应的漏洞度量，漏洞检测引擎138通过应用漏洞检测数据模型使用该漏洞度量来识别任何索赔漏洞。在一些实施例中，类别内的每个漏洞度量具有其自己的个体泄漏可能性，该个体泄漏可能性指示相应的度量对于给定索赔是否发生泄漏的相对影响。例如，“联系”度量类别可以具有相关联的漏洞度量，诸如与所有相关方的初始联系是否及时和适当，以及是否与所有适用的各方进行了后续联系。另外，“调查”度量类别可以具有相关联的漏洞度量，例如调查行动计划的所有要素是否得到妥善处置、是否采用了所有必要的陈述、损失事实调查是否已正确完成、非汽车财产损失调查是否已正确完成、是否已正确通知特别调查组(SIU)，以及是否已完成适当的第三方调查。

返回到图1，通过在利用定制的漏洞检测数据模型的机器学习算法上运行特定开放索赔的特征向量，漏洞检测引擎138基于开放索赔是否满足每个度量来识别其中的泄漏漏洞。在一些实施例中，漏洞检测引擎138还计算每个检测到的漏洞将导致泄漏的可能性520(例如，很有可能、有可能或似乎有可能)，该可能性520与由训练模型做出的漏洞预测的置信水平对应。在一些示例中，每个索赔的检测到的漏洞和相关联的泄漏可能性被存储为数据储存库110中的漏洞数据120。在一些示例中，由索赔监视系统108维护的每个开放索赔通过漏洞检测引擎138以周期性间隔和/或在索赔的生命周期中的预定点处针对漏洞进行处理。在一些实施方式中，漏洞检测引擎138应管理器102b的请求和/或作为反馈循环引擎140所确定的反馈检查来处理索赔。

在一些实施方式中，索赔监视系统108还可以包括索赔评分引擎142，其基于检测到的漏洞计算每个开放索赔的分数，该分数作为索赔评分数据128被存储在数据储存库110中。在一些实施方式中，针对每个索赔计算的分数可以是在每个索赔内检测到的漏洞数量和与检测到的漏洞相关联的对应的泄漏可能性(例如，严重性级别)的函数。在一个示例中，分数可以是检测到的漏洞的泄漏可能性(例如，与漏洞相关联的索赔泄漏的严重、高、中和低可能性)的平均值。在其它示例中，索赔评分引擎142可以基于检测到的漏洞的总数来增加索赔的总体泄漏可能性。例如，如果检测到五个具有“中等”泄漏可能性的漏洞，那么索赔评分引擎142可以为索赔指派“高”的分数，因为检测到的漏洞的阈值数量已被超过。在其它示例中，索赔的分数与索赔内检测到的任何漏洞的最高泄漏可能性相对应。例如，如果在索赔中检测到一个漏洞的泄漏可能性为“高”(例如，(一个或多个)专家的报告的不恰当使用)并且检测到一个漏洞的泄漏可能性为“低”(例如，索赔不应当被升级或移交)，那么索赔评分引擎142为索赔指派“高”的总分。在其它示例中，索赔评分引擎将索赔评分计算为在一定范围(例如，0到10)内的百分比或值，其中较低的分数指示基于检测到的漏洞的数量和严重性的索赔泄漏的较低概率，而较高的分数指示索赔泄漏的更高可能性。

在一些实施例中，索赔评分引擎142可以基于针对每个索赔的计算出的分数来生成提供者102的开放索赔的排名。在一些实施方式中，索赔评分引擎142可以相对于提供者102的所有开放索赔或索赔的子集对索赔进行评分。例如，可以相对于由相同的索赔处置者102a处置的其它索赔或相对于与特定管理者102b相关联的其它索赔对每个开放索赔进行排名。在另一个示例中，一个索赔处置者所处置的索赔集合可以相对于另一个索赔处置者所处置的另一索赔集合进行排名。在一些示例中，索赔排名还可以作为索赔评分数据128被存储在数据储存库110中。

在一些实施方式中，索赔监视系统108还包括反馈循环引擎140，其提供自动照管机制，用于跟踪识别的索赔漏洞的解决方案，并生成索赔处置者102a的表现信息，管理者102b可以使用这些信息来做出人员决策(例如，晋升、终止)或提供附加训练。例如，反馈循环引擎140可以增加由于先前检测到的漏洞而被识别为具有高泄漏风险的开放索赔的漏洞检测处理的频率。在一个示例中，与具有中等或低泄漏风险的索赔相比，具有高泄漏风险的索赔被更频繁地处理和进行漏洞评估。

在一些实施方式中，反馈循环引擎140可以基于在一个或多个用户界面(UI)屏幕处从索赔处置者102a和/或管理者102b接收到的反馈来调整处理索赔的频率和/或调整开放索赔的漏洞分数。例如，对于每个检测到的漏洞，指派的管理者102b可以提供关于是否不需要对检测到的漏洞采取行动、是否已经采取行动来解决检测到的漏洞的问题，或在预定天数内再次提醒管理者102b(参见图6中UI屏幕600的数据字段608)的反馈。在一些示例中，由管理者102b和/或索赔处置者102a在UI屏幕处提供的反馈可以作为反馈数据126被存储在数据储存库110中。

在一些示例中，反馈循环引擎140可以基于漏洞的数量或百分比以及在指派给相应的索赔处置者102a的索赔或索赔的集合中检测到的对应泄漏可能性对特定提供者的每个索赔处置者102a的表现进行排名和/或评分。在一些示例中，反馈循环引擎140可以相对于与提供者相关联或指派给特定管理者102b的其他索赔处置者102a来对每个索赔处置者102a进行排名。在其它示例中，反馈循环引擎140可以相对于在组织内具有相似数量的经验或资历的其他索赔处置者102a来对索赔处置者102a进行排名。在一些示例中，对于表现排名低于预定阈值的索赔处置者102a(例如，在提供者的所有索赔处置者102a的表现的最低百分比内，比具有类似经验的其他索赔处置者102a表现更差的索赔处置者102a，或始终具有低评分索赔的索赔处置者102a)，反馈循环引擎140可以自动增加由索赔监视系统108处理和评估由低表现的索赔处置者102a处置的索赔的频率。与索赔处置者102a的排名和/或分数相关的信息可以作为处置者表现数据127被存储在数据储存库110中。

在一些实施方式中，索赔监视系统108还可以包括前端驱动器引擎136，其通过一个或多个UI屏幕和/或消息传递格式(例如，电子邮件、文本消息或应用界面上的通知)来控制数据的传播以及与保险提供者102进行的交互。在一些实施例中，用户对系统108的访问是通过网站或web托管的应用提供的。在一些示例中，前端驱动器引擎136可以响应于从索赔处置者102a和/或管理者102b接收到的查询来向外部设备158输出信息，该查询用以查看一个或多个开放索赔的漏洞、发起针对索赔的漏洞检测，并且查看指派的索赔处置者102b的集合的表现分数或排名。例如，如图5A中所示，在提供登录凭证后，管理者102b可以在概要UI屏幕500处查看在管理者102b的监督下被指派给索赔处置者的索赔的集合，并且可以在细节UI屏幕536处查看关于与索赔相关联的漏洞的细节(图5C)。

此外，响应于在UI屏幕处接收到输入，前端输出引擎136可以实时地输出与所提供的输入相关联的任何信息。例如，响应于接收到对查看检测到的漏洞的潜在根本原因的选择，前端驱动器引擎136可以实时地呈现根本原因UI屏幕(例如，图10中的根本原因UI屏幕1000)，该屏幕提供检测到的漏洞的每个潜在根本原因的发生概率。

图5-12图示了用于向保险提供者102提供检测到的索赔漏洞信息的UI屏幕，该保险提供者102可以包括管理者102b和/或索赔处置者102a。如图5A中所示，在用户管理引擎130验证登录凭证后，前端驱动器引擎136呈现提供了被指派给用户的开放索赔列表的概要视图UI屏幕500，在一个示例中，用户可以是管理者102b。在一些实施方式中，概要视图UI屏幕500可以提供一个或多个可排序的和/或可过滤的索赔细节字段，诸如索赔编号502、问题优先级504、业务线506(例如，汽车、家庭)、承保代码508(例如，碰撞、财产损失)、理算员/索赔处置者姓名510、监督者姓名512、索赔被开放的日期514、损失日期516、索赔已经开放的天数518和风险暴露类型520。在一些实施例中，问题优先级504与在索赔内检测到的任何漏洞的最高泄漏可能性(例如，低、中或高)相对应。在一些示例中，如果没有检测到漏洞，那么问题优先级字段504可以指示索赔“在正常进行”。在一些实施方式中，前端驱动器引擎136可以响应于用户输入而根据特性502-520中的一个或多个来分类和/或过滤索赔。

图5B示出了索赔过滤UI屏幕522，其允许系统用户根据过滤器输入字段524-534处的一个或多个准则来过滤在概要UI屏幕500中呈现的索赔。在一些实施方式中，过滤准则输入字段可以包括业务线524、理算员姓名526、监督者姓名528、损失日期530、开放天数范围532和问题优先级/泄漏可能性534。其它过滤准则还可以包括准备金、费用和损失金额以及暴露类型。

图5C中的UI屏幕示出了在选择概要视图UI屏幕500(图5A)内呈现的索赔之一时由前端驱动器引擎136呈现的索赔细节UI屏幕536。在一些示例中，索赔细节UI屏幕536提供与检测到的可能导致索赔泄露的漏洞或问题相关的详细信息。例如，UI屏幕536可以包括索赔概要部分538，其包括在图5A中所示的概要视图UI屏幕500中针对索赔显示的信息的至少一部分。在一些示例中，索赔概要部分538可以包括索赔编号、业务线、承保代码、开放日期、损失日期、开放天数、风险类型、特征编号、被保险人姓名、损失描述、理算人姓名、准备金金额、费用金额、已付损失和问题优先级。在一些示例中，索赔细节UI屏幕536还可以包括警告部分540，其显示与索赔相关联的一个或多个检测到的漏洞的概要信息。在一些示例中，检测到的漏洞的概要信息可以包括与漏洞相关联的索赔阶段542(例如，联系阶段)、与漏洞相关联的引导实践问题544(例如，“是否与所有相关方进行了初始联系？”)、问题可能性546(例如，很可能)、潜在问题548(例如，未与被保险人进行联系尝试)和监督者550。

在选择“审查和完成”选择器552后，前端驱动器引擎136可以呈现如图6中所示的警告审查和完成UI屏幕600。在一些示例中，审查和完成UI屏幕600可以显示时间线部分602，其包括与索赔相关联的不同类型事件(例如，第一次损失通知、承保分析完成、责任分析完成、联系索赔人、检测投保责任)的日期。在一些实施方式中，UI屏幕600还可以包括警告细节部分，其显示在UI屏幕536(图5C)处的警告部分540中显示的警告信息的一部分。如果查看警告的用户完成或者确认完成与警告相关联的任务(例如，尝试与被保险人联系)，那么用户可以在完成选择器606处指示完成。否则，用户可以为系统108设置警告提醒608以输出与警告相关联的任务需要被完成的提醒。在一些实施方式中，警告提醒608可以设置为数小时、数天、数周或其它时间段。在一些示例中，检测到的漏洞的警告信息将被保留在UI屏幕536(图5C)的警告部分540中，除非管理者102b选择“在[X]天内提醒”并且该天数尚未过去或者检测到的漏洞的泄漏可能性已降低(例如，从“可能”到“似乎有可能”或从“很有可能”到“有可能”)。

在一些实施例中，在UI屏幕536(图5C)选择“评价”选择器554后，前端驱动器引擎136可以呈现如图7中所示的审查和评价UI屏幕700。在一些实施方式中，审查和评价UI屏幕700呈现由指派给保险索赔的索赔处置者102a和/或管理者102b输入的所有索赔记载。在一些实施方式中，如果索赔记载审查者识别出已经在索赔记载中的相应警告的解决方案，那么审查者可以突出显示并添加相关联的评价。例如，对于在UI屏幕536图5C)中示出的关于未进行初始联系的警告，如果审查者识别出初始联系被记录的位置，那么审查者可以突出显示索赔记载文本702的适用部分并添加对突出显示表示什么进行注释的评价704。在一些示例中，可以将索赔警告审查者在UI屏幕700处提供的任何反馈添加到用于训练漏洞检测数据模型的数据中，从而可以提高模型在自动检测索赔处置事件方面的准确性。

在其它示例中，UI屏幕536(图5C)还包括先前问题部分，其提供所有先前检测到的漏洞以及与每个检测到的漏洞相关联的任何反馈、解决方案或放大信息的日志。在一些实施方式中，一旦管理者102b提供了关于检测到的漏洞的反馈和/或解决了该漏洞，前端驱动器引擎136就将漏洞及其相关联的反馈移动到先前问题部分。在一些实施例中，前端驱动器引擎136还可以呈现如图10中所示的根本原因UI屏幕1000，其呈现检测到的漏洞的可能根本原因的列表以及每个潜在根本原因的对应发生概率。例如，对于在调查阶段期间检测到的具有遗漏陈述的漏洞，该漏洞有48％的可能性是由于警察或其他官方人员的陈述没有被采用，24％的可能性是由于潜在证人的陈述没有被采用，并且有12％的可能性是指定的被保险人的陈述没有被采用。

图11-12示出了统计概要UI屏幕1100、1200的示例，其允许用户查看提供者102的索赔处置统计，这允许他们看到索赔处置者102a随着时间的推移在索赔处置过程的各个方面进展的趋势。例如，在图11中的UI屏幕1100处，诸如管理者102b之类的用户可以基于过滤准则1102的集合来查看索赔处理统计1104-1114，过滤准则1102可以包括理算人姓名、监督者姓名、通知日期和通知月份。在一些示例中，索赔处理统计1104-1114可以包括跨越几个月或几年的时间段的趋势线，其显示了针对与指定准则1102相关联的每个索赔的联系被保险人的时间1104和联系索赔人的时间1106以及责任分析时间1108的量。在一些实施例中，UI屏幕1100还可以显示条形图，该条形图示出满足用于完成与索赔处理相关联的任务的预定时间帧的索赔数量(例如，联系被保险人的时间1110、与索赔人交谈的时间1112、责任分析时间1114)。

此外，在图12中的UI屏幕1200处，诸如管理者102b之类的用户可以基于警告类型来查看漏洞警告随时间的变化趋势，该警告类型可以基于过滤准则1202的集合而包括理算员姓名、监督者姓名、通知日期和通知月份。例如，在图12中的UI屏幕1200处，用户可以查看诸如趋势线1204和1206之类的警告趋势线，其示出了相应的索赔处置者102a(理算员)的警告的数量和类型。在一些示例中，趋势线1204与尝试联系但未实现与索赔人联系的警告数量对应，并且趋势线1206与未尝试联系索赔人的警告数量对应。UI屏幕1200允许管理者102b看到索赔处置者102a在避免可能导致索赔泄露的漏洞警告事件方面所做的进展(或缺乏进展)。

除了通过网站或应用在UI屏幕上查看索赔漏洞信息之外，在一些实施例中，用户还可以接收其它消息传递格式的索赔漏洞信息，诸如电子邮件或文本消息。例如，图8示出了UI屏幕800，其允许用户调整电子邮件通知设置，以决定他们是否希望在每日电子邮件、每周电子邮件或不在电子邮件中接收索赔漏洞信息。图9示出了前端驱动器引擎136向管理者102b提供的每日电子邮件900的示例，其包括在管理者102b的监督下的索赔的新的或更新后的漏洞数据。例如，电子邮件900包括具有已在最后一天内出现的新漏洞的索赔的部分904和具有未决漏洞问题的索赔的部分906。在一些实施方式中，电子邮件900包括用于在选择电子邮件900中的索赔链接之一后访问索赔细节UI屏幕902(例如，图6中的UI屏幕600和610)的网络链接。

转向图13A，图示了用于训练漏洞检测数据模型的示例方法1300的流程图。在一些示例中，方法1300由索赔监视系统108(图1)的数据管理引擎132、索赔处理引擎146和分析训练引擎134执行。在一些实施例中，方法1300在周期性基础上被执行以并入自从训练针对相应的保险提供者102的漏洞检测数据模型以来已经关闭的索赔的附加数据。

在一些实施方式中，方法1300开始于分析训练引擎134确定针对相应的提供者102的当前训练模型是否是最新的(1302)。在一些示例中，分析训练引擎134通过将与针对提供者102的经训练的漏洞模型相关联的日期与作为索赔数据112被存储在数据储存库110中的提供者102的索赔关闭日期进行比较来确定经训练的模型是否并入了最近的关闭索赔数据。

如果针对提供者的经训练的漏洞检测数据模型不是最新的，那么在一些实施方式中，索赔处理引擎146从关闭的保险索赔中提取关键漏洞检测特征，其被组织为客户产生数据129(1304)。在一个示例中，漏洞检测特征可以基于相应的提供者的业务规则和索赔处置过程而特定于各个保险提供者102。

在一些实施例中，数据管理引擎132将针对提供者102的客户产生数据与历史数据116融合以形成用于训练针对提供者102的漏洞检测数据模型的融合数据集118(1306)。在一些示例中，数据管理引擎132将由索赔处理引擎146针对相应的提供者102生成的客户产生数据129规一化以便与历史数据116兼容，并且将规一化的客户产生数据129、历史数据116融合为向相应的提供者102定制的单个融合数据集118。

在一些实施方式中，分析训练引擎134使用受监督的和/或不受监督的机器学习算法利用融合数据集118来训练针对提供者102的漏洞检测数据模型(1308)。因为每个融合数据集118是向个体提供者102定制的，所以在一些示例中，分析训练引擎134可以生成也是向个体提供者102定制的训练数据模型。在一些示例中，分析训练引擎134用来自针对提供者102的对应的融合数据集118和与主动识别索赔内导致索赔泄漏的漏洞相关的有针对性的加权训练变量124的集合的数据，来训练针对该提供者102的漏洞检测数据模型。在一些示例中，训练变量和权重124是手动提供给系统108并存储在数据储存库110中的默认值。在一些实施方式中，训练变量与融合数据集118的索赔特征和索赔特征向量114相对应。

在一些示例中，分析训练引擎134输出针对提供者102的经训练的漏洞检测数据模型(1310)，并且还在一些方面，基于经训练的模型输出针对提供者102的有针对性的索赔特征(1312)。例如，分析训练引擎134可以使用经训练的漏洞检测数据模型基于提供者102的索赔之间的共享特性随时间学习附加的特定于提供者的漏洞检测特征。

虽然在特定的一系列事件中进行了说明，但在其它实施方式中，漏洞检测数据模型训练过程1300的步骤可以以不同的次序执行。例如，可以在输出有针对性的索赔特征(1312)之前、之后或同时执行输出经训练的漏洞检测数据模型(1310)。此外，在其它实施例中，该过程可以包括更多或更少的步骤，同时保持在漏洞检测数据模型训练过程1300的范围和精神内。

图13B是用于识别用于训练漏洞检测数据模型的目标变量的示例方法1320的流程图。在一些实施方式中，方法1320可以由分析训练引擎134、数据管理引擎132和/或索赔处理引擎146来执行。在一些示例中，方法1320可以结合索赔特征提取(1304)以及漏洞检测数据模型训练过程1300的索赔数据与历史数据的融合(1306)来执行。

在一些示例中，方法1320开始于从索赔记载数据和损失运行数据中提取特征和目标变量(1322)。在一个示例中，漏洞检测特征可以基于相应的提供者的业务规则和索赔处置过程而特定于各个保险提供者102。

在一些实施方式中，如果在提取的数据中没有识别出目标变量或丢失目标变量(1324)，那么在一些示例中，分析训练引擎134可以应用一种或多种模式识别技术来检测在提取的数据中的目标变量(1326)。例如，用于训练漏洞检测数据模型的目标变量可以包括在特定情况下是否需要来自索赔人或被保险人员的记录的陈述。如果在从索赔记载和损失运行数据中提取信息之后，记录的陈述是否被采用不是立即明显的，那么在一些示例中，分析训练引擎134可以使用模式识别来检测提取的数据内的训练变量的证据。在一些实施例中，模式识别技术可以包括应用自然语言分类器，其被训练为检测与非结构化索赔记载数据内的目标变量相关联的标识符。在一些示例中，检测到的目标变量可以被链接到提取的特征(1328)，在一些方面，这些特征可以被用于训练漏洞检测数据模型(1330)。

虽然在特定的一系列事件中进行了说明，但在其它实施方式中，目标变量识别过程1320的步骤可以以不同的次序执行。例如，确定目标变量是否从提取的数据中丢失(1324)可以在将检测到的目标变量链接到相应的数据特征(1328)之前、之后或同时执行。此外，在其它实施例中，该过程可以包括更多或更少的步骤，同时保持在目标变量识别过程1320的范围和精神内。

转向图14，图示了用于检测索赔漏洞的示例方法1400的流程图。在一些示例中，方法1400由索赔监视系统108(图1)的数据管理引擎132、索赔处理引擎146和漏洞检测引擎138执行。在一些示例中，方法1400可以针对由系统108监视的每个开放索赔周期性地执行。

在一些实施方式中，方法1400开始于漏洞检测引擎138识别索赔以进行漏洞检测(1402)。在一些示例中，每个开放索赔的索赔数据112包括处理频率和/或下一处理日期，该下一处理日期指示基于包括默认处理频率、预定索赔处理里程碑和先前检测到的漏洞在内的因素接下来何时要针对漏洞来处理索赔。在一些示例中，管理者102b可以在管理者102b的监督下手动发起针对一个或多个索赔的漏洞检测处理。

在一些实施方式中，索赔处理引擎146从存储的索赔数据112中为针对漏洞检测处理识别的开放索赔提取关键漏洞检测特征(1404)。在一些示例中，索赔数据112可以包括结构化数据和非结构化数据两者。在一个示例中，结构化数据可以包括直接提供给系统108并存储在相关数据库中的数据(例如，保险单信息、索赔识别代码、联系索赔人的日期和时间、官方医疗诊断)。此外，在一些示例中，针对汽车保险索赔而言，非结构化数据可以包括关于与索赔人、医疗专业人员、执法专业人员或车辆检查者进行的任何通话或交互的记载、收据、警察报告、医疗记录、汽车检查报告。为了从非结构化数据中提取特征，在一些实施方式中，索赔处理引擎146可以将自然文本检测算法应用于非结构化数据文件以提取文本特征。

在一些实施例中，索赔处理引擎146将从每个开放的保险索赔中提取的关键漏洞特征组织成特征向量，这些特征向量作为索赔特征向量114被存储在数据储存库110中(1406)。在一些实施例中，漏洞检测引擎138可以通过将针对提供者102的相应的经训练的漏洞检测数据模型应用于开放索赔特征向量114的提取的特征来实时地识别开放索赔集合的漏洞(1408)。因为分析训练引擎134生成向每个提供者定制的经训练的数据模型，所以漏洞检测引擎138可以实时地检测与特定于个体提供者102的索赔泄漏相关的漏洞。在一些实施例中，基于由漏洞检测数据模型识别的索赔处理缺陷的模式，漏洞检测引擎138输出在索赔中检测到的一个或多个漏洞，这些漏洞对应于与索赔泄漏相关联的一种或多种类型的漏洞度量121。

在一些实施方式中，如果在开放索赔中检测到任何漏洞(1410)，那么在一些示例中，漏洞检测引擎138确定与每个检测到的漏洞相关联的泄漏可能性(1412)。在一个示例中，索赔的检测到的漏洞的泄漏可能性(例如，很有可能、有可能或似乎有可能)可以与经训练的漏洞检测数据模型所做出的漏洞预测的置信水平相对应。

在一些实施方式中，基于检测到的漏洞和发生泄漏的可能性，索赔评分引擎142计算索赔的漏洞分数(1414)。在一些实施方式中，为每个索赔计算的分数可以是在每个索赔内检测到的漏洞数量和与检测到的漏洞相关联的对应的泄漏可能性(例如，严重性级别)的函数。在一个示例中，分数可以是检测到的漏洞的泄漏可能性(例如，与漏洞相关联的索赔泄漏的严重、高、中和低可能性)的平均值。在其它示例中，索赔评分引擎142可以基于检测到的漏洞的总数来增加索赔的总体泄漏可能性。例如，如果检测到五个具有“中等”泄漏可能性的漏洞，那么索赔评分引擎142可以为索赔指派“高”的分数，因为检测到的漏洞的阈值数量已被超过。在其它示例中，索赔的分数与在索赔内检测到的任何漏洞的最高泄漏可能性相对应。例如，如果在索赔中检测到一个漏洞的泄漏可能性为“高”(例如，(一个或多个)专家的报告的不恰当使用)并且检测到一个漏洞的泄漏可能性为“低”(例如，索赔不应当被升级或移交)，那么索赔评分引擎142为索赔指派“高”的总分。在其它示例中，索赔评分引擎将索赔评分计算为在一定范围(例如，0到10)内的百分比或值，其中较低的分数指示基于检测到的漏洞的数量和严重性的索赔泄漏的较低概率，而较高的分数指示索赔泄漏的更高可能性。

在一些实施方式中，如果与索赔分数相关联的泄漏可能性大于预定阈值(1416)，那么前端驱动器引擎136可以经由电子邮件、文本消息或应用通知向指派的管理者102b输出自动通知(1418)。在一些示例中，漏洞检测引擎138基于可以包括索赔漏洞分数、先前计算的索赔漏洞分数(例如，索赔已经以高泄漏可能性被重复评分)以及到达下一个索赔里程碑之前的预计时间量在内的因素来计算索赔的下一个审查日期(1420)。

虽然在特定的一系列事件中进行了说明，但在其它实施方式中，漏洞检测过程1400的步骤可以以不同的次序执行。例如，可以在确定下一个索赔审查日期(1320)之前、之后或同时执行确定该分数是否保证执行对管理者102b的通知(1416)。另外，可以同时执行漏洞检测过程1400的多个实例以使用被分配给索赔监视系统108的处理资源来检测多个开放索赔中的漏洞。此外，在其它实施例中，该过程可以包括更多或更少的步骤，同时保持在漏洞检测过程1400的范围和精神内。

转向图15，图示了用于处理对保险提供者的索赔漏洞反馈的示例方法1500的流程图。在一些示例中，方法1500由索赔监视系统108(图1)的用户管理引擎130、反馈回路引擎140和前端驱动器引擎136执行。

在一些实施方式中，方法1500开始于用户管理引擎130从系统用户(例如，管理者102b或索赔处置者102a)接收登录凭证(1502)。在一些示例中，用户管理引擎130将与接收到的登录凭证相关联的系统用户关联于指派的开放和/或关闭的保险索赔的集合。在一些实施例中，前端驱动器引擎136在系统用户的远程计算设备处呈现一个或多个指派的索赔的索赔数据和/或其它授权信息(1504)。例如，在从管理者102b接收到登录凭证后，前端驱动器引擎136可以在UI屏幕500(图5A)处呈现在管理者102b的监督下被指派给索赔处置者102a的索赔集合，并且可以查看关于与在UI屏幕536(图5C)处的索赔相关联的漏洞的进一步细节。

在一些实施方式中，如果系统用户(例如，管理者102b)在UI屏幕(例如，图7中的UI屏幕700中的突出显示702和评价字段704)提供对一个或多个检测到的漏洞的反馈(1506)，那么在一些示例中，反馈回路引擎140更新对应的索赔数据112以反映出该反馈(1508)。例如，反馈循环引擎140可以基于接收到的反馈来调整开放索赔的漏洞分数。在一些示例中，反馈回路引擎140还可以将提供的反馈并入到用于训练漏洞检测数据模型的训练数据(例如，训练变量/权重124)中。

在一些实施例中，如果接收到的反馈和/或索赔数据112指示应当更新索赔的处理频率(1510)，那么在一些示例中，反馈回路引擎140确定用于索赔的更新后的处理频率(1512)。例如，反馈循环引擎140可以增加对由于先前检测到的漏洞而被识别为具有高泄漏风险的开放索赔的漏洞检测处理的频率。在另一个示例中，反馈循环引擎140可以更新下一个索赔处理日期以与由管理者102b设置的提醒日期相对应(参见图6中UI屏幕600、610的数据字段608)。在又一个示例中，反馈循环引擎140可以基于接收到的已经对检测到的漏洞采取行动的反馈来降低索赔处理频率。

虽然在特定的一系列事件中进行了说明，但在其它实施方式中，反馈处理过程1500的步骤可以以不同的次序执行。例如，更新索赔数据以包括接收到的反馈(1508)可以在确定索赔的更新后的处理频率(1512)之前、之后或同时执行。此外，在其它实施例中，该过程可以包括更多或更少的步骤，同时保持在反馈处理过程1500的范围和精神内。

接下来，参考图16描述根据示例性实施例的计算设备、移动计算设备或服务器的硬件描述。例如，计算设备可以表示外部实体104、保险提供者102(例如，索赔处置者102a和管理者102b)，或支持索赔监视系统108的功能的一个或多个计算系统，如图1中所示。在图16中，计算设备、移动计算设备或服务器包括执行上述过程的CPU 1600。处理数据和指令可以存储在存储器1602中。在一些示例中，处理电路和存储的指令可以使计算设备能够执行图13-15的方法1300、1400和1500。这些过程和指令还可以被存储在存储介质盘1604(诸如硬盘驱动器(HDD)或便携式存储介质)上，或者可以被远程存储。另外，要求保护的进步不受其上存储本发明过程的指令的计算机可读介质的形式的限制。例如，指令可以存储在CD、DVD、闪存、RAM、ROM、PROM、EPROM、EEPROM、硬盘或计算设备、移动计算设备或服务器与之进行通信的任何其它信息处理设备(诸如服务器或计算机)中。在一些示例中，存储介质硬盘1604可以存储图1的数据储存库110的内容，以及在由索赔监视系统108访问和传送到数据储存库110之前由外部实体104和保险提供者102维护的数据。

另外，要求保护的进步的一部分可以作为实用程序、后台守护程序或操作系统的组件或其组合提供，结合CPU 1600和诸如Microsoft Windows 9、UNIX、Solaris、LINUX、Apple MAC-OS之类的操作系统以及本领域技术人员已知的其它系统来执行。

CPU 1600可以是来自美国英特尔(Intel)的Xenon或Core处理器或者来自美国AMD的Opteron处理器，或者可以是本领域普通技术人员能够识别的其它处理器类型。可替代地，CPU 1600可以在FPGA、ASIC、PLD上实现或使用分立逻辑电路来实现，如本领域普通技术人员将认识到的。另外，CPU 1600可以被实现为并行地协同工作以执行上述本发明过程的指令的多个处理器。

图16中的计算设备、移动计算设备或服务器还包括网络控制器1606，诸如来自美国英特尔公司的英特尔以太网PRO网络接口卡，用于与网络1628接口。如可以认识到的，网络1628可以是公共网络(诸如互联网)，或专用网络(诸如LAN或WAN网络)，或其任何组合，并且还可以包括PSTN或ISDN子网。网络1628也可以是有线的(诸如以太网)，或者可以是无线的(诸如包括EDGE、3G、4G和5G无线蜂窝系统的蜂窝网络)。无线网络还可以是Wi-Fi、蓝牙或任何其它已知的无线通信形式。例如，网络1628可以支持在索赔监视系统108与外部实体104和保险提供者102中的任何一个之间的通信。

计算设备、移动计算设备或服务器还包括显示控制器1608，诸如来自美国NVIDIA公司的NVIDIA GeForce GTX或Quadro图形适配器，用于与显示器1610(诸如惠普HPL2445w液晶显示器)接口。通用I/O接口1612与键盘和/或鼠标1614以及在显示器1610上或与显示器1610分离的触摸屏面板1616接口。通用I/O接口还连接到各种外围设备1618，包括打印机和扫描仪，诸如惠普的OfficeJet或DeskJet。在一些示例中，显示控制器1608和显示器1610可以实现图5-12中所示的用户界面的呈现。

在计算设备、移动计算设备或服务器中还提供声音控制器1620，诸如来自Creative的Sound Blaster X-Fi Titanium，以与扬声器/麦克风1622接口，从而提供声音和/或音乐。

通用存储控制器1624将存储介质盘1604与通信总线1626连接，通信总线1626可以是ISA、EISA、VESA、PCI或类似物，用于互连计算设备、移动计算设备、或服务器的所有组件。为了简洁起见，本文省略了对显示器1610、键盘和/或鼠标1614以及显示器控制器1608、存储控制器1624、网络控制器1606、声音控制器1620和通用I/O接口1612的一般特征和功能的描述，因为这些特征是已知的。

除非另有明确说明，否则可以利用一个或多个处理器来实现本文描述的各种功能和/或算法。此外，除非另外明确说明，否则本文描述的任何功能和/或算法可以在一个或多个虚拟处理器上执行，例如在一个或多个物理计算系统(诸如计算机群或云驱动器)上执行。

已经参考了根据本公开实施方式的方法、系统和计算机程序产品的流程图图示和框图。其各方面由计算机程序指令实现。这些计算机程序指令可以被提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器以产生机器，使得经由计算机或其它可编程数据处理装置的处理器执行的指令创建用于实现流程图和/或一个或多个框图方框中指定的功能/动作的方法。

这些计算机程序指令也可以存储在计算机可读介质中，其可以指导计算机或其它可编程数据处理装置以特定方式运行，使得存储在计算机可读介质中的指令产生包括执行流程图和/或一个或多个框图方框中指定的功能/动作的指令部件的制品。

计算机程序指令也可以被加载到计算机或其它可编程数据处理装置上，以使得在计算机或其它可编程装置上执行一系列操作步骤，从而产生计算机实现的过程，使得在计算机或其它可编程装置上执行的指令提供用于实现流程图和/或一个或多个框图方框中指定的功能/动作的过程。

而且，本公开不限于本文描述的特定电路元件，本公开也不限于这些元件的特定尺寸和分类。例如，本领域技术人员将认识到的是，本文描述的电路可以基于电池尺寸和化学性质的变化或基于要供电的预期备用负载的要求而被适配。

本文描述的功能和特征也可以由系统的各种分布式组件来执行。例如，一个或多个处理器可以执行这些系统功能，其中处理器分布在网络中通信的多个组件上。分布式组件可以包括一个或多个客户端和服务器机器，除了各种人机界面和通信设备(例如，显示监视器、智能电话、平板电脑、个人数字助理(PDA))之外，这些客户端和服务器机器还可以共享处理，如图17中所示。网络可以是专用网络(诸如LAN或WAN)，或者可以是公共网络(诸如互联网)。可以经由直接用户输入来接收系统的输入，以及实时地或者作为批处理来远程地接收系统的输入。此外，一些实施方式可以在与所描述的模块或硬件不同的模块或硬件上执行。因此，其它实施方式在可以要求保护的范围内。

在一些实施方式中，本文描述的可以与云计算环境1730接口，诸如Google CloudPlatform^TM，以执行上面详述的方法或算法的至少一部分。与本文描述的方法相关联的过程可以由数据中心1734在计算处理器(诸如的Google计算引擎)上执行。例如，数据中心1734还可以包括应用处理器，诸如Google App Engine，其可以用作与本文描述的系统的接口以接收数据并输出对应的信息。云计算环境1730还可以包括一个或多个数据库1738或其它数据存储装置(诸如云存储和查询数据库)。在一些实施方式中，云存储数据库1738(诸如Google云存储)可以存储由本文描述的系统提供的经处理的和未经处理的数据。例如，索赔数据112、索赔特征向量114、历史数据116、融合数据集118、漏洞数据120、漏洞度量121、经训练的数据模型122、经训练的变量/权重124、反馈数据126、处置者表现数据127、索赔评分数据128和客户产生数据129可以由图1的索赔监视系统108在诸如数据库1738之类的数据库结构中维护。

本文描述的系统可以通过安全网关1732与云计算环境1730通信。在一些实施方式中，安全网关1732包括数据库查询接口，诸如Google BigQuery平台。例如，数据查询接口可以支持索赔监视系统108访问存储在外部实体104和保险提供者102中的任何一个上的数据。

云计算环境1730可以包括用于资源管理的供应工具1740。供应工具1740可以连接到数据中心1734的计算设备以促进数据中心1734的计算资源的供应。供应工具1740可以经由安全网关1732或云控制器1736接收对计算资源的请求。供应工具1740可以促进到数据中心1734的特定计算设备的连接。

网络1702表示一个或多个网络(诸如互联网)，其将云环境1730连接到多个客户端设备(在一些示例中，诸如蜂窝电话1710、平板计算机1712、移动计算设备1714和台式计算设备1716)。网络1702还可以使用各种移动网络服务1720(诸如Wi-Fi、蓝牙、包括EDGE、3G、4G和5G无线蜂窝系统的蜂窝网络，或任何其它已知的无线形式的通信)经由无线网络进行通信。在一些示例中，无线网络服务1720可以包括中央处理器1722、服务器1724和数据库1726。在一些实施例中，网络1702对于本地接口和与客户端设备相关联的网络是不可知的，以允许本地接口和被配置为执行本文描述的过程的网络的集成。此外，诸如蜂窝电话1710、平板计算机1712和移动计算设备1714之类的外部设备可以经由基站1756、接入点1754和/或卫星1752与移动网络服务1720通信。

虽然已经描述了某些实施例，但是这些实施例仅通过示例的方式呈现并且不旨在限制本公开的范围。实际上，本文描述的新颖方法、装置和系统可以以多种其它形式实施；此外，在不脱离本公开的精神的情况下，可以对本文描述的方法、装置和系统的形式进行各种省略、替换和改变。所附权利要求及其等同物旨在覆盖落入本公开的范围和精神内的此类形式或修改。

Claims (20)

1.一种系统，包括：

处理电路；

非暂时性数据库存储区域；以及

耦合到所述处理电路的非暂时性计算机可读存储器，所述存储器存储机器可执行指令，其中所述机器可执行指令当在处理电路上执行时使处理电路：

基于预定的索赔监视频率，识别针对漏洞检测处理识别的多个保险索赔中的至少一个保险索赔，其中每个识别的索赔与多个保险提供者之一相关联，

对于识别的至少一个保险索赔中的每一个保险索赔，

从与相应的保险索赔相关联的数据文件中提取针对相应的保险索赔的漏洞检测特征，其中提取的漏洞检测特征提供对具有导致索赔泄漏的可能性的索赔处置缺陷的指示，

使用存储在非暂时性数据库存储区域中的漏洞检测数据模型，对在相应的保险索赔的提取的漏洞检测特征内的一个或多个索赔处置漏洞进行检测，

其中所述漏洞检测数据模型用向所述多个保险提供者中与相应的保险索赔相关联的相应的保险提供者定制的特征向量进行训练，

其中定制的特征向量包括针对与相应的保险提供者相关联的索赔的提取的漏洞检测特征的一部分，以及

其中检测到的一个或多个索赔处置漏洞中的每一个索赔处置漏洞包括相应的索赔处置漏洞导致索赔泄漏的可能性，以及

基于检测到的一个或多个索赔处置漏洞，计算指示索赔泄漏的总体可能性的相应的漏洞分数，以及

在用户的远程计算设备处的用户界面屏幕内呈现被指派给用户进行处置的多个索赔中的每一个索赔的漏洞分数，其中所述多个索赔的一部分包括至少一个索赔的一部分。

2.如权利要求1所述的系统，其中与所述至少一个索赔中的每一个索赔相关联的数据文件包括结构化数据文件和非结构化数据文件。

3.如权利要求2所述的系统，其中所述非结构化数据文件包括以下中的至少一个：关于与所述至少一个索赔的一方或多方进行的任何呼叫或交互的记载、收据、警察报告、医疗记录或汽车检查报告。

4.如权利要求2所述的系统，其中针对相应的保险索赔提取漏洞检测特征包括应用被训练为检测非结构化数据文件内的索赔漏洞特征的自然语言处理算法。

5.如权利要求1所述的系统，其中与所述至少一个索赔中的每一个索赔相关联的数据文件包括来自与针对相应的保险索赔的相应的保险提供者相关联的开放索赔和关闭索赔的数据文件。

6.如权利要求5所述的系统，其中所述机器可执行指令当在处理电路上执行时使处理电路：

从与相应的保险提供者相关联的数据文件中，生成针对相应的保险提供者的定制的特征向量，其中所述定制的特征向量包括表示所述开放索赔和关闭索赔的特性的条目。

7.如权利要求1所述的系统，其中所述机器可执行指令当在处理电路上执行时使处理电路：

使用针对相应的保险提供者的经训练的漏洞检测数据模型，识别用于检测所述一个或多个索赔处置漏洞的多个漏洞度量。

8.如权利要求7所述的系统，其中所述多个漏洞度量中的每一个漏洞度量与多个漏洞度量类别之一相关联，所述漏洞度量类别包括以下中的两个或更多个：索赔指派度量、联系度量、承保度量、调查度量、评估度量或诉讼管理度量。

9.如权利要求8所述的系统，其中所述联系度量类别包括以下中的至少一个：与相应的保险索赔的一方或多方的初始联系尝试、初始联系日期或后续联系日期。

10.如权利要求7所述的系统，其中检测所述一个或多个索赔处置漏洞包括：确定所述多个漏洞度量中的一个或多个漏洞度量针对相应的索赔不被满足。

11.如权利要求1所述的系统，其中针对相应的保险提供者的定制的特征向量包括与定制的特征向量中的多个特征的一部分相关联的目标变量，其中所述目标变量与来自所述多个特征的该部分的相应的索赔内的可检测漏洞相对应。

12.如权利要求11所述的系统，其中所述机器可执行指令当在处理电路上执行时使处理电路：

从提取的漏洞检测特征中确定未检测到针对所述多个特征中的该部分的目标变量，以及

经由将模式识别算法应用于提取的漏洞检测特征，来检测针对所述多个特征的该部分的目标变量。

13.如权利要求1所述的系统，其中所述机器可执行指令当在处理电路上执行时使处理电路：

基于检测到的索赔处置漏洞的数量和类型，调整针对检测到的漏洞来处理所述至少一个保险索赔的周期性。

14.如权利要求1所述的系统，其中所述机器可执行指令当在处理电路上执行时使处理电路：

在所述多个保险索赔内，检测一个或多个文档已被添加到所述多个保险索赔中的第一保险索赔中，以及

响应于检测到添加的一个或多个文档，发起针对检测到的漏洞对所述第一保险索赔的处理。

15.如权利要求1所述的系统，其中所述保险索赔是汽车保险索赔。

16.一种方法，包括：

由计算设备的处理电路训练针对多个保险提供者中的每一个保险提供者的漏洞检测数据模型，以检测对相应的保险提供者的索赔中的、具有导致索赔泄漏的可能性的索赔处置缺陷的指示，

其中针对相应的保险提供者的漏洞检测数据模型是用向相应的保险提供者定制的特征向量来训练的，并且其中经训练的漏洞检测模型被保存在数据存储区域中；

对于多个索赔中的每一个索赔，所述多个索赔中的每一个索赔与所述多个保险提供者中的每一个保险提供者相关联，

由处理电路从与相应的索赔相关联的数据文件中提取针对相应的索赔的漏洞检测特征，其中提取的漏洞检测特征提供对具有导致索赔泄露的可能性的索赔处置缺陷的指示；

由处理电路使用存储在数据存储区域中的相应的经训练的漏洞检测数据模型来检测在相应的索赔的提取的漏洞检测特征内的一个或多个索赔处置漏洞，

其中检测到的一个或多个索赔处置漏洞中的每一个索赔处置漏洞包括相应的索赔处置漏洞导致索赔泄漏的可能性；

由处理电路基于检测到的一个或多个索赔处置漏洞计算指示索赔泄漏的总体可能性的相应的漏洞分数；以及

由处理电路经由用户的远程计算设备处的用户界面屏幕输出与相应的保险提供者相关联的所述多个索赔中的至少一部分索赔的漏洞分数。

17.如权利要求16所述的方法，其中与相应的索赔相关联的数据文件包括结构化数据文件和非结构化数据文件。

18.如权利要求17所述的方法，其中针对相应的保险索赔提取漏洞检测特征包括应用被训练为检测非结构化数据文件内的索赔漏洞特征的自然语言处理算法。

19.如权利要求16所述的方法，其中与至少一个索赔中的每一个索赔相关联的数据文件包括来自与针对相应的保险索赔的相应的保险提供者相关联的开放索赔和关闭索赔的数据文件。

20.如权利要求19所述的方法，还包括：

从与相应的保险提供者相关联的数据文件中，生成针对相应的保险提供者的定制的特征向量，其中所述定制的特征向量包括表示所述开放索赔和关闭索赔的特性的条目。

Images