基于区块链的业务处理系统、方法、计算设备及存储介质
技术领域
本申请涉及计算机技术领域,特别涉及一种基于区块链的业务处理系统、方法、计算设备及存储介质。
背景技术
随着经济的发展,大众的生活质量及消费水平不断提高,越来越多的东西已经成为我们生活中很重要的甚至是必不可少的组成部分。
以保险为例,保险作为一种保证机制已经融入到了人们的生活当中。保险的种类日趋繁多,保险的赔偿条款也是各不相同,用户在投保后,如果在投保期限内发生了事故,可以通过保险进行赔偿。
目前保险行业传统的赔偿流程需要待处理用户根据医院方出具的票据和证明,将相关资料提供给保险公司,保险公司根据理赔标准流程,判断待处理用户是否符合理赔要求,符合理赔要求之后进行后续的理赔手续。对于待处理用户来说,报案手续繁杂,需要提供各种医疗凭证,在保险公司判断待处理用户是否理赔要求的过程中如果出现疑问,待处理用户可能需要重新到医院进行资料更正,这样的话从报案开始到理赔完成耗时较长,效率低下服务时效差,严重影响了保险用户的体验。对于保险公司来说需要进行各种医疗凭证真实性调查,依然需要很长时间,也会造成理赔效率的低下,对于调查人员本身是否存在欺骗作假等行为也很难进行甄别。
发明内容
有鉴于此,本说明书实施例提供了一种基于区块链的业务处理系统、方法、计算设备及存储介质,以解决现有技术中存在的技术缺陷。
一方面,本说明书实施例公开了一种基于区块链的业务处理系统,包括:
业务联盟链、请求客户端和服务端;
信息存储节点对应于所述业务联盟链的区块链节点,被配置为接收用户的业务数据并存储;
所述服务端,被配置为从业务联盟链节点拉取业务数据并将所述业务数据保存到本地数据库中;
所述请求客户端,被配置为向服务端发送业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息;
所述服务端,被配置为接收所述业务处理请求,根据所述用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息,根据所述业务处理所需信息完成针对所述用户的业务处理。
可选地,所述业务联盟链包括保险业务联盟链;
信息存储节点对应于所述保险业务联盟链的区块链节点,被配置为接收用户的医疗数据并存储;
所述服务端,被配置为从保险业务联盟链节点拉取数据并将所述数据保存到本地数据库中;
所述请求客户端,被配置为向服务端发送案件处理请求,所述案件处理请求中携带有待处理用户的身份标识及就诊信息;
所述服务端,被配置为接收所述案件处理请求,根据所述待处理用户的身份标识及就诊信息在本地数据库中查询所述待处理用户的计划详情及医疗数据,根据所述计划详情及医疗数据确定报案所需信息,根据报案所需信息完成针对所述用户的案件处理。
可选地,所述服务端,还被配置为向请求客户端发送服务授权请求;
所述请求客户端,还被配置为接收所述服务授权请求并对所述服务端进行服务授权;
所述服务端,还被配置为获取所述待处理用户的服务授权,根据所述待处理用户的身份标识查询用户的处理状态信息;若所述待处理用户的处理状态为正在处理或处理完成,则向请求客户端发送处理失败标识;若所述待处理用户的处理状态为空,则查询所述待处理用户的计划详情及医疗数据。
可选地,所述服务端,还被配置为根据所述用户的就诊信息、计划详情及医疗数据,检测所述待处理用户是否符合预定处理条件;若符合预定处理条件,则根据所述就诊信息的账单明细,和所述计划详情中与所述账单明细对应的赔偿限额和赔偿比例,确定所述待处理用户对应的待赔偿金额,并按照所述待赔偿金额执行相应的快速案件处理操作。
另一方面,本说明书实施例公开了一种基于区块链的业务处理方法,包括:
从业务联盟链节点拉取数据并将所述数据保存到本地数据库中;
接收待处理用户的业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息;
根据用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息;
根据所述业务处理所需信息完成针对所述用户的业务处理。
可选地,一种基于区块链的业务处理方法,包括:
从保险业务联盟链节点拉取数据并将所述数据保存到本地数据库中;
接收待处理用户的案件处理请求,所述案件处理请求中携带有待处理用户的身份标识及就诊信息;
根据所述待处理用户的身份标识及就诊信息在本地数据库中查询所述待处理用户的计划详情及医疗数据,根据所述计划详情及医疗数据确定报案所需信息;
根据报案所需信息完成针对所述用户的案件处理。
可选地,接收所述业务处理请求之后,还包括:
向请求客户端发送服务授权请求;
若获取所述待处理用户的服务授权,则根据所述待处理用户的身份标识查询待处理用户的处理状态信息;
若所述待处理用户的处理状态为正在处理或处理完成,则向请求客户端发送处理失败标识;
若所述待处理用户的处理状态为空,则根据所述用户的身份标识及用户的业务信息查询与所述待处理用户的业务数据。
可选地,根据用户的身份标识在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息包括:
根据所述用户的业务信息、计划详情及业务数据,检测所述待处理用户是否符合预定处理条件;
若所述待处理用户符合预定处理条件,则根据所述计划详情从业务信息中获取与计划详情责任信息的定性属性对应的定性属性信息,所述定性属性信息即为业务处理所需信息。
可选地,根据所述业务处理所需信息完成针对所述用户的业务处理包括:
参照与业务信息匹配的计划详情中的赔偿限额和赔偿比例,理算各项业务信息对应的赔偿金额并相加得到总的待赔偿金额;
将所述待赔偿金额与所述计划详情的最大赔偿限额进行对比;
若所述待赔偿金额小于或等于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额;
若所述待赔偿金额大于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额。
根据所述赔偿金额完成针对所述用户的业务处理。
另一方面,本说明书实施例公开了一种基于区块链的业务处理的装置,包括:
拉取模块,被配置为从业务联盟链节点拉取数据并将所述数据保存到本地数据库中;
接收模块,被配置为接收待处理用户的业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息;
查询模块,被配置为根据用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息;
处理模块,被配置为根据所述业务处理所需信息完成针对所述用户的业务处理。
可选地,查询模块包括:
发送子模块,被配置为向请求客户端发送服务授权请求;
第一查询子模块,被配置为若获取所述待处理用户的服务授权,则根据所述待处理用户的身份标识查询待处理用户的处理状态信息;
判断子模块,被配置为若所述待处理用户的处理状态为空,则查询与所述待处理用户的计划详情及业务数据,根据所述用户的业务信息、计划详情及业务数据,判断所述待处理用户是否符合预定处理条件;
第二查询子模块,被配置为若所述待处理用户符合预定处理条件,则根据所述计划详情从业务信息中获取与计划详情责任信息的定性属性对应的定性属性信息,所述定性属性信息即为业务处理所需信息。
可选地,处理模块包括:
核算子模块,被配置为参照与业务信息匹配的计划详情中的赔偿限额和赔偿比例,理算各项业务信息对应的赔偿金额并相加得到总的待赔偿金额;
确定子模块,被配置为将所述待赔偿金额与所述计划详情的最大赔偿限额进行对比,确定所述待处理用户的实际赔偿金额。
另一方面,本说明书实施例公开了一种计算设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令,所述处理器执行所述指令时实现基于区块链的业务处理的方法的步骤。
另一方面,本说明书实施例公开了一种计算机可读存储介质,其存储有计算机指令,该指令被处理器执行基于区块链的业务处理的方法的步骤。
本说明书提供的一种基于区块链的业务处理系统、方法,本发明希望实现一种基于同盟链的案件快速处理方法,由于区块链使用分布式核算和存储,不存在中心化的硬件或管理机构,任意节点的权利和义务都是均等的,一旦信息经过验证并添加至区块链,就会永久的存储起来,单个节点上对数据库的修改是无效的,因此区块链的数据稳定性和可靠性极高;同时,在用户发送案件处理申请后,服务端直接从本地数据库查询相关信息,免除用户反复收集凭证,降低费用提高时效,能够有效的提升用户体验。
附图说明
图1是本说明书一实施例提供的一种基于区块链的业务处理系统的结构示意图;
图2是本说明书一实施例提供的一种基于区块链的业务处理系统的结构示意图;
图3是本说明书一实施例提供的一种计算设备的结构框图;
图4是本说明书一实施例提供的一种基于区块链的业务处理方法流程图;
图5是本说明书一实施例提供的一种基于区块链的业务处理方法流程图;
图6是本说明书一实施例提供的一种基于区块链的业务处理方法流程图;
图7是本说明书一实施例提供的一种基于区块链的业务处理装置的结构示意图;
图8是本说明书一实施例提供的一种基于区块链的业务处理装置的结构示意图;
图9是本说明书一实施例提供的一种基于区块链的业务处理装置的结构示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本说明书内涵的情况下做类似推广,因此本说明书不受下面公开的具体实施的限制。
在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一也可以被称为第二,类似地,第二也可以被称为第一。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
首先,对本发明一个或多个实施例涉及的名词术语进行解释。
联盟链:由某个群体内部指定多个预选的节点为记账人,每个块的生成由所有的预选节点共同决定,其他任何公司和组织可以通过该区块链开放的API进行限定访问。
在本说明书中,提供了一种基于区块链的业务处理系统、方法、一种计算设备及存储介质,在下面的实施例中逐一进行详细说明。
图1示出了根据本说明书一实施例提供的一种基于区块链的业务处理系统结构示意图,业务处理系统可以包括:
信息存储节点102、服务端104、请求客户端106和业务联盟链108,业务联盟链108为本说明书中作为信息存储的区块链。
信息存储节点102,所述信息存储节点对应于所述业务联盟链的区块链节点,被配置为接收用户的业务数据并存储。
本说明书一个或多个实施例中,业务联盟链可以为保险业务联盟链或互助业务联盟链等。
服务端104,被配置为从业务联盟链节点拉取业务数据并将所述业务数据保存到本地数据库中。
请求客户端106,被配置为向服务端发送业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息。
所述服务端104,还被配置为接收所述业务处理请求,根据所述用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息,根据所述业务处理所需信息完成针对所述用户的业务处理。
所述服务端104,还被配置为将业务处理状态信息发送到业务联盟链节点。
所述业务联盟链108,还被配置为接收所述业务处理状态信息。
本说明书一个或多个实施例中,业务联盟链中的节点设备包括接入所述区块链的业务相关机构节点、监管机构的设备节点以及互联网平台的服务设备。
不同业务涉及机构不同,所以不同的业务联盟链上的业务相关机构设备节点也不相同。例如财险对应的业务相关机构设备节点可以包括维修厂、第三方公估机构等,医疗险对应的业务相关机构设备节点则可以包括医疗终端设备节点、医疗服务机构的服务设备节点等。实际应用中需要根据具体情况确定,本说明书对此不作限定。
下面以医疗险为例进行说明。医疗险业务下,医疗终端设备节点上配置有信息存储节点1、医疗服务机构的服务设备节点上配置有信息存储节点2、互联网平台的服务设备节点上配置有信息存储节点3等。其中,信息存储节点1-3并不一定配置于业务联盟链中的区块链节点上,也可以配置于区块链节点之外的独立节点上。
本说明书一个或多个实施例中,区块链上的成员包括监管机构、业务处理的相关机构等,该联盟链用于数据存储,并通过监管机构进行监督,以保证存储的用户业务数据的未被篡改,服务端从区块链拉取数据,在用户发送业务处理请求后,服务端可以直接从本地数据库查询相关数据,无需进行业务数据真实与准确性的调查,也免除了用户反复收集业务数据的过程,能够保证快速完成业务处理,提高时效性。
图2示出了根据本说明书一实施例提供的一种基于区块链的业务处理系统的结构示意图,包括:
信息存储节点202、服务端204、请求客户端206和保险业务联盟链208,保险业务联盟链208为本说明书中作为信息存储的区块链。
信息存储节点202,所述信息存储节点对应于所述保险业务联盟链的区块链节点,被配置为接收用户的医疗数据并存储。
服务端204,被配置为从保险业务联盟链节点拉取数据并将所述数据保存到本地数据库中。
请求客户端206,被配置为向服务端发送案件处理请求,所述案件处理请求中携带有待处理用户的身份标识及就诊信息。
所述服务端204,还被配置为接收所述案件处理请求,根据所述待处理用户的身份标识及就诊信息在本地数据库中查询与所述待处理用户的计划详情及医疗数据,确定所述计划详情及医疗数据确定报案所需信息,根据所述报案所需信息完成针对所述用户的案件处理。
所述服务端204,还被配置为将处理状态信息发送到业务联盟链节点。
所述保险业务联盟链208,还被配置为接收所述处理状态信息。
本说明书一个或多个实施例中,保险业务联盟链208中包括接入所述区块链的由业务相关机构设备节点、互联网平台的服务设备节点、监管机构的设备节点以及保险机构的服务设备节点。
下面以医疗险为例进行说明。医疗险业务下,监管机构的设备节点上配置有信息存储节点1、保险机构的服务设备节点上配置有信息存储节点2、互联网平台的服务设备节点上配置有信息存储节点3等。其中,信息存储节点1-3并不一定配置于保险业务联盟链中的区块链节点上,也可以配置于区块链节点之外的独立节点上。
本说明书一个或多个实施例中,保险业务联盟链上的成员包括监管机构、保险公司和医疗服务相关机构等,该联盟链用于数据存储,并通过监管机构进行监督,以保证存储的用户的就诊数据的未被篡改,医疗机构将用户的就诊数据上传到联盟链节点,服务端从联盟链节点拉取数据,在用户发送案件处理请求后,服务端可以直接从本地数据库查询相关数据,无需进行就诊数据真实与准确性的调查,能够保证快速完成业务处理,提高时效性。
图3是示出了根据本说明书一实施例的计算设备300的结构框图。该计算设备300的部件包括但不限于存储器310和处理器320。处理器320与存储器310通过总线330相连接。
计算设备300还包括接入设备340,接入设备340可以包括有线或无线的任何类型的网络接口(例如,网络接口卡(NIC))中的一个或多个,诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口,等等。
在本说明书的一个实施例中,计算设备300的上述部件以及图3中未示出的其他部件也可以彼此相连接,例如通过总线。应当理解,图3所示的计算设备结构框图仅仅是出于示例的目的,而不是对本说明书范围的限制。本领域技术人员可以根据需要,增添或替换其他部件。
计算设备300可以是任何类型的静止或移动计算设备,包括移动计算机或移动计算设备(例如,平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如,智能手机)、可佩戴的计算设备(例如,智能手表、智能眼镜等)或其他类型的移动设备,或者诸如台式计算机或PC的静止计算设备。计算设备300还可以是移动式或静止式的服务器。
其中,处理器320可以执行图4所示方法中的步骤。图4示出了根据本说明书一实施例提供的一种基于区块链的业务处理方法的流程图,应用于服务端,包括步骤402至步骤408。
步骤402、从业务联盟链节点拉取数据并将所述数据保存到本地数据库中。
本说明书一个或多个实施例中,服务端拉取区块链节点数据的方式有两种:主动拉取式和监听拉取式;主动拉取式即间隔一定时间拉取链上节点数据写入到本地数据库中,监听拉取式即监听区块链出块信息拉取节点数据写入到本地数据库中;在数据拉取过程中,每次拉取出块数据由块高决定,例如前面已经拉取了1-10000的10000个块,一定时间间隔后块高增为10100,则再次拉取时只会拉取10000-10100中新增的100个块的信息,可以有效避免数据重复拉取。
步骤404、接收业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息。
本说明书一个实施例中,业务处理请求包括保险理赔请求或互助保险业务请求等,以保险理赔请求为例,用户发送案件处理请求时,需要填写相关信息,包括姓名、就诊类型、联系电话、就诊城市、就诊医院、以及就诊时间等信息。
步骤406、根据用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的数据并确定业务处理所需信息。
步骤408、根据所述业务处理所需信息完成针对所述用户的业务处理。
本说明书一个或多个实施例中,服务端通过用户的身份标识及业务信息在本地查询与用户相关的数据,再从这些数据中获取满足预设处理条件的信息,无须用户反复收集和上传相关业务信息,有效的提高了业务处理效率。
下面以保险业务为例,对本说明书提供的业务处理方法进行描述。本实施例中,保险业务联盟链的区块链节点信息存储节点1,结合图5,对业务处理方法进行描述,其中,应用于保险业务联盟链、服务端和请求客户端之间,如图5所示,该业务处理方法可以包括步骤502至步骤508。
步骤502、从保险业务联盟链节点拉取数据并将所述数据保存到本地数据库中。
在服务端拉取区块链节点的数据之前,医疗机构会将用户的就诊信息按照预定的数据模型上传到距离自己最近的区块链节点上,预定的数据模型形式如表1所示:
表1
上表仅示意性的列出几项比较重要的信息,一个患者在门诊进行一次就诊产生一次就诊记录,记录还包括患者唯一标识号、就诊序号、就诊类型、医保卡号、证件类型名称及就诊科室编码等信息。
本说明书一个或多个实施例中,服务端拉取区块链节点数据的方式有两种:主动拉取式和监听拉取式;主动拉取式即间隔一定时间拉取链上节点数据写入到本地数据库中,监听拉取式即监听区块链出块信息拉取节点数据写入到本地数据库中;在数据拉取过程中,每次拉取出块数据由块高决定,例如前面已经拉取了1-10000的10000个块,一定时间间隔后块高增为10100,则再次拉取时只会拉取10000-10100中新增的100个块的信息,可以有效避免数据重复拉取。
步骤504、接收待处理用户的案件处理请求,所述案件处理请求中携带有用户的身份标识及用户的就诊信息。
本说明书一个实施例中,用户发送案件处理请求时,需要填写相关信息,包括姓名、就诊类型、联系电话、就诊城市、就诊医院、以及就诊时间等。
下面以计划成员小徐申请理赔为例进行说明,在发送理赔申请请求时,填写的相关信息如表2所示:
表2
上表仅示意性的列出几项比较重要的信息,一个患者在发送理赔申领请求时,除需填写上表中的信息外,可能还需填写其他相关信息。
步骤506、根据用户的身份标识及就诊信息在本地数据库中查询与所述用户相关的数据并确定报案所需信息。
步骤508、根据所述报案所需信息完成针对所述用户的案件处理。
本说明书一个或多个实施例中,基于对所述报案信息的结算结果,从所述服务端在所述应用系统注册完成的账户地址中扣除对应数量的虚拟资源,以及向所述用户在所述应用系统注册完成的账户地址转入对应数量的虚拟资源。
本说明书一个或多个实施例中,服务端通过用户的身份标识在本地查询与用户相关的数据,包括计划详情和医疗数据,再从这些数据中获取满足预设处理条件的信息,有效的提高了案件处理效率。
图6示出了根据本说明书一实施例提供的一种基于区块链的业务处理方法流程图,包括步骤602至步骤610。
步骤602、向请求客户端发送服务授权请求。
本发明的一个实施例中,用户向服务端授权后,服务端可以查询该用户的相关信息。
步骤604、若获取所述待处理用户的服务授权,则根据所述待处理用户的身份标识查询待处理用户的处理状态信息。
本发明的一个实施例中,用户的处理状态信息会由服务端上传到区块链,先查询用户的处理状态信息,确定该用户是否已经在其他服务端发送了案件处理申请或者案件已经处理完成,若该用户的处理状态为正在处理或处理完成,则向请求客户端发送处理失败标识。
步骤606、若所述待处理用户的处理状态为空,则查询与所述待处理用户的计划详情及业务数据。
步骤608、根据所述用户的业务信息、计划详情及业务数据,检测所述待处理用户是否符合预定处理条件。
服务端根据所述计划详情确定与所述计划详情对应的责任信息;获取与所述责任信息对应的定性属性;根据所述计划详情从数据库中的业务信息中获取与所述定性属性对应的定性属性信息,当服务端查找到完全匹配的场景数据时,则认为该用户符合预定处理条件之一,还需对其他条件作进一步判断,当服务端查找不到完全匹配的场景数据时,向用户发送匹配失败的通知,通知信息为“该用户投保的项目不覆盖此次申请项目”。
下面以某一用户为例进行说明,假设该用户购买的保险为重大疾病险,案件处理申请中包含的就诊信息有心肌梗塞住院和骨折住院,根据疾病分类表可以得出心肌梗塞的疾病类型为重大疾病,骨折属于意外伤害疾病,由此可以初步判定该用户的就诊信息中心肌梗塞住院满足预定处理条件之一,除此之外,还需对其他条件作进一步判断,例如,为了保证理赔操作的安全性,降低保险公司的理赔风险,可以预先将一些存在违规记录的、之前存在骗保等行为的用户信息保存在理赔黑名单中,在检测待处理用户是否符合预定理赔条件时,可以判断该用户是否为理赔黑名单用户,如果是黑名单用户,说明对该用户进行理赔操作会存在很大风险,进而确定该用户不符合预定理赔条件;如果不是黑名单用户,但是该用户在最近半个月的时间里,存在较多次的保险理赔操作,说明该用户最近经常进行保险理赔,可能是骗保用户,为了保证理赔操作的安全性,可以确定该用户不符合预定理赔条件。
步骤610、若所述待处理用户符合预定处理条件,则根据所述业务信息的账单明细,和所述计划详情中与所述账单明细对应的赔偿限额和赔偿比例,确定所述待处理用户对应的待赔偿金额。
本说明书一个或多个实施例中,参照与业务信息匹配的计划详情中的赔偿限额和赔偿比例,理算各项业务信息对应的赔偿金额并相加得到总的待赔偿金额;将所述待赔偿金额与所述计划详情的最大赔偿限额进行对比;若所述待赔偿金额小于或等于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额;若所述待赔偿金额大于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额。
服务端根据待处理用户的计划详情、业务信息中的账单明细和计划详情中与该账单明细对应的赔偿限额和赔偿比例,计算每项账单费用需要赔付多少,最后相加得到需要赔偿的总金额,每个产品的最大赔偿限额可以根据计划详情内容进行设定。
例如,待处理用户的就诊信息中包含住院医疗费、住院床位费、住院手术费,查询该用户的医疗保单中对这三项费用的责任明细,找到这三项费用的理赔比例和理赔限额,最后计算出该用户对应的理赔金额。
本说明书一个或多个实施例中,服务端需要获得用户的服务授权才能查询与用户相关的数据,授权成功后,服务端先查询用户的处理状态是否为正在处理或处理完成,这样可以有效避免重复处理的问题,判断用户的就诊信息与保单的处理范围是否匹配,判断用户是否为理赔黑名单用户,可以有效提高理赔的安全性。
本说明书一实施例还提供一种基于区块链的业务处理装置,如图7所示,包括拉取模块702、接收模块704、查询模块706和处理模块708。
拉取模块702,被配置为从业务联盟链节点拉取数据并将所述数据保存到本地数据库中。
本说明书一个或多个实施例中,以保险业务为例,在服务端拉取区块链节点的数据之前,医疗机构会将用户的就诊信息按照预定的数据模型上传到距离自己最近的区块链节点上。
本说明书一个或多个实施例中,服务端拉取区块链节点数据的方式有两种:主动拉取式和监听拉取式;主动拉取式即间隔一定时间拉取链上节点数据写入到本地数据库中,监听拉取式即监听区块链出块信息拉取节点数据写入到本地数据库中;在数据拉取过程中,每次拉取出块数据由块高决定,例如前面已经拉取了1-10000的10000个块,一定时间间隔后块高增为10100,则再次拉取时只会拉取10000-10100中新增的100个块的信息,可以有效避免数据重复拉取。
接收模块704,被配置为接收待处理用户的业务处理请求,所述业务处理请求中携带有用户的身份标识及用户的业务信息。
仍以保险保险业务为例,用户发送案件处理请求时,需要填写相关信息,包括姓名、就诊类型、联系电话、就诊城市、就诊医院、以及就诊时间等信息。
查询模块706,被配置为根据用户的身份标识及用户的业务信息在本地数据库中查询与所述用户相关的业务数据并确定业务处理所需信息。
处理模块708,被配置为根据所述业务处理所需信息完成针对所述用户的业务处理。
本说明书一个或多个实施例中,基于所述结算结果,从所述服务端在所述应用系统注册完成的账户地址中扣除对应数量的虚拟资源,以及向所述用户在所述应用系统注册完成的账户地址转入对应数量的虚拟资源。
本说明书一个或多个实施例中,服务端通过用户的身份标识在本地查询与用户相关的数据,包括计划详情和业务数据,再从这些数据中获取满足预设处理条件的信息,通过多个条件的对比,有效的提高了安全性。
本说明书一实施例还提供一种基于区块链的业务处理装置,如图8所示,查询模块706包括:
发送子模块802,被配置为向请求客户端发送服务授权请求。
本发明的一个实施例中,用户向服务端授权后,服务端可以查询该用户的相关信息。
第一查询子模块804,被配置为若获取所述待处理用户的服务授权,则根据所述待处理用户的身份标识查询待处理用户的处理状态信息。
本发明的一个实施例中,用户的处理状态信息会由服务端上传到区块链,先查询用户的处理状态信息,确定该用户是否已经在其他服务端发送了案件处理申请或者案件已经处理完成,若该用户的处理状态为正在处理或处理完成,则向请求客户端发送处理失败标识。
判断子模块806,被配置为若所述待处理用户的处理状态为空,则查询与所述待处理用户的计划详情及业务数据,根据所述用户的业务信息、计划详情及医疗数据,判断所述待处理用户是否符合预定处理条件。
服务端根据所述计划详情确定与所述计划详情对应的责任信息;获取与所述责任信息对应的定性属性;根据所述计划详情从数据库中的业务信息中获取与所述定性属性对应的定性属性信息,当服务端查找到完全匹配的场景数据时,则认为该用户符合预定处理条件之一,还需对其他条件作进一步判断,当服务端查找不到完全匹配的场景数据时,向用户发送匹配失败的通知,通知信息为“该用户投保的项目不覆盖此次申请项目”。
第二查询子模块808,被配置为若所述待处理用户符合预定处理条件,则根据所述计划详情从业务信息中获取与计划详情责任信息的定性属性对应的定性属性信息,所述定性属性信息即为业务处理所需信息。
本说明书一个或多个实施例中,如果查询到用户的处理状态为正在处理或处理完成,或者该用户不符合预定处理条件,则向请求客户端发送处理失败标识,这样可以有效提高安全性。
本说明书一实施例还提供一种基于区块链的业务处理装置,如图9所示,处理模块708包括:
核算子模块902,被配置为参照与业务信息匹配的计划详情中的赔偿限额和赔偿比例,理算各项业务信息对应的赔偿金额并相加得到总的待赔偿金额。
本说明书一个或多个实施例中,仍以保险业务为例,参照与就诊信息匹配的计划详情中的赔偿限额和赔偿比例,理算各项就诊信息对应的赔偿金额并相加得到总的待赔偿金额;将所述待赔偿金额与所述计划详情的最大赔偿限额进行对比;若所述待赔偿金额小于或等于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额;若所述待赔偿金额大于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额。
服务端根据待处理用户的计划详情、就诊信息中的账单明细和计划详情中与该账单明细对应的赔偿限额和赔偿比例,计算每项账单费用需要赔付多少,最后相加得到需要赔偿的总金额,每个医疗保险产品的最大赔偿限额可以根据保单内容进行设定。
确定子模块904,被配置为将所述待赔偿金额与所述计划详情的最大赔偿限额进行对比,确定所述待处理用户的实际赔偿金额。
本说明书一个或多个实施例中,若所述待赔偿金额小于或等于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额;若所述待赔偿金额大于所述最大赔偿限额,则将所述待赔偿金额确定为所述待处理用户的赔偿金额。
本说明书一个或多个实施例中,通过业务联盟链存储用户的业务数据,保证了数据的不可篡改性,服务端从联盟链节点拉取数据,如果用户需要进行业务处理,只需在应用系统提交申请,系统直接从本地数据库查询与用户相关的数据,不需要该用户提供纸质票据和证明,由于联盟链存储数据的不可篡改性,服务端在判断待处理用户是否满足预设处理条件时,不需要对各种用户数据的真实性进行调查,从报案开始到处理完成耗时大大减少,提高了处理效率。
本申请一实施例还提供一种计算设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令,所述处理器执行所述指令时实现如前所述基于区块链的业务处理方法的步骤。本申请一实施例还提供一种计算机可读存储介质,其存储有计算机指令,该指令被处理器执行时实现如前所述基于区块链的业务处理方法的步骤。
说明书上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是,该存储介质的技术方案与上述的基于区块链的业务处理方法的技术方案属于同一构思,存储介质的技术方案未详细描述的细节内容,均可以参见上述基于区块链的业务处理方法的技术方案的描述。
所述计算机指令包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括电载波信号和电信信号。
需要说明的是,对于前述的各方法实施例,为了简便描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本说明书并不受所描述的动作顺序的限制,因为依据本说明书,某些步骤可以采用其它顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定都是本说明书所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其它实施例的相关描述。
以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节,也不限制该发明仅为所述的具体实施方式。显然,根据本说明书的内容,可作很多的修改和变化。本说明书选取并具体描述这些实施例,是为了更好地解释本申请的原理和实际应用,从而使所属技术领域技术人员能很好地理解和利用本申请。本说明书仅受权利要求书及其全部范围和等效物的限制。