《基于 Kafka + Quartz 实现时限质控方案》

📢 大家好,我是 【战神刘玉栋】,有10多年的研发经验,致力于前后端技术栈的知识沉淀和传播。 💗

🌻 CSDN入驻不久,希望大家多多支持,后续会继续提升文章质量,绝不滥竽充数,欢迎多多交流。👍

文章目录

写在前面的话

本篇文章分享一下博主所在公司的时限质控系统的解决方案。

主要是基于Kafka + Quartz实现,由于涉及公司隐私,内容主要以方案介绍为主,有需要探讨的可以留言。

好,让我们开始。


背景技术

1、医院质控信息系统,要求医护人员在日常工作中,需按时完成相应的病历书写任务,同时必须遵循时效性上的要求,该任务的完成情况,通常也会被加入绩效考核评估结果。针对上述工作要求,从而衍生的功能模块也称为时限质控模块。时限质控主要是对针对入科、取消入科、转科、取消转科、出院、取消出院、病情变化、完成病历书写等业务场景,根据对应的病历类型是否完成书写任务,以及是否满足时效性要求,进行提醒、统计和评分。通过时限质控提醒,医护人员可以更直观的接收到病历的书写的时限,并在时限内完成病历,医务部则可以通过有无超时书写病历来进行质控评分。

2、传统的时限质控系统,通常采用"程序定时器轮询"或"数据库触发器"实现,两者在实现时限质控功能的同时,也都存在若干缺陷。

2.1、程序定时器轮询方式,通过定时服务不断轮询关键业务数据表,当查询到符合要求的数据则触发时限质控,该方式无论从配置和实现上看都不灵活,同时耗费服务资源,效率较低。

2.2、数据库触发器方式,主要通过监听程序执行的DML语句以做出相应操作,但触发执行的逻辑功能比较单一,只适合于简单的场景,无法运行复杂程序。


发明目的

本方案的发明目的是基于Kafka + Quartz 实现低耦合、易扩展、高及时性和高灵活性的时限质控方案。通过预先针对时限质控规则进行规则维护、事件管理、质控类别维护等,利用相应的触发机制,生成或关闭相应任务,最终实现时限质控要求。

本方案摒弃了传统的程序定时器轮询或数据库触发器实现方式带来的缺陷,将时限质控涉及的临床业务节点定义成一个个事件,事件交由具体业务代码在完成相应操作的同时触发消息中心,而时限质控的生成任务和关闭任务的服务,仅需要被消息中心对应事件主题订阅即可实现。

各业务系统和时限质控系统只需要专注于自身业务逻辑,模块之间的通讯统一交由消息中心完成,最终达到模块解耦的目的。引入消息中心和事件驱动机制后,时限质控的流程是这样的,入院模块只需要关注自身逻辑,完成入院逻辑后,调用消息中心,消息中心负责触发时限质控的生成任务服务,生成相应文书的书写任务并分发给指定用户。当用户完成相应病历文书的书写工作时,病历书写模块在完成自身逻辑后,也会触发消息中心,消息中心也会负责订阅时限质控的关闭任务服务,针对用户的任务按实际时限进行处理。

可以看出,整个过程中,时限质控系统和各个业务系统都是充分解耦的,同时事件主题的发布/订阅模式,可以不仅仅局限于时限质控板块,也适用于其他更多的业务需求。


具体方案

消息中心的搭建

采用 Kafka + Zookeeper 集群作为核心中间件,时限质控涉及的相关临床业务事件作为 Topic,院内的HIS和EMR系统作为消息生产者,时限质控服务作为消费者,整体采用Kafka的发布订阅模式。

1、事件模块准备步骤:

分析医院信息系统中涉及与时限质控相关的临床业务,将这些临床业务定义为一个个事件,事件包含事件编号、事件名称、病历文书类型、以及其他关键业务属性等。当信息系统中的临床业务触发后,可以通过消息中心,快速通知或触发其他系统执行相应操作,这个过程是联动并且解耦的。

2、生产者模块实现步骤:

创建生产者模块服务,该服务提供对外开放接口。当消息中心被调用后,执行生产者校验功能,包含利用XSD进行消息入参格式校验、依据消息唯一编号进行消息查重校验、以及验证事件的有效性等。校验通过后,利用生产者单例去完成消息发送,具体就是以指定的事件编号作为Topic,投递消息到Kafka。

3、消费者模块实现步骤:

创建时限质控的消费者组服务,该服务会不断从集群上拉取消息,当拉取到订阅消息后,将启动新的工作线程进行相应的逻辑处理,具体逻辑是调用时限质控核心服务,生成或关闭相应任务。

构建时限质控核心服务

时限质控核心服务主要负责时限质控相关任务的生成和关闭,该服务订阅了消息中心相应主题,当相应业务主题被触发时,消费者将调用时限质控核心服务。

时限质控核心服务包含生成任务服务、关闭任务服务、和任务中心三大板块。

1、生成任务服务的实现步骤:

1)解析消息入参,进行合法性校验,提取关键信息,例如:事件主题、患者信息、医生信息等,存储至临时变量;

2)根据事件主题读取相关时限质控规则配置信息,根据规则构建相应任务主表,任务属性包含但不限于"单次/连续配置"、"超时配置"、"关闭配置"、"提醒配置"、"触发配置"等等;

3)读取上述规则配置中的接收人配置,使用入参传递的患者和医生信息,动态替换,得出相应接收人列表;

4)利用 Quartz 产生生成时限质控任务的相应定时器,当定时器符合触发要求时,将调用任务中心进行后续操作;

2、关闭任务服务的实现步骤:

1)解析消息入参,进行合法性校验,提取关键信息,例如:事件主题、患者信息、病历类型等,存储至临时变量;

2)根据事件主题读取相关时限质控规则配置信息,根据病历类型和患者信息,判断任务是否达到完成标准;

3)若符合标准,则对任务进行关闭操作,并根据完成的时间和情况对任务状态进行更新;

4)利用 Quartz 产生关闭时限质控任务的相应定时器,当定时器符合触发要求时,将调用任务中心进行后续操作;

3、任务中心的实现步骤:

1)任务中心是最终控制时限质控任务生成和关闭的枢纽,质控核心服务中的生成任务和关闭任务服务,仅触发相应定时器,符合要求时,触发任务中心,任务中心也负责与前端的交互。

2)当任务生成服务的定时器达到触发要求,任务中心将根据预置的任务生成配置模板和相应业务入参信息,生成相应的任务,构建时限质控任务细表数据,并使用 WebSocket 等技术推送至前端,至此,任务生成完毕。

3)当任务关闭服务的定时器达到触发要求,任务中心将根据患者信息预置的任务关闭配置模板,查找符合要求的待关闭任务列表,更新时限质控任务细表数据,使用 WebSocket 等技术推送至前端,对已产生的任务进行关闭操作,至此,任务关闭完成。

实现时限质控辅助板块

1、实时推送

时限质控任务的生成和关闭,都要和用户前端进行实时交互,当任务产生的时候,需要告知用户前台界面,并实时展示出来;当任务关闭的时候,也需要告知用户前台界面,将相应任务进行删除处理。

这种效果,可以采用诸如 WebSocket 等的长连接推送模式,在浏览器和服务器完成一个握手的动作,在建立连接之后,服务器可以主动传送数据给客户端,客户端也可以随时向服务器发送数据。

使用 WebSocket 等推送模式,要考虑其高可用性,建立完善的功能机制,包含但不限于如下:心跳机制、断网自动重连、消息补发机制、离线消息处理、历史消息查询、消息的压缩机制等。

2、任务看板

在医护人员登入之后的前台主界面,需要一个专门的组件,用于时限质控信息展示,该组件可以是一个独立的使用iframe嵌套的html界面。

该组件可以用于展示该用户未完成的时限任务,例如:如XX患者,首次病程需在入院后8小时内完成(超时x小时/x小时候超时),用户点击该任务,即可跳转到该病人的病历书写界面,进行病历的创建。

当任务关闭的时候,前台界面收到推送消息,也可以在该组件针对该任务做出响应,例如:添加删除线效果。

3、质控统计

时限质控的数据表,将会收集到所有产生的用户任务的处理情况,需要针对此类数据,做出统计分析功能,才可以利用时限质控带来的效果,例如用于作为输出报表或作为绩效扣分的依据。

质控系统的时限质控统计界面,应该包含但不限于如下功能:按不同维度查询各类数据、导出各类报表、生成统计图表,针对质控情况进行评分,质控任务的闭环信息查看,以及对后续情况进行预测分析。

统计页面的关键信息包含但不限于:时限任务的基本规则属性、参与人员、开始时间、完成的时间、超时完成/超时未完成的时间、任务完成状态等,方便质控员清晰地看出病历的整体书写情况。

4、评分判定

时限质控的最终目的是为了规范医疗人员的日常行为,引导其满足及时性要求,因此,通过需要与绩效评分挂钩。

在质控的方案管理界面通过将评分规则与时限质控规则进行绑定,在时限质控统计界面,对医生超时完成/超时未完成的时限规则进行快速评分。

5、数据修正与定时补推

借助消息中心事件驱动机制实现的实现的时限质控效果,在达到解耦灵活的同时,我们也需要充分考虑由于消息中间件稳定性引发的数据丢失,以及对应的处理方案。

针对时限质控的数据丢失,可以考虑增加数据修正功能。在质控的数据修正界面,记录了触发失败的时限规则,可以对其进行一个重试操作,还可以对时限任务进行关闭操作,保障了当有配置错误或程序问题导致的任务提醒或关闭异常,进行一个手动的修复。

与此同时,也可以考虑增加定时补推机制,利用定时服务,定时去判断是否存在应该生成但是没生成的,例如通过日志捕捉业务方触发了相关埋点,这种情况给予生成;判断应该关闭但是没关闭的,例如已经书写了病历,但任务没被关闭,针对这种情况,直接将任务给予关闭。

6、统一定时规则配置

提供统一的质控任务定时规则配置界面,不依赖于业务方,针对单次指定时间、连续固定时间、连续不规则频率等定时任务产生规则,进行统一的配置。针对任务关闭,也支持设置业务根据组合Key、互斥关闭等高级功能。

展示一些实际案例

案例1:关于"首次病程记录在入院8小时内完成"的时限质控流程

1)护士为患者办理"入院登记",该业务的后端接口,将在完成相应入院逻辑后,触发消息中心的"入院"事件;

2)由于该"入院"事件,订阅了"时限质控 - 生成服务",当该事件对应主题,有消息产生时,消息中心消费者将拉取相应消息,帮触发该时限质控服务;

3)该"时限质控 - 生成服务",会产生相应的病历文书的时限质控书写任务,其中包含"首次病程记录在入院8小时内完成",同时利用消息入参信息,查询到该患者的主管医生,通过 WebSocket 等实时推送机制,将产生的时限质控任务详情推送给指定医生前端系统,进而在该医生的工作桌面上,将接收到这一推送消息,在任务看板等展示组件中,生成"首次病程记录在入院8小时内完成"任务;

4)当该主管医生完成了该患者的首次病程记录的书写,在点击"确认完成"按钮的同时,将在完成相应书写任务完成的逻辑后,还将触发消息中心的"完成病历书写"事件;

5)由于该"完成病历书写"事件,订阅了"时限质控 - 关闭服务",同样的,在该事件对应主题,有消息产生时,消息中心消费者将拉取相应消息,帮触发该时限质控服务;

6)该"时限质控 - 关闭服务",将从消息入参里,提取该份病历的患者基本信息、病历类型等元素,进而判断是否关闭已产生的病历书写任务,若符合关闭要求,则根据完成时间针对已产生任务做出时效性评价,同时,通过 WebSocket 等推送机制,将关闭任务的信息推送至指定医生的前端系统,做出相应处理,例如自动关闭该任务。

流程图:时限质控任务生成

流程图:时限质控任务关闭

时限质控系统总结

一种基于事件驱动的时限质控系统,包括如下步骤:

1、业务系统异步触发消息中心的指定事件埋点;

2、消费者服务从消息中心拉取消息,触发时限质控服务;

3、时限质控服务根据事件类型和规则配置,判定任务操作是生成还是关闭,以此生成对应的定时器;

4、定时器满足触发条件后,调用任务中心服务,生成或关闭对应的任务,并推送至用户前台进行相应展示;


方案特征

1、基于Kafka + Quartz 实现时限质控方案:

本方案采用事件驱动架构,借助事件消息的通讯作为基础,构建完善的时限质控系统。摒弃了传统的程序定时器或数据库触发器实现方式带来的缺陷,将时限质控涉及的临床业务节点定义成一个个事件,事件交由具体业务代码在完成相应操作的同时触发消息中心,时限质控的生成任务和关闭任务的服务,仅需要被消息中心对应事件主题订阅即可实现,真正做到了低耦合、高内聚的模块化设计。

同时,利用 Quartz 作业调度框架,实现定时任务生成与关闭的效果。简化了定时任务的管理和调度,允许开发人员定义各种不同类型的任务,并在指定的时间点或间隔触发它们的执行。Quartz 提供了可靠的任务调度机制,确保任务按照预定的计划运行,并具备容错和持久化的能力,即使在应用程序重启后也能保持任务的状态。

2、时限质控任务的易扩展:

由于底层基于事件驱动架构实现,若需要增加其他相同或不同业务场景下的时限质控规则,无需修改任何时限质控服务代码,业务系统至多仅需要触发相应的消息中心事件埋点,订阅对应的时限质控服务,针对任务的基本属性进行配置即可实现。完全做到灵活便捷的扩展,让时限质控服务与业务系统解耦。


总结陈词

上文介绍了博主所在公司的《基于 Kafka + Quartz 实现时限质控方案》方案。

💗 后续会逐步分享企业实际开发中的实战经验,有需要交流的可以联系博主。

相关推荐
倔强的石头_8 小时前
kingbase备份与恢复实战(二)—— sys_dump库级逻辑备份与恢复(Windows详细步骤)
数据库
jiayou642 天前
KingbaseES 实战:深度解析数据库对象访问权限管理
数据库
李广坤2 天前
MySQL 大表字段变更实践(改名 + 改类型 + 改长度)
数据库
DemonAvenger3 天前
Kafka性能调优:从参数配置到硬件选择的全方位指南
性能优化·kafka·消息队列
初次攀爬者3 天前
ZooKeeper 实现分布式锁的两种方式
分布式·后端·zookeeper
爱可生开源社区3 天前
2026 年,优秀的 DBA 需要具备哪些素质?
数据库·人工智能·dba
随逸1774 天前
《从零搭建NestJS项目》
数据库·typescript
加号34 天前
windows系统下mysql多源数据库同步部署
数据库·windows·mysql
シ風箏4 天前
MySQL【部署 04】Docker部署 MySQL8.0.32 版本(网盘镜像及启动命令分享)
数据库·mysql·docker
李慕婉学姐4 天前
Springboot智慧社区系统设计与开发6n99s526(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。
数据库·spring boot·后端