一种就医任务管理方法、服务器及存储介质与流程

本申请涉及数据处理技术领域，尤其涉及一种就医任务管理方法、服务器及存储介质。

背景技术：

随着现代医学科技的快速发展，解决了许多类疾病的治疗问题。就目前的医疗体系，患者若需就医，需要亲自去医院或医疗机构，有医生对患者进行问诊、临床症状检查等，作出诊断结果，而随着电子信息技术的发展，医疗信息技术也得到了相应的发展。一些大型、先进的医院或医疗机构中，已采取电子化病历，以及网上预约挂号，但目前用户一般仅能根据医生的值班表和简介选择挂号就诊，并且就医过程依旧较为繁琐。

技术实现要素：

本申请实施例提供一种就医任务管理方法、服务器及计算机可读存储介质，可以实现更准确高效的预约挂号服务，使就医过程一体化，更加方便。

第一方面，本申请实施例提供了一种就医任务管理方法，该方法包括：

接收来自用户终端的就诊请求，所述就诊请求包括用户标签和病情描述内容；

根据所述用户标签确定目标用户，根据所述病情描述内容确定推荐医生类别；

获取所述目标用户的历史诊断记录，判断所述历史诊断记录中的历史医生是否属于所述推荐医生类别；

若所述历史医生属于所述推荐医生类别，将所述历史医生确定为目标推荐医生；

若所述历史医生不属于所述推荐医生类别，根据分析规则分析所述历史诊断记录和所述病情描述内容以确定诊断标签，根据所述诊断标签与推荐医生的对应关系，从所述推荐医生类别的医生中确定所述诊断标签对应的推荐医生为所述目标推荐医生；

生成包含所述目标推荐医生的推荐信息，向所述用户终端发送所述推荐信息；

在接收到来自所述用户终端的对所述目标推荐医生的预约请求时，获取所述目标推荐医生的可预约时间表，向所述用户终端发送所述可预约时间表；

接收来自所述用户终端的预约信息，若所述预约信息中的预约时刻为所述可预约时间表中的空闲时间，生成预约成功信息。

作为一种可能的实施方式，所述历史诊断记录包括所述目标用户的电子病历和/或电子处方；

所述生成预约成功信息之后，所述方法还包括：

获取所述目标推荐医生的用户账号，向所述用户账号发送所述电子病历和/或所述电子处方。

作为一种可能的实施方式，所述根据所述病情描述内容确定推荐医生类别包括：

根据所述病情描述内容中的病情关键字确定就诊科别，确定属于所述就诊科别的医生为所述推荐医生类别。

作为一种可能的实施方式，所述生成预约信息之后，所述方法还包括：

获取所述目标用户的诊断数据，识别所述诊断数据中的目标字段以确定诊断任务，生成所述诊断任务的任务信息，所述任务信息包括所述诊断任务的工作人员基本信息；

向所述用户终端发送所述任务信息。

作为一种可能的实施方式，所述就诊请求包括对指定医生的预约请求，所述方法还包括：

判断所述指定医生是否属于所述推荐医生类别；

若属于，确定所述指定医生与所述病情描述内容匹配，执行获取所述指定医生的可预约时间表的步骤；若不属于，确定所述指定医生与所述病情描述内容不匹配，执行所述根据分析规则分析所述历史诊断记录和所述病情描述内容以确定诊断标签的步骤。

第二方面，本申请实施例提供了一种服务器，包括：传输模块、确定模块、判断模块、推荐模块和预约模块，其中：

所述传输模块，用于接收来自用户终端的就诊请求，所述就诊请求包括用户标签和病情描述内容；

所述确定模块，用于根据所述用户标签确定目标用户，根据所述病情描述内容确定推荐医生类别；

所述判断模块，用于获取所述目标用户的历史诊断记录，判断所述历史诊断记录中的历史医生是否属于所述推荐医生类别；

所述推荐模块，用于：

若所述历史医生属于所述推荐医生类别，将所述历史医生确定为目标推荐医生；若所述历史医生不属于所述推荐医生类别，根据分析规则分析所述历史诊断记录和所述病情描述内容以确定诊断标签，根据所述诊断标签与推荐医生的对应关系，从所述推荐医生类别的医生中确定所述诊断标签对应的推荐医生为所述目标推荐医生；

所述传输模块，还用于生成包含所述目标推荐医生的推荐信息，向所述用户终端发送所述推荐信息；在接收到来自所述用户终端的对所述目标推荐医生的预约请求时，获取所述目标推荐医生的可预约时间表，向所述用户终端发送所述可预约时间表；

所述预约模块，用于接收来自所述用户终端的预约信息，若所述预约信息中的预约时刻为所述可预约时间表中的空闲时间，生成预约成功信息。

在一种可能的实现方式中，所述确定模块，具体用于根据所述病情描述内容中的病情关键字确定就诊科别，确定属于所述就诊科别的医生为所述推荐医生类别。

在一种可能的实现方式中，所述服务器还包括：

任务模块，用于获取所述目标用户的诊断数据，识别所述诊断数据中的目标字段以确定诊断任务，生成所述诊断任务的任务信息，所述任务信息包括所述诊断任务的工作人员基本信息；

所述传输模块还用于，向所述用户终端发送所述任务信息。

第三方面，本申请实施例还提供了一种服务器，包括：处理器、输入设备、输出设备和存储器，所述处理器、输入设备、输出设备和存储器相互连接，其中，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如第一方面及其任一种可能的实施方式所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行上述第一方面及其任一种可能的实施方式的方法。

本申请实施例通过接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容，根据上述用户标签确定目标用户，根据上述病情描述内容确定推荐医生类别，再获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，若属于，将上述历史医生确定为目标推荐医生，若不属于，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，再根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生，然后生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息，在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表，再接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息，可以实现更准确高效的预约挂号服务，使就医过程一体化，更加方便。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种就医任务管理方法的流程示意图；

图2是本申请另一实施例提供的一种就医任务管理方法的流程示意图；

图3是本申请实施例提供的一种服务器的结构示意图；

图4是本申请实施例提供的另一种服务器的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

为了能够更好地理解本申请实施例，下面将对应用本申请实施例的方法进行介绍。

本申请实施例中提到的用户终端是可以与服务器进行通信的设备，上述服务器也称伺服器，是提供计算服务的设备，可以允许多个用户终端进行访问。上述用户终端可以为移动终端，包括各种具有无线通信功能的手持设备、可穿戴设备、计算设备或连接到无线调制解调器的其他处理设备，以及各种形式的用户设备(userequipment，ue)，移动台(mobilestation，ms)等等。

终端用户可以在任意具有远程桌面连接的用户终端连接服务器(终端服务器)。如：当终端用户连接到微软终端服务器，服务器将会分配一个独立的会话给用户，提供桌面环境或者单独应用程序环境给终端用户使用。用户的用户终端(客户端)，比如计算机不处理所运行的应用的程序，只是将键盘和鼠标的点击讯号传送给服务器，所有的处理运算将由服务器完成。

请参见图1，是本申请实施例提供的一种就医任务管理方法的示意流程图，本方法可以应用于服务器，如图1所示该方法可包括：

101、接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容。

其中，上述用户终端包括但不限于诸如具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的移动电话、膝上型计算机或平板计算机之类的其它便携式设备。还应当理解的是，在某些实施例中，所述设备并非便携式通信设备，而是具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的台式计算机。

本申请实施例中，上述就诊请求可以为用户通过用户终端发送的请求，该就诊请求包括用户标签和病情描述内容。

具体地，上述用户标签可理解为代表用户的身份信息。举例来说，上述用户标签可为身份证号、姓名、性别、电话号码和/或银行卡号等信息的一项或多项的组合。可理解，上述用户标签的具体内容是什么，本申请实施例不作限定。

具体地，上述病情描述内容可理解为用户对自身病情具体情况的描述。具体地，上述病情描述内容可以为性别、年龄、病症、病史、病症描述、饮食情况和用药记录等和病情相关的内容。举例来说，上述病情描述内容可以为“男或女，71岁，糖尿病大概6/7年，血糖量在控制范围内，平常注意饮食，人越来越瘦，每天服用盐酸二甲双胍肠溶片和格列美脲片”等具体的描述。或者，可理解，对于上述病情描述内容的具体描述方式，本申请实施例不作限定。

102、根据上述用户标签确定目标用户，根据上述病情描述内容确定推荐医生类别。

本申请实施例中，上述服务器可以根据上述就诊请求所携带的上述用户标签信息确定目标用户。其中，该目标用户指的是申请上述就诊请求的拥有者，可以理解为上传上述就诊请求的用户，上述服务器可以根据上述用户标签信息查询上述服务器中是否存在该用户，若存在该用户，则确定该用户为上述目标用户；若不存在该用户，则上述服务器需要存储该用户的用户标签信息。可理解，本申请实施例中，对于如何确定上述目标用户的具体实现方式不作限定。

本申请实施例中，上述服务器可以根据上述就诊请求所携带的上述病情描述内容确定推荐医生类别。其中，上述推荐医生类别可以为不同诊疗科别的医生，可理解为外科、眼科、耳鼻咽喉科、内科、神经内科、整形外科或小儿科等不同科别的医生。具体地，上述服务器可根据不同的诊疗科别建立不同的病情数据库，当上述服务器在收到上述病情描述内容时，通过查找上述病情数据库能够找到与上述病情描述内容相匹配的诊疗科别医生，则该诊疗科别医生即为上述推荐医生类别。实施本申请实施，上述服务器可初步为用户确定推荐医生类别，提高就诊的预约效率。可理解，对于上述服务器确定推荐医生类别的具体实现方式本申请实施例不作具体限定。

103、获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别。

本申请实施例中，上述服务器可获取上述目标用户的历史诊断记录。其中，上述历史诊断记录可以包括上述目标用户的电子病历和/或电子处方。具体的，电子病历是用电子设备(计算机、健康卡等)保存、管理、传输和重现的数字化的病人的医疗记录；上述电子处方(electronicprescription)是指依托网络传输，采用信息技术编程，在诊疗活动中填写药物治疗信息，开具处方，可以通过网络传输至药房，经药学专业技术人员审核、调配、核对、计费，并作为药房发药和医疗用药的医疗电子文书。

具体地，上述电子病历和/或电子处方可通过用户共享至上述用户终端；或者，在通过身份认证和或用户授权之后，与上述用户终端网络连接的其他医疗界构或医疗服务机构的用户终端可自动获取用户的上述电子病历和/或电子处方，然后上述服务器可通过上述用户终端获取用户的上述电子病历和/或电子处方。可理解，本申请实施例对于服务器获取电子病历和/或电子处方的具体实现方式不作限定。

上述历史诊断记录中可以包括目标用户就诊的历史医生信息，因此可以获得上述历史医生信息，确定目标用户的历史医生，判断上述历史医生是否属于上述推荐医生类别。具体的，可以识别该历史医生的姓名或者医生标识(或者医生编号等)，确定该医生所属类别，再判断是否为上述推荐医生类别，也可以获取上述推荐医生类别的医生名单，在其中查找是否存在该历史医生，从而判断其是否属于上述推荐医生类别。

若上述历史医生属于上述推荐医生类别，可以执行步骤104，若若上述历史医生不属于上述推荐医生类别，不执行步骤104，可以执行步骤105。

104、将上述历史医生确定为目标推荐医生。

若上述历史医生属于上述推荐医生类别，即代表本次目标用户的就诊需求与历史就诊需求是类似的，可能因为同一方面的疾病需要就医，可以执行步骤106，向用户推荐曾经会诊过的医生进行本次治疗，普遍情况下曾经会诊过的医生更了解病人的病情，能够提供更好的治疗效果，因此可以将上述历史医生确定为目标推荐医生为用户推荐，使用户可以优先选择给自己看过病的医生就诊。

105、根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生。

本申请实施例中，上述服务器可以存储有上述分析规则，用于对上述历史诊断记录和上述病情描述内容进行分析，具体地，若上述目标用户有上述历史诊断记录，则上述服务器可根据更加专业的电子病历和/或电子处方进一步判断上述目标用户的病情，服务器中可以存储有关键词库，可以通过对上述历史诊断记录和上述病情描述内容的关键词识别来确定诊断标签，上述分析规则可以包括关键词及其组合与诊断标签的映射关系，服务器可以获取上述历史诊断记录和上述病情描述内容中的目标关键词，具体可以为查找上述历史诊断记录和上述病情描述内容中有哪些关键词库中的关键词，再根据关键词及其组合与诊断标签的映射关系，确定目标关键词对应的诊断标签。

上述诊断标签可以为诊断编码的形式，可以用于体现目标用户的病情分类，也可以用于进一步确定目标推荐医生。在服务器中可以存储诊断标签与推荐医生的对应关系，一个诊断标签可以对应一个或者多个推荐医生，一个推荐医生也可以对应一个或者多个诊断标签。在确定上述诊断标签之后，可以根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生。可以理解为，在确定推荐医生类别之后，可以通过诊断标签的形式进一步分析，从推荐医生类别中确定至少一个目标推荐医生。其中，该目标推荐医生可以理解为与上述目标用户所描述病情相关程度最高的专业医生。举例来说，上述历史诊断记录为肿瘤科病人，可以通过详细的病人资料、历史就诊记录等，可以向病人优先推荐级别更高的医生，比如挑选的医生均为副主任医生级别以上，使病人与就诊医生的匹配度更高。

106、生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息。

本申请实施例中，在确定目标推荐医生之后，上述服务器可生成包含上述目标推荐医生的推荐信息，并向上述用户终端发送上述推荐信息。其中，上述推荐信息可以包含该目标推荐医生的姓名、性别、年龄、联系方式、科室、职称、行医年限、主治和/或研究领域等信息。实施本申请实施例，上述服务器可将上述推荐信息发送至上述用户终端，使用户可以通过上述推荐信息了解到上述目标推荐医生的相关信息，并且可以通过上述推荐信息提供的联系方式主动联系并咨询上述目标推荐医生，不仅提高了用户预约挂号的用户体验，而且使用户能够更加了解上述目标推荐医生的相关信息。可理解，本申请实施例中对于推荐信息的具体内容不作限定。

107、在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表。

本申请实施例中，可理解，用户若接受上述推荐信息所推荐的目标推荐医生之后，上述用户终端会生成对上述目标推荐医生的预约请求指令；若用户不接受上述推荐信息所推荐的目标推荐医生，则上述服务器会重新向上述用户终端发送新的目标推荐医生，直到用户接受上述服务器发送的新的目标推荐医生，则生成对该新的目标推荐医生的预约请求指令。实施本申请实施例，用户可自主选择目标推荐医生，提高用户在预约挂号过程中的满意度。

本申请实施例中，上述服务器在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，会获取上述目标推荐医生的可预约时间表，并向上述用户终端发送上述可预约时间表。其中，上述可预约时间表可以为上述目标推荐医生近一个月每天的工作时间安排表。举例来说，上述可预约时间表可以包含“王医生，上午9:00-11:00，2018.8.24，空闲”等信息。实施本申请实施例，用户可清楚地了解所推荐的目标推荐医生的工作时间安排表，使用户合理地安排预约时间，提高预约挂号服务的效率。可理解，本申请实施例中对于可预约时间表的具体内容和表示方式不作限定。

108、接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息。

本申请实施例中，上述服务器可接受来自用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，预约成功，生成预约成功信息。其中，上述预约信息为用户根据上述可预约时间表进行选择而生成的预约信息；上述预约成功信息可以为文字、图片、语音或视频等中的一项或多项进行组合而形成的信息，可选的，预约成功之后可以获取用户的联系方式，向用户发送预约成功信息，比如获取手机号发送短信，告知预约成功，提示就诊时间和注意事项等。实施本申请实施例，上述服务器可及时通知用户预约挂号是否预约成功，可避免用户不必要的等待时间。可理解，本申请实施例中对于预约信息和预约成功信息的具体内容不作限定。

本申请实施例中，在接收到用户针对上述目标推荐医生的预约请求时，上述方法还可以包括：向上述目标推荐医生发送用户的预约情况信息，上述预约情况信息包括用户的病情描述内容和历史诊断记录。若医生查看上述预约情况信息后，接受本次预约，则预约成功，医生可以不接受本次预约，需要向用户说明原因，并且可以向用户推荐其他合适的医生。当用户没有提交病情描述而是直接想要预约某位医生时，也可以将用户与医生进行匹配，向用户显示匹配程度，供用户选择是否需要预约该医生，同时可以向用户推荐同类型或者更优的医生进行会诊。实施本申请实施例，用户和医生可自由选择是否建立预约任务，使得预约挂号服务更加人性化。

本申请实施例通过接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容，根据用户标签确定目标用户，以及根据病情描述内容确定推荐医生类别，获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，若属于，将上述历史医生确定为目标推荐医生，若不属于，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，再根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生，然后，生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息，以及可以在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表，接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息，可以实现更准确高效的预约挂号服务，使就医过程一体化。

参见图2，是本申请实施例提供的另一种就医任务管理方法的示意流程图，图2所示的实施例可以是在图1所示的实施例的基础上得到的，如图2所示该方法可包括：

201、接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容。

上述步骤201可以参考图1所示的实施例步骤101中的具体描述，此处不再赘述。

202、根据上述用户标签确定目标用户，根据上述病情描述内容中的病情关键字确定就诊科别，确定属于上述就诊科别的医生为推荐医生类别。

上述目标用户的确定可参考图1所示的实施例中步骤102中的具体描述，此处不再赘述。

本申请实施例中，上述服务器可提取上述病情描述内容中的病情关键字，并根据上述病情关键字确定就诊科别，最终确定属于上述就诊科别的医生为推荐医生类别。服务器中可以预先设置有关键字数据库，以及关键字及其组合方式与就诊科别的对应关系，在获得上述病情关键字之后，可以根据上述关键字及其组合方式与就诊科别的对应关系，确定上述病情关键字对应的就诊科别，以为用户选择该就诊科别的医生进行推荐。上述就诊科别的确定也可以通过人工智能算法匹配实现。实施本申请实施例，上述服务器可根据上述病情关键字初步确定用户的病情，选定医生类别，再进行之后的推荐预约，使得预约挂号服务更加准确。

203、获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，上述历史诊断记录包括上述目标用户的电子病历和/或电子处方。

上述步骤203可以参考图1所示的实施例步骤103中的具体描述，此处不再赘述。若上述历史医生属于上述推荐医生类别，可以执行步骤204，若若上述历史医生不属于上述推荐医生类别，不执行步骤204，可以执行步骤205。

204、将上述历史医生确定为目标推荐医生。

205、根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生。

206、生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息。

上述步骤204-步骤206可以分别参考图1所示的实施例步骤104-步骤106中的具体描述，此处不再赘述。

在一种可选的实施方式中，上述就诊请求可以包括对指定医生的预约请求，即服务器可以从就诊请求中获得用户想要预约的指定医生信息，服务器可以执行以下步骤：

判断上述指定医生是否属于上述推荐医生类别；

若属于，确定上述指定医生与所述病情描述内容匹配，可以执行获取上述指定医生的可预约时间表的步骤；若不属于，确定上述指定医生与上述病情描述内容不匹配，可以执行上述根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签的步骤。

上述指定医生属于上述推荐医生类别时，代表用户自己指定的预约医生是与其本次就诊病情符合的，即可以确定上述指定医生与上述病情描述内容匹配，可以进行预约处理；上述指定医生不属于上述推荐医生类别时，代表用户自己指定的预约医生是与其本次就诊病情不符合的，即可以确定上述指定医生与上述病情描述内容不匹配，可以不为用户进行预约处理，而是可以执行步骤205，为用户重新推荐与自身病情更匹配的医生进行治疗，使病人能够接受准确的治疗。

207、在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表。

208、接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，预约成功，生成预约成功信息。

上述步骤207和步骤208可以分别参考图1所示的实施例步骤107和步骤108中的具体描述，此处不再赘述。

209、获取上述目标推荐医生的用户账号，向上述用户账号发送上述电子病历和/或上述电子处方。

本申请实施例中，上述用户账号可以理解为终端设备应用程序中注册的账号，上述服务器可获取上述目标推荐医生的用户账号，向登录上述用户账号的终端设备发送上述历史诊断记录。可理解，上述获取上述目标推荐医生的用户账号可以通过上述目标推荐医生的授权认证和或身份验证。在预约成功之后，可以提供目标用户的历史电子病历和/或电子处方给预约的医生，让医生可以及时了解病人病情，提高治疗效果。

210、获取上述目标用户的诊断数据，识别上述诊断数据中的目标字段以确定诊断任务，生成上述诊断任务的任务信息，上述任务信息包括上述诊断任务的工作人员基本信息。

具体的，服务器可以获取上述目标用户的诊断数据，对用户的就诊数据进行综合分析以确定诊断任务，进而判断用户的就诊进度(体现为上述诊断任务)。上述就诊进度可以理解为在整个就诊周期中的节点或者子周期，上述诊断任务即为当前就诊进度中进行的任务。服务器可以识别上述诊断数据中的目标字段，来确定上述诊断任务。

上述诊断数据可以理解为用户看病就医时产生的信息或数据，可以包括用户的电子病历和/或电子处方，具体可以为诊断结果(如电子病历或报告中记载的)，还可以是来自用户或者医生的病情描述。比如用户需要进行就诊，在还未就诊的情况下，可以输入本人的病情描述，或者提供本人历史就诊信息如历史电子病历，服务器也可以自动获取用户的电子病历等资料(可以需要通过身份认证)。

本申请实施例中服务器可以存储有目标字段和诊断任务的对应关系，可以通过识别诊断数据中的目标字段，根据上述目标字段和诊断任务的对应关系确定当前的诊断任务。具体的，也可以先通过目标字段确定就诊进度，再进一步确定上述诊断任务。上述就诊进度可以包含至少一个诊断任务，在服务器中可以预先存储有不同就诊进度对应的诊断任务，以及就诊进度和诊断任务的对应关系，服务器在确定了就诊进度之后可以确定对应的诊断任务，上述诊断任务包括该就诊进度中的各种事项，比如a类疾病对应的诊断任务可以包括初诊挂号预约、初诊后的检查项目预约，复诊前报告查询等，又如癌症患者的每个化疗阶段对应的治疗项目。上述就诊进度和诊断任务可以以表格的形式存储在系统中，以及可以由工作人员修改、增删(需要获得权限或者进行审核，通过才能修改)。

可选的，可以由用户通过手动操作确定上述就诊进度和/或选择诊断任务，即服务器可以建立用户的就医管理任务，用户可以自己选择当前的就诊进度，比如可以是初诊、复诊、待手术、术后修复等阶段，其中用户可以通过上述用户终端远程选择，待服务器确认之后，可以获取用户选定的就诊进度对应的诊断任务。

需要注意的是，在确定了上述就诊进度之后，针对当前用户的就医管理任务，可以进入上述就诊进度的子任务管理阶段，即此刻重点关注于该就诊进度的诊断任务，其他进度中涉及的诊断任务可以简化显示或者忽略，比如有一些与当前就诊进度相距较远的诊断任务可以不再关注，不向用户推荐和提醒等，可以为用户提供更完善的就医任务管理服务，同时减少了当前不相关的数据处理量。

可选的，在某一个诊断任务处于执行阶段时，其他就诊进度的数据也可以在后台进行，比如提前为用户获取下一步的诊断任务，以及推荐一些相关治疗建议信息、推送有关病情的注意事项等。

具体的，服务器可以生成上述诊断任务的任务信息，上述任务信息可以理解为该诊断任务中用户需要获取的通知类信息，具体的，上述任务信息可以包括上述诊断任务的工作人员基本信息，比如b类疾病初诊的诊断任务，任务信息可以包括就诊医生、联系方式、就诊时间和科别等，住院治疗阶段的任务信息可以包括对接护士、主治医生、病床号等。在本申请实施例中，步骤210可以在步骤208之后执行，也可以在其他时间执行。

211、向上述用户终端发送上述任务信息。

在生成上述诊断任务的任务信息之后，可以向用户终端发送上述任务信息，可以为用户提供全面的就诊服务和任务信息，便于联系相关医务人员，提高就诊效率。

本申请实施例通过接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容，根据上述用户标签确定目标用户，根据上述病情描述内容中的病情关键字确定就诊科别，确定属于上述就诊科别的医生为推荐医生类别，并获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，上述历史诊断记录包括上述目标用户的电子病历和/或电子处方；若属于，将上述历史医生确定为目标推荐医生，若不属于，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，再根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生，进而生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息，在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表，接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，预约成功，可以生成预约成功信息，还可以获取上述目标推荐医生的用户账号，向上述用户账号发送上述电子病历和/或上述电子处方，以及可以获取上述目标用户的诊断数据，识别上述诊断数据中的目标字段以确定诊断任务，生成上述诊断任务的任务信息，上述任务信息包括上述诊断任务的工作人员基本信息，向上述用户终端发送上述任务信息，可以实现更准确高效的预约挂号服务，和就诊阶段的任务管理，使就医过程一体化。

请参阅图3，图3是本申请实施例公开的一种服务器的结构示意图。如图3所示，该服务器包括传输模块310、确定模块320、判断模块330、推荐模块340和预约模块350，其中：

上述传输模块310，用于接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容；

上述确定模块320，用于根据上述用户标签确定目标用户，根据上述病情描述内容确定推荐医生类别；

上述判断模块330，用于获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别；

上述推荐模块340，用于：

若上述历史医生属于上述推荐医生类别，将上述历史医生确定为目标推荐医生；若上述历史医生不属于上述推荐医生类别，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生；

上述传输模块310，还用于生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息；在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表；

上述预约模块350，用于接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息。

可选的，上述历史诊断记录包括上述目标用户的电子病历和/或电子处方；

上述传输模块310，还用于在生成预约成功信息之后，获取上述目标推荐医生的用户账号，向上述用户账号发送上述电子病历和/或上述电子处方。

可选的，上述确定模块320具体用于，根据上述病情描述内容中的病情关键字确定就诊科别，确定属于上述就诊科别的医生为上述推荐医生类别。

可选的，上述服务器还包括任务模块360，用于在生成预约信息之后，获取上述目标用户的诊断数据，识别上述诊断数据中的目标字段以确定诊断任务，生成上述诊断任务的任务信息，上述任务信息包括上述诊断任务的工作人员基本信息；

上述传输模块310还用于，向上述用户终端发送上述任务信息。

可选的，上述就诊请求包括对指定医生的预约请求，上述判断模块330还用于，判断上述指定医生是否属于上述推荐医生类别；

上述确定模块320，还用于：若上述指定医生属于上述推荐医生类别，确定上述指定医生与上述病情描述内容匹配，上述传输模块310可以执行获取上述指定医生的可预约时间表的步骤；若上述指定医生不属于上述推荐医生类别，确定上述指定医生与上述病情描述内容不匹配，上述推荐模块340可以执行上述根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签的步骤。

本申请实施例中的服务器300可以执行如图1和图2所示实施例中的部分或全部方法步骤，此处不再赘述。

本申请实施例中的服务器300，服务器300可以接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容，根据用户标签确定目标用户，以及根据病情描述内容确定推荐医生类别，获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，若属于，将上述历史医生确定为目标推荐医生，若不属于，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，再根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生，然后，生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息，以及可以在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表，接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息，可以实现更准确高效的预约挂号服务，使就医过程一体化。

请参阅图4，图4是本申请实施例公开的另一种服务器的结构示意图。如图4所示，该服务器400包括处理器401和存储器402，其中，服务器400还可以包括总线403，处理器401和存储器402可以通过总线403相互连接，总线403可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。总线403可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。其中，服务器400还可以包括输入输出设备404，输入输出设备404可以包括显示屏，例如液晶显示屏。存储器402用于存储包含指令的一个或多个程序；处理器401用于调用存储在存储器402中的指令执行上述图1和图2实施例中提到的部分或全部方法步骤。

应当理解，在本申请实施例中，所称处理器401可以是中央处理单元(centralprocessingunit，cpu)，该处理器还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

输入设备402可以包括触控板、指纹采传感器(用于采集用户的指纹信息和指纹的方向信息)、麦克风等，输出设备403可以包括显示器(lcd等)、扬声器等。

该存储器404可以包括只读存储器和随机存取存储器，并向处理器401提供指令和数据。存储器404的一部分还可以包括非易失性随机存取存储器。例如，存储器404还可以存储设备类型的信息。

通过本申请实施例的服务器400，服务器400可以接收来自用户终端的就诊请求，上述就诊请求包括用户标签和病情描述内容，根据用户标签确定目标用户，以及根据病情描述内容确定推荐医生类别，获取上述目标用户的历史诊断记录，判断上述历史诊断记录中的历史医生是否属于上述推荐医生类别，若属于，将上述历史医生确定为目标推荐医生，若不属于，根据分析规则分析上述历史诊断记录和上述病情描述内容以确定诊断标签，再根据上述诊断标签与推荐医生的对应关系，从上述推荐医生类别的医生中确定上述诊断标签对应的推荐医生为上述目标推荐医生，然后，生成包含上述目标推荐医生的推荐信息，向上述用户终端发送上述推荐信息，以及可以在接收到来自上述用户终端的对上述目标推荐医生的预约请求时，获取上述目标推荐医生的可预约时间表，向上述用户终端发送上述可预约时间表，接收来自上述用户终端的预约信息，若上述预约信息中的预约时刻为上述可预约时间表中的空闲时间，生成预约成功信息，可以实现更准确高效的预约挂号服务，使就医过程一体化。

本申请实施例还提供一种计算机可读存储介质，其中，该计算机可读存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任何一种就医任务管理方法的部分或全部步骤。

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

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

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

所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储器包括：u盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。