一种诊后随访方法、系统及存储介质与流程

医药医疗技术的改进;医疗器械制造及应用技术1.本技术涉及随访系统的技术领域，尤其是涉及一种诊后随访方法、系统及存储介质。背景技术：2.诊后随访是指医院对诊治后的患者通过各种方式，定期跟踪了解患者病情变化，通过发布随访任务，病友患者配合完成，对患者进行专业性康复指导的一种医疗康复观察行为。3.医学上有很多疾病如一些慢性疾病，治疗和恢复会需要一个漫长的过程，由于如今住院平均时间越来越短，越来越多的患者的居家后期康复时间变得越来越长，这就意味着患者的后期护理、病情观察及健康保健等方面的需求越来越高，而对于患者的诊后回访工作，不仅能满足患者在院外的康复治疗需求，也能趋近医院的医疗、服务工作的提高。4.如今的患者在出院并院外进行康复时，当需要对自身的康复问题进行咨询的时候，普遍使用网络搜索或去医院进行咨询的方法，而医院方想要了解到患者的身体状况的时候也是使用电话等联系方式与患者取得联系后进行随访工作，医院和患者双方的这种随访方式效率较低，没有办法做到信息的同步性和丰富性。技术实现要素：5.为了提高诊后随访的工作效率，本技术提供一种诊后随访方法、系统及存储介质。6.第一方面，本技术提供的一种诊后随访方法，采用如下的技术方案：一种诊后随访方法，包括以下步骤：患者根据就诊信息在患者端进行注册以得到相对应的患者账号；平台端获取患者账号并进行存储，所述平台端根据所述患者账号所对应的就诊信息将病情标签添加至所述患者账号，所述平台端根据就诊信息及病情标签将所述患者端连接于相对应的医师端并根据预设的随访模板生成相应的随访任务，所述病情标签表征为患者的患病类型；所述医师端根据所述随访任务进行随访，以得到随访结果，并将随访结果发送至平台端。7.在其中的一些实施例中，所述平台端根据所述患者账号所对应的就诊信息将病情标签添加至所述患者账号，包括：根据所述注就诊信息获取患者的就诊病因，并根据就诊病因创建病情标签，并定义为第一病情标签；将就诊病因输入至历史病因库，判断所述历史病因库内是否存在与就诊病因相关联的高风险并发症信息，所述历史病因库包括各类疾病信息及其相关联的高风险并发疾病信息；若存在，则根据所述就诊病因相关联的高风险并发症信息创建病情标签，并定义为第二病情标签。8.在其中的一些实施例中，根据所述就诊病因相关联的高风险并发症信息创建病情标签，并定义为第二病情标签，还包括：获取所述就诊病因相关联的高风险并发症信息中的重点检查项数值，将所述就诊信息中的检查项数值与所述重点检查项数值进行比较，以判断是否有至少两个检查项数值出现异常，其中，所述就诊病因相关联的高风险并发症信息中的重点检查项数值表征为患者患上此病症时的极限理论数值；若就诊信息中的至少两个检查项数值出现异常，那么将此第二病情标签设置为显性标签；若就诊信息中少于两个检查项数值出现异常，那么将此第二病情标签设置为隐性标签。9.在其中的一些实施例中，所述平台端根据就诊信息及病情标签将所述患者端连接于相对应的医师端并根据预设的随访模板生成相应的随访任务，包括：所述平台端存储有各类疾病相对应预设的随访模板，所述随访模板至少包括患者姓名、就诊信息、患者联系方式、随访日期、随访日志、康复计划、医生姓名、医生联系方式；所述平台端根据病情标签获取相对应的随访模板；所述平台端根据就诊信息自动对随访模板内的信息进行初步填写，并生成相应的随访任务，所述随访任务包括多个随访节点，所述多个随访节点皆对应于一随访时间。10.在其中的一些实施例中，所述医师端根据所述随访任务进行随访，以得到随访结果，包括：所述医师端接收随访任务，并根据所述随访任务的随访节点与所述患者端进行连接以进行随访，并根据随访过程对随访任务中的随访节点所对应的随访模板进行更新填写；当随访完成后，医师端将更新填写后的随访模板存储至平台端以得到随访结果，患者通过患者端对随访结果进行获取查看。11.在其中的一些实施例中，所述医师端包括就诊医师端、对接医师端和值班医师端，所述平台端根据就诊信息将所述患者端连接于相对应的医师端后，患者使用患者端进行病情查询包括以下步骤：所述平台端包括咨询问答库，判断所述患者的病情查询是否包含在所述咨询问答库内；若包含，则所述对接医师端获得答复权限，并通过咨询问答库获取与病情查询相匹配的答复话术进行答复；若不包含，所述对接医师端进行答复后将答复内容及答复权限转送至就诊医师端处进行权限审批，若就诊医师端通过权限审批，则答复内容发送至患者端，若就诊医师端不通过权限审批，则清除所述答复内容且所述答复权限移动至就诊医师端处；若对接医师端的答复时间超过预设时间，则所述答复权限移动至值班医师端处，所述值班医师端判断病情查询是否包含在所述咨询问答库以进行答复。12.在其中的一些实施例中，所述平台端根据所述患者账号所对应的病情标签向所述患者账号内推送宣教内容，具体包括以下步骤：若所述患者账号只包含第一病情标签，则根据所述第一病情标签推送相对应的第一顺位宣教内容；若所述患者账号包含第一病情标签及第二病情标签，则根据所述第一病情标签推送相对应的第一顺位宣教内容并根据第二病情标签推送相对应的第二顺位宣教内容，其中，第一顺位宣教内容的推送优先级高于第二顺位宣教内容的推送优先级。13.在其中的一些实施例中，还包括评分方法，包括以下步骤：当所述医师端基于所述患者端的操作进行交互更新动作后，所述平台端基于预设的第一得分规则对所述医师端进行智能评分以得到第一得分，所述患者端基于预设的第二得分规则对所述医师端进行人工评分以得到第二得分，所述平台端接收第一得分和第二得分后根据预设的计分规则算出最终得分，并将最终得分关联至医师端的账号上进行显示。14.第二方面，本技术提供一种诊后随访系统，采用如下的技术方案：一种诊后随访系统，包括患者端、平台端和医师端，其中：所述患者端用于供患者根据就诊信息在患者端进行注册以得到相对应的患者账号，患者使用患者端对随访结果进行查看；所述平台端包括存储模块、随访模块、标签模块，所述平台端获取患者账号并根据就诊信息将所述患者端连接于相对应的医师端，所述存储模块对所述患者账号进行存储，所述标签模块用于根据所述患者账号所对应的就诊信息将病情标签添加至所述患者账号，所述随访模块用于根据预设的随访模板生成相应的随访任务；所述医师端用于供医师根据所述随访任务对患者端的患者进行随访，以得到随访结果。15.第三方面，本技术提供一种计算机存储介质，采用如下的技术方案：一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现任一项上述的诊后随访方法。16.综上所述，本技术包括以下有益技术效果：1.患者将根据就诊信息在患者端进行注册，并得到相应的患者账号，并根据就诊信息获得相应的病情标签并进行显示，且根据就诊信息中填写的医生信息连接至相应的医师端，实现患者端和医师端的线上连接，医师端可以通过患者端上显示的病情标签得到相应的随访任务，并通过与患者端连接以进行线上随访，并将随访结果发送至平台端供患者查看，实现快速建立随访任务，并通过线上的方式方便的进行随访工作，无需患者在康复期间反复去医院与医生进行线下随访复诊，提高了随访效率。附图说明17.图1是本技术实施例的整体流程示意图；图2是本技术实施例中设置病情标签的逻辑示意图；图3是本技术实施例中进行随访时的流程示意图；图4是本技术实施例中进行问询答复时的逻辑示意图；图5是本技术实施例中进行问询答复时判断是否超过答复时间的逻辑示意图；图6是本技术实施例中对医师端进行评分时的流程示意图。具体实施方式18.为更清楚地理解本技术的目的、技术方案和优点，下面结合附图和实施例，对本技术进行了描述和说明。然而，本领域的普通技术人员应该明白，可以在没有这些细节的情况下实施本技术。在一些情形下，为了避免不必要的描述使本技术的各方面变得晦涩难懂，对已经在较高的层次上描述了众所周知的方法、过程、系统、组件和/或电路将不作过多赘述。对于本领域的普通技术人员来说，显然可以对本技术所公开的实施例作出各种改变，并且在不偏离本技术的原则和范围的情况下，本技术中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本技术不限于所示的实施例，而是符合与本技术所要求保护的范围一致的最广泛范围。19.除另作定义外，本技术所涉及的技术术语或者科学术语应具有本技术所属技术领域具备一般技能的人所理解的一般含义。本技术所使用的术语仅出于描述特定实施例的目的，而不旨在于对本技术的限制。如本技术所使用的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制，它们可以是单数或者复数。在本技术中所涉及的术语“包括”、“包含”、“具有”及其任何变体，其目的是涵盖不排他的包含；例如，包含一系列步骤或模块（单元）的过程、方法和系统、产品或设备并未限定于列出的步骤或模块（单元），而可包括未列出的步骤或模块（单元），或者可包括这些过程、方法、产品或设备固有的其他步骤或模块（单元）。20.在本技术中所涉及的“多个”是指两个或两个以上。通常情况下，字符“/”表示前后关联的对象是一种“或”的关系。在本技术中所涉及的术语“第一”、“第二”、“第三”等，只是对相似对象进行区分，并不代表针对对象的特定排序。21.本技术所涉及的术语“系统”、“引擎”、“单元”、“模块”和/或“块”是一种用于按级别区分不同级别的不同组件、元件、零件、部件、装配件、或功能的一种方法。这些术语可以被其他能够达到相同目的的表达替换。通常，本技术涉及的“模块”、“单元”或“块”是指硬件或者固件中体现的逻辑或软件指令的集合。本技术描述的“模块”、“单元”或“块”可以作为软件和/或硬件实现，并且在作为软件实现的情形下，他们可以被存储在任何类型的非易失性计算机可读存储介质或存储设备中。22.在一些实施例中，软件模块/单元/块可以被编译并被链接到可执行程序中。将意识到，软件模块可以是可从其他模块/单元/块或从其自身调用的，和/或可以响应于检测到的事件或中断而被调用。配置为在计算设备上执行的软件模块/单元/块可以设置在计算机可读存储介质上，例如光盘、数字视频盘、闪存驱动器、磁盘、或任何其他有形媒体，或作为数字下载（并且可以最初以压缩或可安装的格式存储，该格式需要在执行之前进行安装、解压或解密）。这样的软件代码可以部分地或全部地存储在正在执行的计算设备的存储设备上，并应用在计算设备的操作之中。软件指令可以被嵌入到固件，例如eprom中。还将意识到，硬件模块/单元/块可以被包括在连接的逻辑组件中，例如门和触发器，和/或可以被包括在可编程单元中，例如可编程门阵列或处理器。本文描述的模块/单元/块或计算设备功能可以被实现为软件模块/单元/块，还可以以硬件或固件来表示。通常，本文描述的模块/单元/块，它们可以与其他模块/单元/块组合，或者尽管它们是物理组织或存储的，但也可以被划分为子模块/子单元/子块。该描述可以适用于系统、引擎或其一部分。23.将理解的是，当单元、引擎、模块或块被称为在另一单元、引擎、模块或块“上”、“连接”或“耦合至”另一单元、引擎、模块或块时，其可以直接在其它单元、引擎、模块或块上，与其连接或耦合或与之通信，或者可以存在中间单元、引擎、模块或块，除非上下文另有明确说明。在本技术中，术语“和/或”可包括任何一个或以上相关所列条目或其组合。24.以下结合附图1-6对本技术作进一步详细说明。25.本技术实施例公开一种诊后随访方法。26.如图1所示，一种诊后随访方法包括：s100，患者根据就诊信息在患者端进行注册以得到相对应的患者账号。27.就诊信息包括患者的姓名、性别、联系方式、身份证号码、就诊医师端、挂号信息、检查数值、检查结果、取药信息等信息，其中姓名、性别、联系方式、身份证号码、就诊医师端等信息可以通过手动填写的方式进行填写，而挂号信息、检查数值、检查结果、取药信息等信息可以通过拍摄图片的方式进行上传，当患者进行注册后，会得到患者相对应且具有唯一性的患者账号，此账号用于表征该患者的理疗全过程的记录对象信息。28.后续患者想要再次登录此账号的时候，只需要输入自己在注册时预设的登录信息即可，如身份证号码、手机号等。29.s200，平台端获取患者账号并进行存储，平台端通过患者账号所对应的就诊信息将病情标签添加至患者账号，平台端根据就诊信息及病情标签将患者端连接于相对应的医师端并根据预设的随访模板生成相对应的随访任务。30.其中，病情标签表征为患者的患病类型。如患者a的就诊信息内显示，患者a的收缩压为170mmhg，舒张压为101mmhg，其大于了正常标准中120-139mmhg的收缩压、80-89mmhg的舒张压，且医生的诊断结果为2级高血压，则生成“2级高血压”的病情标签并将此病情标签添加至患者账号，且需要注意的是，病情标签为显性标签，也就是在用户端和医师端上进行显示时，患者的患者账号旁会对此病情标签进行显示，以方便医生对患者的病情进行快速了解，无需使得医生在面对较多患者时需要反复查看患者上传的就诊信息才能得知患者的病情。31.如图2所示，s210，根据就诊信息获取患者的就诊病因，并根据就诊病因创建病情标签，并定义为第一病情标签。32.患者在医院进行就诊时，往往会在检查后、手术后等时候得到一份病情检查结果和患病的病因，如在病例上除了检查的数值、手术的日志外还写有患有的疾病类型，如骨折、癌症、冠心病等，这时平台端可以通过患者在患者端上传的就诊信息，如病历图片等，经过图片识别和神经算法得到就诊信息中患病类型，也就是就诊病因，并根据就诊病因创建病情标签，此标签为显性标签，也就是会显示在患者的患者账号上进行显示，并把这个病情标签定义为第一病情标签。33.又例如，在患者a入院前，入院的入院诊断为脑梗塞，在进行治疗后出院时，出院诊断上为脑梗塞与高同型半胱氨酸血症，这可能是患者在住院期间因脑梗塞而出现相关联的疾病的情况，这时根据患者上传就诊信息的时间端为准，若患者在进行检查而没有入院时上传就诊信息，则将“脑梗塞”作为第一病情标签，若患者在出院时再次上传就诊信息，则将第一病情标签更新为“脑梗塞”和“高同型半胱氨酸血症”。需要注意的是，在患者入院进行治疗的过程中，医师端也可以通过更新就诊日志的方式手动对患者的第一病情标签进行更新。34.s211，将就诊病因输入至历史病因库，判断历史病因库内是否存在与就诊病因相关联的高风险并发症信息。35.当平台端获取到患者的就诊病因时，平台端可以根据就诊病因推断出患者是否可能存在与就诊病因相关联的高风险并发症。而在平台端内设置有历史病因库，历史病因库内存储有历史诊断过程中所有患者所得的疾病及在治疗就诊过程中出现的高风险并发症情况，并将多种原疾病-并发症的关联关系进行整合连接，得到一个具有若干组关联疾病串构成的疾病提取库，其中关联疾病串可以是一对一或一对多，如高血压作为原疾病时，存在的高风险并发症为中风、脑梗塞、脑血栓、肾小球动脉硬化、肾脏损害、肾功能衰竭，肩膀骨折的高风险并发症为关节炎。36.又如轻微感冒因为病状较轻，在大部分时候是不会出现高风险并发症的，可以根据临床的深入去判断轻微感冒的病情是否会加重而再去判断是否存在相应的高风险并发症。37.其中，多个联网医院的历史病因库可以实现共享。38.s212，若存在，则根据就诊病因相关联的高风险并发症信息创建病情标签，并定义为第二病情标签。39.若患者治疗肺炎，当患者将就诊信息进行上传后，平台端根据就诊信息得到其就诊病因为肺炎，并将“肺炎”输出至历史病因库内，且历史病因库内存在与“肺炎”相关联得高风险并发症为“脓毒血症”、“病毒性心肌炎”和“呼吸衰竭”，这时平台端将这三个高风险并发症定义为第二病情标签。40.通过这种方法，在对患者的患病标签进行定义时，可以在对已经确诊的病情进行标记，也同时对患者可能出现的高风险并发症进行标记，使得患者和医生都能提前对已经患上的疾病及可能在未来并发的疾病进行标记预警，并提前做好预防准备。如医生看到患者患上了肺炎，可以在对肺炎进行治疗的同时对可能出现的高风险并发症的身体检查指标进行同步检查，减少突发并发症而无法及时进行救治的可能性。41.进一步的，因为有一些关于血管、心脏、器官等的疾病会关联有数量较多的高风险并发症出现，而将数量较多的高风险并发症都添加成第二病情标签，不仅要在患者账号上显示过多的病情标签，还会提高患者的忧虑感，且还会对医生的工作添加较多的压力，所以为了能对第二病情标签进行一定的管理分类，故在s212的基础上，还包括以下步骤：s213，获取就诊病因相关联的高风险并发症信息中的重点检查项数值，将就诊信息中的检查项数值与重点检查项数值进行比较，以判断是否至少有两个检查项数值出现异常。42.就诊病因相关联的重点检查项数值表征为患者患上此病症时的极限理论数值，且当某一项数值高于或低于这个极限理论数值，那么便确定该检查项数值异常，而到底是高于还是低于，则通过临床医学规定进行指定。43.如患者a患上了肺炎，其高风险并发症为“脓毒血症”、“病毒性心肌炎”和“呼吸衰竭”，我们以“脓毒血症”为例，脓毒血症重点检查项为白细胞、c反应蛋白、血浆降钙素原、肌酐、凝血功能、血小板、血浆总胆红素、血乳酸等，这些指标是判断是否患上脓毒血症的重点检查项，将就诊信息中的检查项数值和这些重点检查项数值对比，以判断是否有数值出现了异常。44.s214，若就诊信息中的至少两个检查项数值出现异常，那么将第二病情标签设置为显性标签。45.还是以上述的“脓毒血症”为例，当白细胞数量大于12×10的9次方每升或小于4×10的九次方每升时，白细胞的检查项数值为异常、当c反应蛋白超过正常值两倍标准差以上，c反应蛋白的检查项数值为异常、当血浆降钙素原超过正常值两倍标准差以上，血浆降钙素原的检查项数值为异常、当肌酐增高大于44.2微摩尔每升时，肌酐的检查项数值为异常、当活化部分凝血活酶时间aptt大于60秒时，凝血功能的检查项数值为异常、当血小板小于100×10的九次方每升时，血小板的检查项数值为异常、当血乳酸大于1毫摩每升时，血乳酸的检查项数值为异常。46.那么在将就诊信息中的若干检查项数值与重点检查项数值进行比较后发现，患者a的白细胞、c反应蛋白、肌酐和血小板的数值皆落在重点检查项的极限理论数值外，说明这四项检查项数值是异常的，且出现异常的检查项数值个数大于了两个，那么就认为该患者极大可能在患上肺炎的同时，也患上了脓毒血症这一肺炎的高风险并发症，这时便将“脓毒血症”作为显性的第二病情标签并在患者账号上进行显示，提醒患者和医生注意并发症出现的可能性。47.如图2所示，以此类推，将患者就诊信息中的检查项数值与可能存在的高风险并发症的重点检查项数值皆进行比较，筛选出较高风险患上的并发症，做为显性标签进行显示。48.s215，若就诊信息中少于两个检查项数值出现异常，那么将第二病情标签设置为隐性标签。49.以上述的“脓毒血症”为例，当把就诊信息中的检查项数值与重点检查项数值进行比较后发现，只有白细胞这一项数据出现了异常，那么便认为患者a极大概率还没有患上脓毒血症这一高风险并发症，那么就将这一个第二病情标签设置为隐性标签，隐性的第二病情标签不会显示在患者账号上，而是进行隐藏处理，减少对患者的心理负担的同时，也可以减少医生的工作压力。当后续就诊信息中的检查项结果进行更新后，如果检查项结果数值变化而导致多于两个检查项结果出现了异常，那么这个隐性的第二病情标签会更新成显性的第二病情标签。50.通过这种方法，将代表着就诊病因所可能引发的高风险并发症进行分类标签设置，设置显性的第二病情标签可以提醒患者和医生其可能大概率存在患有并发症的可能性，方便患者提前做好准备也方便医生进行后续的跟进治疗，设置隐性的第二病情标签可以对一些目前患病概率较低的并发症进行提前统计，无需医生一直对引发并发症的状况进行考虑，减少了医生的工作压力。51.进一步的，为了提高病情标签的提示直观性，平台端可以对病情标签进行颜色区分，区分规则可以通过日常使用积累意见以进行修改，如病情较为严重的第一病情标签使用红色标签，病情较轻的第一病情标签使用绿色标签，第二病情标签同一使用黄色标签，急性疾病使用橙色标签，慢性疾病使用黄色标签等等，因患者可能对一些较为生僻的疾病和并发症不是很了解，所以可能出现较为严重的疾病但是患者并不注意，或较轻的病情患者过分忧虑的情况，所以设置不同颜色的标签将病情标签进行区分，患者可以通过标签的颜色大致了解自身疾病的轻重缓急。52.进一步的，为了减少第二病情标签的误判，当患者端看到自己的患者账号上显示出某一项代表并发症的第二病情标签的时候，经过与医生的沟通后确认不存在第二病情标签上显示的第二病情标签时，患者端可以手动将第二病情标签进行取消显示或隐藏，而后续在出现该并发症症状出现或确定患上此并发症后，可以再手动将第二病情标签进行显示。53.患者端为日常使用的移动式联网设备，如手机、平板电脑、笔记本电脑、台式电脑等，也可以是移动式电子手表或医院方定制的患者康复手环等设备，且因为患者最常使用手机或随身的手表或手环对自身的患者账号进行查看，故当以为患者患病后，可能会有多项代表并发症的第二病情标签，这些标签可能无法在手机上一起进行显示，同时，就算可以一起显示也会显得界面过于臃肿，故在另一个实施例中，一个患者端界面中，只在患者账号名旁边显示一个第一病情标签和一个第二病情标签，且这个第二病情标签为平台端经过算法筛选出关联度最高或最高风险的并发症，也可以是患者自己手动调节的，而剩下的第二病情标签则通过数量角标的方式显示在第二病情标签上，如一个患者具有四个第二病情标签，而只对其中一个第二病情标签a进行显示，剩下的三个会在a的右上方显示一个“3”，代表其压缩了三个剩余没有显示的第二病情标签，用户可以通过点击唯一显示的一个第二病情标签以查看自己所有的第二病情标签。后续的医师端同理。54.如图3所示，其中，平台端根据就诊信息及病情标签将患者端连接于相应的医师端并根据预设的随访模板生成相应的随访任务，包括以下步骤：s220，平台端根据病情标签获取相对应的随访模板。55.平台端内预先存储有与各类疾病相对应的随访模板，随访模板上至少包括患者姓名、就诊信息、患者联系方式、随访日期、随访日志、康复计划、医生姓名、医生联系方式等。56.随访模板在一些细节处，面对不同的疾病有些许的区别，如急性疾病、慢性疾病等根据治疗时间的长短，随访模板中的随访日期、随访日志、康复计划模板等都会有一些不同。57.平台端根据病情标签内的内容寻找到相应的随访模板，如患者a的第一患病标签为“糖尿病”，则平台端会在存储的众多预设随访模板内选取糖尿病所对应的随访模板。通过这种方式，方便医师对随访模板中的内容进行填写更新，因为如果所有疾病都共同使用一个随访模板，可能会出现随访过程中发现随访模板与随访进程无法进行匹配的情况出现，而将若干随即模板根据病症进行分类，可以提高对应性和效率。58.举个较为极端的例子，若患者a患有癌症，患者b为细菌性肠炎，这时平台端通过患者a的“癌症”的第一病情标签获取相对应的随访模板，同时通过患者b的“细菌性肠炎”的第一病情标签获取相对应的随访模板，而患者a的病情明显严重于患者b，且癌症的治理时间、治疗周期、治疗方法是与细菌性肠炎完全不同的，故患者a的随访模板中，随访周期、随访日期、康复计划等与患者b的随访模板必定是完全不同的。故将不同疾病的随访模板进行分类管理有助于快速地进行随访工作。59.需要注意的是，随访模板的生成只针对于第一病情标签，而不会在自动生成阶段考虑第二病情标签，因为第二病情标签所代表的是并发症，而并发症很可能并没有发生，这时如果根据第二病情标签生成随访模板会提高医生的工作量，而针对于第二病情标签的生成可以等待治疗的深入后，如出现确诊第二病情标签中的并发症时，医生通过医师端手动生成。60.s221，平台端根据就诊信息自动对随访模板内的信息进行初步填写，并生成相应的随访任务。61.平台端根据就诊信息先自动对随访模板内的基本信息进行填写，如患者的姓名、性别、联系方式、医生姓名、患病种类、检查项数据等，经过填写后生成相应的随访任务，并将随访任务发送至相对应的医师端。当平台端填写数据时便可以根据就诊信息获知患者所关联的医生姓名，便可以根据医生信息将相应的随访任务发送至相对应的医师端。62.随访任务包括多个随访节点，多个随访节点皆对应于一个随访时间。63.s300，医师端根据随访任务进行随访，以得到随访结果，并将随访结果发送至平台端。64.s310，医师端接收随访任务，并根据随访任务的随访节点与患者端进行随访，并根据随访过程对随访任务中的随访节点所对应的随访模板进行更新填写。65.s320，当随访完成后，医师端将更新填写后的随访模板存储在平台端以得到随访结果，患者通过患者端对随访结果进行获取查看。66.如患者a需要进行一周一次的随访，随访时间定为每周周六的晚上5点，那么在这个随访时间内，医生需要通过与患者端进行连接以进行该节点下的随访任务，并根据随访过程将随访模板内的内容进行更新填写，如目前患者的整体状况、用药状况、随访判断、下次到院检查时间等等。当这一节点的随访任务完成后，医师将更新填写好的随访结果发送至平台端，患者端可以进行查看。67.其中，为了对医生对每个随访任务的随访节点进行提醒，可以在每个随访节点所对应的随访时间前一端预设时间设置提醒功能，以响铃等方式通过医师端对医生进行提醒。68.有时可能出现医生因为工作较多而忘记进行随访任务的情况发生，故患者端对于某一随访节点上的空白随访模板在一端预设时间内具有填写权限，需要注意的是，患者端的填写权限只能用于空白的随访模板，因为非空白的随访模板必定是医师端进行随访后填写的，患者可能会无意的对随访模板上的内容进行修改，这会对后续的治疗产生影响，而用户也只能在医生没有在预定的时间进行随访时，对这一时间点上所对应的节点上的随访模板进行修改，修改的权限可以只限定在随访日志、患者的整体状况、用药情况等内容，使得患者可以在医生无法进行随访时，先将自己的一些状态进行记录，等后续医生通过医师端看到患者更新的随访模板的内容后进行更新修改，以此保证随访任务的连续性。69.如图4和图5所示，同时，患者在接收随访以外，可能在日常治疗或康复过程中，会出现一些疑问想要询问医生，这时可能患者会不方便去医院的情况，这时患者可能会上网进行查询，而网络上常常会很多错误信息，这些错误信息可能会对患者的康复产生负面作用，这时，如何保证患者端和医师端的线上通讯顺畅性极为重要。70.在另一个实施例中，医师端包括就诊医师端、对接医师端和值班医师端。就诊医师端为患者就诊时，负责对患者进行检查、治疗工作的主治医生，对接医师端为与就诊医师相关联的对接医生，可以是同一科室的其他医生或对接医生所管理的医生等等，主要负责在就诊医师工作较忙时与患者进行对接沟通。而值班医生当就诊医生和对接医生皆不在线时负责应对一些突发状况发生的医生，值班医生一般保持24小时在线。71.平台端根据就诊信息将患者连接于相对应的医师端后，患者使用患者端进行病情查询包括以下步骤：s400，判断患者的病情查询是否包含在咨询问答库内。72.s410，若包含，则对接医师端获得答复权限，并通过咨询问答库获取与病情查询相匹配的答复话术进行答复。73.s420，若不包含，则在对接医师进行答复后将答复内容及答复权限转送至就诊医师端进行权限审批，若就诊医师端通过权限审批，则将答复内容发送至患者端，若就诊医师端不通过权限审批，则清除答复内容且答复权限移动至就诊医师端。74.咨询问答库包含平台端内，咨询问答库内存储有大量的患者常见问题，如某种药剂的用量、自身身体变化所可能带来的问题、何时能预约挂号、主治医生的出诊时间、检查项数值的问题等，并针对于每个问题设定有相对应的答复话术，如a药的使用方法-a药一天食用两次，每次3粒、医生a的出诊时间-医生a的出诊时间为周一到周四的早八点到晚五点等等。75.而当患者通过患者端进行问题询问时，对接医师端的医生看到问题后，搜索咨询问答库内是否存在相对应的答复话术，若包含，则直接使用咨询问答库内的答复话术进行回复。其中，查询方法可以使用常用的关键字提取的方式，如药品名称、医生姓名等，每个关键词可以对应于多个问题，而多个问题对应有多个答复话术，如当医生搜索药品a，会出现若干问题，如药品a的使用方式、药品a的使用禁忌、药品a的价格、药品a的副作用等，医生可以选取相应的答复话术进行回复。76.如今在很多领域中都使用平台端自动识别关键词，并通过关键词自动寻找答复话术的方法，但是本技术中，因医疗领域中，对于患者的问题具有较为明确的注意事项，如果通过自动智能回复出现回复错误的情况，使得患者错食的药品，会出现较大的安全事故发生，故在本实施例中，是通过医师手动查询关键词，并手动选择相对应的答复话术的方法，避免出现错误回复导致出现影响患者健康的问题出现。77.有一些问题会有一定的针对性，故无法在咨询问答库内找到，这时对接医师可以根据问题进行手动答复。在患者就诊时，主治医生会根据患者的病情制定一套康复计划和随访计划，而在患者询问一些康复内容或随访内容的问题时，对接医师可能会出现不了解康复计划和随访计划而出现错误答复的情况，而为了杜绝此类情况，当对接医师对问题进行手动答复后，需要经过就诊医师端的权限审批。78.这时，答复内容和答复权限会一同发送至就诊医师端，主治医生接受到后，通过查看答复内容来判断是否通过权限审批，若主治医生认为答复内容没有问题，则通过权限审批，答复内容会直接发送至患者端；若注意医生觉得答复内容与自己设定的康复计划和随访计划有所冲突，则不通过权限审批，这时对接医师端的答复内容会自动删除，并需要就诊医师端对问题进行答复并通过答复权限将答复内容发送至患者端。79.这么做的好处在于，当对接医师端进行答复后，就诊医师端只需要查看内容是否满足要求，如果满足则不再需要就诊医师进行答复，减少了主治医生的工作量，也同时能保证答复的内容对于患者是起到正确康复效果的，而不满足要求时，主治医生可以自己进行答复，以此在减少工作量的同时保证答复内容的准确性。80.s430，若对接医师端的答复时间超过预设时间，则答复权限移动至值班医师端处，值班医师端判断病情查询是否半酣在咨询问答库以进行答复。81.有时会出现对接医生因工作需要而无法及时对问题进行回复的情况发生，故设置一个预设时间，可以为3分钟或5分钟，当超过预设时间，答复问题的权限则移动至24小时在线的值班医师端处，值班医生会对问题进行答复。而值班医生在答复时，与对接医生端的答复逻辑是一样的，若问题包含在咨询问答库，则通过库内的答复话术进行答复，若不存在，则手动答复并需要通过就诊医师端的权限。82.以此可以保证患者端与医师端的通讯及时性，使得患者的问题可以尽快得到准确的答复，而无需进行长时间的等待。83.平台端还可以根据患者账号所对应的病情标签向患者账号内推送宣教内容，具体包括：s500，若患者账号只包含第一病情标签，则根据第一病情标签推送相对应的第一顺位宣教内容。84.s510，若患者账号包含第一病情标签及第二病情标签，则根据第一病情标签推送相对应的第一顺位宣教内容，并根据第二病情标签推送相对应的第二顺位宣教内容，其中，第一顺位宣教内容的推送优先级高于第二顺位宣教内容的推送优先级。85.宣教意为宣传教育，医师端可以上传大量的各类疾病关于治疗、康复、预防等主题的视频、文章、论文等内容至平台端，并根据不同的疾病类型进行分类。86.平台端再根据患病账号中的病情标签将这些宣教内容进行定向推送。87.而在推送时，因第一病情标签为就诊病因，第二病情标签为并发症，故在推送内容时需要设定推送的优先级，因为病人在观看几个宣教内容后会产生疲惫感，若将两种标签所对应的宣教内容一同进行推送，可能会出现患者看了几个第二病情标签所对应的内容后不再看第一病情标签对应的内容，故第一顺位宣教内容的推送优先级高于第二顺位宣教内容的推送优先级。88.如图6所示，其中，为了敦促医师端及时对患者进行随访、答疑等工作，该包括评分方法，包括以下步骤：s600，当医师端基于患者端的操作进行交互更新动作后，平台端基于预设的第一得分规则对医师端进行智能评分以得到第一得分，患者端基于预设的第二得分规则对医师端进行人工评分以得到第二得分，平台端接收第一得分和第二得分后根据预设的计分规则算出最终得分，并将最终得分关联至医师端的账号上进行显示进行交互更新动作指的是：患者端与医师端进行随访、医师端对患者端的问题进行答复、医师端对患者端进行的康复计划更新等等。89.其中，第一得分规则为：根据医师端进行交互的相应时间进行评分，在规定时间内进行解决的，如在规定时间内回复了患者端发出的问题或在规定的时间内进行了随访任务，则给予5分（在此例中，5分为满分），并随着超出规定时间的时间长短进行适量的扣分，如预设在10分钟内进行答复，若超过十分钟，每超过5分钟则扣除1分，以此类推计算出最终得分。90.第二得分规则为：根据使用患者端的患者的整体感受进行评分，如得到答复的时间长短、随访过程中医生的认真程度、对于随访结果的满意程度、对于被推送的宣教内容的满意程度等，可以选择给予0-5分（在本例中，5分为满分）。同时，为了得知患者的意见，可以使患者在评分的同时将扣分理由、意见进行填写，以敦促相应的医师进行改正。91.当平台端接收到第一得分和第二得分后，可以通过取平均值或加权的方式进行计算。取平均值的方式较为简单，如第一得分为5分，第二得分为4分，这时算出的平均值为4.5分，最后将4.5分做为最终得分，并关联至医师端的账号上进行显示。使用加权的方式是因为平台端的智能评分智能依据交互回复的时间，而患者的评分则是代表患者的真实体验，故患者的评分更大意义上代表着医师端的服务质量，所以可以将第一得分占有30%的权值系数，第二得分占有70%的权值系数，而若第一得分为5分，第二得分为3分，则经过（5*0.3+3*0.7）的计算后得到得数为3.6分。92.实际应用时，可以根据具体实施过程中出现的问题而对计分规则进行相应的更改。93.在另一个实施例中，还公开了一种诊后随访系统，包括患者端、平台端和医师端。94.患者端用于供患者根据就诊信息在患者端进行注册以得到相对应的患者账号，患者使用患者端对随访结果进行查看；平台端包括存储模块、随访模块、标签模块，平台端获取患者账号并根据就诊信息将患者端连接于相对应的医师端，存储模块对患者账号进行存储，标签模块用于根据患者账号所对应的就诊信息将病情标签添加至患者账号，随访模块用于根据预设的随访模板生成相应的随访任务；医师端用于供医师根据随访任务对患者端的患者进行随访，以得到随访结果。95.进一步的，平台端还包括历史病因库、咨询问答库、答复模块、权限模块、宣教模块、评分模块等等。96.一种诊后随访系统还可以用于预约挂号、患者投诉、满意度调查等功能。97.另一个实施例公开了一种计算机存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的诊后随访方法。98.以上均为本技术的较佳实施例，并非依此限制本技术的保护范围，故：凡依本技术的结构、形状、原理所做的等效变化，均应涵盖于本技术的保护范围之内。









图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!




内容声明：本文中引用的各种信息及资料（包括但不限于文字、数据、图表及超链接等）均来源于该信息及资料的相关主体（包括但不限于公司、媒体、协会等机构）的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理！本站为非盈利性质站点,发布内容不收取任何费用也不接任何广告!




免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理，本文部分文字与图片资源来自于网络，部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!的,若有来源标注错误或侵犯了您的合法权益，请立即通知我们，情况属实，我们会第一时间予以删除，并同时向您表示歉意,谢谢!