CN112466454B - 一种开方数据处理方法和装置 - Google Patents

Abstract

本申请提供了一种开方数据处理方法和装置，其中，该方法包括：接收开方请求；根据预设规则确定满足所述开方请求的互联网医院列表；获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院；将所述开方请求分配至所述目标互联网医院；在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。通过上述方案解决了现有的开方是一对一固定绑定的所导致的开方效率低，开方质量难以保证的问题，达到了有效提升开方效率和开方质量的技术效果。

Description

一种开方数据处理方法和装置

技术领域

本申请属于互联网技术领域，尤其涉及一种开方数据处理方法和装置。

背景技术

目前，商家与互联网医院之间，一般是商家与某一个互联网医院签约，在商家有处方药订单的情况下，就将该订单发送至该签约的互联网医院，由互联网医院分配医生针对该订单开处方。即，通过签约的一家互联网医院为商家的处方药订单提供开方服务。

然而，这种开方方式，导致主动权在互联网医院，这样导致开方的效率和质量得不到保障。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请目的在于提供一种开方数据处理方法和装置，可以提高开方效率和开方质量。

本申请提供一种开方数据处理方法和装置是这样实现的：

一种开方数据处理方法，包括：

接收开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

一种开方数据处理装置，包括：

接收模块，用于接收开方请求；

确定模块，用于根据预设规则确定满足所述开方请求的互联网医院列表；

获取模块，用于获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

分配模块，用于将所述开方请求分配至所述目标互联网医院；

开方模块，用于在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

一种服务端设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下方法的步骤：

接收开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现如下方法的步骤：

接收开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

本申请提供的开方数据处理方法和装置，在接收到申请开方请求之后，不是直接通过固定的某一个医院进行开方，而是获取能满足该开方请求的互联网医院列表，然后根据实时忙闲度和/或开方质量等确定出一个网院作为目标网院，将开方请求分配至该目标网院，通过该互联网医院中的医生完成开方，通过这种方式可以解决现有的开方是一对一固定绑定的所导致的开方效率低，开方质量难以保证的问题，达到了有效提升开方效率和开方质量的技术效果。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的开方系统的架构图；

图2是本申请提供的智能调度派单跟踪方案的逻辑示意图；

图3是本申请提供的开方数据处理方法的一种实施例的方法流程图；

图4是本申请提供的一种开方数据处理方法的服务器端的硬件结构框图；

图5是本申请提供的开方数据处理装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

在通过互联网购药的时候互联网问诊的时候，互联网医院作为处方供及侧，处方药订单（商家）作为处方需求侧，商家将处方药订单发送给互联网医院请求开方。当前商家与互联网医院是签约的方式，一个商家仅与一个互联网医院签约，即，处方药订单是直接被分配至签约的医院的，不存在对效率和质量的判断，这样就导致如果该互联网医院开方效率低、开方质量低，没有有效的监督机制。

基于此，在本例中提供了一种开方系统，如图1所示，可以包括：用户端101（用户端1、用户端2…用户端）、电商商家端102（电商商家1、电商商家2…电商商家m）、分配服务器103、互联网医院端104（互联网医院1…互联网医院x）。

用户端101通过电商平台，在电商商家处购药，例如：购买处方药，针对处方药需要具备处方，因此，电商商家端可以与互联网医院端104进行合作，在存在开方需求的情况下，可以将该开方需求发送至互联网医院端104。具体的，电商商家端102可以向分配服务器103发送请求开具处方，然后分配服务器103将该开具处方的请求基于规则分配至合适的互联网医院开具处方，由互联网医院端104完成开方，并将开具的处方返回至电商商家端。

在本例中，设置了分配服务器103，分配服务器103与电商商家端102和互联网医院端104进行通信，并按照预设的分配规则，将电商商家端102的开方请求分配至合适的互联网医院端104。具体的，分配服务器103可以通过智能调度派单跟踪方案进行派单，如图2所示，分配服务器103，可以是调度引擎，根据派单规则、互联网医院的开方指标和医生的开方指标，动态地将处方药订单分派给某个互联网医院的某个医生进行开方，从而提高处方质量的合格率。同时可以淘汰一些开方效率低，或者是开方质量差的互联网医院，从而提升开方效率和开方质量。

在实现的时候，可以设置互联网医院的ID列表，在列表中记录有多个互联网医院（如：互联网医院1、互联网医院2……互联网医院n），这些互联网医院都是可供匹配以提供开方服务的互联网医院。

图2是本申请提供的智能调度派单跟踪方案的逻辑示意图，如图2所示，从产品流程的角度考量，创建处方药订单，然后申请开方，进入集合导诊派单，互联网医院接单，然后派单给医生，从而开方完成。对于聚合导诊派单实现模块而言，要进行智能调度派单，具体的，需要依据规则组（规则优先级、医院&商家优先级、自杀人群倾向、高危诊断等），依据医院指标（医院忙闲度、医生开方质量评分、医院开方时长、指标动态派单），依据医生指标（医生外呼率、外呼接通率、开方拒方率、开方时长、开方合格率、质检评分）。聚合导诊派单实现模块需要调度引擎，通过引擎可以进行规则解析、指标实时统计、指标计算、动态派单和派单追溯。基础模型可以包括：签约规则库、诊断库、患者人群行为属性、处方质检库和医院医生指标库。通过聚合导诊派单实现可以将开方请求分配至多个互联网医院（互联网医院1、互联网医院2、互联网医院3…互联网医院N）中的一个。

具体的，ID列表可以基于全局规则和自定义规则形成：

其中，全局规则就是整体的，针对每个商家共用的规则，例如，针对特定药品（例如：精神类用药）需要分派到某一个或多个网院，即，只有这些互联网医院可以对特定药品开处方。自定义规则是针对每个商家和互联网医院单独个性化设置的规则，例如，商家和互联网医院可以设置多对多的签约方式，其中，签约方式可以包括：独家、优先、默认等方式，如果签署了独家，那么该商家的开方请求尽量都是通过签署了独家这个的医院处理，如果是签署了优先，那么就为该商家的开方请求优先匹配该医院。这三种方式的优先级顺序为：独家>优先>默认。

例如，在具体实现的时候，商家A与医院B签署了独家，那么在商家A存在开方请求的时候，先判断该开方请求中的药品是否为高危药品（例如，可以通过药品ICDCode值来判断），如果该药品属于高危药品，那么将该开方请求发送至特定互联网医院进行开方处理，如果不是高危药品，那么将该开方请求发送至医院B进行开方处理。

即，上述的全局规则和自定义规则可以是叠加判断的，以实现开方请求的合理分发。

在为开方请求分配互联网医院的时候，可以根据各互联网医院的忙闲度值，一个各网互联网医院的开方质量，确定将该开方请求分配到哪个互联网医院。

具体的，可以实时统计各互联网医院的指标参数，例如：网院接单数量、待开方数量、开方各状态数量（例如随防，外呼）、开方成功数量、开方失败数量、医生上班数量、上班时间段人数等指标项。

然后根据预先建立的忙闲度估算模型，把上述指标参数值输入该忙闲度估算模型，从而得到各互联网医院的忙闲度值。进一步的，可以基于各医院的历史开方数据，通过预设的合理用药规则，计算出各医院的开方合格率，并基于预设规则（例如：权重值）得到各医院的开方质量分数。

在实现的时候，可以筛选出可以为当前开方请求提供开方服务的医院的ID列表，然后，确定出ID列表中各医院的忙闲度值和开方质量指标，基于ID列表中各医院的忙闲度值和开方质量指标求取将该开单请求分配至哪个医院的最优解，即，确定出目标医院的ID，从而将开方请求发送至该医院进行开方处理。

因为医院中一般是由多个医生的，在将开方请求分配至某个医院后，还需要分配至具体的医生。具体的，可以在开方请求被分配到某个医院后，可以根据医院中各医生的服务指标分数，将开方申请单派单给某个医生去开方。

其中，为了计算医生的服务指标分数，可以获取医生的指标项，其中，指标项可以包括：关键指标和非关键指标两类，其中，关键指标可以包括：接单数量、平均开方时长、开方合格率、开方成功率、外呼率等；非关键指标可以包括：医生上下班时长、随防数量、外呼数量、外呼时长、开方成功和失败数量、外呼拒单率等指标。

然而，值得注意的是上述所列举的指标项仅是一种示例性描述，在实际实现的时候，还可以包括其他的指标项，对此，本申请不作具体限定，只要是可以对医生的服务进行评价的参数都可以作为指标项。

具体的，可以为上述关键指标和非关键指标分别建立一个估算模型，将上述收集的指标项值带入到建立的估算模型中，得到各医生关键指标的得分A和非关键指标的得分B。假设关键服务指标分数A 权重 80%，非关键指标分数B权重20%，那么可以通过加权累加的方式，计算出该医生最终的服务指标分数。选取服务指标分数高的医生作为目标医生，将该开方申请单派单给该医生。

在将开方申请单派单给某个医生后，可以对时间进行监控，如果超过预设时长没有开方，那么可以二次派单至该医院的别的医生开方，以避免开方效率低下导致的用户体验差的问题，使得每个开方申请单都可以及时被处理。

具体的，可以提供调度执行引擎，该调度执行引擎可以提供规则解析、指标实时统计和计算的功能，根据不同维度的预测值派单给互联网医院和医生，并在超时未开方的时候，冲洗进行调度派单，并提供派单记录的明细追溯和实时监控等能力。

例如，可以根据后台配置签约规则和全局规则，在发起开方申请时，根据查询商家和互联网医院的签约规则（例如：通过商家和互联网医院的签约优先级、药品危险等级、患者是否有自杀倾向，是否高危人群等派单规则），以及商家自己配置的优先级规则记性计算，并记录日志明细。 调度执行引擎的后台统计互联网医院和医生的指标项，并实时收集互联网医院上报的指标项，通过预设的计算，并记录中间环节日志明细。

基于记录的日志明细，可以实现对互联网医院和医生的实时大盘监控，例如，各互联网医院的接单率、平均开方时长、开方成功率等，并提供单个开方申请单的派单明细查询和追溯，以及超时未开方二次派单能力。即，通过对多个规则指标的组合使用、运算、综合筛选、过滤、统计、计算、监控等，实现动态派单和处方订单可追溯 。

在上例中，通过互联网医院的历史开方数据分析，例如：医院医生开方合格率，外呼率，开方时长，拒方率，医生上线时长等指标综合评分得出网院服务质量排名分数。基于多维度指标规则组合使用，多级派单调度，超时未开方重新派单调度，开方指标监控分析，追溯订单开方节点。同时，通过对互联网医院开方记录进行实时和归档数据可视化统计分析，考核网院服务质量、淘态不合格或者不复杂的互联网医院并引入新的优质的互联网医院，从而有利于整个系统的健康稳定发展。通过实时统计商家在一段时间内的处方订单分派给哪些网院、开方时长、合格率、拒方率、外呼率、审核率等指标，可以为商家选择合作医院提供参考。

图3是本申请提供的开方数据处理方法的一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行（例如并行处理器或者多线程处理的环境，甚至分布式处理环境）。

具体的，如图3所示，该开方数据处理方法可以包括如下步骤：

步骤301：接收开方请求；

例如，电商商家A接收到用户B购买处方药的申请，因为购买的是处方药，那么就需要具备药方，在这种情况下，电商商家A就会产生一个开方请求，电商商家A可以将该开方请求传送至分配服务器，在分配服务器中设置一套分配规则，基于设置的分配规则可以将该开方请求分配至合适的互联网医院进行处理。

步骤302：根据预设规则确定满足开方请求的互联网医院列表；

具体的，在确定满足所述开方请求的互联网医院列表的时候，可以按照是否与发起开方请求的商家进行签约为判断条件，或者是，以开方请求所请求开的药品是否属于非常规要求为判断条件，以得到一个可以为该开方请求服务的互联网医院的列表。

例如：可以确定所述开方请求所属的商家是否存在具备签约关系的互联网医院；在确定存在具备签约关系的互联网医院的情况下，将具备签约关系的互联网医院的集合作为满足所述开方请求的互联网医院列表。或者，确定所述开方请求所请求开方的药品是否位于预设的非常规药品列表中；在确定所请求开方的药品位于预设的非常规药品列表中的情况下，调取预设的为该药品设置的互联网医院列表；将为该药品设置的互联网医院列表，作为满足所述开方请求的互联网医院列表。

举例而言，针对一些特殊药品，例如精神类药品，不是每个医院都可以开处方的，需要专门的医院开具处方，为此，可以预先建立一个医院名单或者是医院ID列表，在该列表中存储有一个或多个可开特殊药品处方的医院。在获取到待分配开方请求后，可以先确定所述待分配开方请求中所请求开方的药品是否属于预设的非常规药品，如果所请求开方的药品为非常规药品的，那么就获取预设的非常规药品网院列表，作为满足开方要求的互联网医院列表。

有些请求开方的用户或者是病人本身是属于特殊疾病，针对这种人群，也需要专门的医院开具处方，为此，可以预先建立一个医院名单或者是医院ID列表，在该列表中存储有一个或多个可为特殊人群开具处方的医院。在获取到待分配开方请求后，可以先确定所述待分配开方请求中请求开方的用户是否属于非常规用户；在确定请求开方的用户属于非常规用户的情况下，那么就获取预设的非常规药品网院列表，作为满足开方要求的互联网医院列表。

在实际的应用场景中，商家可以与多个互联网医院签订合约，即，这些网院是该商家的开方请求的签约网院，可以该网院列表作为满足开方要求的互联网医院列表。

步骤303：获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

上述的医院的实时忙闲度可以通过如下的指标数据确定，例如：接单数量、待开方数量、开方成功数量、开方失败数量、医生数量、上班时段坐班医生的数量等；医院的开方质量可以通过如下的指标数据确定，例如：开方合格率、外呼率、开方时长、拒方率等。

步骤304：将所述开方请求分配至所述目标互联网医院；

步骤305：在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

在将开方请求派单至所述目标互联网医院中的医生的时候，可以确定所述目标互联网医院中满足所述开方请求的医生列表；获取所述医生列表中各医生的状态数据（例如：实时忙闲度和/或开方质量等）；根据各医生的状态数据，确定目标医生；将所述开方请求派单至所述目标医生，通过所述目标医生完成开方。

其中，上述医生的实时忙闲度可以根据如下数据确定：接单数量、平均开方时长、开方合格率、开方成功率、外呼率、上下班时长、随防数量、外呼数量、外呼时长等，上述医生的开方质量可以根据如下数据确定：开方成功数量、开方失败数量、外呼拒单率等。

具体的，在获取所述互联网医院列表中各医院的实时忙闲度和/或开方质量，根据各医院的实时忙闲度和/或开方质量，确定目标互联网医院的时候，可以调用预先建立的系统忙闲度计算模型，计算所述互联网医院列表中各医院的实时忙闲度；根据预设的合理用药规则，计算所述互联网医院列表中各医院的开方质量；计算各医院的实时忙闲度和开方质量的方差，以确定出最优解的互联网医院；将最优解的互联网医院作为所述目标互联网医院。

例如，可以将互联网医院列表中各个医院的实时忙闲度和开方质量输入至预设的模型中，对各个互联网医院进行打分，将得分最高的医院确定该开方请求要分配至的网院。且可以为每个开方指标数据设置权重值，根据加权求和的方式得到每个目标节点的得分。或者是建立一个分类模型，将获取的开方指标数据直接输入至模型中，就可以输出最优的互联网医院。具体采用哪种方式从互联网医院列表中选择一个医院作为确定的目标医院。

考虑到在实际的开方过程中，将开方请求分配至医院或者医生之后，医院或者医生可能因为一些因素，导致迟迟没有时间处理该开方请求，这样就会导致该开方请求长时间得不到处理。为此，可以设置一个超时时间机制，例如，设置超时时长为20分钟，如果在开方请求被分配20分钟后，未收到医院或者医生所开具的处方，那么就重新为该开方请求分配医生，从而可以避免开方请求长时间不被处理的问题。具体的，在将所述待分配开方请求，分配至医院后，可以确定是否在预定时长内，未完成开方；如果在预定时长内，未完成开方，重新分配所述待分配开方请求。

本申请上述实施例所提供的方法实施例可以在服务器端、计算机终端或者类似的运算装置中执行。以运行在服务器端上为例，图4是本申请提供的一种开方数据处理方法的服务器端的硬件结构框图。如图4所示，服务器端10可以包括一个或多个（图中仅示出一个）处理器102（处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置）、用于存储数据的存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器端10还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的开方数据处理方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的开方数据处理方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输模块106包括一个网络适配器（Network Interface Controller，NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块106可以为射频（Radio Frequency，RF）模块，其用于通过无线方式与互联网进行通讯。

在软件层面，上述开方数据处理装置可以如图5所示，包括：

接收模块501，用于接收开方请求；

确定模块502，用于根据预设规则确定满足所述开方请求的互联网医院列表；

获取模块503，用于获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

分配模块504，用于将所述开方请求分配至所述目标互联网医院；

开方模块505，用于在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

在一个实施方式中，上述确定模块502可以包括：获取单元，用于确定所述开方请求所属的商家是否存在具备签约关系的互联网医院；生成单元，用于在确定存在具备签约关系的互联网医院的情况下，将具备签约关系的互联网医院的集合作为满足所述开方请求的互联网医院列表。

在一个实施方式中，获取模块503可以包括：调用单元，用于调用预先建立的系统忙闲度计算模型，计算所述互联网医院列表中各医院的实时忙闲度；第一计算单元，用于根据预设的合理用药规则，计算所述互联网医院列表中各医院的开方质量；第二计算单元，用于计算各医院的实时忙闲度和开方质量的方差，以确定出最优解的互联网医院；确定单元，用于将最优解的互联网医院作为所述目标互联网医院。

在一个实施方式中，上述确定模块502具体可以用于确定所述开方请求所请求开方的药品是否位于预设的非常规药品列表中；在确定所请求开方的药品位于预设的非常规药品列表中的情况下，调取预设的为该药品设置的互联网医院列表；将为该药品设置的互联网医院列表，作为满足所述开方请求的互联网医院列表。

在一个实施方式中，上述开方模块505具体可以用于确定所述目标互联网医院中满足所述开方请求的医生列表；获取所述医生列表中各医生的状态数据；根据各医生的状态数据，确定目标医生；将所述开方请求派单至所述目标医生，通过所述目标医生完成开方，其中，医生的状态数据至少包括：实时忙闲度和/或开方质量。

在一个实施方式中，上述获取模块503具体可以用于调用预先建立的系统忙闲度计算模型，计算所述互联网医院列表中各医院的实时忙闲度；根据预设的合理用药规则，计算所述互联网医院列表中各医院的开方质量；计算各医院的实时忙闲度和开方质量的方差，以确定出最优解的互联网医院；

将最优解的互联网医院作为所述目标互联网医院。

在一个实施方式中，上述开方数据处理装置在将开方请求派单至所述目标互联网医院中的医生之后，还可以确定是否在预定时长内，未收到返回的开方结果；如果在预定时长内未收到返回的开方结果，重新分配所述开方请求。

其中，上述用户端可以是客户操作使用的终端设备或者软件。具体的，用户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能手表或者其它可穿戴设备等终端设备。当然，用户端也可以是能运行于上述终端设备中的软件。例如：手机淘宝、支付宝或者浏览器等应用软件。

本申请的实施例还提供能够实现上述实施例中的开方数据处理方法中全部步骤的一种电子设备的具体实施方式，所述电子设备具体包括如下内容：处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的开方数据处理方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤1：接收开方请求；

步骤2：根据预设规则确定满足所述开方请求的互联网医院列表；

步骤3：获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

步骤4：将所述开方请求分配至所述目标互联网医院；

步骤5：在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

从上述描述可知，本申请实施例在接收到申请开方请求之后，不是直接通过固定的某一个医院进行开方，而是获取能满足该开方请求的互联网医院列表，然后根据实时忙闲度和/或开方质量等确定出一个网院作为目标网院，将开方请求分配至该目标网院，通过该互联网医院中的医生完成开方，通过这种方式可以解决现有的开方是一对一固定绑定的所导致的开方效率低，开方质量难以保证的问题，达到了有效提升开方效率和开方质量的技术效果。

本申请的实施例还提供能够实现上述实施例中的开方数据处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的开方数据处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤1：接收开方请求；

步骤2：根据预设规则确定满足所述开方请求的互联网医院列表；

步骤3：获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

步骤4：将所述开方请求分配至所述目标互联网医院；

步骤5：在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方。

从上述描述可知，本申请实施例在接收到申请开方请求之后，不是直接通过固定的某一个医院进行开方，而是获取能满足该开方请求的互联网医院列表，然后根据实时忙闲度和/或开方质量等确定出一个网院作为目标网院，将开方请求分配至该目标网院，通过该互联网医院中的医生完成开方，通过这种方式可以解决现有的开方是一对一固定绑定的所导致的开方效率低，开方质量难以保证的问题，达到了有效提升开方效率和开方质量的技术效果。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行（例如并行处理器或者多线程处理的环境）。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行（例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境）。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (11)

1.一种开方数据处理方法，其特征在于，所述方法包括：

接收电商商家的开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方；

其中，根据预设规则确定满足所述开方请求的互联网医院列表包括：基于全局规则和自定义规则，确定满足所述开方请求的互联网医院列表。

2.根据权利要求1所述的方法，其特征在于，根据预设规则确定满足所述开方请求的互联网医院列表，包括：

确定所述开方请求所属的商家是否存在具备签约关系的互联网医院；

在确定存在具备签约关系的互联网医院的情况下，将具备签约关系的互联网医院的集合作为满足所述开方请求的互联网医院列表。

3.根据权利要求1所述的方法，其特征在于，根据预设规则确定满足所述开方请求的互联网医院列表，包括：

确定所述开方请求所请求开方的药品是否位于预设的非常规药品列表中；

在确定所请求开方的药品位于预设的非常规药品列表中的情况下，调取预设的为该药品设置的互联网医院列表；

将为该药品设置的互联网医院列表，作为满足所述开方请求的互联网医院列表。

4.根据权利要求1所述的方法，其特征在于，将所述开方请求派单至所述目标互联网医院中的医生，包括：

确定所述目标互联网医院中满足所述开方请求的医生列表；

获取所述医生列表中各医生的状态数据，其中，各医生的状态数据至少包括：实时忙闲度和/或开方质量；

根据各医生的状态数据，确定目标医生；

将所述开方请求派单至所述目标医生，通过所述目标医生完成开方。

5.根据权利要求1所述的方法，其特征在于，获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，包括：

调用预先建立的系统忙闲度计算模型，计算所述互联网医院列表中各医院的实时忙闲度；

根据预设的合理用药规则，计算所述互联网医院列表中各医院的开方质量；

计算各医院的实时忙闲度和开方质量的方差，以确定出最优解的互联网医院；

将最优解的互联网医院作为所述目标互联网医院。

6.根据权利要求1所述的方法，其特征在于，在将所述开方请求派单至所述目标互联网医院中的医生之后，还包括：

确定是否在预定时长内，未收到返回的开方结果；

如果在预定时长内未收到返回的开方结果，重新分配所述开方请求。

7.一种开方数据处理装置，其特征在于，包括：

接收模块，用于接收电商商家的开方请求；

确定模块，用于根据预设规则确定满足所述开方请求的互联网医院列表；

获取模块，用于获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，所述状态数据至少包括：实时忙闲度和/或开方质量；

分配模块，用于将所述开方请求分配至所述目标互联网医院；

开方模块，用于在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方；

其中，根据预设规则确定满足所述开方请求的互联网医院列表包括：基于全局规则和自定义规则，确定满足所述开方请求的互联网医院列表。

8.根据权利要求7所述的装置，其特征在于，所述确定模块包括：

获取单元，用于确定所述开方请求所属的商家是否存在具备签约关系的互联网医院；

生成单元，用于在确定存在具备签约关系的互联网医院的情况下，将具备签约关系的互联网医院的集合作为满足所述开方请求的互联网医院列表。

9.根据权利要求7所述的装置，其特征在于，所述获取模块包括：

调用单元，用于调用预先建立的系统忙闲度计算模型，计算所述互联网医院列表中各医院的实时忙闲度；

第一计算单元，用于根据预设的合理用药规则，计算所述互联网医院列表中各医院的开方质量；

第二计算单元，用于计算各医院的实时忙闲度和开方质量的方差，以确定出最优解的互联网医院；

确定单元，用于将最优解的互联网医院作为所述目标互联网医院。

10.一种服务端设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下方法的步骤：

接收电商商家的开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方；

其中，根据预设规则确定满足所述开方请求的互联网医院列表包括：基于全局规则和自定义规则，确定满足所述开方请求的互联网医院列表。

11.一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现如下方法的步骤：

接收电商商家的开方请求；

根据预设规则确定满足所述开方请求的互联网医院列表；

获取所述互联网医院列表中各医院的状态数据，根据各医院的状态数据，确定目标互联网医院，其中，状态数据至少包括：实时忙闲度和/或开方质量；

将所述开方请求分配至所述目标互联网医院；

在确定所述目标互联网医院接单的情况下，将所述开方请求派单至所述目标互联网医院中的医生，以通过所述目标互联网医院中的医生完成开方；

其中，根据预设规则确定满足所述开方请求的互联网医院列表包括：基于全局规则和自定义规则，确定满足所述开方请求的互联网医院列表。

Images