CN111311422A - 理赔数据处理方法、装置、设备及存储介质 - Google Patents
理赔数据处理方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN111311422A CN111311422A CN202010074894.4A CN202010074894A CN111311422A CN 111311422 A CN111311422 A CN 111311422A CN 202010074894 A CN202010074894 A CN 202010074894A CN 111311422 A CN111311422 A CN 111311422A
- Authority
- CN
- China
- Prior art keywords
- data
- hospital
- information
- user
- target format
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Economics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
本申请提供一种理赔数据处理方法、装置、设备及存储介质,该方法包括:接收终端发送的业务请求;根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院;若确定用户所入住的医院为直连医院,向数据平台发送通知信息并接收数据平台返回的账单详细信息;根据医院对应的映射规则,将账单详细信息转化为目标格式数据;根据目标格式数据对请求数据进行校验;若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验,并提高了业务处理的数据准确性,避免虚假请求造成的损失。
Description
技术领域
本申请涉及互联网技术领域,尤其涉及一种理赔数据处理方法、装置、设备及存储介质。
背景技术
随着互联网技术的飞速发展,基于互联网的理赔业务业逐渐成为一种重要的模式。
现有技术中的理赔业务,理赔账单的收集方式为初审人员根据用户提供的诊疗信息明细及诊断证明进行理赔判定及理赔账单信息的录入维护,通常用户住院的费用明细条目会非常多,数据量大,对初审人员的录入工作是很大的挑战,导致理赔业务处理效率低,理赔周期长,从而使用户体验较差。
发明内容
本申请提供一种理赔数据处理方法、装置、设备及存储介质,以解决现有技术理赔业务处理效率低等缺陷。
本申请第一个方面提供一种理赔数据处理方法,包括:
接收终端发送的业务请求,所述业务请求包括请求数据;
根据所述请求数据中包括的用户信息、医院信息及预设直连医院信息,判断所述用户入住的医院是否为直连医院;
若确定所述用户所入住的医院为直连医院,向数据平台发送通知信息,以使所述数据平台根据所述通知信息向所述医院请求所述用户的账单详细信息;
接收所述数据平台返回的所述账单详细信息;
根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据;
根据所述目标格式数据对所述请求数据进行校验;
若校验结果为通过,则根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理。
可选地,所述请求数据包括用户信息、医院信息、出险信息及证明影像;
所述根据所述目标格式数据对所述请求数据进行校验,包括:
校验所述证明影像与所述目标格式数据是否一致;
若一致,则校验结果为通过;
若不一致,则校验结果为不通过。
可选地,根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据,包括:
根据所述医院对应的映射规则,将所述账单详细信息中包括的服务名称转化为预设的目标格式,获得转化后的项目名称;
根据所述转化后的项目名称获取所属的项目分类及医保属性;
根据所述转化后的项目名称、所属的项目分类及医保属性,以及所述账单详细信息中包括的对应的其他信息,获得所述目标格式数据。
可选地,所述方法还包括:
若校验结果为不通过,则向终端发送提示数据,以使所述终端展示所述提示数据,所述提示数据包括所述证明影像与所述目标格式数据中不一致的信息;
接收所述终端发送的修改后的请求数据;
根据所述目标格式数据对所述修改后的请求数据进行校验。
可选地,在根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据之后,所述方法还包括:
根据预设限价规则,确定所述用户各项目的自费金额;
根据所述目标格式数据及所述用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据;
所述根据所述目标格式数据对所述请求数据进行校验,包括:
根据所述汇总数据对所述请求数据进行校验。
可选地,所述根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理,包括:
根据所述目标格式数据、所述汇总数据及预设理算账单模板,生成理算账单;
根据所述理算账单及预设险种理算配置,确定理赔金额;
根据所述理赔金额对所述用户进行理赔。
可选地,所述业务请求还包括自动结案指示;
所述根据所述理赔金额对所述用户进行理赔,包括:
根据预设分析模型,确定所述理赔金额是否符合风险较低条件;
若是,则自动根据所述理赔金额对所述用户进行理赔,并进行结案处理。
本申请第二个方面提供一种理赔数据处理装置,包括:
接收模块,用于接收终端发送的业务请求,所述业务请求包括请求数据;
判断模块,用于根据所述请求数据中包括的用户信息、医院信息及预设直连医院信息,判断所述用户入住的医院是否为直连医院;
发送模块,用于若确定所述用户所入住的医院为直连医院,向数据平台发送通知信息,以使所述数据平台根据所述通知信息向所述医院请求所述用户的账单详细信息;
所述接收模块,还用于接收所述数据平台返回的所述账单详细信息;
转化模块,用于根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据;
校验模块,用于根据所述目标格式数据对所述请求数据进行校验;
处理模块,用于若校验结果为通过,则根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理。
可选地,所述请求数据包括用户信息、医院信息、出险信息及证明影像;
所述校验模块,具体用于:
校验所述证明影像与所述目标格式数据是否一致;
若一致,则校验结果为通过;
若不一致,则校验结果为不通过。
可选地,所述转化模块,具体用于:
根据所述医院对应的映射规则,将所述账单详细信息中包括的服务名称转化为预设的目标格式,获得转化后的项目名称;
根据所述转化后的项目名称获取所属的项目分类及医保属性;
根据所述转化后的项目名称、所属的项目分类及医保属性,以及所述账单详细信息中包括的对应的其他信息,获得所述目标格式数据。
可选地,所述处理模块,还用于若校验结果为不通过,则向终端发送提示数据,以使所述终端展示所述提示数据,所述提示数据包括所述证明影像与所述目标格式数据中不一致的信息;
所述接收模块,还用于接收所述终端发送的修改后的请求数据;
所述校验模块,还用于根据所述目标格式数据对所述修改后的请求数据进行校验。
可选地,所述处理模块,还用于:
根据预设限价规则,确定所述用户各项目的自费金额;
根据所述目标格式数据及所述用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据;
所述根据所述目标格式数据对所述请求数据进行校验,包括:
根据所述汇总数据对所述请求数据进行校验。
可选地,所述处理模块,具体用于:
根据所述目标格式数据、所述汇总数据及预设理算账单模板,生成理算账单;
根据所述理算账单及预设险种理算配置,确定理赔金额;
根据所述理赔金额对所述用户进行理赔。
可选地,所述业务请求还包括自动结案指示;
所述处理模块,具体用于:
根据预设分析模型,确定所述理赔金额是否符合风险较低条件;
若是,则自动根据所述理赔金额对所述用户进行理赔,并进行结案处理。
本申请第三个方面提供一种电子设备,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上第一个方面以及第一个方面各种可能的设计所述的方法。
本申请第四个方面提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上第一个方面以及第一个方面各种可能的设计所述的方法。
本申请提供的理赔数据处理方法、装置、设备及存储介质,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为现有技术的理赔业务流程示意图;
图2为本申请实施例基于的处理系统的架构示意图;
图3为本申请一实施例提供的理赔数据处理方法的流程示意图;
图4为本申请另一实施例提供的理赔数据处理方法的流程示意图;
图5为本申请一实施例提供的理赔流程示意图;
图6为本申请一实施例提供的理赔数据处理装置的结构示意图;
图7为本申请一实施例提供的电子设备的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
如图1所示,为现有技术的理赔业务流程示意图。具体包括:代理人员协助客户(即用户)将诊疗信息等相关资料的影像上传理赔系统,初审人员根据影像资料录入理赔账单信息进行理赔。随着业务量的增加,短期内可以通过增加操作人员来缓解理赔账单收集压力,但是随着操作人员的增加,成本也会增加,且此方式不利于理赔信息的审核及诊疗信息的积累。
针对上述问题,本申请实施例提供的理赔数据处理方法,适用于理赔业务的自动化处理,提高理赔业务的处理效率,并且提高理赔业务处理的准确性。如图2所示,为本申请实施例基于的处理系统的架构示意图。该处理系统可以包括理赔系统、数据平台及终端。其中,理赔系统和数据平台可以分别设置在不同的服务器中,也可以设置在同一个服务器中,终端可以包括代理终端,还可以包括用户终端。用户可以通过用户终端向理赔系统发送理赔请求,用户也可以通过代理人员通过代理终端向理赔系统发送理赔请求。理赔系统与数据平台连接通信,数据平台与预设直连医院的相关系统连接通信。当理赔系统接收到用户通过终端发送的业务请求(即理赔请求)时,若确定用户所入住的医院为直连医院,则可以通过数据平台从该医院的相关系统获取该用户的账单详细信息,并将获得的账单详细信息转换为理赔系统的标准格式数据(即目标格式数据),可以根据目标格式数据对用户的业务请求进行校验,若校验通过,则可以根据用户的请求数据及目标格式数据对用户进行理赔。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过设置数据平台与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
此外,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中,“多个”的含义是两个以上,除非另有明确具体的限定。
下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本发明的实施例进行描述。
本申请一实施例提供一种理赔数据处理方法,用于进行理赔业务处理。本实施例的执行主体为理赔数据处理装置,该装置可以设置在理赔系统中,具体可以设置在服务器中。
如图3所示,为本实施例提供的理赔数据处理方法的流程示意图,该方法包括:
步骤101,接收终端发送的业务请求,业务请求包括请求数据。
具体的,该终端可以是代理终端,也可以是用户终端。用户可以通过用户终端向理赔系统发送业务请求,也可以通过代理人员通过代理终端向理赔系统发送业务请求。业务请求可以包括请求数据。具体来说,请求数据可以包括用户信息、医院信息、出险信息、证明影像等。
其中,用户信息具体可以包括用户姓名、性别、身份信息及其他相关信息;医院信息具体可以包括用户入住的医院名称、入院日期及其他相关信息;出险信息具体可以包括出险原因、出险具体内容及其他相关信息;证明影像具体可以包括诊断书、检查结果、缴费明细、发票单据及其他相关内容的照片、图像或视频。
步骤102,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院。
具体的,理赔系统中预先设置有直连医院信息,比如直连医院列表,可以包括能够直连的一个或多个医院的名称、编码等标识信息,还可以包括各医院其他相关信息,比如医院相关系统的服务器地址等,具体可以根据实际需求设置。直连医院是指理赔系统可以直接或通过数据平台间接访问相关数据系统获取用户的账单详细信息的医院。可以根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院。
示例性的,用户入住的医院为医院A,预设直连医院信息中包括医院A,则表示,理赔系统可以通过数据平台与医院A的相关数据系统直连,获取到在医院A住院的用户的账单详细信息。
步骤103,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息。
步骤104,接收数据平台返回的账单详细信息。
具体的,若确定用户入住的医院是直连医院,则可以获取该用户在该医院的账单详细信息。
账单详细信息可以包括该用户本次在该医院住院期间产生的各项服务信息,具体可以包括服务的名称、单价、规格、数量、总价等等。其中,服务比如可以是药品服务、各类检查服务、护理服务等等。具体根据实际需求相关,在此不再赘述。
具体来说,可以设置数据平台与医院的相关数据系统直连,当理赔系统确定用户入住的医院为直连医院时,可以向数据平台发送通知信息,以使数据平台根据通知信息向对应的医院请求该用户的账单详细信息。通知信息可以包括用户的姓名、身份证号、入院日期等信息,以使医院的相关数据系统可以根据通知信息准确地筛选出该用户本次住院的账单详细信息回传给数据平台。
步骤105,根据医院对应的映射规则,将账单详细信息转化为目标格式数据。
具体的,在获取到用户的账单详细信息后,可以获取该医院对应的映射规则,根据该医院对应的映射规则,将账单详细信息转化为目标格式数据。
具体来说,由于不同医院的账单详细信息中记录的服务的名称可能不同,为了能够对各医院的数据进行处理,可以预先建立不同医院与理赔系统的统一格式的映射规则,比如建立不同医院与理赔系统医疗项目的映射库,根据映射库将医院回传的服务名称转化为理赔系统项目的标准名称,映射库中还可以包括各项目对应的项目编码、项目所属的项目分类,项目分类可以根据实际需求设置,比如可以设置三级分类,项目名称及为三级分类名称,项目编码即为三级分类编码,映射库中还包括该项目所属的二级分类名称、二级分类编码、一级分类名称及一级分类编码,还可以包括其他相关信息,具体可以根据实际需求设置。其中,项目分类比如一级分类名称为“住院”,一级分类包括的二级分类名称为“中药”和“西药”,二级分类“中药”包括三级分类名称“药品A”、“药品B”等等。具体的项目分类可以根据实际需求设置,本实施例不做限定。
步骤106,根据目标格式数据对请求数据进行校验。
具体的,在获得了目标格式数据后,可以根据目标格式数据对请求数据进行校验。判断从医院获得的该用户的数据与用户提供的数据是否一致。以保证用户业务请求的真实准确性。
示例性的,用户的请求数据中包括用户上传的证明影像,比如费用明细、发票单据等,可以对证明影像进行识别,提取其中相关数据信息,将从医院获得的该用户的目标格式数据与从证明影像提取的相关数据信息进行比对,来判断是否一致。
可选地,还可以是根据目标格式数据确定用户各项目的自费金额,并按照项目分类进行汇总,获得汇总数据,根据汇总数据与从证明影像中提取的汇总数据进行对比,判断是否一致。具体的校验规则可以根据实际需求设置,本申请实施例不做限定。
步骤107,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。
具体的,若对用户的请求数据校验结果为通过,则可以根据用户的请求数据及目标格式数据对用户进行相应的理赔处理。
具体来说,用户的请求数据中可以包括用户的账户信息,可以根据目标格式数据生成理算账单,根据理算账单来确定理赔金额,根据确定的理赔金额对用户进行理赔。比如将用户的账户信息及理赔金额发送给支付系统,由支付系统根据理赔金额及账户信息,向用户的账户支付相应的理赔金额。具体根据目标格式数据对用户进行理赔处理的过程可以根据实际需求设置,本实施例不做限定。
本实施例提供的理赔数据处理方法,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
本申请另一实施例对上述实施例提供的方法做进一步补充说明。
如图4所示,为本实施例提供的理赔数据处理方法的流程示意图。
作为一种可实施的方式,在上述实施例的基础上,可选地,请求数据包括用户信息、医院信息、出险信息及证明影像;根据目标格式数据对请求数据进行校验,包括:
步骤1061,校验证明影像与目标格式数据是否一致;若一致,则校验结果为通过;若不一致,则校验结果为不通过。
具体的,用户的请求数据中包括用户上传的证明影像,比如费用明细、发票单据等,可以对证明影像进行识别,提取其中相关数据信息,将从医院获得的该用户的目标格式数据与从证明影像提取的相关数据信息进行比对,来判断是否一致。
可选地,还可以是根据目标格式数据确定用户各项目的自费金额,并按照项目分类进行汇总,获得汇总数据,根据汇总数据与从证明影像中提取的汇总数据进行对比,判断是否一致。具体的校验规则可以根据实际需求设置,本申请实施例不做限定。
作为另一种可实施的方式,在上述实施例的基础上,可选地,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,包括:
步骤1051,根据医院对应的映射规则,将账单详细信息中包括的服务名称转化为预设的目标格式,获得转化后的项目名称;
步骤1052,根据转化后的项目名称获取所属的项目分类及医保属性;
步骤1053,根据转化后的项目名称、所属的项目分类及医保属性,以及账单详细信息中包括的对应的其他信息,获得目标格式数据。
具体的,账单详细信息可以包括该用户本次在该医院住院期间产生的各项服务信息,具体可以包括服务的名称、单价、规格、数量、总价等等。其中,服务比如可以是药品服务、各类检查服务、护理服务等等。
由于不同医院的账单详细信息中记录的服务的名称可能不同,为了能够对各医院的数据进行处理,可以预先建立不同医院与理赔系统的统一格式的映射规则,比如建立不同医院与理赔系统医疗项目的映射库,根据映射库将医院回传的服务名称转化为理赔系统项目的标准名称,映射库中还可以包括各项目对应的项目编码、项目所属的项目分类,项目分类可以根据实际需求设置,比如可以设置三级分类,项目名称及为三级分类名称,项目编码即为三级分类编码,映射库中还包括该项目所属的二级分类名称、二级分类编码、一级分类名称及一级分类编码,还可以包括其他相关信息,具体可以根据实际需求设置。其中,项目分类比如一级分类名称为“住院”,一级分类包括的二级分类名称为“中药”和“西药”,二级分类“中药”包括三级分类名称“药品A”、“药品B”等等。具体的项目分类可以根据实际需求设置,本实施例不做限定。映射库中还可以包括项目对应的医保属性,医保属性是指各项目对应的医保情况,比如医保类型(社保赔付、农合补偿等)、是否有自费、自费比例等。
账单详细信息中包括的对应的其他信息包括如上述的单价、规格、数量、总价等信息。具体可以根据实际需求确定生成的目标格式数据中需要的信息。
示例性的,账单详细信息中包括的一条记录如表1所示:
表1
服务名称 | 单价(元) | 规格 | 数量(盒) | 总价(元) |
阿莫西林胶囊 | 10 | XXX | 2 | 20 |
转化获得的目标格式数据如表2所示:
表2
作为另一种可实施的方式,在上述实施例的基础上,可选地,若校验结果为不通过,则向终端发送提示数据,提示数据包括证明影像与目标格式数据中不一致的信息。
具体的,若校验结果为不通过,即目标格式数据中有与证明影像提取的数据不一致的情况,则可以提取出不一致的部分,生成提示信息,发送给终端,以使终端将提示信息展示给用户或操作人员,提示信息可以是提示页面数据,以使终端能够展示提示页面。具体的页面可以根据实际需求设置,本实施例不做限定。操作人员可以在在提示页面进如相应的修改页面进行修改,终端则可以获取到修改后的请求数据,并将修改后的请求数据发送给理赔系统,理赔系统接收到终端发送的修改后的请求数据,则可以再根据目标格式数据对修改后的请求数据进行校验,若能够校验通过,则可以根据修改后的请求数据及目标格式数据对用户进行相应的理赔处理。若还是不能通过校验,则可以退回请求,结束该请求流程,或者继续提示相关操作人员等等,具体可以根据实际需求设置。
作为另一种可实施的方式,在上述实施例的基础上,可选地,在根据医院对应的映射规则,将账单详细信息转化为目标格式数据之后,该方法还包括:
步骤2021,根据预设限价规则,确定用户各项目的自费金额。
步骤2022,根据目标格式数据及用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据。
相应的,根据目标格式数据对请求数据进行校验,包括:
步骤2031,根据汇总数据对请求数据进行校验。
具体的,在获得目标格式数据后,可以根据目标格式数据及预设限价规则,确定用户各项目的自费金额,根据目标格式数据及用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据。根据汇总数据对请求数据进行校验。根据汇总数据与从证明影像中提取的汇总数据进行对比,判断是否一致。
其中,预设限价规则可以根据实际需求设置,比如可以根据医保属性、医院级别、项目单价、预设特殊医院等等进行限价。示例性的,当项目名称中包含“特需”时,为全自费,限价为0。当项目名称中不包含“特需”时,若医院级别为三级:项目单价超过300时为全自费;项目单价为210时,限价200;项目单价为其他时,限价100。具体可以根据实际需求设置。
可选地,根据汇总数据对请求数据进行校验可以是根据汇总数据中的按照一级分类汇总的数据进行校验。具体可以根据实际需求设置,本实施例不做限定。
可选地,若校验结果为通过,根据请求数据及目标格式数据对用户进行相应的理赔处理,包括:
步骤1071,若校验结果为通过,根据目标格式数据、汇总数据及预设理算账单模板,生成理算账单。
步骤1072,根据理算账单及预设险种理算配置,确定理赔金额。
步骤1073,根据理赔金额对用户进行理赔。
具体的,可以预先设置理算账单模板,在确定了汇总数据后,可以根据目标格式数据、汇总数据及预设理算账单模板,生成理算账单。根据理算账单及预设险种理算配置,确定理赔金额,根据理赔金额对用户进行理赔。
可选地,业务请求还包括自动结案指示;
根据理赔金额对用户进行理赔,包括:
步骤2041,根据预设分析模型,确定理赔金额是否符合风险较低条件。
步骤2042,若是,则自动根据理赔金额对用户进行理赔,并进行结案处理。
具体的,可建立分析模型,定期对存入数据库中的结案且正常赔付案件标准账单数据抽取分析,按照疾病类型分类统计,对经常赔付的疾病类型(例如:阑尾炎类案件占每月总医疗案件量的5%以上,或者每月赔付超过500件),筛选此疾病全部标准账单数据,对相同的费用明细项目计数,取计数较多的前80%费用项目作为此疾病的基准医疗项目,并按照地区(一般为省或市区)对医疗费用进行统计,取50分值(中值)作为该地区这一疾病的基准医疗金额,生成地区疾病医疗项目模型。后续理赔医疗账单数据与对应地区的医疗项目模型对比,医疗项目一致率越高,费用超过基准医疗金额越少,得到的分值越高,设定分数区间控制其是否可自动结案。
示例性的,案件为阑尾炎医疗赔偿案件,账单数据标准化汇总处理后,与地区标准数据对比,医疗项目一致率为80%,费用超过地区阑尾炎基准医疗费用10%,得分80分。设定的可自动结案分数区间为75-100分,该案件可自动结案;如分数小于75分,进入下一人工审核流程。
根据数据量的增加,分析模型数据越来越准确,可调节基准医疗项目及控分区间,以达到更加精准控制的目的。
作为一种示例性的实施方式,如图5所示,为本实施例提供的理赔流程示意图。具体流程如下:
1、客户(即用户)出险后在APP(即用户终端)或者操作人员帮助下,填写被保人证件信息、入住医院信息及出险基本信息,并提供身份证件、诊断书及相关证明资料的影像件,提交索赔申请(即业务请求)。如果索赔为医疗类且被保人入住医院为直连医院,则通知数据平台根据客户的证件信息、入住医院及住院时间提前准备电子诊疗资料(即账单详细信息)用于后续理赔使用。
2、理赔系统操作人员根据医院医疗诊断书和出险结果,选择客户名下所有应理赔的险种及责任信息,并选择是否自动结案。
其中,诊断书是指医院给出的用户的诊断结果,出险结果可以包括重疾、身故、伤残等。
3、理赔系统根据客户的证件信息、入住医院及入院日期从数据平台自动获取客户入住医院账单详细信息,其中包含客户的每一项服务的名称、单价、规格、数量、总价等等。
4、由于不同医院中名称等信息可能有差异,理赔系统中建立了不同医院与本理赔系统医疗项目的映射库,根据映射库将医院回传的服务名称转化为理赔系统项目标准名称,并从映射库中取出项目对应项目编码、二级分类编码、二级分类名称、一级分类代编码、一级分类名称、药品属性(即是否属于医保药品)等相关的信息。
5、进入限价流程,理赔系统根据项目名称,医院等级和项目单价等信息确定各项目的限价金额,示例性的,限价规则(即预设限价规则)如下:
A、当项目名称含“特需”时,全自费,限价为0。
B、非A情况,医院级别为三级:项目单价超过300时,全自费;项目金额为210时,限价200;项目单价为其他时,限价100。
C、非A情况,医院级别为二级:项目单价超过230时,全自费;项目金额小于230且为“100家医院”时,限价:150;项目金额为50时,限价48;其他情况,限价65。
D、……。
6、理赔系统根据限价信息计算出自费金额。按照项目二级分类汇总项目总金额、自费金额(即汇总数据),并将以上第3、4步中所得标准账单数据(即账单详细信息及转化后获得的目标格式数据)存入数据库中。
7、校验获取的电子诊疗信息(即汇总数据)与影像信息是否一致,若不一致则提示不一致内容并展示电子诊疗详情,操作人员可修改;若一致则依据费用理算账单模板生成理算账单。
8、理赔系统根据理算账单和理赔系统数据库中险种理算配置计算出应理赔的金额。
9、对存入数据库的标准账单数据定期建模分析,若符合风险较低模型,则可自动结案,即上述调用完自动理算后自动立案、结案、支付。
具体的,可定期对存入数据库中的结案且正常赔付案件标准账单数据抽取分析,按照疾病类型分类统计,对经常赔付的疾病类型(例如:阑尾炎类案件占每月总医疗案件量的5%以上,或者每月赔付超过500件),筛选此疾病全部标准账单数据,对相同的费用明细项目计数,取计数较多的前80%费用项目作为此疾病的基准医疗项目,并按照地区(一般为省或市区)对医疗费用进行统计,取50分值(中值)作为该地区这一疾病的基准医疗金额,生成地区疾病医疗项目模型。后续理赔医疗账单数据与对应地区的医疗项目模型对比,医疗项目一致率越高,费用超过基准医疗金额越少,得到的分值越高,设定分数区间控制其是否可自动结案。
例如:案件为阑尾炎医疗赔偿案件,账单数据标准化汇总处理后,与地区标准数据对比,医疗项目一致率为80%,费用超过地区阑尾炎基准医疗费用10%,得分80分。设定的可自动结案分数区间为75-100分,该案件可自动结案;如分数小于75分,进入下一人工审核流程。
根据数据量的增加,模型数据越来越准确,可调节基准医疗项目及控分区间,以达到更加精准控制的目的。
本实施例提供的方法,理赔系统自动组装账单数据,将数据平台返回的大量费用明细数据(即账单详细信息)进行转化并汇总,转化为住院总费用、社保赔付、农合补偿、总自费等等分类返费用名目,将其与电子诊疗信息中的账目进行比对,并转化为理赔系统可用费用分类保存。并将电子诊疗信息保存,用于后续案件流程优化或统计。
示例性的理赔流程如下:
1、客户张扬(化名)住院治疗后,报案理赔,入住医院朝阳医院为直连医院,理赔系统会将客户的证件信息,入院日期(20180403),入住医院(朝阳医院)推送给数据平台,通知其进行电子诊疗数据的准备。案件被标记并进入初审环节。
2、初审操作人员在录入案件信息时,点击调取客户电子诊疗信息,通过客户的证件信息,入院日期(20180403),入住医院(朝阳医院)获得客户张扬本次在朝阳医院住院的所有费用明细及最终的出院结算信息,并展示在页面上,其中费用明细共863条,包括输液器、气管导管、三通等等,总共合计48562.38元。
3、将获取的账单明细信息转化为标准数据,自动进入限价流程,根据费用明细中每一项名称和数据库对应,最终系统得出所有项目的限价金额及自付比例,并将最终得出的标准数据入库。
4、系统对费用明细进行分类汇总,分为住院手术费13235.00元、住院侦查费2536.00元,药费10569.32元,床位费6350元,护理费3520元,综合8562.00元,其他费用3863.12元;汇总费用为:住院总费用48632.44元,社保报销31582.69元,农合报销0元,自费17049.75元,不合理费用59.62元,其他补偿0元,调取系统内理算账单模板生成理算账单。
5、根据账单信息及数据库中险种理算信息,自动理算并给出建议理赔金额,若此模型为自动结案模型,则自动立案、结案、支付。
6、后续质检及赔案查询中均可查询案件的电子诊疗信息。
需要说明的是,本实施例中各可实施的方式可以单独实施,也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
本实施例提供的理赔数据处理方法,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
本申请再一实施例提供一种理赔数据处理装置,用于执行上述实施例的方法。
如图6所示,为本实施例提供的理赔数据处理装置的结构示意图。该理赔数据处理装置30包括接收模块31、判断模块32、发送模块33、转化模块34、校验模块35和处理模块36。
其中,接收模块,用于接收终端发送的业务请求,业务请求包括请求数据;判断模块,用于根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院;发送模块,用于若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息;接收模块,还用于接收数据平台返回的账单详细信息;转化模块,用于根据医院对应的映射规则,将账单详细信息转化为目标格式数据;校验模块,用于根据目标格式数据对请求数据进行校验;处理模块,用于若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。
关于本实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
根据本实施例提供的理赔数据处理装置,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
本申请又一实施例对上述实施例提供的装置做进一步补充说明。
作为一种可实施的方式,在上述实施例的基础上,可选地,请求数据包括用户信息、医院信息、出险信息及证明影像;校验模块,具体用于:
校验证明影像与目标格式数据是否一致;若一致,则校验结果为通过;若不一致,则校验结果为不通过。
作为另一种可实施的方式,在上述实施例的基础上,可选地,转化模块,具体用于:
根据医院对应的映射规则,将账单详细信息中包括的服务名称转化为预设的目标格式,获得转化后的项目名称;
根据转化后的项目名称获取所属的项目分类及医保属性;
根据转化后的项目名称、所属的项目分类及医保属性,以及账单详细信息中包括的对应的其他信息,获得目标格式数据。
作为另一种可实施的方式,在上述实施例的基础上,可选地,处理模块,还用于若校验结果为不通过,则向终端发送提示数据,以使终端展示提示数据,提示数据包括证明影像与目标格式数据中不一致的信息;接收模块,还用于接收终端发送的修改后的请求数据;校验模块,还用于根据目标格式数据对修改后的请求数据进行校验。
作为另一种可实施的方式,在上述实施例的基础上,可选地,处理模块,还用于:
根据预设限价规则,确定用户各项目的自费金额;
根据目标格式数据及用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据;
根据目标格式数据对请求数据进行校验,包括:
根据汇总数据对请求数据进行校验。
可选地,处理模块,具体用于:
根据目标格式数据、汇总数据及预设理算账单模板,生成理算账单;根据理算账单及预设险种理算配置,确定理赔金额;根据理赔金额对用户进行理赔。
可选地,业务请求还包括自动结案指示;处理模块,具体用于:
根据预设分析模型,确定理赔金额是否符合风险较低条件;若是,则自动根据理赔金额对用户进行理赔,并进行结案处理。
关于本实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
需要说明的是,本实施例中各可实施的方式可以单独实施,也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
根据本实施例的理赔数据处理装置,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
本申请再一实施例提供一种电子设备,用于执行上述实施例提供的方法。
如图7所示,为本实施例提供的电子设备的结构示意图。该电子设备50包括:至少一个处理器51和存储器52;
存储器存储计算机执行指令;至少一个处理器执行存储器存储的计算机执行指令,使得至少一个处理器执行如上任一实施例提供的方法。
根据本实施例的电子设备,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
本申请又一实施例提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当处理器执行计算机执行指令时,实现如上任一实施例提供的方法。
根据本实施例的计算机可读存储介质,通过接收终端发送的业务请求,根据请求数据中包括的用户信息、医院信息及预设直连医院信息,判断用户入住的医院是否为直连医院,若确定用户所入住的医院为直连医院,向数据平台发送通知信息,以使数据平台根据通知信息向医院请求用户的账单详细信息,接收数据平台返回的账单详细信息,根据医院对应的映射规则,将账单详细信息转化为目标格式数据,根据目标格式数据对请求数据进行校验,若校验结果为通过,则根据请求数据及目标格式数据对用户进行相应的理赔处理。一方面实现了理赔业务的自动化处理,提高业务处理效率,降低理赔周期,从而提高用户体验。另一方面,通过与医院直连,从医院获取用户的账单详细信息,对用户的业务请求进行校验,提高了业务处理的数据准确性,避免虚假请求造成的损失。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。
Claims (10)
1.一种理赔数据处理方法,其特征在于,包括:
接收终端发送的业务请求,所述业务请求包括请求数据;
根据所述请求数据中包括的用户信息、医院信息及预设直连医院信息,判断所述用户入住的医院是否为直连医院;
若确定所述用户所入住的医院为直连医院,向数据平台发送通知信息,以使所述数据平台根据所述通知信息向所述医院请求所述用户的账单详细信息;
接收所述数据平台返回的所述账单详细信息;
根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据;
根据所述目标格式数据对所述请求数据进行校验;
若校验结果为通过,则根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理。
2.根据权利要求1所述的方法,其特征在于,所述请求数据包括用户信息、医院信息、出险信息及证明影像;
所述根据所述目标格式数据对所述请求数据进行校验,包括:
校验所述证明影像与所述目标格式数据是否一致;
若一致,则校验结果为通过;
若不一致,则校验结果为不通过。
3.根据权利要求1所述的方法,其特征在于,根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据,包括:
根据所述医院对应的映射规则,将所述账单详细信息中包括的服务名称转化为预设的目标格式,获得转化后的项目名称;
根据所述转化后的项目名称获取所属的项目分类及医保属性;
根据所述转化后的项目名称、所属的项目分类及医保属性,以及所述账单详细信息中包括的对应的其他信息,获得所述目标格式数据。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
若校验结果为不通过,则向终端发送提示数据,以使所述终端展示所述提示数据,所述提示数据包括证明影像与所述目标格式数据中不一致的信息;
接收所述终端发送的修改后的请求数据;
根据所述目标格式数据对所述修改后的请求数据进行校验。
5.根据权利要求1-4任一项所述的方法,其特征在于,在根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据之后,所述方法还包括:
根据预设限价规则,确定所述用户各项目的自费金额;
根据所述目标格式数据及所述用户各项目的自费金额,按照项目分类进行汇总,获得汇总数据;
所述根据所述目标格式数据对所述请求数据进行校验,包括:
根据所述汇总数据对所述请求数据进行校验。
6.根据权利要求5所述的方法,其特征在于,所述根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理,包括:
根据所述目标格式数据、所述汇总数据及预设理算账单模板,生成理算账单;
根据所述理算账单及预设险种理算配置,确定理赔金额;
根据所述理赔金额对所述用户进行理赔。
7.根据权利要求6所述的方法,其特征在于,所述业务请求还包括自动结案指示;
所述根据所述理赔金额对所述用户进行理赔,包括:
根据预设分析模型,确定所述理赔金额是否符合风险较低条件;
若是,则自动根据所述理赔金额对所述用户进行理赔,并进行结案处理。
8.一种理赔数据处理装置,其特征在于,包括:
接收模块,用于接收终端发送的业务请求,所述业务请求包括请求数据;
判断模块,用于根据所述请求数据中包括的用户信息、医院信息及预设直连医院信息,判断所述用户入住的医院是否为直连医院;
发送模块,用于若确定所述用户所入住的医院为直连医院,向数据平台发送通知信息,以使所述数据平台根据所述通知信息向所述医院请求所述用户的账单详细信息;
所述接收模块,还用于接收所述数据平台返回的所述账单详细信息;
转化模块,用于根据所述医院对应的映射规则,将所述账单详细信息转化为目标格式数据;
校验模块,用于根据所述目标格式数据对所述请求数据进行校验;
处理模块,用于若校验结果为通过,则根据所述请求数据及所述目标格式数据对所述用户进行相应的理赔处理。
9.一种电子设备,其特征在于,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如权利要求1-7任一项所述的方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如权利要求1-7任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010074894.4A CN111311422A (zh) | 2020-01-22 | 2020-01-22 | 理赔数据处理方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010074894.4A CN111311422A (zh) | 2020-01-22 | 2020-01-22 | 理赔数据处理方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111311422A true CN111311422A (zh) | 2020-06-19 |
Family
ID=71148769
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010074894.4A Pending CN111311422A (zh) | 2020-01-22 | 2020-01-22 | 理赔数据处理方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111311422A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111932196A (zh) * | 2020-07-08 | 2020-11-13 | 泰康保险集团股份有限公司 | 案件处理方法、装置、设备及可读存储介质 |
CN112116484A (zh) * | 2020-09-21 | 2020-12-22 | 上海亿保健康管理有限公司 | 一种在线理赔方法、装置及设备 |
CN113065972A (zh) * | 2021-04-01 | 2021-07-02 | 支付宝(杭州)信息技术有限公司 | 医保电子凭证处理方法及装置 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107729376A (zh) * | 2017-09-13 | 2018-02-23 | 平安科技(深圳)有限公司 | 保险数据审核方法、装置、计算机设备及存储介质 |
CN107918916A (zh) * | 2017-09-13 | 2018-04-17 | 平安科技(深圳)有限公司 | 自助理赔申请处理方法、装置、计算机设备及存储介质 |
CN109472705A (zh) * | 2018-09-26 | 2019-03-15 | 平安健康保险股份有限公司 | 理赔方法、系统、计算机设备以及存储介质 |
CN109544381A (zh) * | 2018-10-31 | 2019-03-29 | 平安科技(深圳)有限公司 | 获取医疗数据的方法及相关产品 |
CN109544380A (zh) * | 2018-10-31 | 2019-03-29 | 平安医疗健康管理股份有限公司 | 基于位置服务的理赔方法及相关产品 |
CN109670173A (zh) * | 2018-12-13 | 2019-04-23 | 平安医疗健康管理股份有限公司 | 报销数据的排查方法、识别服务端及存储介质 |
CN109933612A (zh) * | 2019-03-13 | 2019-06-25 | 泰康保险集团股份有限公司 | 医疗数据匹配方法、装置、存储介质及电子设备 |
-
2020
- 2020-01-22 CN CN202010074894.4A patent/CN111311422A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107729376A (zh) * | 2017-09-13 | 2018-02-23 | 平安科技(深圳)有限公司 | 保险数据审核方法、装置、计算机设备及存储介质 |
CN107918916A (zh) * | 2017-09-13 | 2018-04-17 | 平安科技(深圳)有限公司 | 自助理赔申请处理方法、装置、计算机设备及存储介质 |
CN109472705A (zh) * | 2018-09-26 | 2019-03-15 | 平安健康保险股份有限公司 | 理赔方法、系统、计算机设备以及存储介质 |
CN109544381A (zh) * | 2018-10-31 | 2019-03-29 | 平安科技(深圳)有限公司 | 获取医疗数据的方法及相关产品 |
CN109544380A (zh) * | 2018-10-31 | 2019-03-29 | 平安医疗健康管理股份有限公司 | 基于位置服务的理赔方法及相关产品 |
CN109670173A (zh) * | 2018-12-13 | 2019-04-23 | 平安医疗健康管理股份有限公司 | 报销数据的排查方法、识别服务端及存储介质 |
CN109933612A (zh) * | 2019-03-13 | 2019-06-25 | 泰康保险集团股份有限公司 | 医疗数据匹配方法、装置、存储介质及电子设备 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111932196A (zh) * | 2020-07-08 | 2020-11-13 | 泰康保险集团股份有限公司 | 案件处理方法、装置、设备及可读存储介质 |
CN112116484A (zh) * | 2020-09-21 | 2020-12-22 | 上海亿保健康管理有限公司 | 一种在线理赔方法、装置及设备 |
CN113065972A (zh) * | 2021-04-01 | 2021-07-02 | 支付宝(杭州)信息技术有限公司 | 医保电子凭证处理方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108257024B (zh) | 一种理赔案件处理方法和装置 | |
US7263493B1 (en) | Delivering electronic versions of supporting documents associated with an insurance claim | |
US20190050953A1 (en) | Method and apparatus for validating an appraisal report and providing an appraisal score | |
US7962350B1 (en) | Payment of health care insurance claims using short-term loans | |
CN111311422A (zh) | 理赔数据处理方法、装置、设备及存储介质 | |
US7835921B1 (en) | Patient credit balance account analysis, overpayment reporting and recovery tools | |
US8583570B2 (en) | Advanced data integrity | |
US7346523B1 (en) | Processing an insurance claim using electronic versions of supporting documents | |
US8311891B2 (en) | System for separating and distributing pharmacy order processing for medication payments | |
US20070088590A1 (en) | System for separating and distributing pharmacy order processing for out of stock medication | |
US20070088566A1 (en) | System for separating and distributing pharmacy order processing for specialty medication | |
US20200105402A1 (en) | Notifying healthcare providers of financially delinquent patients and controlling healthcare claims | |
CN109636632A (zh) | 基于机器学习的保险理赔方法、装置、设备及存储介质 | |
WO2019134231A1 (zh) | 汇总纳税申报管理方法、装置、终端设备及存储介质 | |
CN109978684A (zh) | 一种银行承兑汇票查验方法、系统及相关设备 | |
US20120317003A1 (en) | Automated expense account report generator | |
CN116013505A (zh) | 一种基于drg的医疗费用管理系统 | |
US20180365761A1 (en) | Platform for financing healthcare services | |
US20040143456A1 (en) | Input assisting system | |
US20160267230A1 (en) | Touchless processing | |
CN111242773A (zh) | 虚拟资源申请的对接方法、装置、计算机设备及存储介质 | |
Kubicek et al. | Methodology for analysing the relationship between the reorganisation of the back office and better electronic public services | |
TW202205180A (zh) | 外匯交易自動結匯通報系統及方法 | |
CN112597743A (zh) | 基于考勤数据的报销方法、装置、计算机设备及存储介质 | |
CN112836478A (zh) | 一种零散数据采集应用的方法 |
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 |