远程医疗系统及远程医疗的医生资源分配方法、存储介质与流程

本公开涉及计算机技术领域，具体而言，涉及一种远程医疗系统、一种远程医疗的医生资源分配方法、电子设备以及计算机可读存储介质。

背景技术：

计算机及网络技术的发展与普及为人们的生产生活带来了极大的便利，让人们可以足不出户地享受到各种服务，视频问诊便是其中的一种。

为了满足用户的视频问诊等远程医疗需求，需要安排医生进行接诊。然而，由于各个医生擅长领域不一样，处理不同患者所需的时间也大不相同。现有的远程医疗服务无法合理地对医生进行分配，存在医疗咨询的数量与医生的数量供求不对应，以及用户无法匹配到合适的医生等问题，从而造成资源浪费或问诊效率低等问题。

因此需要提供一种远程医疗系统，通过该系统可以合理地安排值班医生的数量，并基于全局最优的思想为用户匹配到合适的医生，提高了医疗咨询请求的处理效率，节约了医疗资源。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开实施例的目的在于提供一种远程医疗系统、一种远程医疗的医生资源分配方法、电子设备以及计算机可读存储介质，通过上述远程医疗系统可以提高医疗咨询请求的处理效率，节约医疗资源。

根据本公开的第一方面，提供一种远程医疗系统，包括：

第一终端，用于接收用户的症状描述、实时体征数据及医疗咨询请求，并将所述症状描述、所述实时体征数据以及所述医疗咨询请求上传至服务端；

第二终端，用于展示所述用户的历史咨询数据及所述实时体征数据，接收医生输入的诊断结果并发送至服务端，以及接收所述医生的预约回访操作；

服务端，所述服务端包括：

画像模块，用于依据各所述用户及各所述医生的基本信息，以及所述历史咨询数据得到对应的医生画像数据及用户画像数据；

预测模块，用于依据各所述用户的所述实时体征数据、所述历史咨询数据以及环境数据预测第一预设时间段内所述医疗咨询请求的数量；

分配模块，用于依据所述医生画像数据、所述用户画像数据以及所述预测模块得到的预测数据实现所述医生的分配，以使得所述第一终端及所述第二终端依据分配结果实现医疗咨询服务。

在本公开的一种示例性实施例中，所述第一终端包括数据采集模块、请求响应模块以及结果接收模块，其中：

所述数据采集模块用于通过物联网设备采集所述用户的所述实时体征数据，并上传至服务端；

所述请求响应模块用于接收所述用户的医疗咨询请求及所述症状描述，并将所述医疗咨询请求及所述症状描述上传至所述服务端；

所述结果接收模块用于接收所述诊断结果及回拨请求。

在本公开的一种示例性实施例中，所述第一终端还包括医生选择模块：

所述医生选择模块用于接收所述分配模块发送的候选医生列表，并响应于所述用户对于所述候选医生列表的选择操作，将所述选择操作的结果上传至所述服务器，以通过所述服务器将所述医疗咨询请求发送至对应的所述第二终端。

在本公开的一种示例性实施例中，所述第二终端包括接收与展示模块、诊断模块及发送模块，且设置有交互界面，其中：

所述接收与展示模块用于接收所述服务端转发的所述医疗咨询请求，并响应于所述医疗咨询请求，将所述用户的所述症状描述、所述历史咨询数据及所述实时体征数据显示在所述交互界面中；

所述诊断模块用于接收所述医生输入的诊断结果；

所述发送模块用于将所述诊断结果发送至所述服务端，以通过所述服务端完成所述医疗咨询服务。

在本公开的一种示例性实施例中，所述第二终端还包括回拨模块；

所述回拨模块用于向预约回拨列表中的所述用户进行回访操作；其中，所述预约回拨列表由所述服务端依据所述症状描述及所述用户的用户等级确定。

在本公开的一种示例性实施例中，所述画像模块包括医生画像单元及用户画像单元，其中：

所述医生画像单元用于依据所述医生的基本信息及所述历史咨询数据，得到所述医生画像数据；

所述用户画像单元用于依据所述用户的基本信息及所述历史咨询数据，得到所述用户画像数据。

在本公开的一种示例性实施例中，所述预测模块包括分析单元、预测单元及排班单元，其中：

所述分析单元用于依据所述实时体征数据分析得到所述用户的身体状况；

所述预测单元用于依据所述用户的身体状况，所述历史咨询数据、以及所述环境数据预测第一预设时间段内所述医疗咨询请求的数量，所述环境数据包括天气状况；

所述排班单元用于依据所述预测单元得到的预测数据，以及各所述医生的当前状态安排所述第一预设时间段的医生值班。

在本公开的一种示例性实施例中，所述分配模块包括分析单元、匹配单元及连接单元，其中：

所述分析单元用于基于预设的供需预测模型及所述预测模块得到的医生排班结果，分析得到第二预设时间段内新增的医疗咨询请求及空闲医生的数量，以及当前的医疗咨询请求及空闲医生的数量；

所述匹配单元用于依据所述新增的医疗咨询请求及空闲医生的数量，所述当前的医疗咨询请求及空闲医生的数量，所述医生画像数据以及所述用户画像数据对为各所述用户匹配所述医生；

所述连接单元用于将依据所述匹配单元得到的匹配结果，将所述医疗咨询请求发送至匹配到的所述医生对应的所述第二终端。

在本公开的一种示例性实施例中，所述分配模块还包括返回单元：

所述返回单元用于将匹配到的所述候选医生列表发送至所述第一终端，以使所述用户选择建立连接的所述医生。

根据本公开的第二方面，提供一种远程医疗的医生资源分配方法，应用于上述远程医疗系统中的服务端，包括：

接收第一终端上传的用户的症状描述、实时体征数据以及医疗咨询请求，并基于所述实时体征数据分析得到所述用户的身体状况；

依据各所述用户及各所述医生的基本信息，以及所述历史咨询数据得到对应的医生画像数据及用户画像数据；

基于所述用户的身体状况、历史咨询数据以及环境数据预测第一预设时间段内所述医疗咨询请求的数量，并基于预测数据安排所述第一预设时间段的医生值班；

基于预设的供需预测模型及所述预测模块得到的医生排班结果，分析得到第二预设时间段内新增的医疗咨询请求及空闲医生的数量，以及当前的医疗咨询请求及空闲医生的数量；

依据所述新增的医疗咨询请求及空闲医生的数量，所述当前的医疗咨询请求及空闲医生的数量，所述医生画像数据以及所述用户画像数据对为各所述用户匹配所述医生。

根据本公开的第三方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述医疗咨询方法。

根据本公开的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述医疗咨询方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

本公开示例性实施例提供了一种远程医疗系统，该远程医疗系统包括第一终端、第二终端及服务端。其中，第一终端用于接收用户的症状描述、实时体征数据及医疗咨询请求，并将接收到的上述症状描述、实时体征数据以及医疗咨询请求上传至服务端；第二终端用于展示用户的历史咨询数据及实时体征数据，接收医生输入的诊断结果并发送至服务端，以及接收医生的预约回访操作；服务端包括画像模块、预测模块以及分配模块。其中，画像模块用于依据各用户及各医生的基本信息，以及历史咨询数据得到对应的医生画像数据及用户画像数据；预测模块用于依据各用户的实时体征数据、历史咨询数据以及环境数据预测第一预设时间段内医疗咨询请求的数量；分配模块，用于依据上述医生画像数据、用户画像数据以及预测模块得到的预测数据实现医生的分配，以使得上述第一终端及第二终端依据分配结果实现医疗咨询服务。一方面，本示例实施方式提供的远程医疗系统可以通过第一终端采集用户的实时体征数据，通过各用户的实时体征数据，结合历史咨询数据以及环境数据，可以对预设时间段内的医疗咨询数量进行预测，从而可以依据该预测量合理地安排医生值班，实现医生与用户的供求平衡。既可以保证咨询量多时，用户的医疗咨询请求得到快速及时处理，同时，还可以在咨询量少时，减少值班医生的数量，降低人力成本，节约医疗资源。另一方面，上述远程医疗系统的服务端还可以通过画像模块得到医生及用户的画像数据，从而可以依据医生画像数据及用户画像数据，并结合预测模块的预测结果，在保证全局最优的基础上，为每位用户匹配合适的医生提供医疗服务。再一方面，在上述远程医疗系统中，医生还可以通过第二终端进行预约回访操作，也即，在咨询量较大时，可以对其中一些用户进行预约回访。此外，也可以通过预测模块的预测结果对咨询量进行预判，并进行紧急排班，从而可以很好地应对紧急突发状况。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了可以应用本公开实施例的一种远程医疗系统的系统架构示意图；

图2示出了根据本公开的一个实施例的生成医生画像数据过程的流程图；

图3示出了根据本公开的一个实施例的生成用户画像数据过程的流程图；

图4示出了根据本公开的一个实施例的医生值班安排过程的流程图；

图5示出了根据本公开的一个实施例的医生与用户匹配过程的流程图；

图6示出了可以应用本公开实施例的一种远程医疗的医生资源分配方法的流程图；

图7示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

计算机及网络技术的发展与普及为人们的生产生活带来了极大的便利，让人们可以足不出户地享受到各种服务，视频问诊便是其中的一种。

然而，由于各个医生擅长领域不一样，处理不同患者所需的时间也大不相同。现有的视频问诊服务无法合理地对医生进行分配，存在医疗咨询的数量与医生的数量供求不对应，以及用户无法匹配到合适的医生等问题，从而造成资源浪费或问诊效率低等问题。

为了解决上述问题，本示例实施方式首先提供了一种远程医疗系统，参考图1所示，示出了本示例性实施方式所提供的远程医疗系统的架构示意图，如图所示，系统架构100可以包括第一终端110、第二终端120、以及服务端130。其中：

第一终端110可以用于接收用户的症状描述、实时体征数据及医疗咨询请求，并将上述症状描述、实时体征数据以及医疗咨询请求上传至服务端；

第二终端120可以用于展示用户的历史咨询数据及实时体征数据，接收医生输入的诊断结果并发送至服务端，以及接收医生的预约回访操作；

服务端130可以包括画像模块131、预测模块132以及分配模块133。其中，

画像模块131可以用于依据各用户及各医生的基本信息，以及历史咨询数据得到对应的医生画像数据及用户画像数据；

预测模块132可以用于依据各用户的实时体征数据、历史咨询数据以及环境数据预测第一预设时间段内医疗咨询请求的数量；

分配模块133可以用于依据医生画像数据、用户画像数据以及预测模块得到的预测数据实现医生的分配，以使上述第一终端及上述第二终端依据分配结果实现医疗咨询服务。

在本公开示例实施方式提供的远程医疗系统中，一方面，本示例实施方式提供的远程医疗系统可以通过第一终端采集用户的实时体征数据，通过各用户的实时体征数据，结合历史咨询数据以及环境数据，可以对预设时间段内的医疗咨询数量进行预测，从而可以依据该预测量合理地安排医生值班，实现医生与用户的供求平衡。既可以保证咨询量多时，用户的医疗咨询请求得到快速及时处理，同时，还可以在咨询量少时，减少值班医生的数量，降低人力成本，节约医疗资源。另一方面，上述远程医疗系统的服务端还可以通过画像模块得到医生及用户的画像数据，从而可以依据医生画像数据及用户画像数据，并结合预测模块的预测结果，在保证全局最优的基础上，为每位用户匹配合适的医生提供医疗服务。再一方面，在上述远程医疗系统中，医生还可以通过第二终端进行预约回访操作，也即，在咨询量较大时，可以对其中一些用户进行预约回访。此外，也可以通过预测模块的预测结果对咨询量进行预判，并进行紧急排班，从而可以很好地应对紧急突发状况。

下面，对上述远程医疗系统的细节进行进一步的说明：

在本示例实施方式中，上述第一终端110可以被配置为用户端，该第一终端可以包括数据采集模块、请求响应模块以及结果接收模块。

具体地，上述数据采集模块可以用于通过物联网设备采集上述用户的实时体征数据并上传至服务端。通过该数据采集模块可以对用户的身体状态进行实时监测，得到用户的实时体征数据，基于该实时体征数据可以提高做好医生的安排，提高医疗咨询请求的处理效率，改善用户体验。举例而言，该数据采集过程可以由第一终端启动上述物联网设备，并采集用户的体征数据；也可以在医疗咨询过程中的任一时间，由用户触发启动，本示例实施方式对此不做特殊限定。

其中，上述物联网设备可以为智能手环。例如，可以为每位用户配备一个智能手环，通过该智能手环实时采集用户的体征数据，并在用户发起医疗咨询请求时，将采集到的用户的体征数据与上述医疗咨询请求一起上传至服务端。此外，上述物联网设备也可以为可以采集用户实时体征数据的其他设备，本示例实施方式对此不做特殊限定。

上述请求响应模块可以用于接收用户的医疗咨询请求及症状描述，并将医疗咨询请求及症状描述上传至服务端。其中，上述医疗咨询请求为用户发起的寻求医疗诊断或建议的远程请求。例如，该医疗咨询请求可以为视频请求，用户可以通过第一终端发起视频请求至服务端，服务端在接收到该视频请求后，为该用户匹配合适的医生，并建立用户对应的第一终端及医生对应的第二终端之间的视频连接，以实现医生通过该视频连接为用户提供医疗服务。此外，上述医疗咨询请求还可以为语音请求等其他远程请求，本示例实施方式对此不做特殊限定。

在本示例实施方式中，为了更好地为用户匹配医生以及提高医疗服务的效率，用户在通过第一终端发送医疗咨询请求时，还需要输入症状描述。上述症状描述指用户的身体状况的描述，举例而言，该症状描述可以为疾病的临床症状表现，如发烧、咳嗽等，此外，该症状描述还可以为其他符合上述定义的身体状态的表述，本示例实施方式对此不做特殊限定。

上述结果接收模块可以用于接收诊断结果及回拨请求。例如，当系统中同时间段的医疗咨询请求过多时，服务端可以依据实际情况筛选出一部分用户加入预约回拨列表，医生可以在当前时间段后的预约时间对预约回拨列表中的用户进行回拨，用户通过该结果接收模块接收来自医生的回拨请求。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

此外，上述结果接收模块还可以用于接收诊断结果。该诊断结果可以为医生基于采集到的用户实时体征数据以及用户输入的症状描述得到的病症判断及医疗建议，也可以为其他改善用户健康状况的建议，本示例实施方式对此不做特殊限定。举例而言，该结果接收模块可以为一显示设备，将上述诊断结果展示给用户，也可以为语音设备，以供医生在医疗咨询期间将上述诊断结果实时地告知用户。此外，上述结果接收模块还可以通过其他方式将上述诊断结果告知用户，这都属于本示例实施方式的保护范畴。

在本示例实施方式中，服务端可以通过匹配模块为用户合理地分配医生。其中，针对于每一位用户，匹配模块匹配的结果可以为一位医生，此时，服务端可以直接将用户的上述医疗咨询请求转发至匹配到的该医生。此外，匹配模块还可以为一位用户匹配到多名医生以供用户选择，这种情景下，服务端将包含多名医生的候选医生列表返回至上述用户对应的第一终端，以供用户自行选择咨询的医生。

具体地，在上述过程中，上述第一终端还可以包括医生选择模块，该医生选择模块可以用于接收服务端发送的候选医生列表，并响应于上述用户对于接收到的候选医生列表的选择操作，将选择操作的结果上传至服务器，以通过服务器将医疗咨询请求发送至对应的第二终端。

例如，服务端在得到上述候选医生列表后，可以将该候选医生列表发送至上述第一终端，并显示在该第一终端的显示界面中。用户可以通过点击显示界面中候选医生列表中的意向医生，并将该选择结果上传至服务端来得到该意向医生的医疗服务。需要说明的是，上述场景只是一种示例性说明，并不对本示例实施方式的保护范畴起限定作用。例如，用户也可以通过长按、语音控制等其他的选择操作在上述医生候选列表中选择自己的意向医生也属于本示例实施方式的保护范畴。

在本示例实施方式中，上述第二终端120可以被配置为医生端，该第二终端可以包括接收与展示模块、诊断模块及发送模块。同时，为了使医生直观便捷地与用户端及服务端进行交互，以完成医疗服务，该第二终端还设置有交互界面，该交互界面可以为医生提供便捷的工作操作界面。

具体地，上述接收与展示模块可以用于接收服务端转发的医疗咨询请求，并响应于该医疗咨询请求，将用户的症状描述、历史咨询数据及实时体征数据显示在上述交互界面中。例如，服务端在通过上述分配模块实现系统中的用户及医生的最佳匹配后，可以将各用户发起的医疗咨询请求发送至所匹配到的各医生对应的第二终端。第二终端通过上述接收与展示模块接收服务端发送的医疗咨询请求，以及发起该医疗咨询请求的用户输入的症状描述、历史咨询数据以及实时体征数据，并将上述症状描述、历史咨询数据及实时体征数据显示在上述交互界面中，以便医生查看并据此为用户提供医疗服务。其中，上述历史咨询数据可以包括用户的历次就诊记录及健康档案信息，通过该历史咨询数据可以使医生快速地了解用户的病史，降低误诊的概率，提高医疗服务的质量及效率。

上述诊断模块可以用于接收医生输入的诊断结果。在本示例实施方式中，医生在基于上述历史咨询数据、症状描述及实时体征数据得到诊断结果后，医生可以将得到的诊断结果输入该诊断模块。举例而言，该诊断模块可以包含有输入控件，如输入窗口，医生可以将诊断结果输入该窗口。其中，上述诊断结果可以包括疾病判断、治疗建议及用药建议等信息，本示例实施方式对此不做特殊限定。

上述发送模块可以用于将诊断结果发送至服务端，以通过服务端完成医疗咨询服务。例如，在医生将上述输入结果输入至诊断模块后，该发送模块可以将诊断结果上传至服务端，在由服务端发送至用户端。此外，该发送模块也可以将诊断结果直接发送至用户端，如，当上述医疗咨询请求为视频或电话请求时，该发送模块可以为语音采集及发送设备，相应地，可以在用户端设置语音采集及接收设备，通过建立医生端及用户端之间的语音连接，使医生将上述诊断结果实时地告知用户。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限，该发送模块也可以通过其他的方式将诊断结果发送至对应的用户。

上述第二终端还可以包括回拨模块。该回拨模块可以用于向预约回拨列表中的用户进行回访操作；其中，预约回拨列表由服务端依据症状描述及用户的用户等级确定。在本示例实施方式中，在某一时间段内发起医疗咨询请求的用户数量过多时，系统会依据用户的症状描述及用户等级自动筛选出部分客户，放入预约回拨列表。在预约时间内，医生可以通过该回拨模块主动回拨预约回拨列表中的用户，这样既可以均衡用户流量，又能提高用户满意度。此外，该回拨模块也可以用于对用户的病情进行回访了解。例如，当分析得到某一用户的病情需要进行跟踪了解或指导，也可以将该用户加入上述预约回拨列表，并依据实际情况及病情发展状况，由医生在预约好的时间主要向用户进行回拨，以提供医疗服务。

在本示例实施方式中，上述远程医疗系统的服务端130除了包括上述画像模块、预测模块及分配模块外，优选的，还可以包括数据信息库，该数据信息库可以用于存储所有用户的健康档案及历史咨询信息，以及用户及医生的基本信息等数据，该数据库中的数据信息可以用于诊断过程中获取某一用户的相关信息，还可以用于生成用户画像数据及医生画像数据等，这都属于本示例实施方式的保护范畴。

具体地，上述画像模块可以包括医生画像单元及用户画像单元。其中，上述医生画像单元可以用于依据医生的基本信息及历史咨询数据，得到医生画像数据；上述用户画像单元可以用于依据用户的基本信息及历史咨询数据，得到用户画像数据。

上述医生的基本信息可以包括医生的姓名、年龄、性别、身体状况、主攻领域及从医年限等用于表示医生身份及专业的信息。举例而言，上述医生画像单元可以通过执行如图2所示的方法得到医生画像数据，如图所示，可以包括以下步骤：

在步骤s210中，获取历史咨询数据。

在该步骤中，服务端可以获取系统中的历史咨询数据。例如，当系统第一次启动时，服务端可以从上述数据信息库中获取系统当前的全部历史咨询数据。此后，可以定期获取数据信息库中新增的历史咨询数据，以便于对医生画像数据及用户画像数据进行实时更新。此外，优选地，该步骤还可以获取各医生的基本信息，以得到更加精准的医生画像数据。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在步骤s220中，依据上述历史咨询数据得到医生的问诊情况。

在该步骤中，在得到上述历史咨询数据后，可以基于该历史咨询数据得到医生的问诊情况。例如，可以从上述历史咨询数据中抽取医生针对不同病症所需的处理时间及处理效果。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在步骤s230中，依据上述问诊情况分析得到医生的擅长领域。

在该步骤中，依据步骤s220通过历史咨询数据得到的问诊情况分析医生的擅长领域。例如，可以将上述处理时间及处理效果依据一定的权重规则得到一个评分，依据该评分得到各个医生擅长处理的病症及领域。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在步骤s231中，接收医生输入的擅长标签。

在步骤s240中，得到医生画像数据。

在该步骤中，可以结合上述步骤s230依据历史咨询数据分析得到的各医生擅长处理的领域，以及步骤s231中接收到的医生自己输入的擅长标签，综合分析得到医生的擅长领域及特点。基于综合分析的结果及医生的基本信息得到各医生对应的医生画像数据。

上述用户的基本信息可以包括用户的姓名、年龄、性别、职业及病史等用于表示用户身份及与身体状况相关的信息。举例而言，上述用户画像单元可以通过执行如图3所示的方法得到用户画像数据，如图所示，可以包括以下步骤：

在步骤s310中，获取历史咨询数据。

在该步骤中，可以获取用户对应的历史咨询数据。举例而言，该步骤可以获取系统当前全部或更新的历史咨询数据，以便后续依据该历史咨询数据生成用户画像数据。此外，获取历史咨询数据的过程还可以为：例如，可以从系统当前的医疗咨询请求中获取对应用户的身份信息，如用户电话、用户ip地址等，并依据获取到的身份信息在上述数据信息库中获取对应各用户的历史咨询数据。进一步地，还可以在数据信息库中查询到用户的基本信息。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在步骤s320中，获取用户的健康档案。

在该步骤中，在获取到上述历史咨询数据后，还可以从该历史咨询数据中抽取用户的健康档案。上述历史咨询数据可以包括用户的历史咨询记录、问诊记录及健康档案等数据。

在步骤s330中，得到用户画像数据。

在该步骤中，基于得到的健康档案及用户的基本信息得到各用户对应的用户画像数据。

需要说明的是，上述场景只是一种示例性说明，上述医生画像单元及用户画像单元也可以通过其他方式得到医生画像数据及用户画像数据，这也属于本示例实施方式的保护范畴。

为了对医生值班进行合理的安排，避免在咨询量大时值班医生少，或在咨询量少时值班医生多带来的医疗资源浪费、处理不及时及服务质量下降等问题，服务端可以通过上述预测模块对一段时间内的医疗咨询请求的数量进行预测。具体地，该预测模块可以分析单元、预测单元及排班单元：

其中，上述分析单元可以用于依据实时体征数据分析得到用户的身体状况。例如，可以依据上述实时体征数据得到用户的心率、血压、体温等数据，依据这些数据，结合用户的历史咨询数据，得到用户实时的身体状况。

上述预测单元可以用于依据上述分析单元分析得到的用户的身体状况，以及历史咨询数据和环境数据预测第一预设时间段内医疗咨询请求的数量。其中，上述环境数据为可能会对病情或身体状况带来影响的客观环境因素，例如，该环境数据可以包括天气状况，也可以包括其他符合上述定义的环境因素，这都属于本示例实施方式保护范畴。上述第一预设时间可以依据实际情况确定，例如，当某一医院为一周一排班时，该第一预设时间可以设置为一周，视不同的情况，该第一预设时间还可以设置为其他时长，这也都属于本示例实施方式的保护范畴。

上述依据用户的身体状况，以及历史咨询数据和环境数据预测第一预设时间段内医疗咨询请求的数量的过程，举例而言，可以如下：依据用户当前的身体状况，结合历史咨询数据及环境数据，分析得在当前环境中可能出现病症以及已有病症加重的用户数量，以此推断会产生的医疗咨询请求的数量。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

上述排班单元可以用于依据上述预测单元得到的预测数据，以及各医生的当前状态安排上述第一预设时间段的医生值班。上述预测数据为预测单元预测到的第一预设时间段内医疗咨询请求的数量。上述各医生的当前状态可以包括医生的健康状况，近期值班情况以及性别特征等状态。

以上述第一预设时间段为一周为例，实现排班的过程可以如下：获取通过上述预测单元预测得到未来一周内的医疗咨询请求的数量，进而预估所需的各领域的医生数量，并结合各医生的当前状态，如前一天是否晚班(第二天不能早班)，是否请假、班次喜好、身份特征，男生还是女生、是否怀孕、是否有身体不舒服等，得到未来一周内医生的值班安排。

下面，结合图4所示的流程，对上述预测模块实现咨询量预测及医生排班的过程进行进一步的说明，如图所示，包括如下步骤：

在步骤s410中，获取用户的实时体征数据。

在该步骤中，该实时体征数据可以由上述第一终端上传。例如，可以通过第一终端对用户的体征数据进行实时监测，该实时监测可以通过为系统中的每一位用户配置智能手环实现，该智能手环可以对用户的体征数据进行实时监测并上传至服务端。

在步骤s411中，分析实时体征数据，得到用户的身体状况。

在该步骤中，基于得到的实时体征数据，对用户的身体状况进行分析。例如，可以基于用户的体温判断用户是否有发烧症状等，本示例实施方式对此不做特殊限定。

在步骤s420中，获取用户的历史咨询数据。

在该步骤中，获取用户的历史咨询数据。具体地，可以通过上述数据信息库查询得到。

在步骤s430中，获取环境数据。

在该步骤中，获取可能对用户的身体状况产生影响的环境数据。例如，第一预设时间内的天气状况。

在步骤s440中，预测服务量。

在该步骤中，可以根据分析出的用户身体状况，以及历史咨询数据和环境数据，基于大数据和机器学习技术，对第一预设时间内的服务量，也即医疗咨询请求的数量进行预测。例如，可以通过上述参数的历史数据训练得到一个预测模型，并通过该预测模型预测得到第一预设时间内的服务量。此外，还可以通过其他方式进行预测，本示例实施方式的保护范畴不以此为限。

在步骤s450中，获取业务约束条件。

在该步骤中，上述业务约束条件可以依据系统中医生的当前状态确定，如前一天是否晚班(第二天不能早班)，是否请假、班次喜好、身份特征，男生还是女生、是否怀孕、是否有身体不舒服等。

在步骤s460中，得到第一预设时间内的医生值班安排。

此外，在本示例实施方式中，在医生达到一定量以后，还是不能处理的情况下，我们会根据用户的症状描述和优先级，合理安排一些用户预约到后续不忙的一段时间，减少大面积排队。

同时，本示例实施方式做提供的远程医疗系统，还可以通过上述预测模块提前预测即将到来的大流量，智能地紧急加派医生值班。

最优分配的目的是让用户和最适合的医生匹配，这样医生处理的效率高，用户的满意度也会高。但是站在全局视角，同一时间，多位用户的最优医生可能是相同的。因此，为了提高接诊效率，尽量保证尽可能多的用户被接诊，上述分配模块采取了全局最优的分配策略，在保证全局最优的同时，为每位用户分配了最合适的医生。具体地，上述分配模块可以包括分析单元、匹配单元及连接单元：

其中，上述分析单元可以用于基于预设的供需预测模型及上述预测模块得到的医生排班结果，分析得到第二预设时间段内新增的医疗咨询请求及空闲医生的数量，以及当前的医疗咨询请求及空闲医生的数量。其中，上述供需预测模型为预先训练的表示医生与用户之间的供需关系的模型。上述第二预设时间可以为系统期望的用户等待时间，系统期望确保在该等待时间内，系统中的用户得到医疗服务或被加入预约回拨列表，也可以为依据实际情况设置的其他时长，本示例实施方式对此不做特殊限定。

上述匹配单元可以用于依据新增的医疗咨询请求及空闲医生的数量，当前的医疗咨询请求及空闲医生的数量，医生画像数据以及用户画像数据对为各用户匹配医生。

上述连接单元可以用户将依据匹配单元得到的匹配结果，将医疗咨询请求发送至匹配到的医生对应的第二终端。

下面，结合图5所示的流程，对上述分配模块实现用户与医生之间的最优分配的过程进行进一步的说明，如图所示，包括如下步骤：

在步骤s510中，接收用户的医疗咨询请求。

在步骤s520中，计算用户的等待数量。

在该步骤中，系统会查询当前等待接听的用户数量，并预测第二预设时间内会出现的用户数量。例如，以第二预设时间为30秒为例，该过程可以为查找当前等待接听的用户数量和预估出30秒内会拨进来的用户数量，得到用户的等待数量。

在步骤s530中，判断用户与医生的数量关系是否满足第一预设条件。

在该步骤中，上述第一预设条件用于依据用户与医生之间的数量关系限制系统中同一时间段的用户数量，确定将用户加入等待接听列表或预约回拨列表。若不满足上述第一预设条件，则跳转至步骤s531，若满足，则跳转至步骤s532。

以上述第一预设条件为用户等待数量是否超过医生数量的120％为例，上述过程可以为：判断用户等待数量和医生数量的关系，若是等待接听的用户等待数量没有超过医生数量的120％，则跳转至步骤s531，否则，则跳转至步骤s532。

在步骤s531中，进入等待接听列表。

在步骤s532中，判断用户是否满足第二预设条件。

在该步骤中，上述第二预设条件可以为用户等级得分是否达到预设阈值。其中，用户等级得分可以依据上述用户画像数据得到。例如，以上述预设阈值为10分为例，该步骤的过程可以为：依据用户画像数据判断用户的等级得分是否超过10分，若是，跳转至步骤s531；若否，则跳转至步骤s540。此外，上述第二预设条件还可以综合考虑其他因素，如用户病情的紧急程度等，这都属于本示例实施方式的保护范畴。

在步骤s540中，进入预约回拨列表。

在该步骤中，将步骤s530及步骤s532中经判断加入预约回拨列表的用户加入该列表，并依据实际情况为用户推荐一个预约时间段。

在步骤s550中，获取当前空闲医生列表及第二预设时间内新增的空闲医生列表。

在该步骤中，用户进入等待接听列表以后，系统会计算出当前空闲的医生数量和第二预设时间内会空闲出来的医生数量。以第二预设时间为30秒为例，系统会计算出当前空闲的医生数量和30秒内会空闲出来的医生数量。

在步骤s560中，获取需要匹配的医生列表及用户列表。

在该步骤中，系统会列出需要匹配的医生列表及用户列表，例如，列举出加入等待接听列表中的m个客户和当前空闲的以及第二预设时间内会空闲出来的n个医生。

在步骤s570中，依据上述用户画像数据及医生画像数据计算每个医生处理每个用户的医疗咨询请求所需的时间。

在步骤s580中，计算得到最优匹配列表。

在该步骤中，以上述场景为例，计算最优匹配列表的问题可以类比为计算m个客户，n个医生，每个医生处理某一个客户的时长为x，怎么得到最优解的背包问题。举例而言，可以模拟退火算法，得到该问题的最优解。

在步骤s590中，依据匹配单元得到的匹配结果将用户的医疗咨询请求发送至对应的医生。

在本示例实施方式中，上述分配模块还可以包括返回单元，该返回单元可以用于将匹配到的候选医生列表发送至第一终端，以使用户选择建立连接的医生。例如，当系统为用户匹配到的医生不止一个时，可以通过该返回单元将匹配到的候选医生列表发送至第一终端，以供用户选择意向医生。

进一步地，本示例实施方式还提供了提供一种远程医疗的医生资源分配方法，应用于上述远程医疗系统中的服务端，参考图6所示，可以包括以下步骤：

步骤s610：接收第一终端上传的用户的症状描述、实时体征数据以及医疗咨询请求，并基于所述实时体征数据分析得到所述用户的身体状况。

步骤s620：依据各所述用户及各所述医生的基本信息，以及所述历史咨询数据得到对应的医生画像数据及用户画像数据。

步骤s630：基于所述用户的身体状况、历史咨询数据以及环境数据预测第一预设时间段内所述医疗咨询请求的数量，并基于预测数据安排所述第一预设时间段的医生值班。

步骤s640：基于预设的供需预测模型及所述预测模块得到的医生排班结果，分析得到第二预设时间段内新增的医疗咨询请求及空闲医生的数量，以及当前的医疗咨询请求及空闲医生的数量。

步骤s650：依据所述新增的医疗咨询请求及空闲医生的数量，所述当前的医疗咨询请求及空闲医生的数量，所述医生画像数据以及所述用户画像数据对为各所述用户匹配所述医生。

上述提供一种远程医疗的医生资源分配方法中的具体细节已在上述远程医疗系统的对应模块及单元进行了详细的说明，故在此不再赘述。

图7示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图7示出的电子设备的计算机系统700仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从储存部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram703中，还存储有系统操作所需的各种程序和数据。cpu701、rom702以及ram703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。

以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的储存部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入储存部分708。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图2～图6所示的各个步骤等。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

起点商标作为专业知识产权交易平台，可以帮助大家解决很多问题，如果大家想要了解更多知产交易信息请点击 【在线咨询】或添加微信 【19522093243】与客服一对一沟通，为大家解决相关问题。

此文章来源于网络,如有侵权,请联系删除