掌桥专利:专业的专利平台
掌桥专利
首页

自动化理算系统、方法、装置、介质及设备

文献发布时间:2023-06-19 18:37:28


自动化理算系统、方法、装置、介质及设备

技术领域

本申请涉及计算机技术领域,具体而言,涉及一种自动化理算系统、自动化理算方法、自动化理算装置、计算机可读存储介质及电子设备。

背景技术

在用户的线下医疗全流程中,通常需要依次经过如下步骤:挂号-门诊-检查/检验-医生开处方;或者,挂号-住院-检查-检验-手术。

在相关技术中,用户在完成了上述医疗全流程后,可以整理整个流程中涉及的收据、处方单等信息作为证明材料,向保险公司申请商业医疗保险赔付,保险公司可以对用户提交的证明材料进行审核,得到最终的赔付方案,用户可以从赔付方案中获知保险赔付的具体金额。

但是,上述方案存在信息滞后的问题,用户在医疗全流程的每个步骤中都需要先行缴费,却只能在医疗全流程完成后才能获知保险赔付的具体金额。

需要说明的是,在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解,因此可以包括不构成对本领域普通技术人员已知的相关技术的信息。

发明内容

本申请的目的在于提供一种自动化理算系统、自动化理算装置、计算机可读存储介质及电子设备,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

本申请的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本申请的实践而习得。

根据本申请的一方面,提供一种自动化理算系统,自动化理算系统包括医院数据系统、数据理算系统、客户端,其中:

医院数据系统,用于基于用户信息生成当前医疗环节对应的医疗数据,并将医疗数据发送至数据理算系统;

数据理算系统,用于获取用户信息对应的保险数据,并根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用;

客户端,用于获取目标保险理算结果并展示目标保险理算结果。

在本申请的一种可选的实施例中,其中:

客户端,还用于响应于多环节数据请求,获取包含当前医疗环节在内的各个已触发的医疗环节分别对应的医疗数据并展示各医疗数据。

在本申请的一种可选的实施例中,自动化理算系统还包括业务理赔系统,其中:

业务理赔系统,用于响应于医疗结束指令,根据各医疗环节对应的保险理算结果生成医疗订单,并向客户端发送医疗订单;其中,各医疗环节包括当前医疗环节。

在本申请的一种可选的实施例中,业务理赔系统,用于根据各医疗环节对应的保险理算结果生成医疗订单,包括:

业务理赔系统,用于将各保险理算结果中的医保分担费用进行求和,得到医保分担费用总和;将各保险理算结果中的商保分担费用进行求和,得到商保分担费用总和;将各保险理算结果中的用户分担费用进行求和,得到用户分担费用总和;

业务理赔系统,用于生成包含医保分担费用总和、商保分担费用总和、用户分担费用总和的医疗订单。

在本申请的一种可选的实施例中,其中:

客户端,还用于响应于针对医疗订单的支付操作,基于医疗订单执行扣款操作。

在本申请的一种可选的实施例中,其中:

业务理赔系统,还用于获取对应于用户信息的历史医疗订单,并根据医疗订单和历史医疗订单生成赔付情况统计表;响应于统计表获取请求,将赔付情况统计表发送至客户端。

在本申请的一种可选的实施例中,数据理算系统,用于根据保险数据生成对应于医疗数据的目标保险理算结果,包括:

数据理算系统,用于对医疗数据进行结构化处理,得到数据表;

数据理算系统,用于对数据表进行信息审核,若审核通过,则根据保险数据生成对应于数据表的目标保险理算结果。

在本申请的一种可选的实施例中,数据理算系统,用于对数据表进行信息审核,包括:

数据理算系统,用于获取数据表中各字段对应的审核规则;根据审核规则审核相应字段中的信息,得到对应于各字段的审核结果;若各审核结果均表示无异常信息,则判定审核通过。

在本申请的一种可选的实施例中,当前医疗环节包括:挂号环节、门诊环节、检查环节、检验环节、处方环节、住院环节或者手术环节。

根据本申请的一方面,提供一种自动化理算方法,该方法包括:

获取基于用户信息生成的当前医疗环节的医疗数据;

获取用户信息对应的保险数据;

根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用;

将目标保险理算结果发送至客户端,以使得客户端展示目标保险理算结果。

根据本申请的一方面,提供一种自动化理算装置,该装置包括:

数据获取单元,用于获取基于用户信息生成的当前医疗环节的医疗数据;

数据获取单元,还用于获取用户信息对应的保险数据;

保险理算单元,用于根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用;

理算结果发送单元,用于将目标保险理算结果发送至客户端,以使得客户端展示目标保险理算结果。

根据本申请的一方面,提供一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述的各种可选实现方式中提供的方法。

根据本申请的一方面,提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述任意一项的方法。

根据本申请的一方面,提供一种电子设备,包括:处理器;以及存储器,用于存储处理器的可执行指令;其中,处理器配置为经由执行可执行指令来执行上述任意一项的方法。

本申请示例性实施例可以具有以下部分或全部有益效果:

在本申请的一示例实施方式所提供的自动化理算系统中,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1示意性示出了根据本申请的一个实施例的自动化理算系统的架构图;

图2示意性示出了根据本申请的另一个实施例的自动化理算系统的架构图;

图3示意性示出了根据本申请的一个实施例用于展示目标保险理算结果的客户端界面图;

图4示意性示出了根据本申请的一个实施例用于展示医疗订单的客户端界面图;

图5示意性示出了根据本申请的一个实施例的自动化理算系统的序列图;

图6示意性示出了根据本申请的一个实施例的自动化理算方法的流程图;

图7示意性示出了根据本申请的一个实施例的自动化理算装置的结构示意图;

图8示意性示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本申请将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中,提供许多具体细节从而给出对本申请的实施方式的充分理解。然而,本领域技术人员将意识到,可以实践本申请的技术方案而省略所述特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知技术方案以避免喧宾夺主而使得本申请的各方面变得模糊。

请参阅图1,图1示意性示出了根据本申请的一个实施例的自动化理算系统的架构图。如图1所示,自动化理算系统100中可以包括医院数据系统101、数据理算系统102、客户端103。

医院数据系统101,用于基于用户信息生成当前医疗环节对应的医疗数据,并将医疗数据发送至数据理算系统102。

数据理算系统102,用于获取用户信息对应的保险数据,并根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用。

客户端103,用于获取目标保险理算结果并展示目标保险理算结果。

需要说明的是,上述客户端可以实现为以下任一种:用户安装在终端(如,手机、平板电脑等)上的应用程序、线下医院内部设置的供患者使用的医院终端设备。

图1所示的自动化理算系统主要应用于线下医疗,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

下面,对于本示例实施方式的上述步骤进行更加详细的说明。

对于医院数据系统101来说,用于基于用户信息生成当前医疗环节对应的医疗数据,并将医疗数据发送至数据理算系统102。

具体的,医院数据系统101可以基于信息输入操作获取到用户信息,用户信息可以包括与用户相关的一条或多条信息,如,姓名、身份证号、性别、过敏史、既往病史、需要前往的科室等;其中,信息输入操作可以为导诊台人员触发的也可以为用户自行触发的,本申请实施例不作限定。

其中,当前医疗环节包括:挂号环节、门诊环节、检查环节、检验环节、处方环节、住院环节或者手术环节。此外,可选的,当前医疗环节也可以为其他类型的环节,本申请实施例不作限定。医疗数据可以包括与当前医疗环节相关的一条或多条数据。

基于此,举例来说,若当前医疗环节为挂号环节,则医院数据系统101可以基于用户信息生成挂号环节对应的医疗数据,挂号环节对应的医疗数据可以包括科室(如,消化科)、医生等级(如,副院长)、费用(如,20元)等;其中,不同的科室和医生等级可以对应于不同的费用。进而,医院数据系统101可以将挂号环节对应的医疗数据发送至数据理算系统102。

进而,举例来说,若当前医疗环节为处方环节,则医院数据系统101可以基于用户信息生成处方环节对应的医疗数据,处方环节对应的医疗数据可以包括由医生在医院数据系统101中上传的药品名称,处方环节对应的医疗数据还可以包括各个药品名称对应的价格等。其中,各个药品名称对应的价格可以是医院数据系统101从药品价格数据库中查询得到的。

具体的,医院数据系统101可以与数据理算系统102进行直连,医院数据系统101与数据理算系统102之间可以进行无第三方的数据交互。对于数据理算系统102来说,在接收到医院数据系统101触发的就诊流程之后,可以响应于就诊流程的就诊请求,及时从医院数据系统101中获取到用户信息,并查询用户信息对应的用户标识,用户标识可以表示为字符、数值、符号等,本申请实施例不作限定。进而,若用户标识属于特定类型,则可以将用户信息对应的用户判定为商保直赔用户;其中,用户标识所属的类型数量可以为任意数量,本申请实施例不作限定。举例来说,用户标识所属的类型包括:一般类型和特定类型,若用户标识属于特定类型,则表示该用户为VIP用户,若用户标识属于一般类型,则表示该用户为普通用户。若用户标识属于一般类型,则进入普通就诊流程,即,先付费再看病流程。

此外,数据理算系统102,还用于响应于就诊请求,查询对应于用户信息的用户标识;若用户标识属于特定类型,则将用户信息对应的用户判定为商保直赔用户。这样可以在判定用户是否为商保直赔用户,在判定出用户为商保直赔用户时,可以便于为此类用户提供便捷的“先看病再付费”的功能。

进而,可选的,若用户标识属于一般类型,数据理算系统102可以向客户端发送试用信息,试用信息可以包括赠送的商业医疗保险相关信息,进而,响应于确认试用操作,可以将用户信息对应的用户判定为商保直赔用户,从而基于试用信息进入“先看病再付费”流程,并基于试用信息为各医疗环节对应的医疗数据生成保险理算结果。

对于数据理算系统102来说,用于获取用户信息对应的保险数据,并根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用。

具体的,用户信息对应的保险数据用于记录该用户对应的一种或多种商业保险的详细信息,如,赔付比例、赔付范围、赔付时限、赔付年龄段等。若保险数据记录的是多种商业保险的详细信息,则根据保险数据生成对应于医疗数据的目标保险理算结果的方式可以为:预计算对应于多种商业保险中各商业保险的预赔付金额,根据最大预赔付金额对应的商业保险详细信息生成对应于医疗数据的目标保险理算结果,这样可以让用户分担更少的医疗费用。或者,预计算对应于多种商业保险中各商业保险的预赔付金额,为用户展示各预赔付金额以及各预赔付金额的理算详情,响应于选取操作从各预赔付金额中确定目标预赔付金额,根据目标预赔付金额对应的商业保险详细信息生成对应于医疗数据的目标保险理算结果,这样可以提升与用户之间的交互性,根据用户选取的商业保险进行最终的理算,有利于改善用户体验。

此外,保险业务系统102根据保险数据生成对应于医疗数据的目标保险理算结果的方式可以为:保险业务系统102从医保平台获取医保分担费用,并根据保险数据计算对应于医疗数据的商保分担费用,进而,结合医保分担费用和商保分担费用计算用户分担费用,基于医保分担费用、商保分担费用、用户分担费用生成对应于医疗数据的目标保险理算结果;其中,医保平台可以与医院数据系统进行直连,当医院数据系统获取到当前医疗环节对应的医疗数据之后,可以将医疗数据同时发送给医保平台和保险业务系统。

在本申请的一种可选的实施例中,数据理算系统102,用于根据保险数据生成对应于医疗数据的目标保险理算结果,包括:数据理算系统102,用于对医疗数据进行结构化处理,得到数据表;数据理算系统102,用于对数据表进行信息审核,若审核通过,则根据保险数据生成对应于数据表的目标保险理算结果。这样可以通过数据结构化处理提升数据审核的效率,降低人工成本,实现自动化的数据审核。

具体地,数据理算系统102对医疗数据进行结构化处理,得到数据表的方式可以为:数据理算系统102从医疗数据中获取对应于各预设字段的数据,基于各预设字段的数据生成数据表,数据表包含各预设字段以及各预设字段下的数据,一个预设字段下(如,药品名称)可以包括一个或多个数据(如,阿莫西林、阿司匹林等)。进而,数据理算系统102对数据表进行信息审核的方式可以为:数据理算系统102基于审核规则对数据表中的同字段数据进行审核(如,审核同字段的数据中是否存在重复数据),和/或,对数据表中的数据进行跨字段审核(如,审核药品对应价格是否超出上限价格);其中,审核规则可以用于限定数据之间的互斥性(例如,开给一个病人的药中包含成人药品和儿童药品,那么,这两个药品之间存在互斥性)、数据之间的匹配性(例如,药品对应的价格超出了上限价格,即,药品和价格之间不匹配)等。其中,审核规则可以是,机器学习模型基于对历史药品订单的数据学习后生成、更新的。

在本申请的一种可选的实施例中,数据理算系统102,用于对数据表进行信息审核,包括:数据理算系统102,用于获取数据表中各字段对应的审核规则;根据审核规则审核相应字段中的信息,得到对应于各字段的审核结果;若各审核结果均表示无异常信息,则判定审核通过。这样可以实现自动化的数据审核,降低人工成本,并且,基于直连的医院数据系统101获取医疗数据并将其结构化为数据表,可以提升数据的准确性,规避用户线下提交证明材料时篡改数据等风险。

具体地,若各审核结果均表示存在异常信息,数据理算系统102则获取数据表中的异常信息并上报该异常信息,这样可以便于相关人员通过人工介入的方式及时审核该异常信息,若人工审核通过,则可以判定审核通过,进而,还可以基于该审核结果更新审核规则,以提升审核规则的合理性、准确性。

对于客户端103来说,用于获取目标保险理算结果并展示目标保险理算结果。

具体的,用户可以在客户端103随时查询已触发的医疗环节对应的保险理算结果,通过触发理算查询操作,可以为用户展示保险理算结果的可视化界面,具体请参阅图3,图3示意性示出了根据本申请的一个实施例用于展示目标保险理算结果的客户端界面图。如图3所示,可以为用户展示目标保险理算结果300,在目标保险理算结果300中,可以包括医疗项目:挂号、科室:XXX、医生:张三、费用总额:¥16、医保承担费用:¥5、商保承担费用:¥10、个人承担费用:¥1。此外,可选的,在实际应用过程中,目标保险理算结果300中还可以包含其他一种或多种医疗信息或是删减图3所示的一种或多种信息,本申请实施例不作限定。

在本申请的一种可选的实施例中,其中:客户端103,还用于响应于多环节数据请求,获取包含当前医疗环节在内的各个已触发的医疗环节分别对应的医疗数据并展示各医疗数据。这样可以基于即时性的保险理算,方便用户对任一已触发的医疗环节的保险理算结果进行随时查询,用户可以根据查询到的保险理算结果变更医疗决策(如,更换等级更低价格更便宜的门诊医生、在院外购药等),可以有利于改善用户的就诊体验。

具体地,客户端103展示各医疗数据的方式可以为:客户端103按照各医疗数据对应的医疗环节顺序对各医疗数据进行排列,得到数据序列并展示该数据序列,这样可以便于用户了解到各医疗数据的生成顺序。

请参阅图2,图2示意性示出了根据本申请的另一个实施例的自动化理算系统的架构图。如图2所示,自动化理算系统200中可以包括医院数据系统201、数据理算系统202、客户端203、业务理赔系统204。

医院数据系统201,用于基于用户信息生成当前医疗环节对应的医疗数据,并将医疗数据发送至数据理算系统202。

数据理算系统202,用于获取用户信息对应的保险数据,并根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用。

客户端203,用于获取目标保险理算结果并展示目标保险理算结果。

业务理赔系统204,用于响应于医疗结束指令,根据各医疗环节对应的保险理算结果生成医疗订单,并向客户端203发送医疗订单;其中,各医疗环节包括当前医疗环节。

应用图2所示的自动化理算系统,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。以及,可以便于用于针对医疗订单进行一次性付款,无需在各医疗环节前进行分次缴费,节约了医疗流程,提升了医疗服务获取效率。

下面,对于本示例实施方式的上述步骤进行更加详细的说明。

对于业务理赔系统204来说,可以响应于医疗结束指令,根据各医疗环节对应的保险理算结果生成医疗订单,并向客户端203发送医疗订单;其中,各医疗环节包括当前医疗环节。

其中,目标保险理算结果可以特指当前医疗环节对应的保险理算结果,业务理赔系统204可以将各医疗环节对应的保险理算结果进行存储,以便在接收到医疗结束指令之后,通过读取各医疗环节对应的保险理算结果生成医疗订单,医疗订单可以包括医保、商保、个人分别需要负担的医疗费用,医疗订单可以展示于客户端的可视化界面。

在本申请的一种可选的实施例中,业务理赔系统204,用于根据各医疗环节对应的保险理算结果生成医疗订单,包括:业务理赔系统204,用于将各保险理算结果中的医保分担费用进行求和,得到医保分担费用总和;将各保险理算结果中的商保分担费用进行求和,得到商保分担费用总和;将各保险理算结果中的用户分担费用进行求和,得到用户分担费用总和;业务理赔系统204,用于生成包含医保分担费用总和、商保分担费用总和、用户分担费用总和的医疗订单。这样可以为用户直接计算出医疗全流程对应的医保分担费用总和、商保分担费用总和、用户分担费用总和,通过浏览医疗订单,用户可以直观地了解到医保分担费用总和、商保分担费用总和、用户分担费用总和,并可以针对用户分担费用总和进行一次性付款,无需在各医疗环节前进行分次缴费,节约了医疗流程,提升了医疗服务获取效率。

举例来说,若保险理算结果A包括:医保分担费用为10、商保分担费用为5、用户分担费用为3;保险理算结果B包括:医保分担费用为100、商保分担费用为50、用户分担费用为10;保险理算结果C包括:医保分担费用为20、商保分担费用为10、用户分担费用为1。那么,医保分担费用总和=10+100+20=130,商保分担费用总和=5+50+10=65,用户分担费用总和=3+10+1=14。

在本申请的一种可选的实施例中,其中:客户端203,还用于响应于针对医疗订单的支付操作,基于医疗订单执行扣款操作。这样可以实现“一键式”医疗费用支付,无需在各医疗环节前进行分次缴费,节约了医疗流程,提升了医疗服务获取效率。

具体的,客户端展示的医疗订单可以请参阅图4,图4示意性示出了根据本申请的一个实施例用于展示医疗订单的客户端界面图。如图4所示,医疗订单中可以包括综合理算结果410、分账计算详情展示区域420、应支付的金额(如¥10)、支付控件430;其中,综合理算结果410可以包括本次医疗费用总额:100、医保承担费用:¥40、商保承担费用:¥50、个人承担费用:¥10。分账计算详情展示区域420可以用于向用户展示商保承担费用的计算过程以及个人承担费用的计算过程,方便用户了解保险理算详情。

在本申请的一种可选的实施例中,其中:业务理赔系统204,还用于获取对应于用户信息的历史医疗订单,并根据医疗订单和历史医疗订单生成赔付情况统计表;响应于统计表获取请求,将赔付情况统计表发送至客户端203。这样可以便于用户了解到相关自身的赔付情况统计表,提升了与用户之间的交互性,丰富了提供给用户的信息,便于改善用户体验。

具体地,业务理赔系统204可以基于存储对应于各用户的历史医疗订单,获取与该用户信息对应的历史医疗订单,基于该历史医疗订单和本次的医疗订单可以生成赔付情况统计表,赔付情况统计表可以包含文本、图像、表格、图表等形式的信息;其中,用户信息对应的历史医疗订单可以为单位时间(如,1年)内的历史医疗订单,也可以为所有的历史医疗订单。

此外,上述的客户端203可以为用户的终端设备也可以为企业的终端设备,即,赔付情况统计表可以发送给用户本人也可以发送给用户(即,职工)所在的企业,以便企业对用户的健康情况进行分析,进而可以便于企业对未办理商业保险的员工选择相应的商业保险,或者便于企业对下一年度的员工商业保险进行选择。此外,赔付情况统计表也可以方便保险公司分析保险的赔付率等数据。

基于此,业务理赔系统204,还可以用于周期性地获取与目标企业相关的职工历史医疗订单,基于各职工历史医疗订单生成企业赔付情况统计表,并将企业赔付情况统计表发送至对应的企业客户端。

请参阅图5,图5示意性示出了根据本申请的一个实施例的自动化理算系统的序列图。如图5所示,该序列图可以包括如下步骤:步骤S510~步骤S528。

步骤S510:医院数据系统,基于用户信息生成当前医疗环节对应的医疗数据。

步骤S512:医院数据系统,基于用户信息生成当前医疗环节对应的医疗数据,并将医疗数据发送至数据理算系统。

步骤S514:数据理算系统,对医疗数据进行结构化处理,得到数据表。

步骤S516:数据理算系统,获取数据表中各字段对应的审核规则;根据审核规则审核相应字段中的信息,得到对应于各字段的审核结果;若各审核结果均表示无异常信息,则判定审核通过,并根据保险数据生成对应于数据表的目标保险理算结果。

步骤S518:客户端,获取目标保险理算结果并展示目标保险理算结果。

步骤S520:业务理赔系统,响应于医疗结束指令,根据各医疗环节对应的保险理算结果生成医疗订单;其中,各医疗环节包括当前医疗环节。

步骤S522:业务理赔系统,向客户端发送医疗订单。

步骤S524:客户端,响应于针对医疗订单的支付操作,基于医疗订单执行扣款操作。

步骤S526:业务理赔系统,获取对应于用户信息的历史医疗订单,并根据医疗订单和历史医疗订单生成赔付情况统计表。

步骤S528:业务理赔系统,响应于统计表获取请求,将赔付情况统计表发送至客户端。

需要说明的是,步骤S510~步骤S528与图1~2所示的实施例相对应,针对步骤S510~步骤S528的具体实施方式,请参阅图1~2相关描述,此处不再赘述。

可见,实施图5所示的序列图,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

请参阅图6,图6示意性示出了根据本申请的一个实施例的自动化理算方法的流程图。如图6所示,该自动化理算方法可以包括如下步骤:

步骤S610:获取基于用户信息生成的当前医疗环节的医疗数据。

步骤S620:获取用户信息对应的保险数据。

步骤S630:根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用。

步骤S640:将目标保险理算结果发送至客户端,以使得客户端展示目标保险理算结果。

其中,针对步骤S610~步骤S640的具体实施方式,请参阅针对图1的实施例描述,此处不再赘述。图6所示的步骤S610~步骤S640可以由服务器/终端实现。

可见,实施图6所示的方法,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

请参阅图7,图7示意性示出了根据本申请的一个实施例的自动化理算装置的结构示意图。如图7所示,该自动化理算装置700包括:

数据获取单元701,用于获取基于用户信息生成的当前医疗环节的医疗数据;

数据获取单元702,还用于获取用户信息对应的保险数据;

保险理算单元703,用于根据保险数据生成对应于医疗数据的目标保险理算结果;其中,目标保险理算结果包括医保分担费用、商保分担费用、用户分担费用;

理算结果发送单元704,用于将目标保险理算结果发送至客户端,以使得客户端展示目标保险理算结果。

可见,实施图7所示的装置,可以通过医院数据系统、数据理算系统、客户端之间的交互,实现对于医疗费用的实时理算和展示。其中,与医院数据系统直连的数据理算系统可以及时地获取到当前医疗环节的医疗数据,并据此进行保险理算,以确定出当前医疗环节对应的医保分担费用、商保分担费用、用户分担费用,提升了保险理算的效率,实现了实时分账,从而有利于提升保险理赔的效率。进而,基于上述方式,用户在每个医疗环节都可以及时地获知保险理算结果,提升了与用户之间的信息交互频率,避免信息的滞后性,方便用户基于各个医疗环节的保险理算结果随时变更自身的医疗相关决策。

应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本申请的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

由于本申请的示例实施例的自动化理算装置的各个功能模块与上述自动化理算装置的示例实施例的步骤对应,因此对于本申请装置实施例中未披露的细节,请参照本申请上述的自动化理算装置的实施例。

请参阅图8,图8示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是,图8示出的电子设备的计算机系统800仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示,计算机系统800包括中央处理单元(CPU)801,其可以根据存储在只读存储器(ROM)802中的程序或者从储存部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中,还存储有系统操作所需的各种程序和数据。CPU801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805:包括键盘、鼠标等的输入部分806;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807;包括硬盘等的储存部分808;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器810上,以便于从其上读出的计算机程序根据需要被安装入储存部分808。

特别地,根据本申请的实施例,下文参考流程图描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分809从网络上被下载和安装,和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时,执行本申请的系统、方法和装置中限定的各种功能。

作为另一方面,本申请还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现上述实施例中的方法。

需要说明的是,本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。

附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的单元也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由权利要求指出。

技术分类

06120115631575