一种电子处方处理方法及系统与流程

1.本技术涉及数据处理技术领域，尤其涉及一种电子处方处理方法及系统。


背景技术：

2.随着互联网技术的兴起，为人类的生活开辟了第二空间，其中，互联网医疗是互联网在医疗行业的新应用，互联网医院作为互联网医疗的载体和平台之一，可以利用互联网、人工智能、大数据等技术，构建一种全新的医疗服务模式，支持疾病辅助诊断、健康管理、远程会诊等功能。
3.而在现有的互联网医疗系统提供的在线取药方式中，患者根据的电子处方处方单选择药店购药时，由于存在患者不能在一家药店购买到处方单上所有药品的情况，需要患者不断试错，最终为了购买到处方单上的所有药品可能还会选择在不同的药房购买，甚至即使在患者复诊时获取的同样的处方单的情况下，也会存在第一次取药的药店药源不足的情况，所以就需要患者不断试错来选择合适的药店，这导致患者取药过程较繁琐，极大地降低了患者购药体验，且患者自己选择药店取药时，由于处方审核不规范，也会存在用药安全问题。


技术实现要素：

4.基于此，有必要针对上述技术问题，提供一种电子处方处理方法及服务器，该方法应用区块链技术，以解决现有的互联网医疗系统中，患者取药过程较繁琐、用户体验较差以及用药安全的问题。
5.本技术实施例的第一方面提供了一种电子处方处理方法，包括：
6.解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息；所述患者处方信息包括患者个人信息、诊断信息以及药品信息；
7.根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表；
8.将所述药房列表发送至患者端供患者选择；
9.接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付；
10.当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证；所述支付凭证作为所述患者到药房取药的取药凭证。
11.本技术实施例的第二方面提供了一种电子处方处理系统，包括：
12.处方解析模块：用于解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息；所述患者处方信息包括患者个人信息、诊断信息以及药品信息；
13.列表生成模块：用于根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表；
14.列表发送模块：用于将所述药房列表发送至患者端供患者选择；
15.订单支付模块：用于接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付；
16.取药模块：用于当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证；所述支付凭证作为所述患者到药房取药的取药凭证。
17.本技术实施例的第三方面提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现上述电子处方处理方法。
18.本技术实施例的第四方面提供了一个或多个存储有计算机可读指令的可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行如上述电子处方处理方法。
19.本技术实施例提供的一种电子处方处理方法，应用于服务器，通过医生端与患者端进行在线诊断，获取医生端开具的待审核电子处方单，然后解析待审核电子处方单，获得对应的患者处方信息，根据患者处方信息中的药品信息在预设药房数据库中匹配满足药品信息中药品数量和药品种类的药房，生成药房列表，并将药房列表发送至患者端供患者选择，接收患者端反馈的药房选择信息，生成支付订单发送至患者端供患者支付，接收到患者端发送的对所述电子支付订单的支付消息时，生成支付凭证发送至患者端供患者取药时出示。通过系统直接为患者筛选满足处方单上所有药品信息的药店，不需要患者不断试错去选择药房，简化了患者的取药过程，节省了患者的取药时间，提高了用户体验。
附图说明
20.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
21.图1是本技术实施例中一种电子处方处理方法的一应用环境示意图；
22.图2是本技术实施例中一种电子处方处理方法的实现流程示意图；
23.图3是本技术另一实施例中电子处方处理方法的实现流程示意图；
24.图4是本技术再一实施例中电子处方处理方法的实现流程示意图；
25.图5是本技术一实施例提供的一药房入网流程图；
26.图6是本技术一实施例中一种电子处方处理系统的一结构示意图；
27.图7是本技术一实施例中计算机设备的一示意图。
具体实施方式
28.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
29.请参阅图1，图1示出了本技术实施例中电子处方处理方法的一应用环境示意图，
如图1所示，本技术实施例提供的电子处方处理方法，可应用在如图1的应用环境中，服务端的服务器集群包括医院信息系统(包括医生端和药师端等)、药房端、患者端以及运营端的服务器，用于执行各终端发布的命令与信息传递，建立各终端之间的联系，完成在线问诊、开方、药方审核、运营以及取药过程。在本技术实施例中，如表1所示，客户端可以为医院信息系统(包括医生端和药师端等)、药房端、患者端以及运营端，其包括但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。服务端可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
[0030][0031]
表1
[0032]
请参阅表1，表1所示为本技术实施例中服务器端相连接的各终端的功能模块，下面结合本技术实施例提供一种电子处方处理方法对表1进行详细描述。
[0033]
请参阅图2，图2所示为本技术实施例中电子处方处理方法的实现流程图，以该方法应用在图1中的服务端的服务器集群为例进行说明，包括如下步骤：
[0034]
s11：解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息。
[0035]
在步骤s11中，待审核电子处方单是由所述医生端与患者端进行在线诊断过程中，由医生端在线开具的电子表单；医生端包括在线诊室模块和问诊设置模块，用于在线接诊、在线开具电子处方单，以及问诊参数设置和处方模板管理。医生端在开具好电子处方单后，用户可登录在线取药系统进行查看，优选地，可以依托微信、支付宝等第三方应用环境为载
体，作为用户(患者)登录终端入口，相比于一个应用软件更为轻量级，用户黏度更高，全业务流程用户无需进行注册，后台静默注册，用户体验会更好，也可以是系统以超链接形式的短信发送至患者的终端(例如手机等)，患者接收到短信通知并且可以通过点击超链接进行查看。
[0036]
在本实施例中，医生端在开具电子处方单之后上传到到电子处方处理系统，系统对上传的电子处方单进行解析。解析获得的患者处方信息包括患者的药品信息、诊断信息(例如既往病史及当前病症信息)、患者个人信息(例如患者的姓名、性别、年龄、家庭住址及联系方式等)以及诊断医生的身份信息(例如姓名、联系方式等)等，其中药品信息可以包括针对病情信息开具的药物、针剂、理疗等治疗方式的剂量、疗程等信息。
[0037]
s12：根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表。
[0038]
在步骤s12中，预设药房数据库中包括药房信息，药房信息包括药房名称，药房地理位置，药房的药品信息等。由药房端的药房药品管理模块对药房的药房的药品信息，例如药房药品列表、库存信息、价格信息进行管理。
[0039]
在本实施例中，由于在预设的药房数据库中存储的药房信息，并非所有的药房都满足患者电子处方单上的药品信息，例如，一些药房药品种类不满足，还有一些包含电子处方单上的药品但是药品数量不满足。系统会根据患者电子处方单上面的药品信息，自动在预设的药房数据库中匹配满足所有药品信息条件的药房，并统计匹配到的满足条件的药房，生成药房列表，无需患者手动去筛选含有电子处方单上面药品的药房。
[0040]
作为本技术一实施例，所述药品信息包括但不限于药品种类和药品数量；所述根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表，包括：根据所述药品信息，从所述预设药房数据库中筛选出满足所述药品种类和药品数量的药房信息，生成初始药房列表；根据所述患者个人信息，对所述初始药房列表中的药房信息进行排序，生成最终药房列表。
[0041]
在本实施例中，根据患者处方信息中的药品信息，服务器首先对药房数据库的药房药品列表以及库存信息等进行搜索筛选，获得包含药品信息中所有药品的药房信息，生成初始药房列表。然后根据患者个人信息，例如地址信息，以及药房的药品价格信息，用户评价信息等，患者根据个人需求选择取药药房排序方式，形成一个最终药房列表。
[0042]
作为本技术一实施例，所述预设药房数据库包括医院药房和第三方药房；所述第三方药房入驻流程包括：接收第三方药房的药房机构信息，并将所述药房机构信息发送至运营端进行审核；所述运营端用于对所述药房机构信息进行资质审核并将资质审核结果反馈给所述服务器；接收所述运营端反馈的资质审核结果，若所述资质审核结果为合格，则将所述第三方药房的药品信息及所述药方机构信息存储至药房数据库中。
[0043]
在本实施例中，药房机构信息包括药房的《药品经营许可证》、营业执照以及药房经营场所、仓储等设施设备情况表、地理位置等，运营端用于对第三方药房的药方机构信息进行审核，并将审核结果反馈给服务器。其中，药房端和运营端包括但不限于计算机、笔记本电脑以及手机终端。如图5所示的药房入网流程图，第三方药房需要在药房端(终端)注册平台账号并上传药房机构信息，服务器将药房上传的药方机构信息发送至运营端，运营端在对接收到的药方机构信息进行资质审核，并将资质审核结果反馈给服务器。
[0044]
在本实施例中，资质审核结果包括合格和不合格，基于药房的资质审核结果，服务器对第三方药房的药方机构信息及药品信息等进行存储或驳回。如图5所示的药房入网流程图，服务器接收运营端反馈的资质审核结果，若审核通过，则药方机构信息生效，服务器将药房的药方机构信息以及药品信息等存储至药房数据库中。
[0045]
作为本技术一实施例，若资质审核结果为不通过，则运营端会将资质审核不合格的结果及不合格的原因分析等信息发送给服务器，服务器再将接收到的信息反馈给第三方药房，药房根据审核结果及原因分析，对药房进行调整，并将调整后的药房机构信息重新上传，系统重新对药房机构信息进行审核，循环直至所述资质审核通过为止，服务器会将审核通过的药方机构信息及药房药品信息存储至药房数据库中以供患者取药时选择。通过运营端的审核机构对要入驻的药房进行严格的资质审核，保证了系统入驻药房的质量以及患者在系统上面选购药品的安全性。
[0046]
其中，本技术实施例中药房选择入网的时间是随机的，该过程可能发生在患者取药过程中任一时刻。
[0047]
s13：将所述药房列表发送至患者端供患者选择。
[0048]
在步骤s13中，患者端即患者用户所属终端可以是手机、平板电脑等，通过患者端的处方管理模块选择取药方式以及药房等。
[0049]
在本实施例中，服务器将步骤s12中生成的最终药房列表发送至患者端，患者根据个人需求选择目标取药药房，并将药房选择信息反馈给服务器。其中，患者个人需求包括：支持预约到店自提或寄送到家的取药方式的药房、用户评价较好的药房或者药品价格较低的药房等。服务器接收到患者端反馈的药房选择信息后，会将药房选择信息发送给药房端，由药房端的药房处方管理模块，进行备药、核验电子处方单以及处方单流转监测。
[0050]
s14：接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付。
[0051]
在步骤s14中，药房选择信息即患者根据个人需求确定的目标取药药房，例如患者想要选择就近的药店到店自取，那么就可以选择按照药房距离排序，选择最近的药房作为目标取药药房。根据目标取药药房的药品价格信息以及电子处方单上面的药品信息生成电子支付订单，并发送至患者端供患者支付。
[0052]
在本实施例中，患者可以通过第三方系统完成支付，例如支付宝、微信、社保或银行卡支付等。在线电子处方外流的取药系统服务器采用远程过程调用(remote procedure call，rpc)或restful api调用第三方支付系统，保证服务器的稳定性和可靠性。支付完成后会在系统或以短信形式告知患者支付成功信息，其中，后台短信或消息推送系统可支持同步、异步发送等形式，是服务器在高并发情况下依然能够快速处理请求并且保持系统性能稳定。
[0053]
s15：当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证。
[0054]
在步骤s15中，支付凭证用于作为用户到目标取药药房自助取药的取药凭证。用户选择到店自提的取药方式时，患者向药店店员出示扫描该支付凭证或患者到自助药店自助扫描该支付凭证，核对患者支付信息。其中，支付信息包括药品种类，药品数量，患者个人信息等。支付凭证，可以是条形码形式，也可以是短信形式，条形码可以是一维码、二维码等。
[0055]
在本实施例中，接收到患者端发送的对电子支付订单的支付信息后，由药房端的药房处方管理模块进行备药，核验药品信息，患者可通过患者端(终端)接收消息中心模块发送的取药提醒信息等，根据患者的支付信息以及取药状态，药房端的药房药品管理模块实时更新药房药品列表、药品库存信息、药品价格信息等。
[0056]
请参阅图3，图3是本技术另一实施例提供的一种电子处方处理方法的实现流程图，相比于图2对应的实施例，本实施例提供的一种电子处方处理方法在步骤s11之后还包括s21～s22。详述如下：
[0057]
s21：按照预设的前置审核策略，根据所述患者个人信息和诊断信息，判断所述药品信息是否符合预设规则；
[0058]
s22：若所述药品信息符合预设规则，则根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表。
[0059]
在步骤s21中，前置审核策略是根据具体医院信息系统中的审核策略参数决定，其中，审核策略参数包括前置审核策略和后置审核策略，两者不能同时执行。前置审核策略是指在获取医生端发送的待审核电子处方单并解析之后，待审核电子处方单会流转到药师端，药师端根据患者个人信息和诊断信息对电子处方单进行审核，只有审核通过的电子处方单才能继续才能继续下一步的操作。其中，判断电子处方单中的药品信息是否符合预设规则包括依据药学部定义外流处方审查原则进行审核，也可以是审核用药是否合理，例如患者是否是特殊人群，药物与病症是否对应等。
[0060]
在本实施例中，根据患者个人信息和诊断信息，判断电子处方单中的药品信息是否符合预设规则，例如判断药品是否是患者所处年龄段能够服用的，药品信息中是否包含患者过敏源的药品等。根据审核结果，来决定处方单是否能从医院信息系统外流。
[0061]
在步骤s22中，若电子处方单经过审核后，药品信息符合预设规则，则医生端开具的电子处方单是有效的，可以外流出去，系统首先会根据药品信息在预设药房数据库中匹配满足药品信息的药房，即执行s12步骤。
[0062]
作为本技术一实施例，步骤s21之后还包括：若所述药品信息不符合预设规则，则将所述电子处方单判定为失效，并生成失效原因分析；基于所述失效原因分析更新所述电子处方单，并重新解析更新后的电子处方单。
[0063]
在本实施例中，倘若审核没有通过，即电子处方单中的药品信息不符合预设规则，则该电子处方单就会处于失效状态。服务器会返回失效通知以及失效原因分析给医生端，医生端接收到药房失效通知以及失效原因分析，医生端接收到药房失效通知以及失效原因，会重新编辑电子处方单再次上传到电子处方处理系统，服务器接收到修改后的电子处方单，对修改后的电子处方单进行解析后，重新对修改后的电子处方单对应的患者处方信息进行审核，直至患者处方信息中的药品信息符合预设规则为止，系统才能继续执行步骤s12及之后的操作过程。
[0064]
请参阅图4，图4是本技术另一实施例提供的一种电子处方处理方法的实现流程图，相比于图2对应的实施例，本实施例提供的一种电子处方处理方法中，步骤s15还包括s31～s32。详述如下：
[0065]
s31：按照预设的后置审核策略，在接收到所述患者端发送的对所述电子支付订单的支付信息之后，根据所述患者个人信息和诊断信息，判断所述药品信息是否符合预设规
则；
[0066]
s32：若所述药品信息符合预设规则，则生成支付凭证。
[0067]
在步骤s31中，若医院信息系统中的审核策略参数设置为后置审核策略，则按照预设的后置审核策略，在接收到所述患者端发送的对所述电子支付订单的支付信息之后，根据患者个人信息和诊断信息，判断所述药品信息是否符合预设规则，需要说明的是后置审核策略是上述前置审核策略不能同时执行，也就是说，电子处方处理系统在获取医生端发送的待审核电子处方单并解析之后对电子处方单审核之后，就不会在接收到所述患者端发送的对所述电子支付订单的支付信息之后重复审核，同样地，若是在接收到所述患者端发送的对所述电子支付订单的支付信息之后对电子处方单进行审核，则在获取医生端发送的待审核电子处方单并解析之后并不会对电子处方单进行审核。
[0068]
在本实施例中，在接收到患者端发送的对电子支付订单的支付成功的信息之后，根据所述患者个人信息和诊断信息，判断电子处方单中的药品信息是否符合预设规则。同前置审核策略中的判断方法，判断电子处方单中的药品信息是否符合预设规则包括依据药学部定义外流处方审查原则对待审核电子处方单进行审核，也可以是审核用药是否合理，例如患者是否是特殊人群，药物与病症是否对应等。
[0069]
在步骤s32中，若电子处方单中的药品信息符合预设规则，则生成支付凭证。其中，根据预设规则对待审核电子处方单进行审核包括依据药学部定义外流处方审查原则进行审核，也可以是审核用药是否合理，例如患者是否是特殊人群，药物与病症是否对应等。
[0070]
在本实施例中，若电子处方单中的药品信息符合预设规则，则表示医生端开具的电子处方单是有效的，服务器会将患者支付费用以及电子支付订单发送至目标取药药房的目标终端，目标终端接收到的电子支付订单，会相应生成支付凭证并将支付凭证信息通过服务器发送至患者端，患者通过患者端获取支付凭证，凭借支付凭证可到目标取药药房进行取药，其中目标取药药房可以是普通药店也可以是自助取药药店。
[0071]
作为本技术一实施例，步骤s31之后还包括：若所述药品信息不符合预设规则，则退回对所述电子支付订单的支付费用，并生成失效原因分析；基于所述失效原因分析更新所述电子处方单，并重新解析更新后的电子处方单。
[0072]
在本实施例中，倘若药品信息不符合预设规则，则该电子处方单就会处于失效状态，服务器会将患者支付费用退还到患者账户。同时，服务器会返回失效通知以及失效原因分析(例如处方包含不能外流的药品等)给医生端，医生端接收到药房失效通知以及失效原因分析，会根据失效原因分析重新编辑电子处方单再次上传到系统，服务器接收到修改后的电子处方单，重复步骤s11～s14的操作，循环往复直至电子处方单审核通过为止，服务器才会将患者支付费用以及电子支付订单发送至目标取药药房的目标终端，目标终端接收到的电子支付订单，会相应生成支付凭证并将支付凭证信息通过服务器发送至患者端，患者通过患者端获取支付凭证，凭借支付凭证可到目标取药药房进行取药。
[0073]
另外地，本技术提供一种电子处方处理方法，还包括同步患者端取药状态至医院信息系统，服务器实时更新患者的取药状态，并将患者取药状态发送至医生端，以使医生端知晓患者的治疗状态。其中，同步患者取药状态在其它步骤中也会有相应的过程，这里不再一一赘述。
[0074]
本技术实施例提供的一种电子处方处理方法，应用于服务器，通过医生端与患者
端进行在线诊断，获取医生端开具的待审核电子处方单，然后解析待审核电子处方单，获得对应的患者处方信息，根据患者处方信息中的药品信息在预设药房数据库中匹配满足药品信息中药品数量和药品种类的药房，生成药房列表，并将药房列表发送至患者端供患者选择，接收患者端反馈的药房选择信息，生成支付订单发送至患者端供患者支付，接收到患者端发送的对所述电子支付订单的支付消息时，生成支付凭证发送至患者端供患者取药时出示。通过系统直接为患者筛选满足处方单上所有药品信息的药店，不需要患者不断试错去选择药房，简化了患者的取药过程，节省了患者的取药时间，提高了用户体验。
[0075]
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0076]
在一个实施例中，提供一种电子处方处理系统600，该电子处方处理系统与上述实施例中电子处方处理方法一一对应。如图6所示，该电子处方处理系统包括处方解析模块601、列表生成模块602、列表发送模块603、订单支付模块604以及取药模块605。各功能模块详细说明如下：
[0077]
处方解析模块601：用于解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息；所述患者处方信息包括患者个人信息、诊断信息以及药品信息；
[0078]
列表生成模块602：用于根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表；
[0079]
列表发送模块603：用于将所述药房列表发送至患者端供患者选择；
[0080]
订单支付模块604：用于接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付；
[0081]
取药模块605：用于当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证；所述支付凭证作为所述患者到药房取药的取药凭证。
[0082]
关于电子处方处理系统的具体限定可以参见上文中对于电子处方处理方法的限定，在此不再赘述。上述服务器中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0083]
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括可读存储介质、内存储器。该可读存储介质存储有操作系统、计算机可读指令和数据库。该内存储器为可读存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储电子处方处理方法所涉及的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种电子处方处理方法。本实施例所提供的可读存储介质包括非易失性可读存储介质和易失性可读存储介质。
[0084]
在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示
屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括可读存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令。该内存储器为可读存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机可读指令被处理器执行时以实现一种电子处方处理方法。本实施例所提供的可读存储介质包括非易失性可读存储介质和易失性可读存储介质。
[0085]
在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机可读指令，处理器执行计算机可读指令时实现以下步骤：
[0086]
解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息；所述患者处方信息包括患者个人信息、诊断信息以及药品信息；
[0087]
根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表；
[0088]
将所述药房列表发送至患者端供患者选择；
[0089]
接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付；
[0090]
当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证；所述支付凭证作为所述患者到药房取药的取药凭证。
[0091]
在一个实施例中，提供了一个或多个存储有计算机可读指令的计算机可读存储介质，本实施例所提供的可读存储介质包括非易失性可读存储介质和易失性可读存储介质。可读存储介质上存储有计算机可读指令，计算机可读指令被一个或多个处理器执行时实现以下步骤：
[0092]
解析医生端发送的待审核电子处方单，获得所述待审核电子处方单对应的患者处方信息；所述患者处方信息包括患者个人信息、诊断信息以及药品信息；
[0093]
根据所述药品信息在预设药房数据库中匹配满足所述药品信息的药房，并生成药房列表；
[0094]
将所述药房列表发送至患者端供患者选择；
[0095]
接收所述患者端反馈的药房选择信息，根据所述药房选择信息生成电子支付订单，并发送至患者端供患者支付；
[0096]
当接收到所述患者端发送的对所述电子支付订单的支付信息时，生成支付凭证；所述支付凭证作为所述患者到药房取药的取药凭证。
[0097]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一非易失性可读取存储介质或易失性可读存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储
器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
[0098]
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
[0099]
以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。