在线申请处方及凭处方购药的方法与流程

文档序号:17796247发布日期:2019-05-31 20:47阅读:4777来源:国知局

本发明涉及医药技术领域,具体涉及一种在线申请处方及凭处方购药的方法。



背景技术:

现有技术中,病患需要到医院等医疗机构中挂号就医,医生开具处方笺,处方笺在医院的各部门中流转,使得患者只能在医院中取药,对于药品的选择性较差,只能选择医院合作方的厂家的药品,而无法选择其他不同厂家的药品。并且现有处方笺开具速度慢,医院资源紧张,挂号、排队等耗时较长。由于医院资源紧张而产生的看病难、看病贵的问题,导致普通患者容易自己购买药品,导致吃错药、买错药的情况频发。因此如何提高医疗资源利用率及如何提高就医便捷性显得尤为重要。



技术实现要素:

鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种在线申请处方及凭处方购药的方法。

提供一种在线申请处方及凭处方购药的方法,包括:

后台服务器获取病史、症状及初诊药品名称,生成初步诊疗单,并将所述初步诊疗单推送至医师侧智能终端;

获取到诊断资格的医师侧智能终端依据所述初步诊疗单及自身采集的诊断调整数据生成处方。

其中,该方法之前还包括:调剂师侧智能终端采集患者的病史、症状及初诊药品名称,并上传至所述后台服务器。

其中,该方法之前还包括:调剂师侧智能终端采集基本信息及患者自带处方,并将基本信息、初诊药品名称及患者自带处方上传至所述后台服务器;所述基本信息包括:患者年龄、性别、病史及症状。

其中,所述的在线申请处方及凭处方购药的方法,还包括:所述后台服务器下发所述处方至药师侧智能终端,所述药师侧智能终端将审核完成的处方通过所述后台服务器推送至所述调剂师侧智能终端。

其中,所述的在线申请处方及凭处方购药的方法,还包括:患者侧智能终端采集病史、症状及初诊药品名称,并上传至所述后台服务器;所述医师侧智能终端将所述处方推送至所述患者侧智能终端;所述患者侧智能终端上传购买需求信息至所述后台服务器;所述后台服务器依据所述购买需求信息中的药店名称查找所述药店名称对应的药师侧智能终端,并将所述购买需求信息推送至所述药店名称对应的药师侧智能终端;所述药店名称对应的药师侧智能终端将审核完成的处方通过所述后台服务器推送至调剂师侧智能终端。

其中,所述的在线申请处方及凭处方购药的方法,还包括:患者侧智能终端采集病史、症状、取药药店名称及初诊药品名称,并上传至所述后台服务器;所述医师侧智能终端将所述处方推送至所述患者侧智能终端,同时所述后台服务器将所述处方推送至所述取药药店名称对应的药师侧智能终端;所述取药药店名称对应的药师侧智能终端将审核完成的处方通过所述后台服务器推送至调剂师侧智能终端。

其中,所述的在线申请处方及凭处方购药的方法,还包括:所述药师侧智能终端将药品价格信息发送至所述患者侧智能终端;所述患者侧智能终端进行支付。

本发明解决了普通病患离开医疗机构无法获得处方笺,降低普通病患容易买错药、吃错药导致身体不适等问题,解决普通病患没有处方无法在药店购买处方药的问题。并且提高了医生、药店、病患之间的联系,使得三方沟通更加顺畅,提高沟通效率,解决现有医院资源紧张的问题。

上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。

具体实施方式

以下描述充分地示出本发明的具体实施方案,以使本领域的技术人员能够实践它们。其他实施方案可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求,否则单独的部件和功能是可选的,并且操作的顺序可以变化。一些实施方案的部分和特征可以被包括在或替换其他实施方案的部分和特征。

下文所提到的医师侧智能终端、调剂师侧智能终端及患者侧智能终端可以为手机、平板或pc,智能终端通过安装在手机、平板或pc上的app采集数据,并对采集的数据进行处理。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s11:当患者去药店购处方药或非处方药时,调剂师询问患者的病史及症状,打开调剂师侧智能终端上的app,勾选和填入病史和症状,并且在app上选入患者需要购买的初诊药品名称,提交。

此时,调剂师侧智能终端即可采集到患者的病史、症状及初诊药品名称,并上传至后台服务器。

s12:后台服务器获取病史、症状及初诊药品名称,大数据匹配常规用法用量,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s13:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医生抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s14:后台服务器下发处方至药师侧智能终端,此时药师侧智能终端上的app不断提醒,药师即可查看并审核。

s15:药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端,此时,调剂师侧智能终端上的app不断提醒。调剂师在调剂师侧智能终端上拿到审核过的处方,进行复核、打印、存根,并配药给患者。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s21:患者带着纸质的或者电子的处方笺,去药店购处方药或非处方药,调剂师在调剂师侧智能终端上的app录入基本信息和提交患者自带的处方笺。调剂师在调剂师侧智能终端上的app上选入自带处方笺上的药品,提交,此时患者自带的处方笺已经流转到后台服务器。

此时,调剂师侧智能终端即可采集到基本信息及患者自带处方,并将基本信息、初诊药品名称及患者自带处方上传至后台服务器。

基本信息包括:患者年龄、性别、病史及症状。

s22:后台服务器获取病史、症状及初诊药品名称,大数据匹配常规用法用量,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s23:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医师抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s24:后台服务器下发处方至药师侧智能终端,此时药师侧智能终端上的app不断提醒,药师即可查看并审核。

s25:药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端,此时,调剂师侧智能终端上的app不断提醒。调剂师在调剂师侧智能终端上拿到审核过的处方,进行复核、打印、存根,并配药给患者。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s31:患者随时随地直接通过患者侧智能终端上的app填写相关的病史和症状,选择初诊药品名称,并提交申请,具体的可以通过微信公众号填写相关信息。

此时,患者侧智能终端即可采集到病史、症状及初诊药品名称,并上传至后台服务器。

s32:后台服务器获取病史、症状及初诊药品名称,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s33:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医师抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s34:后台服务器下发处方至患者侧智能终端,患者即可通过通过微信公众号得到处方,此时处方已生效。

s35:患者在公众号上选择药店,提出购买需求,此时,患者侧智能终端即可上传购买需求信息至后台服务器。

s36:后台服务器依据购买需求信息中的药店名称查找药店名称对应的药师侧智能终端,并将购买需求信息推送至药店名称对应的药师侧智能终端,药师进行审核。

s37:药师在药师侧智能终端审核通过。

s38:药店名称对应的药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端。

此时,患者直接去线下药店,调剂师复核、打印、存根,患者付款拿药。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s41:患者随时随地直接通过患者侧智能终端上的app填写相关的病史和症状,选择初诊药品名称,并提交申请,具体的可以通过微信公众号填写相关信息。此时,患者侧智能终端即可采集到病史、症状及初诊药品名称。

s42:患者在患者侧智能终端上选择将会取药的线下药店,并提交,患者侧智能终端即可采集到取药药店名称,与步骤s41采集到的病史、症状及初诊药品名称一同上传至后台服务器。

s43:后台服务器获取病史、症状及初诊药品名称,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s44:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医师抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s45:后台服务器下发处方至患者侧智能终端,患者即可通过通过微信公众号得到处方,此时处方已生效。

s46:后台服务器将处方推送至患者侧智能终端采集的取药药店名称所对应的药师侧智能终端,药师进行审核。

s47:药师在药师侧智能终端审核通过。

s48:患者侧智能终端采集的取药药店名称所对应的药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端。

此时,患者直接去线下药店,调剂师复核、打印、存根,患者付款拿药。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s51:患者随时随地直接通过患者侧智能终端上的app填写相关的病史和症状,选择初诊药品名称,并提交申请,具体的可以通过微信公众号填写相关信息。

此时,患者侧智能终端即可采集到病史、症状及初诊药品名称,并上传至后台服务器。

s52:后台服务器获取病史、症状及初诊药品名称,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s53:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医师抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s54:后台服务器下发处方至患者侧智能终端,患者即可通过通过微信公众号得到处方,此时处方已生效。

s55:患者在公众号上选择药店,提出购买需求,此时,患者侧智能终端即可上传购买需求信息至后台服务器。

s56:后台服务器依据购买需求信息中的药店名称查找药店名称对应的药师侧智能终端,并将购买需求信息推送至药店名称对应的药师侧智能终端,药师进行审核。

s57:药师在药师侧智能终端审核通过。

s58:药师侧智能终端将药品价格信息发送至患者侧智能终端,患者侧智能终端进行支付。

患者在公众号上获取药品价格,直接线上支付。

s59:药店名称对应的药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端,调剂师复核,并打印、存根。

s510:患者直接去线下药店,柜台或者售药机拿药。

在一些说明性的实施例中,提供一种在线申请处方及凭处方购药的方法,包括:

s61:患者随时随地直接通过患者侧智能终端上的app填写相关的病史和症状,选择初诊药品名称,并提交申请,具体的可以通过微信公众号填写相关信息。此时,患者侧智能终端即可采集到病史、症状及初诊药品名称。

s62:患者在患者侧智能终端上选择将会取药的线下药店,并提交,患者侧智能终端即可采集到取药药店名称,与步骤s61采集到的病史、症状及初诊药品名称一同上传至后台服务器。

s63:后台服务器获取病史、症状及初诊药品名称,生成初步诊疗单,并将初步诊疗单推送至医师侧智能终端。

医师侧智能终端的数量为多个,医师侧智能终端上的app不断提醒,此时多个医生即可进行抢单。

s64:获取到诊断资格的医师侧智能终端依据初步诊疗单及自身采集的诊断调整数据生成处方。

其中,抢到初步诊疗单的医师侧智能终端具有诊断资格,抢到初步诊疗单的医生通过互联网医疗,根据病史、症状及初诊药品名称进行诊断和调整,此时获取到诊断资格的医师侧智能终端即可生成处方。

其中,医师抢单后,可通过文字、音频或视频发起跟患者的沟通问询,进行观察了解。

s65:后台服务器下发处方至患者侧智能终端,患者即可通过通过微信公众号得到处方,此时处方已生效。

s66:后台服务器将处方推送至患者侧智能终端采集的取药药店名称所对应的药师侧智能终端,药师进行审核。

s67:药师在药师侧智能终端审核通过。

s68:药师侧智能终端将药品价格信息发送至患者侧智能终端,患者侧智能终端进行支付。

患者在公众号上获取药品价格,直接线上支付。

s69:患者侧智能终端采集的取药药店名称所对应的药师侧智能终端将审核完成的处方通过后台服务器推送至调剂师侧智能终端,调剂师复核,并打印、存根。

s610:患者直接去线下药店、柜台或者售药机扫码、刷身份证或其他方式对接取药。

本领域技术人员还应当理解,结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性,上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件,取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用,以变通的方式实现所描述的功能,但是,这种实现决策不应解释为背离本公开的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1