CN112508713A - 任务管理方法及系统、装置、存储介质及电子终端 - Google Patents

Abstract

本公开涉及计算机技术领域，具体涉及一种任务管理方法及系统、装置、存储介质和电子终端。所述方法包括：获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在用户申请权限核验完成后向所述用户终端反馈核验结果；响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。本公开能够实现流程的信息化、智能化，进而有效的简化程序，并大幅度的降低人工成本。

Description

任务管理方法及系统、装置、存储介质及电子终端

技术领域

本公开涉及计算机技术领域，具体涉及一种任务管理方法、一种任务管理系统、一种任务管理装置、一种存储介质以及一种电子终端。

背景技术

患者在部分疾病的诊断和治疗过程中，需要使用药品产品，并购买对应的保险。当需要使用保险时，需要用户提交投保人本人的身份证明相关资料、患病的相关病历资料以及购药的相关资料等信息来进行报案、处方审核、理赔审核等流程。在这个过程中，大部分完成服务的方式都是通过人工现场办理，以及使用office办公软件完成，需要收集用户的文件、邮件，以及纸质文件、快递等方式完成数据的整理并完成流程，客户需要花费很长时间，等待多个环节的审批。服务方产生的大量客户资料难以管理，人力成本高。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种任务管理方法、一种任务管理系统、一种任务管理装置、一种存储介质以及一种电子终端，能够实现对特药报案的自动化、智能化处理；进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种任务管理方法，包括：

获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在所述用户申请权限核验完成后向所述用户终端反馈核验结果；

响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

在本公开的一种示例性实施例中，所述第一购药申请信息包括用户姓名、证件类型和证件号码；

所述基于所述第一购药申请信息对用户申请权限进行核验，包括：

利用预设证件核验规则对所述第一申请将进行核验，在核验通过时，生成核验通过信息，以及创建第二药品申请信息上传任务，并发送至所述用户终端；或者

在核验不通过时，生成核验未通过信息，以及创建第一图像采集任务并发送至所述用户终端，以使所述用户终端执行所述第一图像采集任务并采集证件图像；

识别所述用户终端上传的证件图像以提取第一证件数据，以及根据所述用户姓名向保单数据库中查询匹配的保单数据；根据所述保单数据中的第二证件数据与所述第一证件数据进行比对，生成证件数据比对结果；

基于上述证件数据比对结果生成人脸识别任务，并发送至所述用户终端，以使所述用户终端执行所述人脸识别任务并采集人脸图像；

获取所述用户终端上传的人脸图像，根据人脸图像确定用户的生存状态。

在本公开的一种示例性实施例中，所述第二药品申请信息包括：病例信息和处方信息；

所述基于所述第二药品申请信息进行处方审核，包括：

对所述病例信息和处方信息进行文本解析以提取目标关键字，以基于所述目标关键字对所述处方信息进行初次审核，并创建报案任务并发送至理赔管理服务器，以使所述理赔管理服务器创建对应的药品理赔监控任务；

基于所述初次审核结果生成二次审核任务并发送至处方审核终端以获取二次审核结果，并根据所述初次审核结果和所述二次审核结果生成处方审核信息。

在本公开的一种示例性实施例中，所述基于所述初次审核结果生成二次审核任务并发送至处方审核终端以获取二次审核结果，并根据所述初次审核结果和所述二次审核结果生成处方审核信息，包括：

在识别所述初次审核结果为初次审核通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果；在识别所述二次审核结果为二次审核通过时，同步所述二次审核结果和所述初次审核结果，并生成包含审核通过内容的处方审核信息；或者

在识别所述初次审核结果为初次审核不通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果，以及创建用户调查任务并发送至保单服务器，以使所述保单服务器执行所述用户调查任务查询用户历史信息并基于历史信息生成调查结果；基于上述二次审核结果、所述保单服务器反馈的调查结果和第二药品申请信息生成所述处方审核信息；

若所述处方审核信息包含审核未通过内容，则生成报案注销任务并发送所述理赔管理服务器以使所述理赔管理服务器注销所述药品理赔监控任务。

在本公开的一种示例性实施例中，所述方法还包括：

获取用户终端上传的所述凭证信息，并发送至处方审核终端以获取所述处方审核终端对所述凭证信息的审核结果；

在所述审核结果包括核销成功时，激活对应的药品理赔监控任务以使理赔管理服务器处理所述药品理赔监控任务。

在本公开的一种示例性实施例中，所述方法还包括：

响应于所述用户终端发送的理赔请求，进行用户身份验证，并在身份验证通过时创建药品理赔监控任务，以使理赔管理服务器执行所述药品理赔监控任务对所述理赔请求进行核验；其中，所述对理赔请求审核包括处方核验；

获取所述理赔请求的核验结果，并在所述核验结果为核验通过时，向所述理赔管理服务器发送药品理赔监控任务更新信息，以使所述理赔管理服务器根据所述理赔任务更新信息调用索赔任务接口触发索赔处理流程。

根据本公开的第二方面，提供一种任务管理系统，包括：

用户终端，用于向用户管理服务器上传申请信息，以及接收所述用户管理服务器反馈的上述申请信息对应的核验结果；其中，所述申请信息包括第一购药申请信息和第二药品申请信息

用户管理服务器，用于响应所述用户终端发送的第一购药申请信息进行申请权限验证，以及响应所述用户终端发送的第二药品申请信息进行处方审核；

处方审核终端，用于执行处方审核，并对用户终端对应的购药订单进行审核，并在所述购药订单审核通过时创建凭证信息；

理赔管理服务器，用于处理用户对应的药品理赔监控任务。

根据本公开的第三方面，提供一种任务管理装置，包括：

第一购药申请信息响应模块，用于获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在所述用户申请权限核验完成后向所述用户终端反馈核验结果；

第二药品申请信息响应模块，用于响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

购药订单处理模块，用于获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

根据本公开的第四方面，提供一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述的任务管理方法。

根据本公开的第五方面，提供一种电子终端，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述的任务管理方法。

本公开的一种实施例所提供的任务管理方法中，用户利用用户终端上传第一购药申请信息，服务器端在接收到申请后自动进行核验并反馈核验结果；服务器在接收到来自用户终端的第二药品申请信息后自动触发对信息的核验，并反馈核验结果；在核验通过后，能够提示用户终端上传购药信息并生成对应的购药订单，并调用对应的规则触发对订单的自动审核，并将审核结果进行存储和下发至用户终端；从而实现对用户的购药申请、药品处方审核、理赔流程的全流程线上完成，并能够响应用户的申请自动进审核并反馈审核结果，实现流程的信息化、智能化，进而有效的简化程序，并大幅度的降低人工成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种任务管理方法的流程示意图；

图2示意性示出本公开示例性实施例中一种任务管理系统的架构示意图；

图3示意性示出本公开示例性实施例中一种用于用户在院外购药的任务管理方法的流程示意图；

图4示意性示出本公开示例性实施例中一种用于用户在院内购药的任务管理方法的流程示意图；

图5示意性示出本公开示例性实施例中一种任务管理系统的结构框图；

图6示意性示出本公开示例性实施例中一种任务管理装置的结构框图；

图7示意性示出本公开示例性实施例中一种电子设备的组成示意图；

图8示意性示出本公开示例性实施例中一种程序产品的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

在相关技术中，特效药保险产品售卖给客户后，客户患病后需要使用保险时，需要用户提交投保人本人的身份证明相关资料，患病的相关病历资料，购药的相关资料，进行报案，处方审核，理赔审核等流程，在这个过程中，大部分完成服务的方法都是通过人工现场办理，需要工作人员以人工的方式收集用户的文件，以邮件、纸质文件、快递等方式传输并完成流程；而用户则需要花费很长时间，等待多个环节的审批。且由于收集的用户资料多为纸件，产生的大量用户资料也存在难以管理的问题；使得整个处理过程人力成本高。

基于上述问题，本示例实施方式中首先提供了一种任务管理方法。参考图1中所示，上述的任务管理方法可以包括以下步骤：

步骤S11，获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在所述用户申请权限核验完成后向所述用户终端反馈核验结果；

步骤S12，响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

步骤S13，获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

本示例实施方式所提供的任务管理方法，通过在用户终端上传第一购药申请信息，使得服务器端在接收到申请后自动进行核验并反馈核验结果；服务器在接收到来自用户终端的第二药品申请信息后自动触发对信息的核验，并反馈核验结果；一方面，在核验通过后，能够提示用户终端上传购药信息并生成对应的购药订单，并调用对应的规则触发对订单的自动审核，并将审核结果进行存储和下发至用户终端；另一方面，能够实现对用户的购药申请、药品处方审核、理赔流程的全流程线上完成，并能够响应用户的申请自动进审核并反馈审核结果，实现流程的信息化、智能化，进而有效的简化程序，并大幅度的降低人工成本。

图2示出了可以应用本发明实施例的技术方案的示例性系统架构的示意图。

如图2所示，系统架构可以包括用户终端设备201、网络204、PBM管理服务器205、处方审核终端202、理赔管理服务器203。其中，用于终端可以是智能手机、平板电脑等智能设备。网络204用以在用户终端设备与PBM服务器之间、PBM服务器与理赔管理服务器和处方审核终端之间提供通信链路的介质。网络204可以包括各种连接类型，例如有线通信链路、无线通信链路等等。

应理解，图2中的PBM(Pharmacy Benefit Management，药品福利管理系统)服务器205并非是限定性的，服务器205可以为任何其他适合的用户管理服务器。应该理解，图2中的用户终端、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如，PBM管理服务器205可以是多个服务器组成的服务器集群等；或者，PBM管理服务器205和理赔数据管理服务器203可以是一个服务器集群，由不同的服务器实例实现不同的功能。

需要说明的是，本发明实施例所提供的任务管理方法可以由用户终端和服务器协作执行。

下面，将结合附图及实施例对本示例实施方式中的任务管理方法中各个步骤进行更详细的说明。

在步骤S11中，获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在用户申请权限核验完成后向所述用户终端反馈核验结果。

本示例实施方式中，上述的方法可以应用于上述图2中所示的系统架构，应用于用户在医院外部购买特药的应用场景。

具体来说，在用户终端，用户可以通过应用程序、微信小程序或者微信公众号的方式，上传第一购药申请信息。例如，可以在小程序的交互界面中提供输入信息和申请的窗口。其中，上述的第一购药申请信息可以是用户姓名、证件类型以及证件号码。

具体的，在用户终端，可以在交互界面中提供一购药申请的入口。用户点击购药申请的入口后，可以进入第一购药申请信息的提交界面，在该界面中，用户可以输入姓名、证件号码、证件类型，并生成第一购药申请信息发送至PBM服务器。PBM服务器在接收到该第一购药申请信息后，对用户是否具有购药申请权限进行校验。

本示例实施方式中，上述对第一购药申请信息进行校验的方法具体可以包括：

步骤S21，利用预设证件核验规则对所述第一申请将进行核验，在核验通过时，生成核验通过信息，以及创建第二药品申请信息上传任务，并发送至所述用户终端；或者

步骤S22，在核验不通过时，生成核验未通过信息，以及创建第一图像采集任务并发送至所述用户终端，以使所述用户终端执行所述第一图像采集任务并采集证件图像；

步骤S23，识别所述用户终端上传的证件图像以提取第一证件数据，以及根据所述用户姓名向保单数据库中查询匹配的保单数据；根据所述保单数据中的第二证件数据与所述第一证件数据进行比对，生成证件数据比对结果；

步骤S24，基于上述证件数据比对结果生成人脸识别任务，并发送至所述用户终端，以使所述用户终端执行所述人脸识别任务并采集人脸图像；

步骤S25，获取所述用户终端上传的人脸图像，根据人脸图像确定用户的生存状态。

举例来说，PBM服务器可以首先对用户输入的文本格式的身份信息进行初次校验，若校验成功，则向用户终端发送核验成功的指示信息，用户终端在接收到该指示信息后可以跳转至第二药品申请信息的交互页面。此外，在对用户输入的身份信息初次校验成功后，也可以向用户终端发送采集人像信息的第一图像采集任务，判断用户的真实生存状态。

或者，若初次检验失败，则生成核验未通过信息，将第一图像采集任务发送至用户终端；同时，创建用户信息查询任务，根据用户姓名向保单数据库中查询是否存在该用户相关的保单信息或历史数据，提取相关的身份作为第二证件数据。

用户终端接收并执行第一图像采集任务，在交互界面中提供图像采集页面，以使用户在该页面中上传证件图像。PBM服务器利用OCR技术对证件图像进行识别，并提取第一证件数据。第一证件数据可以是姓名、证件类型、证件号码以及地址信息等内容。PBM服务器再将该第一证件数据与保单数据库中查询的第二证件数据进行比对，判断数据身份信息是否匹配。若不匹配，则判定该用户没有购药申请权限，向用户终端反馈该信息，以使用户终端在交互界面中显示该信息。或者，若匹配成功，则PBM服务器再生成人脸识别任务，发送至用户终端。用户终端接收并执行该任务，调用摄像头进行即时的人脸图像采集，并将采集的人脸图像或人脸图像序列上传至PBM服务器。采集过程可以发送一个或多个动态指令，例如转头、张嘴、眨眼等。PBM服务器根据人脸图像确定用户的生存状态。若判断为正常，则向用户终端反馈核验通过信息以及第二药品申请信息上传任务；或者，若判断为异常，则向用户终端反馈核验失败信息。

在步骤S12中，响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端。

本示例实施方式中，PBM服务器在对第一购药申请信息核验通过时，向用户终端发送第二药品申请信息上传任务。用户终端在执行该任务时，在交互界面中提供第二药品申请信息的上传窗口。具体的，第二药品申请信息可以包括病例信息和处方信息。其中，用户可以在用户终端将上传病例信息和处方信息对应的图像数据，或者文本数据。

本示例实施方式中，上述的基于所述第二药品申请信息进行处方审核可以包括：

步骤S31，对所述病例信息和处方信息进行文本解析以提取目标关键字，以基于所述目标关键字对所述处方信息进行初次审核，并创建报案任务并发送至理赔管理服务器，以使所述理赔管理服务器创建对应的药品理赔监控任务；

步骤S32，基于所述初次审核结果生成二次审核任务并发送至处方审核终端以获取二次审核结果，并根据所述初次审核结果和所述二次审核结果生成处方审核信息。

具体来说，用户终端可以上传用户的处方、门诊病例、住院病例、检查检验结果的相关图像或文本，作为第二药品申请信息并上传至PBM服务器。PBM服务器在接收到该些数据后，若为图像数据，则可以首先对图像进行OCR识别来提取文本；对于文本内容，则可以利用预设的关键词对应识别指定的内容。举例来说，关键词可以是药品名称、用量，或者是诊断结果、病程等，从而确定用户的病例和处方中的具体药品和疾病类型及程度。在提取到相关信息后，PBM服务器可以创建初审任务，利用预设的审核规则对提取的相关信息进行自动审核。例如，可以预先建立患者年龄和状态、疾病种类和程度、药品类型和用量、并发症、禁忌信息之间的关系数据表，并利用该数据表进行自动的初审，并生成审核结果。在审核通过时，创建药品理赔监控任务并发送至理赔管理服务器；理赔管理服务器执行该监控任务，创建报案信息。

基于上述内容，为了保证审核结果的准确性，还可以在初审完成后，生成二次审核任务并发送至处方审核终端，由处方审核终端进行二次审核。处方审核终端的二次审核可以是人工审核的方式。处方审核终端可以根据处方信息、病历信息和用户信息完成二次审核，并将审核结果反馈至PBM服务器。

PBM服务器在接收到二次审核结果后，可以结合初审结果确定最终的处方审核结果。具体来说，可以包括：

步骤S41，在识别所述初次审核结果为初次审核通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果；在识别所述二次审核结果为二次审核通过时，同步所述二次审核结果和所述初次审核结果，并生成包含审核通过内容的处方审核信息；或者

步骤S42，在识别所述初次审核结果为初次审核不通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果，以及创建用户调查任务并发送至保单服务器，以使所述保单服务器执行所述用户调查任务查询用户历史信息并基于历史信息生成调查结果；基于上述二次审核结果、所述保单服务器反馈的调查结果和第二药品申请信息生成所述处方审核信息；

步骤S43，若所述处方审核信息包含审核未通过内容，则生成报案注销任务并发送所述理赔管理服务器以使所述理赔管理服务器注销所述药品理赔监控任务。

举例来说，若两次审核均为通过则为处方审核通过；若两次审核均为未通过，则判定为处方审核未通过；若初审未通过，二审通过，则可以触发用户调查任务，利用理赔管理服务器向保单数据库查询用户的保单数据和历史数据，由PBM服务器根据二次审核结果、药品信息、诊断信息、影像信息、调查结果，判定是否处方审核通过，做进一步的确认。

在确定处方审核结果后，将其发送至用户终端。

在步骤S13中，获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

本示例实施方式中，当用户的第二药品申请审核成功后，便可以将审核通过的处方审核信息发送至用户终端，并向用户终端发送购药任务，用户终端执行该购药任务，在用户终端的交互界面中展示购药页面。在该页面中，用户可以输入特药名称、购买数量、服用方式等信息。或者，PBM服务器也可以在第二药品申请审核成功后，根据在处方信息中提取的药品名称、用法、用量等信息自动计算当前用户在当前治疗阶段需要购买的特药药品及数量，生成对应的购药信息，并发送至用户终端，由用户确认，并根据该购药信息生成对应的购药订单，上传至PBM服务器审核。此外，PBM服务器在接收到用户终端上传的购药订单后，根据处方中提取的药品名称、用法用量等信息对购药订单中的特药药品名称、类型和数量进行自动验证；并在验证合格后生成凭证信息下发至用户终端。用户可以通过该凭证信息在线上或线下取药时使用。

基于上述内容，本示例实施方式中，上述的方法还可以包括：

步骤S14，获取用户终端上传的所述凭证信息，并发送至处方审核终端以获取所述处方审核终端对所述凭证信息的审核结果；在所述审核结果包括核销成功时，激活对应的药品理赔监控任务以使理赔管理服务器处理所述药品理赔监控任务。

本示例实施方式中，用户在线下或线上取药时，需要上传之前接收到的凭证信息，并由处方审核终端对凭证信息进行核验。在核验成功时，向用户发放对应的特药药品。同时，可以向理赔管理服务器激活并处理该用户对应的药品理赔监控任务，对该用户的药品订单进行结算。

基于上述内容，本示例实施方式中，参考图3所示，提供的基于院外购药的任务管理方法，具体可以包括：(1)用户在智能终端设备上客户服务终端系统的交互界面中的申请入口提交购药申请。(2)在系统中，根据用户姓名、证件类型、证件号码等信息，通过PBM服务器进行权益审核，校验用户是否具有购药申请权益；若有权益，进入第(3)步骤，若没有权益，系统提示客户没有购药权益。用户在提交身份证图片后，由PBM服务器解析识别身份证中的姓名及证件号信息，并与数据库中的保单数据核对，并反馈给用户终端核对结果是否为本人，同时需要用户进行人脸识别，将人脸照片发送至PBM服务器，PBM服务器会识别图片是否为被保人同时是否具有生命体征，确保用户处于生存状态。(3)用户终端在系统提交用户的购药申请信息及相关资料到PBM服务器，进行处方自动审核；PBM服务器根据产品配置等条件判断是否自动处方审核通过，PBM服务器自动审核通过后，进入处方审核终端进行审方审核，同时提交至理赔管理服务器(CSS)做报案及发调处理；若处方审核终端自动审核不通过，则进入第(4)步骤。(4)处方审核终端根据用户提交资料进行处方人工审核。(5)PBM服务器判断是否需要审方审核，并在判断需要时由PBM服务器提交审方审核，进入处方审核终端进行审方审核。(6)PBM服务器判断是否需要发起对用户的调查，PBM服务器提交理赔管理服务器(CSS)做报案及发调(发起用户调查)处理。(7)处方审核终端完成审方审核后，处方审核终端发送报文至PBM服务器同步审方审核结论、诊断、药品相关信息及相关影像资料，PBM服务器接收审方信息，并进入第(9)步骤。(8)理赔管理服务器(CSS)查询调查结果并发送报文同步给PBM服务器，PBM服务器接收报文中的调查信息并进入第(9)步骤。(9)PBM服务器通过数据库记录并展示审方审核结论、药品信息、诊断、影像资料、调查结论、调查过程，PBM服务器判断处方审核是否通过，通过报文方式下发审核结论，并同步审核结果给用户终端；如果审核通过，进入第(10)步骤；或者，审核不通过，回传审核不通过信息给理赔管理服务器(CSS)进行报案注销处理，流程结束。(10)用户终端引导用户进入购药服务页面，通过报文形式连接理赔管理服务器(CSS)查询剩余保额信息并展示在页面上，用户填写购药信息，进入第(11)步骤。(11)用户确认购药并提交购药信息。(12)PBM服务器生成购药订单，记录药品信息、取药方式、地址等，并推送订单到处方审核终端。(13)处方审核终端确认订单后，回调订单信息给PBM服务器。(14)PBM服务器系统接收订单信息，同步给用户终端展示(系统计算订单金额＝药品单价*数量，客户自付金额＝订单金额-预计理赔金额)。(15)PBM服务器将预计理赔金额通过报文传输到理赔管理服务器(CSS)，理赔管理服务器(CSS)根据预计理赔金额更新报案信息，冻结保额。(16)用户线下取药。(17)处方审核终端核销取药凭证，并通过restful接口推送核销结果、是否走社保结算标识、理赔申请金额、理赔影像资料到PBM服务器。(18)PBM服务器接收理赔信息及资料，核销取药凭证。(19)PBM服务器推送理赔信息及影像资料至理赔管理服务器(CSS)进行理赔处理。

此外，在本公开的其他示例性实施方式中，上述的方法还可以包括：

步骤S51，响应于所述用户终端发送的理赔请求，进行用户身份验证，并在身份验证通过时创建药品理赔监控任务，以使理赔管理服务器执行所述药品理赔监控任务对所述理赔请求进行核验；其中，所述对理赔请求审核包括处方核验；

步骤S52，获取所述理赔请求的核验结果，并在所述核验结果为核验通过时，向所述理赔管理服务器发送药品理赔监控任务更新信息，以使所述理赔管理服务器根据所述理赔任务更新信息调用索赔任务接口触发索赔处理流程。

本示例实施方式中，若用户在医院内购买特药药品，在购买药品后，便可以在用户终端上向PBM服务器上传特药药品的理赔请求。该理赔请求可以包括用户的个人身份信息、病例信息以及处方信息等数据。上述的对用户身份进行验证，可以包括对用户基本信息的验证。具体的，PBM服务器在接收到该些信息后，首先进行身份信息的验证；同时可以生成药品理赔监控任务，并下发至理赔管理服务器。理赔管理服务器接收并执行该任务，判断是否需要处方审核。若不需要执行审核，则调用索赔任务接口向索赔执行终端(LIC终端)发送索赔申请，由索赔执行终端执行LIC理赔程序。或者，若判断需要处方审核，则整理数据反馈至PBM服务器，通知需要进行处方审核。PBM服务器则向处方审核终端下发处方审核任务；处方审核终端接收并执行该审核任务后将结果反馈至PBM服务器。PBM服务接收并识别该结果，若审核不通过，则结束并通知用户终端不能理赔；护着，若审核通过则向理赔管理服务器下发指令进行报案。

本示例实施方式中，参考图4所示，提供的一种基于院内购药的任务管理方法，可以包括：(1)用户通过用户终端上传理赔资料至PBM服务器，PBM服务器推送理赔信息至理赔管理服务器(CSS)，在提交身份证图片后，PBM服务器会解析识别身份证中的姓名及证件号信息与数据库中的保单数据核对，并反馈给用户终端核对结果是否为本人，同时需要用户进行人脸识别，将人脸照片发送至PBM服务器，服务器会识别图片是否为被保人同时是否具有生命体征，确保用户处于生存状态。(2)PBM服务器调用理赔管理服务器(CSS)报案规则校验；若校验通过，CCS进行报案，并进入第(3)步骤；若校验不通过，则返回用户终端通知用户，流程完成。(3)理赔管理服务器(CSS)基于核赔规则判断是否需要处方审核，如需处方审核，则通过报文方式通知PBM服务器系统以执行第(4)步骤；如不需处方审核，则调用LIC索赔申请接口，进入LIC理赔处理程序。(4)PBM服务器进行权益审核；若审核通过，进入第(5)步骤，若审核不通过，则通过报文通知理赔管理服务器(CSS)处方审核结论，理赔管理服务器(CSS)调用LIC索赔申请接口，进入LIC理赔处理程序。(5)PBM服务器根据产品配置是否自动处方审核通过；若自动审核通过，则进入第(6)步骤；若自动审核不通过，则进入人工处方审核程序，用户判断是否发审方审核；如是，则进入第(6)步骤；如否，则进入第(8)步骤。(6)PBM服务器发送报文到处方审核终端进行审方审核，审核完成后发送审方结论报文至PBM服务器。(7)PBM服务器接收审方审核报文。(8)用户在PBM服务器系统下发处方审核结论，发送理赔管理服务器(CSS)报案数据报文将处方审核相关信息更新到报案信息中，理赔服务终端(CSS)调用LIC索赔申请接口，进入LIC理赔处理流程。

应理解，图3和图4中的的PBM服务器并非是限定性的，任何其他适合的用户管理服务器也是可行的。

本公开各实施例所提供的方法中，通过信息化系统方式实现非接触式的报案理赔流程，节省客户大量时间，提升用户体验；提高公司的案件处理效率及节约人员成本，缩短理赔审核时间；通过系统方式统一，长期，有效的管理用户资料；防止被保人已去世仍然继续使用服务情况，降低理赔金额；通过信息技术手段将用户理赔审核流程信息化，简化报案、理赔程序，降低人工成本；通过该系统完成用户用药到医药企业的快速处方电子审核方式，用户到保险公司的快速理赔审核，将用户、医药企业、药店和保险公司的流程通过技术手段有效连接与业务打通。

需要注意的是，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

进一步的，参考图5所示，本示例的实施方式中还提供了一种数据管理系统，对应于上述的任务管理方法，系统可以包括：用户终端501、用户管理服务器502、处方审核终端503和理赔管理服务器504。其中，

用户终端501用于向用户管理服务器上传申请信息，以及接收所述用户管理服务器反馈的上述申请信息对应的核验结果；其中，所述申请信息包括第一购药申请信息和第二药品申请信息。

用户管理服务器502，用于响应所述用户终端发送的第一购药申请信息进行申请权限验证，以及响应所述用户终端发送的第二药品申请信息进行处方审核。

处方审核终端503，用于执行处方审核，并对用户终端对应的购药订单进行审核，并在所述购药订单审核通过时创建凭证信息；

理赔管理服务器504，用于处理用户对应的药品理赔监控任务。

在本示例实施方式中，上述的用户管理服务器502可以为PBM(Pharmacy BenefitManagement，药品福利管理系统)服务器。PBM服务器可以与用户终端501之间进行信息和数据的交互；同时，PBM服务器也可以与处方审核终端503、理赔管理服务器504之间进行控制指令的传递和数据的交互。

进一步的，参考图6所示，本示例的实施方式中还提供了一种任务管理装置60，包括：第一购药申请信息响应模块601、第二药品申请信息响应模块602、购药订单处理模块603。其中，

第一购药申请信息响应模块601，用于获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在用户申请权限核验完成后向所述用户终端反馈核验结果；

第二药品申请信息响应模块602，用于响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

购药订单处理模块603，用于获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

上述的任务管理装置60中各模块的具体细节已经在对应的任务管理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图7来描述根据本发明的这种实施方式的电子设备300。图7显示的电子设备300仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，电子设备300以通用计算设备的形式表现。电子设备300的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元320和处理单元310)的总线330。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元310执行，使得所述处理单元310执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元310可以执行如图1中所示方法。

存储单元320可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)3201和/或高速缓存存储单元3202，还可以进一步包括只读存储单元(ROM)3203。

存储单元320还可以包括具有一组(至少一个)程序模块3205的程序/实用工具3204，这样的程序模块3205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线330可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备300也可以与一个或多个外部设备600(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备300交互的设备通信，和/或与使得该电子设备300能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口350进行。并且，电子设备300还可以通过网络适配器360与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器360通过总线330与电子设备300的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

参考图8所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

此外，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (10)

1.一种任务管理方法，其特征在于，包括：

获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在所述用户申请权限核验完成后向所述用户终端反馈核验结果；

响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

2.根据权利要求1所述的方法，其特征在于，所述第一购药申请信息包括用户姓名、证件类型和证件号码；

所述基于所述第一购药申请信息对用户申请权限进行核验，包括：

利用预设证件核验规则对所述第一购药申请信息将进行核验，在核验通过时，生成核验通过信息，以及创建第二药品申请信息上传任务，并发送至所述用户终端；或者

在核验不通过时，生成核验未通过信息，以及创建第一图像采集任务并发送至所述用户终端，以使所述用户终端执行所述第一图像采集任务并采集证件图像；

识别所述用户终端上传的证件图像以提取第一证件数据，以及根据所述用户姓名向保单数据库中查询匹配的保单数据；根据所述保单数据中的第二证件数据与所述第一证件数据进行比对，生成证件数据比对结果；

基于上述证件数据比对结果生成人脸识别任务，并发送至所述用户终端，以使所述用户终端执行所述人脸识别任务并采集人脸图像；

获取所述用户终端上传的人脸图像，根据人脸图像确定用户的生存状态。

3.根据权利要求1所述的方法，其特征在于，所述第二药品申请信息包括：病例信息和处方信息；

所述基于所述第二药品申请信息进行处方审核，包括：

对所述病例信息和处方信息进行文本解析以提取目标关键字，以基于所述目标关键字对所述处方信息进行初次审核，并创建报案任务并发送至理赔管理服务器，以使所述理赔管理服务器创建对应的药品理赔监控任务；

基于初次审核结果生成二次审核任务并发送至处方审核终端以获取二次审核结果，并根据所述初次审核结果和所述二次审核结果生成处方审核信息。

4.根据权利要求3所述的方法，其特征在于，所述基于所述初次审核结果生成二次审核任务并发送至处方审核终端以获取二次审核结果，并根据所述初次审核结果和所述二次审核结果生成处方审核信息，包括：

在识别所述初次审核结果为初次审核通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果；在识别所述二次审核结果为二次审核通过时，同步所述二次审核结果和所述初次审核结果，并生成包含审核通过内容的处方审核信息；或者

在识别所述初次审核结果为初次审核不通过时，生成二次审核任务并发送至处方审核终端以获取二次审核结果，以及创建用户调查任务并发送至保单服务器，以使所述保单服务器执行所述用户调查任务查询用户历史信息并基于历史信息生成调查结果；基于上述二次审核结果、所述保单服务器反馈的调查结果和第二药品申请信息生成所述处方审核信息；

若所述处方审核信息包含审核未通过内容，则生成报案注销任务并发送所述理赔管理服务器以使所述理赔管理服务器注销所述药品理赔监控任务。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取用户终端上传的所述凭证信息，并发送至处方审核终端以获取所述处方审核终端对所述凭证信息的审核结果；

在所述审核结果包括核销成功时，激活对应的药品理赔监控任务以使理赔管理服务器处理所述药品理赔监控任务。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于所述用户终端发送的理赔请求，进行用户身份验证，并在身份验证通过时创建药品理赔监控任务，以使理赔管理服务器执行所述药品理赔监控任务对所述理赔请求进行核验；其中，所述对理赔请求审核包括处方核验；

获取所述理赔请求的核验结果，并在所述核验结果为核验通过时，向所述理赔管理服务器发送药品理赔监控任务更新信息，以使所述理赔管理服务器根据所述理赔任务更新信息调用索赔任务接口触发索赔处理流程。

7.一种任务管理系统，其特征在于，包括：

用户终端，用于向用户管理服务器上传申请信息，以及接收所述用户管理服务器反馈的上述申请信息对应的核验结果；其中，所述申请信息包括第一购药申请信息和第二药品申请信息；

用户管理服务器，用于响应所述用户终端发送的第一购药申请信息进行申请权限验证，以及响应所述用户终端发送的第药品二申请信息进行处方审核；

处方审核终端，用于执行处方审核，并对用户终端对应的购药订单进行审核，并在所述购药订单审核通过时创建凭证信息；

理赔管理服务器，用于处理用户对应的药品理赔监控任务。

8.一种任务管理装置，其特征在于，包括：

第一购药申请信息响应模块，用于获取用户终端发送的第一购药申请信息，基于所述第一购药申请信息对用户申请权限进行核验，并在所述用户申请权限核验完成后向所述用户终端反馈核验结果；

第二药品申请信息响应模块，用于响应于所述用户终端发送的第二药品申请信息，以基于所述第二药品申请信息进行处方审核，并生成处方审核信息发送至所述用户终端；

购药订单处理模块，用于获取所述用户终端的购药信息并生成对应的购药订单，以对所述购药订单进行审核，并在所述购药订单审核通过时创建凭证信息，将所述凭证信息进行存储并发送至所述用户终端。

9.一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现根据权利要求1至6中任一项所述的任务管理方法。

10.一种电子终端，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至6中任一项所述的任务管理方法。

Images