接诊方法与流程

1.本说明书涉及线上问诊技术领域，尤其涉及一种接诊方法。


背景技术：

2.现有的线上问诊，一般是线上问诊平台接收问诊请求，并基于该问诊请求匹配医生，以在用户与匹配到的医生所对应的终端设备之间建立通信连接，实现线上问诊。
3.但受用户问诊请求中的描述信息不够清晰或平台的分诊匹配算法不够完善等因素的影响，可能会存在匹配到的医生与用户的问诊需求不相符的情况，从而导致用户和匹配到的医生较难顺畅的完成线上沟通，进而导致用户较难实现相应的问诊需求，给用户及医生带来不好的线上问诊体验感，同时也可能导致退款订单量增加。


技术实现要素：

4.本说明书实施方式提供一种接诊方法，可以使得执行线上问诊沟通的问诊医生更符合用户的问诊需求，进而提高用户及医生的使用体验感。
5.本说明书实施方式提供一种接诊方法，应用于医生客户端，包括：接收接诊提示信息；其中，所述接诊提示信息至少包括针对用户客户端发起的问诊请求的辅助诊断信息；在接诊提示界面展示所述接诊提示信息；其中，所述接诊提示界面还包括同意接诊控件及拒绝接诊控件，以基于对所述同意接诊控件或拒绝接诊控件的触发操作确定是否对所述问诊请求进行接诊。
6.本说明书实施方式提供一种医生客户端，包括：信息接收模块，用于接收接诊提示信息；其中，所述接诊提示信息至少包括针对用户客户端发起的问诊请求的辅助诊断信息；信息发送模块，用于在接诊提示界面展示所述接诊提示信息；其中，所述接诊提示界面还包括同意接诊控件及拒绝接诊控件，以基于对所述同意接诊控件或拒绝接诊控件的触发操作确定是否对所述问诊请求进行接诊。
7.本说明书实施方式提供一种接诊方法，应用于服务器，包括：接收用户客户端发送的问诊请求；在确定所述问诊请求对应的问诊医生后，向所述问诊医生的医生客户端发送接诊提示信息，以使所述医生客户端展示所述接诊提示信息；其中，所述接诊提示信息至少包括针对所述问诊请求的辅助诊断信息。
8.本说明书实施方式提供一种服务器，包括：信息接收模块，用于接收用户客户端发送的问诊请求；信息展示模块，用于在确定所述问诊请求对应的问诊医生后，向所述问诊医生的医生客户端发送接诊提示信息，以使所述医生客户端展示所述接诊提示信息；其中，所述接诊提示信息至少包括针对所述问诊请求的辅助诊断信息。
9.本说明书实施方式，服务器在接收到问诊请求后，可以进一步确定针对问诊请求的辅助诊断信息，并将该辅助诊断信息作为问诊请求的接诊提示信息之一，先向所确定的问诊医生发送接诊提示。问诊医生可以基于该接诊提示信息中的辅助诊断信息初步判断其是否能够完成相应问诊请求的诊断。如可以完成针对，则进入问诊环节；如不能完成诊断，
则可以拒绝接诊。通过上述方式，可以使得问诊医生更加快速准确的确定其是否能够完成问诊请求，在可以完成的情况下，再进行相应的问诊环节，进而提高用户及医生在问诊沟通过程中顺畅度，提高用户及医生的使用体验感。
附图说明
10.所包括的附图用来提供对本说明书实施方式的进一步的理解，其构成了说明书的一部分，用于例示本说明书的实施方式，并与文字描述一起来阐释本说明书的原理。显而易见地，下面描述中的附图仅仅是本说明书的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。在附图中：
11.图1为本说明书实施方式提供的一个接诊方法的场景交互示意图；
12.图2为本说明书实施方式提供的医生客户端的显示界面示意图；
13.图3为本说明书实施方式提供的一个接诊方法的流程示意图；
14.图4为本说明书实施方式提供的医生客户端的显示界面示意图；
15.图5为本说明书实施方式提供的医生客户端的显示界面示意图；
16.图6为本说明书实施方式提供的用户客户端的显示界面示意图；
17.图7为本说明书实施方式提供的医生客户端的显示界面示意图；
18.图8为本说明书实施方式提供的服务器的结构示意图；
19.图9为本说明书实施方式提供的一个接诊方法的流程示意图。
具体实施方式
20.为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施方式中的附图，对本说明书实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式仅仅是本说明书一部分实施方式，而不是全部的实施方式。基于本说明书中的实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施方式，都应当属于本说明书保护的范围。
21.如图1所示，在一个场景示例中，用户可以通过用户客户端访问线上问诊网站。所述线上问诊网站的问诊服务可以由问诊平台提供。所述问诊平台可以包括一个或者多个服务器及数据库。所述服务器中可以配置有问诊数据处理程序，用于执行与问诊相关的数据处理。所述数据库中至少可以存储有辅助问诊医生确定的信息以及辅助诊断结果生成的信息。用户客户端或医生客户端如可以为手机、电脑等智能终端设备。
22.例如，用户可以在用户客户端所展示的线上问诊发起界面，输入“眼睛红起来一大片，是怎么回事，好像里面流血一样，有点痛，怎么办”的用户主诉信息及用户基础信息，所述用户基础信息如可以包括性别、年龄等。然后，用户还可以触发线上问诊发起界面上的问诊发起控件。用户客户端可以基于该触发操作，生成问诊请求。相应的，所述问诊请求可以包括用户输入的用户主诉信息、用户基础信息等。用户客户端可以将所述问诊请求发送至问诊平台的服务器。
23.服务器在接收到问诊请求后，可以确定所述问诊请求所对应的问诊医生。但受用户主诉信息中的疾病描述不够清晰或平台的分诊匹配算法不够完善等因素的影响，可能会存在匹配到的医生与用户的问诊需求不相符的情况，从而导致用户和匹配到的医生较难顺
畅的完成线上沟通，进而导致用户较难实现相应的问诊需求，给用户及医生带来不好的线上问诊体验感。
24.相应的，本场景示例中，服务器在接收到问诊请求后，还可以生成所述问诊请求所对应的辅助诊断信息。例如，服务器可以利用预先配置的辅助诊断算法对问诊请求中的用户主诉信息“眼睛红起来一大片，是怎么回事，好像里面流血一样，有点痛，怎么办”进行处理，以生成该问诊请求对应的疾病诊断结果“92％结膜炎，8％青光眼”，可以将该疾病诊断结果作为辅助诊断信息。
25.服务器在确定所述问诊请求所对应的问诊医生a后，可以将所述问诊请求以及对应的辅助诊断信息作为接诊提示信息之一，发送至所述问诊医生a的医生客户端。医生客户端如可以展示接诊提示界面。相应的，可以在所述接诊提示界面展示所述问诊请求对应的辅助诊断信息；当然，还可以展示所述问诊请求中的用户主诉信息、用户基础信息等。如图2所示，医生客户端可以在接诊提示界面中展示用户的性别、年龄、用户主诉信息以及辅助诊断信息。
26.辅助诊断信息包括了服务器基于预设算法初步对问诊请求的疾病诊断结果，将辅助诊断信息作为接诊提示信息之一，向医生客户端发送接诊提示，可以辅助医生快速准确的确定其能否完成该问诊请求的诊断。问诊医生可以基于该接诊提示信息中的辅助诊断信息初步判断其是否能够完成相应问诊请求的诊断。如可以完成诊断，则进入问诊环节，如不能完成诊断，则可以拒绝接诊，从而可以进一步提高进入问诊沟通环节的用户及医生的沟通顺畅度，进而提高用户及医生的使用体验感。
27.例如，所述接诊提示界面还可以包括表达同意接诊的控件及表达拒绝接诊的控件。如图2所示，所述接诊提示界面可以包括“去接诊”按钮及“拒绝接诊”按钮。若问诊医生确定其可以完成该问诊请求的诊断，则可以触发“去接诊”按钮。医生客户端可以基于该触发将问诊医生同意接诊的指令反馈至服务器。服务器在接收到该反馈的指令后，可以在用户客户端与该问诊医生的医生客户端之间建立数据通信，构建会话窗口，以使用户与问诊医生进行在线交互。用户客户端、医生客户端与服务器之间可以基于网络通信协议进行数据通信。网络通信协议如可以包括但不限于http或tcp/ip等。
28.若问诊医生a基于上述信息确认不能完成该问诊请求的诊断。如出现该问诊请求不属于问诊医生所在的科室、该问诊请求不是问诊医生所擅长的专业领域、或问诊医生当前暂时没时间接诊等情况，导致问诊医生a不能完成该问诊请求的诊断，问诊医生a可以拒绝接诊。如图2所示，问诊医生a可以触发“拒绝接诊”按钮。医生客户端可以基于该触发将问诊医生a拒绝接诊的指令反馈至服务器。服务器在接收到该反馈的指令后，可以重新确定针对该问诊请求的问诊医生。在问诊医生a触发“拒绝接诊”按钮后，医生客户端还可以采集问诊医生a的拒绝理由、科室推荐信息、医生推荐信息等，并发至服务器。服务器还可以基于医生客户端采集的上述信息重新确定问诊医生。
29.如图1所示，假设重新确定的问诊医生为问诊医生b，则服务器还可以将问诊请求对应的辅助诊断信息作为接诊提示信息之一，发送至问诊医生b的医生客户端。问诊医生b的医生客户端可以在诊断提示界面中展示问诊请求的辅助诊断信息，以使问诊医生b确认是否接诊。依次类推，直至问诊医生确认可以接诊，则进入在线问诊沟通环节。
30.上述场景示例，服务器可以先确定针对问诊请求的辅助诊断信息，以利用该辅助
诊断信息来辅助问诊医生快速准确地确定其能否完成相应问诊请求的诊断。如不能完成诊断，服务器可以基于相应的拒接接诊指令重新确定问诊医生，以使执行线上问诊沟通的医生更符合用户问诊需求，进而提高用户及医生的使用体验感。
31.基于上述场景示例，本说明书还提供一种接诊系统。所述系统还可以包括服务器、数据库、用户客户端以及医生客户端。所述服务器可以是指一个单独的服务器，也可以是指由多个服务器所组成的服务器集群。
32.所述服务器中可以预先配置有实现确定问诊医生、转诊处理及辅助诊断信息生成等的计算机程序指令。所述计算机程序指令如可以包括辅助诊断信息生成的程序指令、确定问诊医生的程序指令、构建会话窗口的程序指令及是否接诊提示的程序指令等等。
33.所述数据库中可以存储有辅助匹配医生的信息，如医院信息、科室信息、医生擅长领域信息等。所述数据库中还可以存储有实现辅助诊断信息生成的信息。可以将存储有实现辅助诊断信息生成的信息的数据库部分称为问诊信息库。所述问诊信息库至少可以包括药品信息库、疾病信息库、诊断库、人体基础信息库、医学词典等。数据库中的信息可以采用多种方式进行存储，如可以采用表格的方式，也可以采用知识图谱的方式等。
34.接诊系统还可以与其他平台的服务器或数据库进行关联，如与医院的挂号平台、检查检测平台、医学知识百科平台、医院信息百科平台等等，从而可以在问诊医生确定的过程中，进一步与其他平台互联互通，辅助进行医生的匹配，提高医生匹配的准确性。
35.所述用户客户端或医生客户端可以为具有一定人机交互功能和数据处理能力的电子设备。具体的，例如，用户客户端或医生客户端可以是台式电脑、笔记本电脑、平板电脑或者智能手机等。
36.所述用户客户端或医生客户端可以包括输入装置、显示器、存储器、处理器和网络通信单元等硬件模块。输入装置如可以是键盘、鼠标、手写板或者录音装置等。当然，在一些情况下，显示器可以具有触摸感应功能，此时，所述输入装置可以是通过显示器展示的虚拟键盘和触摸感应功能实现。客户端可以通过处理器运行有操作系统，通过操作系统支撑上述硬件调用以及功能实现。所述网络通信单元可以遵循网络通信协议的集成模块。可以实现网络数据的双向通信。所述显示器可以是lcd显示器、crt显示器或者led显示器等。所述输入装置可以用于接收用户或医生输入的信息。所述网络通信单元可以用于向服务器发送用户或医生输入的信息。所述显示器可以用于展示用户或医生输入的信息以及服务器反馈的需要向用户或医生展示的信息。
37.例如，用户客户端中可以安装有浏览器。用户可以通过用户客户端的浏览器访问线上问诊网站，以实现在线问诊。或者，用户客户端中可以安装有问诊应用程序。用户也可以通过安装在用户客户端线上的问诊应用程序进行在线问诊。或者用户也可以通过集成在其他应用程序中的小程序进行在线问诊。当然也可以采用其他的方式实现线上问诊。当然，医生客户端也可以安装有浏览器、问诊应用程序或者集成在其他应用程序中的小程序。医生也可以通过访问线上问诊网站、或问诊应用程序、集成在其他应用程序中的小程序进行在线问诊。
38.所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
39.图3表示本说明书实施例提供的一种接诊方法的流程示意图。如图3所示，本说明
书实施例还提供一种接诊方法，应用于所述服务器，所述方法可以包括如下步骤。
40.s20：接收用户客户端发送的问诊请求。
41.用户可以通过用户客户端访问线上问诊网站、问诊应用程序或者集成在其他应用程序中的小程序等进行在线问诊。
42.以问诊应用程序为例，用户可以先在用户客户端的问诊应用程序中发起问诊请求。用户客户端如可以向用户展示问诊请求发起界面。用户可以在该问诊请求发起界面输入信息。用户如可以通过文本、语音等方式输入信息。
43.例如，用户可以在该问诊请求发起界面输入用户主诉信息。所述用户主诉信息至少可以包括用户当前需要咨询的疾病描述信息，如“加班8小时后，站立起来，突然恶心，胸闷眩晕，心脏难受，是怎么回事”、“眼睛红起来一大片，是怎么回事，好像里面流血一样，有点痛，怎么办”等。或者，用户还可以在该问诊请求发起界面输入用户基础信息、历史疾病信息、线下检查检测结果等中的一种或多种。所述历史疾病信息如可以包括用户的现病/既往病史等。
44.用户在输入信息后，可以触发问诊请求发起界面上的问诊发起控件。用户客户端可以根据用户的触发生成问诊请求。相应的，所述问诊请求至少可以包括用户输入的上述信息。当然，所述问诊请求还可以包括其他信息，如用户客户端的标识信息等。用户客户端可以将所述问诊请求发送至服务器。
45.当然，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
46.s22：在确定所述问诊请求对应的问诊医生后，向所述问诊医生的医生客户端发送接诊提示信息，以使所述医生客户端展示所述接诊提示信息；其中，所述接诊提示信息至少包括针对所述问诊请求的辅助诊断信息。
47.服务器可以在接收到问诊请求后，可以生成针对该问诊请求的辅助诊断信息。所述辅助诊断信息可以为对所述问诊请求中的用户主诉信息进行的预诊断，以辅助问诊医生高效准确的确定其是否能完成对该问诊请求的诊断。所述辅助诊断信息至少可以包括疾病诊断结果、疾病诊断结果生成的依据信息、疾病诊断分析信息等等。其中，疾病诊断结果如可以为“低血压”、“青光眼”、“结膜炎”等。疾病诊断结果生成的依据信息如可以包括生成该疾病诊断结果所依据的主诉信息、历史疾病信息、用户基础信息等。疾病诊断分析信息如可以包括疾病诊断结果生成过程中所提取的较为详细的疾病分析信息等。
48.服务器可以仅基于问诊请求中的用户主诉信息进行辅助诊断信息的生成。服务器如可以提取用户主诉信息中的症状、疾病、检测检验等信息，作为问诊描述信息。服务器可以基于问诊信息库，利用辅助诊断算法生成相应的问诊描述信息所对应的辅助诊断信息，作为问诊请求对应的辅助诊断信息。通过仅基于主诉信息所提取的信息进行相应辅助诊断信息的生成，可以避免其他信息对本次问诊请求所对应的辅助诊断信息生成的干扰，使得生成的辅助诊断信息更具有针对性。
49.如可以连接症状-诊断-疾病-检查检验-用药-手术治疗方案等，形成诊断知识图谱，可以将该诊断知识图谱存储至问诊信息库中。服务器在接收到问诊请求后，可以对该问诊请求中的用户主诉信息等进行实体提取，如可以提取症状、疾病、检查检验、用药等实体信息。信息提取的方式如可以采用文本信息检测方法、实体信息提取方法等。如待实体提取
的信息中存在非文本形式，还可以将相应的信息转化为文本形式，再进行实体提取。服务器可以基于诊断知识图谱对提取的实体信息进行医疗信息识别。所述医疗信息识别如可以包括意图识别、疾病识别、症状识别等。再基于识别到的信息生成辅助诊断信息。
50.或者，还可以预先构建诊断信息生成模型。诊断信息生成模型如可以基于神经网络、seq2seq等算法构建。如可以获取历史诊断信息，利用历史诊断信息中的用户疾病信息以及对应的医生诊断结果进行模型的信息标注，结合弱监督学习进行模型训练，得到最终的诊断信息生成模型。相应的，服务器在接收到问诊请求后，可以利用该预先构建的诊断信息生成模型访问问诊信息库中的诊断知识图谱，对该问诊请求中的用户主诉信息进行处理，以生成该问诊请求对应的辅助诊断信息。
51.当然，服务器还可以进一步结合用户基础信息以及已知疾病信息等，构建问诊请求所对应的问诊描述信息，并基于上述辅助诊断信息生成算法或者模型对该问诊描述信息进行处理，以生成问诊请求对应的辅助诊断信息。通过进一步结合用户的身份信息以及历史疾病信息等进行辅助诊断信息的生成，可以使得生成的辅助诊断信息更准确。
52.相应的，一些实施例中，所述问诊请求可以包括用户主诉信息。其中，所述用户主诉信息至少可以包括用户在发起问诊请求时所输入的疾病描述信息。相应的，所述服务器至少可以根据所述问诊请求中的用户主诉信息生成针对所述问诊请求的辅助诊断信息。
53.疾病诊断复杂多变，用户的表观症状可能是由多种因素导致的，或者可能存在多种疾病具有相似的表观症状。相应的，针对某问诊请求，服务器利用预先构建的算法或模型所生成的疾病诊断结果可能不止一个，各疾病诊断结果产生的可能性可能也存在较大的差异性。为了便于表述，可以利用疾病诊断结果的发生概率来表征相应疾病诊断结果产生的可能性大小。服务器在生成问诊请求所对应的辅助诊断信息时，可以进一步输出发生概率较大的前几个疾病诊断结果及对应的发生概率，以更加全面的准确地为医生提供诊断提示。相应的，一些实施例中，所述辅助诊断信息可以包括至少一个疾病诊断结果及相应疾病诊断结果的发生概率。
54.例如，如图2所示，第一个问诊请求对应的辅助诊断信息为“50％低血压，20％活动性心肌炎，
…”
、第二个问诊请求对应的辅助诊断信息为“92％结膜炎，8％青光眼”。其中，“低血压”、“活动性心肌炎”为第一个问诊请求对应的两个以上的疾病诊断结果，50％、20％为疾病诊断结果“低血压”、“活动性心肌炎”的发生概率。“结膜炎”、“青光眼”为第二个问诊请求对应的两个以上的疾病诊断结果，92％、8％为疾病诊断结果“结膜炎”、“青光眼”的发生概率。
55.当然，上述辅助诊断信息生成方式及包括的信息类型仅为优选举例说明，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
56.服务器在接收到问诊请求后，还可以基于预设的问诊医生匹配算法，初步匹配该问诊请求对应的问诊医生。
57.例如，服务器可以先匹配针对所述问诊请求的医生专业类别。再从匹配到的相应专业类别下的医生的擅长方向描述信息中，确定可以完成该问诊咨询的医生。所述医生专业类别如可以利用科室来表征，所述科室如可以包括眼科、耳科、脑科、神经科等一级科室类别，一级科室类别下还可以包括二级科室，二级科室下还可以包括三级科室，等等。科室
的类别及级别划分可以结合现有医院划分方式进行，也可以根据需要自行配置，这里不做限定。医生的擅长方向描述信息可以包括医生所擅长的诊断方向、经典诊断案例等等。可以将医生与科室预先进行关联，如医生目前在哪个科室下。医生与科室并不限定是一对一的关系，一个医生可以对应在几个科室下。
58.可以先对问诊请求中的用户主诉信息进行实体提取，提取出用户主诉信息中的疾病描述信息，再基于该疾病描述信息确定问诊请求对应的至少一个科室。再获取所确定的科室下的医生，将各医生的擅长方向描述信息与所述疾病描述信息进行比对，以确定符合需求的医生。或者，还可以结合患病时长、用户年龄、性别、历史患病信息等，与医生的擅长方向描述信息进行比对，以确定符合需求的医生。
59.例如，对于问诊请求中的用户主诉信息“眼睛红起来一大片，是怎么回事，好像里面流血一样，有点痛，怎么办”，可以确定其对应的一级科室为“眼科”，二级科室为“眼底病变科”、“眼角膜科”。当然，如果存在更低级别的科室(如三级科室、四级科室等)，也可以进一步选择更低级别的科室。然后，再从二级科室“眼底病变科”、“眼角膜科”所关联的医生中筛选医生。如可以进一步结合患病时长、年龄、患病严重程度、疾病紧急程度等，从上述关联的医生中筛选出符合需求的医生。
60.在医生匹配过程中，还可以基于辅助诊断信息进行医生匹配。例如，对于用户主诉信息“眼睛红起来一大片，是怎么回事，好像里面流血一样，有点痛，怎么办”，辅助诊断信息为“92％结膜炎，8％青光眼”。服务器可以结合该辅助诊断信息“92％结膜炎，8％青光眼”快速定位出科室。之后，服务器再从定位出的科室所关联的医生中，基于医生的擅长方向描述信息进一步筛选医生。基于辅助诊断信息进行医生匹配的方式，可以大幅提高医生匹配的效率及准确性。
61.如筛选出的医生为一个医生，则可以将筛选出的医生作为问诊医生。若存在多个医生，则还可以将筛选出的医生作为备选医生。如可以将备选医生的信息发送至用户客户端，以使用户客户端从备选医生中选择一个医生作为问诊医生。或者，也可以由服务器自动从备选医生中选择可以最快接单的医生作为问诊医生。
62.或者，可以预先连接疾病-医生专业类别-医生所擅长的诊断方向-医生经典案例等，形成医生-疾病知识图谱。可以提取出主诉信息中的疾病描述信息，还可以结合患病时长、用户年龄、性别、历史患病信息等，然后，基于该提取的信息访问医生-疾病知识图谱，以确定符合需求的医生。当然，还可以预先构建医生匹配模型，利用医生匹配模型访问医生-疾病知识图谱，确定符合问诊请求所对应的问诊需求的医生。医生匹配模型如可以基于神经网络、seq2seq等算法构建。
63.当然，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
64.在确定出问诊医生后，服务器可以向该问诊医生的医生客户端发送接诊提示，以提示问诊医生是否与该问诊请求所对应的用户进行问诊沟通。服务器至少可以将问诊请求对应的辅助诊断信息作为接诊提示的信息之一，发送至医生客户端。医生客户端可以展示该接诊提示信息，以使问诊医生基于接诊提示信息中的辅助诊断信息决定同意接诊还是拒绝接诊。当然，所述接诊提示信息还可以包括其他信息，如用户的性别、年龄、用户主诉信息等，通过进一步将用户的基础信息、用户主诉信息、历史疾病信息等作为接诊提示信息之
一，可以进一步提高问诊医生确认其是否能够接诊的准确性。
65.医生客户端可以展示接诊提示界面。可以在所述接诊提示界面展示问诊请求对应的接诊提示信息。如图2所示，医生客户端可以在该接诊提示界面展示用户的性别、年龄、主诉信息、辅助诊断信息等。
66.所述接诊提示界面还可以包括表达同意接诊的控件及表达拒绝接诊的控件。如图2所示，所述接诊提示界面可以包括“去接诊”按钮及“拒绝接诊”按钮。若问诊医生确定其可以完成该问诊咨询的诊断，则可以触发“去接诊”按钮。若问诊医生确认不能完成该问诊咨询的诊断，问诊医生可以触发“拒绝接诊”按钮。医生客户端可以基于该触发将问诊医生同意/拒绝接诊的指令反馈至服务器。或者，还可以在所述接诊提示界面配置表达同意/拒绝接诊的滑动动作接收控件，如某问诊请求被选中后，向右滑动表示同意接诊，向左滑动表示拒绝接诊。则医生客户端可以基于该滑动动作将问诊医生同意/拒绝接诊的指令反馈至服务器。
67.医生客户端的接诊提示界面中可以至少展示一个问诊请求对应的接诊提示信息。若接诊提示界面同时展示有两个以上的问诊请求所对应的接诊提示信息，还可以配置各问诊请求分别关联有表达同意接诊的控件及表达拒绝接诊的控件，如图2所示。问诊医生可以基于各问诊请求对应的接诊提示信息确认是否接诊，如果确认接诊，则可以触发该问诊请求所关联的同意接诊控件；若拒绝接诊，则可以触发相应的拒绝接诊控件。通过为各问诊请求关联同意接诊控件及拒绝接诊控件的方式，可以进一步提高医生操作的简便性。
68.相应的，一些实施例中，服务器可以向所述医生客户端发送接诊提示展示数据包。所述接诊提示展示数据包可以包括接诊提示信息、接诊提示信息关联的同意接诊控件、拒绝接诊控件等信息。以使所述医生客户端基于所述接诊提示展示数据包展示接诊提示界面，并在所述接诊提示界面展示所述接诊提示信息及所述接诊提示信息关联的同意接诊控件、拒绝接诊控件。
69.或者，也可以在所述接诊提示界面中仅配置一个同意接诊控件及拒绝接诊控件，各问诊请求可以被选中。相应的，服务器可以将问诊请求对应的接诊提示信息发送至医生客户端，以使医生客户端在接诊提示界面中展示问诊请求对应的接诊提示信息。问诊医生对某问诊请求进行处理时，可以先在接诊提示界面中选中相应的问诊请求，再接诊提示界面中的同意接诊控件及拒绝接诊控件进行触发操作，以实现对该被选中的问诊请求的接诊或者拒绝接诊。
70.当然，医生客户端还可以采用其他的方式展示问诊请求对应的接诊提示信息。例如，可以通过接诊消息提示框的方式展示接诊提示信息。问诊医生在接收到服务器发送的接诊提示信息，可以在医生客户端的在线问诊程序的展示界面中弹出接诊消息提示框。在所述接诊消息提示框中展示接诊提示信息。也可以针对所述接诊消息提示框配置表达同意/拒绝接诊的操作控件。如双击所述接诊消息提示框表示同意接诊、单击所述接诊消息提示框表示拒绝接诊等。所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
71.服务器还可以生成辅助诊断信息的辅助诊断提示信息。所述辅助诊断提示信息可以用于表示对辅助诊断信息的详细展示进行提示的信息。如可以将疾病诊断结果及对应的
发生概率“92％结膜炎，8％青光眼”作为辅助诊断提示信息；或者，还可以将“辅助诊断”之类的字样作为辅助诊断提示信息。服务器可以将该辅助诊断提示信息发送至医生客户端，医生客户端可以先展示该辅助诊断提示信息，在辅助诊断提示信息被触发后，再展示对应的辅助诊断信息的详细信息，如疾病诊断结果生成的依据信息、疾病诊断分析信息等。通过上述展示方式，可以使得辅助诊断信息的展示更为简洁、灵活。
72.可以预先配置辅助诊断信息及对应的辅助诊断提示信息的展示方式，所述展示方式可以为服务器先将辅助诊断提示信息发送至医生客户端，服务器在接收到医生客户端反馈的辅助诊断提示信息被触发的情况下，再向医生客户端反馈给辅助诊断提示信息对应的辅助诊断信息，展示相应的辅助诊断信息。或者，服务器也可以将辅助诊断提示信息、辅助诊断信息、展示方式一起发送至医生客户端。医生客户端可以基于所述展示方式先展示辅助诊断提示信息，在接收到问诊医生对所述辅助诊断提示信息的触发操作的情况下，医生客户端再展示相应的辅助诊断信息。
73.医生客户端如可以生成单独的辅助诊断信息展示界面，将该辅助诊断信息展示界面在接诊提示界面的上方进行显示，接诊提示界面隐藏展示。医生客户端在接收到问诊医生对辅助诊断信息展示界面的关闭操作后，关闭辅助诊断信息展示界面，恢复展示接诊提示界面。或者，医生客户端也可以直接在辅助诊断提示信息的下方展示对应的辅助诊断信息。如可以配置辅助诊断提示信息的展示框是可扩展的，医生客户端在接收到问诊医生对相应辅助诊断提示信息的触发操作后，可以向下扩展辅助诊断提示信息的展示框，并在该展示框的扩展区域中展示对应的辅助诊断信息。如辅助诊断信息受展示框的限制，未能全部展示，则医生客户端还可以基于上、下、左、右滑动等操作，在展示框中依据滑动方向展示辅助诊断信息的其余内容。还可以预先配置辅助诊断信息的退出展示操作方式，如双击或滑动等。问诊医生可以执行相应的退出展示操作，医生客户端在接收到该操作后，可以收起展示框，回退至仅展示辅助诊断提示信息的状态。
74.相应的，一些实施例中，可以将辅助诊断信息中的疾病诊断结果及疾病诊断结果的发生概率作为辅助诊断信息的辅助诊断提示信息，以使医生客户端先展示辅助诊断提示信息，在辅助诊断提示信息被触发后，再展示被触发的辅助诊断提示信息对应的辅助诊断信息，以进一步提高接诊提示信息展示的简洁性及灵活性。
75.当然，上述展示方式仅为优选举例说明，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
76.上述实施例提供的方案中，服务器在接收到问诊请求后，可以进一步确定针对问诊请求的辅助诊断信息，并将该辅助诊断信息作为问诊请求的接诊提示信息之一，先向所确定的问诊医生发送接诊提示。问诊医生可以基于该接诊提示信息中的辅助诊断信息初步判断其是否能够完成相应问诊请求的诊断。如可以完成针对，则进入问诊环节；如不能完成诊断，则可以拒绝接诊。通过上述方式，可以使得问诊医生更加快速准确的确定其是否能够完成问诊请求，在可以完成的情况下，再进行相应的问诊环节，进而提高用户及医生在问诊沟通过程中顺畅度，提高用户及医生的使用体验感。
77.医生客户端在接收到同意接诊的触发后，可以将同意接诊的指令反馈至服务器。服务器在接收到该反馈的指令后，可以在用户客户端与该问诊医生的医生客户端之间建立
数据通信，构建会话窗口，以使用户与问诊医生进行在线交互。
78.若问诊医生基于接诊提示信息中的辅助诊断信息确认不能完成该问诊请求的诊断。如出现该问诊请求不属于问诊医生所在的科室、该问诊请求不是问诊医生所擅长的专业领域、或问诊医生当前暂时没时间接诊等情况，导致问诊医生不能完成该问诊请求的诊断，则问诊医生可以拒绝接诊。相应的，医生客户端在接收到拒绝接诊的触发后，可以将拒绝接诊的指令反馈至服务器。
79.所述拒绝接诊指令可以为单独的拒绝接诊指示，也可以包括拒绝接诊理由、转诊推荐信息等。当然，并非所有情况下都需要重新确定问诊医生，服务器还可以基于该拒绝接诊指令中所包含的拒绝接诊理由确定是否执行重新确定问诊医生的操作，或者服务器也可以将拒绝接诊指令反馈给用户客户端，以使用户确定是否重新确定问诊医生。
80.例如，医生客户端接收到拒绝接诊的触发操作后，可以展示拒绝接诊的理由输入界面。如图4所示，所述理由输入界面可以包括预先配置的理由选项及理由输入框。所述理由选项可以为预先配置的常用拒绝原因，如可以包括“科室不正确”、“非擅长的专业问题”、“患者为急诊，需线下就医”、“当前暂无时间接诊”等。所述理由输入框可以由医生根据需要自行输入拒绝接诊理由。问诊医生可以在该理由输入界面选择理由选项，也可以在理由输入框中输入拒绝接诊理由。相应的，医生客户端可以将拒接接诊的指令及拒绝接诊理由一起发送至服务器。
81.如上述示例所述，拒绝的原因存在很多种情况，但并非所有情况均需重新确定问诊医生。如对于拒绝接诊的原因为“患者为急诊，需线下就医”的情况，则服务器可以先向用户客户端反馈该拒绝理由，以使用户确认继续在线问诊还是放弃在线问诊。用户在接收到通知后，通常会选择线下就医，相应的，服务器也无需再重新确定线上问诊医生。而对于接诊时间不匹配导致的拒接接诊、病症不匹配导致的拒接接诊的情况，则通常需要重新确定线上问诊医生。接诊时间不匹配对应的拒绝接诊理由如可以描述为“当前暂无时间接诊”等。病症不匹配对应的拒绝接诊理由如可以描述为“科室不正确”、“非擅长的专业问题”等。相应的，服务器至少在接收到接诊时间不匹配对应的拒绝接诊理由、病症不匹配对应的拒绝接诊理由的情况下，重新确定问诊医生，以使得问诊医生的确定更符合实际线上问诊需求。
82.假设服务器在第一次确定问诊医生时，先确定出针对问诊请求的科室，再从该科室下的医生中筛选出针对该问诊请求的多个医生，作为备选医生。如果拒绝理由是“当前暂时无法接诊”，则服务器可以先从所述备选医生中剔除拒接接诊的问诊医生，再结合剔除处理后剩余的备选医生中各医生的接诊速度确定可以快速接诊的医生，作为重新确定的问诊医生。或者，也可以将剔除处理后剩余的备选医生发送至用户客户端，以使用户从中选择一个医生，作为重新确定的问诊医生。
83.服务器还可以基于医生客户端反馈的转诊推荐信息重新确定问诊医生。例如，问诊医生还可以在拒绝接诊的理由输入框输入转诊推荐信息。所述转诊推荐信息如可以为推荐的科室信息、推荐的医生信息等。一些实施方式中，在接收到病症不匹配对应的拒绝接诊理由的情况下，服务器还可以向医生客户端发送转诊推荐界面，以使问诊医生在所述转诊推荐界面输入转诊推荐信息，服务器可以接收医生客户端反馈的转诊推荐信息，以基于所述转诊推荐信息重新确定问诊医生。
84.例如，如果拒绝接诊理由为“科室不正确”，则医生客户端还可以展示科室推荐界面。如医生客户端在接收到该拒绝理由后，可以将该拒绝理由反馈至服务器，服务器可以基于该拒绝理由，提取科室信息，并反馈至医生客户端，以使医生客户端展示科室推荐界面。提取的科室信息如可以为本次医生匹配时所确定的最低一级科室的同级别的其他科室。如本次医生匹配时所确定的最低一级科室为“眼底病变科”，则可以获取与“眼底病变科”同级别的其他科室，提取的科室为“眼科综合”、“眼底病变科”、“眼眶病眼肿瘤科”等。然后，可以将提取的科室作为针对该问诊请求的预推荐科室，发送至医生客户端。如图5所示，医生客户端可以在科室推荐界面展示上述预推荐科室。通过基于预推荐科室进行科室推荐，可以大幅提高医生进行科室推荐的简便性，提高医生使用体验感。
85.如果科室推荐界面展示的上述预推荐科室中不存在问诊医生所需的科室，则问诊医生还可以触发“无对应科室”选项。医生客户端可以基于问诊医生对该选项的触发操作，向服务器发送详细科室提取指令。服务器可以向医生客户端反馈较为全面的科室信息，如图5所示，问诊医生可以从中选择推荐的科室信息。
86.医生客户端可以将问诊医生推荐的科室信息反馈至服务器，以使服务器基于医生推荐的科室信息重新确定问诊医生。
87.如拒绝理由是“非擅长的专业问题”，则服务器还可以在保证科室不变的情况下，结合转诊推荐信息，基于相应科室下各医生的擅长方向描述信息，重新筛选医生，作为备选医生，进而再基于该备选医生重新确定问诊医生。
88.上述实施方式，基于推荐转诊信息重新确定问诊医生，可以更加快速准确地的筛选出符合用户问诊需求的问诊医生，提高用户使用体验感。
89.辅助诊断信息也可能是不准确的或者存在一些错误的，在接收到病症不匹配对应的拒绝接诊理由的情况下，医生客户端还可以展示辅助诊断核查界面，以使问诊医生在辅助诊断信息有误的情况下，在辅助诊断核查界面输入针对所述辅助诊断信息的修正信息。服务器可以基于针对所述辅助诊断信息的修正信息重新生成新的辅助诊断信息及重新确定问诊医生，进一步提高辅助诊断信息及问诊医生重新确定的准确性。或者，服务器还可以综合辅助诊断信息的修正信息、推荐的科室信息等，重新确定问诊医生。
90.服务器在接收到医生客户端发送的拒绝接诊指令的情况下，还可以向用户客户端发送转诊提醒，以使用户基于所述转诊提醒确认是否转诊。服务器在接收到用户客户端发送确认转诊的情况下，重新确定问诊医生。
91.如图6所示，所述转诊提醒可以包括拒绝接诊理由、问诊医生的转诊推荐信息等。用户可以基于所述转诊提醒确认是否转诊。例如，所述转诊提醒还可以包括“转诊”控件和“申请退款”控件，用户在同意转诊的情况下，可以选择“转诊”控件，如果不同意转诊的情况下，可以选择“申请退款”控件。如果用户选择“转诊”控件，用户客户端可以基于用户的该触发操作向服务器发送同意转诊指令。服务器可以在接收到该同意转诊指令的情况下，重新确定问诊医生。
92.在用户选择“转诊”控件后，服务器可以用户客户端发送重新筛选出的备选医生或者剔除拒绝接诊的医生后的备选医生。如图6所示，用户客户端可以向用户展示相应的医生信息。如果存在多个医生，则还可以配置自动转诊选项，如果用户选择自动转诊选项，则服务器可以根据结合各医生的接诊速度选择可以更快接诊的医生，作为重新确定的问诊医
生。当然，用户也可以基于展示的医生信息，从中选择任一医生。服务器可以将用户选择的医生作为重新确定的问诊医生。
93.服务器可以在重新确定问诊医生后，直接在该问诊医生的医生客户端和用户的用户客户端之间构建交互窗口，进入在线问诊沟通环节。当然，服务器也可以在重新确定问诊医生后，将问诊请求对应的辅助诊断信息发送至重新确定的问诊医生的医生客户端，以使重新确定的问诊医生基于辅助诊断信息确认是否接诊。依次类推，直至某问诊医生同意接诊。
94.在服务器接收到拒绝接诊的指令后，还可以根据需要变更医生客户端所展示的问诊咨询的状态。如服务器准备执行重新确定问诊医生的操作，则可以将问诊咨询的状态变更为已转诊，以使医生客户端展示问诊咨询的状态为已转诊，如图5所示。当然，对于“患者为急诊，需线下就医”的情况，服务器可以将问诊咨询的状态变更为结束线上诊断等。
95.服务器还可以根据问诊医生所反馈的拒绝接诊的理由、转诊推荐信息等，向问诊医生发放奖励，以提高问诊医生辅助重新确定问诊医生的积极性，以及还可以辅助问诊平台快速准确地确定合适的问诊医生，节省问诊平台的数据处理资源，以及提高用户的满意度。如图7所示，服务器可以将转诊奖励发放情况发送给医生客户端，以使医生客户端进行展示。
96.一些实施方式中，可以预先针对不同类型的转诊推荐信息分别配置不同的转诊奖励分配策略。参见上述实施方式，所述转诊推荐信息如可以为科室推荐信息、辅助诊断信息的修正信息，以便于服务器基于该转诊推荐信息执行问诊医生的二次匹配。或者，所述转诊推荐信息还可以直接为推荐的医生信息，此时，则不需要服务器再执行问诊医生的二次匹配。当然，也可能存在未给出转诊推荐信息的情况。针对不同类型的转诊推荐信息，问诊医生所付出的劳动以及对问诊平台的问诊资源节省情况是存在较大差异的，相应的可以为问诊医生配置不同的转诊奖励。例如，可以配置科室推荐信息对应第一奖励额，辅助诊断信息的修正信息对应第二奖励额，推荐的医生信息对应第三奖励额，第一奖励额、第二奖励额以及第三奖励额的大小可以根据需要配置。当然，针对科室推荐信息所包含的科室级别的不同，还可以进一步对科室推荐信息对应的第一奖励额进一步进行细分。而针对没有转诊推荐信息的情况，可以不给予转诊奖励，也可以适当给予指定奖励额。
97.相应的，服务器在接收到转诊推荐信息后，还可以基于转诊推荐信息所关联的转诊奖励分配策略，向给出所述接诊推荐信息的问诊医生分配转诊奖励。如转诊推荐信息包括科室推荐信息，则可以向给出所述接诊推荐信息的问诊医生分配第一奖励额；或者，针对科室推荐信息所包含的科室级别，向给出所述接诊推荐信息的问诊医生分配对应的细分奖励额。如果转诊推荐信息包括科室推荐信息以及辅助诊断信息的修正信息，则可以将第一奖励额与第二奖励额的和作为转诊奖励，分配至给出所述接诊推荐信息的问诊医生。
98.当然，上述实施方式仅为优选举例说明，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。基于上述实施方式，一些实施例中，服务器可以接收所述医生客户端反馈的拒绝接诊指令，以基于所述拒绝接诊指令重新确定所述问诊请求对应的问诊医生。
99.另一些实施例中，服务器在接收到所述医生客户端反馈的拒绝接诊指令后，还可
以向所述医生客户端反馈拒绝接诊的理由输入界面，以基于所述医生客户端反馈的拒绝接诊理由确认是否需要重新确定问诊医生。优选的，服务器可以至少在所述拒绝接诊理由为接诊时间不匹配或病症不匹配的情况下，重新确定所述问诊请求对应的问诊医生。
100.另一些实施例中，服务器还可以将所述拒绝接诊指令发送至所述用户客户端，在接收到所述用户客户端反馈的重新筛选问诊医生的指令的情况下，重新确定所述问诊请求对应的问诊医生。
101.另一些实施例中，服务器还可以在确认是否需要重新确定问诊医生的情况下，向所述医生客户端发送转诊推荐界面；并接收所述医生客户端反馈的在所述转诊推荐界面所输入的转诊推荐信息，以基于所述转诊推荐信息重新确定所述问诊请求对应的问诊医生。
102.其中，在所述拒绝接诊理由为病症不匹配的情况下，所述转诊推荐界面可以包括科室推荐界面，所述科室推荐界面可以包括至少一个科室信息，所述科室信息预先与问诊医生相关联。所述科室推荐界面还可以包括服务器针对所述问诊请求的预推荐科室。在预推荐科室中没有问诊医生所需选择的科室类型的情况下，再基于相应的触发向问诊医生展示更为全面的科室信息，以使问诊医生选择。
103.或者，在所述拒绝接诊理由为病症不匹配的情况下，所述转诊推荐界面还可以包括辅助诊断核查界面。服务器还可以接收所述医生客户端反馈的在所述辅助诊断核查界面中所输入的针对所述辅助诊断信息的修正信息，以基于所述针对所述辅助诊断信息的修正信息重新确定所述问诊请求对应的问诊医生。
104.另一些实施例中，服务器还可以基于所述转诊推荐信息所关联的转诊奖励分配策略，向给出所述接诊推荐信息的问诊医生分配转诊奖励。
105.本说明书实施方式还提供一种服务器，包括如下模块。信息接收模块，用于接收用户客户端发送的问诊请求。信息发送模块，用于在确定所述问诊请求对应的问诊医生后，向所述问诊医生的医生客户端发送接诊提示信息，以使所述医生客户端展示所述接诊提示信息；其中，所述接诊提示信息至少包括针对所述问诊请求的辅助诊断信息。本实施方式提供的服务器中，所涉及的功能模块实现的功能和效果，可以与其它实施方式对照解释，不再赘述。
106.如图8所示，所述服务器可以包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现上述任意一个或者多个实施例所述方法的步骤。类似的，所述用户客户端及医生客户端也可以包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现上述任意一个或者多个实施例所述方法的步骤。所述用户客户端及医生客户端相比服务器，还可以包括显示设备及输入设备等。
107.所述存储器包括但不限于随机存取存储器(random access memory,ram)、只读存储器(read-only memory,rom)、缓存(cache)、硬盘(hard disk drive,hdd)或者存储卡(memory card)。在本实施方式中，所述计算机存储介质中计算机程序指令实现的具体功能，可以参照其它实施方式对照解释。
108.本说明书还提供一种接诊系统。所述系统至少包括数据库、用户客户端以及医生客户端。当然，所述接诊系统也可以包括服务器。可以预先配置实现确定问诊医生、转诊处理及辅助诊断信息生成等的计算机程序指令。所述确定问诊医生、转诊处理的程序指令可以存储在服务器中，也可以存储在用户客户端的存储介质中。所述辅助诊断信息生成的程
序指令可以存储在服务器中，也可以存储在医生客户端的存储介质中。所述数据库、用户客户端、医生客户端及服务器的其他模块功能及结构可以参考上述实施方式，这里不做赘述。相应的，如图9所示，本说明书实施方式还提供一种接诊方法，所述接诊方法可以应用于该接诊系统的医生客户端，所述方法可以包括以下步骤。
109.s40：接收接诊提示信息；其中，所述接诊提示信息至少包括针对用户客户端发起的问诊请求的辅助诊断信息。
110.如上述实施方式所述，用户客户端可以生成问诊请求，并将问诊请求发送至服务器。服务器在接收到用户客户端发送的问诊请求后，可以确定针对该问诊请求的问诊医生。当然，确定问诊医生的方法还可以配置在用户客户端中，由用户客户端在生成问诊请求后，确定针对该问诊请求的问诊医生。用户客户端确定针对该问诊请求的问诊医生的具体实施方式可以参考服务器的执行方式实施，这里不做赘述。
111.用户客户端或者服务器在确定问诊医生后，可以向问诊医生的医生客户端发送接诊提示信息。所述接诊提示信息至少可以包括针对用户客户端发起的问诊请求的辅助诊断信息。所述辅助诊断信息可以由服务器基于上述方式生成，当然也可以由用户客户端生成。或者，也可以在医生客户端接收到问诊请求后，由医生客户端执行辅助诊断信息的生成操作，在生成辅助诊断信息后，作为接诊提示信息的信息之一，以进行接诊提示信息的展示。医生客户端或用户客户端生成针对该问诊请求的辅助诊断信息的具体实施方式可以参考服务器的执行方式实施，这里不做赘述。
112.所述辅助诊断信息至少可以包括疾病诊断结果、疾病诊断结果生成的依据信息、疾病诊断分析信息等等。其中，疾病诊断结果如可以为“低血压”、“青光眼”、“结膜炎”等。疾病诊断结果生成的依据信息如可以包括生成该疾病诊断结果所依据的主诉信息、历史疾病信息、用户基础信息等。疾病诊断分析信息如可以包括疾病诊断结果生成过程中所提取的较为详细的疾病分析信息等。优选的，一些实施例中，所述辅助诊断信息可以包括针对所述问诊请求的至少一个疾病诊断结果及疾病诊断结果的发生概率。服务器在生成问诊请求所对应的辅助诊断信息时，进一步输出发生概率较大的前几个疾病诊断结果及对应的发生概率，可以更加全面的准确地为医生提供诊断提示。
113.一些实施例中，所述问诊请求可以包括用户主诉信息，所述用户主诉信息至少可以包括用户在发起问诊请求时所输入的疾病描述信息。相应的，所述辅助诊断信息至少可以根据所述问诊请求中的用户主诉信息所生成。当然，也可以结合用户基础信息、历史疾病信息等生成问诊请求对应的辅助诊断信息。相应的，所述接诊提示信息至少还可以包括所述用户主诉信息。
114.辅助诊断信息的生成方式及所包含的信息类型可以基于上述实施例实施，这里不做赘述。
115.s42：在接诊提示界面展示所述接诊提示信息；其中，所述接诊提示界面还包括同意接诊控件及拒绝接诊控件，以基于对所述同意接诊控件或拒绝接诊控件的触发操作确定是否对所述问诊请求进行接诊。
116.医生客户端可以展示所述接诊提示信息。例如，医生客户端可以展示接诊提示界面。可以在所述接诊提示界面展示问诊请求对应的接诊提示信息。如图2所示，医生客户端可以在该接诊提示界面展示用户的性别、年龄、主诉信息以及辅助诊断信息等。
117.一些实施例中，可以将辅助诊断信息中的疾病诊断结果及疾病诊断结果的发生概率作为辅助诊断信息的辅助诊断提示信息。相应的，可以先在接诊提示界面展示针对所述问诊请求的辅助诊断提示信息，在所述辅助诊断提示信息被触发后，再展示被触发的辅助诊断提示信息对应的辅助诊断信息。通过初步显示辅助诊断提示信息的方式，可以节省展示空间，使得展示更加简洁。
118.若辅助诊断信息由服务器所生成，基于辅助诊断提示信息触发展示辅助诊断信息的触发机制可以参考上述实施方式，这里不做赘述。若辅助诊断信息由医生客户端所生成，则医生客户端可以先展示辅助诊断提示信息，在接收到问诊医生对辅助诊断提示信息的触发操作后，再对应展示该提示信息所对应的辅助诊断信息。
119.医生客户端在接收到对所述辅助诊断提示信息的触发操作的情况下，可以展示所述辅助诊断信息的展示界面，并隐藏所述接诊提示界面。或者，也可以将辅助诊断提示信息的展示框扩展，在扩展区域内展示相应辅助诊断提示信息对应的辅助诊断信息。具体展示方式可以参考上述实施例，这里不做赘述。
120.医生客户端还可以在所述接诊提示界面配置表达同意/拒绝接诊的操作控件，以使医生客户端基于对相应操作控件的触发确认问诊医生是否接诊。如图2所示，所述接诊提示界面可以包括“去接诊”按钮及“拒绝接诊”按钮。若问诊医生确定其可以完成该问诊咨询的诊断，则可以触发“去接诊”按钮。若问诊医生确定不能完成该问诊咨询的诊断，问诊医生可以触发“拒绝接诊”按钮。医生客户端可以基于该触发将问诊医生同意/拒绝接诊的指令反馈至服务器。或者，还可以在所述接诊提示界面配置表达同意/拒绝接诊的滑动动作，如某问诊请求被选中后，向右滑动表示同意接诊，向左滑动表示拒绝接诊。则医生客户端可以基于该滑动动作将问诊医生同意/拒绝接诊的指令反馈至服务器。
121.医生客户端还可以采用其他的方式展示所述问诊请求以及对应的辅助诊断信息。例如，可以通过接诊消息提示框的方式展示所述问诊请求以及对应的辅助诊断信息。问诊医生在接收到服务器发送的问诊请求以及对应的辅助诊断信息后，可以在医生客户端的在线问诊程序的展示界面中弹出接诊消息提示框。在所述接诊消息提示框中展示所述问诊请求以及对应的辅助诊断信息。也可以针对所述接诊消息提示框配置表达同意/拒绝接诊的操作指令。如双击所述接诊消息提示框表示同意接诊、单击所述接诊消息提示框表示拒绝接诊等。
122.当然，所属领域技术人员在本说明书实施例的技术精髓启示下，还可能有其它变更实施方式，但只要其实现的功能和效果相同或相似，均应涵盖于本说明书保护范围内。
123.医生客户端在接收到问诊医生拒绝接诊的相关操作的情况下，还可以向服务器或用户客户端反馈拒绝接诊理由，以使服务器或用户客户端基于该拒绝接诊理由重新确定问诊医生。所述拒绝接诊理由至少可以包括接诊时间不匹配对应的拒绝接诊理由、病症不匹配对应的拒绝接诊理由等。在接收到问诊医生拒绝接诊的相关操作的情况下，医生客户端可以根据接诊医生的拒绝接诊理由确认是否需要重新确定接诊医生，如接诊医生选择接诊时间不匹配、病症不匹配对应的拒绝接诊理由，医生客户端可以根据该触发展示转诊推荐界面，以采集接诊医生的转诊推荐信息，进而将该转诊推荐信息发送至服务器或用户客户端，以使服务器或用户客户端基于该转诊推荐信息重新确定问诊医生。或者，医生客户端也可以将接诊医生选择的拒绝接诊理由发送至服务器或用户客户端，以使服务器或用户客户
端确认是否重新确定问诊医生。例如，用户客户端可以展示该拒绝接诊理由，以使用户基于该拒绝接诊理由确认是否重新确定问诊医生。
124.在接收到问诊医生拒绝接诊的相关操作的情况下，医生客户端可以展示拒绝接诊的理由输入界面，以基于问诊医生在所述理由输入界面输入的拒绝接诊理由重新确定问诊医生。在接收到病症不匹配对应的拒绝接诊理由的情况下，所述医生客户端还可以展示转诊推荐界面，以使问诊医生在所述转诊推荐界面输入转诊推荐信息。如上述实施方式所述，所述转诊推荐界面可以是医生客户端基于接诊医生在理由输入界面的触发操作后，直接展示的；也可以是服务器或用户客户端确认需要重新确定问诊医生的情况下，向医生客户端发送转诊推荐界面展示指令，以使医生客户端展示的。
125.或者，医生客户端还可以展示辅助诊断核查界面，以基于问诊医生在辅助诊断核查界面输入的针对辅助诊断信息的修正信息重新确定问诊医生。辅助诊断核查界面的展示机制可以参考上述转诊推荐界面执行，这里不做赘述。
126.相应的，基于上述实施方式，一些实施例中，医生客户端在接收到对所述拒绝接诊控件的触发操作的情况下，可以展示拒绝接诊的理由输入界面。以及，医生客户端还可以接收在所述理由输入界面中所输入的拒绝接诊理由，并反馈至用户客户端或服务器，以使用户客户端或服务器基于所述拒绝接诊理由重新确定所述问诊请求对应的问诊医生。
127.另一些实施例中，在确认需要重新确定问诊医生的情况下，医生客户端可以展示转诊推荐界面。如用户客户端或者服务器确认需要重新确定问诊医生的情况下，可以向医生客户端发送转诊推荐界面数据包，以使医生客户端进行展示。或者医生客户端也可以基于问诊医生所选择的拒绝接诊理由，在确认需要重新确定问诊医生的情况下，基于医生客户端预先配置的数据展示转诊推荐界面。相应的，医生客户端还可以在接收在所述转诊推荐界面中所输入的转诊推荐信息，并反馈至用户客户端或服务器，以使用户客户端或服务器基于所述拒绝接诊理由重新确定所述问诊请求对应的问诊医生。
128.另一些实施例中，在所述拒绝接诊理由为病症不匹配的情况下，所述转诊推荐界面还可以包括科室推荐界面，所述科室推荐界面可以包括至少一个科室信息；所述科室信息预先与问诊医生相关联。其中，所述科室推荐界面可以包括针对所述问诊请求的预推荐科室。
129.另一些实施例中，在所述拒绝接诊理由为病症不匹配的情况下，所述转诊推荐界面还可以包括辅助诊断核查界面，所述辅助诊断核查界面用于问诊医生输入的针对所述辅助诊断信息的修正信息，以基于所述辅助诊断信息的修正信息重新生成辅助诊断信息或重新确定问诊医生，提高问诊医生匹配的准确性。
130.另一些实施例中，医生客户端还可以展示转诊奖励，其中，所述转诊奖励基于所述转诊推荐信息所关联的问诊奖励分配策略所确定。例如，医生客户端还可以接收服务器反馈的转诊奖励，并进行展示。其中，所述转诊奖励由服务器基于所述转诊推荐信息所关联的转诊奖励分配策略所确定。或者，医生客户端也可以基于所述转诊推荐信息所关联的问诊奖励分配策略，确定向给出所述接诊推荐信息的问诊医生分配转诊奖励，并进行展示。
131.上述问诊医生的重新确定方案可以参考上述实施方式实施，这里不做赘述。
132.上述实施方式中，在初步确定问诊医生后，可以先在问诊医生的医生客户端展示接诊提示，该接诊提示中可以包括针对问诊请求的辅助诊断信息。问诊医生可以基于问诊
请求对应的辅助诊断信息确认是否接诊，如果同意接诊则进入线上问诊沟通环节；若拒绝接诊，则重新确定符合需求的问诊医生。通过辅助诊断提示的方式，可以使得问诊医生更加快速准确的确认其能否完成该问诊咨询，在确认不能完成的情况下，可以重新确定问诊医生，以使最终执行线上问诊沟通的问诊医生更符合用户的问诊需求，提高线上问诊沟通的顺畅性，进而提高用户及医生的使用体验感。
133.本说明书实施方式还提供一种医生客户端，包括如下模块。信息接收模块，用于接收接诊提示信息；其中，所述接诊提示信息至少包括针对用户客户端发起的问诊请求的辅助诊断信息。信息展示模块，用于在接诊提示界面展示所述接诊提示信息；其中，所述接诊提示界面还包括同意接诊控件及拒绝接诊控件，以基于对所述同意接诊控件或拒绝接诊控件的触发操作确定问诊医生是否对所述问诊请求进行接诊。本实施方式提供的医生客户端中，所涉及的功能模块实现的功能和效果，可以与其它实施方式对照解释，不再赘述。
134.本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其它实施方式的不同之处。
135.上面对本说明书的各种实施方式的描述以描述的目的提供给本领域技术人员。其不旨在是穷举的、或者不旨在将本发明限制于单个公开的实施方式。如上所述，本说明书的各种替代和变化对于上述技术所属领域技术人员而言将是显而易见的。因此，虽然已经具体讨论了一些另选的实施方式，但是其它实施方式将是显而易见的，或者本领域技术人员相对容易得出。本说明书旨在包括在此已经讨论过的本发明的所有替代、修改、和变化，以及落在上述申请的精神和范围内的其它实施方式。
136.本说明书可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
137.虽然通过实施方式描绘了本说明书，本领域技术人员知道，本说明书有许多变形和变化而不脱离本说明书的精神，希望所附的权利要求包括这些变形和变化而不脱离本说明书的精神。