CN101027689A - 用于精确计算医疗保险计划中投保人的折扣的数据处理系统及其方法 - Google Patents

Abstract

一种用于精确计算医疗保险计划中的折扣的数据处理系统包括保险费模块，其适于存取有关医疗保险计划的投保人支付的预定期限的保险费数额的数据。索赔模块适于存取有关医疗保险计划支付给投保人的预定期限的索赔数额的数据，索赔模块还适于存取数据，以确定是否存在投保人已提出但还未支付的任何索赔，如果存在，则对还未支付的每个提出的索赔应用一组规则，来确定其是否有可能被支付，以及如果索赔有可能被支付，则将该索赔数额添加到已支付的预定期限的索赔数额中。最后，折扣模块适于接收来自保险费模块和索赔模块的数据以及使用上述数据来计算折扣数额。

Description

用于精确计算医疗保险计划中投保人 的折扣的数据处理系统及其方法

技术领域

本发明涉及一种用于精确计算医疗保险计划中投保人的折扣的数据处理系统及其方法。

背景技术

医疗保险计划，特别是个人医疗保险计划的优良的管理很显然对于计划管理者确保进行中的计划的财务可行性来说是非常重要的。然而，近年来，在一些国家，医疗保险计划的管理出现了以下改变：关注于计划的投保人并鼓励计划的投保人保持健康。至今，这在英国并没有成为可看得出的发展趋势。

在第99/1746和2001/3936号南非专利中描述了这个领域的发展实例，其全部内容结合于此作为参考。

另一种关注于鼓励计划的投保人管理他们的索赔的医疗保险计划的管理方法是基于支付给医疗保险计划的保险费数额、根据医疗保险计划所作出的索赔数额、以及与保险计划有关的激励机制中投保人的有可能的等级为投保人提供折扣。这种方法总体来说解决了保险中所固有的两个潜在问题，即，可以激励投保人索赔的道德风险、以及吸引高危人群来购买保险计划的不利选择。

另外，这种方法减轻了个人医疗保险中奖励疾病的倾向。

然而，由于很难确定支付给医疗保险计划的保险费数额以及根据医疗保险计划所作出的索赔数额，所以这种方法的实际执行存在技术困难。这是因为，例如，如果投保人改变其计划选项，则所要支付的保险费数额就会突然变化。同样，例如，如果存在已提交但还未处理的索赔或存在尚未解决的索赔，则索赔数额也会改变。仅简单地描述已在计算期限内支付了多少保险费、和已向投保人支付了多少索赔，并不能给出用于确定适当折扣的精确数额。

本发明提供了一种用于精确计算医疗保险计划中投保人的折扣的数据和规则处理系统及其方法。

发明内容

根据本发明，提供了一种用于精确计算医疗保险计划中投保人的折扣的数据处理系统，该系统包括：

保险费模块，适于存取有关医疗保险计划的投保人支付的预定期限的保险费数额的数据；

索赔模块，适于存取有关医疗保险计划支付给投保人的预定期限的索赔数额的数据，索赔模块还适于存取数据以确定是否存在投保人已提出但还未支付的任何索赔，如果存在，则对还未支付的每个已提出的索赔应用一组规则，以确定其是否有可能被支付，如果该索赔有可能被支付，则将索赔数额添加到已支付的预定期限的索赔数额中；以及

折扣模块，适于接收来自保险费模块和索赔模块的数据，并使用该数据来计算折扣数额。

优选地，该系统进一步包括激励机制模块，适于存取有关激励机制中投保人的等级的数据，以及其中，折扣模块还适于接收来自激励机制模块的数据，并使用这个数据来计算折扣数额。

优选地，折扣模块适于检验从保险费模块和索赔模块所接收的数据。

索赔模块还适于确定是否存在已为投保人审定但还未领取的任何索赔，如果存在，则应用一组规则来确定所审定的索赔的可能数额，并将索赔的可能数据添加到已支付的预定期限的索赔数额中。

可选地，保险费模块可以适于确定由医疗保险计划的投保人所支付的预定期限的保险费数额是否为折扣数额，如果是，则计算如果没有授予投保人折扣情况下投保人所要支付的数额的名义数额(notional amount)，其中，名义数额用于计算折扣数额。

索赔模块可以适于对投保人所提出的索赔数目和先前时限内投保人所提出的索赔的数目进行比较，作为进一步的差错校验。

保险费模块优选地适于使用计算出的折扣来计算下一年投保人的保险费。

本发明延伸至计算医疗保险计划中的折扣的方法，该方法包括：

存取有关由医疗保险计划的投保人所支付的预定期限的保险费数额的保险费数据；

存取有关由医疗保险计划支付给投保人的预定期限的索赔数额的索赔数据；

存取另外的索赔数据，以确定是否存在投保人已提出但还未支付的索赔，如果存在，则对还未支付的每个已提出的索赔应用一组规则，以确定其是否有可能被支付，如果有可能被支付，则将索赔数额添加到已支付的预定期限的索赔数额中；以及

使用所存取的数据来计算折扣数额。

该方法可以包括：存取有关激励机制中投保人的等级的数据，并使用该数据来计算折扣数额。

该方法还可以进一步包括：检验从保险费模块和索赔模块接收的数据。

优选地，该方法可以进一步包括：确定是否存在已为投保人审定但还未领取的任何索赔，如果存在，则应用一组规则来确定所审定的索赔的可能数额，然后将索赔的可能数额添加到已支付的预定期限的索赔数额中。

如果在由医疗保险计划的投保人所支付的预定期限的保险费数额是折扣数额，则计算名义数额，名义数额是没有授予投保人折扣的情况下投保人将要支付的数额，其中，该名义数额用于计算折扣数额。

该方法还可以进一步包括：对投保人提出的索赔数目和先前时限内投保人提出的索赔数目进行比较，作为进一步的差错检验。

附图说明

图1是医疗保险计划中的折扣方法的示意图；

图2是根据本发明的用于实现图1所示的折扣方法的系统的示意图；

图3是与医疗保险计划一起使用的激励系统的示意图；以及

图4是折扣计算程序用于从执行计算所需的各种原始资料中获取数据所采取的措施的示意图。

具体实施方式

参考第99/1746号和第2001/3936号南非专利，其全部内容结合于此作为参考，这些文件描述了一种医疗保险计划的管理方法，其中，为医疗保险计划的投保人提供了多种有关健康的设施和/或服务。这些专利列出了大量的有关健康的设施和/或服务(其实例是得到批准的健身俱乐部或健身房、减肥方案或戒烟方案)。投保人对这些设施和/或服务的使用受到监控，并为使用这些设施和/或服务的投保人奖励点数。下表概括了赚点数行为的实例：

类别	详细类别/行为	适用性	奖励的点数	频率
					健康	健身房训练	所有	5	每次训练
	健康评估	所有	75	每次评估
						组织的健康活动	所有	20	每次活动
					健康选择	不吸烟的人	所有	250	每年申报
	如果是吸烟的人，参加戒烟活动	所有	150	每次活动
						阅读自救文章	所有	10	每篇文章
	在线风险评估	所有	25	每次评估
						完成第一次救助课程	所有	30	两年中每一年所赚的点数
	通过在线健康信息测验	所有	40	每次测验
						压力中心	所有	25	每次评估

					预防措施	为孩子、婴儿进行定期身体检查	小于12岁	250	每次身体检查
	完成接种疫苗	小于24个月	200	每次接种
						乳房X线照片	大于45岁的女性	250	每次活动
	青光眼测试	大于40岁	250	两年中每一年的点数
						葡萄糖测试	大于40岁	250	两年中每一年的点数
	牙齿检查	所有	150	每次检查
						阴道抹片检查	大于16岁的女性	250	每次检查
	胆固醇检测	大于35岁的男性，大于45岁的女性	250	五年中每一年的点数
						前列腺检测	大于50岁的男性	150	每次检测
	使用在线/电话GP	所有	20	每次活动
						接种流感疫苗	所有	150	每次接种
					营养	在线营养文章	所有	10	每篇文章
	在线建立健康膳食计划	所有	30	每次活动
结果	保持健康等级	所有	30	每次保持等级
						提高健康等级	所有	50	每次提高等级
	保持目标BMI区	所有	30	每次保持等级
						改善目标BMI区	所有	50	每次改善等级
	保持身体脂肪目标	所有	30	每次保持等级
						改善身体脂肪目标	所有	50	每次改善等级
	保持血压	所有	30	每次保持等级
						改善血压	所有	50	每次改善等级
	没有休病假的工作奖励	所有	200	每年所达到的
	其他

						第二年结束的总点数
	第三...	10％
						第四...	15％
	第五+...	20％

另外，如这些专利中所述，在激励机制中定义多个状态等级，在这些专利中将这些等级定义为蓝、青铜、银、和金。基于奖励投保人的点数，将这些状态等级中的一个分配给投保人，以使得投保人的状态等级基本对应于设施和/或服务的使用。

最后，基于投保人的状态等级为投保人分配奖励。然而，在这些专利中预期的奖励并不总是能刺激到投保人。

大多数医疗保险计划的保险费都会逐年上涨，以与通货膨胀保持同步，这与投保人是否从医疗保险计划中进行索赔无关。因而，刺激投保人的另一种方法是为投保人提供折扣，折扣采取红利现金回报(cash-back bonus)或减少未来时限内可支付给医疗保险计划的保险费的形式。

根据本发明，使用由投保人从医疗保险计划得到的索赔数额连同激励机制中投保人的状态等级一起来确定投保人在下一年可支付的保险费。

例如，参考图1，居住在伦敦的为其配偶和两个孩子投保的36岁已婚男人可能希望每月支付约￡80。即，全年p＝￡960。如果我们假定在这一年中他索赔￡428用于私人会诊，则意味着潜在的可用作下一年保险费折扣的数额是￡532(￡672-￡428)。

如果还使用了激励机制，则作为下一年的保险费折扣的￡532的实际百分比取决于投保人如何积极地照顾他们自己的健康。从25％的最小值直到全部的￡532。因而，可以将这个数额的全部100％用于减少下一年的保险费。可选地，投保人可以取得50％的现金折扣。

在这种情况中，折扣等级更接近25％还是更接近100％完全取决于投保人的状态。每个人都要从作为青铜投保人开始，并且即使他们不另外做任何事来改善他们的健康状况，他们也会被授予25％的青铜投保人折扣率。因而，在上述实例中，投保人通常会有资格从下一年保险费中少付￡133。但是，几乎不费吹灰之力，投保人就可以享受具有高达100％折扣的金或白金状态，如下面的示例性表格所示：

	折扣率(％)	所需点数
			青铜银金白金	355075100	0150025003200

实质上，上述的医疗保险计划的管理方法集中在投保人身上并且激励投保人关心他们自己的健康。

为了实施上述方法，有必要提供一种能够计算折扣的数据处理系统。

然而，由于很难确定支付给医疗保险计划的保险费数额以及从医疗保险计划取得的索赔数额，所以这种方法的实际实施存在技术困难。这是因为，例如，如果投保人改变他们的计划选项，则所要支付的保险费数额会突然改变。同样，例如，如果存在已经提出但还未处理的索赔或如果存在有争议的索赔，则所取得的索赔数额可能会改变。仅简单描述已在给定期限内支付了多少保险费和已向投保人支付了多少索赔，并不能给出用于确定适当折扣的精确数额。

本发明以计算机系统的示例性形式在机器中实施，在上述计算机系统中存在一组用于使该机器执行本发明的方法的指令。在可选实施例中，该机器作为独立设备运行、或可以将其连接(例如，联网)至其他机器。在联网配置中，该系统可以在服务器-客户机网络环境中作为服务器或客户机运行、或在对等(或分布式)网络环境中作为对等机器。机器可以是服务器计算机或任何可以执行用于指定机器将要采取的动作的一组指令(序列或其他)的机器。另外，虽然以下仅参考了单个的机器，但是术语“机器”还可以包括用于单独或联合执行一组(或多组)指令以执行本文所述的方法中的任何一个或多个方法的机器的任何集合。

示例性计算机系统一般包括通过总线互相通信的处理器(例如，中央处理单元(CPU)、图形处理单元(GPU)、或两者)、主存储器、和静态存储器。计算机系统可以进一步包括视频显示单元(例如，液晶显示器(LCD)或阴极射线管(CRT))。计算机系统还包括字母数字输入设备(例如，键盘)、光标控制设备(例如，鼠标)、磁盘驱动单元、信号发生设备(例如，扬声器)、以及网络接口设备。

磁盘驱动单元包括其上存储了包含有本文所述的任意一个或多个方法或功能的一组或多组指令(例如，软件)的机器可读介质。在计算机系统执行软件的过程中，软件也可以完全或至少部分地存在于主存储器和/或处理器中，其中，主存储器和处理器也构成机器可读介质。

还可以经由网络接口设备通过网络来传送或接收软件。

虽然示例性实施例中所示的机器可读介质是单个介质，但是术语“机器可读介质”应该包括用于存储一组或多组指令的单个介质或多个介质(例如，集中式或分布式数据库、和/或相关的高速缓存或服务器)。术语“机器可读介质”还应包括能够存储、编码、或承载由机器执行的一组指令并且使该机器能够执行本发明的任意一个或多个方法的任意介质。因此，术语“机器可读介质”应该包括但不限于固态存储器、光和磁介质、以及载波信号。

参考图2，实施本发明的机器包括保险费模块10、索赔模块12、和可能的激励模块14。所有的这些模块都可操作地连接至用于计算所计算出的折扣18的折扣模块16。

另外，上述模块可以形成用于实施医疗保险计划的较大系统的一部分。

首先参考保险费模块，应了解可以计算任意预定期限(例如，每月、每季、每半年、或每年)内所要支付的保险费。假设在优选实施例中，将按年计算可支付的保险费。在这种情况下，之前的预定期限将是前一年。

当第一次创建时，要计算保险单上的保险费。另外，由于保险单接下来的某些变化就要进行重新计算。保险费计算将基于管理改变(administration change)的生效日期生成保险费的改变。

在通过雇主将保险计划卖给一群人的情况下，会出现另外的复杂性。相较于卖给个人的计划，这些计划在保险费和可用保险费(applicable benefits)方面有所不同。在这些情况下，管理的关键特征在于，为雇主提供仅给投保人的保险供款的一部分投保的选项(也称为“分割”或“弹性”计费)。这实际上是一种按照固定百分比或其他数学函数来在雇主和雇员之间分割每个投保人的保险费的方法。当雇主选择投保相关保险费的百分比时，分割还可以以投保人家属为基础。另外，雇主可以支付某种计划下所投保的费用，使得雇员如果需要就要自己升级并支付差额。总之，雇主从薪水中扣除由雇员支付的保险费，其中，雇主由于执行这个征收功能而能够得到任意折扣。在计算系统中对这种交易的所有记录进行了说明。

保险费模块16被设计来将全部保险费“分割”成用于各个支付方的多个部分(例如，投保人部分、雇主部分等)。这种计算是以上述描述的数据和规则的结合为基础的。将这些规则总结如下：

1)计算确定从投保人数据参考得到的计费类别和保险费计划。另外的规则基于该数据的可能排列来确定接下来的措施顺序

2)然后以支付方、保险费部分、分割序列(split sequence)的顺序来处理每个步骤

3)将该步骤应用于相同部分的每份保险费数额、将该步骤应用于每个家属的相同类型的保险费数额

4)根据为特定雇主所建立的规则定义来计算分割数额。这可以完全是用户指定的数额、或这个保险费数额的百分比、或通过值等携带的类似表查找的更复杂的类型

5)基于为每个部分定义的层级，计算同一部分或同一方的家属数额类型。以与用于首要投保人的比率相同的比率来计算用于这一方的分割数额

6)对于保险费子部分(sub-component)的“双亲”来说，将计算出的每个数额添加到累加总计，从而执行对于同一方来说双亲数额等于儿女数额之和的规则。

保险费部分的一般定义

保险费计算功能的核心在于数据和系统中，并被设计用于在给定期限内提供实时的个人和累加保险费供款。费率表被保存并被参考来确定已为其调用了计算的投保人的可用费率。根据不同的投保人选项来确定这些保险费费率，这些选项包括：

1)计划选项

2)投保人的年龄

3)投保人的状况

4)吸烟者/不吸烟者状况

5)医院病房等级

6)医院的位置(伦敦内/外)

然后，再次基于投保者选项(诸如绝对免赔限度等级、医院病房等级等)，将风险因素结合到该保险费费率中。这种风险因素的计算会造成加载到以上确定的保险费费率上的风险。然而，最新调整的保险费数额还要受到诸如保险费税的附加的额外保险费的影响。将这些额外保险费中的每一项都作为各自单独的部分保存在保险费分类帐中，以使其在需要时可以被单独公开。基于作为到新商业应用程序中的输入的投保人所作的选项来自动存储和计算以上所有项。可以在一个月中的任意一天来对上述部分中的任意一项进行有效改变，因而保险费可以以“任意日期”为基础而改变。

这个设计的适应性延伸到指定诸如“风险保险费”、“管理费”、“额外开支”的一般类型的保险费部分的方法。可以根据每个双亲类型的样板来生成子部分。低索赔红利被配置来从其保险费计算中包括或排除各种部分类型。

现在参考索赔数额的计算，由于在从接收到解决的处理索赔过程中存在多个步骤，所以医疗保险计划的系统是以一收到索赔就获得索赔鉴定为基础的。因而，将获取索赔的任务分为“标题获取(header capture)”阶段和“数据行获取(line capture)”阶段，其中，“标题获取”阶段在即使没有用电子学方法获取所有数据的情况下使得索赔处理的跟踪能够继续下去。

医疗保险系统还包括用于将索赔译成标准获取格式的模块。这使得无论接收方法如何，索赔都可以被尽快识别出来。可以通过邮件、电子邮件、传真(Fax)、人工递送或用电子学方法来接收索赔。

这个系统已被设计来将索赔的映象(image)自动插入到工作流程流水线中。为了达到此目的，必须首先得到关于索赔的背景。由于所有索赔都需要预先核准，所以这个步骤的目的在于找到相应的核准数据，以及执行一系列自动数据比较。在核准时，将从通知方获得以下数据：投保人的身份证明、临床顾问医生或医院的身份证明、表示临床标准(凭借其被授予核准)的临床代码组、以及临床治疗的预期日期和次数。(在复杂情况中，作为病例管理和其他通信的功能，可以在核准之后修改该数据)。

索赔的背景化是一种使得关于索赔的数据与预存在的数据组相匹配的手段。在很多情况中，这种匹配并不准确，而需要一系列的规则来自动进行关联。这些规则基于下列标准组：

●临床代码并不匹配期望的代码组，但由于多种原因而依然有效(这个编码可以在临床上相似，或可以以诊断格式而不是以程序格式来编码)

●服务提供者可以在某些方面归为期望的提供者：例如，同一医院群体、或既单独又合伙工作的医生

●投保人和医生的识别符(identfier)可能不正确或不完整

可以基于触发规则库中的一系列规则来自动或部分地解决诸如此类的情况。

在其他情况中，可以改为应用独立的一组规则：例如，可以缺少临床代码，但是索赔仅视病例而定。该系统将执行这个和其他的检查，以确定尽管数据缺失是否还可以进行病例索赔。在所有情况中都存在限定的最小数据组，没有该数据组索赔就不能被背景化。

如果没有一个规则能够执行绝对关联，则该系统可以将索赔发送给能够执行这种关联的一方。

关于所获取的索赔的中间判断服从于结合到系统的数据和算法中的多个规则。下图示出了在整个索赔流水线的背景中的判断规则。

从原始发票的图像中获取发票的格式化文本。所获取的详细资料包括提供者、投保人、服务日期、程序、以及索赔数额。

然后，检查下列各项：

1.提供者是已注册的、有效的、且没有被标记有欺诈行为。

2.成员和家属关系存在，没有终止。

3.程序代码存在并且适于计费提供者。

如果服务日期落在特定家属的核准的住院治疗的准入和清帐日期内，那么就将发票与该事件相互链接。

确定发票每行的最大收费和经过协议/标准的收费。有关支付多少的规则通常都与这些最大收费和费率有关。收费计算受到诸多因素的影响，诸如所进行的程序、提供者及其网络协议等。

该系统检查在为当前发票提供资金之前，还没有被预先付给发票。用于确定发票行是先前支付行的真实复制的标准对于每个医疗合同(speciality)都是不同的。例如，程序代码、提供者、投保人、家属、和服务日期在被认定是真实复制之前必须通过两个GP发票行完全匹配，但是对于病理(pathology)发票来说，与家属数目无关。自动拒绝真实副本。

如果发票内违反了临床计费规则，则拒绝发票行。例如，可能存在两个病理程序代码。一个程序代码是用于一组测试的，而第二个程序代码是用于包括在第一程序代码下的该组测试中的特定测试。提供者在发票上对两个程序计费是不正确的。

当投保人加入时，承保过程可以确定某时间期限的某些条件排除了投保。例如，一般的特定投保人的承保除外责任可以排除两年内所有投保。如果投保人具有诸如糖尿病的在先存在的疾病，则可以在某时间期限内应用特定疾病除外责任。不支付有关承保疾病的所有发票。在某些情况下，路由选择算法将确定是否确保获得了人员的身份验证。可选地，可以使用“延期偿付”承保，从而就不用提前进行任何调查，一直推迟到投保人患有临床疾病为止。正常承保过程然后将在以后的时间内相继发生。

存在关于不支付产品专有发票的规则。这些规则可以是来自产品的企业或风险管理所有者的临床决定或保险费决定。例如，不投保每天的牙科和不孕治疗。在计划、程序代码或类别、医药代码、提供者、业务类型、年龄范围等方面限定这些规则。这些规则基本上都是系统的固有部分。在存在根据临床代码进行编码的产品规则的情况下，该系统将警报原因代码添加到关于除外责任程序的发票行。除非评估人认可该决定，否则该系统将不会拒绝作为产品除外责任的发票行。

支付给发票行的数额可以受到限制的约束。发票行将积累的可用限制将通过程序代码、执业类型、或事件认可类别来识别。

如果投保人选择了按年的绝对免赔限度，则系统将不对每个家属的绝对免赔限度数额的值支付发票。对绝对免赔限度数额的累加将与接收发票的顺序一致。在某些情况下，可以自动重写这个规则。将要支付的数额将被累加到绝对免赔限度，即，不需要是完全的索赔数额，且并不是将永远不会被该计划投保的发票。

如果投保人已经选择了具有关于特定住院程序的扣除条款的计划，则不会对对应于特定程序的核准事件的医院发票支付扣除条款数额。

投保人或雇主可以由于诸如保险费的未支付或欺诈的原因而中止他们的发票的支付。可以自动更新流水线中的索赔状态。

在治疗开始之后3个月才接收到的发票被认为提出支付太晚。

将公布出被认为是“网络中”的医院的清单。网络中的医院将包括伦敦内和伦敦外的医院的选择。当投保人拿出保险单时，他或她可以选择是否要把伦敦的医院加入到他们的网络中医院的清单中。如果投保人允许入网络外的医院(当没有选择这个选项时的伦敦医院、或不在备咨询的健康清单中的医院)时，将存在可用于医院帐目的病人自费部分。在网络医院之外的医院，每天将支付￡400。其他病人自费部分选项包括：30％的病人自费部分，对于该事件的扣除条款；或者等价于在网络中医院发生的住院成本的支付情况。在规则库中对这些规则进行了编码。

投保人可以从几个病房等级中进行选择。基本等级为标准的私人病床。首要等级指更高的商业中心的医院(market hospital)或标准医院中的较好房间。不是所有的医院都提供两种病房等级，所以网络中医院的投保人的选项受限于他们病房等级的选择。无论实际上使用的是哪个病房等级，投保人将根据他们病房等级的选择来支付每天的费用。

如果投保人选择在非私人的NHS机构中治疗，并且该治疗为他们的计划所投保，则授予该投保人NHS现金津贴。NHS清帐表将被当作所提交的发票，并且将向投保人支付每天的费用。

经核准的医院审定是支付的一种保证。一组元规则(meta-rule)被嵌入到规则逻辑中，以解决保证的但违反其他标准的索赔冲突。

除非发票上有投保人已支付的指示，通常都会向服务提供者或医院支付费用(在两次支付费用的情况下，将所支付的费用退还给投保人)。

索赔裁决系统将检查是否适合为人工评价发送发票。元规则确定是否可以将在先规则应用作为约束、或确定是否应单独应用警告以及为人工评价发送索赔。工作流程系统在恰当的时将索赔发送到传送至人工评价库中。

图3示出了软件模块的互连方式，其中，这些软件模块结合来执行与激励程序中的点数和状态分配有关的任务。下文中将该程序称为Vitality^TM程序。

可以将Vitality(生命力)合伙人分成提供有关健康的服务(收益点数)的那些合伙人或以特惠费率对Vitality投保人提供商品或服务的保险费合伙人。给定合伙人都可能属于这两种类型中。

只受益(benefit-only)合伙人通常仅与金融等级的管理系统通信，而与Vitality点数无关。Vitality(健康带菌者的部分)网站有利于与这些使得投保人能够挽回利益的合伙人通信。这会在“网上商城”环境中通过电话或电子方式的营销的零售点发生。

一些合伙人向投保人提供有关健康的服务，在这种情况下，投保人处于点数累加状态。其他合伙人基于通过点数积累活动达到的状态等级来提供特惠费率的商品和服务。在所有的情况中，基于合同的需要和合伙人的技术能力，在Vitality管理系统和合伙人系统之间进行数据传输。

为了迎合多种情况，Vitality系统软件提供一组五个不同的通信模板，以方便与各合伙人进行数据交换。因而，可以在不额外开发或集成的情况下，仅通过应用适当软件模块和通信协议就可以实现与新合伙人的通信。下面描述各种方法：

1.基础交换协议-当Vitality合伙人需要经常存取整个Vitality投保人库的综合详细资料时使用。该协议使用多种机制来确保数据流通以及最小化数据量。其他算法确保及时校正传输误差，因而，从而确保在交易点(通常签约参加特定业务)所有数据的可用性。

2.指令交换协议-当不需要整个数据组，但是当基于需要知道而传送用于将发生的一组活动的详细指令时使用。例如，这会在投保人没有任何预先通知就注册特定服务时发生。该协议的核心在于将复杂(可能是重叠且矛盾的)指令变为单个统一的传输消息的机制。这又利用了规则引擎，而规则引擎使用能够表达各种核心和边界条件的专门规则。

3.网络服务协议-这涉及对合伙人的系统进行修改，以直接与主机网络服务器进行接口。使用预置的算法传输相关交易数据，而不需要合伙人软件的用户对此完全了解。这些算法利用能够容易定制来到各个数据交换协议的需要的高度组建化(componentised)代码。

4.调制解调设备协议-如果合伙人系统不可配置成网络服务协议(或不存在系统)，则可以使用专用的硬件设备。启动该设备(通常是通过零售合伙人)，以将交易数据和使用信息传送至Vitality主机系统。在这种情况中，使用了链接设备与普遍的电话网络的调制解调器。可用的接收软件模块对通过该通道到达的数据进行翻译和存储。

5.联机协议-在交易量十分低、并且不能集成到现存合伙人系统的情况下，通过特定的合伙人网站帮助进行数据交换。合伙人(安全地)进入站点，并通过与专用的用户接口的交互来传输所有相关数据。这个接口将利用为此而专门设计的可重复使用的软件组件。

可以依靠通信从多方参与的合伙人处、或通过经由人工、电话、或其他电子装置与投保人的直接通信来赚取点数。相关索赔数据存储在索赔管理系统的数据库中。责任在于系统要通知可能相关(相关性的仲裁程序是在点数计算模块内所激发的规则)的医疗服务的Vitality点数计算模块。

索赔模块通常以预定间隔轮询它的数据，并将特定医疗服务(由服务代码指定)的出现传输至Vitality模块。轮询程序是高速优化模块。

基于通过上述协议之一从合伙人接收到的数据来分配点数。计算的频率是所规定的服务等级的函数，仅受到确保无误差传输所需的时间限制。在很多情况下，只要发生输入的交易的处理和验证，就分配点数。

点数分配是以用于指定与特定活动相关的点数的一组通用的用户驱动数据表为基础的。补充规则引擎用于实施更复杂的规则以及元规则。

复杂的规则公式的实例：三年期限内仅一次胆固醇测试授予5000点；以5个月为间隔每年2次健康评估；如果3个月内少于10次锻炼则取消去健身房的资格。通过java“策略”在规则库中实施诸如此类的复杂规则。这些都是很容易插入任意环境(surrounding)规则基础中的自测组件。

规则策略的子集是三层限制引擎，其确保点数的分配不会超过预定阈值和子阈值。

Vitality状态(例如，“青铜”、“银”、“金”、“白金”)的主要决定因素是在投保人的保险业务量中增加的点数。然而，这还受强迫接受Vitality合同本身所隐含的大量规则、以及存在于相关个人医疗保险保险单中的规则的影响。

Java规则引擎实施在多个等级处可扩展的这些规则，一直到个人投保人规则。这意味着可以建立新规则来覆盖整个投保人总体、一组雇主(例如，工业类型)、个人雇主、个人投保人、或乃至个人的家属。

这个机制还为群体考虑了特殊规则的强迫接收。例如，可以通过添加可用规则或元规则，奖励给特定组投保人(例如，那些患有指定慢性病的投保人)更高的Vitality等级。

理论上，低索赔红利应该正好在保险单的续订日期完成。然而，由于下列两个原因，这是不可能的：第一，必须与投保人进行沟通，以使投保人明白由红利产生的利益优选权；第二，续订前必须留有“结算(cut off)”时间，以使软件能够进行所需的计算。最好使结算点尽可能地接近实际续订时间，以确保投保人计有最大点数，计算中包括已接收到所有索赔、以及任何保险费调整。

为了确保达到有效的近似，从计算模块请求所有索赔、点、以及保险费活动的“简短描述”。该模块向对应于这三个子系统的模块发送消息，并请求对用在红利计算中的所有三个算子进行立即的状态检查。

下面各段落进一步深入研究通过计算模块16执行的功能。该模块控制从正确序列中的相关子系统中获得相关信息所需的所有必要活动。

该计算模块利用“工作流程”顺序，其调用环境系统中的函数，以获得供折扣公式使用的必要值。其使用这些值，结合内置智能的应用程序来计算新的保险费。下面参考图4a-4c概述这些步骤。

获取保险费

红利计算模块向保险费系统发送消息。获取自从执行最后的这种计算所支付的所有保险费的总和。然后，对返回值进行某些检查，以解决下列问题：

●确保使用“名义”保险费来确定用于计算的值。由于所使用的保险费是在前一年没有施行折扣的情况下投保人将支付的数额，所以其在两个以上的保险单年度中是相关的。因而，计算模块参考上一年的计算来确定紧接在折扣计算之前的期限内不存在任何这种折扣。如果存在，则不使用所支付的实际保险费，而是向保险费模块发送消息，以像不存在折扣一样，计算该投保人的名义保险费(包括计划改变、家庭改变)。作为检查，将考虑中的本年百分比折扣应用于实际支付的保险费，并将其与第一值进行比较。如果他们不匹配，则在手动检查过程中中止计算。自动消息将被发送至负责解决该不一致的一方。

●保险费比之前的计算高还是低？如果低，则发送附加信息，以确保引起该改变的所发生的适当事件。这可以是投保的改变或家庭组成的改变。

●如果大约在计算时发生保险费变动，则存在关于用在公式中的保险费的确切额的某些疑问。在这种情况下，一些假设是必要的，以使得计算能够继续下去。平均数和其他“平滑”策略的使用有助于正确的保险费总和的近似，从而有助于正确的红利数额的近似。

●计算程序必须考虑可能存在于由健康保险单所投保的家庭单元的组成中的任何变动。计算模块必须仔细分析对于保险项目来说变得不合格的结婚、离婚、以及家属和孩子的增加。这使得计算模块能够在详细审查期限当中，将计算公式的变量应用于由保险单所吸引的累计保险费。计算模块能够向保险费子系统查询该数据，然后了解其以用于红利确定的目的。

获得索赔

红利计算模块如下向索赔模块子系统发送请求：

1.预核准(preauthorisation)子系统：这将以使得红利计算模块确定该系统中余留的未决索赔风险的等级的数据作为响应。然后，计算模块将该年内投保人的所有临床事件分成三类：

a.结束的临床事件(支付了所有索赔)

b.正在发生的临床事件(已部分支付了索赔)

c.通知并审定，但仍未索赔的临床事件。

然后，红利计算模块将利用规则来确定将要在其计算中使用哪个索赔。适用于不同临床情况的费用基于相关的临床预见性而不同。例如，在可接受的误差范围内，扁桃体切除术的花费通常相同。又例如，诸如可以完成髋关节置换术的某些住院治疗，但是计算模块包括表明期望一定量的后续物理治疗的临床知识。在这种临床情况下，在与审定本身相关联的某一标准下，红利计算中可能会包括未完成事件的索赔。

2.索赔子系统：与保险费一起，支付给投保人的索赔的精确总数是红利计算中的主要运算量。计算模块将请求在某个时间期限内所支付的所有索赔。然后，在由预核准子系统返回的时候，将检查临床事件的所有索赔。与事件无关的索赔可能表明误差。该模块包括多个规则，以将潜在误差传送(escalate)至能够解决他们的各方。

计算模块还对特定投保人的索赔总数与先前时间期限内(一般是前一年)的总数进行比较。这个值随着时间推移的显著变化表示额外的误差。在知道投保人将遭受预计会引起治疗(以及因而产生索赔)的健康事件的某些情况下，通过计算模块将计算期限内的总索赔的减少标记为用于研究的潜在区域。

索赔量的增加可能是由于除了身体状况不佳以外的其他因素。例如，投保人可能已经增加了在那个保险单上的投保人数。对于大的索赔量，计算模块将向附加的子系统发送消息，以试图使索赔总数与单独个人和/或临床环境能够一致。

如果在预核准和索赔之间的比较产生了一些差异，那么红利计算程序将尝试“平滑”索赔，以使其与记录在系统中的临床数据一致。例如，如果存在由于预核准的临床事件导致的某个索赔总数的预期(其中，对于预核准的临床事件来说，没有收到索赔)，则计算模块将假定允许其处理使不受欺骗的索赔，就好像已经顺利接收了这些索赔，即，与预期一致。

获得点数、状态

已在红利计算期限内，通过软件记录了所有的点数累积活动。计算模块需要用于基于多个标准来重新计算“状态”等级的总点数。

●对于简单情况来说，状态是点范围的函数，点范围赋予投保人的某种“颜色”状态。

●在投保人可能已经结婚或离婚(或离婚，然后再婚)的情况下，需要更加复杂的计算。由于单身和家庭的状态阈值不同，因此在先等级函数重新计算特定保险单所需的阈值等级。这将是计算期限内的相对于所赚点数的最终状态等级。

●甚至可能存在计算软件可以通过某些规则的应用来解决的更加复杂的情况。例如，已婚男人可能离婚，并且他的前妻可能嫁给另一个投保人(选择转到该保险单)。在这种情况下，妻子离婚前所赚取的点数在计算期限中需要通过两个保险单来进行分配。根据原始点数获取活动的种类，利用完全不同的公式进行分配。此外，对施加了最大容许点数的活动来说，需要得出可用的限度，以计算用于该保险单的最终点数分配。

计算红利数额

直到已经识别和解析出上述参数之前，红利计算模块16将不会继续进行最后的计算模块。红利计算模块具有能够确定已进行到整个计算的什么程度的能力，并可以使得所执行的整组部分活动变得显而易见。另外，计算模块将自己确定为下列状态之一：

完成-简单计算，没有其他的问题

未完成，但一些未决的问题可能会自动解决

未完成，但有一些需要人为干预的不严重问题

未解决，仍有严重问题

一旦计算出来投保人可得到的红利，就根据保险单(个人、团体)的种类以及个人所进行的选择(折扣、现金回报)而对投保人可得到的红利进行多次改变。这在别处有所描述。

然后，可以计算出下一年的保险费。于是，这成为了诸如年龄、性别、地理和投保人已购买的投保的常规元素的函数。如本文所述，添加其上的元素将是前一年所要支付的保险费、索赔历史记录和生活方式历史记录。

得到保险单消息

根据上述处理和规则，可用的低索赔折扣的计算会产生将支付给保险单的可得到的值。然后，必须将这个数额告知给投保人。然而，还要配备计算模块，以辨别趋势以及确定(formulate)对投保人的适当反应。

例如，如果保险费逐年显著升高(即，投保人得不到折扣)，则这可归因于以下多个因素之一：

●Vitality状态急剧下降，索赔正常：在这种情况下，计算模块将得出已缩减或停止了哪个赚点活动，并确定对投保人的适当反应。这将包括提醒要比前一年的同样情况中更频繁地去健身房。然而，需要将其与索赔数据进行比较，以确保不会产生不适当的消息：例如，人已实施过严重的髋关节手术或更严重的手术。

●Vitality状态正常，高索赔历史：这对后来经历严重临床情况或其他可选则的外科手术的低索赔人来说是非常正常的情况。这种情况下的正确反应是使用整个红利分成机制如何起作用的提醒来表明知道要进行索赔，以使投保人可以设置并获得下一年的更加有利的费率。

●混和模型-减轻对所所得点数的改变和索赔：在这种情况下，将重点放在更一般的主题上，而不仅仅是放在赚点数和索赔问题上。

因而，数据处理系统使得医疗保险计划的管理者能够计算出下一年的保险费，下一年的保险费基本上与投保人已从保险计划中索赔的数额以及与导致点数赚取有关健身和健康活动的相结合。

Claims (13)

1.一种用于精确计算医疗保险计划中的折扣的数据处理系统，所述系统包括：

保险费模块，适于存取有关所述医疗保险计划的投保人支付的预定期限的保险费数额的数据；

索赔模块，适于存取有关由所述医疗保险计划支付给所述投保人的所述预定期限的索赔数额的数据，所述索赔模块还适于存取数据，以确定是否存在任何投保人已提出但还未支付的索赔，如果存在，则对还未支付的每个所提出的索赔应用一组规则，以确定其是否有可能被支付，以及如果所述索赔有可能被支付，则将所述索赔数额添加到已支付的所述预定期限的索赔数额中；以及

折扣模块，适于接收来自所述保险费模块和所述索赔模块的数据，并使用所述数据来计算折扣数额。

2.根据权利要求1所述的系统，进一步包括激励机制模块，适于存取有关激励机制中的所述投保人的等级的数据，以及使用所述数据来计算所述折扣数额。

3.根据权利要求1或2所述的系统，其中，所述折扣模块适于检查从所述保险费模块接收的所述数据和从所述索赔模块接收的所述数据。

4.根据前述权利要求中的任一项所述的系统，其中，所述索赔模块还适于确定是否存在已为投保人审定但还未领取的索赔，如果存在，则应用一组规则来确定所审定的索赔的可能数额，然后将所述索赔的所述可能数额添加至已支付的所述预定期限的所述索赔数额中。

5.根据前述权利要求中的任一项所述的系统，其中，所述保险费模块适于确定由所述医疗保险计划的所述投保人所支付的所述预定期限的所述保险费数额是否为折扣数额，如果是，则计算名义数额，所述名义数额是没有授予所述投保人折扣的情况下所述投保人所要支付的数额，其中，所述名义数额用于计算所述折扣数额。

6.根据前述权利要求中的任一项所述的系统，其中，所述索赔模块适于对投保人提出的索赔数目和先前时间期限内投保人所提出的索赔数目进行比较，作为进一步的差错检验。

7.根据前述权利要求中的任一项所述的系统，其中，所述保险费模块适于使用所计算出来的折扣来计算下一年的所述投保人的保险费。

8.一种计算医疗保险计划中的折扣的方法，所述方法包括：

存取有关由所述医疗保险计划的投保人所支付的预定期限的保险费数额的保险费数据；

存取有关所述由所述医疗保险计划支付给所述投保人的预定期限的索赔数额的索赔数据；

存取另外的索赔数据，以确定是否已存在投保人已提出但还未支付的任何索赔，如果存在，则对还未支付的每个所提出的索赔应用一组规则，以确定其是否有可能被支付，如果有可能被支付，则将所述索赔的数额添加到已支付的所述预定期限的索赔数额中；以及

使用所存取的数据来计算折扣数额。

9.根据权利要求8所述的方法，进一步包括：

存取有关激励机制中的所述投保人的等级的数据，以及使用所述数据来计算所述折扣数额。

10.根据权利要求8或9所述的方法，进一步包括：

检查从所述保险模块接收的所述数据和从所述索赔模块接收的所述数据。

11.根据权利要求8至10中任一项所述的方法，进一步包括：

确定是否存在已为投保人审定但还未领取的任何索赔，如果存在，则应用一组规则来确定所审定的索赔的可能数额，然后将所述索赔的所述可能数额添加至已支付的所述预定期限的所述索赔数额中。

12.根据权利要求8至11中任一项所述的方法，进一步包括：

确定在由所述医疗保险计划的所述投保人所支付的所述预定期限的所述保险费数额是否为折扣数额，如果是，则计算名义数额，所述名义数额是没有授予所述投保人折扣的情况下所述投保人所要支付的数额，其中，所述名义数额用于计算所述折扣数额。

13.根据权利要求8至12中的任一项所述的方法，进一步包括：

对投保人提出的索赔数目和先前时间期限内投保人提出的索赔数目进行比较，作为进一步的差错检验。

Images