医疗服务处理方法、服务器及终端与流程

1.本技术涉及医疗服务领域，尤其涉及一种医疗服务处理方法、服务器及终端。


背景技术：

2.随着互联网技术的发展和社会的进步，互联网技术已应用于人们生活的方方面面，例如医疗领域，线上问诊变得越来越普遍。
3.线上问诊场景中，用户基于自身诉求有时会就同一症状进行多次问诊，即“一病多问”。例如，用户就某一症状对医生a进行一次线上问诊通话结束之后，再就该症状对医生b发起二次线上问诊通话，甚至更多次问诊通话。或者，用户也可以在就某一症状对医生a进行线上问诊通话时，通过“更换问诊医生”功能转到其他医生的线上诊室进行问诊，即一次问诊通话实现多个医生问诊。在“一病多问”场景中，当问诊结束后，不论用户是否需要，用户问诊过的医生均会为用户开具处方。但在实际场景中，用户仅需唯一一张处方进行购药即可，多张处方的开具不仅造成了用户选择上的困难，更是造成了医疗资源的严重浪费。
4.因此，需要一种能够准确选择出用户适合的处方、并且避免医疗资源浪费的医疗服务处理方案。


技术实现要素：

5.本技术提供一种医疗服务处理方法、服务器及终端，用以解决现有的线上问诊场景中，用户难以选择除合适的处方，并且会造成医疗资源浪费的技术问题。
6.第一方面，本技术提供一种医疗服务处理方法，应用于服务器，包括：
7.接收用户终端输入的问诊开方请求，确定所述用户终端的用户对应的问诊问题以及问诊医生；
8.当所述问诊医生为多个时，判断所述问诊问题的数目是否为一个；
9.若是，则根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表，并将所述推荐开方医生列表发送至所述用户终端；
10.接收所述用户终端发送的开方医生，并向所述开方医生对应的第一医生终端发送开方提示信息；
11.接收所述第一医生终端发送的处方信息，并将所述处方信息发送至所述用户终端。
12.在一种可能的实施方式中，所述根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表，具体包括：
13.判断所述用户是否存在对应的开方偏好，所述开方偏好包括问诊时长偏好和医生职称偏好中的一种或多种；
14.若是，则获取每一所述问诊医生对应的问诊时长和/或医生职称；按照问诊时长由长到短的顺序、和/或医生职称由高到低的顺序，对所述问诊医生进行排序，以生成推荐开方医生列表，并对列表中排序最先的问诊医生设置推荐标签；
15.若否，则利用预设的评估指标对每一所述问诊医生进行评估，以确定每一所述问诊医生对应的评估分数；按照评估分数由大到小的顺序，对所述问诊医生进行排序，以生成推荐开方医生列表，并对列表中排序最先的问诊医生设置推荐标签。
16.在一种可能的实施方式中，所述评估指标包括问诊时长、医生职称、医生好评率、问诊问题与所述问诊医生所处科室的匹配度、医生问诊数目、医生文章发表数目中的一种或多种。
17.在一种可能的实施方式中，所述确定所述用户终端的用户对应的问诊问题以及问诊医生，具体包括：
18.确定所述用户在预设时长内的线上问诊记录；根据每一所述线上问诊记录对应的问诊问题以及问诊医生，确定所述用户对应的问诊问题以及问诊医生；
19.或者，
20.确定所述用户最近一次的线上问诊记录；根据所述最近一次的线上问诊记录对应的问诊问题以及问诊医生，确定所述用户对应的问诊问题以及问诊医生。
21.在一种可能的实施方式中，所述线上问诊记录是通过下列方式获得的：
22.接收所述用户终端发送的问诊请求，确定所述问诊请求中的问诊问题对应的第一医生；
23.判断所述用户是否存在对应的就医偏好，所述就医偏好包括医生性别偏好、医生职称偏好和医生类型偏好中的一种或多种；
24.若是，则根据所述用户对应的就医偏好对所述第一医生进行筛选，以得到符合所述就医偏好的第二医生；利用所述评估指标对每一所述第二医生进行评估，以确定每一所述第二医生对应的评估分数；按照评估分数由大到小的顺序对所述第二医生进行排序，以生成第一推荐问诊医生列表，并对列表中排序最先的第二医生设置推荐标签；
25.若否，则利用所述评估指标对每一所述第一医生进行评估，以确定每一所述第一医生对应的评估分数；按照评估分数由大到小的顺序对所述第一医生进行排序，以生成第一推荐问诊医生列表，并对列表中排序最先的第一医生设置推荐标签；
26.将所述第一推荐问诊医生列表发送至所述用户终端，接收所述用户终端发送的第一问诊医生，并向所述第一问诊医生对应的第二医生终端发送问诊连接请求；
27.接收所述第二医生终端发送的允许连接信息后，开启所述用户终端与所述第二医生终端之间的线上通信连接，以开启所述第一问诊医生对应的第一问诊过程；
28.在接收到所述第二医生终端发送的问诊结束信息之后，根据所述第一问诊医生、所述第一问诊医生对应的问诊医生信息、所述第一问诊过程对应的问诊时长、所述问诊请求中的问诊问题中的一种或多种，生成所述第一问诊过程对应的第一线上问诊记录；
29.根据所述第一线上问诊记录，生成所述用户对应的线上问诊记录；
30.其中，所述问诊医生信息包括如下的一种或多种：医生姓名、医生性别、医生类型、医生职称、医生好评率、医生问诊数目、医生文章发表数目。
31.在一种可能的实施方式中，在所述接收到所述第二医生终端发送的问诊结束信息之后，还包括：
32.接收所述用户终端发送的更换医生请求，并判断所述用户是否存在对应的就医偏好；
33.若是，则根据所述用户对应的就医偏好对所述第一医生进行筛选，以得到符合所述就医偏好的第三医生；利用所述评估指标对每一所述第三医生进行评估，以确定每一所述第三医生对应的评估分数；按照评估分数由大到小的顺序对所述第三医生进行排序，以生成第二推荐问诊医生列表，并对列表中排序最先的第三医生设置推荐标签；
34.若否，则利用所述评估指标对每一所述第一医生进行评估，以确定每一所述第一医生对应的评估分数；按照评估分数由大到小的顺序对所述第一医生进行排序，以生成第二推荐问诊医生列表，并对列表中排序最先的第一医生设置推荐标签；
35.将所述第二推荐问诊医生列表发送至所述用户终端，接收所述用户终端发送的第二问诊医生，并向所述第二问诊医生对应的第三医生终端发送问诊连接请求；
36.接收所述第三医生终端发送的允许连接信息后，开启所述用户终端与所述第三医生终端之间的线上通信连接，以开启所述第二问诊医生对应的第二问诊过程；
37.在接收到所述第三医生终端发送的问诊结束信息之后，根据所述第二问诊医生、所述第二问诊医生对应的问诊医生信息、所述第二问诊过程对应的问诊时长、所述问诊请求中的问诊问题中的一种或多种，生成所述第二问诊过程对应的第二线上问诊记录；
38.相应的，所述根据所述第一线上问诊记录，生成所述用户对应的线上问诊记录，具体包括：
39.根据所述第一线上问诊记录以及所述第二线上问诊记录，生成所述用户对应的线上问诊记录。
40.在一种可能的实施方式中，还包括：
41.当所述问诊问题的数目为多个时，判断所述问诊问题中是否存在对应多个问诊医生的目标问诊问题；
42.若是，则针对所述目标问诊问题，执行所述根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表的步骤；针对所述问诊问题中除所述目标问诊问题之外的其他问诊问题，分别向各自对应的问诊医生的医生终端发送开方提示信息；
43.若否，则对以每一所述问诊问题，分别向各自对应的问诊医生的医生终端发送开方提示信息。
44.第二方面，本技术提供另一种医疗服务处理方法，应用于用户终端，包括：
45.向服务器发送问诊开方请求，所述问诊开方请求用于指示服务器确定所述用户终端的用户对应的问诊问题以及问诊医生，并在所述问诊医生为多个时，判断所述问诊问题的数目是否为一个，若是，则根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表，并将所述推荐开方医生列表发送至所述用户终端；
46.接收并显示服务器发送的推荐开方医生列表，在接收到用户选择的开方医生之后，将所述开方医生发送至服务器，以便服务器接收所述用户终端发送的开方医生，并向所述开方医生对应的第一医生终端发送开方提示信息，并接收所述第一医生终端发送的处方信息，并将所述处方信息发送至所述用户终端；
47.接收并显示所述服务器发送的处方信息。
48.第三方面，本技术提供一种服务器，包括：
49.接收模块，用于接收用户终端输入的问诊开方请求，确定所述用户终端的用户对应的问诊问题以及问诊医生；
50.第一处理模块，用于在所述问诊医生为多个时，判断所述问诊问题的数目是否为一个；若是，则根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表，并将所述推荐开方医生列表发送至所述用户终端；接收所述用户终端发送的开方医生，并向所述开方医生对应的第一医生终端发送开方提示信息；接收所述第一医生终端发送的处方信息，并将所述处方信息发送至所述用户终端。
51.第四方面，本技术提供一种用户终端，包括：
52.发送模块，用于向服务器发送问诊开方请求，所述问诊开方请求用于指示服务器确定所述用户终端的用户对应的问诊问题以及问诊医生，当所述问诊医生为多个时，判断所述问诊问题的数目是否为一个，若是，则根据预设的评估指标或者所述用户对应的开方偏好，对所述问诊医生进行排序，以生成推荐开方医生列表，并将所述推荐开方医生列表发送至所述用户终端；
53.第二处理模块，用于接收并显示服务器发送的推荐开方医生列表，在接收到用户选择的开方医生之后，将所述开方医生发送至服务器，以便服务器接收所述用户终端发送的开方医生，并向所述开方医生对应的第一医生终端发送开方提示信息，并接收所述第一医生终端发送的处方信息，并将所述处方信息发送至所述用户终端；接收并显示所述服务器发送的处方信息。
54.第五方面，本技术提供一种服务器，包括：处理器，以及与所述处理器通信连接的存储器；
55.所述存储器存储计算机执行指令；
56.所述处理器执行所述存储器存储的计算机执行指令，以实现上述第一方面的方法。
57.第五方面，本技术提供一种用户终端，包括：处理器，以及与所述处理器通信连接的存储器；
58.所述存储器存储计算机执行指令；
59.所述处理器执行所述存储器存储的计算机执行指令，以实现上述第二方面的方法。
60.第六方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面上述的方法。
61.第七方面，本技术提供另一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第二方面上述的方法。
62.本技术提供的医疗服务处理方法、服务器及终端，可以接收用户终端输入的问诊开方请求，确定用户终端的用户对应的问诊问题以及问诊医生；在问诊医生为多个时，判断问诊问题的数目是否为一个；若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端；接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息；接收第
一医生终端发送的处方信息，并将处方信息发送至用户终端。本技术的方法，在接收到用户终端输入的问诊开方请求之后，可以通过确定用户终端的用户对应的问诊问题以及问诊医生，来判断该问诊开方请求是否存在“一病多问”的情形。当确定存在该情形，即一个问诊问题对应多个问诊医生时，可以对用户对应的问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端，从而为用户推荐开方医生。在接收到用户终端发送的开方医生之后，可以仅向开方医生对应的第一医生终端发送开方提示信息。通过这样的设置，可以在用户线上问诊过程中出现“一病多问”情形，即一个问诊问题对应多个问诊医生时，仅使得多个问诊医生中的一位开具处方，而不是全部问诊医生均开具处方，不仅可以避免多张处方的开具给用户选择上带来的困难，还能够避免多位医生针对同一病症开具处方造成的医疗资源的浪费，提升了医生的工作能效。进一步的，通过根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，可以提高开方医生推荐的准确性和匹配性，并且也保证了用户选择的自由性，用户可以自主选择开方医生，提升了用户使用体验。
附图说明
63.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
64.图1为现有技术中某一线上问诊的系统架构图；
65.图2为本技术一实施例的系统架构图；
66.图3为本技术一实施例的医疗服务处理方法的流程图；
67.图4为本技术另一实施例的医疗服务处理方法的流程图；
68.图5为本技术一实施例的服务器的结构示意图；
69.图6为本技术一实施例的用户终端的结构示意图；
70.图7为本技术另一实施例的服务器的结构示意图；
71.图8为本技术另一实施例的用户终端的结构示意图。
72.附图标记：1、用户终端；2、服务器；3a、医生a对应的医生终端；3b、医生b对应的医生终端；4、第一医生终端；51、接收模块；52、第一处理模块；61、发送模块；62、第二处理模块。
73.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
74.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
75.本技术的医疗服务处理方法、服务器及终端可用于医疗领域，例如，用户利用医疗平台进行线上问诊的场景。当然，本技术的医疗服务处理方法、服务器及终端也可用于其他
领域，具体的应用领域并不作限定。
76.需要说明的是，本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
77.线上问诊场景中，用户基于自身诉求有时会就同一症状进行多次问诊，即“一病多问”。例如，用户就某一症状对医生a进行一次线上问诊通话结束之后，再就该症状对医生b发起二次线上问诊通话，甚至更多次问诊通话。或者，用户也可以在就某一症状对医生a进行线上问诊通话时，通过“更换问诊医生”功能转到其他医生的线上诊室进行问诊，即一次问诊通话实现多个医生问诊。在“一病多问”场景中，当问诊结束后，不论用户是否需要，用户问诊过的医生均会为用户开具处方。
78.示例性的，图1为现有技术中某一线上问诊的系统架构图，如图1所示，某用户通过用户终端1向某医疗平台的服务器2就某一症状请求线上问诊，服务器2根据症状为其匹配医生a，并在获得该用户许可之后向医生a对应的医生终端3a发送通话请求，以连通该用户与医生a之间的线上问诊通话，从而开始线上问诊。该用户在结束与医生a的问诊后，通过“更换问诊医生”79.功能向服务器2请求更换医生，服务器2为其匹配医生b，并在获得该用户许可之后向医生b对应的医生终端3b发送通话请求，以连通该用户与医生b之间的线上问诊通话，从而开始线上问诊。该用户在结束与医生b的问诊后，
80.彻底结束此次的线上问诊通话，并通过用户终端1向服务器2发送问诊开方5请求，服务器2接收到之后，向医生终端3a和医生医生终端3b分别发送开
81.方提示信息，医生a和医生b接收到开方提示信息之后，分别将开具的处方通过终端上传至服务器2，服务器2接收到之后将其分别发送至用户终端1。
82.但在实际场景中，用户仅需唯一一张处方进行购药即可，多张处方的开具不仅造成了用户选择上的困难，更是造成了医疗资源的严重浪费。
83.0基于该技术问题，本技术的发明构思在于：如何提供一种能够准确选择
84.出用户适合的处方、并且避免医疗资源浪费的医疗服务处理方法。
85.具体为，在接收到用户终端输入的问诊开方请求之后，可以通过确定用户终端的用户对应的问诊问题以及问诊医生，来判断该问诊开方请求是否存
86.在“一病多问”的情形。当确定存在该情形，即一个问诊问题对应多个问诊5医生时，可以对用户对应的问诊医生进行排序，以生成推荐开方医生列表，
87.并将推荐开方医生列表发送至用户终端，从而为用户推荐开方医生。在接收到用户终端发送的开方医生之后，可以仅向开方医生对应的第一医生终端发送开方提示信息。通过这样的设置，可以在用户线上问诊过程中出现“一病
88.多问”情形，即一个问诊问题对应多个问诊医生时，仅使得多个问诊医生中0的一位开具处方，而不是全部问诊医生均开具处方，不仅可以避免多张处方的开具给用户选择上带来的困难，还能够避免多位医生针对同一病症开具处方造成的医疗资源的浪费，提升了医生的工作能效。进一步的，通过根据预设的评估指标或者用户对应的开方偏好，对问诊
医生进行排序，以生成推荐
89.开方医生列表，可以提高开方医生推荐的准确性和匹配性，并且也保证了用5户选择的自由性，用户可以自主选择开方医生，提升了用户使用体验。
90.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
91.0图2是本技术一实施例的系统架构图，如图2所示，1表示用户终端、2表示服务器、4表示第一医生终端。服务器2接收到用户终端1输入的问诊开方请求之后，确定用户终端1的用户对应的问诊问题以及问诊医生，在问诊医生为多个时，判断问诊问题的数目是否为一个；若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端1；接收用户终端1发送的开方医生，并向开方医生对应的第一医生终端4发送开方提示信息；接收第一医生终端4发送的处方信息，并将处方信息发送至用户终端1。
92.实施例一
93.图3是本技术一实施例提供的医疗服务处理方法的流程图，本实施例以执行主体为服务器对该医疗服务处理方法进行说明。如图3所示，该医疗服务处理方法可以包括以下步骤：
94.s101：接收用户终端输入的问诊开方请求，确定用户终端的用户对应的问诊问题以及问诊医生。
95.在本实施例中，用户在彻底结束一次线上问诊之后，可以通过用户终端向服务器发送问诊开方请求，以便服务器通知问诊医生开具处方。
96.在一个可能的实施方式中，上述步骤s101中的确定用户终端的用户对应的问诊问题以及问诊医生，可以包括：确定用户在预设时长内的线上问诊记录；根据每一线上问诊记录对应的问诊问题以及问诊医生，确定用户对应的问诊问题以及问诊医生。
97.在本实施方式中，预设时长本领域技术人员可以灵活设置，例如，预设时长可以是30min，也可以是1h，在此不做任何限制。
98.在本实施方式中，用户在就同一症状进行问诊时，可能在一段时间之内通过发起多次问诊通话的方式，对多个医生进行问诊，即多次通话记录对应一个问诊问题。因此，通过用户在预设时长内的线上问诊记录，即可准确而又全面地确定用户对应的问诊问题以及问诊医生。
99.可替代的，上述步骤s101中的确定用户终端的用户对应的问诊问题以及问诊医生，还可以包括：确定用户最近一次的线上问诊记录；根据最近一次的线上问诊记录对应的问诊问题以及问诊医生，确定用户对应的问诊问题以及问诊医生。
100.在本实施方式中，用户最近一次的线上问诊记录，可以是用户对应的线上问诊记录中，产生时间最新的记录。
101.在本实施方式中，用户在就同一症状进行问诊时，还可能利用“更换问诊医生”功能在一次线上问诊通话中进行转诊，从而对多个医生进行问诊，即一次通话记录对应一个问诊问题。因此，通过用户最近一次的线上问诊记录，即可简单便捷地确定用户对应的问诊问题以及问诊医生。
102.在一个可能的实施方式中，线上问诊记录可以是通过下列方式获得的：
103.s11：接收用户终端发送的问诊请求，确定问诊请求中的问诊问题对应的第一医生。
104.s12：判断用户是否存在对应的就医偏好，就医偏好包括医生性别偏好、医生职称偏好和医生类型偏好中的一种或多种。
105.s13：若是，则根据用户对应的就医偏好对第一医生进行筛选，以得到符合就医偏好的第二医生；利用评估指标对每一第二医生进行评估，以确定每一第二医生对应的评估分数；按照评估分数由大到小的顺序对第二医生进行排序，以生成第一推荐问诊医生列表，并对列表中排序最先的第二医生设置推荐标签。
106.s14：若否，则利用评估指标对每一第一医生进行评估，以确定每一第一医生对应的评估分数；按照评估分数由大到小的顺序对第一医生进行排序，以生成第一推荐问诊医生列表，并对列表中排序最先的第一医生设置推荐标签。
107.s15：将第一推荐问诊医生列表发送至用户终端，接收用户终端发送的第一问诊医生，并向第一问诊医生对应的第二医生终端发送问诊连接请求。
108.s16：接收第二医生终端发送的允许连接信息后，开启用户终端与第二医生终端之间的线上通信连接，以开启第一问诊医生对应的第一问诊过程。
109.s17：在接收到第二医生终端发送的问诊结束信息之后，根据第一问诊医生、第一问诊医生对应的问诊医生信息、第一问诊过程对应的问诊时长、问诊请求中的问诊问题中的一种或多种，生成第一问诊过程对应的第一线上问诊记录。
110.s18：根据第一线上问诊记录，生成用户对应的线上问诊记录。
111.其中，问诊医生信息包括如下的一种或多种：医生姓名、医生性别、医生类型、医生职称、医生好评率、医生问诊数目、医生文章发表数目。
112.在本实施方式中，用户可以通过用户终端向医疗平台对应的服务器发起问诊请求，以进行线上问诊。服务器接收到之后，可以根据问诊请求中的问诊问题匹配对应的第一医生，即初步筛选出能够解决问诊问题的医生，此时的符合要求的第一医生一般为多个。
113.在本实施方式中，用户接收到第一推荐问诊医生列表之后，可以选择列表中排序最先的医生(设置有推荐标签的医生)，也可以自主选择心仪的医生。
114.在本实施方式中，医生性别偏好可以是用户对医生性别的偏好，例如偏好男医生或者偏好女医生。医生职称偏好可以是用户对医生职称的偏好，例如偏好高职称医生(主任医师等)。医生类型偏好可以是用户对医生类型的偏好，例如偏好中医还是偏好西医。
115.在本实施方式中，第一推荐问诊医生列表中的每一问诊医生，还可以包括各自对应的问诊医生信息，以便用户根据问诊医生信息确定合适的问诊医生。
116.在本实施方式中，生成第一线上问诊记录时，首先可以判断第一问诊过程对应的问诊时长是否超过时长阈值，只有在超过超过时长阈值时，才认为此次问诊过程是有效的，可以生成第一线上问诊记录。
117.在本实施方式中，在初步筛选出能够解决问诊问题的第一医生之后，可以通过用户对应的就医偏好对第一医生二次进行筛选，以得到符合就医偏好的第二医生，并利用评估指标对每一第二医生进行评估，以生成第一推荐问诊医生列表，并对列表中排序最先的第二医生设置推荐标签。通过这样的设置，不仅可以满足不同用户的就医偏好，还可以通过
评估指标提高问诊医生推荐的准确性和匹配性，从而提升用户体验。进一步的，通过在推荐问诊医生列表中设置推荐标签，可以为用户推荐最合适的医生人员，并且推荐问诊医生列表的存在还保留了用户选择的自主性，进一步提升用户体验。进一步的，通过根据第一问诊医生、第一问诊医生对应的问诊医生信息、第一问诊过程对应的问诊时长、问诊请求中的问诊问题中的一种或多种，生成线上问诊记录，可以提高线上问诊记录的准确性和全面性，以便于后续根据线上问诊记录确定问诊问题和问诊医生，并根据线上问诊记录相应的问诊医生进行评估。
118.在一个可能的实施方式中，在上述步骤s17中的在接收到第二医生终端发送的问诊结束信息之后，还可以包括：
119.s21：接收用户终端发送的更换医生请求，并判断用户是否存在对应的就医偏好。
120.s22：若是，则根据用户对应的就医偏好对第一医生进行筛选，以得到符合就医偏好的第三医生；利用评估指标对每一第三医生进行评估，以确定每一第三医生对应的评估分数；按照评估分数由大到小的顺序对第三医生进行排序，以生成第二推荐问诊医生列表，并对列表中排序最先的第三医生设置推荐标签。
121.s23：若否，则利用评估指标对每一第一医生进行评估，以确定每一第一医生对应的评估分数；按照评估分数由大到小的顺序对第一医生进行排序，以生成第二推荐问诊医生列表，并对列表中排序最先的第一医生设置推荐标签。
122.s24：将第二推荐问诊医生列表发送至用户终端，接收用户终端发送的第二问诊医生，并向第二问诊医生对应的第三医生终端发送问诊连接请求。
123.s25：接收第三医生终端发送的允许连接信息后，开启用户终端与第三医生终端之间的线上通信连接，以开启第二问诊医生对应的第二问诊过程。
124.s26：在接收到第三医生终端发送的问诊结束信息之后，根据第二问诊医生、第二问诊医生对应的问诊医生信息、第二问诊过程对应的问诊时长、问诊请求中的问诊问题中的一种或多种，生成第二问诊过程对应的第二线上问诊记录。
125.相应的，上述步骤s18根据第一线上问诊记录，生成用户对应的线上问诊记录，可以包括：
126.根据第一线上问诊记录以及第二线上问诊记录，生成用户对应的线上问诊记录。
127.在本实施方式中，生成第二线上问诊记录时，首先可以判断第二问诊过程对应的问诊时长是否超过时长阈值，只有在超过超过时长阈值时，才认为此次问诊过程是有效的，可以生成第二线上问诊记录。
128.在本实施方式中，若在第二问诊过程之后，用户再次通过用户终端向服务器发送更换医生请求，具体的处理过程可以参考上述步骤s21-s26，在此不做赘述。
129.在本实施方式中，在线上问诊过程中，用户可能在一次线上问诊通话中通过“更换问诊医生”功能更换问诊医生，从而进行多次问诊。因此，在第一次问诊结束(接收到第二医生终端发送的问诊结束信息)，并接收到用户终端发送的更换医生请求之后，可以重新对初步筛选出能够解决问诊问题的第一医生进行二次筛选和评估，确定新的第二推荐问诊医生列表，而不是重新展示第一推荐问诊医生列表。通过这样的设置，可以提高更换问诊医生时推荐的准确性和匹配性，从而提升用户体验。进一步的，若一次线上问诊通话中存在多次问诊，可以根据每一问诊过程分别生成线上问诊记录，并将全部线上问诊记录作为用户对应
的线上问诊记录，在保证记录独立性的前提下，保证记录的全面性和准确性。
130.s102：当问诊医生为多个时，判断问诊问题的数目是否为一个。
131.在本实施例中，当问诊医生为多个时，可以通过判断问诊问题的数目是否为一个的方式，来确定是否存在“一病多问”的情形。
132.在一个可能的实施方式中，当问诊问题的数目为多个时，该方法还可以包括：
133.s31：判断问诊问题中是否存在对应多个问诊医生的目标问诊问题。
134.s32：若是，则针对目标问诊问题，执行根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表的步骤；针对问诊问题中除目标问诊问题之外的其他问诊问题，分别向各自对应的问诊医生的医生终端发送开方提示信息。
135.s33：若否，则对以每一问诊问题，分别向各自对应的问诊医生的医生终端发送开方提示信息。
136.在本实施方式中，若问诊问题的数目为多个，说明用户就多个症状进行了问诊。虽然用户一般会在就一个症状进行问诊之后即开具处方，但是也可能存在全部症状问诊结束之后再开具处方的情形。因此，当问诊问题的数目为多个时，首先需要判断这些问诊问题中是否存在对应多个问诊医生的目标问诊问题，即是否存在“一病多问”的问诊问题。若不存在，可以分别向各自对应的问诊医生的医生终端发送开方提示信息即可，若存在，则目标问诊问题开方医生的确定可以按照下述步骤s103进行处理。通过这样的设置，可以解决问诊问题和问诊医生多对多的情形时开方医生的确定问题，进一步避免多张处方的开具给用户选择上带来的困难。
137.s103：若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端。
138.在本实施例中，
139.在一个可能的实施方式中，上述步骤s103中的根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，可以包括：
140.s1031：判断用户是否存在对应的开方偏好，开方偏好包括问诊时长偏好和医生职称偏好中的一种或多种。
141.s1032：若是，则获取每一问诊医生对应的问诊时长和/或医生职称；按照问诊时长由长到短的顺序、和/或医生职称由高到低的顺序，对问诊医生进行排序，以生成推荐开方医生列表，并对列表中排序最先的问诊医生设置推荐标签。
142.s1033：若否，则利用预设的评估指标对每一问诊医生进行评估，以确定每一问诊医生对应的评估分数；按照评估分数由大到小的顺序，对问诊医生进行排序，以生成推荐开方医生列表，并对列表中排序最先的问诊医生设置推荐标签。
143.在本实施方式中，问诊时长偏好可以是用户对问诊时长的偏好，例如偏好问诊时长最长的。医生职称偏好可以是用户对医生职称的偏好，例如偏好高职称医生(主任医师等)。
144.在本实施方式中，若用户的开方偏好同时选择问诊时长偏好和医生职称偏好，则在生成推荐开方医生列表，可以优先以问诊时长排序，若问诊时长相同，再以医生职称排序。
145.在本实施方式中，确定问诊医生之后，可以首先判断用户是否存在对应的开方偏
好，若存在，则利用用户设置的开方偏好对问诊医生进行排序以生成推荐开方医生列表；若不存在，则利用服务器中预设的评估指标对问诊医生进行排序以生成推荐开方医生列表。通过这样的设置，可以提高开方医生推荐的准确性和匹配性，通过在推荐开方医生列表中设置推荐标签，可以为用户推荐最合适的开方医生，并且推荐开方医生列表的存在还保留了用户选择的自主性，进一步提升用户体验。
146.在一个可能的实施方式中，评估指标可以包括问诊时长、医生职称、医生好评率、问诊问题与问诊医生所处科室的匹配度、医生问诊数目、医生文章发表数目中的一种或多种。
147.在本实施方式中，本领域技术人员可以预先设置每一评估指标对应的评估分数，例如主任医师10分，副主任医师5分，普通医生0分等。在确定某医生的评估指标之后，根据预设的对应关系即可确定各自对应的评估分数，所有评估指标的评估分数的加和，即为该医生对应的评估分数。
148.在本实施方式中，根据问诊时长、医生职称、医生好评率、问诊问题与问诊医生所处科室的匹配度、医生问诊数目、医生文章发表数目，即可全面而又准确的对医生的问诊进行评估，保证了根据上述评估指标对医生进行排序和推荐的准确性。
149.s104：接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息。
150.在本实施例中，用户确定开方医生之后，即可向开方医生对应的第一医生终端发送开方提示信息，以提示开方医生开具处方，其他问诊医生不再开具处方，即在问诊过程中，只有一个医生开具处方。
151.s105：接收第一医生终端发送的处方信息，并将处方信息发送至用户终端。
152.在本实施例中，在接收到开方医生开具的处方信息之后，可以将处方信息发送至用户终端，用户可以接收到唯一处方。
153.在本实施例中，在接收到用户终端输入的问诊开方请求之后，可以通过确定用户终端的用户对应的问诊问题以及问诊医生，来判断该问诊开方请求是否存在“一病多问”的情形。当确定存在该情形，即一个问诊问题对应多个问诊医生时，可以对用户对应的问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端，从而为用户推荐开方医生。在接收到用户终端发送的开方医生之后，可以仅向开方医生对应的第一医生终端发送开方提示信息。通过这样的设置，可以在用户线上问诊过程中出现“一病多问”情形，即一个问诊问题对应多个问诊医生时，仅使得多个问诊医生中的一位开具处方，而不是全部问诊医生均开具处方，不仅可以避免多张处方的开具给用户选择上带来的困难，还能够避免多位医生针对同一病症开具处方造成的医疗资源的浪费，提升了医生的工作能效。进一步的，通过根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，可以提高开方医生推荐的准确性和匹配性，并且也保证了用户选择的自由性，用户可以自主选择开方医生，提升了用户使用体验。
154.实施例二
155.图4是本技术另一实施例提供的医疗服务处理方法的流程图，本实施例以执行主体为用户终端对该医疗服务处理方法进行说明。如图3所示，该医疗服务处理方法可以包括以下步骤：
156.s201：向服务器发送问诊开方请求，问诊开方请求用于指示服务器确定用户终端的用户对应的问诊问题以及问诊医生，并在问诊医生为多个时，判断问诊问题的数目是否为一个，若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端。
157.在本实施例中，用户可以通过用户终端向服务器发送问诊开方请求，服务器接收到问诊开方请求之后，确定推荐开方医生列表的具体实施方式可以参照上述实施例一中的s101-s103，在此不做赘述。
158.s202：接收并显示服务器发送的推荐开方医生列表，在接收到用户选择的开方医生之后，将开方医生发送至服务器，以便服务器接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息，并接收第一医生终端发送的处方信息，并将处方信息发送至用户终端。
159.在本实施例中，用户终端接收到推荐开方医生列表之后，可以在显示界面显示该推荐开方医生列表以供用户选择，并在用户选择之后，将选择出的开方医生发送至服务器。服务器接收到开方医生后，确定开方信息的具体实施方式可以参照上述实施例一中的s104-s105，在此不做赘述。
160.s203：接收并显示服务器发送的处方信息。
161.在本实施例中，用户终端接收到处方信息之后，可以在显示界面显示该处方信息，以便用户根据处方信息购买相应的药物。
162.下面以一个具体的实施例对本技术的医疗服务处理方法进行阐述。
163.实施例三
164.在一个具体的实施例中，某用户通过某医疗平台进行了线上问诊过程，问诊结束之后想要得到医生开具的处方，具体的医疗服务处理过程如下：
165.第一步，问诊结束之后，用户通过用户终端向服务器发送问诊开方请求。
166.第二步，服务器接收到用户终端输入的问诊开方请求之后，根据用户最近一次的线上问诊记录，确定用户终端的用户对应的问诊问题以及问诊医生。
167.第三步，当问诊医生为多个时，服务器判断问诊问题的数目为一个。
168.第四步，服务器根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端。
169.第五步，用户终端在显示界面显示该推荐开方医生列表以供用户选择，并在用户选择之后，将选择出的开方医生发送至服务器。
170.第六步，服务器接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息。
171.第七步，第一医生终端接收并显示开方提示信息，以便开方医生接收到之后开具处方，并将处方信息上传至服务器。
172.第八步，服务器接收第一医生终端发送的处方信息，并将处方信息发送至用户终端，用户根据用户终端显示的处方信息购买相应的药物。
173.图5为本技术一实施例的服务器的结构示意图，如图5所示，该服务器包括：接收模块51，用于接收用户终端输入的问诊开方请求，确定用户终端的用户对应的问诊问题以及问诊医生；第一处理模块52，用于在问诊医生为多个时，判断问诊问题的数目是否为一个；
若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端；接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息；接收第一医生终端发送的处方信息，并将处方信息发送至用户终端。一个实施方式中，服务器具体实现功能的描述可以参见实施例一中的步骤s101-s105，在此不做赘述。
174.图6为本技术一实施例的用户终端的结构示意图，如图6所示，该用户终端包括：发送模块61，用于向服务器发送问诊开方请求，问诊开方请求用于指示服务器确定用户终端的用户对应的问诊问题以及问诊医生，当问诊医生为多个时，判断问诊问题的数目是否为一个，若是，则根据预设的评估指标或者用户对应的开方偏好，对问诊医生进行排序，以生成推荐开方医生列表，并将推荐开方医生列表发送至用户终端；第二处理模块62，用于接收并显示服务器发送的推荐开方医生列表，在接收到用户选择的开方医生之后，将开方医生发送至服务器，以便服务器接收用户终端发送的开方医生，并向开方医生对应的第一医生终端发送开方提示信息，并接收第一医生终端发送的处方信息，并将处方信息发送至用户终端；接收并显示服务器发送的处方信息。一个实施方式中，用户终端具体实现功能的描述可以参见实施例二中的步骤s201-s203，在此不做赘述。
175.图7为本技术另一实施例的服务器的结构示意图，如图7所示，该服务器包括：处理器101，以及与处理器101通信连接的存储器102；存储器102存储计算机执行指令；处理器101执行存储器102存储的计算机执行指令，实现上述实施例一中的医疗服务处理方法的步骤。
176.在上述服务器中，存储器102和处理器101之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可以通过一条或者多条通信总线或信号线实现电性连接，如可以通过总线连接。存储器102中存储有实现数据访问控制方法的计算机执行指令，包括至少一个可以软件或固件的形式存储于存储器102中的软件功能模块，处理器101通过运行存储在存储器102内的软件程序以及模块，从而执行各种功能应用以及数据处理。
177.存储器102可以是，但不限于，随机存取存储器(random access memory，简称：ram)，只读存储器(read only memory，简称：rom)，可编程只读存储器(programmableread-only memory，简称：prom)，可擦除只读存储器(erasable programmable read-onlymemory，简称：eprom)，电可擦除只读存储器(electric erasable programmable read-only memory，简称：eeprom)等。其中，存储器102用于存储程序，处理器101在接收到执行指令后，执行程序。进一步地，上述存储器102内的软件程序以及模块还可包括操作系统，其可包括各种用于管理系统任务(例如内存管理、存储设备控制、电源管理等)的软件组件和/或驱动，并可与各种硬件或软件组件相互通信，从而提供其他软件组件的运行环境。
178.处理器101可以是一种集成电路芯片，具有信号的处理能力。上述的处理器101可以是通用处理器，包括中央处理器(central processing unit，简称：cpu)、网络处理器(network processor，简称：np)等。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
179.图8为本技术另一实施例的用户终端的结构示意图，如图8所示，该用户终端包括：处理器201，以及与处理器201通信连接的存储器202；存储器202存储计算机执行指令；处理
器201执行存储器202存储的计算机执行指令，实现上述实施例二中的医疗服务处理方法的步骤。
180.在上述用户终端中，存储器202和处理器201之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可以通过一条或者多条通信总线或信号线实现电性连接，如可以通过总线连接。存储器202中存储有实现数据访问控制方法的计算机执行指令，包括至少一个可以软件或固件的形式存储于存储器202中的软件功能模块，处理器201通过运行存储在存储器202内的软件程序以及模块，从而执行各种功能应用以及数据处理。
181.存储器202可以是，但不限于，随机存取存储器(random access memory，简称：ram)，只读存储器(read only memory，简称：rom)，可编程只读存储器(programmableread-only memory，简称：prom)，可擦除只读存储器(erasable programmable read-onlymemory，简称：eprom)，电可擦除只读存储器(electric erasable programmable read-only memory，简称：eeprom)等。其中，存储器202用于存储程序，处理器201在接收到执行指令后，执行程序。进一步地，上述存储器202内的软件程序以及模块还可包括操作系统，其可包括各种用于管理系统任务(例如内存管理、存储设备控制、电源管理等)的软件组件和/或驱动，并可与各种硬件或软件组件相互通信，从而提供其他软件组件的运行环境。
182.处理器201可以是一种集成电路芯片，具有信号的处理能力。上述的处理器201可以是通用处理器，包括中央处理器(central processing unit，简称：cpu)、网络处理器(network processor，简称：np)等。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
183.本技术的一实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现本技术上述实施例一中各方法的步骤。
184.本技术的一实施例还提供了另一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现本技术上述实施例二中各方法的步骤。
185.本技术的一实施例还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本技术实施例一中各方法的步骤。
186.本技术的一实施例还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本技术实施例二中各方法的步骤。
187.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由所附的权利要求书指出。
188.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。