一种医患群组的动态构建方法及系统

文档序号:31195888发布日期:2022-08-20 00:34阅读:53来源:国知局
一种医患群组的动态构建方法及系统

1.本发明属于医疗领域,尤其涉及一种医患群组的动态构建方法及系统。


背景技术:

2.本部分的陈述仅仅是提供了与本发明相关的背景技术信息,不必然构成在先技术。
3.目前,患者的诊疗过程主要集中在医院,以门诊或住院为主;而院外患者通常只能通过电话或微信等聊天工具与医生交流;使用电话或微信等聊天工具进行交互时,存在信息不方便有效存储和查询的问题,每次医生都要回忆或翻找以前的患者信息,不能及时准确了解患者病史信息。
4.而且医院外的信息没有有效管理,与医院内的信息化数据相互隔离,形成信息孤岛,不利于信息系统智能管理。
5.微信、qq等聊天工具比较好地提供了医患交互的功能,但是实际应用中存在以下几方面的局限:
6.(1)管理或负责的患者数量巨大,工作相对比较繁琐,如果与患者进行一对一沟通,单个医生或护士通常难以有效完成每个患者的随访工作;
7.(2)患者诊疗信息具有私密性,不同患者应该隔离,如果将大量患者用同一个微信群进行管理,将会造成患者信息暴露于其他患者,存在不可控的隐私泄露风险;
8.(3)由于某些疾病的诊疗周期较长,患者每次诊疗可能接诊的不是同一个医护人员,经常加入多个不同的微信群,导致重复、混乱,而且每个医生或护士都存在大量的“群”,存在群成员交叉、群重复等问题,实际工作中不能方便地找到信息,经常出现应答不及时或信息误发送到错误的群中的问题;
9.(4)针对为单个患者创建微信群,由于微信群是静态的,因此存在很多问题:
10.(a)当出现某个医生或者护士调离原职位、有新医生或新护士入岗时,往往牵扯若干个群都要将调离的医生或者护士进行删除,或者将新医生或新护士加入若干个群中;
11.(b)某个患者之前患白血病,当初创建的群里面的群成员是与白血病相关的医护人员,在治疗好白血病一段时间之后,该患者又得了淋巴瘤;那么现有的做法是重新创建一个群,这个群里面的群成员是与淋巴瘤相关的医护人员;不利于医生向前查看病史记录;
12.上述(a)和(b)两种情况均造成了群管理混乱、重复,不利于医护人员对患者和患者群的管理。


技术实现要素:

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.图1是本发明实施例示出的动态群构成示意图;
40.图2是本发明实施例示出的医护人员群列表获得流程图;
41.图3是本发明实施例示出的群成员动态构成图。
具体实施方式
42.下面结合附图与实施例对本发明作进一步说明。
43.应该指出,以下详细说明都是例示性的,旨在对本发明提供进一步的说明。除非另有指明,本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。
44.需要注意的是,这里所使用的术语仅是为了描述具体实施方式,而非意图限制根据本发明的示例性实施方式。如在这里所使用的,除非上下文另外明确指出,否则单数形式也意图包括复数形式,此外,还应当理解的是,当在本说明书中使用术语“包含”和/或“包括”时,其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
45.需要注意的是,附图中的流程图和框图示出了根据本公开的各种实施例的方法和系统的可能实现的体系架构、功能和操作。应当注意,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,所述模块、程序段、或代码的一部分可以包括一个或多个用于实现各个实施例中所规定的逻辑功能的可执行指令。也应当注意,在有些作为备选的实现中,方框中所标注的功能也可以按照不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,或者它们有时也可以按照相反的顺序执行,这取决于所涉及的功能。同样应当注意的是,流程图和/或框图中的每个方框、以及流程图和/或框图中的方框的组合,可以使用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以使用专用硬件与计算机指令的组合来实现。
46.实施例一
47.本实施例提供了一种医患群组的动态构建方法,本实施例以该方法应用于服务器进行举例说明,可以理解的是,该方法也可以应用于终端,还可以应用于包括终端和服务器和系统,并通过终端和服务器的交互实现。服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务器、云通信、中间件服务、域名服务、安全服务cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等,但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本技术在此不做限制。本实施例中,该方法包括以下步骤:
48.获取指定患者信息与指定医疗小组信息的关联关系;
49.当需求响应时,根据指定患者信息与指定医疗小组信息的关联关系,创建包括指定患者的群;其中,所述医疗小组信息包括医疗小组成员;
50.当需求响应时,根据所述需求响应实现所述群内的指定患者与指定医疗小组成员的信息交互;
51.当接收到操作指令时,根据操作指令对所述指定医疗小组成员的信息进行相应修改。
52.作为一种或多种实施方式,所述获取指定患者信息与指定医疗小组信息的关联关系包括:
53.确定指定医疗小组成员的信息,根据指定医疗小组成员的信息确定指定医疗小组id;
54.根据指定患者id与指定医疗小组id的关联关系,确定指定患者信息与指定医疗小组信息的关联关系。
55.作为一种或多种实施方式,允许满足设定条件的任何人加入包括指定患者的群,且允许所述群内的所有群成员查看所有聊天记录;具体地:
56.允许满足指定患者协同人的协同人员加入或退出包括指定患者的群;
57.允许医护人员通过加入指定患者的医疗小组来加入包括指定患者的群;
58.允许医护人员通过退出指定患者的医疗小组来退出包括指定患者的群;
59.允许通过更换指定患者的医疗小组,改变指定患者的群中所有的医护人员。
60.作为一种或多种实施方式,所述根据操作指令对所述指定医疗小组成员的信息进行相应修改具体包括:根据删除指令删除所述指定医疗小组内的医护人员id、根据添加指令添加新的医护人员id进入所述指定医疗小组id以及根据替换指令将所述指定医疗小组id替换为其他医疗小组id。
61.下面具体阐述本实施例的具体技术方案:
62.医疗小组:由若干医生和护士组成的、为便于管理设置的小组,包括审核医生、医生和护士。审核医生由高年资或高级别医生担任,负责解决医疗小组内的疑难问题和进行诊疗决策,针对一个具体患者,区分主管医生和辅助医生、主管护士和辅助护士;一个医生可以属于若干医疗小组;医疗小组是构成患者群的医护人员,由于医疗小组的管理是动态的,患者群中的成员也就是动态的。医疗资源分配原则依照医疗人力资源的规则,将各级职称的医护人员合理搭配,组成一定数量人数的医疗小组。
63.主管医生或主管护士:是当前患者的主要负责医生或护士,承担该患者的主要随访工作。医疗小组中的其他医生或护士负责辅助主管医生和护士,对其工作进行协助和补充;
64.协同人:通常为辅助患者完成随访工作的患者亲属,或参与患者随访过程的人员,与患者本人有相同的权限;
65.患者群:以一个患者为核心,由患者、当前患者的协同人、当前患者的医疗小组中的所有医生和护士构成一个动态群;
66.授权:医护人员或患者经审核人员批准进入相应群和查看群消息的过程;
67.交互:医护人员与患者在临床诊疗、随访过程中进行信息沟通的功能,在一个固定
的对话窗口中,一个患者群中所有人能够发起对话或看见别人的对话,可以通过录入文字、上传文件或拍照上传等方式进行;
68.针对现有随访过程的困难,采用移动端系统,通过定义医疗小组,为每一个患者分配:主管医生、主管护士、辅助医生和辅助护士,并根据医疗小组中的角色定义规范聊天群中的权限,实现了随访过程的提醒、交互和信息存储、交换、查询等功能。本实施例所采用的技术方案如下:
69.医患群组的动态构建方法,该实现方法具体包括如下步骤:
70.步骤101、建立医疗小组,系统分配id,录入医疗小组名称、小组介绍等管理元数据;建立原则是按照医疗人力资源的规则,将医生和护士合理搭配,将各级职称的医护人员合理搭配,组成5到6人的医疗小组;
71.步骤102、增加医护人员,每个医疗小组增加若干医护人员;一个医护人员可以加入一个或多个医疗小组;
72.步骤103、每个患者分配一个医疗小组为其服务;
73.步骤104、在前述步骤的基础上,构造以患者为中心的动态群。即,针对每一个患者,设备中的群是固定的,以患者姓名、年龄等信息命名;但是群中的其他成员是动态的,可根据诊疗、随访需要及其它实际情况动态组织群成员;
74.步骤105、在步骤104的基础上,设备以患者群为核心动态分配和管理随访过程的所有权限、提醒、交互等相关功能;
75.其中,医疗小组,具体内容为:一个医疗小组由审核医生、医生和护士组成,其中审核医生是小组负责人,负责审核或解决疑难问题,医生和护士分别有若干人,配合工作,为患者的服务;一个医疗小组指定具体患者后,进一步需要为这个患者指定主管医生和主管护士,他们具体负责这个患者,小组中的其他人成为这个患者的辅助医生或辅助护士。
76.以患者为中心的动态群,具体包括:患者群不是患者或某个医护人员人为创建的,而是设备实时自动将患者、该患者的协同人以及该患者的医疗小组中的医生和护士组成动态的患者群;在群的对话窗口中,所有当前成员拥有相同的权限;群成员可以查看所有对话窗口信息,后进入的成员也可查看既往的诊疗过程和信息。如图3所示。
77.患者群是动态的,具体包括:患者或患者协同人进入群时,设备根据该患者的医疗小组,自动将其中的医护人员加入;医护人员只能看见其所属的医疗小组管理的患者群,其进入某个患者的群时,自动根据这个患者的医疗小组,创建群中的人员。
78.为了维护患者的个人隐私,设备仅将这个患者的群展示给这个患者或其协同人。
79.设备将一个医护人员所在医疗小组管辖的所有患者的群展示给该医护人员。
80.随访过程中,根据患者实际情况,调整医护人员,是通过维护设备中的医疗小组成员或重新分配医疗小组完成的,从而符合了临床实践的实际情况。
81.下面结合具体实施例对本发明做进一步说明,如图1所示:
82.患者的动态群本身只保存自己一个成员;在授权、交互等群事件发生时,设备根据其医疗小组关联关系动态增加其他群成员。
83.表1为医疗小组和医护人员关联关系示例表:
84.医疗小组id医护人员id组内角色序号g001y0001审核医生1
g001y0002医生2g001h0001护士3g001h0002护士4g002y0003审核医生1g002y0004医生2g002y0002医生3g002h0003护士4
85.表中可见,医疗小组g001中包含四位医护人员,其中y0001是审核医生;其中医生y0002同时属于g001和g002两个医疗小组,表中序号为医护人员在各个医疗小组中的顺序。
86.表2为患者和医疗小组关联关系示例表:
[0087][0088][0089]
表中可见,目前是医疗小组g001为患者370102xxxxxxxxx11x服务。
[0090]
患者要进入群聊天页面和医护人员交流时,设备自动将群成员增加为:370102xxxxxxxxx11x、y0001、y0002、h0001、h0002;
[0091]
医生y0001在获取自己所管理的群时(授权过程),设备自动将医疗小组g001管辖的所有患者的群推送给他,本实例为患者370102xxxxxxxxx11x和370124xxxxxxxxx136的群;
[0092]
医生y0001要进入370102xxxxxxxxx11x的群聊天页面进行交流时,设备自动将群成员增加为:370102xxxxxxxxx11x、y0001、y0002、h0001、h0002。
[0093]
设备支持表1和表2数据的维护,举例描述为:只需要将医生y0002从医疗小组g001中移除,即删除表1中的对应记录,患者370102xxxxxxxxx11x再次进入自己的群时,群成员中即没有了医生y0002;可以将患者370102xxxxxxxxx11x的医疗小组更换为g002,患者370102xxxxxxxxx11x再次进入自己的群时,设备自动将群成员变成:y0003、y0004、y0002和h0003
[0094]
本实施例中,“患者”包括其协同人,是患者动态群的核心人员;“医护”是医护人员,由医护人员组成医疗小组,一个医护人员可以是若干医疗小组的成员;每一个患者,只对应一个医疗小组,该医疗小组中的医护人员是该患者动态群的所属人员;同一个医疗小组,可以为若干名患者服务,所以一个医护人员可以属于若干个群;系统通过维护医疗小组人员、给患者分配或更换医疗小组实现患者群的动态管理。
[0095]
需要强调的是,本实施例所述的动态群区别于现有的微信群,对于微信群而言,微信群是首先建立一个群,然后群成员逐个拉入成员、踢出成员,或者成员主动退群;群聊时进入相应群组进行交互;长期不用自动隐藏或群组主动删除。微信群建立后才能使用,建立后一直存在,不使用了可以删除,删除后就不能再聊天了。微信群的群成员是“固定的”,拉
入、踢出或退群,可以改变群成员,当前是群成员才能入群聊天,聊天内容也是这个成员入群开始到退群结束。
[0096]
本实施例所述的动态群是以患者为中心,患者进入随访系统app,自动就有了这个患者的“动态群”,患者加入随访系统app时,给他指定一个医疗小组,在使用过程中,可以更换医疗小组;在不使用的时候群成员是不确定的,在用户进入对应患者动态群时将患者本人、患者协同人和患者的医疗小组成员拉在一起,建立这个群的群成员,然后开始交互。其中,医疗小组成员和患者没有关系,和医院行政管理相关,是医疗资源分配的。
[0097]
也就是说,动态群在使用时现组织(查找)群成员;聊天交互后退出群聊,本次群成员信息放弃;下次(或别人)要进入这个群时,再次组织群成员。
[0098]
如果医护人员想要与某患者进行交互,首先需要查找该患者,而不是群;然后系统后台接收到医护人员要和该患者交互时,系统后台查找与这个患者相关联的“群成员”,构建动态群后进入交互,即医护人员的发送的消息是发送给了这个患者的“动态群”,其他医护人员要与这个患者交互时,也是系统查找这个患者的“群成员”,组织后交互,交互时的内容是所有向这个患者的动态群中发送的内容。这个“动态群”是一直存在的(一个患者一个,患者加入随访系统app时就有),但是群成员是不确定的,只有开始交互的时候,才需要计算;所以群成员的聊天内容不限制于“自己加入这个群的时间”,而是这个群从创建到现在的所有。实际医疗工作中,不能多个患者一个群(患者信息保密要求)。而一个患者一个群,如果按照微信群方式,建群非常麻烦,需要后台建立进程批量处理,数据一致性等管理相对麻烦。本实施例通过以患者为中心的动态群的设计和实现,即实现了一个患者一个群的要求,也实现了难点分离;即:群成员的设置不是逐个患者或逐个医护人员去关心具体群的成员,而是关心医疗资源的分布(设置医疗小组),患者服务的需要(为患者指定医疗小组)。
[0099]
如果采用微信群那样存储并管理群成员,那么以下情况下,要更新群成员:
[0100]
1、在患者更换医疗小组时,此时去掉所有原医疗小组医护人员,增加新医疗小组医护人员;
[0101]
2、在医疗小组医护人员变化时,此时要更新所有此医疗小组负责的患者的群;
[0102]
显然,上面第一条相对简单,但是第二条就非常多了,一个医疗小组管理的患者很多,相当于一个医护人员的简单调动,要更新大量的患者群成员。此时为保证数据一致性,需要数据库的“事务锁”,从而严重影响相关群的交互。显然在微信等社交软件中,群成员的管理不存在这种情况,所以在微信等社交软件中不需要这么做。
[0103]
而且,本实施例所述的动态群中的群成员没有存储,是在使用时动态计算的。对一个群成员来说,没有什么时候被拉入群或踢出群的说法,只有当前时刻是否在这个群中的判断。
[0104]
实施例二
[0105]
本实施例提供了一种医患群组的动态构建系统。
[0106]
一种医患群组的动态构建系统,包括:
[0107]
关系确定模块,其被配置为:获取指定患者信息与指定医疗小组信息的关联关系;
[0108]
群创建模块,其被配置为:当需求响应时,根据指定患者信息与指定医疗小组信息的关联关系,创建包括指定患者的群;其中,所述医疗小组信息包括医疗小组成员;
[0109]
交互模块,其被配置为:当需求响应时,根据所述需求响应调用群创建模块动态创
建群,实现所述群内的指定患者与指定医疗小组成员的信息交互;
[0110]
动态变化模块,其被配置为:当接收到操作指令时,根据操作指令对所述指定医疗小组成员的信息进行相应修改。
[0111]
此处需要说明的是,上述关系确定模块、群创建模块、交互模块和动态变化模块与实施例一中的步骤所实现的示例和应用场景相同,但不限于上述实施例一所公开的内容。此外,上述模块作为系统的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。
[0112]
实施例三
[0113]
本实施例提供了一种医患群组的动态构建系统。
[0114]
一种医患群组的动态构建系统,采用实施例一所述的医患群组的动态构建方法,包括:
[0115]
医护端,通过网络连接至后台服务,用于提供指定医疗小组信息,以使患者端通过识别指定医疗小组信息,建立患者信息与指定医疗小组信息的关联关系;用于查找患者,并进入对应患者的群;
[0116]
患者端,通过网络连接至后台服务,通过识别医护端提供的指定医疗小组信息,建立患者信息与指定医疗小组信息的关联关系,创建包括指定患者的群;
[0117]
后台服务器,用于提供指定医疗小组信息和患者信息,通过网络与医护端及患者端连接,用于在医护端或患者端,建立患者信息与指定医疗小组信息的关联关系,以使当需求响应时,动态创建患者的群,并完成信息交互任务。
[0118]
如图2所示,所述医护端用于显示该医护端对应的医护人员所在的所有医疗小组列表,以及显示该医护人员所在的所有医疗小组所负责的患者。
[0119]
作为一种或多种实施方式,所述患者端通过扫描医护端提供的指定医疗小组的二维码,创建包括患者端对应指定患者的群。
[0120]
本领域内的技术人员应明白,本发明的实施例可提供为方法和系统。因此,本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
[0121]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(read-only memory,rom)或随机存储记忆体(random accessmemory,ram)等。
[0122]
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1