CN107909487A - 基于医疗保险的理赔方法、装置及*** - Google Patents

Abstract

本申请公开了一种基于医疗保险的理赔方法、装置及***，涉及保险理赔技术领域，可以提高医疗保险的理赔效率。所述方法包括：当保险公司服务器接收到医院方客户端发送的理赔请求时，获取所述理赔请求中携带的待理赔用户的医疗账单信息；及查询所述待理赔用户的保单信息；根据所述保单信息和所述医疗账单信息，检测所述待理赔用户是否符合预定直结条件；若是，则根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，确定所述待理赔用户对应的理赔金额，并按照所述理赔金额进行相应的直结理赔操作。本申请适用于医疗保险的理赔。

Description

基于医疗保险的理赔方法、装置及***

技术领域

本申请涉及保险理赔技术领域，特别是涉及一种基于医疗保险的理赔方法、装置及***。

背景技术

随着社会的发展，医疗保险对人们越来越重要。医疗保险是为补偿疾病所带来的医疗费用的一种保险，职工因疾病、负伤、生育时，由社会或企业提供必要的医疗服务或物质帮助的社会保险。

目前对于已购买医疗保险的用户，在该用户去医院就诊时，需要先支付给医院相关的诊疗费用，然后才能就诊看病，事后凭借医院返回的已缴费的费用账单去保险公司进行理赔。

然而，上述这种医疗保险的理赔方式对于用户而言比较繁琐，需要用户去保险公司进行理赔结算，会耗费用户过多的时间，进而会影响医疗保险的理赔效率，从而影响了用户的体验。

发明内容

有鉴于此，本申请提供了一种基于医疗保险的理赔方法、装置及***，主要目的在于解决目前传统的医疗保险的理赔方式对于用户而言比较繁琐，会耗费用户过多的时间，进而会影响医疗保险的理赔效率，从而影响了用户的体验的问题。

依据本申请一个方面，提供了一种基于医疗保险的理赔方法，该方法包括：

当保险公司服务器接收到医院方客户端发送的理赔请求时，获取所述理赔请求中携带的待理赔用户的医疗账单信息；及

查询所述待理赔用户的保单信息；

根据所述保单信息和所述医疗账单信息，检测所述待理赔用户是否符合预定直结条件；

若是，则根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，确定所述待理赔用户对应的理赔金额，并按照所述理赔金额进行相应的直结理赔操作。

依据本申请另一个方面，提供了一种基于医疗保险的理赔装置，该装置包括：

获取单元，用于当保险公司服务器接收到医院方客户端发送的理赔请求时，获取所述理赔请求中携带的待理赔用户的医疗账单信息；

查询单元，用于查询所述待理赔用户的保单信息；

检测单元，用于根据所述获取单元获取的保单信息和所述查询单元查询到的医疗账单信息，检测所述待理赔用户是否符合预定直结条件；

理赔单元，用于若检测单元检测出所述待理赔用户符合预定直结条件，则根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，确定所述待理赔用户对应的理赔金额，并按照所述理赔金额进行相应的直结理赔操作。

依据本申请又一个方面，提供了一种基于医疗保险的理赔***，包括保险公司服务器和医院方客户端；

所述医院方客户端，用于获取用户的医疗账单信息；根据所述医疗账单信息中的用户标识，查询所述用户是否已经参保医疗保险；若是，则将所述用户确定为待理赔用户，并向所述保险公司服务器发送携带有所述待理赔用户医疗账单信息的理赔请求；

所述保险公司服务器，用于在根据所述待理赔用户的保单信息和所述医疗账单信息，确定所述待理赔用户符合预定直结条件后，按照所述待理赔用户对应的理赔金额进行相应的直结理赔操作。

依据本申请再一个方面，提供了一种存储设备，其上存储有计算机程序，所述程序被处理器执行时实现上述基于医疗保险的理赔方法。

依据本申请再一个方面，提供了一种基于医疗保险理赔的实体装置，包括存储设备、处理器及存储在存储设备上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述基于医疗保险的理赔方法。

借由上述技术方案，本申请提供的一种基于医疗保险的理赔方法、装置及***，与目前传统的医疗保险的理赔方式相比，本申请可以由医院方客户端将待理赔用户的医疗账单信息发送给保险公司服务器，使得保险公司服务器在根据该待理赔用户的保单信息和医疗账单信息，确定该待理赔用户符合预定直结条件后，直接按照待理赔用户对应的理赔金额进行相应的直结理赔操作，无需待理赔用户再去保险公司进行理赔核算，节省了保险理赔结算时间，提高了医疗保险的理赔效率，增强了用户的体验。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请实施例提供的一种基于医疗保险的理赔方法流程示意图；

图2示出了本申请实施例提供的一种基于医疗保险的理赔装置的结构示意图；

图3示出了本申请实施例提供的另一种基于医疗保险的理赔装置的结构示意图；

图4示出了本申请实施例提供的另一种基于医疗保险的理赔***结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供了一种基于医疗保险的理赔方法，可以应用于保险公司方，实现提高医疗保险的理赔效率，如图1所示，该方法包括：

101、当保险公司服务器接收到医院方客户端发送的理赔请求时，获取理赔请求中携带的待理赔用户的医疗账单信息，以及查询待理赔用户的保单信息。

其中，医疗账单信息中包含待理赔用户的用户个人信息(如年龄、性别、身份证号、工作单位等)、需要缴纳的各项费用信息(如费用名称、费用金额等)、待理赔用户治疗所在的医疗机构信息(如医疗机构代码、医院或诊所名称等)等内容。保单信息中包含保单标识信息(如保单编号、名称等)、保单险种信息、保单类型信息(如个人寿险、团险等)、保单投保金额信息、保单责任明细信息(如各项费用的理赔比例、理赔范围、理赔限额、理赔条件等)等内容。

在本申请实施例中，在用户确认直结理赔的前提下，在医院方生成该用户的医疗账单信息后，可以发送给医院方客户端，医院方客户端在判断该用户已经参保医疗保险时，确定该用户为待理赔用户，并查询该待理赔用户参保保险公司的通信地址，例如保险公司方相关医疗保险理赔处理网站的统一资源定位符(Uniform Resource Locator，URL)地址、服务器的互联网协议地址(Internet Protocol Address，IP)等，在查询到该通信地址后，可以向与该通信地址对应的保险公司服务器发送该待理赔用户的理赔请求。而对于本申请实施例的执行主体可以为用于处理医疗保险快捷理赔业务的服务器或装置，用于实现根据待理赔用户的保单信息和医疗账单信息进行待理赔用户的快速保险理赔结算。

102、根据查询到的保单信息和获取到的医疗账单信息，检测待理赔用户是否符合预定直结条件。

其中，预定直结条件可以根据实际需求预先进行设定。例如，根据待理赔用户的保单信息，查询该用户是否购买医疗保险产品，该医疗保险产品是否为支持直结服务的保险产品，该用户是否为直结理赔黑名单用户，且需要理赔的数额是否超过该保险产品的最大理赔限额，以及该用户治疗的医疗机构是否在可直结理赔医疗机构的范围内；若该用户购买了医疗保险产品、且该医疗保险产品支持直结服务、且该用户不是直结理赔黑名单用户、且需要理赔的数额没有超过该医疗保险产品的最大理赔限额，则说明该用户符合预定直结条件。

103、若待理赔用户符合预定直结条件，则根据获取到的医疗账单信息中的账单明细，和查询到的保单信息中与账单明细对应的理赔限额和理赔比例，确定待理赔用户对应的理赔金额，并按照理赔金额进行相应的直结理赔操作。

例如，待理赔用户的医疗账单信息中包含住院医疗费、住院床位费、住院手术费，查询该用户的医疗保单中对这三项费用的责任明细，找到这三项费用的理赔比例和理赔限额，最后计算出该用户对应的理赔金额，并按照该理赔金额，将该用户的医疗保险理赔费用打进医院账户，以便完成该用户医疗账单信息的理赔直结操作，如果理赔费用小于账单费用，则该用户需要补齐差额，进而实现医疗账单费用缴纳。

本申请实施例提供的一种基于医疗保险的理赔方法，与传统的医疗保险的理赔方式相比，本申请实施例无需待理赔用户再去保险公司进行理赔核算，节省了保险理赔结算时间，提高了医疗保险的理赔效率，这样用户可以无需预先支付、或部分支付给医院相关的治疗费用，就可以实现就诊看病，极大的增强了用户的体验。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了说明步骤102的具体实施过程，在本申请的一个可选实施例中，步骤102具体可以包括：根据查询到的保单信息，查询待理赔用户购买的医疗保险产品信息，并检测查询到的医疗保险产品信息是否支持预置直结服务；和/或根据获取到的医疗账单信息中的账单明细，和查询到的保单信息中与账单明细对应的理赔限额和理赔比例，检测需要理赔的金额是否大于保险产品信息的最大理赔限额；和/或检测待理赔用户是否为预置直结理赔黑名单用户；和/或检测待理赔用户在预定时间段内的保险理赔次数是否大于预置次数阈值。

当医疗保险产品信息支持预置直结服务、和/或需要理赔的金额小于或等于保险产品信息的最大理赔限额、和/或待理赔用户不是预置直结理赔黑名单用户、和/或保险理赔次数小于预置次数阈值，确定待理赔用户符合预定直结条件。

例如，保险公司方规定只有少数高端医疗保险产品才支持预置直结服务，保险公司服务器根据待理赔用户保单的保单编号，可以查询该用户购买的医疗保险产品是否属于这少数高端医疗保险产品中的一种，在该医疗保险产品支持预置直结服务的前提下，才能进行后续的直结理赔操作，保险公司还可以规定一些安全性较高的、复杂度较小的医疗保险产品支持预置直结服务等，具体可以根据保险公司的业务需求而定；保险公司服务器还可以根据医疗账单信息中的账单明细，和保单信息中与该账单明细对应的理赔限额和理赔比例，计算每项账单费用需要赔付多少，最后相加得到需要理赔的总金额，判断该总金额是否大于该用户购买的医疗保险产品的最大理赔限额，在该总金额小于或等于该最大理赔限额时，才能进行后续的直结理赔操作，每个医疗保险产品的最大理赔限额可以根据保单内容进行设定。

再例如，为了保证直结理赔操作的安全性，降低保险公司的直结理赔风险，可以预先将一些存在违规记录的、之前存在骗保等行为的用户信息保存在直结理赔黑名单中，在检测待理赔用户是否符合预定直结条件时，可以判断该用户是否为直结理赔黑名单用户，如果是黑名单用户，说明对该用户进行直结理赔操作会存在很大风险，进而确定该用户不符合预定直结条件；如果不是黑名单用户，但是该用户在最近半个月的时间里，存在较多次的保险理赔操作，具体可以包括直结理赔操作和/或其他普通保险理赔操作等，说明该用户最近经常进行保险理赔，可能是骗保用户，为了保证直结理赔操作的安全性，可以确定该用户不符合预定直结条件。

需要说明的是，除了上述可选实施例给出的步骤102的具体实施过程以外，还可以结合待理赔用户的保单险种、保单类型、保单投保金额等因素，综合判别该用户是否符合预定直结条件，具体可以根据保险公司的业务需求进行设定。

为了进一步保证直结理赔操作的安全性，在本申请的一个可选实施例中，步骤102具体还可以包括：获取待理赔用户的信用评估信息；根据获取的信用评估信息，检测待理赔用户的信用评分是否大于或等于预定评分阈值，和/或该待理赔用户的信用评估等级是否大于或等于预定等级阈值；当该用户的信用评分小于预定评分阈值、和/或信用评估等级小于预定等级阈值时，确定待理赔用户不符合预定直结条件。其中，预定评分阈值和预定等级阈值可以根据业务实际的安全等级情况进行设定。

在本可选实施例中，对于一些信用情况不好的、信用度较差的待理赔用户，保险公司对其执行保险直结理赔操作，会存在一定的风险，因此可以确定该用户不符合预定直结条件。

进一步的，为了获取得到更加准确、更加全面的待理赔用户信用评估信息，上述获取待理赔用户的信用评估信息的步骤具体可以包括：通过查询外部***，获取待理赔用户的信用评估信息，其中外部***中包含预先分析得到的不同用户分别对应的信用评估信息；或依据待理赔用户在多个消费领域分别对应的理赔记录，确定待理赔用户的信用评估信息。

例如，外部***根据用户在不同保险公司的历史保险理赔情况，综合评定用户的信用评估信息，具体可以根据用户在不同保险公司分别对应的信用评分进行加权求和，再取平均值得到该用户的信用评估信息，每个保险公司的权重可以根据实际需求进行设定。

再例如，还可以根据待理赔用户在网络购物、实体店购物、电视购物等的保险理赔记录，分析得到该用户的信用评估信息，如若用户经常进行网购保险理赔、运费险赔偿、实体店购物商品赔偿等，可以确定该用户的信用度较低。

为了加快保险公司服务器对理赔请求的处理进度，在本申请的一个可选实施例中，在获取理赔请求中的医疗账单信息和查询相应保单信息之前，还可以包括：查询医院方客户端相应的医院方是否已与保险公司签订预定直结服务协议；若医院方未与保险公司签订预定直结服务协议，则向医院方客户端发送理赔请求失败响应信息；若医院方已与保险公司签订预定直结服务协议，则再获取理赔请求中的医疗账单信息和查询相应保单信息。

在本实施例中，保险公司会和医院签订直结服务协议，在签署协议之后保险公司才能后续进行相应的直结理赔操作。例如，在保险公司服务器接收到医院方客户端发送的理赔请求时，可以首先查询医院方客户端相应的医院方是否已与保险公司签订预定直结服务协议，如果没有签约直结服务协议，可以直接向医院方客户端发送理赔请求失败响应信息，通知其理赔请求失败；如果有签约直结服务协议，再进行后续操作。通过这种方式可以加快保险公司服务器对理赔请求的处理进度，对于一些不符合要求的理赔请求直接进行过滤，减轻保险公司服务器的负担，缓解相应的请求处理压力。

进一步的，为了及时发现直结理赔操作错误的理赔案件，在本申请的一个可选实施例中，在步骤103之后，还可以包括：按照预定时间间隔对已完成直结理赔操作的理赔案件进行核算；记录存在异常的理赔案件的相关信息，并执行费用追讨或费用补偿的相关操作。其中，预定时间间隔可以根据实际需求进行设定，例如每日对当天已完成直结理赔操作的理赔案件进行核算，筛查到理赔金额计算有误的理赔案件，如果理赔金额大于账单金额，后续可以由保险公司或者医院向用户进行费用追讨，以防止保险公司的经济利益收到损失；如果理赔金额小于账单金额，后续可以向用户进行费用补偿，以保证用户的利益。

进一步的，为了发现存在直结理赔操作失败的理赔案件，以便工作人员及时进行解决，避免待理赔用户的理赔处理进度受到影响，在本申请的一个可选实施例中，步骤103之后，还可以包括：统计直结理赔操作失败的理赔案件的相关信息；根据理赔维护模块的通信方式信息，实时将所述直结理赔操作失败的理赔案件的相关信息推送给理赔维护模块。其中，理赔案件的相关信息可以包含理赔案件编号、理赔内容、用户医疗账单信息、用户保单信息、理赔操作失败原因等；理赔维护模块可以为根据理赔案件的相关信息进行分析得到解决直结理赔操作失败的单元模块，具体处理过程可以参见现有技术中的处理方式，在此不再赘述；通信方式信息可以包含理赔维护模块的电子邮箱(Electronic MAIL，E-mail)地址、IP地址、电话号码、即时通信工具的账号等。

在本实施例中，在理赔案件发生理赔操作失败时，可以将该理赔案件的相关信息及时推送给理赔维护模块进行处理，以便及时对其进行解决，保证医疗保险的理赔效率。

进一步的，作为图1所述方法的具体实现，本申请实施例提供了一种基于医疗保险的理赔装置，如图2所示，所述装置包括：获取单元21、查询单元22、检测单元23、理赔单元24。

获取单元21，可以用于当保险公司服务器接收到医院方客户端发送的理赔请求时，获取所述理赔请求中携带的待理赔用户的医疗账单信息；

查询单元22，可以用于查询所述待理赔用户的保单信息；

检测单元23，可以用于根据所述获取单元21获取的保单信息和所述查询单元22查询到的医疗账单信息，检测所述待理赔用户是否符合预定直结条件；

理赔单元24，可以用于若检测单元23检测出所述待理赔用户符合预定直结条件，则根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，确定所述待理赔用户对应的理赔金额，并按照所述理赔金额进行相应的直结理赔操作。

在具体的应用场景中，为了保证直结理赔操作的安全性，降低保险公司的直结理赔风险，如图3所示，检测单元23具体可以包括：检测模块231、确定模块232；

检测模块231，可以用于根据所述保单信息，查询所述待理赔用户购买的医疗保险产品信息，并检测所述医疗保险产品信息是否支持预置直结服务；和/或根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，检测需要理赔的金额是否大于所述医疗保险产品信息的最大理赔限额；和/或检测所述待理赔用户是否为预置直结理赔黑名单用户；和/或检测所述待理赔用户在预定时间段内的保险理赔次数是否大于预置次数阈值；

确定模块232，可以用于当所述医疗保险产品信息支持预置直结服务、和/或所述需要理赔的金额小于或等于所述医疗保险产品信息的最大理赔限额、和/或所述待理赔用户不是预置直结理赔黑名单用户、和/或所述保险理赔次数小于所述预置次数阈值，确定所述待理赔用户符合预定直结条件。

在具体的应用场景中，为了进一步保证直结理赔操作的安全性，如图3所示，检测单元23具体还包括：获取模块233；

获取模块233，可以用于获取所述待理赔用户的信用评估信息；

检测模块231，可以用于根据所述信用评估信息，检测所述待理赔用户的信用评分是否大于或等于预定评分阈值，和/或所述待理赔用户的信用评估等级是否大于或等于预定等级阈值；

确定模块232，可以用于当所述信用评分小于所述预定评分阈值、和/或所述信用评估等级小于所述预定等级阈值时，确定所述待理赔用户不符合预定直结条件。

在具体的应用场景中，为了获取得到更加准确、更加全面的待理赔用户信用评估信息，如图3所示，获取模块233，具体可以用于通过查询外部***，获取所述待理赔用户的信用评估信息，所述外部***中包含预先分析得到的不同用户分别对应的信用评估信息；或依据所述待理赔用户在多个消费领域分别对应的保险理赔记录，确定所述待理赔用户的信用评估信息。

在具体的应用场景中，如图3所示，所述装置还包括：发送单元25。

查询单元22，还可以用于查询所述医院方客户端相应的医院方是否已与保险公司签订预定直结服务协议；

发送单元25，可以用于若所述查询单元22查询出医院方未与所述保险公司签订预定直结服务协议，则向所述医院方客户端发送理赔请求失败响应信息；

获取单元21，具体可以用于若所述查询单元22查询出医院方已与所述保险公司签订预定直结服务协议，则获取所述理赔请求中携带的待理赔用户的医疗账单信息。

在具体的应用场景中，为了及时发现直结理赔操作错误的理赔案件，如图3所示，所述装置还包括：核算单元26、记录单元27；

核算单元26，可以用于按照预定时间间隔对已完成直结理赔操作的理赔案件进行核算；

记录单元27，可以用于记录存在异常的理赔案件的相关信息，并执行费用追讨或费用补偿的相关操作。

在具体的应用场景中，如图3所示，所述装置还包括：统计单元28、推送单元29；

统计单元28，可以用于统计直结理赔操作失败的理赔案件的相关信息；

推送单元29，可以用于根据理赔维护模块的通信方式信息，实时将所述直结理赔操作失败的理赔案件的相关信息推送给理赔维护模块。

需要说明的是，本申请实施例提供的一种基于医疗保险的理赔装置所涉及各功能单元的其他相应描述，可以参考图1中的对应描述，在此不再赘述。

基于上述如图1所示方法，相应的，本申请实施例还提供了一种存储设备，其上存储有计算机程序，该程序被处理器执行时实现上述如图1所示的基于医疗保险的理赔方法。

基于上述如图1所示方法和如图2所示虚拟装置的实施例，为了实现上述目的，本申请实施例还提供了一种基于医疗保险理赔的实体装置，该实体装置包括存储设备和处理器；所述存储设备，用于存储计算机程序；所述处理器，用于执行所述计算机程序以实现上述如图1所示的基于医疗保险的理赔方法。

进一步的，基于上述方案，本申请实施例还提供了一种基于医疗保险的理赔***，如图4所示，该***包括：保险公司服务器31、医院方客户端32；

医院方客户端32，可以用于获取用户的医疗账单信息；根据所述医疗账单信息中的用户标识，查询所述用户是否已经参保医疗保险；若是，则将所述用户确定为待理赔用户，并向所述保险公司服务器31发送携带有所述待理赔用户医疗账单信息的理赔请求；例如，医院方客户端可以查询在已投保名单中是否存在该用户的标识(如用户名称、身份证号码等)，其中，该已投保名单中保存有已经参保医疗保险的不同用户分别对应的标识，以及相应的已投保保险产品信息；如果在已投保名单中存在该用户的标识，则确定该用户已经参保医疗保险。

保险公司服务器31，可以用于接收所述医院方客户端发送的所述理赔请求，并在根据所述待理赔用户的保单信息和所述医疗账单信息，确定所述待理赔用户符合预定直结条件后，按照所述待理赔用户对应的理赔金额进行相应的直结理赔操作。

通过应用本申请的技术方案，与传统的医疗保险的理赔方式相比，无需待理赔用户再去保险公司进行理赔核算，节省了保险理赔结算时间，提高了医疗保险的理赔效率，这样用户可以无需预先支付、或部分支付给医院相关的治疗费用，就可以实现就诊看病，极大的增强了用户的体验。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种基于医疗保险的理赔方法，其特征在于，包括：

当保险公司服务器接收到医院方客户端发送的理赔请求时，获取所述理赔请求中携带的待理赔用户的医疗账单信息；及

查询所述待理赔用户的保单信息；

根据所述保单信息和所述医疗账单信息，检测所述待理赔用户是否符合预定直结条件；

若是，则根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，确定所述待理赔用户对应的理赔金额，并按照所述理赔金额进行相应的直结理赔操作。

2.根据权利要求1所述的方法，其特征在于，所述根据所述保单信息和所述医疗账单信息，检测所述待理赔用户是否符合预定直结条件，包括：

根据所述保单信息，查询所述待理赔用户购买的医疗保险产品信息，并检测所述医疗保险产品信息是否支持预置直结服务；和/或

根据所述医疗账单信息中的账单明细，和所述保单信息中与所述账单明细对应的理赔限额和理赔比例，检测需要理赔的金额是否大于所述医疗保险产品信息的最大理赔限额；和/或

检测所述待理赔用户是否为预置直结理赔黑名单用户；和/或

检测所述待理赔用户在预定时间段内的保险理赔次数是否大于预置次数阈值；

当所述医疗保险产品信息支持预置直结服务、和/或所述需要理赔的金额小于或等于所述医疗保险产品信息的最大理赔限额、和/或所述待理赔用户不是预置直结理赔黑名单用户、和/或所述保险理赔次数小于所述预置次数阈值，确定所述待理赔用户符合预定直结条件。

3.根据权利要求2所述的方法，其特征在于，所述根据所述保单信息和所述医疗账单信息，检测所述待理赔用户是否符合预定直结条件，还包括：

获取所述待理赔用户的信用评估信息；

根据所述信用评估信息，检测所述待理赔用户的信用评分是否大于或等于预定评分阈值，和/或所述待理赔用户的信用评估等级是否大于或等于预定等级阈值；

当所述信用评分小于所述预定评分阈值、和/或所述信用评估等级小于所述预定等级阈值时，确定所述待理赔用户不符合预定直结条件。

4.根据权利要求3所述的方法，其特征在于，所述获取所述待理赔用户的信用评估信息，包括：

通过查询外部***，获取所述待理赔用户的信用评估信息，所述外部***中包含预先分析得到的不同用户分别对应的信用评估信息；或

依据所述待理赔用户在多个消费领域分别对应的保险理赔记录，确定所述待理赔用户的信用评估信息。

5.根据权利要求1所述的方法，其特征在于，所述获取所述理赔请求中携带的待理赔用户的医疗账单信息之前，所述方法还包括：

查询所述医院方客户端相应的医院方是否已与保险公司签订预定直结服务协议；

若所述医院方未与所述保险公司签订预定直结服务协议，则向所述医院方客户端发送理赔请求失败响应信息；

所述获取所述理赔请求中携带的待理赔用户的医疗账单信息，包括：

若所述医院方已与所述保险公司签订预定直结服务协议，则获取所述理赔请求中携带的待理赔用户的医疗账单信息。

6.根据权利要求1所述的方法，其特征在于，所述按照所述理赔金额进行相应的直结理赔操作之后，所述方法还包括：

按照预定时间间隔对已完成直结理赔操作的理赔案件进行核算；

记录存在异常的理赔案件的相关信息，并执行费用追讨或费用补偿的相关操作。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述按照所述理赔金额进行相应的直结理赔操作之后，所述方法还包括：

统计直结理赔操作失败的理赔案件的相关信息；

根据理赔维护模块的通信方式信息，实时将所述直结理赔操作失败的理赔案件的相关信息推送给理赔维护模块。

8.一种基于医疗保险的理赔***，其特征在于，包括权利要求1至7中任一项所述的保险公司服务器和医院方客户端；

所述医院方客户端，用于获取用户的医疗账单信息；根据所述医疗账单信息中的用户标识，查询所述用户是否已经参保医疗保险；若是，则将所述用户确定为待理赔用户，并向所述保险公司服务器发送携带有所述待理赔用户医疗账单信息的理赔请求；

所述保险公司服务器，用于接收所述医院方客户端发送的所述理赔请求，并在根据所述待理赔用户的保单信息和所述医疗账单信息，确定所述待理赔用户符合预定直结条件后，按照所述待理赔用户对应的理赔金额进行相应的直结理赔操作。

9.一种存储设备，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至7中任一项所述的基于医疗保险的理赔方法。

10.一种服务器，包括存储设备、处理器及存储在存储设备上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7中任一项所述的基于医疗保险的理赔方法。