健康险信息处理方法和装置与流程

本发明涉及互联网技术领域，特别是涉及一种健康险信息处理方法和装置。

背景技术：

健康险(健康保险)是以被保险人的身体为保险标的，使被保险人在疾病或意外事故所致伤害时发生的费用或损失获得补偿的一种保险。随着经济和社会的发展，人们越来越关注自身的生命安全与健康安全，相应的，健康险也为用户提供更多的保险服务，如包括可为用户在买药后报销药品费用。

传统的方式中，方用户需要使用健康险来报销药品费用时，需要用户携带购买药品的相关凭证(如发票、收据等)进行临柜处理，保险业务人员对用户提供的相关凭证进行审核，审核通过后再给用户提供对应的报销。因此，传统的方法处理效率低下。

技术实现要素：

基于此，有必要针对上述技术问题，提供一种能够提高健康险信息处理效率的健康险信息处理方法和装置。

一种健康险信息处理方法，所述方法包括：接收支付请求，所述支付请求携带用户的健康险标识和支付信息；判断所述支付请求是否符合预设条件，若是，则根据所述支付信息获取对应的支付数额和转入账户；根据所述健康险标识获取对应当前的第一预设数额；判断所述支付数额是否小于或等于所述第一预设数额，若是，则调用第三方支付系统向所述转入账户中转入支付数额；根据所述支付数额和所述当前的第一预设数额确定新的第一预设数额。

在其中一个实施例中，所述支付信息包括支付数额、转入账户、待支付药品的信息和药店的信息；所述判断所述支付请求是否符合预设条件的步骤，包括：判断所述待支付药品是否为预设药品，且所述药店是否为预设药店。

在其中一个实施例中，所述方法还包括：根据所述健康险标识获取用户关 联的终端；获取与所述待支付药品对应的服药方法；向所述终端发送所述服药方法。

在其中一个实施例中，在所述向所述联系方式发送所述服药方法步骤之后，还包括：根据所述服药方法为所述终端创建对应的提示闹钟。

在其中一个实施例中，所述方法还包括：接收退付请求，所述支付请求携带用户的健康险标识和退付信息；判断所述退付信息是否与所述支付信息对应，若是，则根据所述退付信息获取对应的退付数额和转入账户；接收所述转入账户转入的退付数额；根据所述健康险标识获取对应当前的第二预设数额；根据所述退付数额和所述当前的第二预设数额确定新的第二预设数额。

一种健康险信息处理装置，所述装置包括：请求接收模块，用于接收支付请求，所述支付请求携带用户的健康险标识和支付信息；条件判断模块，用于判断所述支付请求是否符合预设条件；信息获取模块，用于当所述条件判断模块的判断结果为是时，根据所述支付信息获取对应的支付数额和转入账户，根据所述健康险标识获取对应当前的第一预设数额；数额判断模块，用于判断所述支付数额是否小于或等于所述第一预设数额；转账模块，用于当所述数额判断模块的判断结果为是时，调用第三方支付系统向所述转入账户中转入支付数额；预设数额确定模块，用于根据所述支付数额和所述当前的第一预设数额确定新的第一预设数额。

在其中一个实施例中，所述支付信息包括支付数额、转入账户、待支付药品的信息和药店的信息；所述条件判断模块还用于判断所述待支付药品是否为预设药品，且所述药店是否为预设药店。

在其中一个实施例中，所述装置还包括：终端获取模块，用于根据所述健康险标识获取用户关联的终端；服药方法获取模块，用于获取与所述待支付药品对应的服药方法；服药方法发送模块，用于向所述终端发送所述服药方法。

在其中一个实施例中，所述装置还包括：提示闹钟创建模块，用于根据所述服药方法为所述终端创建对应的提示闹钟。

在其中一个实施例中，所述请求接收模块还用于接收退付请求，所述支付 请求携带用户的健康险标识和退付信息；所述条件判断模块还用于判断所述退付信息是否与所述支付信息对应；所述信息获取模块还用于在所述条件判断模块判断为是时，根据所述退付信息获取对应的退付数额和转入账户；所述转账模块还用于接收所述转入账户转入的退付数额；所述信息获取模块还用于根据所述健康险标识获取对应当前的第二预设数额；所述预设数额确定模块还用于根据所述退付数额和所述当前的第二预设数额确定新的第二预设数额。

上述健康险信息处理方法和装置，当判断所接收的支付请求符合预设条件时，根据支付信息获取对应的支付数额和转入账户；并根据支付请求携带的健康险标识获取对应当前的第一预设数额；然后判断支付数额小于或等于第一预设数额时，则调用第三方支付系统向转入账户中转入支付数额；再根据支付数额和当前的第一预设数额确定新的第一预设数额。使得可自动化地完成对健康险购买物品的报销，从而无需人工审核，提高了健康险信息处理效率。

附图说明

图1为一个实施例中健康险信息处理方法的应用环境示意图；

图2为一个实施例中健康险信息处理方法的流程示意图；

图3为一个实施例中健康险信息处理方法中退付的步骤的流程示意图；

图4为一个实施例中健康险信息处理方法中服药方法发送的步骤的流程图；

图5为一个实施例中健康险信息处理装置的结构框图；

图6为另一个实施例中健康险信息处理装置的结构框图；

图7为又一个实施例中健康险信息处理装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例所提供的健康险信息处理方法看而应用于如图1所示的应用 场景中。参考图1所示，第一终端100为健康险用户所使用的终端，可为携带用户健康险信息的健康卡。第二终端200为药品提供方所使用的终端，通常为药店的工作人员所使用的终端，该第二终端200可以是但不限于是个人计算机、笔记本电脑、平板电脑、智能手机、可穿戴式智能设备等。第一服务器300为用于与处理健康险信息相关的服务器，可为与健康险用户对应的保险公司的服务器。第二服务器400为可执行转账等交易信息的服务器，可为银行服务器。

其中，当健康险用户使用第一终端100在药品提供方进行购买药品时，可将所获取的药品信息和药品提供方的信息通过网络传输给第一服务器300。第一服务器300可通过网络或相关的接口与第二服务器400进行通信，向其发送转账信息，如可向其发送向第二终端转入任意数额的金额。第二服务器400通过网络接收第一服务器300所发送的转账信息，完成该转账请求中所携带的转账要求。

在一个实施例中，如图2所示，提供了一种健康险信息处理方法，该方法以应用于图1中的第一服务器进行举例说明，包括下述步骤202～216。

步骤202，接收支付请求。

本实施例中，支付请求携带用户的健康险标识和支付信息。其中，用户的健康险标识用户唯一确定用户的健康险信息。该健康险标识可为用户的健康险账号，或与用户的健康险匹配的健康卡的卡号，或者为第一服务器为用户分配的具有唯一性的编号，或者为用户健康险的登录账号或身份证号等。第一服务器可通过该健康险标识查询并获取到用户的健康险信息。用户的健康险信息包括用户的个人信息以及用户健康险的保号、保费、当前健康险的有效期限、赔付信息以及与健康险关联的保险账号等。用户的个人信息包括用户的姓名、年龄、健康信息、联系方式等。

支付信息为用户使用健康卡进行消费需要进行的支付信息。具体的，可为用户使用健康卡在药店买药时，使用健康卡支付所购买的待支付药品的支付信息。该支付信息包括支付数额、转入账户、待支付药品的信息和药店的信息。用户可通过该健康卡与药店终端进行交易行为，生成支付请求，该支付请求中携带用户的保险标识和支付信息。并被发送到保险公司的第一服务器。第一服 务器通过接收该支付请求，并获取其中所携带的用户的健康险标识和支付信息。

步骤204，判断支付请求是否符合预设条件，若是，则执行步骤206，否则，执行步骤216。

本实施例中，预设条件可以包括预设的药品条件、药店条件以及支付数额条件等一种或多种。即判断该支付的药品是否符合预设要求，购买的待支付药品所在的药店是否符合预设要求，支付的数额是否符合预设要求。若符合预设条件，则执行步骤206，否则，执行步骤216。

在一个实施例中，判断支付请求是否符合预设条件的步骤，包括：判断待支付药品是否为预设药品，且药店是否为预设药店。

具体的，第一服务器中的数据库可预先存储可允许购买的待支付药品信息与药店信息。该药品信息可包括药品名称、药品类别、药品标识码等信息，类似的，药店信息也可包括药店名称以及药店标识码等信息。其中，药品标识码可以是药品的批准文号，通过该药品标识码可查询到对应的药品信息。同样的，药店标识码与用户的身份证号码类似，可通过该药店标识码来唯一确定对应的药店信息。

第一服务器可通过该支付信息获取到对应的药品标识码，并查询对应的数据库中是否存在该药品标识码，若是，则说明该药品为允许购买的待支付药品。第一服务器还该支付信息获取到对应的药店标识码，并查询对应的数据库中是否存在该药店标识码，若是，则说明该药店为允许用户购买药品的药店。当着两者都符合时，则说明该支付请求符合预设条件，执行步骤206，否则，说明不符合预设条件，执行步骤216。

本实施例中，第一服务器通过在相关数据库中预先存储可允许购买的待支付药品信息与药店信息，并判断支付信息中的药品信息和药店信息是否已存储在对应数据库中，可快速判断出该支付请求是否符合预设条件。

进一步的，在一个实施例中，对于药品信息是否符合预设条件的判断，第一服务器可预先设置允许支付的药品类型，如可设置允许支付处方药一类的药品，不允许支付保健类的药品。第一服务器可根据该支付信息获取药品标识码，并通过该药品标识码来获取对应的药品信息。具体的，可通过网络或调用相关 接口连接相关的药品信息查询系统(如国家食品药品监督管理总局)来查询获取对应的药品信息，获取该药品类型，并判断该药品类型是否为预设的可允许使用健康险进行支付的药品类型。

这样，第一服务器可无需预先在数据库中存储可允许购买的待支付药品信息与药店信息，从而可减小第一服务器对存储资源的占用。

步骤206，根据支付信息获取对应的支付数额和转入账户。

本实施例中，用户在药店购买药品时，可相应确定所需支付数额以及转入账户，该支付数额和转入账户同样包含在支付信息中。第一服务器通过该支付信息获取到用户所需支付的数额。

步骤208，根据健康险标识获取对应当前的第一预设数额。

本实施例中，第一预设数额为当前健康险所允许的最大支付数额。该最大支付数额可为健康卡中的余额，随着用户的使用情况而相应改变。

步骤210，判断支付数额是否小于或等于第一预设数额。若是，则执行步骤212，否则，执行步骤216。

本实施例中，第一服务器在根据健康险标识获取到用户的第一预设数额，并根据支付信息获取到对应的支付数额后，比较该支付数额和第一预设数额的大小，判断支付数额是否小于或等于第一预设数额。当判断结果为是，则执行步骤212，否则执行步骤216。

步骤212，调用第三方支付系统向转入账户中转入支付数额。

本实施例中，第三方支付系统为可执行支付命令的系统，如该第三方支付系统可为银行系统，并位于第二服务器中。具体的，第一服务器可调用相关的接口实现与第二服务器之间的通信。并根据该支付请求生成对应的转账指令，将该转账指令发送给第二服务器。该转账指令中包含该支付数额和转入账户，使得第二服务器可根据该转账指令将相应的支付数额转入到该转入账户中，使用户完成对该购买的物品的付款。

步骤214，根据支付数额和当前的第一预设数额确定新的第一预设数额。

本实施例中，当第一服务器在完成用户的支付请求后，可根据该支付数额和当前的第一预设数额确定新的第一预设数额。其中该新的第一预设数额可为 当前的第一预设数额与支付数额之差。

步骤216，不执行支付请求。

当第一服务器在判断该支付请求不符合预设条件或者支付数额大于当前的第一预设数额时，则不执行该支付请求，并可向对应用户提示不执行该支付请求的原因。

本实施例所提供的，健康险信息处理方法，通过上述步骤可自动完成对健康险购买物品的报销，从而无需人工审核，提高了健康险信息处理效率。

在一个实施例中，调用第三方支付系统向转入账户中转入支付数额的步骤，包括：调用第三方支付系统使第二账户向第转入账户中转入支付数额，并确定转账数额，根据预设的转账方式向第二账户转入该转账数额。

本实施例中，第二账户为与第二服务器相关的账户，可为银行账户。第一终端将所生成的转账指令发送给第二终端，使得第二服务器可根据该转账指令从第二账户中扣除对应的支付数额，并将该支付数额转入到该转入账户中。

具体的，第一服务器与第二服务器之间可预先建立转账周期，并根据上一次的转账时间与转账周期确定下一次的转账时间。在检测到当前时间达到该下一次的转账时间，则根据其与第二服务器之间所确定的转账数额，向第二账户支付该转账数额。其中，该转账数额为第一账户与第二账户在上一次的转账时间与下一次的转账时间的期间交易所累计的总的转账数额。

进一步的，第一服务器与第二服务器之间设置预设转账数额，第一服务器实时累计自上一次的转账时间之后，第一账户与第二账户之间的累计转账数额。并判断该累计转账数额是否达到预设转账数额，若是，则将第一账户中的累计转账数额转入第二账户中。

更进一步的，第一服务器可结合转账周期和预设转账数额，根据上一次的转账时间与转账周期确定下一次的预计转账时间，并判断该累计转账数额是否达到预设转账数额，若是，则在当前时间下将第一账户中的累计转账数额转入第二账户中，若在下一次的预计转账时间下的累计转账数额也未达到预设转账数额，则在下一次的预计转账时间下将第一账户中的累计转账数额转入第二账户中。

本实施例中，由于健康险的用户数量众多，因而第一服务器可能会在每时每刻都会接收到大量的用户发送的支付请求，第一服务器通过根据预设的转账方式来向第二账户转入转账数额可降低对支付资源的占用。

在一个实施例中，如图3所示，健康险信息处理方法还包括退付的步骤。

步骤302，接收退付请求。

本实施例中，与支付请求类似，退付请求携带用户的健康险标识和退付信息。退付信息为用户之前使用健康卡进行购买物品后，准备退货时需要提供的退付信息。该退付信息包括退付数额、转入账户、待退付药品的信息和药店的信息。转入账户为用户之前购买该药品时的转入账户，该转入账户在用户进行退付时需要向用户的健康卡转入相应数额。用户可通过该健康卡与药店终端进行交易行为，生成退付请求，该退付请求中携带用户的保险标识和退付信息。并被发送到保险公司的第一服务器。第一服务器通过接收该退付请求，并获取其中所携带的用户的健康险标识和退付信息。

步骤304，判断退付信息是否与支付信息对应，若是，则执行步骤306，否则，执行步骤314。

本实施例中，第一服务器可存储用户的支付请求，并判断该退付请求中的退付的药品与药店是否与用户之前所提交的支付请求中的药品与药店相同。若是则执行下述步骤306，否则，说明该退付请求与支付请求不对应，不允许用户进行退付，执行步骤314。

步骤306，根据退付信息获取对应的退付数额和转入账户。

步骤308，接收转入账户转入的退付数额。

本实施例中，转入账户同样可调用第三方支付系统将该退付数额转入到第一账户中。

具体的，可预先将该退付数额转入第二账户，第一服务器根据该退付数额重新确定在当前时间下，第一账户与第二账户之间的累计转账数。进而确定转账数额，根据预设的转账方式向第二账户转入该转账数额，根据预设的转账方式向第二账户转入该转账数额。

步骤310，根据健康险标识获取对应当前的第二预设数额。

步骤312，根据退付数额和当前的第二预设数额确定新的第二预设数额。

本实施例中，当第一服务器在完成用户的退付请求后，可根据该支付数额和当前的第二预设数额确定新的第二预设数额。其中该新的第二预设数额可为当前的第二预设数额与退付数额之和。

步骤314，不执行退付请求。

当第一服务器在判断该退付请求与支付请求不对应时，则不执行该支付请求，并可向对应用户提示不执行该支付请求的原因。

本实施例中，通过上述退付的步骤还可自动完成对健康险购买物品的退付，从而无需人工审核，提高了健康险信息处理效率。

在一个实施例中，如图4所示，健康险信息处理方法还包括服药方法发送的步骤。

步骤402，根据健康险标识获取用户关联的终端。

第一服务器可根据该健康险标识获取到数据库中所存储的对应用户的联系方式，如用户预先设置的电话号码或及时通信账号等，进而根据该联系方式获取用户的终端。

步骤404，获取与待支付药品对应的服药方法。

本实施例中，第一服务器在获取到用户购买的待支付药品后，可根据待支付药品的信息查询对应的服药方法。其中，服药方法包括药品的服药周期、服药疗程服药数量等。如服药周日可为一日服药一次或两次或三次等，服药数量可为每次服药2粒或1包或20克等。

具体的，第一服务器可根据该待支付药品的药品名称或药品标识码在相关的药品网站上进行自动检索，获取其公布的服药方法。或者，第一服务器中的相关数据库也可在存储可允许购买的待支付药品信息时，进一步存储该药品的服药方法。此时，第一服务器可直接在服务器中读取该服药方法。

步骤406，向终端发送服药方法。

本实施例中，第一服务器可将该服药方法发送至与该联系方式对应的终端，使用户可获知其所购买的药品的服用方法。

以联系方式为手机号码为例进行说明，第一服务器可以短信的形式将该服药方法发送给至该手机号码所在的终端。具体的，第一服务器可将包含该服药方法的信息生成短信息，并采用3gpp或3gpp2或wap等通信协议对所生成的短信息进行打包，生成数据包文件，将该数据包文件通过无线通信方式发送至该联系方式所在的终端。

进一步的，在一个实施例中，健康险信息处理方法还包括：根据服药方法为终端创建对应的提示闹钟。

本实施例中，第一服务器可向用户的终端发送创建提示闹钟的请求，在获取到该终端的允许指令后，可根据服药方法为用户的终端创建对应的提示闹钟，使得该终端在到达提示时间时，开启提示闹钟，并展示对应的服药信息。

本实施例中，第一服务器可根据服药方法确定提示闹钟的提示时间。

举例来说，若该服药方法为每日服药一次，则可创建08:00的提示闹钟，使其在到达08:00时开启。若该服药方法为每日服药两次，则可创建08:00以及18:00的提示闹钟，使其在到达08:00以及18:00时开启相应的提示闹钟。类似的，若该服药方法为每日服药三次，则可创建08:00、12:00以及18:00的提示闹钟，使其在到达08:00、12:00以及18:00时开启相应的提示闹钟。

进一步的，第一服务器还可根据用户所购买的待购买药品的数量确定提示闹钟的提示次数。

具体的，根据待购买药品的数量与服药方法计算需服药的次数，根据需服药的次数与所接收到的支付请求的时间确定所创建的每个提示闹钟的提示次数。

举例来说，第一服务器获取到用户购买了两盒药品a，并获取到每盒药品a的中包含24颗药品a，其对应的服药方法为每日服药两次，则可计算出该用户需服药24次。可创建08:00以及18:00的提示闹钟，再根据所接收到的支付请求的时间以及该需要次数08:00以及18:00的提示闹钟所需提示的次数。如该支付请求的时间在08:00之后，18:00之前，则可确定08:00以及18:00提示闹钟均需开启12次。

具体的，可在终端的展示界面上展示该药品的服药方法。更进一步的，当 用户的支付请求中包含多个药品信息时，终端在该展示界面上展示每个对应需服药的药品的服药方法。

本实施例中，通过根据服药方法来为用户终端创建相应的闹钟，提示用户按时服药，从而可提升用户对健康险的使用体验。

在一个实施例中，如图5所示，提供了一种健康险的信息处理装置，该装置包括：

请求接收模块502，用于接收支付请求，支付请求携带用户的健康险标识和支付信息。

条件判断模块504，用于判断支付请求是否符合预设条件。

信息获取模块506，用于当条件判断模块504的判断结果为是时，根据支付信息获取对应的支付数额和转入账户，根据健康险标识获取对应当前的第一预设数额。

数额判断模块508，用于判断支付数额是否小于或等于第一预设数额。

转账模块510，用于当数额判断模块508的判断结果为是时，调用第三方支付系统向转入账户中转入支付数额。

预设数额确定模块512，用于根据支付数额和当前的第一预设数额确定新的第一预设数额。

在一个实施例中，支付信息包括支付数额、转入账户、待支付药品的信息和药店的信息。

条件判断模块504还用于判断待支付药品是否为预设药品，且药店是否为预设药店。

在一个实施例中，如图6所示，提供了另一种健康险的信息处理装置，该装置还包括：

终端获取模块514，用于根据健康险标识获取用户关联的终端。

服药方法获取模块516，用于获取与待支付药品对应的服药方法。

服药方法发送模块518，用于向终端发送服药方法。

在一个实施例中，如图7所示，提供了又一种健康险的信息处理装置，该 装置还包括：

提示闹钟创建模块520，用于根据服药方法为终端创建对应的提示闹钟。

在一个实施例中，该健康险的信息处理装置还可进行退付信息处理。其中，

请求接收模块502还用于接收退付请求，支付请求携带用户的健康险标识和退付信息；

条件判断模块504还用于判断退付信息是否与支付信息对应；

信息获取模块506还用于在条件判断模块判断为是时，根据退付信息获取对应的退付数额和转入账户；

转账模块510还用于接收转入账户转入的退付数额；

信息获取模块506还用于根据健康险标识获取对应当前的第二预设数额；

预设数额确定模块512还用于根据退付数额和当前的第二预设数额确定新的第二预设数额。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。