医患和医务人员间消息交互管理方法、装置和存储介质与流程

本申请涉及医疗领域，特别是医患和医务人员间消息交互管理方法、装置和存储介质。

背景技术：

在医疗领域，医务人员对患者诊治的过程之中，离不开消息的交流。在治疗过程，会有消息需要医务人员通知患者来执行，比如，医务人员会对回家休养的患者提出一些医嘱，帮助患者进行配合治疗，或者，医务人员会通知患者填写表格或者提交照片文档等操作；除此之外，会出现病例需要医务人员进行消息交流来协作诊治的情况。

在相关技术中，对于医疗诊治过程之中的消息交流还是采取口头通知和实地交流为主，这些消息交流方式常常会出现消息交流滞后，消息交流困难，消息交流难以追溯等问题。消息交流问题常会导致患者响应医务人员的指示出现偏差，对患者的诊治产生不良的影响。

目前针对相关技术中，在医务人员对患者诊治过程中，医务人员间消息交流困难，医患消息交流困难，医务人员难以即时指示患者，患者难以响应医务人员的指示的问题，尚未提出有效的解决方案。

技术实现要素：

本申请实施例提供了医患和医务人员间消息交互管理方法、装置和存储介质，以至少解决相关技术中医务人员间消息交流困难，医患消息交流困难，医务人员难以即时指示患者，患者难以响应医务人员的指示的问题。

第一方面，本申请实施例提供了一种用于医疗过程中的医患消息交互管理方法，所述方法包括：

创建并储存管理医务人员的医务人员账号与管理患者用户的患者用户账号，根据所述医务人员的合作业务建立所述医务人员账号与所述患者用户账号之间的阶段性关联关系；

获取到消息发送者的所述医务人员账号提交的推送消息请求后，根据所述阶段性关联关系将所述推送消息推送给消息接收者的所述患者用户账号。

在其中一些实施例中，在所述推送消息请求包括信息类型和指定所述消息接收者的情况下，所述方法包括：

在所述信息类型为医嘱信息的情况下，获取所述消息接收者响应所述医嘱信息的第一反馈消息；

在所述信息类型为操作信息的情况下，获取所述消息接收者响应所述操作信息的第二反馈消息，其中，根据操作信息要求，获取所述消息接收者响应所述操作信息要求的反馈数据。

在其中一些实施例中，获取到所述消息接收者发送的与所述推送消息对应的反馈数据后，将所述反馈数据按类型进行存储；在所述反馈数据为结构化数据的情况下，所述反馈数据存储进入数据库实列；在所述反馈数据为二进制数据的情况下，所述反馈数据存储进入对象存储。

在其中一些实施例中，所述方法包括：所述反馈数据存储后，获取到所述反馈数据的查询请求后，查询与所述查询请求对应的所述患者用户账号是否有权限访问所述反馈数据。

在其中一些实施例中，在所述推送消息请求包括信息类型和指定所述消息接收者的情况下，所述方法包括：

获取到消息发送者的所述医务人员账号提交的所述推送消息请求后，根据所述推送消息请求指定的所述消息接收者，将所述推送消息请求对应的所述推送消息发送给指定的所述消息接收者，可执行消息的所述消息接收者可将消息再次指定接受者进行转发。

在其中一些实施例中，获取到所述医务人员账号提交创建消息请求后，调出消息模板提供给所述医务人员账号。

在其中一些实施例中获取到所述消息发送者或者所述消息接收者添加备注的请求，将所述备注请求对应的备注加入到所述推送消息或者所述反馈消息中。

第二方面，本申请实施例提供了一种用于医疗过程中的医务人员间消息交互管理方法，所述方法包括：

创建并储存管理医务人员的医务人员账号，根据所述医务人员的合作业务建立所述医务人员账号之间的阶段性关联关系；

获取到消息发送者的所述医务人员账号提交的推送消息请求后，根据所述阶段性关联关系将所述推送消息推送给消息接收者的所述医务人员账号；

其中，在所述推送消息请求包括信息类型和指定所述消息接收者的情况下，所述方法包括：

在所述信息类型为医嘱信息的情况下，获取所述消息接收者响应所述医嘱信息的第一反馈消息；

在所述信息类型为操作信息的情况下，获取所述消息接收者响应所述操作信息的第二反馈消息，其中，根据操作信息要求，获取所述消息接收者响应所述操作信息要求的反馈数据。

第三方面，本申请实施例提供了一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有可运行计算机程序所述计算机程序可执行上述第一方面所述的医患消息交互管理方法，或者，所述计算机程序可执行上述第二方面所述的医务人员间消息交互管理方法。

第四方面，本申请实施例提供了一种存储介质，所述存储介质中存储有计算机程序，所述计算机程序可执行上述第一方面所述的医患消息交互管理方法，或者，所述计算机程序执行上述第二方面所述的医务人员间消息交互管理方法。

相比于相关技术，本申请实施例提供了医患和医务人员间消息交互管理方法、装置和存储介质，该方法包括创建并储存管理医务人员的医务人员账号与管理患者用户的患者用户账号，根据该医务人员的合作业务建立该医务人员账号与该患者用户账号之间的阶段性关联关系；获取到消息发送者的该医务人员账号提交的推送消息请求后，根据该阶段性关联关系将该推送消息推送给消息接收者的该患者用户账号，解决了在医务人员对患者诊治过程中，医务人员间消息交流困难，医患消息交流困难，医务人员难以即时指示患者，患者难以响应医务人员的指示的问题，实现了在线上的医患消息交流，帮助患者实时了解医务人员的医嘱或者医疗过程，并实时响应操作要求，并使诊治过程的工作流转和执行可跟踪可统计。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种医患消息交互管理和医务人员间消息交互管理方法的应用环境示意图；

图2是根据本申请实施例的医患消息交互管理方法的流程示意图；

图3是根据本申请实施例的医务人员间消息交互管理方法的流程示意图；

图4是根据本申请实施例的在具体应用场景的医患消息交互管理系统和医务人员间的消息交互管理系统的项目流程示意图；

图5是根据本申请实施例的电子设备的内部结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

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

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本申请提供的医患消息交互管理和医务人员间消息交互管理方法，可以应用于如图1所示的应用环境中，图1是根据本申请实施例的一种医患消息交互管理和医务人员间消息交互管理方法的应用环境示意图，如图1所示，其中，该应用环境的系统包括服务器10和终端设备11若干，其中，在服务器10上运行消息管理平台，负责对消息进行管理，该终端设备11可以发送消息，接收消息并显示，并有图形化触控交互界面，方便进行各种操作；在服务器10上运行的消息管理平台与终端设备11配合下，解决了在医务人员对患者诊治过程中，医务人员间消息交流困难，医患消息交流困难，医务人员难以即时指示患者，患者难以响应医务人员的指示的问题，实现了在线上的医患消息交流，帮助患者实时了解医务人员的医嘱或者医疗过程，并实时响应操作要求，并使诊治过程的工作流转和执行可跟踪可统计。

在一个实施例中，本申请实施例提供了一种用于医患消息交互管理方法，图2是根据本申请实施例的医患消息交互管理方法的流程示意图，如图2所示，包括如下步骤：

s201，创建并储存管理医务人员的医务人员账号与管理患者用户的患者用户账号，该医务人员与该患者用户的根据治疗与合作业务需要建立该医务人员账号与该患者用户账号之间的阶段性关联关系，关联关系有时间属性，可管理可终止，关联关系期间产生数据永久云端存储；例如，患者用户和医务人员用户在saas服务上开设账号，医务人员账号与管理患者用户的患者用户账号根据阶段性关联关系组建成项目团队；医务人员账号从已注册的医生库里寻找，或者让人员短信注册或者扫码注册，注册好后输入本院医生数据库，成为项目的成员或者项目管理员，同时患者用户账号从已注册的c端用户库里寻找，或者让患者用户短信注册或者扫码注册。

s202，获取到消息发送者的该医务人员账号提交的推送消息请求后，根据该阶段性关联关系将该推送消息推送给消息接收者的该患者用户账号，例如，医务人员向云端递交消息，云端服务器在项目团队中寻找指定的接收者，将该推送消息请求对应的该推送消息提交后进入消息队列，在队列排队后，将消息发送给指定接收者的移动设备终端，并在应用首页对消息接收者显示提醒。

通过上述步骤s201至s202，相比于现有技术中的在医务人员对患者诊治过程中，医务人员难以即时通知患者消息的问题，该技术方案通过在线上构建一个消息管理程序，再通过终端通知患者消息来解决，最后该方案解决了上述问题，使医务人员可以即时通知患者消息，帮助医患进行交流。

在一个实施例中，在该推送消息请求包括了信息类型和指定了消息接收者，在该信息类型为医嘱信息的情况下，获取该消息接收者响应该医嘱信息的第一反馈消息；在该信息类型为操作信息的情况下，获取该消息接收者响应该操作信息的第二反馈消息，其中，根据操作信息要求，获取该消息接收者响应该操作信息要求的反馈数据，例如，患者账号看到提醒后打开移动设备端的应用，可以根据消息发送者的消息类型执行不同操作，如是医嘱可确认并依照医嘱执行，如是操作要求可以按照要求填写表格或者提交照片文档等操作，确认结果或者操作结果实时返回发送者应用内展示；相比于现有技术中的在医务人员对患者诊治过程中，医务人员提出指示后难以获得患者的响应的问题，该技术方案通过在云端服务器接受消息接受者的确认结果或者操作结果，并及时反馈给发送者应用内展示，最后该方案解决了上述问题，使医务人员提出指示后可以快速获得患者的响应。

在其中一些实施例中，获取到该消息接收者发送的与该推送消息对应的反馈数据后，将该反馈数据按类型进行存储；在该反馈数据为结构化数据的情况下，该反馈数据存储进入数据库实列；在该反馈数据为二进制数据的情况下，该反馈数据存储进入对象存储，例如，在消息接受者按照要求填写表格或者提交照片文档等操作之后，所进行操作提交产生的结构化数据或者二进制数据按类型分别存储进入数据库实列以及对象存储oss(objectstorageservice)；同时，确认结果或者操作结果实时返回发送者应用内展示。

在其中一些实施例中，获取到该消息接收者发送的与该推送消息对应的反馈数据后，将该反馈数据按类型进行存储；该反馈数据存储后，对储存的数据设置查询权限，当获取到该反馈数据的查询请求后，查询与该查询请求对应的该患者用户账号或者该医务人员账号是否有权限访问该反馈数据。如果该患者用户账号或者该医务人员账号有权查询其请求的反馈数据，才会把对应的反馈数据提供给账号查阅，以此来保护用户的隐私。

在其中一些实施例中，在该推送消息请求包括信息类型和指定该消息接收者的情况下，获取到消息发送者的该医务人员账号提交的该推送消息请求后，根据该推送消息请求指定的该消息接收者，将该推送消息请求对应的该推送消息发送给指定的该消息接收者；另外，可执行消息的消息接收者还可以按照执行条件将消息再次指定接受者进行转发待执行操作，将消息移交给下一位接受者，新接收账号可以选择执行操作或者将可执行消息继续选择新的接收账号进行转发待执行操作。

在其中一些实施例中，消息创建时可以调用模板来帮助消息创建者编写消息内容，获取到该医务人员账号提交创建消息请求后，云端服务器从消息模板库中的系列模板中找到患者消息模板发送给提交创建消息请求的项目成员，方便其进行后续消息处理工作。

在其中一些实施例中，消息发送者或者消息接收者可以在消息的内容中添加备注，获取到该消息发送者或者该消息接收者添加备注的请求，将该备注请求对应的备注加入到该推送消息或者该反馈消息中，填写的备注信息用于对消息里的问题进行提问或者说明。

在一个实施例中，本申请实施例提供了一种用于医患消息交互管理方法，图3是根据本申请实施例的医务人员间消息交互管理方法的流程示意图，如图3所示，包括如下步骤：

s301，创建并储存管理医务人员的医务人员账号用户账号，该医务人员之间的根据治疗与合作业务需要建立该医务人员账号之间的阶段性关联关系，关联关系有时间属性，可管理可终止，关联关系期间产生数据永久云端存储；例如，医务人员用户在saas服务上开设账号，医务人员账号之间根据阶段性关联关系组件成项目团队；医务人员账号从已注册的医生库里寻找，或者让人员注册短信或者扫码注册，注册好后输入本院医生数据库，成为项目的成员或者项目管理员。

s302，获取到消息发送者的该医务人员账号提交的推送消息请求后，根据该阶段性关联关系将该推送消息推送给消息接收者的医务人员账号，例如，医务人员向云端递交消息，云端服务器在项目团队中寻找指定的接收者，将该推送消息请求对应的该推送消息提交后进入消息队列，在队列排队后，将消息发送给指定接收者的移动设备终端，并在应用首页对消息接收者显示提醒。

s303，在该推送消息请求包括了信息类型和指定了消息接收者，在该信息类型为医嘱信息的情况下，获取该消息接收者响应该医嘱信息的第一反馈消息；在该信息类型为操作信息的情况下，获取该消息接收者响应该操作信息的第二反馈消息，其中，根据操作信息要求，获取该消息接收者响应该操作信息要求的反馈数据；反馈信息及时反馈给消息发送者，反馈数据按类别储存起来。

下面结合具体应用场景对本发明进行详细说明，图4是根据本申请实施例的在具体应用场景的医患消息交互管理系统和医务人员间的消息交互管理系统的项目流程示意图，如图4所示：

首先需要新建项目，为项目添加名称，之后组建团队，其中，从已注册的医生库里寻找医务人员，输入本院医生数据库，成为项目的成员或者项目管理员，或者让医务人员短信注册或者扫码注册，注册好后输入本院医生数据库，成为项目成员或者项目管理员，同时患者用户账号从已注册的c端用户库里寻找，或者让患者用户短信注册或者扫码注册，项目成员与患者根据根据治疗与合作业务需要组成项目团队，这样，项目就组建完成了；之后，我在需要使用系统时，需要先新建消息，其中，消息创建时可以调用模板来帮助消息创建者编写消息内容，获取到该项目成员提交创建消息请求后，云端服务器从消息模板库中的系列模板中找到患者消息模板发送给项目成员，也可以从c端用户库调用消息发送给项目成员；之后项目成员可以选者团队成员将消息移交给其他团队成员，也可以在消息中添加备注；项目中的团队成员可以在项目库里查看项目详情，比如项目信息、项目文件、备忘录、消息列表、团队成员和患者信息，其中，备忘录仅指即可写可见，并且退出项目后不再可以看见项目消息；当项目结束时关闭项目，可以查阅历史消息。

在一个实施例中，图5是根据本申请实施例的电子设备的内部结构示意图，如图5所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图5所示。该电子设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的数据库用于存储数据。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种医患消息交互管理方法和医务人员间消息交互管理方法。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程；其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器；非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存；易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器；作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。