CN111222997A - 医疗保险理赔方法、装置、设备及存储介质 - Google Patents

医疗保险理赔方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN111222997A
CN111222997A CN202010009811.3A CN202010009811A CN111222997A CN 111222997 A CN111222997 A CN 111222997A CN 202010009811 A CN202010009811 A CN 202010009811A CN 111222997 A CN111222997 A CN 111222997A
Authority
CN
China
Prior art keywords
user
settlement
medicine
insurance
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010009811.3A
Other languages
English (en)
Inventor
王亚丽
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Taikang Insurance Group Co Ltd
Taikang Online Property Insurance Co Ltd
Original Assignee
Taikang Insurance Group Co Ltd
Taikang Online Property Insurance Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Taikang Insurance Group Co Ltd, Taikang Online Property Insurance Co Ltd filed Critical Taikang Insurance Group Co Ltd
Priority to CN202010009811.3A priority Critical patent/CN111222997A/zh
Publication of CN111222997A publication Critical patent/CN111222997A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请提供一种医疗保险理赔方法、装置、设备及存储介质,所述方法包括:通过获取用户的药品订单信息,并根据药品订单信息判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。进一步地,若确定上述用户所订购的药品属于上述保单信息中的理赔范围,则根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向终端推送支付页面,以便上述用户通过支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,本申请实施例实现了用户在购买药品的过程中就完成了医疗保险的在线实时理赔,理赔程序简单,从而提高了医疗保险的理赔效率。

Description

医疗保险理赔方法、装置、设备及存储介质
技术领域
本申请实施例涉及保险技术领域,尤其涉及一种医疗保险理赔方法、装置、设备及存储介质。
背景技术
随着社会发展,越来越多的用户有医疗保险。医疗保险是为补偿疾病所带来的医疗费用的一种保险。
图1为现有技术提供的医疗保险的理赔流程示意图,如图1所示,现有的医疗保险的理赔流程包括:立案查勘、审核理赔材料、理赔受理和支付理赔款。1)立案查勘:用户在线下就医并购药后,先垫付医药品费用,然后向保险公司提交理赔申请,以便保险公司查询客户的保单,并登记立案。2)审核理赔材料:保险公司接收用户提交的理赔资料以及用于接收理赔款的支付账户信息,然后对理赔资料进行理赔审核,其中,理赔资料可以包括诊断报告、药品处方、购药凭证等。3)理赔受理:保险公司在对理赔资料审核通过后,受理理赔案件,计算理赔款的金额。4)支付理赔款:保险公司向被保险人或受益人支付理赔款。
现有技术提供的医疗保险的理赔流程中,需要客户提交大量的理赔资料用于理赔审核,且理赔程序较繁琐,导致理赔周期较长。
发明内容
本申请实施例提供一种医疗保险理赔方法、装置、设备及存储介质,解决了现有的医疗保险的理赔程序较繁琐,导致理赔周期较长的技术问题。
第一方面,本申请实施例提供一种医疗保险理赔方法,包括:
获取用户的药品订单信息;
根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围;
若确定所述用户所订购的药品属于所述保单信息中的理赔范围,则根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
在一种可能的实现方式中,所述药品订单信息中包括:所述用户所订购的药品信息,所述根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围,包括:
根据预设的药品信息与出险病种之间的映射信息,确定所述用户所订购的药品信息对应的目标出险病种;
根据所述用户所订购的药品信息以及所述目标出险病种,判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围。
在一种可能的实现方式中,所述从终端获取用户的药品订单信息,包括:
接收所述终端发送的理赔申请,其中,所述理赔申请中携带有所述用户对应的用户信息;
根据所述用户信息判断所述用户是否具有理赔权益;
若确定所述用户具有理赔权益,则向所述终端推送药品订购页面,所述药品订购页面用于所述终端提交所述药品订单信息。
在一种可能的实现方式中,所述根据所述用户信息判断所述用户是否具有理赔权益,包括:
根据所述用户信息获取所述用户对应的保单信息和理赔记录信息;
根据所述保单信息和理赔记录信息判断所述用户是否具有理赔权益。
在一种可能的实现方式中,所述根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面之前,所述方法还包括:
根据所述用户对应的保单信息和理赔记录信息,确定所述用户具有理赔权益。
第二方面,本申请实施例提供一种医疗保险理赔方法,包括:
向保险理赔服务器发送理赔申请,其中,所述理赔申请中携带有用户对应的用户信息;
接收所述保险理赔服务器在根据所述用户信息确定所述用户具有理赔权益时,向终端推送的药品订购页面;
通过所述药品订购页面向所述保险理赔服务器提交所述用户的药品订单信息;
接收所述保险理赔服务器在根据所述药品订单信息确定所述用户所订购的药品属于所述用户对应的保单信息中的理赔范围时,根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向所述终端推送的支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
第三方面,本申请实施例提供一种医疗保险理赔装置,包括:
获取模块,用于获取用户的药品订单信息;
判断模块,用于根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围;
推送模块,用于若所述判断模块确定所述用户所订购的药品属于所述保单信息中的理赔范围,则根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
第四方面,本申请实施例提供一种医疗保险理赔装置,包括:
发送模块,用于向保险理赔服务器发送理赔申请,其中,所述理赔申请中携带有用户对应的用户信息;
第一接收模块,用于接收所述保险理赔服务器在根据所述用户信息确定所述用户具有理赔权益时,向终端推送的药品订购页面;
提交模块,用于通过所述药品订购页面向所述保险理赔服务器提交所述用户的药品订单信息;
第二接收模块,用于接收所述保险理赔服务器在根据所述药品订单信息确定所述用户所订购的药品属于所述用户对应的保单信息中的理赔范围时,根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向所述终端推送的支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
第五方面,本申请实施例提供一种电子设备,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行上述第一方面或第二方面的任意实现方式所述的方法。
第六方面,本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述第一方面或第二方面的任意实现方式所述的方法。
本申请实施例提供的医疗保险理赔方法、装置、设备及存储介质,保险理赔服务器通过获取用户的药品订单信息,并根据药品订单信息判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。进一步地,若确定上述用户所订购的药品属于上述保单信息中的理赔范围,则保险理赔服务器根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向终端推送支付页面,以便上述用户通过支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,相对于现有的用户先垫付医药品费用然后提交理赔申请的医疗保险的理赔方式,本申请实施例实现了用户在购买药品的过程中就完成了医疗保险的在线实时理赔,理赔程序简单,从而提高了医疗保险的理赔效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1为现有技术提供的医疗保险的理赔流程示意图;
图2为本申请实施例提供的应用场景示意图;
图3为本申请一实施例提供的医疗保险理赔方法的流程示意图;
图4为本申请另一实施例提供的医疗保险理赔方法的流程示意图;
图5为本申请另一实施例提供的医疗保险理赔方法的流程示意图;
图6为本申请另一实施例提供的医疗保险理赔方法的流程示意图;
图7为本申请一实施例提供的医疗保险理赔装置的结构示意图;
图8为本申请另一实施例提供的医疗保险理赔装置的结构示意图;
图9为本申请实施例提供的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
图2为本申请实施例提供的应用场景示意图。如图1所示,本申请实施例的应用场景示意图中可以包括但不限于:终端、保险理赔服务器和药品订购服务器。应理解,上述保险理赔服务器与药品订购服务器可以为两个服务器,也可以为同一服务器。
当然,本申请实施例的应用场景示意图中还可以包括其它设备,本申请实施例中对此并不作限制。
本申请实施例中,用户可以通过终端向保险理赔服务器发送携带有用户信息的理赔申请,使得上述保险理赔服务器在根据上述用户信息确定上述用户具有理赔权益时向上述终端推送药品订购页面。进一步地,上述终端通过上述药品订购页面向上述保险理赔服务器提交上述用户的药品订单信息。对应地,上述保险理赔服务器在确定出上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围时,根据上述用户对应的理赔余额和上述用户所订购的药品的总价,可以自己向上述终端推送支付页面,或者可以通过药品订购服务器向上述终端推送支付页面,以便上述用户通过上述支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,本申请实施例中实现了医疗保险的在线实时理赔方案,从而解决了现有的医疗保险的理赔程序较繁琐,导致理赔周期较长的技术问题。
本申请实施例中,执行终端侧方法的执行主体可以是终端,也可以是终端中的医疗保险理赔装置(需要说明的是,在本申请提供的实施例中以终端为例进行描述的)。示例性地,本申请实施例中的终端或其中的医疗保险理赔装置,可以通过软件和/或硬件实现。
本申请实施例中涉及的终端可以包括但不限于:手机、平板、电脑,当然,还可以包括具有显示功能的其它设备。
本申请实施例中,执行保险理赔服务器侧方法的执行主体可以是保险理赔服务器,也可以是保险理赔服务器中的医疗保险理赔装置(需要说明的是,在本申请提供的实施例中以保险理赔服务器为例进行描述的)。示例性地,本申请实施例中的保险理赔服务器或其中的医疗保险理赔装置,可以通过软件和/或硬件实现。
本申请实施例中涉及的用户信息可以包括但不限于以下至少一项:用户的姓名、用户的身份证号、用户的账号标识(Identity,ID)。
本申请实施例中涉及的保单信息可以包括但不限于以下至少一项:保单的标识、保单的类别信息、保单的用户信息、保单有效时间、保单的理赔范围、保单的理赔记录信息。
本申请实施例中涉及的有效的保单信息可以包括但不限于:保单信息中的保单有效时间未过期。
本申请实施例中涉及的无效的保单信息可以包括但不限于:保单信息中的保单有效时间已过期。
本申请实施例中涉及的用户对应的理赔记录信息可以是指用户对应的保单信息中所包括的保单的理赔记录信息,其中,保单的理赔记录信息可以包括但不限于以下至少一项:保单可以理赔的总金额、历史理赔金额,和/或,上述保单可以理赔的理赔余额。
本申请实施例中涉及的用户的药品订单信息可以包括但不限于以下至少一项:用户所订购的药品信息、订购时间、用户的账号ID。
本申请实施例中涉及的药品信息可以包括但不限于以下至少一项:药品的名称、药品的种类、药品的规格、药品的价格、药品的数量、药品的性质。
下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图3为本申请一实施例提供的医疗保险理赔方法的流程示意图。本申请实施例中以执行主体为保险理赔服务器为例,对医疗保险理赔方法的可实现方式进行介绍。如图3所示,本申请实施例的方法可以包括:
步骤301、获取用户的药品订单信息。
本申请实施例中,用户可以通过终端向保险理赔服务器提交用户的药品订单信息。示例性地,上述用户可以通过上述终端直接在预设的药品订购页面提交上述用户的药品订单信息,或者,上述用户可以通过上述终端在保险理赔服务器所推送的药品订购页面提交上述用户的药品订单信息。当然,上述用户通过上述终端还可以通过其它方式向保险理赔服务器提交用户的药品订单信息。
本步骤中,保险理赔服务器可以从上述终端获取上述用户的药品订单信息。其中,上述用户的药品订单信息可以包括但不限于以下至少一项:上述用户所订购的药品信息、订购时间、用户的账号ID;上述药品信息可以包括但不限于以下至少一项:药品的名称、药品的种类、药品的规格、药品的价格、药品的数量、药品的性质。
当然,保险理赔服务器还可以通过其它方式获取上述用户的药品订单信息,本申请实施例中对此并不作限定。
步骤S302、根据药品订单信息判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。
本步骤中,保险理赔服务器根据上述步骤301中所获取的药品订单信息,判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。其中,上述保单信息中保单的理赔范围可以包括但不限于:上述保单可以理赔的药品信息和出险病种。
本实施例的下述部分对上述步骤S302的可实现方式进行介绍。
本申请实施例中,保险理赔服务器中可以配置有预设的药品信息与出险病种之间的映射信息。其中,预设的药品信息与出险病种之间的映射信息可以包括:至少一个药品信息和每个药品信息对应的出险病种之间的映射信息。例如,预设的药品信息与出险病种之间的映射信息包括:药品信息1与出险病种1之间的映射信息、药品信息2与出险病种2之间的映射信息、药品信息3与出险病种3之间的映射信息。
一种可能的实现方式,若上述用户的药品订单信息中可以包括:上述用户所订购的药品信息,例如药品信息2,则保险理赔服务器可以根据上述预设的药品信息与出险病种之间的映射信息,确定出上述用户所订购的药品信息(例如药品信息2)对应的目标出险病种,例如出险病种2。
进一步地,保险理赔服务器根据上述用户所订购的药品信息以及目标出险病种,判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。示例性地,若上述理赔范围中所包括的上述保单可以理赔的药品信息包含有上述用户所订购的药品信息,且上述理赔范围中所包括的上述保单可以理赔的出险病种包含有上述目标出险病种,则保险理赔服务器可以确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围。可见,本实现方式中审核了用药规则,可以实现全面、准确地医疗保险审核。
又一示例性地,若上述理赔范围中所包括的上述保单可以理赔的药品信息未包含有上述用户所订购的药品信息,和/或,上述理赔范围中所包括的上述保单可以理赔的出险病种未包含有上述目标出险病种,则保险理赔服务器可以确定上述用户所订购的药品不属于上述用户对应的保单信息中的理赔范围。
另一种可能的实现方式,保险理赔服务器可以判断上述用户的药品订单信息中的药品信息是否属于上述保单可以理赔的药品信息。若上述用户的药品订单信息中的药品信息属于上述保单可以理赔的药品信息,则保险理赔服务器可以确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围。或者,若上述用户的药品订单信息中的药品信息不属于上述保单可以理赔的药品信息,则保险理赔服务器可以确定上述用户所订购的药品不属于上述用户对应的保单信息中的理赔范围。
步骤S303、若确定上述用户所订购的药品属于上述保单信息中的理赔范围,则根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向终端推送支付页面。
本步骤中,若在上述步骤S302中确定上述用户所订购的药品属于上述保单信息中的理赔范围,则保险理赔服务器根据上述用户对应的理赔记录信息中的理赔余额和上述用户所订购的药品的总价,可以自己向上述用户的终端推送支付页面,或者可以通过药品订购服务器向所述终端推送支付页面。其中,上述支付页面用于向上述用户指示此次赔付的理赔金额以及上述用户所需支付的支付金额。
需要说明的是,保险理赔服务器还可以通过其它方式向上述终端推送支付页面。
应理解,保险理赔服务器可以根据上述用户的药品订单信息中的用户的账号ID,查询到上述用户对应的保单信息,其中,保单信息中可以包括有保单的理赔记录信息。另外,保险理赔服务器也可以根据上述用户的药品订单信息中的药品信息,确定出上述用户所订购的药品的总价。
示例性地,若上述用户对应的理赔余额小于上述用户所订购的药品的总价,则保险理赔服务器可以向上述终端推送支付页面。其中,支付页面中显示赔付的理赔金额以及上述用户所需支付的支付金额;理赔金额为上述理赔余额,支付金额为上述用户所订购的药品的总价与上述理赔余额的差值,以便于用户完成支付剩余的上述支付金额。
例如,若上述用户对应的理赔余额为200元,上述用户所订购的药品的总价为300元,则保险理赔服务器可以向上述终端推送支付页面;其中,支付页面中显示赔付的理赔金额为200元以及上述用户所需支付的支付金额为100元。
又一示例性地,若上述用户对应的理赔余额不小于上述用户所订购的药品的总价,则保险理赔服务器可以向上述终端推送支付页面。其中,支付页面中显示赔付的理赔金额以及上述用户所需支付的支付金额;理赔金额为上述用户所订购的药品的总价,支付金额为零元。
例如,若上述用户对应的理赔余额为310元,上述用户所订购的药品的总价为300元,则保险理赔服务器可以向上述终端推送支付页面;其中,支付页面中显示赔付的理赔金额为300元以及上述用户所需支付的支付金额为0元。
本申请实施例中,保险理赔服务器获取用户的药品订单信息,并根据药品订单信息判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。进一步地,若确定上述用户所订购的药品属于上述保单信息中的理赔范围,则保险理赔服务器根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向终端推送支付页面,以便上述用户通过支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,相对于现有的用户先垫付医药品费用然后提交理赔申请的医疗保险的理赔方式,本申请实施例实现了用户在购买药品的过程中就完成了医疗保险的在线实时理赔,理赔程序简单,从而提高了医疗保险的理赔效率。
进一步地,若确定上述用户所订购的药品不属于上述用户对应的保单信息中的理赔范围,则保险理赔服务器可以向上述终端发送理赔审核未通过指示信息,以便于上述用户可以及时获知理赔审核的结果。
进一步地,为了便于查询此次的理赔记录信息,保险理赔服务器还可以关联保存上述用户对应的保单信息、上述药品订单信息,以及上述赔付的理赔金额;当然,还可以关联保存其它信息,例如,上述目标出险病种等。需要说明的是,保险理赔服务器可以将上述信息关联保存到数据库;当然还可以保存到其它位置。
图4为本申请另一实施例提供的医疗保险理赔方法的流程示意图。在上述实施例的基础上,本申请实施例中对上述步骤S301的可实现方式进行介绍。如图4所示,本申请实施例中,上述从终端获取用户的药品订单信息,可以包括:
步骤S401、接收终端发送的理赔申请。
本申请实施例中,上述用户可以通过终端向保险理赔服务器提交理赔申请。示例性地,上述用户可以通过上述终端直接在预设的理赔申请页面提交上述理赔申请,或者,上述用户可以通过上述终端在保险理赔服务器所推送的理赔申请页面提交上述理赔申请。当然,上述用户通过上述终端还可以通过其它方式向保险理赔服务器提交理赔申请。
本步骤中,保险理赔服务器接收上述终端发送的理赔申请,其中,理赔申请中可以携带有上述用户对应的用户信息;用户信息可以包括但不限于以下至少一项:上述用户的姓名、上述用户的身份证号、上述用户的账号ID。
步骤S402、根据上述用户信息判断上述用户是否具有理赔权益。
本步骤中,保险理赔服务器根据上述步骤S401中所获取的用户信息判断上述用户是否具有理赔权益。
可选地,保险理赔服务器可以根据上述用户信息查询到上述用户信息对应的保单信息,其中,上述保单信息中可以包括但不限于:保单的理赔记录信息、保单有效时间。进一步地,保险理赔服务器根据上述用户信息所获取到的上述用户对应的保单信息和理赔记录信息,判断上述用户是否具有理赔权益。
本申请实施例中,保险理赔服务器可以首先判断上述保单信息是否为有效的保单信息。示例性地,保险理赔服务器可以根据上述保单信息中的保单有效时间,判断上述保单信息是否为有效的保单信息。若上述保单信息中的保单有效时间未过期,则保险理赔服务器可以确定上述保单信息为有效的保单信息;或者,若上述保单信息中的保单有效时间已过期,则保险理赔服务器可以确定上述保单信息为无效的保单信息。应理解,若上述保单信息为无效的保单信息,则保险理赔服务器可以确定上述用户不具有理赔权益。
进一步地,若上述保单信息为有效的保单信息,则保险理赔服务器可以根据上述理赔记录信息确定上述用户对应的理赔余额,并进一步判断上述用户对应的理赔余额是否大于预设值,例如0元。若上述用户对应的理赔余额大于上述预设值,则保险理赔服务器可以确定上述用户具有理赔权益;或者,若上述用户对应的理赔余额不大于上述预设值,则保险理赔服务器可以确定上述用户不具有理赔权益。
当然,保险理赔服务器根据上述用户信息,还可以通过其它方式判断上述用户是否具有理赔权益。
步骤S403、若确定上述用户具有理赔权益,则向上述终端推送药品订购页面。
本步骤中,若在上述步骤S402中确定上述用户具有理赔权益,则保险理赔服务器可以自己向上述终端推送药品订购页面,或者可以通过药品订购服务器向上述终端推送药品订购页面,以便于上述用户可以通过上述终端在上述药品订购页面提交上述用户的药品订单信息。
需要说明的是,保险理赔服务器还可以通过其它方式向上述终端推送药品订购页面。
本申请实施例中,保险理赔服务器在接收到终端发送的理赔申请后,根据上述理赔申请中所携带的用户信息判断上述用户是否具有理赔权益。进一步地,保险理赔服务器在确定上述用户具有理赔权益后,向上述终端推送药品订购页面,使得上述用户可以通过上述终端在上述药品订购页面提交上述用户的药品订单信息,以便于保险理赔服务器在根据上述药品订单信息确定上述用户所订购的药品属于上述保单信息中的理赔范围时,可以根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向上述终端推送支付页面。可见,本申请实施例中,保险理赔服务器在根据上述终端提交的理赔申请确定上述用户具有理赔权益时进行医疗保险的实时理赔,从而进一步提高了医疗保险的理赔效率。
进一步地,若在上述步骤S402中确定上述用户不具有理赔权益,则保险理赔服务器可以向上述终端发送理赔申请的拒绝指示信息,用于指示上述用户不具有理赔权益。
应理解,考虑到若保险理赔服务器执行上述步骤S403与执行上述步骤S302的时间间隔较大,则上述用户对应的保单信息和/或理赔记录信息可能会发生变化,导致上述用户是否具有理赔权益的判断结果可能有变化,因此,保险理赔服务器在执行上述步骤S302之前,还可以根据上述用户对应的保单信息和理赔记录信息,再次判断上述用户是否具有理赔权益。上述保险理赔服务器只有在确定上述用户具有理赔权益时,执行上述步骤S302。
同理,考虑到若保险理赔服务器执行上述步骤S403与执行上述步骤S303的时间间隔较大,则上述用户对应的保单信息和/或理赔记录信息可能会发生变化,导致上述用户是否具有理赔权益的判断结果可能有变化,因此,保险理赔服务器在执行上述步骤S303之前,还可以根据上述用户对应的保单信息和理赔记录信息,再次判断上述用户是否具有理赔权益。上述保险理赔服务器只有在确定上述用户具有理赔权益时,执行上述步骤S303。
图5为本申请另一实施例提供的医疗保险理赔方法的流程示意图。在上述实施例的基础上,本申请实施例中以执行主体为终端为例,对上述医疗保险理赔方法的可实现方式进行介绍。如图5所示,本申请实施例的方法可以包括:
步骤S501、向保险理赔服务器发送理赔申请。
本申请实施例中,上述用户可以通过终端向保险理赔服务器提交理赔申请,其中,理赔申请中携带有上述用户对应的用户信息,以便于保险理赔服务器根据上述用户对应的用户信息判断上述用户是否具有理赔权益。
当然,上述理赔申请中还可以携带其它信息,本申请实施例中对此并不做限定。
示例性地,终端可以在通过理赔申请页面接收到上述用户输入的上述理赔申请时,向保险理赔服务器发送上述理赔申请。其中,上述理赔申请页面可以为上述终端中预设的理赔申请页面,例如上述终端中的理赔微信公众号所提供的理赔申请页面;或者可以为保险理赔服务器向上述终端所推送的理赔申请页面。
步骤S502、接收保险理赔服务器在根据上述用户信息确定上述用户具有理赔权益时,向上述终端推送的药品订购页面。
本步骤中,上述终端可以接收保险理赔服务器在根据上述用户信息确定上述用户具有理赔权益时,自己向终端推送的药品订购页面,或者通过药品订购服务器向终端推送的药品订购页面,从而以便于上述用户通过上述终端在上述药品订购页面提交上述用户的药品订单信息。
需要说明的是,保险理赔服务器还可以通过其它方式向上述终端推送上述药品订购页面。
步骤S503、通过上述药品订购页面向上述保险理赔服务器提交上述用户的药品订单信息。
本申请实施例中,上述用户可以通过上述终端在上述药品订购页面输入上述用户的药品订单信息。
本步骤中,上述终端通过上述药品订购页面接收上述用户所输入的上述用户的药品订单信息,然后向上述保险理赔服务器提交上述用户的药品订单信息。
当然,终端还可以通过其它方式,向保险理赔服务器发送上述用户的药品订单信息。
步骤S504、接收保险理赔服务器在根据上述药品订单信息确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围时,根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向上述终端推送的支付页面。
本步骤中,终端可以接收保险理赔服务器在根据上述药品订单信息确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围时,根据上述用户对应的理赔余额和上述用户所订购的药品的总价,自己向终端推送的支付页面,或者通过药品订购服务器向终端推送的支付页面。其中,上述支付页面用于向上述用户指示此次赔付的理赔金额以及上述用户所需支付的支付金额。
示例性地,若上述用户对应的理赔余额小于上述用户所订购的药品的总价,则终端可以接收保险理赔服务器向终端推送的支付页面。其中,支付页面中显示赔付的理赔金额以及上述用户所需支付的支付金额;理赔金额为上述理赔余额,支付金额为上述用户所订购的药品的总价与上述理赔余额的差值。
又一示例性地,若上述用户对应的理赔余额不小于上述用户所订购的药品的总价,则终端可以接收保险理赔服务器向终端推送的支付页面。其中,支付页面中显示赔付的理赔金额以及上述用户所需支付的支付金额;理赔金额为上述用户所订购的药品的总价,支付金额为零元。
本申请实施例中,终端通过向保险理赔服务器发送携带有用户信息的理赔申请,并接收上述保险理赔服务器在根据上述用户信息确定上述用户具有理赔权益时,向上述终端推送的药品订购页面。进一步地,上述终端通过上述药品订购页面向上述保险理赔服务器提交上述用户的药品订单信息。进一步地,终端接收保险理赔服务器在根据上述药品订单信息确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围时,根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向终端推送的支付页面,以便上述用户通过支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,本申请实施例实现了用户在购买药品的过程中就完成了医疗保险的在线实时理赔,理赔程序简单,从而提高了医疗保险的理赔效率。
图6为本申请另一实施例提供的医疗保险理赔方法的流程示意图。在上述实施例的基础上,本申请实施例中结合上述终端和上述保险理赔服务器对上述医疗保险理赔方法的可实现方式进行介绍。如图6所示,本申请实施例的方法可以包括:
步骤S601、终端向保险理赔服务器发送理赔申请;其中,理赔申请中携带有上述用户对应的用户信息。
步骤S602、保险理赔服务器根据上述用户信息判断上述用户是否具有理赔权益。
示例性地,若确定上述用户具有理赔权益,则执行步骤S603;若确定上述用户不具有理赔权益,则执行步骤S604。
步骤S603、保险理赔服务器向上述终端推送药品订购页面。
步骤S604、保险理赔服务器向上述终端发送理赔申请的拒绝指示信息,用于指示上述用户不具有理赔权益,此次理赔过程结束。
步骤S605、上述终端通过上述药品订购页面向上述保险理赔服务器提交上述用户的药品订单信息。
步骤S606、保险理赔服务器根据预设的药品信息与出险病种之间的映射信息,确定出上述用户所订购的药品信息对应的目标出险病种。
步骤S607、保险理赔服务器根据上述用户所订购的药品信息以及目标出险病种,判断上述用户所订购的药品是否属于上述用户对应的保单信息中的理赔范围。
示例性地,若确定上述用户所订购的药品属于上述用户对应的保单信息中的理赔范围,则执行步骤S608;若确定上述用户所订购的药品不属于上述用户对应的保单信息中的理赔范围,则执行步骤S609。
考虑到上述步骤S607的执行时间与上述步骤S602的执行时间间隔较大,上述用户对应的保单信息和/或理赔记录信息可能会发生变化,导致上述用户是否具有理赔权益的判断结果可能有变化。可选地,保险理赔服务器在执行上述步骤S607之前,还可以再次判断上述用户是否具有理赔权益;若确定上述用户仍然具有理赔权益,则继续执行步骤S607;若确定上述用户不具有理赔权益,则执行步骤S604。
步骤S608、保险理赔服务器根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向上述终端推送支付页面,以便于上述用户可以获知此次赔付的理赔金额以及上述用户所需支付的支付金额。
考虑到上述步骤S608的执行时间与上述步骤S602的执行时间间隔较大,上述用户对应的保单信息和/或理赔记录信息可能会发生变化,导致上述用户是否具有理赔权益的判断结果可能有变化。可选地,保险理赔服务器在执行上述步骤S608之前,还可以再次判断上述用户是否具有理赔权益;若确定上述用户仍然具有理赔权益,则继续执行步骤S608;若确定上述用户不具有理赔权益,则执行步骤S604。
步骤S609、保险理赔服务器向上述终端发送理赔审核未通过指示信息,以便于上述用户可以及时获知理赔审核的结果。
本申请实施例中各步骤的实现方式,可以参考本申请上述实施例中的相应内容,此处不再赘述。
综上所述,保险理赔服务器在接收到终端发送的理赔申请后,根据上述理赔申请中所携带的用户信息判断上述用户是否具有理赔权益。进一步地,保险理赔服务器在确定上述用户具有理赔权益后,向上述终端推送药品订购页面,使得上述用户可以通过上述终端在上述药品订购页面提交上述用户的药品订单信息。进一步地,保险理赔服务器在根据上述药品订单信息确定上述用户所订购的药品属于上述保单信息中的理赔范围时,可以根据上述用户对应的理赔余额和上述用户所订购的药品的总价,向上述终端推送支付页面,以便上述用户通过支付页面可以获知赔付的理赔金额以及上述用户所需支付的支付金额。可见,本申请实施例中,保险理赔服务器在根据上述终端提交的理赔申请确定上述用户具有理赔权益时,实现了上述用户在购买药品的过程中就完成了医疗保险的在线实时理赔,从而进一步提高了医疗保险的理赔效率。
图7为本申请一实施例提供的医疗保险理赔装置的结构示意图。可选地,本实施例提供的医疗保险理赔装置可以为上述保险理赔服务器中的装置。如图7所示,本申请实施例提供的医疗保险理赔装置70可以包括:获取模块701、判断模块702和推送模块703。
其中,获取模块701,用于获取用户的药品订单信息;
判断模块702,用于根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围;
推送模块703,用于若所述判断模块702确定所述用户所订购的药品属于所述保单信息中的理赔范围,则根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
在一种可能的实现方式中,所述药品订单信息中包括:所述用户所订购的药品信息,所述判断模块702,包括:
确定单元,用于根据预设的药品信息与出险病种之间的映射信息,确定所述用户所订购的药品信息对应的目标出险病种;
判断单元,用于根据所述用户所订购的药品信息以及所述目标出险病种,判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围。
在一种可能的实现方式中,所述获取模块701,包括:
接收单元,用于接收所述终端发送的理赔申请,其中,所述理赔申请中携带有所述用户对应的用户信息;
判断单元,用于根据所述用户信息判断所述用户是否具有理赔权益;
推送单元,用于若所述判断单元确定所述用户具有理赔权益,则向所述终端推送药品订购页面,所述药品订购页面用于所述终端提交所述药品订单信息。
在一种可能的实现方式中,所述获取模块701中的判断单元具体用于:
根据所述用户信息获取所述用户对应的保单信息和理赔记录信息;
根据所述保单信息和理赔记录信息判断所述用户是否具有理赔权益。
在一种可能的实现方式中,所述推送模块703具体用于:
在根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面之前,根据所述用户对应的保单信息和理赔记录信息,确定所述用户具有理赔权益。
本实施例提供的医疗保险理赔装置70,可以用于执行本申请上述医疗保险理赔方法实施例中关于保险理赔服务器的技术方案,其实现原理和技术效果类似,此处不再赘述。
图8为本申请另一实施例提供的医疗保险理赔装置的结构示意图。可选地,本实施例提供的医疗保险理赔装置可以为上述终端中的装置。如图8所示,本申请实施例提供的医疗保险理赔装置80可以包括:发送模块801、第一接收模块802、提交模块803和第二接收模块804。
其中,发送模块801,用于向保险理赔服务器发送理赔申请,其中,所述理赔申请中携带有用户对应的用户信息;
第一接收模块802,用于接收所述保险理赔服务器在根据所述用户信息确定所述用户具有理赔权益时,向终端推送的药品订购页面;
提交模块803,用于通过所述药品订购页面向所述保险理赔服务器提交所述用户的药品订单信息;
第二接收模块804,用于接收所述保险理赔服务器在根据所述药品订单信息确定所述用户所订购的药品属于所述用户对应的保单信息中的理赔范围时,根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向所述终端推送的支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
本实施例提供的医疗保险理赔装置80,可以用于执行本申请上述医疗保险理赔方法实施例中关于终端的技术方案,其实现原理和技术效果类似,此处不再赘述。
图9为本申请实施例提供的电子设备的结构示意图。本申请实施例中的电子设备可以包括但不限于:终端或者保险理赔服务器。
如图9所示,本申请实施例提供的电子设备90可以包括:处理器901以及存储器902。可选地,所述电子设备90还可以包括收发器903,所述收发器903用于和其他设备通信。
其中,所述存储器902,用于存储所述处理器901的可执行指令;所述处理器901配置为经由执行所述可执行指令来执行本申请上述医疗保险理赔方法实施例中关于保险理赔服务器的技术方案,或者本申请上述医疗保险理赔方法实施例中关于终端的技术方案,其实现原理和技术效果类似,此处不再赘述。
应理解,当本申请实施例中的电子设备90包括保险理赔服务器时,所述处理器901配置为经由执行所述可执行指令来执行本申请上述医疗保险理赔方法实施例中关于保险理赔服务器的技术方案;当本申请实施例中的电子设备90包括终端时,所述处理器901配置为经由执行所述可执行指令来执行本申请上述医疗保险理赔方法实施例中关于终端的技术方案。
本申请实施例还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现本申请上述医疗保险理赔方法实施例中关于保险理赔服务器的技术方案,或本申请上述医疗保险理赔方法实施例中关于终端的技术方案,其实现原理和技术效果类似,此处不再赘述。
本领域普通技术人员可以理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种医疗保险理赔方法,其特征在于,包括:
获取用户的药品订单信息;
根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围;
若确定所述用户所订购的药品属于所述保单信息中的理赔范围,则根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
2.根据权利要求1所述的方法,其特征在于,所述药品订单信息中包括:所述用户所订购的药品信息,所述根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围,包括:
根据预设的药品信息与出险病种之间的映射信息,确定所述用户所订购的药品信息对应的目标出险病种;
根据所述用户所订购的药品信息以及所述目标出险病种,判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围。
3.根据权利要求1或2所述的方法,其特征在于,所述获取用户的药品订单信息,包括:
接收所述终端发送的理赔申请,其中,所述理赔申请中携带有所述用户对应的用户信息;
根据所述用户信息判断所述用户是否具有理赔权益;
若确定所述用户具有理赔权益,则向所述终端推送药品订购页面,所述药品订购页面用于所述终端提交所述药品订单信息。
4.根据权利要求3所述的方法,其特征在于,所述根据所述用户信息判断所述用户是否具有理赔权益,包括:
根据所述用户信息获取所述用户对应的保单信息和理赔记录信息;
根据所述保单信息和理赔记录信息判断所述用户是否具有理赔权益。
5.根据权利要求1或2所述的方法,其特征在于,所述根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面之前,所述方法还包括:
根据所述用户对应的保单信息和理赔记录信息,确定所述用户具有理赔权益。
6.一种医疗保险理赔方法,其特征在于,包括:
向保险理赔服务器发送理赔申请,其中,所述理赔申请中携带有用户对应的用户信息;
接收所述保险理赔服务器在根据所述用户信息确定所述用户具有理赔权益时,向终端推送的药品订购页面;
通过所述药品订购页面向所述保险理赔服务器提交所述用户的药品订单信息;
接收所述保险理赔服务器在根据所述药品订单信息确定所述用户所订购的药品属于所述用户对应的保单信息中的理赔范围时,根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向所述终端推送的支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
7.一种医疗保险理赔装置,其特征在于,包括:
获取模块,用于获取用户的药品订单信息;
判断模块,用于根据所述药品订单信息判断所述用户所订购的药品是否属于所述用户对应的保单信息中的理赔范围;
推送模块,用于若所述判断模块确定所述用户所订购的药品属于所述保单信息中的理赔范围,则根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向终端推送支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
8.一种医疗保险理赔装置,其特征在于,包括:
发送模块,用于向保险理赔服务器发送理赔申请,其中,所述理赔申请中携带有用户对应的用户信息;
第一接收模块,用于接收所述保险理赔服务器在根据所述用户信息确定所述用户具有理赔权益时,向终端推送的药品订购页面;
提交模块,用于通过所述药品订购页面向所述保险理赔服务器提交所述用户的药品订单信息;
第二接收模块,用于接收所述保险理赔服务器在根据所述药品订单信息确定所述用户所订购的药品属于所述用户对应的保单信息中的理赔范围时,根据所述用户对应的理赔余额和所述用户所订购的药品的总价,向所述终端推送的支付页面,其中,所述支付页面用于向所述用户指示赔付的理赔金额以及所述用户所需支付的支付金额。
9.一种电子设备,其特征在于,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行权利要求1-5或者6中任一项所述的方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1-5或者6中任一项所述的方法。
CN202010009811.3A 2020-01-06 2020-01-06 医疗保险理赔方法、装置、设备及存储介质 Pending CN111222997A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010009811.3A CN111222997A (zh) 2020-01-06 2020-01-06 医疗保险理赔方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010009811.3A CN111222997A (zh) 2020-01-06 2020-01-06 医疗保险理赔方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN111222997A true CN111222997A (zh) 2020-06-02

Family

ID=70829243

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010009811.3A Pending CN111222997A (zh) 2020-01-06 2020-01-06 医疗保险理赔方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN111222997A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112508716A (zh) * 2020-11-30 2021-03-16 泰康保险集团股份有限公司 数据管理方法及系统、装置、存储介质及电子终端
CN112581294A (zh) * 2020-12-07 2021-03-30 泰康保险集团股份有限公司 一种理赔和服务权益数据处理方法及装置
CN113409156A (zh) * 2021-07-07 2021-09-17 北京京东拓先科技有限公司 一种数据处理的方法和装置
CN113822765A (zh) * 2021-01-29 2021-12-21 北京京东拓先科技有限公司 数据处理方法、装置、系统、介质及电子设备
CN115022396A (zh) * 2022-06-07 2022-09-06 支付宝(杭州)信息技术有限公司 内容推送方法、装置和服务器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107292597A (zh) * 2017-05-26 2017-10-24 深圳医畅科技发展有限公司 基于社保卡实现就诊支付的方法、移动终端及存储设备
CN107909487A (zh) * 2017-11-10 2018-04-13 平安科技(深圳)有限公司 基于医疗保险的理赔方法、装置及系统
TW201814641A (zh) * 2016-10-06 2018-04-16 國泰人壽保險股份有限公司 電子系統及伺服器
CN109785095A (zh) * 2018-12-13 2019-05-21 平安医疗健康管理股份有限公司 一种医疗费用的结算方法、结算装置和终端设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW201814641A (zh) * 2016-10-06 2018-04-16 國泰人壽保險股份有限公司 電子系統及伺服器
CN107292597A (zh) * 2017-05-26 2017-10-24 深圳医畅科技发展有限公司 基于社保卡实现就诊支付的方法、移动终端及存储设备
CN107909487A (zh) * 2017-11-10 2018-04-13 平安科技(深圳)有限公司 基于医疗保险的理赔方法、装置及系统
CN109785095A (zh) * 2018-12-13 2019-05-21 平安医疗健康管理股份有限公司 一种医疗费用的结算方法、结算装置和终端设备

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112508716A (zh) * 2020-11-30 2021-03-16 泰康保险集团股份有限公司 数据管理方法及系统、装置、存储介质及电子终端
CN112581294A (zh) * 2020-12-07 2021-03-30 泰康保险集团股份有限公司 一种理赔和服务权益数据处理方法及装置
CN113822765A (zh) * 2021-01-29 2021-12-21 北京京东拓先科技有限公司 数据处理方法、装置、系统、介质及电子设备
CN113409156A (zh) * 2021-07-07 2021-09-17 北京京东拓先科技有限公司 一种数据处理的方法和装置
CN113409156B (zh) * 2021-07-07 2024-05-17 北京京东拓先科技有限公司 一种数据处理的方法和装置
CN115022396A (zh) * 2022-06-07 2022-09-06 支付宝(杭州)信息技术有限公司 内容推送方法、装置和服务器

Similar Documents

Publication Publication Date Title
CN111222997A (zh) 医疗保险理赔方法、装置、设备及存储介质
US11763277B2 (en) Systems and methods for a health care e-commerce marketplace
US11790329B2 (en) System for processing retail clinic claims
US8538875B2 (en) Process for linked healthcare and financial transaction initiation
US8515784B2 (en) Systems and methods of processing health care claims over a network
US7346523B1 (en) Processing an insurance claim using electronic versions of supporting documents
US20220189589A1 (en) Highly reliable data transaction system, and highly reliable data transaction method
CN112037903B (zh) 在线问诊开药系统
JP6750156B2 (ja) 患者の医療機関に対する一部負担金債務を医療保険の保険給付金で解消する仕組み
US20200135326A1 (en) Method of facilitating imaging study interpretations between healthcare facilities and physicians
US20160321412A1 (en) Cost, Quality and Distance Based Method and System for Health Care Referrals
US11847678B2 (en) Adjudication and claim payment for selectively redeemable bundled healthcare services
US20240290451A1 (en) Data processing system for processing network data records transmitted from remote, distributed terminal devices
US20080027760A1 (en) Healthcare eligibility and benefits data system
JP4443946B2 (ja) 健康保険等医療保険自己負担分の支払システム及び支払方法
US11501352B2 (en) Backend bundled healthcare services payment systems and methods
US11475499B2 (en) Backend bundled healthcare services payment systems and methods
JP7144495B2 (ja) 支払対象外可能性判定装置、支払対象外可能性判定システム、および支払対象外可能性判定方法
JP2002297911A (ja) 保険金支払システム、保険金支払方法、並びに保険金支払用サーバ
US11915287B2 (en) Backend bundled healthcare services payment systems and methods
US20220300908A1 (en) System and method for claim reimbursement
US12131299B2 (en) System for processing retail clinic claims
JP7418797B2 (ja) 動物診療費精算システム及び動物診療費精算プログラム
US20220005098A1 (en) Cpt code search engine for backend bundling of healthcare services and a virtual payment system
JP2004288142A (ja) 健康保険等医療保険保険給付分の支払システム及び支払方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200602