CN113284598B - 诊断请求消息的提醒方法、设备及可读存储介质 - Google Patents

Abstract

本申请涉及消息提醒技术领域，公开了诊断请求消息的提醒方法、设备及可读存储介质。该方法包括：获取诊断请求消息，诊断请求消息包含检测数据；确定诊断请求消息的数据源类型；将诊断请求消息添加至多个消息队列中与数据源类型对应的一个；其中，多个消息队列同屏显示，消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行处理。通过上述方式，能够提高远程诊断的服务效率以及特殊病例的诊断及时性要求。

Description

诊断请求消息的提醒方法、设备及可读存储介质

技术领域

本申请涉及消息提醒技术领域，特别是涉及诊断请求消息的提醒方法、设备及可读存储介质。

背景技术

远程诊断是指将医疗设备采集的数据集中进行诊断。发明人长期研究发现，随着不同医疗机构、不同病源的诊断请求消息数量的增加，每一位诊断医生需要承担的诊断量越来越大，当待诊消息积累越来越多时，会存在诊断请求消息排序过于单一，很容易出现紧急病例不能及时发现导致诊断延误的问题。

发明内容

本申请主要解决的技术问题是提供诊断请求消息的提醒方法、设备及可读存储介质，能够提高远程诊断的服务效率以及特殊病例的诊断及时性要求。

为了解决上述问题，本申请采用的一种技术方案是提供一种诊断请求消息的提醒方法，该方法包括：获取诊断请求消息，诊断请求消息包含检测数据；确定诊断请求消息的数据源类型；将诊断请求消息添加至多个消息队列中与数据源类型对应的一个；其中，多个消息队列同屏显示，消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行处理。

其中，将诊断请求消息添加至多个消息队列中与数据源类型对应的一个之后，包括：获取诊断请求消息中的紧急程度；若紧急程度满足预设条件，则提取检测数据中的关键信息，将关键信息显示在显示界面的设定区域。

其中，提取检测数据中的关键信息，将关键信息显示在显示界面的设定区域之前，包括：获取满足预设条件的诊断请求消息的第一数量；若第一数量超过第一预设数量，则在显示界面显示一转发列表；其中，转发列表用于显示空闲的诊断医生账户；响应于对诊断医生账户的选择指令，将诊断请求消息发送至选择指令对应的诊断医生账户。

其中，该方法还包括：获取每一消息队列中的诊断请求消息的请求时间；若请求时间超过预设时间，对诊断请求消息进行标识，并在对应的消息队列中显示标识。

其中，将诊断请求消息添加至多个消息队列中与数据源类型对应的一个之后，包括：判断显示界面前是否有用户存在；若否，则获取诊断请求消息的紧急程度；在紧急程度满足预设条件时进行预警。

其中，该方法还包括：若显示界面前有用户存在，对用户进行人脸识别；在用户与诊断医生账户中的诊断医生不匹配时，获取诊断请求消息的紧急程度；在紧急程度满足预设条件时进行预警。

其中，该方法还包括：显示数据源类型列表和提醒规则列表；响应于对数据源类型列表中数据源类型以及提醒规则列表中提醒规则的选择指令，基于被选择的数据源类型和提醒规则生成可同屏显示的目标消息队列。

其中，该方法还包括：将目标消息队列添加至消息队列列表中；响应于对目标消息队列的拖动指令，根据拖动指令对应的轨迹，将目标消息队列拖动至消息队列列表中的目标位置。

其中，该方法还包括：获取每个消息队列中诊断请求消息的第二数量；将第二数量小于第二预设数量的消息队列中的诊断请求消息合并至目标消息队列中，并将合并的目标消息队列显示于显示界面一侧；其中，显示界面另一侧显示第二数量大于或等于第二预设数量的消息队列。

其中，该方法还包括：获取目标消息队列中的每一数据源类型的诊断请求消息第三数量；将第三数量大于或等于第二预设数量的诊断请求消息进行消息队列恢复。

其中，该方法还包括：获取请求更改消息；确定请求更改消息对应的目标诊断请求消息；基于请求更改消息，更改目标诊断请求消息在对应的消息队列中的显示模式。

其中，基于请求更改消息，更改目标诊断请求消息在对应的消息队列中的显示模式，包括：若请求更改消息中的当前紧急程度低于目标诊断请求消息中的紧急程度，则将目标诊断请求消息移动至对应的消息队列的后列；若请求更改消息中的当前紧急程度高于目标诊断请求消息中的紧急程度，则将目标诊断请求消息移动至对应的消息队列的前列，并对目标诊断请求消息进行标识，以及在对应的消息队列中显示标识。

为了解决上述问题，本申请采用的另一种技术方案是提供一种诊断请求消息提醒设备，该诊断请求消息提醒设备包括处理器以及与处理器耦接的存储器和显示屏，存储器中存储有计算机程序，处理器用于执行计算机程序以实现如上述技术方案提供的方法。

为了解决上述问题，本申请采用的另一种技术方案是提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序在被处理器执行时，实现如上述技术方案提供的方法。

本申请的有益效果是：区别于现有技术的情况，本申请提供的诊断请求消息的提醒方法、设备及可读存储介质。本方法通过将诊断请求消息按照数据源类型分为多个消息队列，并将多个消息队列同屏显示的方式，能够使诊断医生能直观的看到不同消息队列/不同要求的诊断请求消息，更加方便的按照每个消息队列中诊断请求消息的优先级要求、业务要求灵活处理不同消息队列中的诊断请求消息，能够提高远程诊断的服务效率以及特殊病例的诊断及时性要求。

附图说明

图1是本申请提供的诊断请求消息的提醒方法一实施例的流程示意图；

图2和图3是本申请提供的诊断请求消息的提醒方法一实施例的应用场景示意图；

图4是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图5是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图6和图7是本申请提供的诊断请求消息的提醒方法一实施例的另一应用场景示意图；

图8是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图9和图10是本申请提供的诊断请求消息的提醒方法一实施例的另一应用场景示意图；

图11是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图12是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图13是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图14是本申请提供的诊断请求消息的提醒方法一实施例的另一应用场景示意图；

图15是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图16是本申请提供的诊断请求消息的提醒方法一实施例的另一应用场景示意图；

图17是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图；

图18、图19和图20是本申请提供的诊断请求消息的提醒方法一实施例的另一应用场景示意图；

图21是本申请提供的诊断请求消息提醒设备一实施例的结构示意图；

图22是本申请提供的计算机可读存储介质的一实施例的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

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

远程诊断是指将医疗设备采集的数据集中进行诊断。发明人长期研究发现，随着不同医疗机构、不同病源的诊断请求消息数量的增加，每一位诊断医生需要承担的诊断量越来越大，当待诊消息积累越来越多时，会存在诊断请求消息排序过于单一，很容易出现紧急病例不能及时发现导致诊断延误的问题。基于此，本申请提出以下技术方案。

参阅图1，图1是本申请提供的诊断请求消息的提醒方法一实施例的流程示意图。该方法包括：

步骤11：获取诊断请求消息，诊断请求消息包含检测数据。

在一些实施例中，诊断请求消息可以是医护人员利用相应医疗设备采集得到，然后发送至诊断医生所使用的设备上。如，在心电诊断中，医护人员利用心电图机对检测者进行心电采集，得到对应的心电图。医护人员可以根据心电图生成诊断请求消息，发送至诊断医生所使用的设备上。诊断医生所使用的设备上会获取到诊断请求消息，诊断请求消息的检测数据则是心电图。如，在核磁共振诊断中，医护人员利用核磁共振成像设备对检测者的相应部位，如脑部、腿部进行图像采集，得到对应的核磁共振图。医护人员可以根据核磁共振图生成诊断请求消息，发送至诊断医生所使用的设备上。诊断医生所使用的设备上会获取到诊断请求消息，诊断请求消息的检测数据则是核磁共振图。

步骤12：确定诊断请求消息的数据源类型。

在一些实施例中，数据源类型可以根据不同医疗机构进行设置。如体检机构、三甲级医疗机构、疗养院、门诊部、诊所、卫生所（室）以及急救站等。

在一些实施例中，数据源类型可以根据不同病源进行设置。如外界因素、营养因素、免疫因素等。如，心电诊断的病源可以是胸闷、房颤等。

在一些实施例中，数据源类型可以根据紧急程度进行设置。诊断请求消息在生成时对应设置紧急程度。

诊断请求消息在生成时，可对应将数据源类型添加至诊断请求消息中，以在获取到诊断请求消息时，可从诊断请求消息中获取到对应的数据源类型。

步骤13：将诊断请求消息添加至多个消息队列中与数据源类型对应的一个。

其中，多个消息队列同屏显示，消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行处理。可以理解，处理方式为诊断医生根据诊断请求消息对应的检测数据进行诊断，并将诊断结果反馈至请求端。

在一应用场景中，以心电诊断为例，结合图2和图3进行说明：

图2中显示了四个消息队列，队列名称分别为卫生院、体检中心、急诊室、社康中心。其中，卫生院消息队列中显示有待诊人数3，要求报告时间15min，以及三条诊断请求消息，以第一条诊断请求消息为例进行说明：第一条诊断请求消息显示的内容是张三、常规十二导、54岁、男、yyyy-m-d 12:34:34，分别对应了姓名、检查项目、年龄、性别以及诊断请求消息上传时间。

体检中心消息队列中显示有待诊人数3，要求报告时间12h，以及三条诊断请求消息，以第一条诊断请求消息为例进行说明：第一条诊断请求消息显示的内容是周七、常规十二导、54岁、男、yyyy-m-d 12:34:34，分别对应了姓名、检查项目、年龄、性别以及诊断请求消息上传时间。

急诊室消息队列中显示有待诊人数2，要求报告时间10min，以及二条诊断请求消息，第一条诊断请求消息显示的内容是五角星、赵四、54岁、男、yyyy-m-d 12:36:34，分别对应了紧急程度、姓名、年龄、性别以及诊断请求消息上传时间。第二条诊断请求消息显示的内容是孙六、32岁、男、yyyy-m-d 12:35:34。因第一条的紧急程度满足了预设条件，则将对应赵四的诊断请求消息排在了对应孙六的诊断请求消息的前面。5min显示的对应赵四的诊断请求消息超时倒计时。

社康中心消息队列中显示有待诊人数1，要求报告时间10min，以及一条诊断请求消息，该条诊断请求消息显示的内容是王三、常规十二导、54岁、男、yyyy-m-d 12:34:34，分别对应了姓名、检查项目、年龄、性别以及诊断请求消息上传时间。

在诊断医生选择一诊断请求消息进行处理时，获取到一条诊断请求消息，诊断请求消息包含检测数据。通过获取该诊断请求消息为社康中心，则将诊断请求消息添加至社康中心消息队列中，如图3所示的方式进行显示。具体地，如图3所示，社康中心消息队列中显示有待诊人数2，要求报告时间10min，以及两条诊断请求消息，第一条诊断请求消息显示的内容与之前相同，第二条诊断请求消息显示的内容是冯九、常规十二导、54岁、女、yyyy-m-d 12:37:34。

诊断医生可以选择对应的诊断请求消息，以使消息队列响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行诊断。

在本实施例中，通过将诊断请求消息按照数据源类型分为多个消息队列，并将多个消息队列同屏显示的方式，能够使诊断医生能直观的看到不同消息队列/不同要求的诊断请求消息，更加方便的按照每个消息队列中诊断请求消息的优先级要求、业务要求灵活处理不同消息队列中的诊断请求消息，能够提高远程诊断的服务效率以及特殊病例的诊断及时性要求。

参阅图4，图4是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤41：获取诊断请求消息，诊断请求消息包含检测数据。

步骤42：确定诊断请求消息的数据源类型。

步骤43：将诊断请求消息添加至多个消息队列中与数据源类型对应的一个。

步骤41-步骤43与上述实施例具有相同或相似的技术方案，这里不做赘述。

步骤44：获取诊断请求消息中的紧急程度。

诊断请求消息中的紧急程度可在检测数据形成后，进行设置。如，在医疗设备端，医护人员使用该医疗设备对检测者进行数据采集，生成检测数据，同时对本次检测数据进行紧急程度选择。若该检测者是急救病人，则紧急程度可以选择特急，若该检测者是普通病人，则紧急程度可以选择一般。相应的，不同紧急程度的诊断请求消息具有不同的诊断时限要求。如，紧急程度为特急的诊断请求消息的诊断时限为15分钟、紧急程度为一般的诊断请求消息的诊断时限为240分钟。

步骤45：若紧急程度满足预设条件，则提取检测数据中的关键信息，将关键信息显示在显示界面的设定区域。

在一些实施例中，紧急程度可以用数字代替，若将紧急程度分为5级，分别以1、2、3、4和5表示，从1-5的紧急程度逐步降低，则可以将预设条件小于3。在获取到的紧急程度为1或2时，满足预设条件，则提取检测数据中的关键信息，将关键信息显示在显示界面的设定区域。如，关键信息可以包括年龄、性别、病史、初步诊断结果等。设定区域可以是显示界面的一固定区域，如右上角区域、左上角区域。也可以在显示界面的顶部区域，以浮窗的形式显示。或者还可以对关键信息的字体的颜色、字号进行改变，如字号变大、颜色改为红色的方式，使关键信息更加醒目，然后以字幕滚动的方式在显示界面的顶部区域显示。以这种方式提醒诊断医生需要及时处理。

在一应用场景中，发明人研究发现，当诊断医生的显示界面中同时显示多个紧急程度满足预设条件的诊断请求消息时，因该诊断请求消息的诊断时限要求较短，诊断医生存在处理不及时的情况，基于此，参阅图5，本申请提出在提取检测数据中的关键信息，将关键信息显示在显示界面的设定区域之前可以是如下流程：

步骤51：获取满足预设条件的诊断请求消息的第一数量。

步骤52：若第一数量超过第一预设数量，则在显示界面显示一转发列表；其中，转发列表用于显示空闲的诊断医生账户。

其中，第一预设数量可以为1或者2。

若第一数量超过第一预设数量，则该诊断医生无法及时处理多余的诊断请求消息，为避免诊断延误，则获取诊断系统中所有诊断医生账户中空闲的诊断医生账户。并在显示界面显示一转发列表，显示这些空闲的诊断医生账户，以供选择诊断请求消息的转发的诊断医生账户。

步骤53：响应于对诊断医生账户的选择指令，将诊断请求消息发送至选择指令对应的诊断医生账户。

当空闲的诊断医生账户获取转发来的诊断请求消息后，可直接对诊断请求消息进行选择，响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便诊断医生对检测数据进行诊断。

结合图6和图7进行说明：

其中，图6以图3为基础进行显示，急诊室消息队列中显示有待诊人数3，要求报告时间10min，以及三条诊断请求消息，前两条诊断请求消息不变，新增一条诊断请求消息，显示的内容是五角星、程四、54岁、男、yyyy-m-d 12:36:52。此时获取到满足预设条件的诊断请求消息的数量为2，对应两个五角星的诊断请求消息。

此时，会在显示界面显示一转发列表，其中，转发列表用于显示空闲的诊断医生账户。如图7所示，有空闲状态下的诊断医生A、B、C和D，则可以选择其中一诊断医生的转发按钮，将五角星的诊断请求消息转发至该空闲诊断医生处。

在本实施例中，通过将满足预设条件的诊断请求消息转发至其余空闲的诊断医生处，使空闲诊断医生对其进行诊断，避免诊断请求消息堆积，诊断医生处理不及时的情况发生。

在一应用场景中，发明人研究发现，当诊断医生的显示界面中同时显示多个诊断请求消息时，容易出现对诊断请求消息的遗漏，导致存在诊断请求消息一直未被处理的情况，基于此，本申请提出以下技术方案。

参阅图8，图8是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤81：获取每一消息队列中的诊断请求消息的请求时间。

可选的，可从诊断请求消息添加至消息队列中开始进行显示计时，则可对应获取到消息队列中的诊断请求消息的请求时间。

步骤82：若请求时间超过预设时间，进行预警操作，并对诊断请求消息进行标识，以及在对应的消息队列中显示标识。

在诊断请求消息中，对应设置有诊断时限，可根据诊断时限设置预设时间。如，诊断时限为120分钟，则预设时间可以为100分钟，诊断时限为30分钟，则预设时间可以为20分钟，诊断时限为60分钟，则预设时间可以为45分钟。通过预设时间比诊断时限短的方式，在诊断时限前对诊断请求消息进行标识，提醒诊断医生及时处理即将超时的诊断请求，避免遗漏。同时，可以进行预警操作，如，进行声音提醒，通过控制扬声器播放预警铃声，以使诊断医生知晓有诊断请求需要处理。

对诊断请求消息进行标识的方式可以是对诊断请求消息对应的显示区域进行闪烁，或者添加红色标识，如红色五角星，并使五角星闪烁。

结合图2、图9和图10进行说明：

图9是将图2所示的卫生院、急诊室、社康中心消息队列的诊断请求消息处理后的显示界面示意图。随着时间流逝，社康中心消息队列中的诊断请求消息的请求时间超过预设时间，则会对每一诊断请求消息进行标识，如图10所示的五角星标识，并显示倒计时时间30min。

在本实施例中，通过对每一诊断请求消息进行请求时间统计，在超过预设时间时，对诊断请求消息进行标识，并在对应的消息队列中显示标识，以此提醒诊断医生及时进行处理，以解决诊断请求消息遗漏未被处理的情况。

在一应用场景中，发明人研究发现，诊断医生通常是在显示屏前对显示屏上诊断请求消息进行处理，但是存在诊断医生不在显示屏前，但是诊断请求消息发送至该诊断医生的设备，容易出现诊断不及时的问题。基于此，参阅图11，本申请提出在将诊断请求消息添加至多个消息队列中与数据源类型对应的一个之后可以是如下流程：

步骤111：判断显示界面前的空间中是否有用户存在。

在一些实施例中，可利用图像采集装置对显示界面前的空间进行图像采集，以从采集到的图像中确定是否存在人脸图像，若存在人脸图像，则确定存在用户，即诊断医生。若不存在人脸图像，则确定显示界面前的空间中不存在用户。

在一些实施例中，还可以检测该显示界面对应的设备当前时刻是否被操作，如鼠标点击操作，使用诊断系统的操作。若检测该设备当前时刻被操作，则确定存在用户，即诊断医生。若检测该设备当前时刻未被操作，则利用图像采集装置对显示界面前的空间进行图像采集，以从采集到的图像中确定是否存在人脸图像，若存在人脸图像，则确定存在用户，即诊断医生。若不存在人脸图像，则确定显示界面前的空间中不存在用户。

还可以在诊断请求消息发送至该诊断医生的设备时，检测该显示界面是否处于锁屏状态，若处于锁屏状态，可确定不存在用户。

若通过上述的方式确定显示界面前的空间中没有用户存在，则执行步骤112。

步骤112：获取诊断请求消息的紧急程度。

步骤112与上述任一实施例具有相同或相似的技术方案，这里不再赘述。

步骤113：在紧急程度满足预设条件时进行预警。

预警的方式可以是向诊断医生的移动设备发送提醒，如从诊断医生账户中的基本信息中获取手机号，向该手机号发送短信提醒；通过QQ、微信、钉钉等通讯应用向诊断医生的移动设备发送消息提醒。以及诊断医生的设备通过扬声器发出报警声，进行提醒。

在一些实施例中，若在预警提醒后，预设时间内显示界面前的空间中仍然没有用户存在或诊断请求消息未被处理，则这些诊断请求消息将会自动转发至其余诊断医生处。

在本实施例中，通过识别显示屏前是否存在用户的方式，以确保诊断请求消息能够被显示屏前的诊断医生及时处理，在显示屏前不存在诊断医生时，通过向诊断医生预警的方式，提醒诊断医生有诊断请求消息需要处理，以解决诊断请求消息处理不及时的问题。

在一应用场景中，发明人研究发现，即使显示屏前存在用户，但是该用户不一定是诊断医生，则存在无法处理诊断请求消息，依然容易出现诊断不及时的问题。基于此，本申请提出若显示界面前的空间中有用户存在，对用户进行生物特征识别，如人脸识别、虹膜识别、唇部识别以及指纹识别等；在用户与诊断医生账户中的诊断医生的预设生物特征不匹配时，获取诊断请求消息的紧急程度；在紧急程度满足预设条件时进行预警。通过识别显示屏前的用户的是诊断医生的方式，以确保诊断医生能够看到显示界面上的多个消息队列中的诊断请求消息，以便诊断医生及时处理。

在一应用场景中，本申请提出可以自定义消息队列的显示及提醒规则。参阅图12，图12是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤121：显示数据源类型列表和提醒规则列表。

在一些实施例中，数据源类型列表中可以包括医疗机构，如体检中心、急诊室、社康中心等。提醒规则列表中可以包括铃声、提醒类型、超时提醒时间、队列显示字段。

步骤122：响应于对数据源类型列表中数据源类型以及提醒规则列表中提醒规则的选择指令，基于被选择的数据源类型和提醒规则生成可同屏显示的目标消息队列。

进一步，可以将目标消息队列添加至消息队列列表中；响应于对目标消息队列的拖动指令，根据拖动指令对应的轨迹，将目标消息队列拖动至消息队列列表中的目标位置。

下面以新增消息队列为例说明实现步骤：

用户登录诊断系统，进入用户设置中的消息队列列表配置界面，点击新增消息队列按钮，弹出添加消息队列界面。

用户输入消息队列名称（比如基层体检），以此名称作为该消息队列的数据源类型，在医疗机构列表中选择该消息队列包含的医疗机构清单，被勾选的医疗机构，代表该医疗机构下的诊断请求消息存放在该消息队列进行显示。

用户选择消息队列中诊断请求消息的提醒方式，可以包括铃声，如，消息队列中新的诊断请求消息到达的铃声提醒；提醒类型，如，消息队列中的诊断请求消息未被处理时多久提醒一次，可以设置为不提醒、单次或循环多次等；超时提醒时间，如，与医疗机构协议的诊断时间范围，当要超过该诊断时间时，进行特殊醒目提醒，避免超长时间未处理；诊断请求消息在消息队列中的显示字段，如，可以配置该消息队列中需要显示的诊断请求消息中相关字段信息，比如姓名、性别、年龄、检查时间等信息。

用户选择及配置消息队列相关信息完毕后，点击保存按钮，诊断系统将消息队列配置信息保存到用户自定义配置中，并存储在数据库中，并将新增的消息队列显示在已有消息队列列表中；用户可以在消息队列列表中查看该消息队列的显示效果，并可以通过鼠标拖动消息队列的排序位置并保存，实现消息队列显示位置的自定义设置。如，将目标消息队列添加至消息队列列表中；响应于对目标消息队列的拖动指令，根据拖动指令对应的轨迹，将目标消息队列拖动至消息队列列表中的目标位置。如，消息队列列表中的排序为消息队列A、B、C，默认的排序位置为消息队列A显示在显示界面A区域，消息队列B显示在显示界面B区域，消息队列C显示在显示界面C区域，通过消息队列C拖动，使消息队列列表中的排序变为消息队列C、A、B，C，则接下的排序位置为消息队列A显示在显示界面B区域，消息队列B显示在显示界面C区域，消息队列C显示在显示界面A区域。

当用户成功登录诊断系统后，诊断系统根据用户账号获取配置的消息队列信息，将不同消息队列显示在同一显示界面中。

当有新的诊断请求消息到达时，诊断系统上述任一实施例中的方法，确定诊断请求消息的数据源类型，从而确定对应的消息队列，并将诊断请求消息添加至消息队列中，同时根据设置的消息提醒铃声播放音频文件，发出响铃提醒。

进一步，用户可以根据医疗机构的变动来修改消息队列的配置，如删除消息队列、修改消息队列的提醒方式等。

通过上述方式，用户可以自定义配置多种消息队列，不同类型的消息队列可以配置不同来源数据、不同显示内容以及不同提醒时间，实现同屏显示不同消息队列。

在一应用场景中，发明人研究发现，当诊断医生的显示界面中同时显示多个消息队列时，存在一种现象，即不同的消息队列中的诊断请求消息是在动态变化的，如，在诊断医生处理消息队列中的诊断请求消息后，该消息队列中的诊断请求消息对应减少，而在远程的诊断请求消息不断发送至诊断医生处时，对应的消息队列中的诊断消息会对应增加。因多个消息队列同屏显示，因此消息队列的尺寸的固定的，在显示界面的不同区域。由此，较多诊断请求消息的消息队列会存在该区域不能全部显示诊断请求消息，而较少诊断请求消息的消息队列会存在该区域不能全部用于显示诊断请求消息的问题。基于此，本申请提出以下技术方案。

参阅图13，图13是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤131：获取每个消息队列中诊断请求消息的第二数量。

步骤132：将第二数量小于第二预设数量的消息队列中的诊断请求消息合并至目标消息队列中，并将合并的目标消息队列显示于显示界面一侧。

其中，第二预设数量可以设置为3、4、5、6或7。具体地，可以根据消息队列的数量进行设置。如，显示界面计划显示5个消息队列，则可以将第二预设数量设置为3。则若5个消息队列中的诊断请求消息的数量均小于第二预设数量时，目标消息队列中则可显示10个诊断请求消息。

其中，显示界面另一侧显示第二数量大于或等于第二预设数量的消息队列。

结合图10和图14进行说明：

如图10所示，属于卫生院、社康中心、急诊室的消息队列中已经没有诊断请求消息，而这些诊断请求消息依然在显示界面中占据相应的显示区域，因此，将属于卫生院、社康中心、急诊室的消息队列的诊断消息进行合并，生成新的目标消息队列。将合并的目标消息队列显示于显示界面一侧。如图14所示，合并的目标消息队列显示于显示界面的左侧，而体检中心的消息队列因为诊断请求消息的增加，则可以利用原本属于社康中心的消息队列的显示区域显示体检中心的消息队列增加的诊断请求消息，以使显示界面显示更多的诊断请求消息，便于诊断医生的查看。

在上述实施例的合并的方案，也存在合并的目标消息队列中增加诊断请求消息，使得目标消息队列也无法全部显示，造成消息的遗漏，基于此，本申请提出以下技术方案。

参阅图15，图15是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤151：获取目标消息队列中的每一数据源类型的诊断请求消息第三数量。

步骤152：将第三数量大于或等于第二预设数量的诊断请求消息进行消息队列恢复。

结合图14和图16进行说明：

随着每个消息队列对应的诊断请求消息的增加，目标消息队列已经不能满足显示需求。如图16所示，社康中心的消息队列中新增两条诊断请求消息，此时小于3，则显示于目标消息队列中。急诊室的消息队列中新增三条诊断请求消息，此时等于3，则将急诊室的消息队列恢复，以使其在合并前的属于急诊室的显示区域显示急诊室此时的消息队列。

通过上述方式，根据每一消息队列中的诊断请求消息的数量动态的调整消息队列的显示方式，以使在显示界面显示更多的诊断请求消息，以便于诊断医生的查看及处理。

在一应用场景中，发明人研究发现，当诊断医生的显示界面中同时显示多个消息队列时，存在一种现象，即不同的消息队列中的诊断请求消息是可能变化的，如，请求端对诊断请求消息的紧急程度进行修改，而现有的技术方案无法应对此现象，基于此，本申请提出以下技术方案。

参阅图17，图17是本申请提供的诊断请求消息的提醒方法另一实施例的流程示意图。该方法包括：

步骤171：获取请求更改消息。

请求更改消息由诊断请求消息的发起方产生。如，请求端认为之前的诊断请求消息需要加快处理，则请求端可以更改诊断请求消息的紧急程度，请求端认为之前的需要加快处理的诊断请求消息目前不需要加快，则可以需要加快处理，则请求端可以更改诊断请求消息的紧急程度。

步骤172：确定请求更改消息对应的目标诊断请求消息。

在获取到请求更改消息后，确定该请求更改消息对应的目标诊断请求消息，以执行步骤173。

步骤173：基于请求更改消息，更改目标诊断请求消息在对应的消息队列中的显示模式。

在一些实施例中，请求更改消息中可以包括对紧急程度的修改，若请求更改消息中的当前紧急程度低于目标诊断请求消息中的紧急程度，则将目标诊断请求消息移动至对应的消息队列的后列；若请求更改消息中的当前紧急程度高于目标诊断请求消息中的紧急程度，则将目标诊断请求消息移动至对应的消息队列的前列，并对目标诊断请求消息进行标识，以及在对应的消息队列中显示标识。

结合图18和图19进行说明：

在图18中，急诊室的消息对列中的对应“赵四”的诊断请求消息的紧急程度较高，此时，获取到对应“赵四”的诊断请求消息的请求更改消息。该请求更改消息中的当前紧急程度低于对应“赵四”的诊断请求消息中的紧急程度，则将对应“赵四”的诊断请求消息移动至急诊室的消息对列的后列，如图19所示，取消对应“赵四”的诊断请求消息的标识，并将其排到后列。

结合图18和图20进行说明：

在图18中，体检中心的消息对列中按照“周七”、“吴四”、“郑五”的顺序排列，此时，获取到对应“郑五”的诊断请求消息的请求更改消息。该请求更改消息中的当前紧急程度高于“郑五”的诊断请求消息中的紧急程度，则将“郑五”的诊断请求消息移动至体检中心的消息队列的前列，并对“郑五”的诊断请求消息进行标识，以及在体检中心的消息队列中显示标识。如图20所示，将“郑五”的诊断请求消息移动至第一位，并对其添加“五角星”标识，以使诊断医生知晓其紧急程度。

通过上述方式，响应于请求端的更改消息，以使显示界面上的消息队列灵活显示其对应的诊断请求消息，以便于诊断医生的及时知晓每一诊断请求消息的情况，及时查看及处理。

参阅图21，图21是本申请提供的诊断请求消息提醒设备一实施例的结构示意图。该诊断请求消息提醒设备210包括处理器211以及与处理器211耦接的存储器212和显示屏213，存储器212中存储有计算机程序，处理器211用于执行计算机程序以实现以下方法：

获取诊断请求消息，诊断请求消息包含检测数据；确定诊断请求消息的数据源类型；将诊断请求消息添加至多个消息队列中与数据源类型对应的一个；其中，多个消息队列同屏显示，消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行处理。

可以理解，处理器211还用于执行计算机程序以实现以上任一实施例的方法，具体方式请参阅上述任一实施例。

参阅图22，图22是本申请提供的计算机可读存储介质的一实施例的结构示意图。该计算机可读存储介质220存储有计算机程序221，计算机程序221在被处理器执行时，实现以下方法：

获取诊断请求消息，诊断请求消息包含检测数据；确定诊断请求消息的数据源类型；将诊断请求消息添加至多个消息队列中与数据源类型对应的一个；其中，多个消息队列同屏显示，消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对检测数据进行处理。

可以理解，计算机程序221在被处理器执行时，还可以实现以上任一实施例的方法，具体方式请参阅上述任一实施例。

综上，在本申请提供的诊断请求消息的提醒方法、提醒设备及可读存储介质应用于远程诊断服务时，如心电图诊断，能够对于远程诊断中心的诊断请求消息列表进行优化，通过同屏将多个消息队列同时显示在显示界面上，以使诊断医生能直观的看到不同消息队列/不同要求的诊断请求消息，能够更加方便的按照优先级要求、业务要求灵活处理不同消息队列中的诊断请求消息，提高远程诊断的服务效率以及特殊病例的诊断及时性要求。

在本申请所提供的几个实施方式中，应该理解到，所揭露的方法以及设备，可以通过其它的方式实现。例如，以上所描述的设备实施方式仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

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

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

上述其他实施方式中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，RandomAccess Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (7)

1.一种诊断请求消息的提醒方法，其特征在于，所述方法包括：

获取诊断请求消息，所述诊断请求消息包含检测数据；

确定所述诊断请求消息的数据源类型；其中，所述数据源类型根据不同医疗机构进行设置；

将所述诊断请求消息添加至多个消息队列中与所述数据源类型对应的一个；其中，所述多个消息队列同屏显示，所述消息队列被配置为响应于对诊断请求消息的选择指令，显示被选择的诊断请求消息对应的检测数据，以便对所述检测数据进行处理；

获取所述诊断请求消息中的紧急程度；

若所述紧急程度满足第一预设条件，则获取满足所述预设条件的所述诊断请求消息的第一数量；

若所述第一数量超过第一预设数量，则在显示界面显示一转发列表；其中，所述转发列表用于显示空闲的诊断医生账户；

响应于对诊断医生账户的选择指令，将所述诊断请求消息发送至所述选择指令对应的诊断医生账户；

以及，判断显示界面前是否有用户存在；若否，则获取所述诊断请求消息的紧急程度；在所述紧急程度满足第二预设条件时进行预警，若在预警提醒后，预设时间内显示界面前的空间中没有用户存在或所述诊断请求消息未被处理，则将所述诊断请求消息转发至其余诊断医生处；

以及，获取每个消息队列中诊断请求消息的第二数量；

将所述第二数量小于第二预设数量的消息队列中的诊断请求消息合并至目标消息队列中，并将合并的所述目标消息队列显示于显示界面一侧；

其中，所述显示界面另一侧显示所述第二数量大于或等于所述第二预设数量的消息队列；

以及，获取所述目标消息队列中的每一数据源类型的诊断请求消息第三数量；

将所述第三数量大于或等于所述第二预设数量的诊断请求消息进行消息队列恢复；

以及，获取请求更改消息；

确定所述请求更改消息对应的目标诊断请求消息；

若所述请求更改消息中的当前紧急程度低于所述目标诊断请求消息中的紧急程度，则将所述目标诊断请求消息移动至对应的消息队列的后列；

若所述请求更改消息中的当前紧急程度高于所述目标诊断请求消息中的紧急程度，则将所述目标诊断请求消息移动至对应的消息队列的前列，并对所述目标诊断请求消息进行标识，以及在对应的消息队列中显示所述标识。

2.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

获取每一消息队列中的诊断请求消息的请求时间；

若所述请求时间超过预设时间，进行预警操作，并对所述诊断请求消息进行标识，以及在对应的消息队列中显示所述标识。

3.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

若所述显示界面前有用户存在，对所述用户进行生物特征识别；

在所述用户与诊断医生账户中的诊断医生的预设生物特征不匹配时，获取所述诊断请求消息的紧急程度；在所述紧急程度满足预设条件时进行预警。

4.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

显示数据源类型列表和提醒规则列表；

响应于对数据源类型列表中数据源类型以及提醒规则列表中提醒规则的选择指令，基于被选择的数据源类型和提醒规则生成可同屏显示的目标消息队列。

5.根据权利要求4所述的方法，其特征在于，

所述方法还包括：

将所述目标消息队列添加至消息队列列表中；

响应于对所述目标消息队列的拖动指令，根据所述拖动指令对应的轨迹，将所述目标消息队列拖动至所述消息队列列表中的目标位置。

6.一种诊断请求消息提醒设备，其特征在于，所述诊断请求消息提醒设备包括处理器以及与所述处理器耦接的存储器和显示屏，所述存储器中存储有计算机程序，所述处理器用于执行所述计算机程序以实现如权利要求1-5任一项所述的方法。

7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序在被处理器执行时，实现如权利要求1-5任一项所述的方法。

Images