首页> 中国专利> 购药订单处理方法及装置、电子设备及可读存储介质

购药订单处理方法及装置、电子设备及可读存储介质

摘要

本发明公开了一种购药订单处理方法及装置、电子设备及可读存储介质。其中,该方法包括:根据购药用户的购药订单的订单信息,判断购药订单是否为代买订单;若购药订单为代买订单,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;若购药订单不是代买订单,则根据购药清单为购药订单开具处方单。本发明解决了由于相关技术中无法识别用户代买药品行为,导致用户用药隐患的技术问题。

著录项

  • 公开/公告号CN114912983A

    专利类型发明专利

  • 公开/公告日2022-08-16

    原文格式PDF

  • 申请/专利权人 北京三快在线科技有限公司;

    申请/专利号CN202210607868.2

  • 发明设计人 刘山山;张云龙;李洪光;张喜;

    申请日2022-05-31

  • 分类号G06Q30/06(2012.01);G16H10/60(2018.01);G16H20/10(2018.01);

  • 代理机构北京润泽恒知识产权代理有限公司 11319;

  • 代理人任亚娟

  • 地址 100080 北京市海淀区北四环西路9号2106-030

  • 入库时间 2023-06-19 16:25:24

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2023-06-23

    实质审查的生效 IPC(主分类):G06Q30/06 专利申请号:2022106078682 申请日:20220531

    实质审查的生效

说明书

技术领域

本发明涉及数据库技术领域,具体而言,涉及一种购药订单处理方法及装置、电子设备及可读存储介质。

背景技术

目前所有平台线上处方药购药流程需要按照相关规定,必须要经过如图1所示的审核流程。而在现有技术中某平台中购买处方药流程,如图2所示,在提交购药清单后,需要继续补充用药人信息,包括身份证实名信息,以及相关的疾病名称,若是相对敏感药品,必须上传线下就诊后的复诊凭证,然后医生根据申请内容决定是否开方,只有医生审核开方通过,药师审方通过,药品才能出库配送。

处方药品在提交审核到开方医生前,是无法识别并判断用户填写购药清单和用户信息是否匹配,会出现利用其他人的用药信息购买不符合本人的药品,例如使用成人的用药信息购买儿童的等等代买的行为。

申请人在实现本发明的过程中,发现相关技术中至少存在以下技术问题。

1.处方需要提交到开方医生处才能被识别后拒方,浪费了平台开方医生的资源;

2.若医生没有识别是他人代买处方药品,容易有用药安全隐患。

3.一些平台根据预设的规则,例如购药人无法利用男性患者信息购药专治女性患者的处方药,这种直接拒方的行为会因为一部分用户不了解处方药的购买流程而损失一部分订单和尝新用户。

可见,相关技术中针对上述的问题,目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种购药订单处理方法及装置、电子设备及可读存储介质,以至少解决由于相关技术中无法识别用户代买药品行为,导致用户用药隐患的技术问题。

根据本发明实施例的一个方面,提供了一种购药订单处理方法,包括:根据购药用户的购药订单的订单信息,判断所述购药订单是否为代买订单;若所述购药订单为代买订单,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,所述用药人信息位于所述购药用户的账户信息中;若所述购药订单不是代买订单,则根据所述购药清单为所述购药订单开具处方单。

进一步地,根据购药用户的订单信息判断所述购药订单是否为代买订单,包括:通过预先训练完成的代买判别模型,根据所述订单信息中的购药清单以及实际用药人信息确定所述购药订单为代买订单。

进一步地,根据购药用户的订单信息判断所述购药订单是否为代买订单,包括:获取所述购药用户提供的复诊凭证;对所述复诊凭证进行图像识别,以得到所述购药订单的订单信息对应的用药信息;若所述用药信息与所述订单信息中的实际用药人信息不匹配,则确定所述购药订单为代买订单。

进一步地,所述订单信息包括购药清单以及用药信息,所述用药人信息包括所述购药用户对应的购药历史记录以及用药人记录,其中,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,包括:通过预先训练完成的用药推荐模型,根据所述购药清单、所述用药信息、所述购药历史记录以及所述用药人记录,对所述用药人记录中的用药人进行打分并排序,以得到所述至少一个推荐用药人。

进一步地,在根据所述账户信息、所述购药订单中的购药清单以及用药人信息确定至少一个推荐用药人之后,还包括:在所述购药用户的用户终端上展示所述至少一个推荐用药人;根据目标用药人开具所述购药订单对应的处方,其中,所述目标用药人为所述购药用户在所述至少一个推荐用药人中选择的用药人。

根据本发明实施例的另一方面,还提供了一种购药订单处理装置,包括:判断模块,用于根据购药用户的购药订单的订单信息,判断所述购药订单是否为代买订单;确定模块,用于若所述购药订单为代买订单,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,所述用药人信息位于所述购药用户的账户信息中;处理模块,用于若所述购药订单不是代买订单,则根据所述购药清单为所述购药订单开具处方单。

进一步地,所述判断模块包括:第一确定单元,用于通过预先训练完成的代买判别模型,根据所述订单信息中的购药清单以及实际用药人信息确定所述购药订单为代买订单。

进一步地,所述判断模块包括:获取单元,用于获取所述购药用户提供的复诊凭证;图像识别单元,用于对所述复诊凭证进行图像识别,以得到所述购药订单的订单信息对应的用药信息;第二确定单元,用于若所述用药信息与所述订单信息中的实际用药人信息不匹配,则确定所述购药订单为代买订单。

进一步地,所述订单信息包括购药清单以及用药信息,所述用药人信息包括所述购药用户对应的购药历史记录以及用药人记录,其中,所述确定模块包括:推荐单元,用于通过预先训练完成的用药推荐模型,根据所述购药清单、所述用药信息、所述购药历史记录以及所述用药人记录,对所述用药人记录中的用药人进行打分并排序,以得到所述至少一个推荐用药人。

进一步地,还包括:展示模块,用于在根据所述账户信息、所述购药订单中的购药清单以及用药人信息确定至少一个推荐用药人之后,在所述购药用户的用户终端上展示所述至少一个推荐用药人;所述处理模块,还用于根据目标用药人开具所述购药订单对应的处方,其中,所述目标用药人为所述购药用户在所述至少一个推荐用药人中选择的用药人。根据本发明实施例的另一方面,还提供了一种电子设备,包括处理器,存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令,所述程序或指令被所述处理器执行时实现如上所述的购药订单处理方法的步骤。

根据本发明实施例的另一方面,还提供了一种可读存储介质,所述可读存储介质上存储程序或指令,所述程序或指令被处理器执行时实现如上所述的购药订单处理方法的步骤。

在本发明实施例中,根据购药用户的购药订单的订单信息,判断购药订单是否为代买订单;若购药订单为代买订单,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;若购药订单不是代买订单,则根据购药清单为购药订单开具处方单。本实施例中,根据购药订单的订单信息判断购药订单是否是代买订单,在购药订单为代买订单时,根据订单信息以及用药人信息来确定推荐用药人,进行用药人推荐,从而实现了帮助购药用户快速准确购药,避免因拒方造成用户和包含处方药购药订单的流失,同时也有效减少了购药平台的医疗资源的供给压力的技术效果,进而解决了由于相关技术中无法识别用户代买药品行为,导致用户用药隐患的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:

图1是根据现有技术的一种线上处方药购药流程的示意图;

图2是根据现有技术的一种平台线上处方药购药流程的示意图;

图3是根据本发明实施例的一种可选的购药订单处理方法的流程示意图;

图4是根据本发明实施例的一种可选的购药订单处理装置的结构示意图。

具体实施方式

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

需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

在介绍本实施例的技术方案之前,首先对以下名词进行解释:

开方医生:对用户提交的购药请求进行审核,识别购买的处方药是否存在不合理用药的行为,则为用户开具电子处方单,否则拒绝开具处方,用户无法购买处方药。

审方药师:对开方医生开具的电子处方进行审核,判断是否有不合理用药的行为,若审核不通过,则用户无法购买药品。

复诊凭证:必须线下就诊后的纸质处方信息、门诊病例、住院病例、出院小结、诊断证明、检测报告等有效的用药凭证信息。比如6岁以下儿童在线上购药,必须上传线下的复诊凭证,才可以买药。

拒方:医生拒绝开具处方,患者无法进行购买处方药流程。

然后,对本实施例中的技术方案进行详细介绍:

根据本发明实施例,提供了一种购药订单处理方法,如图3所示,该方法包括:

S302,根据购药用户的购药订单的订单信息,判断购药订单是否为代买订单;

在本实施例中,购药订单中订单信息中包括购药清单以及用药信息,其中,购药清单中包括非处方药品以及处方药品,处方药品需要开方医生对购药用户提交的购药请求进行审核,识别购买的处方药是否存在不合理用药的行为,则为购药用户开具电子处方单,否则拒绝为购药用户提交的购药清单开具处方。而对于非处方药品,则不需要进行审核,购药用户可以自行购买。

本实施例中的购药订单为购药用户提交的购药请求,购药订单中的订单信息包括用药清单以及实际用药人信息。其中,实际用药人信息包括但不限于实际用药人的姓名、年龄、性别、购药用户输入的诊断病症、购药史以及用药清单等。

在具体地应用场景中,存在购药用户帮实际用药人代买处方药的情况下,在该种情况下,需要确定购药用户购买的处方药与实际用药人的病症信息是否吻合。

此外,若购药用户未明确是帮他人购买,需要确定购药订单中的处方药是否适用于实际用药人。本实施例中,根据用药信息对应的药品使用知识图谱对实际用药人信息进行匹配,可以判断购药订单是否为代买订单。其中,处方药对应的药品使用知识图谱包括但不限于该处方药适用的病症信息、适用人群信息、禁忌事项以及服用剂量等。

可选地,在本实施例中,根据购药用户的订单信息判断购药订单是否为代买订单,包括但不限于:通过预先训练完成的代买判别模型,根据订单信息中的购药清单以及实际用药人信息确定购药订单为代买订单。

本实施例中的代买判别模型用于根据购药清单以及实际用药人信息来预测购药订单是否代买订单。具体地,通过向代买判别模型中输入购药订单对应的订单信息中的实际用药人信息以及购药清单,由代买识别模型预测购买订单是否是代买订单。

在一些实施例中,使用疾病库、病症库、药品适用管理库、用药人特征信息、历史问诊信息、历史处方信息等作为训练模型的数据源。然后,基于上述数据源中的数据构建训练样本,以得到训练样本集。基于构建的训练样本集训练代买判别模型,以问诊数据、购药清单、药品库、病症、药品适用数据等作为模型输入,以实际用药人信息对应的得分为训练目标,训练代买判别模型。在本实施例中,将实际用药人信息以及购药清单输入至代买识别模型中,以得到实际用药人信息对应的得分,然后基于得分判断购买订单是否为代买订单。其中,实际用药人信息包括但不限于购药用户输入的病症描述以及诊断结果。

在上述示例中,通过预先训练完成的代买判别模型,根据购药清单以及实际用药人信息确定购药订单是否为代买订单,可以实现对购药用户是否为代买处方药进行准确地判断。

可选地,在本实施例中,根据购药用户的订单信息判断购药订单是否为代买订单,包括但不限于:获取购药用户提供的复诊凭证;对复诊凭证进行图像识别,以得到购药订单的订单信息对应的用药信息;若用药信息与订单信息中的实际用药人信息不匹配,则确定购药订单为代买订单。

在本实施例中,可以根据现有的图片识别等技术可以识别出复诊凭证中的各类用药信息,包括但不限于:身份证号、姓名、年龄、用药清单、诊断病症、购药史等等。本实施例中的复诊凭证包括但不限于线下就诊后的纸质处方信息、住院单、检查单、检验单、体检报告等待有效的用药凭证。

若识别得到复诊凭证对应的用药信息不存在缺失且信息明确,则可以通过比对用药信息以及实际用药人信息比对,若信息不一致,则该购药用户的购药行为为代买行为,购药订单为代买订单;若用药信息与实际用药人信息一致,则确定该购药用户的购药行为不为代买行为,购药订单不为代买订单。

此外,若无复诊凭证、或者复诊凭证无法识别出相关用药信息,则使用上述示例中的代买模型识别对购药订单进行代买订单识别。

在上述示例中,通过预先训练完成的代买判别模型,根据用药信息以及实际用药人信息确定购药订单是否为代买订单,可以实现对购药用户是否为代买处方药进行准确地判断。

获取购药用户提供的复诊凭证;对复诊凭证进行图像识别,以得到用药信息;对用药信息与实际用药人信息进行比对来确定购药订单是否为代买订单,可以实现对购药用户是否为代买处方药进行准确地判断。

S304,若购药订单为代买订单,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;

在购药用户的购药订单为代买订单的情况下,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;

可选地,在本实施例中,订单信息包括购药清单以及用药信息,用药人信息包括购药用户对应的购药历史记录以及用药人记录,其中,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,包括但不限于:通过预先训练完成的用药推荐模型,根据购药清单、用药信息、购药历史记录以及用药人记录,对用药人记录。

具体地,在识别到购药订单为代买订单后,此时需要在购药用户的用户终端上展示代买提示,以提示用户实际用药人信息与订单信息中的用药信息不一致,此时需要基于购药用户的购药历史中的其他用药人信息,来为购药用户展示至少一个推荐用药人,来帮助购药用户选择正确的用药人。

在本实施例中,在确定购药订单为代买订单后,获取购药用户对应的账户中的用药人信息,用药人信息包购药账户对应的购药历史记录以及用药人记录。然后,基于用药人记录中每个用药人分别对应的历史购药信息、历史诊断信息、历史症状信息以及历史购药清单,对当前购药订单对应的用药信息进行匹配,来确定推荐用药人列表,列表中会基于匹配度对推荐用药人进行排序,推荐用药人列表中包括至少一个推荐用药人。

具体地,在本实施例中,将订单信息中的购药清单、用药信息以及用药人信息中的用药人记录、购药历史记录输入至用药推荐模型,以对用药人记录中的用药人进行打分并进行排序,以得到推荐用药人列表。其中,用药人信息包括病症信息以及疾病结果。用药人记录中包括用药人名单、用药人的诊断结果、病症记录以及用药史等。

在一个例子中,将购药订单中的购药清单、用药人信息、用药人记录以及购药历史记录,输入至用药推荐模型,获取符合各项行为特征的推荐用药人列表,并利用预设规则找出最匹配的用药人,进行推荐,供购药用户选择。

在一些实施例中,使用疾病库、病症库、药品适用管理库、用药人信息、历史问诊信息、历史处方信息等作为训练模型的数据源。然后,基于上述数据源中的数据构建训练样本,以得到训练样本集。基于构建的训练样本集训练用药推荐模型,以问诊数据、订单数据、药品库、病症、药品适用数据等作为模型输入,以用药人信息对应的得分为训练目标,训练用药推荐模型。

在本实施例中,将购药清单、用药人信息、用药人记录以及购药历史记录至用药推荐模型中,以得到用药人信息对应的得分,然后基于得分确定用药人是否为推荐用药人。

可选地,在本实施例中,在根据账户信息、购药订单中的购药清单以及用药人信息确定至少一个推荐用药人之后,还包括但不限于:在购药用户的用户终端上展示至少一个推荐用药人;根据目标用药人开具购药订单对应的处方,其中,目标用药人为购药用户在至少一个推荐用药人中选择的用药人。

具体地,在确定购药订单为代买订单后,根据购药订单的订单信息以及用药人信息获取至少一个推荐用药人,然后在购药用户的用户终端上展示推荐用药人对应的推荐用药人列表,检测用户作用于推荐用药人列表中的用户操作,确定用户选择的目标用药人,然后根据目标用药人开具购药订单对应的处方。

在一些实施例中,若推荐用药人列表为空或用户不选择推荐用药人列表中的用药人,则表示用户对当前推荐或识别结果不认可,若用户坚持提交购药订单,则将购药订单发送至开方医生,以使开方医生人工审核用药申请。

在购药订单中的购药清单对应的用药信息与用药人信息匹配的情况下,为用户开具购药订单对应的处方,如此,则可以跳过开方医生审核购药订单,生成电子处方单。接下来,将购药用户购买的购药订单发送至审核节点,审核节点用于对购药订单对应的处方单进行审核,审核节点通常由专业药师进行审核。在药师审核电子处方单且审核通过后,商家进行购药订单的配货送货等订单流程。配货送货等订单流程在现有技术中已较为成熟,本实施例中对此不做赘述。

S306,若购药订单不是代买订单,则根据购药清单为购药订单开具处方单。

具体地,在本实施例中,若购药订单不是代买订单,则表示购药用户的购药订单中的购药清单与用药人信息是匹配的,可以开具相应地处方单。接下来,将购药用户购买的购药订单发送至审核节点,审核节点用于对购药订单对应的处方单进行审核,审核节点通常由专业药师进行审核。在药师审核电子处方单且审核通过后,商家进行购药订单的配货送货等订单流程。配货送货等订单流程在现有技术中已较为成熟,本实施例中对此不做赘述。

通过本发明实施例,根据购药用户的购药订单的订单信息,判断购药订单是否为代买订单;若购药订单为代买订单,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;若购药订单不是代买订单,则根据购药清单为购药订单开具处方单。本实施例中,根据购药订单的订单信息判断购药订单是否是代买订单,在购药订单为代买订单时,根据订单信息以及用药人信息来确定推荐用药人,进行用药人推荐,从而实现了帮助购药用户快速准确购药,避免因拒方造成用户和包含处方药购药订单的流失,同时也有效减少了购药平台的医疗资源的供给压力的技术效果,进而解决了由于相关技术中无法识别用户代买药品行为,导致用户用药隐患的技术问题。

需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例,还提供了一种用于实施上述购药订单处理方法的购药订单处理装置,如图4所示,该装置包括:

1)判断模块40,用于根据购药用户的购药订单的订单信息,判断所述购药订单是否为代买订单;

2)确定模块42,用于若所述购药订单为代买订单,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,所述用药人信息位于所述购药用户的账户信息中;

3)处理模块44,用于若所述购药订单不是代买订单,则根据所述购药清单为所述购药订单开具处方单。

可选地,在本实施例中,所述判断模块40包括:

1)第一确定单元,用于通过预先训练完成的代买判别模型,根据所述订单信息中的购药清单以及实际用药人信息确定所述购药订单为代买订单。

可选地,在本实施例中,所述判断模块40包括:

1)获取单元,用于获取所述购药用户提供的复诊凭证;

2)图像识别单元,用于对所述复诊凭证进行图像识别,以得到所述购药订单的订单信息对应的用药信息;

3)第二确定单元,用于若所述用药信息与所述订单信息中的实际用药人信息不匹配,则确定所述购药订单为代买订单。

可选地,在本实施例中,所述订单信息包括购药清单以及用药信息,所述用药人信息包括所述购药用户对应的购药历史记录以及用药人记录,其中,所述确定模块42包括:

1)推荐单元,用于通过预先训练完成的用药推荐模型,根据所述购药清单、所述用药信息、所述购药历史记录以及所述用药人记录,对所述用药人记录中的用药人进行打分并排序,以得到所述至少一个推荐用药人。

可选地,在本实施例中,还包括:

1)展示模块,用于在根据所述账户信息、所述购药订单中的购药清单以及用药人信息确定至少一个推荐用药人之后,在所述购药用户的用户终端上展示所述至少一个推荐用药人;

2)所述处理模块44,还用于根据目标用药人开具所述购药订单对应的处方,其中,所述目标用药人为所述购药用户在所述至少一个推荐用药人中选择的用药人。

通过本发明实施例,根据购药用户的购药订单的订单信息,判断购药订单是否为代买订单;若购药订单为代买订单,根据购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,用药人信息位于购药用户的账户信息中;若购药订单不是代买订单,则根据购药清单为购药订单开具处方单。本实施例中,根据购药订单的订单信息判断购药订单是否是代买订单,在购药订单为代买订单时,根据订单信息以及用药人信息来确定推荐用药人,进行用药人推荐,从而实现了帮助购药用户快速准确购药,避免因拒方造成用户和包含处方药购药订单的流失,同时也有效减少了购药平台的医疗资源的供给压力的技术效果,进而解决了由于相关技术中无法识别用户代买药品行为,导致用户用药隐患的技术问题。

实施例3

根据本发明实施例,还提供了一种电子设备,包括处理器,存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令,所述程序或指令被所述处理器执行时实现如上所述的购药订单处理方法的步骤。

可选地,在本实施例中,存储器被设置为存储用于执行以下步骤的程序代码:

S1,根据购药用户的购药订单的订单信息,判断所述购药订单是否为代买订单;

S2,若所述购药订单为代买订单,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,所述用药人信息位于所述购药用户的账户信息中;

S3,若所述购药订单不是代买订单,则根据所述购药清单为所述购药订单开具处方单。

可选地,本实施例中的具体示例可以参考上述实施例1中所描述的示例,本实施例在此不再赘述。

实施例4

本发明的实施例还提供了一种可读存储介质,所述可读存储介质上存储程序或指令,所述程序或指令被处理器执行时实现如上所述的购药订单处理方法的步骤。

可选地,在本实施例中,可读存储介质被设置为存储用于执行以下步骤的程序代码:

S1,根据购药用户的购药订单的订单信息,判断所述购药订单是否为代买订单;

S2,若所述购药订单为代买订单,根据所述购药订单的订单信息以及用药人信息确定至少一个推荐用药人,其中,所述用药人信息位于所述购药用户的账户信息中;

S3,若所述购药订单不是代买订单,则根据所述购药清单为所述购药订单开具处方单。

可选地,可读存储介质还被设置为存储用于执行上述实施例1中的方法中所包括的步骤的程序代码,本实施例中对此不再赘述。

可选地,在本实施例中,上述可读存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地,本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例,本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号