CN101925919A - 自动化索赔处理系统 - Google Patents

Abstract

本发明提供了一种基于计算机系统的自动化损失查证系统，用于估计在保险单或债务保护合同下提交的索赔的有效性。系统基于预测建模和多个潜在风险因素使用风险评估工具对索赔的相对风险进行预先评分，而不是要求索赔人联系保险公司或贷方以提交索赔并提供对要求索赔的损失的有效性的详尽文档证明。相关的自动化索赔查证工具使用该索赔评分以及与索赔有关的其他信息来分派有效损失的证明的相对置信度，以及分派第三方提供的源或可以被系统自动访问以验证索赔的证明源的组合，其中在能够通过自动化判定过程来批准索赔之前必须满足所述相对置信度。

Description

自动化索赔处理系统

相关申请的交叉引用

本申请要求于2007年11月28日提交的美国临时申请61/004,587的优先权，其全部公开一并在此作为参考。

技术领域

本申请总体涉及对投保方客户提交的保险单索赔的处理，更具体地，涉及用于由保险公司通过验证过程对这样的索赔自动进行处理的系统，所述验证过程依赖于针对索赔的可信性的、由第三方提供的数据。

背景技术

保险表示一种提供保护以在多种情况下免受经济损失的手段。例如，人寿保险帮助在作为雇佣劳动者的双亲死亡的情况下赔偿家庭的收入损失。健康保险帮助在雇佣劳动者或家庭成员生病的情况下支付医疗费用。火险在投保方的家或房屋被火灾损坏时支付全部或部分损失。汽车或海上保险帮助赔偿由于汽车或船事故导致的损坏的费用。

保险的工作原理是在人之间分担损失。希望上保险以免受特定类型损失的人同意向保险公司定期支付保险费，保险公司作为回报将提供称作“保险单”的合同。实质上，公司承诺针对保险单中标识的损失类型向投保方支付特定金额的钱。保险公司将使用保险费来购买股票、债券、抵押、政府证券以及其他产生收入的投资，以产生额外的钱，从而使用这些钱以及从所有投保方收集的保险费来支付在保险单下欠下的所有集合的收益或索赔。

保险起作用，因为投保方希望用保险费支付形式的少量特定损失来换取以下契约保证：在发生较大但是不可预测的损失的情况下将赔偿(即，支付)投保方。即使投保方在保险单下没有从保险公司得到任何给付，但保险费也没有被浪费，因为保险单为投保方提供了安全的感觉。因此，投保方可以拥有财产、开车、做生意以及参与许多其他活动甚至可能有风险的活动，而不用担心可能发生的经济损失。

典型地，许多雇主向他们的雇员提供的重要福利是伤残保险。这种伤残保险采取“赞助保险”或“团体保险”的形式，并且使基础保险公司在员工伤残从而不能工作或比正常情况工作时间短时为员工支付其收入损失的一部分。伤残将典型地构成对员工的限制使员工由于疾病或受伤而不能执行其常规职业的具体的和实质的职责，并且构成了由于同样的疾病或受伤而导致的月收入的最低损失。如果员工在通过培训、教育和/或经验而适合的任何有报酬的职业的工作中受伤的情况下，则团体伤残保险单还可以在启动给付期之后，向该员工赔偿来自于该员工的常规职业的收入损失。保险单可以赔偿在短的初始时间范围的员工伤残(“短期伤残”)，或者在员工的伤残持续了指定的“排除期”(如，90天)之后更长的时间范围的员工伤残(“长期伤残”)。一旦排除期过去并且员工仍然伤残，该员工就会得到支付，所述支付总共是伤残开始之前月收入的百分比(例如，60％)直到伤残持续时间的覆盖的金额。然而，伤残保险单还可以覆盖给付的持续时间，以进一步减小投保人的风险。

除了人寿保险、火险保险和伤残保险之外，客户要求的其他形式的风险保护范围包括失业保险和“债务保护”。失业保险单在非自愿失业的情况下对个人或其受益人进行支付。简言之，债务保护类似于信用人寿保险、伤残保险和非自愿失业保险，但不是保险单形式的，债务保护是对贷款协议的修改，从而对于费用，贷方可以在借方死亡、伤残或非故意失业的情况下推迟或取消全部或部分债务。还存在休假保险承保范围，其中，如果借方因为生小孩而不得不请假离开，则债务将被推迟或部分取消。

保险公司和贷方通常准备并且希望在他们的保险或保护计划合同所覆盖的情况下为投保方及其受益人提供由保险单或者条款及计划的条件指定的给付。然而，在兑现这样的承诺之前，承保人和贷方等必须验证投保方或受益人所报告的事件的情况是真实发生的并且符合保险单或合同的条款。这是因为基于概率的原理以及投保方的实际经历，保险公司或贷方针对保险单或合同收取的保险费是在开始确定的，以反映发生受保事件的风险。将可能的收益金额与在保险覆盖的限制内将向可能死亡、变得伤残、变得非自愿失业等的投保方支付可能的金额进行组合，保险公司或贷方可以将保险单定价为：覆盖这种损失，覆盖保险公司运行业务的成本，并为股东(或与保险公司共有的投保方)提供合理的利润。然而，如果在欺诈或错误的保险单承保范围内进行了支付，则这种保险计划的偿付能力将会有风险，随后需要向客户收取更高的保险费率。

因此，承保人和贷方等开发了用于对投保方提交的索赔进行验证的过程。这种行业损失验证过程典型地包括用于确定事件的性质以及用于验证事件的真实发生的若干数据采集步骤。保险单提供方典型地要求索赔人拨打一个电话，提供接收索赔表格的邮寄信息。然后索赔人必须回答索赔表格内提出的各种问题。保险单提供方还要求索赔人提供证据证明受保事件是实际发生的。例如，在人寿保险单下的死亡事件中，可能需要索赔人提供死亡证明书或验尸报告的副本。在伤残事件中，可能需要索赔人提供医生填写的表格，说明受保人伤残或无法工作。对于失业，可能要求受保人提供证据，证明其向其所在州的失业救济办公室提交了失业救济请求。

典型地对所有客户都有提交受保事件的证明的这些需求，而不考虑欺骗或客户错误的实际风险。保险公司或贷方仅仅想要证明所有索赔人对于他们索赔的所有给付都是合格的。当然，这种验证过程在决定是否对索赔人支付之前需要大量的书面工作，并且需要保险公司雇员继续调查。从管理角度来讲也是成本高的，从而增加了健康护理和保险费用，所述健康护理和保险费用已经由于上涨的医疗和药物成本而承受不断上涨的压力。尽管保险公司努力在批准后的10天之内支付索赔，然而索赔调查和验证过程花费30天的时间并不少见。假定索赔人已经在报告索赔的损失事件之后等待了30-60天，则索赔人的理解是保险公司要用70-100天的时间来进行支付，这实在是非常长的时间。此外，当受益人正对失去死亡的投保人感到伤心时保险公司提出许多证据证明要求则显得没有感情且没有必要。

在保险行业中已经做出了许多努力以使审阅和判定来自保险受益人或代表被保险受益人的支付请求的这种管理过程合理化。例如，在健康护理行业中，健康护理提供方将请求病人的保险公司支付为病人提供的医疗服务和供给。保险公司对这些支付请求的管理变得越来越自动化，从而健康护理提供方的办公室的技术员以电子的形式创建医疗保险索赔并将该医疗保险索赔提交给中央处理系统。标识医生、病人、医疗服务、承保人等的信息典型地将作为医疗保险索赔的一部分包含在内。中央处理系统然后查证医生、病人和承保人实际上是索赔处理系统中的参与者。在该自动化查证步骤之后，中央处理系统将医疗保险索赔转换成针对具体保险公司的适当格式，并将该索赔转发至承保人。当保险公司雇员人工判定并批准保险索赔时，承保人将向健康护理提供方银行账户电子地转移资金。参见例如由Drennan提交的美国公开申请2003/0187695。

然而，在从中央处理系统接收到医疗保险请求之后，承保人仍然需要花费大量的时间和金钱来审阅和批准医疗保险请求。由于人工审阅和判定成本高，作为选择，承保人可以简单地进行少量地审阅或不审阅的情况下支付大量的索赔，但是这种选项不是最优的，因为这种做法会使承保人深受欺骗或索赔错误之害。

Bealke等提交的美国公开申请2005/0075912公开了一种电子保险索赔解决系统，该系统使当事人(即，承保人和索赔人)可以以电子的形式访问索赔过程，使得他们可以监控该过程。可以在批准了索赔时立即将款项按期支付给索赔人，但是同样地，得到这种批准决定的这种审阅过程实际上是人工的。授权给Peterson等的美国专利No.6,343,271提供了一种电子系统，该电子系统在健康护理提供方提交索赔之前“预先判定”该索赔，健康护理提供方指示承保人进行人工审阅该索赔还是立刻支付该索赔。以这种方式，健康护理提供方可以定制器医疗保险索赔，以提高该健康护理提供方得到承保人立刻支付的可能性，从而加速了款项的接收。还参见Peterson等提交的美国公开申请2002/0019754。

在保险行业中已知用于部分地使索赔审阅过程的某一方面自动化的其他电子系统。例如，Sohr等提交的美国公开申请2007/0050219提出了一种系统，该系统用于将保险索赔跟保险人的之前得到支付的索赔核对以防止重复索赔。Tholl等提交的美国专利申请2006/0149784提出了一种系统，该系统用于在人工判定之前预先检查保险索赔以确定该保险索赔是否声明了在相关保险单承保范围内的索赔。同时，Rowe III等提交的美国公开申请2004/0078247公开了一种电子索赔处理系统，该电子索赔处理系统在人工判定之前预先检查索赔的完整性和一致性。系统可以将任何不完整或实质上不一致的索赔返回给索赔人修改，以节省人工索赔判定员的时间，并减少被拒绝的索赔的数目。还参见Hoffner等提交的美国公开申请2007/0038484。

存在用于帮助保险公司提高承保人-索赔人之间关系的效率的其他电子系统。例如，Kennedy等提交的美国专利申请2007/0005402提出了一种系统，该系统被医生用来确定是承保人还是病人会支付医疗保险单项目下的账单。医生可以使用该信息来适当地提交发票并在可能情况下从病人的医疗储蓄账户实时地得到支付。然而，仍然由承保人来判定索赔。因此，保险公司实现了用于辅助这种判定步骤的技术方案。

Gandee等提交的美国公开申请2005/0038682公开了一种双向音频/视频通信系统，这种双向音频/视频通信系统使得保险公司可以远程检查索赔的意外损失而不需要派遣理算师对人执行检查。Freedam等提交的美国公开申请2002/0002475提供了一种系统，该系统被汽车保险公司用来捕获理算师所需的索赔信息和视频图像，以便侦查欺骗性索赔。Crain提交的美国公开申请2004/0013729公开了一种类似的系统，该系统被邮局用来判定针对受损包裹的索赔。Cadigan等提交的美国公开申请2004/0093242提出了一种电子系统，该电子系统执行与保险索赔处理有关的多个功能，包括对理算师判定索赔所需的数据进行跟踪的模块。

然而，所有这样的现有系统都需要对保险索赔的人工判定，并且仅捕获和管理对于提高人工判定过程的效率所需的信息。授权给Menendez的美国专利No.7,203,654通过提供一种电子系统来尝试更进一步，该电子系统将索赔与关键字搜索、索赔历史数据以及索赔的数额进行比较，以确定这些索赔的哪个子集有欺骗或错误的风险更大，从而特别地批准人工仔细检查和判定。承保人自动支付其他索赔而不用仔细检查和判定。还参见Menendez提交的美国公开申请2007/0150319。

实际情况是，并非所有索赔者都向保险公司做相同暴露水平的错误和欺骗活动。因此不是所有索赔人都逻辑上需要相同水平的查证。特殊案子的情况可能指示与索赔有关的欺骗或错误的相对更高或更低风险。例如，针对支付保险费达20年以上、在报告死亡时已经80岁并且总潜在给付总数为$500的投保方的死亡在人寿保险单下提交的损失索赔，与针对支付保险费仅一个月、在报告死亡时25岁、而潜在给付总数为$100,000的投保方的死亡的索赔，并不表示同样的风险水平。80岁死亡的可能性比25岁更高。在考虑其他因素时，索赔人针对$500的给付支付实行欺骗的可能性比针对$100,000的给付实行欺骗的可能性更低。此外，客户关系的长期性影响欺骗的可能性。

在一组索赔人中，有这样的一部分索赔人，一旦这部分索赔人经过了在行业中用来验证索赔的过程中的全系列判定步骤，则这部分索赔人的索赔应当并且将被批准。同时，一旦其余索赔人经过传统的验证过程，这些其余索赔人的索赔应当并且将被拒绝。不幸地，很难提前预测其索赔应当被批准的那部分索赔人。Menendez的“全或无”判定系统较不吸引承保人，因为在“完全判定”和“不判定”之间没有中间地带。另外，统计概率建议，即使可能是对于更少的美金金额，某一部分未经判定的索赔也会具有欺骗性。因此，保险公司和贷方试图强制所有索赔人忍受与逻辑上仅应当对很少索赔人应用的严格仔细检查水平。同时，保险公司和贷方承受与这种严格的索赔调查过程有关的高额费用，这对保险费施加了上涨的压力。

因此，提供一种合理化的索赔处理系统，该索赔处理系统基于某一水平的仔细检查和判定使索赔人可以与保险公司或贷方联系、提供损失信息、并从保险公司或贷方接收与索赔人的索赔的支付有关的答复和即刻决定，这对于保险公司和银行以及索赔人等都是非常有利的。理想地，这种系统应当放弃受保事件的索赔人提供的所需的文档证明(至少除了高风险索赔人以外)，而是依赖于审阅和判定过程，所述审阅和判定过程实际上基于可访问的第三方数据源提供的证明。

发明内容

本发明提供了一种基于计算机系统的自动化损失查证系统，用于估计在保险单或债务保护合同下提交的索赔的有效性。系统基于预测建模和多个潜在风险因素(包括但不限于，索赔的金额、损失的性质和概率、索赔人关于保险单或合同的历史、以及保险公司或贷方关于其他类似索赔的历史)使用风险评估工具对索赔的相对风险进行预先评分，而不是要求向保险公司或贷方提交索赔的索赔人提供对要求索赔的损失的有效性的详尽文档证明。相关的自动化索赔查证工具使用该索赔评分以及与索赔有关的其他相关信息来分派有效损失的证明的相对置信度，在通过自动化判定过程能够查证损失之前必须满足所述分派的相对置信度。系统还分派可由系统自动访问的第三方提供的证明源或证明源的组合，以验证索赔。一旦得到了克服索赔有欺骗性或错误的风险所需的证明，就批准索赔，从而无需索赔人作出其他努力来提供文档证据。以这种方式，本发明的自动化损失查证系统可以按照保险业标准——在两个营业日内，优选地，在索赔人通过电话、互联网网站或互动语音应答门户(IVR portal)激活索赔的两个小时之内，更优选地，在索赔人激活索赔同时，非常快速估计并批准索赔，而不需要索赔人独立获得和提供要求索赔的损失的文档证明。这样的系统提高了保险公司或贷方的索赔判定过程的效率，同时改善了索赔人的索赔体验。

附图说明

附图中：

图1是本发明的自动化索赔处理系统的周围环境的示意图。

图2是自动化索赔处理系统的计算机实施例的示意图。

图3是示出了自动化索赔处理系统的流程图。

图4是自动化索赔处理系统的风险评估工具和自动化损失查证工具部分的硬件组件的示意图。

图5是对人寿保险单应用自动化损失查证系统的的图示。

图6是对非自愿失业保险单应用自动化损失查证系统的图示。

图7是对伤残保险单应用自动化损失查证系统的图示。

图8-10示出了自动化索赔处理系统的流程图。

图11-12是自动化损失查证系统的风险评估处理部分的示意图。

图13-25是描述了自动化损失查证系统的管理控制台部分的不同功能的屏幕截图。

图26是本发明的控制测试环境模块的示意图。

具体实施方式

本发明提供了一种自动化系统和方法，该自动化系统和方法以合理化的形式处理在受益承保范围合同下的索赔，其中向索赔人即刻通知支付或给付决定并且索赔人需要提供最少的证据证明。本发明采取自动化索赔处理系统的形式，所述自动化索赔处理系统用于从索赔人接收限定索赔的性质所需的信息，并基于查证以及受益承保范围合同内阐述的规则，将是否会支付索赔或提供其他给付的最终决定通知给索赔人。索赔处理系统然后基于索赔人提供的与受保事件有关的信息来设立索赔的详细摘要。然后应用风险评估工具对索赔人和索赔进行评分以限定欺骗性或错误索赔的风险。然后系统应用自动化损失查证工具，以基于索赔的性质以及在可以进行索赔的判定之前必须考虑的一个或多个独立数据验证源，来分派批准支付或其他给付所需的相关置信度。这种单个的独立数据源或独立数据源的组合可以建立验证索赔的基础，从而得到由系统作出的肯定支付或其他给付批准决定，而不需要索赔人和受益承保范围合同承保人公司成员进行人工查证。

在本发明的上下文中，“受益承保范围合同”指的是个人由于合同上受保事件(如死亡、伤残、火灾或失业)的发生而接受支付或其他给付的合同权利。这种受益承保范围合同包括而不限于保险单或债务保护产品。

出于本发明的目的，“保险单”指的是法人或相互保险公司为了向个人或群体提供保护以避免由于发生受保事件(包括但不限于死亡、伤残、疾病或受伤、火灾、或不动产或个人财产的损害)而带来的经济损失。因此，保险包括而不限于短期或长期伤残保险、健康保险、大病保险、牙齿保险、定期人寿保险、终身人寿保险、综合性或变额人寿保险、养老金、火险、住宅所有者保险、龙卷风或飓风保险、洪水保险、汽车保险、海上保险、以及其他形式的财产和伤亡保险。

出于本发明的目的，“债务保护产品”指的是在借方与向借方延长信贷的金融机构之间的合同约定，其中，从而作为对费用回报，金融机构同意在借方遭遇诸如死亡、伤残、或失业等可能使借方难以履行其责任从而偿还贷款的生活事件时，暂停关于信贷交易的每个月需要的本金偿还或支付利息或者甚至免除全部或部分本金偿还责任。

出于本发明的目的，“金融机构”指的是在针对零售货物/服务交易向客户提供必要的资金使得该客户不需要为该交易支付现金的商业中任何商业的、非赢利的、政府或其他实体。这种金融机构的示例包括而不限于银行、储蓄与贷款机构、信用合作社、以及零售商的信贷分支机构。

如本申请中所使用的，“伤残”指的是：个人由于疾病或受伤而在执行其常规职业的具体的和实质职务方面的限制，这种限制使得由于这种疾病或受伤而产生损失，该损失占这个人月收入的最小的预定的百分比。

出于本发明的目的，“保险人”是保险公司、金融机构中的人或第三方管理员，“保险人”必须确定各种受益承保范围合同的保险费率以及保险公司或金融机构针对每个这样的保险单而假定的风险数额和程度。

如在本申请中使用的，“受益人”是在受益承保范围合同中指定的接收在该合同下应支付的任何支付或其他给付的人。受益人可以是以例如人寿保险、补充伤残保险、住宅所有者保险、或汽车保险的形式购买保险或债务保护承保范围的个人投保方或合同持有者；或者受益人可以是以例如伤残保险、健康保险、牙齿保险或人寿保险的形式受雇主投保方的团体保险单承保范围保护的团体。

在本发明中，“索赔人”指的是提交保险或债务保护产品以要求保险公司进行支付或要求金融机构修改贷款条款的人。在大多数情况下，索赔人是在受益承保范围合同下的受益人。

图1示出了本发明的自动化索赔处理系统10。保险公司或金融机构14操作客户通信中心12以相对于索赔人在保险单下提交的索赔与索赔受益人16交互。客户通信中心12具有用于与索赔人16交互的接口18，索赔人16可以包括可通过电话、传真或电子邮件来通信的索赔代理。备选地，该接口18可以使受益人能够通过经由互联网网站或IVR响应系统的自我服务来发起或继续索赔。不管是谁发起的索赔，索赔处理系统100都以相同的方式工作。

参考图2的示例实施例，自动化索赔处理系统10包括通用的可编程计算机22，所述通用的可编程计算机22具有中央处理单元(“CPU”)24，所述中央处理单元(“CPU”)24控制存储器单元26、存储单元28、输入/输出(“I/O”)控制单元30、以及至少一个监视器32。计算机22连接至数据库40，数据库40包括例如受益承保范围合同的记录、索赔人数据以及索赔数据。计算机22还连接至以下将更详细描述的风险评估工具36和自动化损失查证工具38。计算机22还可以包括时钟电路、数据接口、网络控制器以及内部总线。本领域技术人员将认识到，诸如打印机、驱动、键盘、鼠标等其他外围组件也可以与可编程计算机22相结合使用。此外，本领域技术人员将认识到，可编程计算机22可以使用各种计算机组件的已知硬件、软件等配置，以使包含在自动化索赔处理系统10中的数据和其他信息的存储和操作最优化。

软件程序34可以被设计为以编码语言形式组织的指令集合的表示。这些指令被编程为便于索赔信息的引入、与索赔相关联的风险的评估、或对抗欺骗或错误的索赔验证。

系统所在的计算机系统可以是标准PC、膝上型计算机、主机、手持无线设备、或能够运行软件以监控可转移材料的进展的任何自动化数据处理设备。CPU控制计算机系统，并且能够运行存储在存储器中的数据。例如，存储器可以包括：诸如RAM和/或ROM之类的内部存储器，诸如CD-ROM、DVD、闪存驱动之类的外部存储器，或任何现有或未来数据存储装置。时钟电路可以包括能够产生指示当前时间和/或日期的信息的任何类型的电路。时钟电路还可以被编程为倒计时预定的或设置的时间量。

数据接口使得可以在一个或多个网络之间通信，所述一个或多个网络可以是LAN(局域网)、WAN(广域网)或链接操纵索赔的每一方的任何类型的网络。例如膝上型计算机或无线设备之类的不同计算机系统典型地使用不同的协议(即，不同的语言)。为了使得不同的设备通信，数据接口可以包括数据转换程序或设备或与数据转换程序或设备交互，以交换数据。数据接口还可以使得不同的设备可以通过公共交换电话网(PSTN)、互联网或专用或半专用网络来进行通信。参考图2，自动化索赔处理系统10包括软件程序34，所述软件程序34具有多个图形用户界面(“GUI”)，所述图形用户界面(“GUI”)以文本或图形的形式被显示给用户，以允许输入与受益承保范围合同持有者、受益承保范围合同损失事件、以及作为索赔基础的其他因素有关的数据。GUI还可以用于向保险公司、金融机构个人以及索赔人客户显示索赔的状态。

软件程序34还可以产生并打印记载了该信息的一系列报告。最终，软件程序34将保险公司或金融机构的索赔决定通知给索赔人。

图3-4中更详细地示出了本发明的自动化索赔处理系统10。在“起始阶段”50，索赔人16可以通过经由由自动化索赔处理系统10的操作者来维护的外部网站52或IVR电话输入站点54，或通过操作者的电话索赔代理呼叫中心56，来提交新的索赔或检验现有索赔的状态。一旦在接口18处，系统10提示索赔人16在以下操作之间进行选择：提交新的索赔/激活、请求继续给付、或检验现有索赔/激活的状态。

然后系统10将继续进行，向受益承保范围合同的索赔人16请求关键数据。用于识别索赔人的该关键数据包括以下项目中的一项或多项：索赔人的姓和邮政编码、受益承保范围合同的账号、索赔人的出生日期、以及激活/索赔号。系统10可以基于产品类型(即，保险单或债务保护合同)、产品、索赔人或它们的组合来预先选择这些数据元素。不完整的数据会阻止索赔人继续与系统10进行操作。

基于这种从索赔人16输入的数据，索赔处理系统10确定该数据是否具有与所输入的信息相匹配的保险公司或金融机构记录。该数据必须与保险公司或金融机构出于安全目的而维护的记录信息精确匹配。系统10可以提示索赔人16提供保险单或债务保护合同记录的口令作为附加的安全预防措施。

然后系统10继续进行到“权利阶段”60。在该阶段，系统10得到被提供至给付系统64的索赔人输入的数据62，并自动将该数据62与存储在系统数据库中的登记数据66和登记规则68相比较，以确定覆盖所提交的损失事件的受益人的可应用的保险单或债务保护合同是否在索赔的损失日期之前存在。在该权利阶段60，从索赔人收集附加的数据元素以发起“设立阶段”70。在该权利阶段60，索赔人16还可以通过输入该索赔人的索赔/激活号来检验该索赔人在其保险单下继续给付的权利。系统将基于其存储的对保险单的条款加以描述的权利规则68来提供回答。

接下来，自动化索赔处理系统10在“设立阶段”70期间创建索赔记录，所述索赔记录限定了受益承保范围合同以及对构成索赔基础的损失事件加以描述的相关信息。如本文所描述的，系统将在后续的“风险评估阶段”80和“自动化损失查证阶段”90期间估计该记录，以自动判定索赔。

对于新的索赔，如果没有找到承保范围，则系统10请求索赔人16审阅所输入的信息并重新提交该信息。在第二次不成功的尝试之后，向索赔人提出与保险单或合同以及承保范围的类型有关的问题。基于所输入的信息，根据用于通过接口18与系统接口连接的介质(web、IVR、电话等)，将如下作出响应：

●web：系统为索赔人提供用于进一步援助的索赔免费电话号码。该免费电话号码绕过IVR直接到达专业的索赔专员。

●IVR：系统将索赔人转移到专业的索赔专员。

●电话：索赔专员尝试识别索赔人承保范围，请求附加信息。

●邮件/传真：索赔专员尝试识别索赔人承保范围。如果未成功，表格及信和进一步的指示返回到索赔人。

如果找到承保范围，则系统向索赔人请求损失日期并显示覆盖承保日期的所有选项。索赔人选择损失类型并继续进行至设立阶段70。

如果系统找到符合损失类型和损失日期的若干承保范围记录，则提示索赔人选择他想要激活/要求索赔的权益。一旦索赔人进行了选择，权利阶段60结束并且设立阶段70开始。在该设立阶段，系统收集建立索赔/激活记录所需的所有信息并且对这些信息进行查证。

如果找到若干承保范围记录，但是没有记录符合损失日期和/或损失类型，则向客户通知该客户确实具有的承保范围并附上简要的客户友好条款和条件。

如果找到承保范围但是索赔人由于等待期或其他需要而无权得到给付，则将这种情况通知给索赔人并提示索赔人保存输入的信息。为了保存信息，索赔人必须输入电子邮件或街道地址。系统保存信息并(基于在权利阶段输入的信息)在满足等待期需要时向索赔人发送电子邮件/寄信。为索赔人给出起始号，所述起始号使索赔人可以在满足需要的情况下访问所输入的信息。

在满足需要之后应当在系统10中维持该信息达到90天。如果在90天之后索赔人还没有联系索赔中心12，则向索赔人发送最终通知，并在120天时删除该信息。

一旦索赔人输入了他的已有索赔/激活号，系统10就显示索赔的状态。然后索赔人查证信息并继续进行至本发明的自动化索赔处理系统的“风险评估”阶段80。

在设立阶段70，在进行至风险评估阶段80、“自动化损失查证”阶段90和“判定”阶段100之前，系统10收集并查证建立索赔激活记录所需的所有信息。索赔人查证信息，如，索赔人/被保险人的姓名、地址、电话号码、电子邮件地址、所选的损失类型、以及在权利阶段60输入的损失日期。在该阶段，提示索赔人选择通信类型以供系统用来发送与提交的索赔的支付有关的判定决定。默认的通信类型是电子邮件，但是其他选项包括邮件和口头通知。

如果通信类型的这种选择是通过IVR链接来实现的，则系统保存选择日志并将该选择日志附到客户记录中。如果通信类型的这种选择通过与索赔专员通电话来实现的，则专员对授权进行录音。为所录制的授权给出确认号，所述确认号附到索赔人记录中以便将来可以检索该确认号。

通信类型“仅口头”意味着索赔人接受口头通知并且由于电话呼叫而关闭任何web或纸张通信。如果索赔人经过电话与索赔专员联络，则仅显示该选项。当选择该选项时，索赔人向索赔专员给出授权以便不发送“书面”确认。如果选择这种通信类型，则非电话交易(例如，Web/IVR)需要附加一个通信类型。

索赔人通过按设立确认按钮来交付所设立的索赔。此时，系统10显示与发起索赔有关的任何限制。例如包括：

●信用卡使用限制(索赔人在激活期间不能使用信用卡)。

●激活之间的等待期(一旦索赔被批准，则在从上一次支付之后到当前索赔日期经过了30天之前，索赔人不能提交另一索赔)

索赔人有机会取消选择他不想继续进行的任何承保范围记录。系统10根据所选记录和未选记录的这种交易来保存记录。

索赔人提交并且系统10提供弹出屏幕，所述弹出屏幕询问索赔人“是否确定设立针对所选承保范围记录的索赔记录”，如果索赔人选择“否”，则进程终止并且存储交易记录。如果索赔人选择“是”，则为索赔人给出设立安全等级的机会。

基于索赔人设立(不是所有索赔人都可以选择使用该选项)，为索赔人给出设立安全询问/口令的机会。将存储该口令，并且任何人都需要该口令来获得针对该索赔人账户的信息。

图4所示的索赔处理系统10包括用于执行基础进程的风险评估阶段80的风险评估处理模块82。与风险评估处理模块82相关联的是用于对欺骗性或谎报利益承保范围索赔的相对风险进行预测的模型84。系统使用在系统数据库中存储的商业规则集合来激活使用该模型的风险评估处理模块82。与风险评估处理模块82相关联的还有风险评分表86，所示风险评分表86响应于风险评估处理模块82的风险预测输出为利益承保范围合同索赔分派数字风险评估评分。审计日志88存储与所讨论的索赔相类似的先前利益承保范围合同索赔的实际风险结果。使用该信息，系统10的操作者可以修改风险评估处理模块82以使其尽可能精确。

在风险评估阶段80，将在起始阶段、权利阶段和设立阶段输入的信息与诸如账户结余、客户信用评分、年龄等相结合，以评估索赔具有欺骗性的相对风险并分派风险评分。索赔处理系统10的风险评估阶段80使用基于先进的预测建模技术的工具来使得保险公司可以评估与索赔相关联的相对风险。

统计建模使用所有被保险人的数据属性来开发自动风险评估工具(“RAT”)36(参见图3)，以评估与特殊索赔相关联的风险。效果好的模型(图4)考虑多个变量中的所有可能趋势，以评估索赔并对与索赔相关联的潜在风险进行建模。

表1阐述了与保险索赔相关联的不同风险因素的示例。

表1：

RAT 36模型周期性地(例如，每天、每周、或每个月)对整个保险人进行预评分。每个保险人在产品/承保范围级别具有多个预评分。将预评分存储在由系统10维持的oracl数据仓库中。

当特定保险索赔到来时，将在起始阶段、权利阶段和设立阶段50、60和70输入的信息与预评分过程中使用的信息相结合，以实时地对每个独立索赔进行预评分。注意，相比之下，要求继续给付的请求经过仅针对继续索赔而定制的不同RAT模型。

在这种情况下，按照风险曲线从高到底排列索赔人。然后按风险类别对这些索赔人进行分组。使用这些类别，保险人和贷方可以确定应当向具体索赔应用验证步骤的程度来作为判定过程的一部分。判决要使用什么源也是由模型来驱使的，其中使用各种统计建模技术来确定每个数据源的置信度。例如，在先前讨论的死亡索赔说明中，这两个索赔可能接受与索赔相关联的高或低风险。在涉及80岁保险人的死亡情况下，模型可以将风险描绘为低。在$100,000索赔的情况下，模型可以将索赔分类为高。响应于这些类别，保险公司可以利用提供较低置信度的验证技术在进程早期判决批准较低风险的索赔。此外，保险公司可以选择仅在接收到提供较高置信度的针对损失验证的更多信息之后批准较高风险的索赔。例如，在第一种情况下，保险公司可以接受讣告作为用于批准的死亡证明。在第二种情况下，保险公司可以向州请求死亡证明书作为批准索赔的证明。

优选地，RAT 36包括查找表，所述查找表可以由系统10下的计算机22来使用，或者由人工进行索赔验证处理的利益承保范围合同公司雇员来使用。这样的查找表可以采取表2的形式，在表2中，将索赔的相对风险等级转换为适当的置信度(即，证明)，在给定与索赔相关联的风险水平的情况下，保险公司或金融机构需要该置信度来批准索赔。

表2

风险等级                置信度

                              

0(非常低)               0％

1(低)                   40％

2                       60％

3                       80％

4(高)                   100％

因此，评分“4”确定交易是高风险的，并且可能需要：在授权支付或延期之前，以全文档形式，经由已被确定为提供100％置信度的数据源或结合集体提供100％置信度的源来验证。相比之下，低评分“1”可以产生更少的文档需求。非常低评分“0”可以提示不需要通过数据源验证来批准。

对于本发明的自动化索赔处理系统10来说，重要的是相对于索赔人提交的索赔有效性的实际结果，周期性地检查在RAT工具36下的先进的预测模型和相关的模型82。因此，利用提交索赔的索赔人的随机提交的样本89来控制、监控和验证数据源。通过针对每n个客户进行选择来产生随机提交的样本89。在需要系统10工作在最大置信度的情况下，RAT工具36对提交的样本89进行评分，一个或多个自动化损失查证(“ALV”)数据源(优选地，所有可用数据源)对提交的样本89进行查证。系统将每个数据源查证结果与索赔人提供的损失查证结果相比较，以便确定ALV系统模型正在正确地工作。对特定趋势(如，从不提供损失查证(自我否定)的客户)进行分析，然后基于该分析来确定是否需要对数据源作出任何改变(例如，调节置信度)。

保险公司或金融机构可能不需要对具有非常低风险等级(例如，风险等级“0”)的索赔进行验证，因为这种索赔显然是有效的或索赔金额太低以至于不能确保验证过程的成本。在这种情况下，索赔处理系统10将被构造为将该索赔直接发送至判定阶段100(参见图3)以向索赔人通知针对支付的肯定判决。

在管理控制台中维持针对RAT模型的参数和表驱动值。该管理控制台允许对数据元素、系数、数据源和置信度的评分作改变和调整。使用管理控制台在受控环境内进行对假设的测试。在管理控制台允许其有测试推测的能力。以公共商业语言进行报告，从而用户可以基于测试来进行判决。

如果在风险评估阶段80查找表已经指示所要求的置信度的测量已高于0％，则系统将进行至自动损失查证阶段90。自动损失查证或“ALV”是表驱动工具38，所述表驱动工具38根据损失类型连接至不同数据源。ALV工具的工作是通过基于风险评分和产品、产品类型、客户和/或状态(其任意组合)分派置信度需求来使查证过程自动化。然后，基于针对索赔而指定的置信度需求，单独的查找表基于该风险评分识别验证索赔所需的独立的数据源或独立数据源的组合。表3示出了这种查找表。

表3

针对索赔批准的所需置信度	独立数据源组合
		0％	无
40％	A
		60％	A，B
80％	A，B，C
		100％	A，B，C，D

备选地，存储在软件34中的算法或基本逻辑可以指定系统所使用的数据源的顺序。然后系统10将自动查阅这些指定的独立数据源中的每个数据源，以便查证要求索赔的损失。

表4示出了可用于验证索赔的独立第三方源的示例列表以及属于每个源的相对置信度。

表4

根据损失类型，ALV表、算法或基本逻辑驱动工具38连接至不同数据源。ALV工具的工作是通过基于风险评分和保险产品、产品类型、客户和/或状态、或其任意组合向索赔分派置信度需求，来使查证过程自动化。ALV工具能够从不同的数据源中检索信息并基于从每个数据源得到的信息来累积点/置信度。基于索赔的置信度需求，询问对于达到置信度来说必要的每个数据源，以自动查证损失。一些数据源基于可以从这些数据源得到的查证的类型而具有不同的置信度。例如，在SSDI的情况下，P的死亡确认可以产生置信度100％，而V的死亡确认仅可以产生50％评分。每个数据源尝试一种或多种损失类型，并且可以当在ALV级处的设立时根据产品类型、产品、客户、状态、损失类型和/或任意组合而具有不同的置信度评分。

在本发明的自动化查证工具的优选实施例中，系统分派所需的目标置信度(“TCL”)以验证具体利益承保范围合同索赔，该索赔与针对索赔而分派的风险评分相对应。注意，仅由于授权保险单或债务保护合同的保险公司或金融机构可以根据索赔经历和保险业保险单来设置风险评分，所以保险公司或金融机构可以基于其接受的风险程度来选择其自己所需的TCL。一个保险公司或金融机构可以针对潜在欺骗性或错误索赔而接受较高的风险程度，从而需要较低的TCL在该自动化损失查证工具下验证索赔。该较低的TCL值将使该保险公司或金融机构可以使用本发明的自动化查证工具来减小与索赔验证过程相关联的管理成本。相比之下，另一保险公司或金融机构可能由于其降低了可接受的风险水平而需要较高的TCL值以便验证索赔。这将导致使用自动化损失查证工具来验证索赔所用的证实数据源参考的更大组合。

每个证实数据源已经分派了有与其相对置信度成比例的贡献验证评分，以建立索赔的真实性。例如，与人寿保险承保人的死亡有关的客户提供信息可能仅以40％置信度为特征，而报纸讣告可能提供60％置信度。报纸是独立源，对于真实性在逻辑上比索赔人自身更可信。然而，已知报纸作者会出错。另一方面，由于被社会保障署用来在开始给付之前查证死亡的文档查证过程，社会保障死亡索引中死者的列表可能具有80％置信度评分。最后，地方政府所发出的经过证实的死亡证明书将建立100％置信度的死亡事实。

注意，保险公司或金融机构可以确定其自己的置信度评分，该保险公司或金融机构根据其自己的索赔验证经历和风险承受概况将该置信度评分分派给每个证实数据源。

本发明的系统执行以下重复计算以便使用可用的证实数据源来验证索赔：

累积查证值(“AVV”)＝∑针对索赔而检验的数据源的值

其余查证值(“RVV”)＝索赔所需的(TCL-AVV)

可能查证值(“PVV”)＝∑针对索赔的未检验的可用数据源的值

最大查证值(“MVV”)＝∑在自动化损失查证过程的开始处针对索赔的所有可用数据源的值

运行可能查证值(“RPVV”)＝∑针对每个通路的所有PVV(命中(hit)或未命中)：RPVV＝PVV

如果超过了针对相应产品/客户的暂时期，则仅会发起连续索赔的ALV处理。如果相应的给付期仍然有效，则不应使用ALV处理。而是索赔过程应当直接进行至判定阶段。如果索赔人提供了利益承保范围合同下的损失证明，则同样应当绕过ALV处理。最后，索赔必须在发起ALV处理之前已经过权利阶段。

对ALV处理的管理应用多个特定规则。首先，如果TCL是可获得的并且已经分派TCL作为针对相应的商业(产品/客户部分)的验证的来源(可以是由ALV系统的操作者来维持的内部数据库或外部来源数据库)的情况下，则可以访问证实数据源。因此MVV≥TCL。

其次，在索赔的判定期间证实数据源仅会被使用一次，除非证实数据源被指示为数据相关验证源或在先前尝试搜索数据库未能产生匹配的情况下。

第三，将连续搜索的与索赔匹配的每个证实数据源的置信评分添加到AVV，使得AVV评分表示该索赔的当前累积验证评分。

第四，在每次证实数据源搜索之后，将AVV评分与该索赔的所需TCL值相比较，以确定是否针对该索赔达到了TCL评分。如果达到了TCL评分，则完成ALV处理，索赔处理系统10进行至针对索赔的判定阶段100。如果针对索赔尚未满足TCL评分，则ALV处理应当仅通过以下操作来继续：在利用其余未检验的证实数据源的PVV可得到索赔的RVV值(TCL-AVV)的情况下，查阅可用于索赔的其余证实数据源。如果这些其余未检验证实数据源的PVV值没有超过索赔的RVV评分，则ALV处理结束，索赔处理系统10应当在到达判定阶段100之前进行至索赔的客户提供损失查证。

示例1

本发明的ALV处理工具的应用示例是图5所示的人寿保险单索赔。对于人寿保险单索赔150，ALV处理预先分派两个证实数据源：由联邦社会保障署管理的社会保障死亡索引(“SSDI”)152以及讣告索引154。

ALV处理工具的规则引擎包含由发出人寿保险单的保险公司预先建立的TCL转换表156。该表指示对于作为给付索赔主题的类型的人寿保险单，等于1的风险评估评分(“RAS”)158转换为等于30％的TCL评分159以验证要求索赔的损失。另一方面，等于2的RAS需要等于40％的TCL评分。在示例性ALV处理下，相应的RAS值3、4和5分别转换为所需的TCL评分75％、85％和100％。

根据规则引擎，ALV处理首先查阅可在线访问的SSDI。如果在死者的社会保障号与索赔人和SSDI记录所提供的死亡日期相匹配，则由于这种数据匹配而将预先分派的置信度50添加到AVV评分。因此，对于自动化索赔验证过程AVV＝50％。在这种情况下，由于AVV≥TCL，所以可以查证RAS评分为1或2的索赔以及得到的30％或40％TCL需求。这种索赔应当进行至判定阶段。

然而，对于具有分别与TCL评分75％、85％或100％相对应的RAS评分3、4或5的索赔，ALV处理必须继续进行。在这种情况下，查阅SSDI参考的SSID返回码。如果返回码具有“P”值，这表示已经向社会保障署提供了死亡证明书形式的死者死亡的证明，则可以将附加的预先分派置信度值50％添加到AVV评分，从而AVV＝100％。在这种情况下，将查证具有RAS值3、4或5的所有索赔。相比之下，如果仅向社会保障署电话通知了死者的死亡而没有死亡证明书的证明，则SSDI返回码将是“V”，在这种情况下，将附加的预先分派置信度值25％添加到AVV评分，从而AVV＝75％。在该事件中，将查证具有RAS值3的索赔，然而对于具有RAS值4或5的索赔将需要附加的证明。

如果SSDI记录与索赔人报告的死者的社会保障号匹配而死亡日期不匹配，则ALV处理进行至确定SSDI死亡日期与索赔中报告的死亡日期之差。如果差值≤2天，则对于索赔的AVV＝40％。在这种情况下，将查证具有RAS值1或2的索赔，而不会查证具有RAS值3、4或5的索赔。另一方面，如果报告的死亡日期与要求索赔的死亡日期之差小于7天，则SSDI参考所贡献的AVV值将仅是30％，因此只会查证具有RAS值1的索赔。

对于没有被SSDI记录成功查证的任何索赔，ALV处理将进行至查阅死者数据库154。如果与索赔中找到的信息相比发现相同姓名、死亡日期、州和城市的死者的匹配讣告记录，则将附加的50％添加到索赔的AVV评分。如果在使用SSDI之后针对未查证的索赔的RVV≤50％，则将通过成功的讣告数据库匹配来查证这样的索赔。

示例2

图6提供了向非主动失业保险(“IUI”)索赔应用本发明的ALV处理的示例。规则引擎已经预先分派TALX TPA职业查证数据库172作为用于查证IUI索赔的证实数据源。该数据库将由提交失业索赔的所有客户来访问。不是所有雇主都是该数据库的一部分，因此ALV处理首先针对雇主姓名来检验TALX TPA职业查证。匹配没有对该索赔的AVV贡献出置信度，而是允许ALV处理继续进行。

接下来，ALV处理针对失业人员的姓名、社会保障号以及终止日期来检验TALX TPA数据库。如果数据库记录中的该信息与索赔人所提供的信息相匹配，则ALV处理对该索赔的AVV评分贡献了100％置信度值。在这种情况下，由于AVV≥TCL评分178，所以将查证索赔(尽管该索赔的RAS评分176)。

如果TALX TPA数据库中报告的终止日期与索赔人提供的终止日期不匹配，则可以在ALV处理下计算这两个日期之差。如果差值没有超过7天，则置信度值70％将被贡献给AVV。这样的AVV评分将查证具有RAS评分1、2或3的所有IUI索赔。相比之下，具有风险评分4或5的IUI索赔将需要附加的证实数据源证明，该证实数据源证明可以采取州政府失业180或由前任雇主182直接提供的查证信息的形式。如果差值超过7天但小于30天，则仅40％置信度值将被贡献给该索赔的AVV评分。

示例3

图7提供了向伤残保险单索赔应用本发明的ALV处理的示例。伤残保险单索赔190与查找表192相关联，查找表192包含预定的RAS评分194和相关TCL值196。保险公司还出于在ALV处理下查证伤残保险单的目的而提供了多种证实数据源198。

例如，向病人提供服务的医生和其他医疗服务提供者可以访问医疗提供者列表数据库200。如果医疗服务提供者的姓名和电话号码与索赔人所提供的信息相匹配，则30％置信度被贡献给索赔的AVV评分。在这种情况下，将查证具有RAS评分1的索赔，而具有RAS评分2-5的索赔需要附加的贡献源来证明这些索赔的真实性。

ICD9诊断/专家数据库202包含医疗服务专家以及与该专家相关联的典型诊断。伤残保险索赔所提供的诊断与医疗提供者列表数据库200已查证的医疗服务提供者的专家之间的成功匹配将贡献出20％置信度值，使得AVV＝50％。这将查证具有RAS评分2的伤残保险。

然后ALV处理将进行至询问药物指示数据库204。该数据库包含药物名称和开这些药物的医疗诊断的列表。如果在药物指示数据库中发现索赔人所提供的药物处方和医疗诊断信息相匹配，则将20％置信度值添加到索赔的AVV评分。在这种情况下，得到的70％AVV评分将不会查证具有RAS评分3-5的索赔。

在保险工司根据HIPPA(健康保险责任法)的索赔人授权(206)查证医疗记录提供了附加的5％置信度值，该置信度值是由特殊证实数据源贡献的。现在，索赔的AVV评分是75％。这验证具有RAS评分3的伤残保险索赔，而没有验证具有RAS评分4-5的伤残保险索赔。

ICD9数据库208包含分派给相应诊断的ICD9码的列表。如果该数据库匹配了索赔中的ICD9码，则25％置信度值被贡献给索赔的ACC评分。在这种情况下，得到的100％AVV评分将查证具有RAS评分4-5的所有索赔。然而应注意，如果利用医疗提供者列表数据库200没有找到医疗服务专家姓名的匹配，则ICD9专家数据库202也不会贡献出置信度点。在这种情况下，使用该药物指示数据库204、HIPPA授权同意206以及ICD9数据库的成功匹配仅会提供总AVV值50％，因此只会查证RAS1-2索赔。

处方历史数据库210包含为具体病人开的药物的列表。如果处方历史数据库210内的社会保障号、损失日期、和姓名记录与索赔中的信息匹配并且处方名称与索赔中标识的处方匹配，则该具体证实数据源的使用向初始伤残保险单索赔提供了25％置信度值。这足以产生超过索赔所需的TCL评分的AVV评分。

因此，在ALV验证过程38中使用每个证实数据源之后，将针对索赔循环地重新计算RVV和PVV。该过程确定是否达到了索赔所需的TCL值以验证索赔，或ALV处理是否需要继续进行至询问另一证实数据源(在这种情况下识别出要求索赔人提供的任何附加数据)。

由于第三方数据源的花费不影响系统10的费用，所以重要的是使用向索赔人判定执行判决过程提供必要置信度的、最节约成本的源或源的组合。本发明的自动化损失查证工具90从最低置信度到最高置信度连续地查阅每个独立的数据源。因此，如果客户提供的损失信息证实索赔满足所需的置信度，则系统进行至依据判定阶段100的判决点。如果不满足所需的置信度，则系统将进行至搜索连续证实数据源直到索赔的AVV≥TCL为止。根据索赔的风险，系统可能已经设置了非常高的置信度，只有两个或多个独立数据源相结合才能满足该置信度。

如果达到所需的置信度，则ALV阶段90完成，索赔/激活进行至判定阶段100。如果没有达到该置信度，则ALV阶段90完成，记录所需的置信度和达到的置信度，索赔/激活进行至客户提供损失证明的过程。

因此，在行业上使用的现有索赔处理系统中，保险公司和金融机构典型地通过需要客户提供所需的信息来验证事件而加重客户负担，而与行业上使用的现有索赔处理系统不同，本发明的系统10在大多数情况下减小了索赔人的负担。例如，在现有方法下，在索赔批准之前要求提交死亡索赔的受益人向保险公司提供死亡证明书。要求提交伤残索赔的承保人提供医生签名表格验证该承保人伤残并且无法工作。提供证明的步骤耗费客户的时间和金钱。此外，该步骤耗费保险公司的资源来记载对信息的请求、追踪请求、处理接收到的信息以及得到信息以供将来参考。该步骤还添加了向客户履行给付所需的周期时间。

在本发明下，要求索赔人提供损失证明是不标准的、较不优选的损失查证方法。由于不满足风险/置信度或由于客户/产品/州需求而无权进行自动化损失查证的索赔/激活将触发这种需求。

提示索赔人完成特定信息和/或附上所需文档(web)。例如，可能需要应诊医生声明(APS)。如果需要应诊医生声明(APS)或其他表格，则提示客户打印文档或请求以(经由web)全文档打印的形式邮寄或加条形码邮寄，以与适当索赔记录相联系。

将所附的任何文档(仅web)发送至适当检查员工作组以供检查员审阅和判定。通知索赔人已转发文档以供审阅并且在5到10个营业日(根据客户设置来显示天数)之内(经由电子邮件或邮局邮件)发送该通知。在这一点上，提醒索赔人所选的通信方法并为索赔人给出更新或改变所提供的信息的机会。在该阶段，还提醒索赔人继续要求支付直到批准索赔/激活(或基于客户设置的任何其他原来的要求)为止。如果没有附上文档，则基于产品、客户、状态等驱动信件的表项，索赔人将会周期性地接收到未决文档的电子邮件/邮件通知。

应注意，在一些情况下，索赔人提供的口头查证可以用作充分证实数据源，以便验证要求索赔的损失事件。这通常会发生在风险非常低的事件中，在这样的事件中仅由索赔人提供的欺骗性或错误索赔或实际讲述并不证明存在与进一步询问相关联的花费和客户不方便性，在本发明的ALV处理和系统下也是如此。

本发明的ALV系统的以上描述关注两步处理：(1)使用RAT向要求索赔的损失分派风险评估评分，TCL值的选择必须被实现为查证要求索赔的损失的有效性；以及(2)重复选择一个或多个证实数据源，这些证实数据源向TCL值的实现贡献了预定的置信度评分，这是因为系统命中这些证实数据源以成功查证要求索赔的损失。在本发明的优选实施例中，使用分析学来产生一步ALV系统模型。在该实施例中，将表征索赔人、要求索赔的损失事件、以及可用证实数据源的所有数据相组合，以通过统计技术产生模型，所述统计技术提供单个总评分，所述单个总评分表示与利用所推选的验证源来批准索赔相关联的置信度。该系统用于寻找索赔和证实数据源的组合，索赔和证据源提供了在系统中建立的最小阈值。应当在模型内考虑与数据源相关联的成本，以便使执行ALV处理的成本最优化。

在自动化或客户损失信息提供查证过程之后，基于接收到的查证以及由产品、客户、判定阶段100下的状态(以及状态异常)等或其任意组合建立的规则给出判定。在该判定阶段，确定并向索赔人公开给付持续时间(如果可应用的话)和支付金额。

为了继续给付，自动化给付持续时间模型包含规则，所述规则确定一旦在授权了索赔的批准的情况下批准给付索赔的持续时间。这种规则处理多个因素，包括医疗诊断、雇佣类型、以及居住状态(例如，已知的失业事件、自然灾害)。以这种方式，要求索赔的给付持续时间可以与索赔人的特定损失情况有关，而不是一般化的一种情况适合所有规则。

如果批准了索赔/激活，则索赔人查看属于该批准的所有信息。例如，支付或延期金额、或者如果在金额不可得到的情况下按月的或简单的“已批准偿还您的财产”声明。显示的细节由规则引擎中的表项来驱动。

根据客户/产品设置，系统的自动化模型确定：

●在哪里/如何检索所需的信息(自动化数据检索vs.请求开账单声明)

●适当的支付计算方法

●任何可应用的到期利息

●任何附加的给付(即，基于人寿保险单的附加的意外死亡给付)

●是否索赔的类型具有相关的持续时间模型

自动取回开账单声明数据，以基于客户设置来进行支付金额判决。若干方法可用：与客户的数据的连接；使用循环过程从客户向索赔中心馈送数据；等等。系统还可以在需要时寻找来自金融机构的开账单声明数据。如果开账单声明信息不自动可用，则存在半自动过程和较不优选的手动过程以确定给付/支付金额。向用户建议未来的通知，半自动化或手动过程开始。

保险公司和金融机构进入了示出索赔/激活的web工具，其中需要开账单声明信息来确定给付/支付金额。保险公司或金融机构输入所需的信息并向索赔人通信中心12发送所需的数据，其中系统自动确定给付/支付金额并通知索赔人。

索赔人(web)可以选择附上开账单声明的拷贝。如果索赔人正在通过IVR提交索赔/激活，则向索赔人建议该索赔人可以经由web来邮寄或电子邮寄所需的文档。

较不优选地，系统的操作者将寻找直接来自索赔人的开账单声明附件。开账单声明附件被发送至适当的检查员工作组以确定给付/支付金额。优选地，将在两个营业日或由ALV系统内的客户设置来限定数目个工作日内(经由电子邮件或邮局邮寄)发送支付/给付金额的通知。

当客户提供的损失查证过程是必要的时，检查员使用逐步文档审阅过程。系统针对每个保险产品关于该保险产品的客户、给付结构等指定可接受的文档需求。当检查员审阅文档时，系统通过该过程来询问或引导检查员。

例如，在意外死亡索赔中，需要证实的死亡证明书(CDC)。系统将如下提示索赔人：

●您是否具有CDC？

●死因是意外吗？

●损失日期是什么？

●这是针对主卡持有者的吗？

当检查员输入/选择响应时，判决执行过程完成。

每个判决都受由索赔人所选的通信方法(web、电子邮件、IVR、信件、索赔相关描述)传达给索赔人的措辞的约束。针对附加文档的请求列出了所有所需的文档；否定列出了所有否定原因；以及批准提供了与支付日期、方法和希望下一步做什么有关的特定细节。容纳所有措辞的该模块是表驱动的并且是用户维护的。该模块允许保险公司和金融机构利用产品/索赔人/给付/状态等来设立措辞。检查人可以在措辞被发布给索赔人之前查看以及批准或修订措辞(如果该过程由AIZ来驱动的话)。

在该阶段，如果欠下支付，则索赔人选择支付方法(检验、ACH等)。支付方法将被存储在表中并基于客户/产品设置来显示。一旦用户选择了支付方法，系统就将基于所选的方法和客户/产品设置来给出与期望的支付交付日期有关的建议。

一旦选择了支付，就提示索赔人保存信息(AIZ/web用户)或打印(web)。提醒索赔人其索赔/激活号并为索赔人提供800#(或针对互联网用户的网址)。在这一点上，对话结束。

如果否定了索赔/激活，则基于产品、客户、状态等规则来显示否定原因。一旦被否定，索赔人可以选择查看条款和条件或向索赔人所选的地址邮寄/电子邮寄副本。还可以在该阶段(web)提供索赔免费电话号码。维持否定记录以及索赔人通知记录，索赔人可以选择是否接收手写通信。在这一点上，对话结束。所有判定描述都是表驱动的。索赔人所看见的和听见的依赖于客户/产品/状态设置。

因此，根据本发明的自动化索赔处理系统10，可以快速且高效地审阅索赔而在大多数情况下不会因需要索赔人提交详细的索赔表格并获得和提供证实文档来证明受保事件而加重索赔人的负担。通过从有资格的第三方或专门来源得到这种证据文件，保险公司或金融机构可以对与其接受的风险等级一致的索赔进行判定，同时节约管理成本并将检查和判定时间段从一个月或更多减少到短持续时间。出于本发明的目的，考虑，“短持续时间”是指两天，优选地两个小时，甚至更优选地，当索赔人与保险公司或金融机构客户服务代表通电话或连接至网络或IVR入口给付激活系统时是实时的。此外，索赔人将不可避免地将最新式的索赔处理系统看作是示例客户服务。

图8-10描述了索赔处理系统10的ALV处理部分38的体系架构。一旦利益承保范围合同索赔经过了其起始阶段50、权利阶段60、设立阶段70和风险评估阶段80，该利益承保范围合同索赔就到达了ALV系统38的起始点230。在步骤1，系统检验客户的ALV标志的状态232。数据库234存储由本发明的索赔处理系统10和自动化查证系统38来服务的所有不同保险公司和金融机构客户的列表，在这种情况下公司操纵对多个客户的索赔进行服务的系统。如果客户的标志被设置为“开”状态，则ALV系统进行至步骤2的ALV配置步骤234。如果尚未设置ALV，则系统更新审计日志数据库238以反映这一事实，然后进行至利益承保范围合同索赔的客户提供损失查证。数据库240存储ALV系统38的每个客户特定配置的数据。这样的数据应当包括：ALV系统是否应该用于查证要求索赔的损失，受ALV系统保护的索赔的参数，测试ALV系统的频繁程度，支持ALV系统的规则或算法模型，索赔的风险评估评分，索赔的所需TCL值，以及相应的要求索赔的损失事件的可接受独立数据源，以及根据每个这种数据源的相对置信度。如果没有找到配置，则系统更新审计日志244以反映这一事实，系统进行至索赔的客户提供损失查证。

数据库246采用步骤3的ALV处理筛选步骤242，数据库246存储每个客户的必需数据或存储该客户的特定产品。基本上，客户可以定制规则集合，规则集合确定了该客户的保险或债务保护合同的每种类型或受益人类型(是否想要使ALV系统38能够作为索赔验证过程的一部分自动查证索赔以代替更耗费劳动力和时间的客户提供损失查证过程)。产品、索赔或受益人的具体类型可能具有过高的风险程度以至于客户不能将索赔查证委托给ALV处理。如果数据库246中存储的规则指示不应使用ALV处理，则更新审计日志248以反映这一事实，系统将进行至索赔的客户提供损失查证。

如果规则指示应当使用ALV处理评估和查证索赔，那么，系统进行至确定配置类型是否是模型类型(250)，其中模型类型(250)的RAS值已被计算出并且被存储在系统中。如果配置类型是这种模型类型，则系统进行至步骤4的风险评估确定252。在数据库254中存储这种利益承保范围合同的风险评估评分(“RAS”)。在处理步骤4中，系统(252)搜索数据库254以发现索赔的这种RAS以及保持样本指示符。另一方面，如果配置类型是规则驱动的，则系统将执行数据库258中存储的规则256以实时计算该索赔的RAS。注意，为保险公司或金融机构客户的特定风险接受曲线定制这种RAS计算，从而这种RAS计算可以在相同类型索赔的客户之间广泛地变化。如果用于计算索赔的RAS的必要规则是可用的，则系统进行至节点258。如果这种规则不可用，则不计算供系统执行ALV处理以查证索赔的RAS。相反，将更新审计日志260以反映索赔的这种未知RAS，系统将进行至索赔的客户提供损失查证。

如果在数据库254中找到索赔的预定RAS，则系统确定是否存在修改RAS的商业规则。客户标准RAS的这种修改可以适应特殊情况(如，不需要邮政编码查证的灾区)。该处理步骤使用数据库264中存储的规则和数据。通过学习以下描述的保持采样分析，模型可以从先前索赔经历中“学习”判定索赔的预定的RAS，其中需要该预定的RAS尽可能精确地表征索赔有欺骗性或其他错误的真实风险。然后系统利用所修改的RAS继续进行至ALV处理的节点258。

在节点258发现、修改或计算了索赔的RAS之后，系统进行至步骤6，在步骤6中，在266处检索与该RAS相关联的TCL。典型地经由“查找表”将这样的TCL存储在数据库268中。如上所述，这种TCL(或总置信度)评分确定了特定容限阈值，总体上证实文档或口头独立数据源的成功匹配必须满足该特定容限阈值，以通过ALV处理来查证索赔。较高的RAS值将需要较高的TCL评分向保险公司或金融机构反映客户发生欺骗或错误的较高风险程度，较低风险的索赔将需要较低的TCL评分，从而使得可以利用较少的证实数据源匹配经由ALV处理来查证索赔。如果系统没有发现索赔的TCL，则更新审计日志270以反映这一事实，系统将进行至索赔的客户提供损失查证。

如果在步骤6中系统找到了索赔的TCL评分，则系统在必要时应用在数据库272中存储的规则来修改(274)TCL评分。再次地，ALV处理的这方面允许基于过去索赔经历来修改TCL评分以使该TCL评分尽可能精确地表征索赔有欺骗性或错误的真实相对风险。因此，本发明的ALV系统38使得可以针对许多保险公司的保险单或金融机构的债务保护合同预先计算和存储RAS和TCL评分，以在这种保险单或债务保护合同下加速索赔的自动化索赔处理，这依赖于以下事实：系统可以使用所存储的规则来实时修改RAS和TCL评分以提高精度。

在ALV处理的步骤8，系统开始自动化损失查证处理276。该处理应用在数据库278中存储的数据，所述数据包括：多种证实数据源，为了查证索赔而对具体证实数据源的特定分派，每个证实数据源的预先分派的置信度评分，所需的查找数据元素，以及用于将证实数据源与索赔人针对索赔而提交的信息相比较的规则，以及在登记上存储的信息和先前索赔记录。如果索赔是“继续”索赔(例如，先前查证过的伤残给付索赔，其中索赔人在该索赔人的保险单下提交了要求在未来时间段给付的索赔)，则系统将排除先前用来查证索赔的并且没有多次命中数据源的证实数据源。

在步骤9中，ALV系统38计算(280)索赔的RVV，如上所述，RVV表示从索赔的设置TCL值中减去的用于索赔的AVV。注意，在第一次重复证实数据源检索并与索赔设立信息进行匹配之前，最初将该AVV评分最初设置为等于索赔的TCL值。

系统38接下来进行至步骤10，在步骤10，计算索赔的MVV值282。该处理步骤使用在数据库284中存储的针对具体证实数据源的信息，其中预先分派所述具体证实数据源以查证索赔。如上所述，将所有这些证实数据源的置信度相组合以产生MVV或最大查证值。如果查证索赔所需的TCL评分超过了该MVV值，则在更新后的审计日志286中反映这一事实并且系统继续进行至索赔的客户提供损失查证。由于甚至所有预先分派的证实数据源与索赔中包含的信息都成功匹配也不能产生足以满足TCL需求的总置信度，所以在没有附加的证实数据源可用于查证索赔的情况下不可能继续对索赔应用ALV系统38。

如果在步骤11确定可用于查证索赔的组合证实数据源的MVV值超过了查证索赔所需的TCL评分，则系统38进行至步骤12，在步骤12，系统计算出索赔的尚未检索到的所有证实数据源的PVV值(288)以查证索赔，其中这些证实数据源可用于在这种重复期间查证要求索赔的损失。注意，每当检索到证实数据源时，针对预先分派给索赔的其余证实数据源的组合PVV值必然会减小。

数据库290包含：必要的预先分派的证实数据源，这些证实数据源的置信度，以及用于计算该PVV的规则。数据库290还保持跟踪已取回并且对索赔应用的任何证实数据源，使得可以从当前路径的PVV计算中省略这些数据源。

此外，在步骤12，系统计算ALVS处理的运行可能查证值(“RPVV”)得分：

RPVV＝RPVV+PVV。

该RPVV，与来自当前查证重复的证实数据源的置信度点值(PVV)相结合，来记录来自先前查证重复(RPVV)的证实数据源的所有置信度点值。

在步骤13，系统38确定是否PVV＞0。只有在所有预先分派的证实数据源都已被检索并且被系统用来查证索赔的情况下，或者在数据源不可用的情况下，PVV值才不会超过0。在这种情况下，使用当前可用的证实数据源来查证索赔以满足所需的TCL值是不可能的，因此系统将ALV处理的其他应用异常中断并进行至节点292。

另一方面，如果PVV＞0，则系统38进行至步骤14以基于多种因素来确定从数据库290中检索(294)哪个证实数据源。首先，存储在数据库290中的规则定义了用于选择特定证实数据源的基本逻辑，其中所述特定证实数据源需要被预先分派给用于查证索赔的证实数据源的子集。其次，每个数据源都具有相关的成本。每当系统请求使用该系统的数据源时，证实数据源的一些提供方可能索费。在一些情况下，这种费用可能很高。在其他情况下，保险公司或金融机构可能已经创建了专门数据源，并且将给出使用该数据源来查证索赔的优先级，以便收回该数据源开发成本并避免递增的第三方数据源费用。

第三，不是所有数据源都可以提供相同的成功率来使索赔信息与贡献者相匹配从而查证索赔。应当使具有较高“命中率”的数据源优先，除非访问该具体数据源的成本超过了考虑该命中率的数据源的值。

第四，可以通过检索和应用一个或一组可用数据源来实现查证索赔需要满足的RVV值(即，AVV-TCL)。这使得使用这几个数据源而不是大量独立的便宜的数据源来实现期望的查证结果更有意义。因此，用于进行数据源选择294的规则对本发明的ALV处理的当前状态作出灵活反应。

在ALV处理的步骤15，检索具体数据源并对索赔中提供的信息应用296该数据源。存储在数据库298中的数据源规则和数据规则元件便于执行该处理。所述数据源得自于内部数据源300和外部第三方提供的数据源302。如果有关数据源的查证规则无法匹配索赔信息，则该数据源没有对索赔的AVV评分贡献出置信度点。另一方面，如果数据源成功与索赔信息匹配，则该数据源具有经过证实的索赔，并且在步骤16中将该数据源的预先分派的置信度点添加到索赔的运行AVV得分304。

在步骤17，通过从所需的TCL值中减去更新后的AVV得分来重新计算索赔的RVV评分，以查证索赔。在这一点上，利用存储在数据库310中的信息，将更新后的AVV和RVV评分以及成功与索赔匹配的证实数据源的标识添加到审计日志308。

接下来，ALV处理进行至步骤19，在步骤19，将更新后的AVV评分与索赔的所需TCL评分相比较(312)。如果AVV≥TCL，则ALV处理满足所需的TCL阈值，该信息被记录在审计日志314中。然后ALV系统将查证后的索赔发送至判定阶段100(参见图3)。

然而，如果AVV≤索赔的TCL，则索赔尚未经过查证。在步骤20，系统根据步骤14的规则和基本逻辑294来确定(316)附加查证数据源是否可用于检索和应用于索赔。如果不再有可用的证实数据源，则ALV处理和实线系统进行至节点292。

转向图10，不再有查证数据源300、302可用的索赔进行至步骤21。在该ALV处理步骤中，系统确定320是否RVV＞MVV-RPVV。如果是，则系统更新审计日志322以反映无法达到所需TCL的这一事实。然后系统在未查证索赔的情况下返回入口。

然而，如果RVV＝MVV-RPVV，则系统进行至步骤22以基于数据库325中存储的基本逻辑或优先级来确定要命中什么样的证实数据源。根据步骤23必须向索赔人请求328这些附加的证实数据元素。请求的短语由数据库330来提供，更新审计日志332。系统返回入口以向客户请求334该附加信息，这是因为如果根据索赔人对所提出的问题的回答使一个或多个证实数据源可用则可以达到所需的TCL评分。系统在辅助路径340(参见图9)中使用从客户得到的任何这样的新的数据比特338来再次发起循环询问过程以查证索赔，这是在PVV计算步骤288(步骤12)开始的。

示例4

如下提供了图8-10中描述的ALVS处理的示例：

●索赔查证的所需TCL：70％

●MVV＝90％

●证实数据源：

○SSN数据库＝20％

○死亡日期数据库＝30％

○讣告公布数据库＝30％

○口头确认＝10％。

●第一次重复

○仅SNN和死亡日期数据源可用。

○RVV＝TCL＝90％(步骤9)。

○MVV＝90％(步骤10)。

○由于TCL≤MVV，继续进行(步骤11)。

○PVV＝20％+30％＝50％(步骤12)。

○RPVV＝RPVV+PVV(步骤12)。

RPVV＝0％+50％

RPVV＝50％

○PVV＞0，所以继续进行(步骤13)。

○系统得到针对SNNu和死亡日期数据源两者的正命中(步骤14-15)。

○AVV＝20％+30％＝50％(步骤16)。

○RVV＝TCL-AVV(步骤17)

RVV＝70％-50％＝20％

○AVV≤TCL，所以继续进行第二次重复(步骤19)。

○有新的讣告数据源可用(步骤20)。

○是否RVV≥MVV-RPVV？(步骤21)

20％≤90％-50％

20％≤40％，所以继续进行。

●第二次重复

○讣告数据库价值30％置信度点

○PVV＝30％(步骤12)

○RPVV＝RPVV+PVV(步骤12)。

RPVV＝50％+30％

RPVV＝80％

○PVV＞30％，所以继续进行(步骤13)。

○系统部包含成功匹配(步骤14-15)。

○AVV仍然＝50％(步骤16)。

○RVV＝TCL-AVV(步骤17)

RVV＝70％-50％

RVV＝20％

○AVVTCL，所以继续进行第三次重复(步骤19)。

●第三次重复

○有新的口头数据源可用(步骤20)

○是否RVV≥MVV-RPVV？(步骤21)

20％≤90％-80％

○20％≤10％，所以结束ALV处理，这是因为10点口头数据源不足以满足剩余的TCL间隙。

因此，ALVS处理不能查证索赔。

本发明的ALV处理和系统38的重要部分是为各种索赔限定RAS的过程。如图11所示，风险评估过程(“RAP”)36基于周期性数据和时间而自动运行352。将使用来自若干数据库的输入数据经由编码计算机服务器运行354来计算这样的RAS。CDS数据库356存储针对未决保险单和债务保护合同的注册数据、以及在这些保险单和合同下得到的未决索赔的记录、以及在这种保险单和合同下支付的保险费，以抵消保险公司或金融机构必须支付该保险单和合同下的索赔的风险。CMS数据库358存储所有注册阶段、未决索赔激活阶段以及保险费阶段的数据。最终，数据库360分组(如，根据邮政编码、家庭或块组)存储保险单和承保人标识数据。

注意，ALV处理的操作者还可以选择人工运行362风险评估工具364。如果操作者注意到为了精确而需要更新未决索赔的RAS，则操作者的判决科学市场分析366将执行这一操作。

在计算机服务器上运行风险评估工具36将会针对各种保险单和合同产生一系列RAS 370。检验该TS评分应用以发现错误。如果有错误，则通知372科学组。进行对RAP模型的校正374，模型根据步骤350重新运行。

如果在RAT模型中没有检测到错误，则判决科学组将向服务器376发送更新后的RAS文件。数据仓库378将拾取更新后的RAS文件并更新风险评分表。数据仓库将当前RAS 380输出至索赔处理系统10以更新RAS表。然后系统向适当科学队员发送电子邮件以通知这些科学队员成功运行了周期性(例如，每周)RAT 36文件。

图12更详细示出了ALV系统38对风险评估工具36的使用。索赔人提供必要信息，所述必要信息表征了在利益承保范围合同400下进行的索赔。客户审阅对该描述性索赔信息402加以概括的确认页并提交索赔404。

然后ALV系统38请求检索索赔人以及要求索赔的损失类型的相关RAS 406。如果没有找到索赔人姓名和RAS(408)，则更新审计日志410以反映这一事实。然而，如果系统找到了索赔人姓名和RAS(412)，则检验相关规则引擎414以确定客户(保险公司或金融机构)是否已建立用于修改RPA评分418的任何特定规则416。更新审计日志420以识别日期、时间、索赔人、保险单或合同号。还记录原始RAS和修改后的RAS。

然后系统检验由保险公司或金融机构建立的规则以确定是否应当在索赔的判定期间绕过422ALV处理。如果规则表明应当绕过ALV处理(例如，如果损失的特性需要特定的文档证明，如，针对以外死亡索赔需要死亡证明书，或针对永久伤残索赔需要社会保障伤残的文档)，则索赔根据保险单或债务保护合同的条款直接进行至判定424。

另一方面，如果规则表明应对索赔进行ALV处理，则基于索赔的RAS继续进行至ALV查证426。在本发明的重要方面，将随机的特定数目的索赔指定为“保持采样”428。这表明除了经过ALV处理38的查证并且根据本发明的判定之外，还在未来时间点处跟随索赔结果，以根据保险单或合同的条款确定实际上该索赔是否合法，或确定该索赔是否是欺骗性的或错误的。通过经过RAT和ALV查证处理来比较保持采样索赔的实际结果与该保持采样索赔的预测结果，系统操作者可以识别出任何不相符之处。以这种方式，可以在必要时修改RAT和ALV处理参数以提高RAT和ALV处理的预测精度。

本发明的另一重要方面是ALV系统38的管理控制台。包括软件程序和相关图形用户界面(“GUI”)，该管理控制台允许保险公司、金融机构或其他系统操作者设立并维持不同的参数以执行ALV处理38。

图13示出了ALV系统38的登录屏幕450。该登录屏幕450包括用户ID区452，在该用户ID区452中用户输入针对ALV管理控制台所在的服务器而为该用户分派的标识名称。出于安全目的，用户还必须在区454中输入预定的口令。在单击“登录”图标456之后，系统将检验该系统的用户ID登记簿和相关口令以仅在有精确匹配的情况下为用户提供对ALV管理控制台的访问。如计算机领域已知的，如果用户忘记其口令，则该用户可以单击“忘记您的密码”超链接458，在这种情况下，系统管理员将通过邮件向该用户发送替换口令。

图14示出了本发明的ALV管理控制台的主页460。位于主页GUI上的是一系列图标：RAS/TCL 462、数据源464、数据元素466、客户配置468、搜索470、测试472和报告474。以下将描述这些图标的功能。

通过单击RAS/TCL图标462，如图15所示，将调用GUI 480，这使得系统操作者可以为具体保险公司或金融机构插入或删除风险评估评分(“RAS”)值和总置信度(“TCL”)值。RAS值是没有小数点的数。数可以在-999到999之间。TCL值是没有小数点的数，大约等于零且小于999。因此，RAS和TCL值存储在一个或多个系统数据库中。

在区482中呈现当前RAS值。通过单击单选按钮484，可以通过单击“插入”超链接486来编辑相应的RAS值。

在区487中描述当前TCL值。通过单击单选按钮488，可以通过单击“插入”超链接489来编辑相应的TCL值。

通过单击“数据源”图标464来访问图16所示的数据源GUI 490。该屏幕使系统操作者可以设立ALV系统38的证实数据源以进行索赔查证。在该会话设置应用于该证实数据源。

区492使得可以以输入至区494中的正式名称来标识数据源。向区496中输入数据源的成本基础(例如，免费的、评价的、针对每次命中的)。向区489中输入数据源的实际成本。多命中区500通过“是”或“否”条目示出了是否可以出于查证损失事件的目的多次调用具体数据源。例如，图16所示的被检验为“是”的处方历史数据库是数据驱动数据库，所以该处方历史数据库可以在索赔查证过程中多次提供更新后的查证信息。相反，医生专家数据库永远相对于索赔提供单个数据点。因此，系统在索赔查证过程中仅应查阅该医生专家数据库一次。

通过将有效命中的总数除以命中总数，计算出每个证实数据源的“命中率”。该值可以表示为百分比，并且表征用于查证索赔的数据源的有用性，将该值输入区502中。可以由系统操作者人工输入该命中率值。备选地，如果检验到“计算出的”单选按钮504，则系统可以自动计算该命中率值。“政府机关”区506和“地区”区508指示用于查证索赔信息的具体证实数据源的地理可应用性。“政府机关”指的是客户的操作国家。“地区”指的是该国家内的州或省。系统在区509内标识数据源数据条目或修订的有效数据。

单击世界地球符号510打开弹出窗口512，弹出窗口512允许选择地区(所有vs所选地区)。通过单击“数据元素”图标466，计算机ALVS系统38调用图17所示的GUI 520。该屏幕允许系统操作者输入每个证实数据源的数据元素。将该屏幕的设置应用于所有客户配置。

“区域源”下拉框522或“搜索区”下拉框524可以过滤证实数据源。该屏幕允许在区526中修改数据元素名称以及在区528中确定数据元素是否是区可搜索的。数据元素名称不能具有多于50个字符。如果索赔人必须提供元素的信息，根据针对数据查证而设置的规则来使用或不使用数据元素的“搜索区”确定器。应用使用该区来确定附加问题。

授权和同意被看作是数据元素。因此，如果数据源在被命中前需要授权，则该授权将被设置为数据元素。

区530限定了每个数据源的可搜索的具体元素。对于社会保障死亡索引532，这可以是死者的名或姓。对于讣告数据库，这可能是死者的死亡日期534。系统在区536内标识数据源条目的有效日期。

图18示出了ALV客户配置GUI 540，可以通过单击图标468来访问该ALV客户配置GUI 540。该ALV客户配置GUI 540收集在相同的行政机关(例如，美国、加拿大、波多黎各)、商业险(例如，保险、债务保护)、产品捆绑、客户和组成下的配置。ALV系统38使用该配置来确定使用哪些数据源和规则来查证给付索赔。

GUI屏幕540显示已有的ALV系统客户配置。GUI屏幕540还允许通过单击“单击此处以添加新配置”超链接542来创建新的客户配置。还可以编辑已有的客户配置。

可以容易地搜索客户配置条目。例如，为了得到由保险公司或金融机构的美国行政机关的所有ALV配置组成的列表，应当将“美国”插入“行政机关”区544并单击“搜索”按钮546。为了得到客户A的所有配置，应当将“客户A”插入“客户”区548，之后激活搜索按钮546。客户配置的其他可搜索区包括“配置ID”区550、“产品捆绑”区522、“商业线”区544、和“组成”区566。在摘要框558中描述具体客户配置的所有相关区信息。“重置”按钮559允许执行新的搜索。

图19示出了用于创建新的客户配置的GUI 560。通过单击GUI 540中的超链接542来访问该GUI 560。ALV系统38将在区562中分派“配置ID”，所述“配置ID”可以由数字、字母或其组合构成。下拉框为系统操作者提供了方便的途径以输入针对行政机关(564)、客户(568)、产品捆绑(570)和组成(572)的有关标识信息。还可以向下拉框574中插入配置的状态(即，开、关、测试)。向下拉框576中输入利益承保范围合同的类型(即，保险、债务保护)。最后，系统操作者可以容易地向区578中输入与客户配置有关的注释。

单击“下一个”按钮580使系统操作者来到图20所描述的GUI 590，以选择从应当应用于客户配置的规则引擎108设置的规则。这些规则是风险评估处理(“ARP”)规则，ALV系统应用风险评估处理(“ARP”)规则来修改具体客户配置条目的保险单或祭无保护产品的预先分派的风险评估评分(“RAS”)。该屏幕允许插入、更新和删除RAP规则比特。RAP规则比特被插入区中，同时单击条目栏594中的单选按钮595允许编辑已有的RAP规则条目。“下一个”按钮596使系统操作者能够进行至图21所示的GUI 600。“前一个”按钮598允许再访问GUI 560。GUI600提供了转换表，ALV系统38使用该转换表将RAS转换成ALV目标置信度(“TCL”)。借助于下拉框604向RAS区602输入可用RAS值。接下来，借助于下拉框608将保险公司或金融机构针对具体RAS评分而选择的TCL值输入至区606。借助于下拉框，将为了在尚未预先分派RAS评分的情况下计算保险单或债务保护合同的RAS评分而选择的规则设置输入区610中。最终，将用于对得自于转换表614的TCL值进行修改的规则设置输入下拉框612。“下一个”按钮使系统进行至图22所示的GUI 620。

GUI 620使得可以输入证实数据源及其相应置信度。如上所述，这些数据源被ALV系统38用来查证索赔。可以经由该屏幕来插入、删除或更新数据源。借助于下拉框将数据源的标识输入区622。下拉框仅示出了具体类型保险单或祭无保护合同的相关可用证实数据源。例如，对于人寿保险单仅会示出人寿相关数据源(例如，社会保障死亡索引、讣告数据库)。系统还考虑数据源的政府机构设置。

“优先级”区624是从0到99的数，对于数据源条目的创建来说不需要该“优先级”区624。“状态”区626是提供以下选择的下拉框：开、关和测试。

“置信度”区628是保险公司或金融机构分派给每个数据源的相对置信度的仓库。典型地，相对置信度是0和100之间的百分比。每个证实数据源将具有与其相关的访问成本。将该成本数输入区628以及将成本类型(例如，评价、针对每次命中、等)插入区630。“命中率”632是具有以下三个选项的下拉框：默认的、计算的和分派的。“默认的”是指应当使用输入数据源中的命中率。“计算的”是指系统应当根据以下公式自动计算值：

“分派的”是指系统操作者应当人工输入值。

“多命中”区634允许输入以下选择：是、否和默认。

这确定了系统是否可以针对相同索赔命中数据源多次。如果选择了“默认”，则使用从数据源屏幕得到的信息。

如上所述，通过单击“下一个”按钮636，访问图23所示的GUI 640以指定应用于各种数据源以查证索赔信息的规则设置。这还允许在规则设置中针对每个规则设置置信度值和状态。

对于当前配置的每个数据源存在标签642。每个数据源必须具有至少一个规则设置644。规则设置是在规则引擎中分派的规则设置ID。将数据源的置信度值输入区646中，而在区648中表示相关规则的状态(开、关、测试)。

数据源的所有规则置信度值之和不能超过为数据源分派的置信度值。当系统操作者单击“完成”按钮649时应用程序保存配置。在保存信息之前，软件应用程序验证不存在具有相同设置的两个配置。

图24示出了GUI 650，GUI 650用于搜索已经过ALV系统38处理的索赔。该屏幕不用作经过处理的索赔的报告。通过单击“搜索”图标470来访问该屏幕。

GUI 650允许通过以下元素的组合来搜索索赔：

●行政机关(652)：行政机关列表的下拉框。选项“所有”可用。

●商业线(654)：依赖于所选行政机关的值的下拉框。选项“所有”可用。

●客户(656)：客户列表的下拉框。该列表依赖于所选的行政机关和商业线。选项“所有可用。

●产品捆绑(658)：依赖于所选行政机构、商业线和客户的产品捆绑列表。选项“所有”可用。

●组成(660)：依赖于所选行政机关、商业线、客户和产品捆绑的组成列表。选项“所有”可用。

●给付号(662)：用于输入给付号的文本框。

●序列(664)：依赖于给付号的序列号的下拉框。

●RAS(666)：可能风险评分的下拉框。选项“所有”可用。

●TCL(668)：可能TCL值的下拉框。选项“所有”可用。

●数据源(670)：数据源的下拉框。基于所选组成来对该列表进行过滤。

●初始继续(672)：具有三个选项“所有”、“初始”和“继续”的下拉框。

●配置(674)：用于输入ALV客户配置ID的文本框。

●保持采样(676)：具有三个选项“所有”、“是”或“否”的下拉框。

●给付表格(678)：用于输入数据的文本框。

●给付至(680)：用于输入数据的文本框。

搜索返回与所选标准匹配的所有记录。示出了以下区：

●给付号

●序列号

●ALV查证给付的日期

●行政机关

●商业线

●产品捆绑

●组成

●客户

●RAS

●TCL

●数据源

●保持

●状态

单击“搜索”图标682对所处理的索赔条目起作用，在框684中概括了索赔条目。“重置”按钮686允许执行另一搜索。

图25所示的GUI 690示出了所选的经过处理的ALV系统查证的全部细节。在上面的区692中，示出了给付号694、索赔人姓名696、行政机关698、商业线700、产品捆绑702、客户704、组成706、损失日期708、初始或继续给付状态710、ALV客户配置ID 712、ALV状态714、RAS评分716、TCL评分718、MVV值720以及保持采样722。系统为数据库提取这些信息。屏幕还在表724中描述了规则设置(如果有的话)，ALV系统38使用该规则设置来确定shi否应当继续进行ALV查证处理。

最后，GUI 690示出了表726中用于验证索赔的所有数据源以及得到的PVV 728、RPVV 730、获得的值732、AVV 734、RVV 736、数据源优先级738、数据源状态740以及用于查证信息的规则设置741。如果向索赔人请求附加信息，则在区742中反映这一情况。针对数据源的每一次重复使用在区744中描述了ALV状态。

本发明的自动化损失查证工具38的另一重要特征是“控制测试环境”模块800。如图26所示，该“控制测试环境模块”800包括并行的规则引擎802、数据库804、以及管理控制GUI 806的集合，由ALV管理控制台的“测试”图标472(参见图14)来访问管理控制GUI 806的集合。该控制测试环境模块用于在ALV配置和规则的任何可能改变并入生产系统之前测试这种改变。以上已经描述了生产系统的规则引擎108、相关数据库62、66、68、82、84、86以及管理控制GUI 450。证实数据源110、112支持生产系统和控制测试环境系统。通过具有子集的规则引擎802和相关数据库804，测试数据可以源自于索赔视觉产生数据库810中包含的历史索赔，或可以经由索赔视觉测试数据库808被人工输入。

以这种方式，系统操作者可以修改至ALV系统的重要输入变量，如索赔的RAS值、索赔的所需TCL值、分派给证实数据源(内部和外部的)的置信度点值、新的内部或外部证实数据源、为了查证特定索赔损失而分派的证实数据源的组合、针对分派给索赔的这种证实数据源组合的询问顺序等等，以确定受控的测试环境内ALV系统38的性能结果。ALV系统操作者将希望确保ALV系统参数的可能改变会产生以下有益结果：在产品的规则引擎和数据库中发生实际修改之前，精确地查证所测试的要求索赔的损失。因此，这种控制测试环境模块800使得可以根据需要来查证、维护和调节ALV系统38，以确保系统38的最优化。

其他示例

以下三个示例示出了索赔，其中，保险公司通过根据索赔人的源独立性寻找查证，来验证索赔。

示例5

客户提交死亡索赔，索赔被评分为低风险。进行验证以实现批准的备选最小可接受方法包括：(a)审阅公开的讣告；(b)从政府机构获得对个人死亡的确认；(c)获得死亡证明书。在该示例中，系统将自动搜索所购买的在声誉好的新闻在线服务中公开的讣告数据库，以发现与受益人提供的事实匹配的个人。web不是讣告的有效源，除非web是官方新闻站点。如果存在匹配，则自动批准索赔。如果没有找到匹配，则自动搜索社会保障数据库以发现与受益人提供的事实匹配的个人报告死亡。如果找到匹配，则自动批准索赔。如果没找到匹配，则系统通知客户必须通过发送死亡证明书来证明死亡。

示例6

客户提交死亡索赔，索赔被评分为中等风险。进行验证以批准的备选最小方法包括：(a)从政府机构得到确认；或(b)得到死亡证明书。在该示例中，系统将自动搜索社会保障数据库以发现与受益人提供的事实匹配的个人报告死亡。如果找到匹配，则批准索赔。如果没找到匹配，则将通知客户提供死亡证明书的拷贝。

示例7

客户提交死亡索赔，索赔被评分为高风险。进行查证以批准的唯一可接受方法是死亡证明书。要求客户提供死亡证明书。

示例1和2说明了所述处理是自动搜索各种源以确认事件(死亡)而与索赔人的辅助无关的情况。在这些示例中，如果系统经由一个独立的验证备选方案成功验证了死亡，则立即通知客户损失已经过验证而无需另外的客户提供查证。好处是客户没有负担，更快地批准了索赔，以及保险公司或贷方更高效地完成了交易。

以下示例说明了保险公司或贷方通过独立编译来自各种源的信息来验证索赔，以提高这些信息源在索赔人作出的声明中的置信度。

示例8

索赔人提交伤残索赔。索赔人由于近期心脏病发作而变得无法工作。客户电话告知保险公司申请伤残索赔。公司收集与事件相关联的信息，包括心脏病发作的日期、主治医师、开的药物、住院时间。系统自动验证客户所标识的医生是心脏专家。系统还验证标识的药物典型地是针对心脏病患者而开的。系统还自动针对处方数据基本服务验证客户在事件之后某一时间接收到处方药物。使用这些经过查证的信息的点的组合，系统批准索赔。

示例9

客户提交伤残索赔。客户由于后背受伤而无法工作。客户电话告知保险公司申请伤残索赔。保险公司收集与该事件相关联的信息。系统自动验证索赔人要求索赔的由于受伤而服用的药物是针对受伤类型的。系统验证被标识为主治医师的医生是有执照的从业者。系统产生医生访问和客户声明其伤残并且无法工作的自动化邮件确认，如果所提供的信息不准确，则请求医生立即作出响应。在悬而未决两天之后，系统自动批准索赔而无需其他工作。

上述说明、示例和数据提供了对本发明的自动化损失查证系统及相关方法的完整描述。由于在不脱离本发明的精神和范围的前提下可以实现本发明的许多实施例，所以本发明的范围由所附权利要求来限定。

Claims (16)

1.一种具有信息数据库的自动化系统，用于处理在保险公司或金融机构所发出的利益承保范围合同下的索赔，所述系统包括：

(a)利益承保范围合同的标识以及对利益承保范围合同下要求索赔的事件加以表征的事实；

(b)装置，保险公司或金融机构通过统计模型或商业规则集合向利益承保范围合同下的索赔分派风险评分，以使用统计建模技术来表征索赔具有欺骗性或错误的风险；

(c)装置，用于使保险公司或金融机构所需的总置信度(“TCL”)与索赔的风险评分相关联，以查证要求索赔的损失事件；

(d)装置，用于预先选择多个证实数据源，每个证实数据源由保险公司或金融机构针对所述数据源查证要求索赔的损失事件的能力而选择或统计上建模的置信度来表征；

(e)装置，用于自动查阅一个证实数据源以确定该证实数据源的内容是否与索赔人针对要求索赔的损失事件而提供的信息相匹配，仅在确实匹配的情况下将证实数据源的预先分派的置信度值添加到索赔的累积查证值(“AVV”)评分；

(f)装置，用于通过从TCL值中减去AVV评分来确定查证要求索赔的损失事件所需的剩余查证值(“RVV”)(即，RVV＝TCL-AVV)；

(g)如果RVV值小于TCL值，则对于连续的证实数据源反复重复步骤(e)和(f)；

(h)在索赔的AVV评分等于至少所需的TCL值的情况下，按照最终决定的利益承保范围合同的规则，将经过查证的索赔处理为判定；以及

(i)如果累积AVV值不等于或超过所需的TCL值而没有其他可用的证实数据源具有足够的预先分派的置信度值，则将索赔看作是未经过查证的，其中，如果系统查阅所述其他可用的证实数据源，则所述足够的预先分派的置信度值将桥接AVV值与所需TCL值之差。

2.根据权利要求1所述的自动化索赔处理系统，还包括：

装置，用于在对于证实数据源重复使用步骤(e)和(f)之前查证索赔人有资格在利益承保范围合同下索赔给付。

3.根据权利要求1所述的自动化索赔处理系统，还包括：

装置，用于在对于证实数据源的至少首次重复使用步骤(e)和(f)之后查证索赔人有资格在利益承保范围合同下索赔给付。

4.根据权利要求1所述的自动化索赔处理系统，其中，索赔的最终决定包括：根据依据经过查证的要求索赔的损失事件的利益承保范围的规则向索赔人支付索赔。

5.根据权利要求1所述的自动化索赔处理系统，其中，索赔的最终决定包括：在使用证实数据源对索赔应用自动化查证处理之后，要求客户按照未经过查证的要求索赔的损失事件提供索赔的损失事件的损失证明。

6.根据权利要求1所述的自动化索赔处理系统，在索赔处理期间至少一个附加证实数据源变得可用于系统的自动化查阅的情况下。所述系统还包括：

(j)装置，用于计算在索赔处理期间的任何时刻可用的所有证实数据源的最大查证值(“MVV”)；

(k)装置，用于针对在步骤(e)和(f)的当前重复期间可用的具体证实数据源，计算当前查证值(“PVV”)，所述当前查证值(“PVV”)是总置信度点值；

(l)装置，用于针对在步骤(F)和(g)的当前重复期间可用的证实数据源，计算运行的当前查证值(“RPVV”)，所述运行的当前查证值(“RPVV”)是先前RPVV值与PVV值之和；

(m)如果PVV＞0，则仅继续重复步骤(f)和(g)；以及

(n)如果RVV＞MVV-RPVV，则仅针对可用证实数据源继续重复步骤(f)和(g)。

7.根据权利要求1所述的自动化索赔处理系统，其中，利益承保范围合同包括保险单。

8.根据权利要求5所述的自动化索赔处理系统，其中，保险单是从以下项目选择：短期或长期伤残保险、健康保险、大病保险、牙齿保险、定期人寿保险、终身人寿保险、通用或可变人寿保险、养老金、火灾保险、房屋保险、龙卷风或飓风保险、洪水保险、车辆保险、海上保险以及其他形式的财产和伤亡保险。

9.根据权利要求1所述的自动化索赔处理系统，其中，利益承保范围合同包括债务保护合同。

10.根据权利要求1所述的自动化索赔处理系统，还包括：规则集合，基于以节约成本的方式查证损失事件的适合性，来自动选择要与要求索赔的损失事件信息匹配的证实数据源。

11.根据权利要求8所述的自动化索赔处理系统，其中，证实数据源的适合性包括证实数据源的访问成本。

12.根据权利要求8所述的自动化索赔处理系统，其中，证实数据源的适合性包括证实数据源的命中率。

13.根据权利要求8所述的自动化索赔处理系统，其中，证实数据源的适合性包括证实数据源的置信度值与索赔的RVV值的比较。

14.根据权利要求1所述的自动化索赔处理系统，其中，证实数据源是由保险公司、金融机构或系统操作者来维护的内部数据库。

15.根据权利要求1所述的自动化索赔处理系统，其中，证实数据源是源自第三方的外部数据库。

16.一种具有信息数据库的自动化系统，用于处理保险公司或金融机构所发出的利益承保范围合同下的索赔，所述系统包括：

(a)利益承保范围合同的标识以及对利益承保范围合同下要求索赔的事件加以表征的事实；

(b)装置，使用统计建模技术来分派单个评分，所述单个评分组合了索赔人、要求索赔的事件以及一个或多个预先选择的证实数据源的相对风险评估，所述单个评分表示索赔不具有欺骗性或错误的置信度；

(c)装置，用于自动查阅一个或多个证实数据源，以确定所述证实数据源的信息内容是否与索赔人针对要求索赔的损失事件而提供的信息相匹配；

(d)仅在确实匹配的情况下，按照最终决定的利益承保范围合同的规则，将经过查证的索赔处理为判定；以及

(e)如果没有确实匹配，则将索赔处理为未经过查证。

Images