CN116977023A - 一种售药方法、售药平台及自动售药终端 - Google Patents

Abstract

本申请涉及一种售药方法、售药平台及自动售药终端，售药平台获取到药品订单后可以生成并向自动售药终端发送出货信息，自动售药终端可以根据出货信息中包含的药品识别信息自动拣选药品并出货。针对购药者的药品订单，不用药店内的工作人员在药店内人工配货，而是由自动售药终端进行药品仓储，并自动根据需求从其仓储的药品中进行药品拣选与出货，自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。而且，自动售药终端无须人工值守，有利于降低药品销售成本。

Description

一种售药方法、售药平台及自动售药终端

技术领域

本申请涉及无人零售领域，尤其是涉及一种售药方法、售药平台及自动售药终端。

背景技术

随着互联网技术的飞速发展，人们的生活越发便利，大到房、车，小到日用品都可以通过线上购物的方式实现选购。以药品购买为例，目前药品的线上订单逐年增加，线下的购药订单逐步向线上订单转移，这主要是由于购药者购买药品时也大概率是正是其不便出行的时候，所以线上购药并由配送平台配送至购药者所在处，这样可以极大地方便购药者。不过目前线上购药主要依赖于线下药店来配货，购药订单的完成时间很大程度取决于配货药店与消费者间的距离。线下药店并非全都支持24小时营业，例如在夜间大部分线下药店打烊，购药订单需要从距离购药者较远的药店配货，这样极大地降低了订单配送效率；而且在一些相对偏远的地区，药店数量本身就比较少，大量开设药店并安排工作人员值守并不现实，所以这些地区即便是线上购药的便捷程度也不高，导致用药者无法及时用药，容易出现延误用药者的病情的问题。

发明内容

为了解决相关技术中线上购药的配货依赖于线下药店，容易出现购药效率低，用药者不能及时用药的问题，本申请提供一种售药方法、售药平台及自动售药终端。

第一方面，本申请提供一种售药方法，所述售药方法包括：

获取药品订单，所述药品订单中包含待购药品的药品识别信息；

根据所述药品订单生成出货信息，所述出货信息中包含所述药品识别信息；

向自动售药终端发送所述出货信息，以供所述自动售药终端根据所述出货信息出货。

通过采用上述技术方案，售药平台获取到药品订单后可以生成并向自动售药终端发送出货信息，自动售药终端可以根据出货信息中包含的药品识别信息自动拣选药品并出货。针对购药者的药品订单，不用药店内的工作人员在药店内人工配货，而是由自动售药终端进行药品仓储，并自动根据需求从其仓储的药品中进行药品拣选与出货，自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。而且，自动售药终端无须人工值守，有利于降低药品销售成本。

可选地，所述获取包含药品识别信息的药品订单包括以下几种中的任意一种：

方式一：接收用户终端与所述自动售药终端中至少一个发送的购药请求，所述购药请求中包含所述待购药品的药品识别信息；根据所述购药请求进行计价核算，并向所述购药请求的发送端返回支付入口信息；在完成支付验证后根据所述购药请求生成所述药品订单；

方式二：接收第三方购物平台发送的所述药品订单，所述药品订单由所述第三方购物平台在购药者完成药品选择与药品支付后生成。

通过上述技术方案，售药平台支持从第三方购物平台上接收药品订单，也支持从自动售药终端与用户终端中的任意一个处接收购药请求并基于购药请求生成药品订单，可以理解的是，售药平台支持多种获取药品订单的途径，实际上也是向购药者提供了多种可选的购药途径，这样可以方便购药者根据自己的实际情况灵活选择更便于实施的方式来购药，提升了购药的方便程度与灵活程度，有利于增强用户体验。

可选地，所述获取药品订单之后，还包括：为所述药品订单生成药品取货码，将所述药品取货码发送给配送平台或所述用户终端；

所述根据所述药品订单生成出货信息包括：生成同时包含所述药品识别信息与所述药品取货码的所述出货信息。

通过采用上述技术方案，售药平台可以为药品订单生成药品取货码，让购药者或者配送人员凭药品取货码到自动售药终端上取货，实现药品的购取分离，让购药者可以更灵活地安排购药事宜。

可选地，所述获取药品订单之后，根据所述药品订单生成出货信息之前，还包括：

为所述药品订单生成药品取货码，将所述药品取货码发送给配送平台或所述用户终端；

接收所述自动售药终端发送的取货码验证请求，所述取货码验证请求中包含待验证取货码；

根据所述药品取货码对所述待验证取货码进行验证；

所述根据所述药品订单生成出货信息包括：在验证通过后生成包含所述药品识别信息的所述出货信息。

通过采用上述技术方案，售药平台可以为药品订单生成药品取货码，让购药者或者配送人员凭药品取货码到自动售药终端上取货，实现药品的购取分离，让购药者可以更灵活地安排购药事宜。

可选地，所述向自动售药终端发送所述出货信息之后，还包括：

生成针对所述自动售药终端的补货信息；

向药企系统发送所述补货信息，以请求药企对所述自动售药终端进行补货，所述补货信息中包含待补货药品的药品识别信息以及所述自动售药终端的终端识别信息。

通过上述技术方案，售药平台与药企系统通信连接，售药平台可以对自动售药终端的库存进行监测，在需要的时候生成补货信息发送给药企系统，让药企工作人员可以及时通过药企系统了解自动售药终端上的缺货情况，并安排对自动售药终端的补货事宜。

可选地，接收到所述购药请求后，根据所述购药请求进行计价核算之前还包括：

根据所述药品识别信息对所述待购药品进行类型识别，所述类型包括处方药与非处方药；

在识别到所述待购药品中包含处方药的情况下，向互联网医院发送问诊请求，以请求所述互联网医院分派医生对所述发送端的购药者进行问诊并开具所述处方药对应的处方信息；

获取并保存所述处方信息。

通过采用上述技术方案，售药平台接收到所述购药请求后，可以对待购药品的类别进行识别，如果确定待购药品中包含处方药，则售药平台可以向互联网医院发送问诊请求，以请求互联网医院分派医生对发送端的消费者进行问诊并开具处方药对应的处方信息，在问诊完成后，售药平台可以获取并保存处方信息，实现药品售卖的规范管理。另一方面，购药者在购药之前可以不必对待购药品的类型进行区分，更不必去医院挂号请求医生开具处方，这不仅减少了购药者的时间消耗与精力消耗、金钱消耗，也节约了医疗资源，使得线下医疗资源可以更多地用于必须面诊的患者。

第二方面，本申请提供一种售药方法，所述售药方法包括：

接收售药平台根据药品订单生成的出货信息，所述出货信息中包含待购药品的药品识别信息；

根据所述药品识别信息自动拣选药品并出货。

通过采用上述技术方案，自动售药终端可以接收售药平台发出的出货信息，根据出货信息中包含的药品识别信息自动拣选药品并出货。针对购药者的药品订单，不用药店内的工作人员在药店内人工配货，而是由自动售药终端进行药品仓储，并自动根据需求从其仓储的药品中进行药品拣选与出货，自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。而且，自动售药终端无须人工值守，有利于降低药品销售成本。

可选地，所述接收售药平台根据药品订单生成的出货信息之前，还包括：

检测针对待购药品的购买操作；

根据所述购买操作生成购药请求，所述购药请求中包含所述待购药品的药品识别信息；

将所述购药请求发送给所述售药平台；

接收所述售药平台发送的支付入口信息并将所述支付入口信息对应的支付入口提供给消费者，以使所述消费者通过所述支付入口进行支付操作。

通过采用上述技术方案，自动售药终端本身可以支持购药者进行购药操作，购药者可以直接通过与自动售药终端进行人机交互实现药品的选购与支付，这样便于没有携带或不习惯使用手机等移动终端的用户购药。而且购药者在自动售药终端上购买药品时，在自动售药终端出货后，无需另外召唤配送人员配送购药者即可直接取得药品。

可选地，所述将所述购药请求发送给所述售药平台之后，还包括：

接收所述售药平台发送的问诊接口信息；

根据所述问诊接口信息接入互联网医院，以供所述互联网医院的医生对所述消费者进行问诊并开具所述待购药品中处方药对应的处方信息。

通过上述技术方案，如果购药者的待购药品中包含处方药，售药平台可以向自动售药终端发送包含问诊接口的问诊接口信息，自动售药终端接收到问诊接口信息后，可以让购药者通过问诊接口与互联网医院的医生交互，以使互联网医生实现对购药者的问诊，并实现处方开具。通过该技术方案，购药者在购药之前可以不必对待购药品的类型进行区分，更不必去医院挂号请求医生开具处方，这不仅减少了购药者的时间消耗与精力消耗、金钱消耗，也节约了医疗资源，使得线下医疗资源可以更多地用于必须面诊的患者。

可选地，所述根据所述药品识别信息拣选药品并出货之前，还包括：

通过输入模块接收待验证取货码；

对所述待验证取货码进行验证；

在验证通过后，根据所述药品识别信息进行出货。

通过采用上述技术方案，自动售药终端可以通过自己的输入模块接收待验证取货码，并在对待验证取货码进行验证后，对该待验证取货码对应的药品进行出货。该方案适用于购药者通过手机、平板台式电脑等用户终端购药后，自行或者召唤配送人员到自动售药终端处取药的场景，所以本申请实施例所提供的售药方法，面向购药者提供远程购药的途径、延时取药与凭码取药的服务，让购药者可以灵活安排取药时间与取药人员，提升了用户体验。

可选地，所述对所述待验证取货码进行验证包括以下任意一种：

方式一：从所述售药平台发送的所述出货信息中提取药品取货码；根据所述药品取货码对所述待验证取货码进行验证；

方式二：将所述待验证取货码发送至所述售药平台，以供所述售药平台根据药品取货码对所述待验证取货码进行验证；接收所述售药平台发送的验证结果。

第三方面，本申请提供一种售药平台，包括第一处理器、第一存储器以及第一通信总线，所述第一通信总线用于实现所述第一处理器与所述第一存储器之间的通信连接，所述第一处理器用于执行存储在所述第一存储器中的第一计算机程序，以实现前述第一方面中任一项所述的售药方法。

第四方面，本申请提供一种自动售药终端，包括第二处理器、第二存储器、拣选机构、仓储柜以及第二通信总线，所述第二存储器、所述拣选机构分别通过所述第二通信总线同所述第二处理器通信连接，所述仓储柜用于存放待售卖的药品，所述拣选机构用于在所述第二处理器的控制下从所述仓储柜中拣选药品；所述第二处理器用于执行存储在所述第二存储器中的第二计算机程序，以实现前述第二方面中任一项所述的售药方法。

通过上述技术方案，自动售药终端中包括存放待售卖药品的仓储柜，以及可以在处理器的控制下对仓储柜中药品进行拣选出货的拣选机构，同时该自动售药终端的处理器还能执行计算机程序以实现前述任一项的售药方法，所以该自动售药终端可以接收售药平台发出的出货信息，根据出货信息中包含的药品识别信息自动拣选药品并出货。针对购药者的药品订单，不用药店内的工作人员在药店内人工配货，而是由自动售药终端进行药品仓储，并自动根据需求从其仓储的药品中进行药品拣选与出货，自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。而且，自动售药终端无须人工值守，有利于降低药品销售成本。

第五方面，本申请提供一种售药系统，包括上述的售药平台以及多台上述自动售药终端，所述自动售药终端与所述售药平台通信连接。

通过上述技术方案，售药平台可以获取包含待购药品之药品识别信息的药品订单，然后根据所述药品订单生成包含药品识别信息的出货信息，并向自动售药终端发送该出货信息。自动售药终端接收到售药平台发出的出货信息后，根据出货信息中包含的药品识别信息自动拣选药品并出货。针对购药者的药品订单，不用药店内的工作人员在药店内人工配货，而是由自动售药终端进行药品仓储，并自动根据需求从其仓储的药品中进行药品拣选与出货，自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。而且，自动售药终端无须人工值守，有利于降低药品销售成本。

第六方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序；所述计算机程序被处理器执行时实现上述任一项所述的售药方法。

通过采用上述技术方案，提供了售药方法的计算机程序的载体。

综上所述，本申请包括以下至少有益技术效果：

1.自动售药终端的工作时间不受门店营业时间的限制，能够24小时协助处理药品订单，能够显著提升药品订单的处理效率，缩短用药者的等待时长。

2.自动售药终端无须人工值守，有利于降低药品销售成本。

附图说明

图1为本申请实施例一中提供的售药系统的一种示意图；

图2为本申请实施例一中提供的售药平台的一种硬件结构示意图；

图3为本申请实施例一中提供的自动售药终端的一种硬件结构示意图；

图4为本申请实施例一中提供的自动售药终端的一种示意图；

图5为本申请实施例一中提供的售药方法的一种交互流程示意图；

图6为本申请实施例一中提供的售药平台获取药品订单的一种流程示意图；

图7为本申请实施例一中提供的售药系统的另一种示意图；

图8为本申请实施例一中提供的售药系统的有一种示意图；

图9为本申请实施例二中提供的售药方法的一种交互流程示意图；

图10为本申请实施例三中提供的售药方法的一种交互流程示意图；

附图标记说明：

1-售药系统；20-售药平台；21-第一处理器；22-第一存储器；23-第一通信总线；30-自动售药终端；31-第二处理器；32-第二存储器；33-第二通信总线；34-拣选机构；35-仓储柜；40-互联网医院；50-药企系统。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

实施例一：

为了让购药者在下单购药后能及时获得药品，减少时间与地理环境对购药效率的影响，本实施例首先提供一种售药系统1，请参见图1：

售药系统1包括售药平台20以及多台自动售药终端30，售药平台20与自动售药终端30通信连接。例如一售药平台20连接并管理多台分别被部署在不同位置的自动售药终端30，这些自动售药终端30可以通过以太网与售药平台20通信。售药平台20可以通过服务器或配置有较高存储与计算资源的计算机来实施。

请参见图2，售药平台20包括第一处理器21、第一存储器22以及第一通信总线23，其中，第一处理器21、第一存储器22通过第一通信总线23实现通信连接。在第一存储器22中存储有第一计算机程序，第一计算机程序可供第一处理器21读取、编译并执行以实现售药平台20侧的售药方法流程。

对于自动售药终端30，请参见图3示出的该自动售药终端30的一种硬件结构示意图：自动售药终端30包括第二处理器31、第二存储器32、第二通信总线33以及拣选机构34，同时请结合图4示出的自动售药终端30的一种示意图，自动售药终端30还包括仓储柜35。

第一存储器22与第二存储器32可用于存储指令、程序、代码、代码集或指令集。在本实施例的一些示例中，第一存储器22与第二存储器32均包括存储程序区和存储数据区。其中，第一存储器22存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令，以及用于实现售药平台20侧的售药方法的第一计算机程序的指令等；其存储数据区可存储该售药方法中涉及到的数据等。第二存储器32存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令，以及用于实现自动售药终端30侧的售药方法的第二计算机程序的指令等；其存储数据区可存储该售药方法中涉及到的数据等。

第一处理器21与第二处理器31中的至少一个可以包括一个或者多个处理核心。第一处理器21与第二处理器31中的至少一个通过运行或执行存储在存储器内的指令、程序、代码集或指令集，调用存储在存储器内的数据，执行本申请的各种功能和处理数据。第一处理器21与第二处理器31中的至少一个可以为特定用途集成电路(Application SpecificIntegrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(ProgrammableLogic Device，PLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、中央处理器(Central Processing Unit，CPU)、控制器、微控制器和微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

仓储柜35用于存放待售药的药品，其形态可以参考冷饮柜、口罩贩卖机、零食贩卖机等，待售卖的药品放置在柜中。在一些示例中，仓储柜35可以具有透明的展示窗口，用于让购药者或者路人从外部观看到仓储柜35内部的情况，实现对柜中药品的展示。例如一些示例中，仓储柜35具有玻璃柜门，或者若干玻璃窗。还有一些示例中考虑到很多药品都需要遮光保存，因此仓储柜35的柜体不支持透视，自动售药终端30并不支持对外展示柜内药品，或者自动售药终端30通过设置在仓储柜35上的显示屏对柜内药品进行形象展示。显示屏显示的画面除了可以是柜内药品的形象展示画面以外，还可以是广告画面、人机交互界面等。

同时，仓储柜35作为自动售药终端30的主体，也承担了承载自动售药终端30中其他部件的任务。例如在一种示例中，第二处理器31的功能采用工控机来实现，而工控机可以部署在仓储柜35的顶部、底部或背部。仓储柜35的。因为自动售药终端30的主体结构是柜式结构，所以，在本实施例其他一些示例中自动售药终端30也被称为“自动售药柜”，除此以外，自动售药终端30也可以被称为“自动售药机”、“自动贩药机”、“无人药店”等。

自动售药终端30的第二处理器31、第二存储器32以及拣选机构34均能连接在第二通信总线33上，通过第二通信总线33，实现了第二存储器32、拣选机构34与第二处理器31的通信。

在本实施例中，第二通信总线33包括但不限于为RS485总线、RS449总线、RS432总线、RS423总线与RS422总线中的任意一种。第二存储器32中存储了一个或多个计算机程序，这些计算机程序中包括售药程序，该售药程序可供第二处理器31读取、编译并执行，以实现售药方法。另外，第二存储器32中还可以存储第二处理器31执行售药方法过程中产生的各类数据。拣选机构34可在第二处理器31的控制下实现药品拣选，在本实施例的一些示例中，拣选机构34可以为药品抵落机构，例如，在仓储柜35中，各类待售药品分栏存放，每个存放栏的端部都设有下落区，药品抵落机构可以在第二处理器31的控制下推动待售药品朝向下落区移动，以使最靠近的下落区的药品被抵后从下落区下落，实现药品的拣选。另外一些示例中，拣选机构34可以为机械手，其可以通过抓取、吸附等方式拾取药品，实现药品拣选。

可以理解的是，除了上述部件，自动售药终端30通常还包括其他必要或不必要的部件，例如通信模块，人机交互模块，其中，人机交互模块中包括输入模块与输出模块，输入模块可以包括键盘、触控板、音频输入模块（麦克风）、图像采集模块（摄像头）、红外扫描仪等几种中的至少一种。输出模块包括显示屏、音频输出模块（扬声器）等。在本实施例的一些示例中，自动售药终端30配置了触控屏，利用触控屏可以同时实现输入与输出。

下面结合图5示出的售药平台20与自动售药终端30间的交互流程示意图对售药方法进行介绍：

S502：售药平台获取药品订单。

售药平台20获取的药品订单中包含待购药品的药品识别信息，药品识别信息用于从众多药品中唯一识别一种药品，其可以是药品批准文号、药品名称、国家药品标识码等几种中的任意一种，在本实施例的其他一些示例中，药品识别信息也可以由药品厂商，厂商为药品分配的、用以在厂内唯一识别一种药品的厂内标号，药品主要适用症状等几种信息中部分的组合。因为售药平台20获取的药品订单中包含药品识别信息，所以，根据药品识别信息旧可以确定该药品订单需要购买的药品是哪些。

在本实施例中，售药平台20可以通过以下几种方式中的任意一种来获取药品订单：

方式一：售药平台20基于来自用户终端或自动售药终端30的购药请求生成药品订单。

下面以购药请求来自自动售药终端30为例对售药平台20基于购药请求获取药品订单的过程进行阐述，请参见图6示出的自动售药终端30与售药平台20的交互流程示意图：

S602：自动售药终端检测针对待购药品的购买操作。

自动售药终端30通过自己的输入模块检测购药者针对待购药品的购买操作。例如，购药者处在可触及自动售药终端30的范围内，自动售药终端30通过其触控屏向购药者展示药品信息，购药者根据自动售药终端30展示的图文选择待购药品，或者购药者直接在输入框内输入待购药品的药品识别信息。

S604：自动售药终端根据购买操作生成购药请求。

自动售药终端30根据购药者的选择指令或者购药者直接输入的信息生成包含待购药品之药品识别信息的购药请求。

S606：自动售药终端将购药请求发送给售药平台。

生成购药请求后，自动售药终端30将购药请求发送给售药平台20。

在本实施例的其他一些示例中，售药平台20接收到的购药请求也可以来自用户终端。可以理解的是，用户终端包括但不限于手机、PAD（Tablet Personal Computer，平板电脑）、PDA（Personal Digital Assistant，个人数字助理）、穿戴式设备、台式电脑等几种中的任意一种，连接售药平台20，向售药平台20发送购药请求。例如，购药者可以在手机上安装购药客户端，通过购药客户端与售药平台20连接，购药客户端与购药者人机交互，向购药者示出可选的药品信息，让购药者按需选择。然后购药客户端根据购药者的选择指令生成包含待购药品之药品识别信息的购药请求，并发送至售药平台20。或者，购药者也可以不用安装购药客户端，而是通过使用小程序与售药平台20连接。

S608：售药平台根据购药请求进行计价核算，并向购药请求的发送端返回支付链接信息。

售药平台20接收到购药请求之后，可以根据其中携带的药品识别信息确定对应药品的价格，然后售药平台20进行计价核算，确定购药者需要支付的金额。在本实施例的一些示例中，售药平台20可以直接根据待支付金额向购药请求的发送端返回支付入口信息，支付入口信息中包含支付入口，支付入口实际上也就是支付链接，其可以是网址链接，也可以是收款二维码，甚至还可以是银行账号等。

S610：自动售药终端将支付入口信息对应的支付入口提供给购药者。

购药请求的发送端接收到支付入口信息后，可以向购药者示出支付入口，以便购药者从该支付入口完成费用缴纳。

S612：售药平台在完成支付验证后根据购药请求生成药品订单。

在售药平台20向购药请求的发送端返回支付入口信息后，其可以周期性地进行支付验证，以确定购药者是否已经完成了支付。若判断结果为否，则继续等待时机进行支付验证，若判断结果为是，则售药平台20可以根据购药请求生成药品订单。

在本实施例的一些示例中，售药平台20在接收到购药请求，对购药请求进行计价核算之前，需要先根据购药请求中携带的药品识别信息对待购药品进行类型识别。这里将药品分为处方药与非处方药，其中处方药需要根据医生的处方签进行购买，而非处方药的购买则没有要求。所以，售药平台20对待购药品进行类型识别主要是为了确定待购药品中是否包含处方药。在识别到待购药品中包含处方药的情况下，售药平台20可以向互联网医院发送问诊请求，以请求互联网医院分派医生对发送端的购药者进行问诊并开具所述处方药对应的处方信息。

在一种示例中，售药系统1中还包括互联网医院40，请参见图7示出的售药系统1的另一种示意图。互联网医院40与售药平台20通信连接。在售药平台20向互联网医院40发送问诊请求后，互联网医院40为购药者分派互联网医生，并向售药平台20返回问诊入口信息，问诊入口信息中包含有问诊入口。

严格来说，购药的人并不等同于用药的人，所以，购药的人可能并不是互联网医生问诊的对象，不过这属于医疗范畴的内容，本实施例中仅讨论售药方案，并不对购药人与用药人做具体区分。而且从宽泛的维度来说，本实施例中购药者可以不是只一个具体的人，而是一个包含两人或多人的团体，在该团体中，选择药品的人、负责支付的人以及用药的人可能是彼此独立的。

售药平台20接收到问诊入口信息后，可以将该问诊入口信息发送给购药请求的发送端，即自动售药终端30或者用户终端。自动售药终端30或者用户终端侧的购药者通过问诊入口信息中的问诊入口可以互联网医院40内的互联网医生建立通信连接，使得互联网医生得以对购药者问诊，并根据情况开具处方。在本实施例的一些示例中，购药者与互联网医生的通信可以通过售药平台20进行透传，还有一些示例中，购药者与互联网医生的通信不依赖于售药平台20实现。不过是哪种情况，在互联网医生为购药者开具处方之后，售药平台20需要获取该处方，一些示例中，可以由互联网医院40先将处方信息发送给用户终端或者自动售药终端30，由用户终端或者自动售药终端30再将处方信息发送给售药平台20；另外一些示例中，互联网医院40可以同时将处方信息发送至售药平台20与购药者侧。在售药平台20获取到处方信息后，可以对该处方信息进行保存，以实现规范售药。同时，因为购药者已经出具了针对处方药的处方，因此售药平台20可以向购药者出售处方药，所以售药平台20可以统一对待购药品进行计价核算。

在本实施例的一些示例中，在售药平台20确定待购药品中包含处方药的情况下，其向互联网医院40发送问诊请求之前，可以先判断购药者是否可以提供或者是否已经提供了对应处方药的处方信息，例如如果购药者通过其他途径从线下医院或者互联网医院40处已经获得了处方药的处方信息，则其可以在购药的时候将处方信息发送给售药平台20。例如，在一种示例中，用户终端或者自动售药终端30可以在生成购药请求时，将购药者提供的处方信息一起携带在购药请求内，然后发送给售药平台20。在这种情况下，售药平台20接收到购药请求后，虽然会从待购药品中识别出处方药，但同时其也能获得对应的处方信息，因此不必再连接互联网医院40发送问诊请求。

方式二：售药平台20接收第三方购物平台发送的药品订单。

第三方购物平台是指售药平台20以外的购物平台，例如京东、天猫、淘宝、美团、饿了么等都属于综合购物平台，在其中部分综合购物平台中也集成了购药平台，所以购药者有购药需求时，会登录到对应的平台中进行药品选购。在一些示例中，本实施例提供的售药平台20可以入驻第三方购物平台，当购药者需要购药时，可以向第三方购物平台发送购药请求，由第三方购物平台进行计价核算、支付验证等流程，在购药者完成支付后，第三方购物平台可以生成药品订单，并将该药品订单发送给售药平台20，由售药平台20所在的售药系统1实现后续的药品出货等事务。在这种模式中，第三方购物平台负责药品销售过程中与购药者交流的前端事务，而售药系统1则负责的后端事务。由于第三方购物平台大多经过多年推广，具有稳定用户群体，因此，售药系统1与第三方购物平台的结合能够节省售药系统1投入实际运营时的推广成本。

S504：售药平台根据药品订单生成出货信息。

售药平台20获取到药品订单之后，可以根据药品订单生成出货信息，该出货信息中包含待购药品的药品识别信息。出货信息可以向自动售药终端30指示需要出货哪些药品。

S506：售药平台向自动售药终端发送出货信息。

生成出货信息后，售药平台20可以向自动售药终端30发送该出货信息，以供自动售药终端30根据该出货信息拣选药品并进行出货。

S508：自动售药终端根据药品识别信息自动拣选药品并出货。

自动售药终端30接收到出货信息后，可以提取其中包含的药品识别信息，然后控制拣选机构34拣选药品识别信息对应的药品。药品拣选完成以后，自动售药终端30可以进行出货。在自动售药终端30的仓储柜35上，设置有取货口，取货者可以从该取货口拿到药品。在本实施例的一些示例中，取货口具有打开与闭合两种状态，且其开闭受第二处理器31的控制。在自动售药终端30出货时，第二处理器31控制取货口打开，其余时候，取货口均处于关闭状态，这样既能保证柜内药品的安全性，防止药品丢失；又能减少外部水汽、灰尘进入柜内，维护柜内药品的有效性与柜内的整洁。

可以理解的是，如果购药者本身就是通过自动售药终端30发起购药操作的，那么其通常是完成支付以后需要尽快拿到药品离开，这种购药场景属于“即购即取”场景。在“即购即取”场景中，购药操作与取药操作由基本相同的人在基本相同的时间于相同的地方完成，所以，售药平台20在接收到药品订单后，可以立即生成并发送出货信息给自动售药终端30，让自动售药终端30立即出货。

如果购药者是通过用户终端发起的购药操作，则购药与取药两个阶段就极有可能不是连续的，这种购药场景属于“购取分离”场景，在“购取分离”场景中，购药操作与取药操作很有可能由不同的人先后在不同的地方完成。例如购药者可以在自己家中通过自己的手机实现购药操作，其要求由配送人员将其购买的药物配送到自己家中。在这种情况下，取药操作不是由购药者完成，而是由配送人员完成；而且购药操作发生于购药者家中，取药操作完成与自动售药终端30所在处。针对“购取分离”场景，自动售药终端30会根据取药者的需要进行出货，例如在取药者发起取药操作后在进行出货。

在一些示例中，自动售药终端30可以提前完成药品拣选，然后在取药者发起取药操作，触发出货流程后再出货；还有一些示例中，自动售药终端30也可以等到取药者触发出货流程后再进行药品拣选及出货。可以理解的是，自动售药终端30在根据一个药品订单的出货信息进行药品拣选后，拣选出来的药品就需要与柜内其他药品进行单独存放，不能混在一起。但一台自动售药终端30在同一时段中可能需要处理多个药品订单的出货信息，所以，如果自动售药终端30在监测到取药操作之前就先完成药品拣选，则其仓储柜35内需要设置多个专门用于存放拣选药品的区域，这样对仓储柜35的存储空间要求较高。而监测到取药操作之后再拣选药品并随即出货能够极大地减少对仓储柜35存储空间的要求，降低自动售药终端30的生产成本与部署成本。

在本实施例的一些示例中，自动售药终端30还可以提供包装袋，在拣选药品时，利用包装袋对拣选出的药品进行打包，这样出货的时候可以整包出货，便于取药者拿取。而且，在一些示例中，自动售药终端30提供不透明的包装袋，也便于保护购药者的隐私。

由于在“购取分离”场景中，购药操作与取药操作独立，为了便于自动售药终端30在检测到取药操作后，知晓取药者需要提取的是哪一药品订单的药物，也便于自动售药终端30对取药者的身份进行认证，在本实施例的一些示例中，售药平台20可以为药品订单生成取货码，取药者基于取货码在自动售药终端30上实现取药。

在本实施例的一些示例中，售药平台20获取到药品订单后，可以为药品订单生成药品取货码，然后将药品取货码与药品识别信息一起包含在出货信息中发送给自动售药终端30。另一方面，售药平台20还会将药品取货码发送给取药者（即购药者自己或者是配送平台为订单分配的配送人员）。取药者到达自动售药终端30所在处后，可以将药品取货码出示给自动售药终端30，对于自动售药终端30而言，其通过输入模块接收到一待验证取货码。接着，其将待验证取货码与出货信息中携带的药品取货码进行匹配，实现对待验证取货码的验证，如果待验证取货码与药品出货码匹配成功，则待验证取货码通过验证，其可以根据出货信息中的药品识别信息进行出货。

在本实施例的另外一些示例中，对待验证取货码的验证工作可以由售药平台20完成，例如，售药平台20获取到药品订单后为药品订单生成药品取货码，然后将药品取货码发送给取药者，取药者向自动售药终端30出示药品取货码，自动售药终端30接收到一待验证取货码，接着其将该待验证取货码发送给售药平台20。售药平台20将从自动售药终端30处接收到的待验证取货码与之前发送给取药者的药品取货码进行匹配验证，并将验证结果发送给自动售药终端30。在本实施例的一些示例中，售药平台20可以在从自动售药终端30处接收到待验证取货码之前就将出货信息发送给自动售药终端30，在这种情况下，售药平台20发送给自动售药终端30的验证结果实际上就是出货指令，该出货指令指示自动售药终端30立即对相应的药品订单进行出货。另外一些示例中，售药平台20在从自动售药终端30处接收到待验证取货码之前不会将出货信息发送给自动售药终端30，因此，如果售药平台20对待验证取货码的验证通过，则其可以向自动售药终端30发送出货信息表征验证成功，同时利用出货信息指示自动售药终端30进行药品拣选及出货。

在本实施例的一些示例中，售药平台20还可以与药企系统50通信连接，例如请参见图8示出的另外一种售药系统1的示意图：售药系统1中还包括药企系统50，药企系统50可以部署在服务器或者计算机上。

在这些示例中，售药平台20可以获取自动售药终端30的库存信息，库存信息表征了自动售药终端30中各药品的存量。然后售药平台20根据库存信息生成补货信息，并将补货信息发送给药企系统50。在本实施例的一些示例中，补货信息中可以包含待补货药品的药品识别信息，待补货自动售药终端30的终端识别信息。其中自动售药终端30的终端识别信息可以为自动售药终端30的设备标识，也可以是自动售药终端30的部署位置信息。可以理解的是，如果部署位置信息足够精确，那么是可以从众多自动售药终端30中唯一区分出其中一个的，而且，如果药企系统50接收到包含部署位置信息的补货信息，那么药企工作人员就可以直接知晓应当到哪里去执行补货操作了。如果药企系统50接收到的补货信息中不包含待补货的自动售药终端30的部署位置信息，而是包含设备标识等其他信息，那么药企系统50需要通过其他方式了解对应的补货位置。

在本实施例的一些示例中，售药平台20还可以对各自动售药终端30的药品售药情况进行统计分析，例如分季节统计、分地理区域统计，从而确定在某一时段或某一位置处，各种药品的需求情况。售药平台20将这些统计结果提供给药企，可以让药企预先了解市场需求，及时调整药品的投放策略。

本申请实施例提供一种计算机可读存储介质，例如包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该计算机可读存储介质存储有能够被处理器加载并执行的第一计算机程序与第二计算机程序中的至少一种，其中第一计算机程序可被处理器加载并执行，以实现前述售药方法中售药平台20侧的流程；第二计算机程序被处理器加载并执行，以实现前述售药方法中自动售药终端30侧的流程。

实施例二：

本实施例将结合示例对前述售药方法做进一步介绍，请参见图9示出的该售药方法对应的交互流程示意图：

S902：售药平台在第三方购物平台进行设备入驻；

在本实施例中，第三方购物平台是指售药系统1以外的购物平台，例如可以是美团、饿了么等偏向于本地生活服务的平台，例如，设备可以入驻到“美团买药”中。这里的设备是指自动售药终端30。

S904：第三方购物平台将入驻设备映射为药店；

自动售药终端30在第三方购物平台入驻以后，将会被映射为一个药店，该药店就是一个虚拟门店，购药者进入第三方购物平台后可以选择进入该药店选购药品。可以理解的是，目前“美团买药”等线上平台中入驻的药店均是需要有人值守才能营业的传统药店。本实施例中自动售药终端30作为药店入驻后，将作为无人药店填补因传统药店闭店或者传统药店分布不均而造成的药品供应空白。

S906：售药平台在第三方购物平台进行药品入驻；

S908：第三方购物平台将入驻药品映射为药店内待售药品；

售药平台20在第三方购物平台进行药品入驻，实际上就是在对应的虚拟药店中添加药品。

S910：用户终端进入第三方购物平台的药店购药；

购药者可以通过其用户终端上的客户端或者小程序进入到第三方购物平台，在第三方购物平台上，通常有数量庞大的药店（包括传统药店与无人药店）可供购药者选择，尤其是在白天的时候。购药者可以随时进入任意一个药店进行药品选购，以及随时从当前药店中退出再重新选择药店进入。当然夜间的时候，购药者的选择会相对少一些，不过如果本申请提供的自动售药终端30大批量入驻，则可以保证购药者的购药需求基本不受影响。

S912：第三方购物平台根据用户侧的购药请求计价核算，用户侧实现支付；

无论购药者是在传统药店对应的虚拟门店中进行药品选购，还是在自动售药终端30对应的虚拟门店中进行药品选购，在选购完成后，购药者会进行下单，下单的过程实际上就是购药者通过其用户终端向第三方购物平台发送购药请求的过程。此时，第三方购物平台可以根据购药请求中携带的药品识别信息进行计价核算，确定购药者需要支付的金额。然后第三方购物平台向用户终端发送支付入口信息，让购药者根据支付入口信息中携带的支付入口完成支付。

可以理解的是，在第三方购物平台进行计价核算之前，也可以先对购药请求对应的待购药品进行类型识别，确定其中是否包含处方药，并在确定包含处方药的情况下确定购药者是否提供了对应的处方签，如果没有则其可以向互联网医院40发送问诊请求，请求互联网医院40为购药者分派医生，实现对购药者的问诊，并进行处方开具。互联网医院40的医生开具处方后，第三方购物平台可以获取并保存这些处方信息，然后再针对待购药品进行计价核算。

S914：第三方购物平台确定支付成功后生成药品订单；

在向用户终端发送了支付入口信息后，第三方购物平台可以进行支付验证，确定购药者是否已经完成了支付；在确定为是的情况下，第三方购物平台生成药品订单，药品订单中包含待购药品的药品识别信息。

S916：第三方购物平台对药品订单进行同步；

第三方购物平台生成药品订单后，一方面可以将该药品订单发送给用户终端，以让用户终端侧的购药者了解其对应的订单已经生成。另一方面，第三方购物平台可以将该药品订单发送至售药平台20处。

S918：售药平台对第三方购物平台同步的药品订单进行存储，生成药品取货码；

售药平台20接收到第三方购物平台同步过来的药品订单后，可以对药品订单进行存储，并生成药品取货码。在本实施例的一些示例中，第三方购物平台发送给售药平台20的药品订单中还可以包括处方药对应的处方信息，对于处方信息，售药平台20也会进行保存。

S920：售药平台将药品取货码携带于配送请求中发送给第三方购物平台；

售药平台20生成药品取货码后，可以将该药品取货码携带与配送请求中发送给第三方购物平台，由第三方购物平台处理配送事务。不过，本领域技术人员可以理解的是，在本实施例的其他一些示例中，售药平台20如果自己运营有配送平台，或者具有与之合作的外部配送平台，则售药平台20也可以直接将配送请求发送给配送平台。

S922：第三方购物平台向配送人员发起配送业务单；

第三方购物平台接收到售药平台20发送的配送请求后，可以向配送人员发起配送业务单，以美团为例，其接收到售药平台20发送的配送请求后，可以根据配送业务单对应的地理区域向一定距离范围内的美团骑手发起配送业务单。

S924：配送人员接单，获取药品取货码；

配送人员接收配送业务单后，可以选择接单或不接单，根据配送平台制定的接单规则，最终只会有一位配送人员成功接单，该配送人员可以获取到对应的药品取货码，当然配送人员必然还会获得取货地址，即自动售药终端30所在的位置。

S926：配送人员向自动售药终端出示药品取货码；

配送人员到达自动售药终端30所在位置后，可以向自动售药终端30出示药品取货码。在本实施例中，药品取货码可以为图形码（二维码或者条形码），配送人员可以控制其便携式终端（通常是手机）显示图形码，自动售药终端30则通过摄像头检测图形码的输入。在本实施例的其他一些示例中，药品取货码也可以是数字序列，配送人员可以通过自动售药终端30的实体键盘或虚拟键盘输入该数字序列，以将药品取货码提供给自动售药终端30。

S928：自动售药终端将待验证取货码发送给售药平台进行验证；

对于自动售药终端30而言，其他通过输入模块接收到一待验证取货码，在本实施例中，自动售药终端30将该待验证取货码发送至售药平台20侧进行验证。在本实施例的其他一些示例中，如果售药平台20在此之前已经向自动售药终端30发送了包含药品取货码与药品识别信息的出货信息，则自动售药终端30可以自己根据出货信息中携带的药品取货码对待验证取货码进行验证，无须将待验证取货码发送给售药平台20。

S930：验证通过后售药平台向自动售药终端发送出货信息。

在本实施例中，售药平台20向自动售药终端30发送的出货信息中包含需要出货的药品的药品识别信息以及药品的数量。可以理解的是，该出货信息实际上也是售药平台20对待验证取货码进行验证的验证结果，其表征验证通过。

S932：自动售药终端出货；

自动售药终端30接收到出货信息即表征售药平台20的验证通过，其可以根据出货信息进行出货。在本实施例的其他一些示例中，自动售药终端30出货所根据的出货信息也可以由售药平台20在其他时机发送给自动售药终端30。

S934：配送人员进行配送，结束药品订单；

自动售药终端30出货后，配送人员可以取到待配送药品，然后，其开始配送，直至将药品送到购药者手中或者购药者指定的位置，结束配送业务单；配送业务单的结束也意味着药品订单结束。

S936：自动售药终端向售药平台上报出货清单；

在本实施例的一些示例中，自动售药终端30还会向售药平台20上报自己的出货清单，例如自动售药终端30可以以一天为周期，周期性地上报自己的出货清单。

S938：售药平台确定针对自动售药终端的补货信息，并将补货信息推送至药企系统。

售药平台20接收到自动售药终端30的出货清单后，可以确定针对自动售药终端30的补货信息，并将补货信息推送至药企系统50，让药企及时了解自动售药终端30的补货需求。可以理解的是，在不改变自动售药终端30对应的药品投放策略的情况下，自动售药终端30的出货清单实际上也可以直接作为补货信息被售药平台20发送给药企系统50。在本实施例的另外一些示例中，售药平台20可以先根据出货信息进行统计分析，确定自动售药终端30当前的药品投放策略是否适当，如果不适当，则其可以调整药品投放策略，并根据调整后的药品投放策略生成捕获信息发送给药企系统50，使得药企在自动售药终端30中的药品投放能够更积极地应对市场需求。

实施例三：

为了让本领域技术人员对前述售药方法的优点与细节更清楚，本实施例将继续结合具体示例对其进行介绍，请参见图10示出的售药方法对应的一种交互流程示意图：

S1002：自动售药终端检测购买操作并生成购药请求；

自动售药终端30可以检测购药者在本机上进行的针对待购药品的购买操作，并根据购买操作生成购药请求。在购药请求中，包含有待购药品的药品识别信息。

S1004：自动售药终端将购药请求发送给售药平台；

自动售药终端30生成购药请求后，将购药请求发送至与之通信连接的售药平台20。

S1006：售药平台对待购药品进行类型识别；

售药平台20接收到来自自动售药终端30的购药请求后，可以根据购药请求中的药品识别信息对待购药品进行类型识别，识别出待购药品中是否包含处方药。

S1008：在确定待购药品中包含处方药，但购药者未提供处方信息时，向互联网医院发送问诊请求；

如果经过类型识别，售药平台20确定待购药品中包含处方药，但购药者不能提供对应的有效处方信息，则售药平台20可以向互联网医院40发送问诊请求，让互联网医院40为该购药者分配互联网医生，对购药者进行问诊。

可以理解的是，如果售药平台20经过识别，确定购药请求中包含处方药，在向互联网医院40发送问诊请求之前，可以先向自动售药终端30发送处方上传指令，自动售药终端30可以根据处方上传指令询问购药者是否已经有对应的有效处方信息，如果有，则自动售药终端30将购药者提供的处方信息发送给售药平台20；如果没有，则自动售药终端30向售药平台20返回表征购药者无处方信息的应答，让售药平台20连接互联网医院40。

在本实施例的一些示例中，对待购药品进行类型识别的工作、获取处方药处方信息的工作可以由自动售药终端30与售药平台20在购药者选择待购药品的过程中就实现，而不用等待购药者完成对所有待购药品的选择之后再进行。

S1010：接收互联网医院发送的问诊入口信息；

向互联网医院40发送问诊请求后，互联网医院40将会返回问诊入口信息，该问诊入口信息中包含问诊入口，通过问诊入口，购药者可以与互联网医院40为之分派的医生交流，所以售药平台20将该问诊入口信息发送给自动售药终端30。

S1012：将问诊入口信息发送至自动售药终端；

S1014：自动售药终端与互联网医院建立通信，以使医生对购药者进行问诊；

自动售药终端30接收到问诊入口信息后，可以将其中包含的问诊入口提示给购药者，购药者通过问诊入口进入与互联网医生交流的界面，互联网医生可以通过与购药者沟通了解其基本情况，是否适用对应的处方药等。如果确定购药者符合适用对应处方药的条件，则互联网医生可以为购药者开具对应的处方信息，并将处方信息发送到自动售药终端30侧。但如果经过问诊后互联网医生确定购药者不符合使用对应处方药的条件在，则其可以拒绝开具处方信息。

S1016：自动售药终端将处方信息发送给售药平台；

在本实施例中，自动售药终端30接收到处方信息后，可以将处方信息发送给售药平台20。需要说明的是，由于处方信息中涉及到购药者的隐私，而自动售药终端30作为共用设备会被社会公众使用，因此，虽然自动售药终端30会正在用户购药过程中获处方信息，但在订单结束后，自动售药终端30并不保存该处方信息。

本领域技术人员可以理解的是，在本实施例的其他一些示例中，互联网医院40也可以直接将处方信息发送给售药平台20，这样就不需要自动售药终端30进行转发。

S1018：售药平台进行计价核算，向自动售药终端发送支付入口信息；

售药平台20获取的待购药品中处方药对应的处方信息后，可以对待购药品进行计价核算，并向自动售药终端30发送包含支付入口的支付入口信息。

S1020：自动售药终端示出支付入口，以供购药者进行支付；

自动售药终端30接收到支付入口信息后，可以示出支付入口，例如，在一种示例中，自动售药终端30可以通过自己的显示屏显示收款码，购药者通过自己的手机扫描二维码实现支付。

S1022：售药平台完成支付验证后生成并发送出货信息；

在向自动售药终端30发送支付入口信息后，售药平台20可以周期性进行支付验证，确定购药者是否已经完成了支付。另外一些示例中，在自动售药终端30向购药者示出支付入口时，其可以同时示出一功能控件，如该功能控件上的文字为“已支付”，购药者完成支付后，其会点击该功能控件，从而使得自动售药终端30知晓支付已完成，并将支付已完成的信息发送给售药平台20；售药平台20接收到自动售药终端30发送的信息后，再进行支付验证，确定购药者是否真的完成了支付。

完成支付验证后，售药平台20可以生成出货信息，该出货信息中包含待出货药品的药品识别信息以及数量信息。随后，售药平台20将出货信息发送给自动售药终端30。在本实施例中，因为售药平台20接收到的购药请求由自动售药终端30发送，所以说明购药者自身当前就在自动售药终端30旁边，因此该购药场景属于“即购即取”场景，售药平台20不必生成药品取货码。

S1024：自动售药终端根据出货信息进行药品拣选及出货。

自动售药终端30接收到出货信息后，可以立即根据药品识别信息与数量信息进行药品拣选与出货，使得购药者可以尽快取得药品。

以上所述，以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本申请的方法及其核心思想，不应理解为对本申请的限制。本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种售药方法，其特征在于，所述售药方法包括：

获取药品订单，所述药品订单中包含待购药品的药品识别信息；

根据所述药品订单生成出货信息，所述出货信息中包含所述药品识别信息；

向自动售药终端发送所述出货信息，以供所述自动售药终端根据所述出货信息出货。

2.如权利要求1所述的售药方法，其特征在于，所述获取包含药品识别信息的药品订单包括以下几种中的任意一种：

方式一：接收用户终端与所述自动售药终端中至少一个发送的购药请求，所述购药请求中包含所述待购药品的药品识别信息；根据所述购药请求进行计价核算，并向所述购药请求的发送端返回支付入口信息；在完成支付验证后根据所述购药请求生成所述药品订单；

方式二：接收第三方购物平台发送的所述药品订单，所述药品订单由所述第三方购物平台在购药者完成药品选择与药品支付后生成。

3.如权利要求2所述的售药方法，其特征在于，所述获取药品订单之后，还包括：为所述药品订单生成药品取货码，将所述药品取货码发送给配送平台或所述用户终端；

所述根据所述药品订单生成出货信息包括：生成同时包含所述药品识别信息与所述药品取货码的所述出货信息。

4.如权利要求2所述的售药方法，其特征在于，所述获取药品订单之后，根据所述药品订单生成出货信息之前，还包括：

为所述药品订单生成药品取货码，将所述药品取货码发送给配送平台或所述用户终端；

接收所述自动售药终端发送的取货码验证请求，所述取货码验证请求中包含待验证取货码；

根据所述药品取货码对所述待验证取货码进行验证；

所述根据所述药品订单生成出货信息包括：在验证通过后生成包含所述药品识别信息的所述出货信息。

5.如权利要求1至4任一项所述的售药方法，其特征在于，所述向自动售药终端发送所述出货信息之后，还包括：

生成针对所述自动售药终端的补货信息；

向药企系统发送所述补货信息，以请求药企对所述自动售药终端进行补货，所述补货信息中包含待补货药品的药品识别信息以及所述自动售药终端的终端识别信息。

6.一种售药方法，其特征在于，所述售药方法包括：

接收售药平台根据药品订单生成的出货信息，所述出货信息中包含待购药品的药品识别信息；

根据所述药品识别信息自动拣选药品并出货。

7.如权利要求6所述的售药方法，其特征在于，所述接收售药平台根据药品订单生成的出货信息之前，还包括：

检测针对待购药品的购买操作；

根据所述购买操作生成购药请求，所述购药请求中包含所述待购药品的药品识别信息；

将所述购药请求发送给所述售药平台；

接收所述售药平台发送的支付入口信息并将所述支付入口信息对应的支付入口提供给购药者，以使所述购药者根据所述支付入口进行支付操作。

8.如权利要求6或7所述的售药方法，其特征在于，所述根据所述药品识别信息拣选药品并出货之前，还包括：

通过输入模块接收待验证取货码；

对所述待验证取货码进行验证；

在验证通过后，根据所述药品识别信息进行出货。

9.一种售药平台，其特征在于，包括第一处理器、第一存储器以及第一通信总线，所述第一通信总线用于实现所述第一处理器与所述第一存储器之间的通信连接，所述第一处理器用于执行存储在所述第一存储器中的第一计算机程序，以实现如权利要求1至5任一项所述的售药方法。

10.一种自动售药终端，其特征在于，包括第二处理器、第二存储器、拣选机构、仓储柜以及第二通信总线，所述第二存储器、所述拣选机构分别通过所述第二通信总线同所述第二处理器通信连接，所述仓储柜用于存放待售卖的药品，所述拣选机构用于在所述第二处理器的控制下从所述仓储柜中拣选药品；所述第二处理器用于执行存储在所述第二存储器中的第二计算机程序，以实现如权利要求6至8任一项所述的售药方法。