一种药品下单的方法、装置、存储介质以及电子设备与流程

1.本说明书涉及计算机技术领域，尤其涉及一种药品下单的方法、装置、存储介质以及电子设备。


背景技术：

2.随着电子商务的发展，越来越多的用户使用线上购物的方式购买物品，而用户在购买某些物品时，需要上传对应的凭证，由相关人员根据该用户上传的凭证确定该用户有资格后，用户才能购买该物品。例如，用户在购买处方药时，需要上传对应的处方、病例等凭证，由线上的药师核对后，方能购买对应的药品。
3.目前，用户在每次购买处方药时，都需要上传对应的药方，经药师核对后才能购买药品，这种购药方式的购药效率较低，给用户带来了极大的不便。


技术实现要素：

4.本说明书提供一种药品下单的方法、装置、存储介质以及电子设备，以部分的解决现有技术存在的上述问题。
5.本说明书采用下述技术方案：
6.本说明书提供了一种药品下单的方法，包括：
7.确定用户所需下单的第一药品；
8.从所述用户的历史购药记录中确定所述用户购买过的与所述第一药品相匹配的第二药品；
9.确定所述用户购买所述第二药品时上传的购药资格证明信息并展示；
10.确定所述用户选择的购药资格证明信息，作为目标证明信息；
11.将所述目标证明信息发送给审核人所使用的终端设备进行审核；
12.响应于所述目标证明信息通过所述审核人的审核，执行针对所述第一药品的下单任务。
13.可选地，确定所述用户购买所述第二药品时上传的购药资格证明信息并展示，具体包括：
14.向所述用户推荐所述用户购买所述第二药品时填写的至少一个用药人信息并展示；
15.将所述用户选择的用药人信息，作为使用所述第一药品的目标用药人信息；
16.查询所述用户购买所述第二药品时上传的所述目标用药人信息对应用药人的购药资格证明信息并展示。
17.可选地，所述历史购药记录包括：用药人的用药量和所述用户的购药量；
18.向所述用户推荐所述用户购买所述第二药品时填写的至少一个用药人信息并展示，具体包括：
19.根据历史上所述用户为每个用药人信息对应用药人所购买的所述第二药品的购
药量，预测每个用药人使用所述第二药品后的剩余药量；
20.根据所述预测出的每个用药人使用所述第二药品后的剩余药量，向所述用户推荐所述用户购买所述第二药品时填写的至少一个用药人信息并展示。
21.可选地，在将所述目标证明信息发送给审核人所使用的终端设备进行审核之前，所述方法还包括：
22.根据所述第一药品，确定所述第一药品用于治疗的各疾病信息；
23.向所述用户展示所述第一药品治疗的各疾病的疾病信息；
24.确定所述用户从展示的各疾病的疾病信息中选择的疾病，作为第一疾病；
25.将所述目标证明信息发送给审核人所使用的终端设备进行审核，具体包括：
26.将所述用户选择的所述第一疾病的疾病信息以及所述目标证明信发送给审核人所使用的终端设备进行审核。
27.可选地，所述历史购药记录还包括：用药人确诊的历史疾病；
28.向所述用户展示所述第一药品治疗的各疾病的疾病信息，具体包括：
29.从确定出的使用所述第一药品的目标用药人信息对应的用药人确诊的历史疾病中，确定出所述第一药品能治疗的历史疾病，作为第二疾病；
30.确定所述第二疾病所归属的疾病类型；
31.将所述第一药品所能治疗的所述疾病类型的疾病的疾病信息，排列在所述第一药品平所能治疗的其他疾病类型的疾病的疾病信息之前进行展示。
32.可选地，向所述用户展示所述第一药品治疗的各疾病的疾病信息，具体包括：
33.针对所述第一药品所能治疗的每个疾病，确定使用所述第一药品治疗该疾病的使用率，作为该疾病对应的使用率；
34.按照所述第一药品所能治疗的每个疾病对应的使用率从高到低的顺序，展示所述第一药品所能治疗的每个疾病的疾病信息。
35.可选地，确定所述用户购买所述第二药品时上传的购药资格证明信息并展示，具体包括：
36.判断所述购药资格证明信息是否超过所述购药资格证明信息的有效期；
37.若是，则将所述购药资格证明信息展示给所述用户。
38.本说明书提供了一种药品下单的装置，包括：
39.第一确定模块，用于确定用户所需下单的第一药品；
40.第二确定模块，用于从所述用户的历史购药记录中确定所述用户购买过的与所述第一药品相匹配的第二药品；
41.展示模块，用于确定所述用户购买所述第二药品时上传的购药资格证明信息并展示；
42.第三确定模块，用于确定所述用户选择的购药资格证明信息，作为目标证明信息；
43.发送模块，用于所述目标证明信息发送给审核人所使用的终端设备进行审核；
44.执行模块，用于响应于所述目标证明信息通过所述审核人的审核，执行针对所述第一药品的下单任务。
45.本说明书提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述药品下单的方法。
46.本说明书提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述药品下单的方法。
47.本说明书采用的上述至少一个技术方案能够达到以下有益效果：
48.在本说明书提供的药品下单的方法中，首先确定用户所需下单的第一药品，之后从用户的历史购药记录中确定用户购买过的与第一药品相匹配的第二药品。确定用户购买第二药品时上传的购药资格证明信息并展示，并确定用户选择的购药资格证明信息，作为目标证明信息，以及将目标证明信息发送给审核人所使用的终端设备进行审核，在确定出目标证明信息通过所述审核人的审核后，执行针对第一药品的下单任务。
49.从上述方法中可以看出，在用户购买第一药品时，可以根据获取到的用户的历史购药记录中包含的购药资格证明信息，来确定是否可以向用户提供购药业务，而不需要用户重新上传购买第一药品所需的购药资格证明信息，从而提高了用户执行购药业务的效率。
附图说明
50.此处所说明的附图用来提供对本说明书的进一步理解，构成本说明书的一部分，本说明书的示意性实施例及其说明用于解释本说明书，并不构成对本说明书的不当限定。在附图中：
51.图1为本说明书提供的一种药品下单的方法的流程示意图；
52.图2为本说明书提供的一种购药界面的示意图；
53.图3为本说明书提供的现有的购药界面示意图；
54.图4为本说明书提供的一种药品下单的方法的购药界面的示意图
55.图5为本说明书提供的一种药品下单的装置的示意图；
56.图6为本说明书提供的一种对应于图1的电子设备的示意图。
具体实施方式
57.为使本说明书的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书保护的范围。
58.需要指出的是，本说明书中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给与授权的情况下进行的。
59.以下结合附图，详细说明本说明书各实施例提供的技术方案。
60.图1为本说明书中提供的一种药品下单的方法的流程示意图，包括以下步骤：
61.s101：确定用户所需下单的第一药品。
62.目前，用户在网上购药时，往往需要用户在平台提供的表格中填写各种数据。例如，用药人、疾病、线下就诊证明文件等。而由于用户每次购药都需要填写对应的信息，效率较低的同时，降低了用户执行购药业务的用户体验。
63.基于此，本说明书提供了一种药品下单的方法，首先，客户端可以确定用户所需下
单的第一药品。其中，客户端可以监测用户在客户端展示的购药界面中所选择的药品，当确定用户对展示的药品信息执行选取操作时(如将药品信息对应的药品添加到购物车中，或是对选中的药品执行下单操作)，则可以确定出用户所需的第一药品。
64.当然，对于需要长期服用的药品来说，客户端也可以根据用户历史上购买该种药品的购买时刻以及当前时刻，确定出用户购买该种药品后距离现在的时长，而后，根据该时长以及该种药品的用药量，推测出该种药品是否已经或是将要消耗完，若是，则可以将该种药品，作为用户需要购买的第一药品。
65.另外，在本说明书中，在确定用户需要下单的第一药品时，还可以进一步的判断该第一药品是否属于治疗慢性病的药品，在确定出该第一药品属于治疗慢性病的药品后，可以在后续过程中，确定出用户历史上购买过与该第一药品相匹配的第二药品时所上传的购药资格证明信息。例如，用户在执行结算操作时，客户端向服务器发送该第一药品的药品信息，而服务器在接收到该药品信息后，可以根据预先构建的慢性病药品库，判断该第一药品是否为用于治疗慢性病的药品。
66.s102：从所述用户的历史购药记录中确定所述用户购买过的与所述第一药品相匹配的第二药品。
67.客户端在确定用户所需下单的第一药品后，可以从用户的历史购药记录中确定用户购买过的与第一药品相匹配的第二药品。其中，第二药品可以是与第一药品相同，第二药品也可以是与第一药品的功效相同或相近的药品。
68.确定出与第一药品相匹配的第二药品所采用的方式可以有多种，例如，可以确定出第一药品的药品信息关键字(如药品名、所治疗的疾病的疾病名称等)，而后，从用户的历史购药记录中将用户购买过的各种药品的药品信息关键字与第一药品的药品信息关键字进行匹配，以匹配出第二药品。
69.再例如，可以将第一药品的包装图像，与用户在历史上购买过的各药品的包装图像进行匹配，以匹配出第二药品；再例如，可以将第一药品的药品信息与用户在历史上购买过的各药品的药品信息输入到预设的匹配模型中，以匹配出第二药品。其他方式在此就不一一举例说明了。
70.需要说明的是，上述步骤s102的具体实现方式可以大致分为两种，一种是如果客户端本地中保存有用户的历史购药记录，那么在确定出用户需要下单的第一药品后，客户端可以从保存的历史购药记录中确定出用户购买过的与第一药品相匹配的第二药品。
71.第二种则是服务器中保存有用户的历史购药记录，那么，客户端在确定出用户需要下单的第一药品后，需要将第一药品的药品信息发送给服务器，而服务器则可以通过将用户的历史购药记录进行整合，以通过整合后的信息，确定出用户在历史上购买过的与第一药品相匹配的第二药品。
72.当然，如果没有确定出与第一药品相匹配的第二药品，则客户端提示用户主动上传购买第一药品所需的购药资格证明信息，以执行购买第一药品的订单任务。
73.s103：确定所述用户购买所述第二药品时上传的购药资格证明信息并展示。
74.在确定出第二药品后，可以确定出该用户购买第二药品时上传的购药资格证明信息，并通过客户端展示给用户。其中，这里提到的购药资格证明信息可以是指用户购买第二药品时所上传的用药人信息、病例信息、处方数据以及用户或用药人与医生之间的问诊对
话记录等。
75.在实际应用中，一个用户可能会帮助其他人购买药物，因此用药人和用户可能为同一个人也可能不为同一个人。所以，用药人信息可以为，在该用户所使用的客户端中该用户的信息，或是该用户帮助其他用药人购买药物时填写的其他用药人的信息。其中，用药人信息可以包括：用药人姓名、身份证号、手机号等数据。
76.而在实际情况中，用户可能在历史上为多个用药人购买过第二药品，所以，在确定出用户购买第二药品时上传的购药资格证明信息时，需要进一步地确定出需要将历史上哪一用药人的购药资格证明信息在客户端展示给用户。
77.所以，在确定用户购买第二药品时上传的购药资格证明信息之前，也可以先向用户推荐该用户在历史上购买第二药品时填写的至少一个用药人信息，而后，客户端可以根据用户所执行的选择操作，确定出用户选择的用药人信息，作为使用该第一药品的目标用药人信息，并查询出该用户购买该第二药品时上传的目标用药人信息对应用药人的购药资格证明信息，以展示给用户。
78.若是服务器中保存有用户的历史购药记录，则可以将历史上用户购买第二药品时所上传的所有用药人信息返回给客户端进行展示，以供用户从这些用药人信息中选择出实际使用第一药品的目标用药人信息。
79.当然，服务器也可以将历史上用户购买第二药品时所上传的部分用药人信息返回给客户端进行展示。其中，服务器可以根据历史购药记录，先筛选出可能是使用第一药品的用药人的用药人信息返回给客户端。具体的实现方式可以是，服务器可以根据历史上用户为每个用药人信息对应用药人所购买的第二药品的购药量，预测每个用药人使用第二药品后的剩余药量，之后，可以根据预测出的每个用药人使用第二药品后的剩余药量，向用户推荐该用户购买第二药品时填写的至少一个用药人信息并通过客户端进行展示。
80.其中，服务器可以根据预先设置的第二药品的消耗速度，确定用药人使用第二药品的消耗速度，服务器可以根据用药人使用第二药品的消耗速度和用户的购药量，确定出剩余药量，从而向用户推荐该用户购买第二药品时填写的至少一个用药人信息并通过客户端进行展示。例如，第二药品为药品a，药品a的建议使用次数为一天一包，用户为用药人a购买的药品a的购药量为十包，现在距离用户上次购买已经过去九日，则可以判断剩余药量为一包，从而确定该用户可能需要为用药人a再次购买药品a。
81.当然，也可以通过其他的方式来先用户推荐用药人信息，例如，客户端在确定出在用户选择使用第一药品治疗的疾病后，将用户选择的疾病的疾病信息发送给服务器，服务器通过对用户的历史购药记录进行分析，可以将患有该疾病的用药人的用药人信息推荐给用户。
82.另外，若是确定出用户在历史上只为一个用药人购买过第二药品，那么也可以直接将该用药人的用药人信息作为使用第一药品的用药人的用药人信息向用户进行展示，此时用户只需要执行确认操作即可，无需进行选择。
83.s104：确定所述用户选择的购药资格证明信息，作为目标证明信息。
84.s105：将所述目标证明信息发送给审核人所使用的终端设备进行审核。
85.客户端在获取到购药资格证明信息后，可以将购药资格证明信息向用户进行展示。而用户则可以根据实际需求，选择出使用第一药品的用药人的购药资格证明信息，相应
的，客户端可以将用户选择出的购药资格证明信息作为目标证明信息。
86.而后，客户端可以将该目标证明信息发送给服务器，以使服务器将该目标证明信息发送给审核人所使用的终端设备进行审核。当然，在实际应用时，由于服务器保存有各购药资格证明信息，所以，客户端实际上可以只向服务器发送目标证明信息对应的信息标识，而服务器可以根据该信息标识，查询出该目标证明信息，并将该目标证明信息发送给审核人所使用的终端设备进行审核。其中，这里提到的信息标识可以是指目标证明信息对应的用药人的姓名、目标证明信息的信息编号、用户上一次上传目标证明信息的时间信息等，这里提到的审核人可以是指审核用药人购药资格的医师或药师。
87.而在将目标证明信息发送给审核人所使用的终端设备进行审核之前，也可以先根据第一药品，确定第一药品治疗的各疾病，之后向用户展示第一药品治疗的各疾病的疾病信息以供用户选择，客户端可以将用户从展示的各疾病的疾病信息中选择的疾病，作为第一疾病。其中，由于第一药品可能可以治疗很多种疾病，例如，第一药品为阿莫西林，则对应的候选疾病可以为呼吸道感染、泌尿道感染、消化道感染、皮肤和软组织感染等疾病。
88.在用户选择第一疾病后，可以将第一疾病的疾病信息以及目标证明信息发送给审核人所使用的终端设备进行审核。
89.而因为第一药品治疗的各疾病的种类可能会有很多，为了方便用户从中选择出第一疾病，客户端在向用户展示各疾病的过程中，可以从确定出的使用第一药品的目标用药人信息对应的用药人确诊的历史疾病中，确定出第一药品能治疗的历史疾病，作为第二疾病，确定第二疾病所归属的疾病类型，将第一药品所能治疗的疾病类型的疾病的疾病信息，排列在第一药品所能治疗的其他疾病类型的疾病的疾病信息之前进行展示。
90.例如，第二疾病属于呼吸系统疾病，则将第一药品所能治疗的疾病中属于呼吸系统疾病的疾病信息排在第一药品所能治疗的疾病中不属于呼吸系统疾病的疾病信息之前向用户展示。其中，疾病类型可以为该历史疾病所属的人体系统，例如，呼吸系统，消化系统等。
91.而在向用户展示各候选疾病的过程中，也可以针对第一药品所能治疗的每个疾病，确定使用第一药品治疗该疾病的使用率，作为该疾病对应的使用率，按照第一药品所能治疗的每个疾病对应的使用率从高到低的顺序，展示第一药品所能治疗的每个疾病的疾病信息。例如，第一药品为药品a，药品a用于治疗疾病a的使用率为50％、用于治疗疾病b的使用率为30％、用于治疗疾病c的使用率为20％，因此最后的排序结果可以为，第一位为疾病a、第二位为疾病b、第三位为疾病c。
92.为了保障用户的用药安全，因此可以针对不同的购药资格证明信息对应的疾病，设置不同的购药资格证明信息的有效期。当购药资格证明信息超过该购药资格证明信息的有效期时，客户端可以提示用户重新提供对应的购药资格证明信息。其中，这里购药资格证明信息的主要作用是为了向提供购药业务的平台证明该用户可以购买哪些处方药。因此，购药资格证明信息可以是用户线下就诊的证明文件，也可以是用户通过和线上医生沟通医生开具的处方或证明文件。
93.需要说明的是，客户端在将目标证明信息通过服务器发送给审核人所使用的终端设备时，服务器可先通过预先设置的图像识别模型，识别目标证明信息是否符合预设的条件(这里提到的预设的条件是购药资格证明信息不为一些无意义的图片，如空白图等)，之
后将符合预设条件的目标证明信息发送给审核人所使用的终端设备，由审核人通过该目标证明信息确认该用户可以购买第一药品。
94.s106：响应于所述目标证明信息通过所述审核人的审核，执行针对所述第一药品的下单任务。
95.在审核人确定该目标证明信息通过审核后，服务器可以执行针对第一药品的下单任务。在此过程中，用户可以先通过支付页面进行付款，在完成付款后，将上述目标证明信息发送给审核人所使用的终端设备进行审核，服务器一旦确定该目标证明信息通过审核人的审核后，即可执行针对该第一药品的配送任务。当然，用户也可以先对第一药品执行下单操作，此时将触发上述步骤所对应的流程，以将目标证明信息发送给审核人所使用的终端设备进行审核。服务器一旦确定该目标证明信息通过审核人的审核后，即可向客户端返回支付指令，以使客户端根据该支付指令，向用户展示支付页面。用户一旦完成支付操作，则服务器可以执行针对该第一药品的配送任务。
96.当然，若是确定该目标证明信息未通过审核人的审核，则服务器将不执行针对该第一药品的配送任务，即取消订单。
97.在实际应用中，向用户提供购药业务的方式具体可以分为两类：其中一类为平台自动填写问诊信息，另一类为用户手动填写问诊信息。
98.首先针对平台自动填写问诊信息进行说明。
99.图2为本说明书提供的一种购药界面的示意图。
100.在图2中，用户在购买第一药品时，客户端可以先将确定出的可能使用第一药品的用药人的用药人信息展示给用户。该用药人信息可以通过如图2所示中弹出的一键续方的弹窗进行展示。
101.若是用户点击了该弹窗中所展示的“同意”选项，则客户端确定用户需要获取弹窗中所展示的用药人的购药资格证明信息。
102.其中，若是用户在购买第一药品时未勾选图2中弹窗上方的一键续方选项，则不会弹出该弹出，即，当已经事先勾选了一键续方的选项后，才能通过该弹窗向用户展示确定出的可能使用第一药品的用药人的用药人信息。
103.在本说明书中，该一键续方的选项可以是用户自行勾选的，也可以是用户在执行购药业务之前，在客户端中执行了允许平台(即服务器)获取并暂存用户上传的购药资格证明信息的授权操作后，客户端默认勾选的。
104.需要说明的是，本说明书中提到的购药资格证明信息中除了包含有用药人的疾病信息、处方数据等常规信息外，还可以包含有用药人或是用户与医生之间的问诊对话记录。该问诊对话记录除了包含有用药人或是用户与医生之间关于病情的问诊对话外，还可以包括用药人或用户与医生之间关于服药后反应的问诊对话。
105.服务器可以将这些问诊对话记录进行整理，并将整理后的问诊对话记录作为购药资格证明信息中的一部分返回给用户进行查看与选择。其中，服务器可以对问诊对话记录进行语义分析，以从问诊对话记录中识别出不规范的描述词，作为待替换词，并从预设的词库中查找出与这些待替换词相对应的标准描述词。服务器可以在问诊对话记录中将待替换词替换为标准描述词，以得到整理后的问诊对话记录。
106.例如，假设一个用药人与医生之间的问诊对话记录中包含有“肚子痛”的病情描述
词，那么服务器可以识别出该描述词为不规范的描述词，需要进行替换。进一步地，服务器可以从预设的词库中确定出该描述词对应的标准描述词为“腹痛”，则服务器可以将问诊对话记录中的“肚子痛”，替换为“腹痛”。
107.当然，服务器也可以对问诊对话记录执行其他的优化操作，如，可以通过语义分析，识别出与问诊无关的语句，并将这些语句从问诊对话记录中去除，得到整理后的问诊对话记录。
108.相应的，用户在点击图2中所示的“同意”选项后，客户端将会向用户展示确定出的购药资格证明信息，用户可以对客户端所展示的疾病信息、处方数据、服务器整理的问诊对话记录等购药资格证明信息进行审核。用户确定客户端展示的购药资格证明信息无误后，可以执行确认操作，此时，客户端可以将该购药资格证明信息作为用户选择的目标证明信息通过服务器发送给审核人所使用的终端设备进行中审核。
109.若该目标证明信息未通过审核人的审核，则客户端需要提示用户主动填写购药人信息、疾病信息、处方数据以及用户或用药人与医生之间的问诊对话记录等，并展示给用户，以在用户确认后，执行针对第一药品的下单任务。
110.当然，若是未匹配出上述第二药品，或是经过用户确认后客户端所展示的购药资格证明信息不是用户需要的信息，那么，用户可以自行填写购药资格证明信息。自行填写的方式为现有的常规方式，在此就不进行详细介绍了。
111.为了进一步地说明通过本技术所提供的药品下单的方法能够极大的提高购药效率，下面结合图3为本说明书提供的现有的购药界面示意图和图4为本说明书提供的一种药品下单的方法的购药界面的示意图进行比对说明。
112.如图3所示，在现有的购药流程中，用户需要在每次购药时手动填写用药人信息(图3中的用药人姓名、身份证号、手机号、疾病史/妊娠哺乳、与用户关系)，以及疾病信息，还需要手动上传购药资格证明信息。需要说明的是，在图3中，用户可以通过点击各个加号来填写对应的信息。
113.而如图4所示，在本技术的购药流程中，客户端可以向用户展示客户端获取到的用药人信息，用户可以从客户端展示各用药人信息中选择出该次购药对应的用药人，而不需要重新填写。如果客户端展示的用药人信息中没有包含用户该次购药对应的用药人，用户也可以点击用药人信息后面的加号手动输入用药人信息。
114.相应的，客户端也可以向用户展示客户端获取到的用药人确诊的历史疾病信息，用户可以从客户端展示的用药人确诊的历史疾病信息选择出该次购药需要治疗的疾病信息，而不需要手动填写，如果客户端展示的用药人确诊的历史疾病信息中没有包含用户该次购药对应的疾病信息，用户也可以点击用药人信息后面的加号手动输入疾病信息。
115.最后，客户端可以向用户展示用户的历史购药记录中包含的用户购买第二药品时上传的购药资格证明信息，用户可以从中选择对应于使用第一药品的用药人的购药资格证明信息，而不需要用户手动上传。如果用户根据客户端展示的购药资格证明信息确定需要额外上传其他的购药资格证明信息，则用户也可以点击购药资格证明信息后面的加号手动上传购药资格证明信息。
116.用户只需要选择用药人的信息、疾病信息和历史上传的购药资格证明信息即可，不需要手动填写和上传，提高了用户购药的效率。
117.其中，颜色加深的为用户选择的用药人信息、疾病信息以及购药资格证明信息。
118.从上述方法可以看出，在用户购买第一药品时，可以根据获取到的用户在历史上购药时所上传的购药资格证明信息，来确定是否可以向用户提供购药业务，而不需要用户重新上传购买第一药品所需的购药资格证明信息，从而有效地提高了用户执行购药业务的效率。
119.需要说明的是，本技术中所涉及的所有数据都是在遵照所在地国家相应的数据保护法规政策的前提下获取的，并获得由相应装置所有者给予授权的情况下进行的。
120.图5为本说明书提供的一种药品下单的装置的示意图，包括：
121.第一确定模块501，用于确定用户所需下单的第一药品；
122.第二确定模块502，用于从所述用户的历史购药记录中确定所述用户购买过的与所述第一药品相匹配的第二药品；
123.展示模块503，用于确定所述用户购买所述第二药品时上传的购药资格证明信息并展示；
124.第三确定模块504，用于确定所述用户选择的购药资格证明信息，作为目标证明信息；
125.发送模块505，用于所述目标证明信息发送给审核人所使用的终端设备进行审核；
126.执行模块506，用于响应于所述目标证明信息通过所述审核人的审核，执行针对所述第一药品的下单任务。
127.可选地，所述展示模块503具体用于，向所述用户推荐所述用户购买所述第二药品时填写的至少一个用药人信息并展示；将所述用户选择的用药人信息，作为使用所述第一药品的目标用药人信息；查询所述用户购买所述第二药品时上传的所述目标用药人信息对应用药人的购药资格证明信息并展示。
128.可选地，所述历史购药记录包括：所述用户的购药量；
129.所述展示模块503具体用于，根据历史上所述用户为每个用药人信息对应用药人所购买的所述第二药品的购药量，预测每个用药人使用所述第二药品后的剩余药量；根据所述预测出的每个用药人使用所述第二药品后的剩余药量，向所述用户推荐所述用户购买所述第二药品时填写的至少一个用药人信息并展示。
130.可选地，在将所述目标证明信息发送给审核人所使用的终端设备进行审核之前，所述展示模块503还用于，根据所述第一药品，确定所述第一药品治疗的各疾病；向所述用户展示所述第一药品治疗的各疾病的疾病信息；确定所述用户从展示的各疾病的疾病信息中选择的疾病，作为第一疾病；
131.所述发送模块505具体用于，将所述用户选择的所述第一疾病的疾病信息以及所述目标证明信发送给审核人所使用的终端设备进行审核。
132.可选地，所述历史购药记录还包括：用药人确诊的历史疾病；
133.所述展示模块503具体用于，从确定出的使用所述第一药品的目标用药人信息对应的用药人确诊的历史疾病中，确定出所述第一药品能治疗的历史疾病，作为第二疾病；确定所述第二疾病所归属的疾病类型；将所述第一药品所能治疗的所述疾病类型的疾病的疾病信息，排列在所述第一药品所能治疗的其他疾病类型的疾病的疾病信息之前进行展示。
134.可选地，所述展示模块503具体用于，针对所述第一药品所能治疗的每个疾病，确
定使用所述第一药品治疗该疾病的使用率，作为该疾病对应的使用率；按照所述第一药品所能治疗的每个疾病对应的使用率从高到低的顺序，展示所述第一药品所能治疗的每个疾病的疾病信息。
135.可选地，所述展示模块503具体用于，判断所述购药资格证明信息是否超过所述购药资格证明信息的有效期；若是，则将所述购药资格证明信息展示给所述用户。
136.从上述装置可以看出，由于用户通过该装置购买第一药品时，并不需要用户上传购买第一药品所需的购药资格证明信息，而可以先根据用户的历史购药记录，确定出用户购买过的与第一药品相匹配的第二药品，以获取用户历史上购买第二药品时所上传的购药资格证明信息，作为购买第一药品所需的购药资格证明信息，这样可以有效地提高用户的购药效率，从而给用户的购药带来了极大的方便。
137.本说明书还提供了图6所示的一种对应于图1的电子设备的示意结构图。如图6所述，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，以实现上述图1所述的药品下单的方法。当然，除了软件实现方式之外，本说明书并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
138.需要说明的是，本说明书中提供的药品下单的方法所涉及的执行逻辑，可以由客户端独自来完成，即若是客户端中保存有用户的历史购药记录以及用户之前发送给审核人的购药资格证明信息，那么上述步骤均可以有客户端作为执行主体来完成。当然，也可以由客户端和服务器之间通过信息交互来完成。
139.在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardware description language，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等，目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
140.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc 625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
141.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
142.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
143.本领域内的技术人员应明白，本说明书的实施例可提供为方法、系统、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
144.本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
145.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
146.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
147.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网
络接口和内存。
148.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
149.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
150.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
151.本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
152.本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
153.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
154.以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。