实现危急值处理措施推荐和触发范围校准的方法

技术领域

本发明属于数据处理领域，具体涉及一种实现危急值处理措施推荐和触发范围校准的方法。

背景技术

现目前大多危急值管理系统存在如下问题：

1、各类危急值检验项目按照固定触发范围进行危急值区间判定，不支持动态调整触发范围的上限和下限，往往只是简单粗暴的进行区间数值比对，缺乏科学的范围判定和校准方式，造成了不符合临床实际的“假的危急值”的频繁通知，该临床医护人员工作造成困扰；

2、医护人员针对危急值做出的干预措施，只是单纯地填写并反馈医技部门，没有与病程和护理记录产生交互，处理过程也没有形成记忆和管理，针对相同情形的处理，往往需要重复工作，不仅花费时间，也容易产生偏差；

3、危急值涉及环节较广，没有统一的流程化管理，容易产生环节缺失，未形成完整闭环，同时，整个过程缺少环节监控、日志跟踪和异常处理方案，也缺少全院统计汇总页面，无法提供整体改善医院危急值的处理方案。

发明内容

为了解决上述技术问题，本发明提供一种实现危急值处理措施推荐和触发范围校准的方法，在危急值全流程管理过程中，提供科学校准危急值触发范围以及对危急值处理措施进行智能推荐的方法，以解决目前危急值流程管理中存在的诸如危急值触发范围不准确、处理措施数据未利用、全院危急值优化机制不完善等问题，进而优化危急值管理流程，提升危急值处理效率，形成完整闭环追踪。

本发明实现危急值处理措施推荐和触发范围校准的方法，适用于危急值全流程管理系统，包括如下步骤：

步骤1、前置环境准备：

部署 Kafka 环境：Kafka作为消息中间件，负责提供生产者和消费者的协作模式，程序引入 Kafka 相关依赖，并进行相关配置与功能集成，定义“危急值发送”事件和“危急值反馈”事件，配置事件的消息入参格式与XSD校验文本，将该两个事件作为 Kafka 的两个Topic；

部署 Elasticsearch 环境：程序引入 Elasticsearch 相关依赖，并进行相关配置与功能集成，Elasticsearch 定义若干索引结构，该索引结构用于存储危急值原始数据、关联数据或运算结果，并利用 Elasticsearch 特性进行统计分析；

部署 Flink 环境：程序引入 Flink 相关依赖，并进行相关配置与功能集成，Flink一方面用于消费 Kafka 集群投递的主题消息，另一方面，通过相关 API，将数据运算结果输出存储到 Elasticsearch 中；

步骤2、检验系统对检验报告中的项目数据进行判定，当系统发现危急值时，触发危急值发送流程；调用数据中心危急值发送接口，先进行危急值原始数据的存储，接着消息中心触发“危急值发送”事件，调用消息中心生产者接口，投递“危急值发送”Topic 数据至Kafka；利用 Flink 订阅 Kafka 的“危急值发送” Topic，并利用 Flink Transform API对接收到的“危急值发送”主题数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，当新危急值到来时，向医生用户端给出提示和支持填写助手功能；经过核心服务的数据处理，调用用户后端接口，在医生用户前端展示出危急值霸屏弹窗界面并实现交互，危急值发送流程结束；

所述核心服务的数据处理，指的是在危急值发送过程中，进行触发范围校准和处理措施推荐的如下运算：

查询并获取项目危急值的区间分布情况，判断该危急值所属的区间分布，做出更新，并将更新结果进行数据组装；

查询并获取项目危急值的历史处理措施分布情况，并通过运算得出按不同维度的不同处理措施出现的频次排列，将更新结果进行数据组装后存储到Elasticsearch的不同索引结构中，便于后续推送给医生用户前端，辅助医生参考和利用；

查询并获取项目危急值历史出现时，其他同样出现异常的项目，并通过运算得到这些项目和当前危急值项目之间存在的联动关系；

查询并获取项目危急值对应的历史值，做出趋势分析，并将结果组装；

查询并获取项目危急值的其他关联和扩展信息，将结果组装，用于辅助分析；

步骤3、医生根据危急值霸屏弹窗界面中展示的患者的危急值信息、报告信息、就诊信息的内容进行判断，若确认符合危急值范畴，则填写相应处理措施并提交，若确认不符合危急值范畴，则医生判断该危急值属于误报，给予异常处理，结束危急值处理流程，并进入危急值反馈处理流程，投递“危急值反馈”Topic 数据至 Kafka，利用 Flink 订阅 Kafka的“危急值反馈”Topic得到主题数据，并利用 Flink Transform API 对拉取到的 Kafka的“危急值反馈”Topic数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中；

在上述危急值处理反馈过程中，进行触发范围校准和措施推荐的如下运算：

a、若医生针对该项目危急值给出处理措施，则代表该项目危急值触发范围的可信度增加，若该项目危急值属于现有触发范围内，则增加并更新现有触发范围的出现频次记录；若该项目危急值超出现有触发范围，则根据该项目危急值扩大触发范围，更新该项目危急值对应的触发范围，并记录出现频次；将医生针对不同项目出现危急值所使用的处理措施、原始危急值数据、危急值所属区间、以及关联患者的当前和历史的报告信息、就诊信息、危急值信息存储到措施记忆索引中；

b、若医生针对该危急值给予了异常处理，则代表危急值触发范围的可信度降低，分别插入并更新原始危急值数据到反馈疑问索引、危急值触发范围索引、危急值处理措施索引中；然后，往危急值范围区间索引中插入相关异常数据；最后更新处理措施索引。

所述索引结构包括有措施记忆索引、反馈疑问索引、危急值触发范围分布索引、危急值原始数据索引、危急值扩展数据索引、危急值处理措施分布索引。

采用Oracle和Elasticsearch两种数据存储方式，将结构化的原始数据存在Oracle表中，将通过计算统计得到的组装数据，存在Elasticsearch的索引结构中。

所述消息中心生产者接口，用于“危急值发送”事件和“危急值反馈”事件，针对消息入参进行合理性校验、解析和处理，再通过调用 Kafka API 进行消息发送，利用生产者单例去完成消息发送，发送的 Topic 为“危急值发送”或“危急值反馈”。

所述利用 Flink Transform API 对接收到的“危急值发送”主题数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，具体包括如下步骤：

1）利用正则表达式提取消息入参中危急值的属性信息，识别出各属性的code和value，进行数据组装；

2）利用上述属性信息，从Oracle中提取与危急值业务关联的报告信息、患者信息、就诊信息，以及上述内容的历史信息，以及从 Elasticsearch 中提取危急值区间分布信息、危急值处理措施分布的信息，并将这些内容进行数据组装；

3）利用 Flink Transform API 对上述组装后的数据进行加工处理后得到运算结果，将运算结果组装成可利用的知识库数据存入Elasticsearch中。

所述利用 Flink Transform API 对拉取到的 Kafka 的“危急值反馈”Topic数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，具体包括如下步骤：

1）利用正则表达式提取消息入参中危急值处理的属性内容，至少包含危急值ID、处理方式、处理措施、处理人，识别出各属性的code和value，并进行数据组装；

2）利用上述属性内容，从Oracle和 Elasticsearch 中提取关联信息；

3）利用 Flink Transform API 对组装后的数据进行加工处理，得到运算结果，将运算结果组装成可利用的知识库数据存入Elasticsearch中。

所述发送给医生用户前端展示出危急值霸屏弹窗界面，包括展示项目危急值对应的基本信息、报告信息、患者信息、处理措施填写窗口、反馈疑问按钮和已处理按钮；

医生在处理措施填写窗口内给出处理措施，点击已处理按钮，向检验系统发送已运算结果，并通知病历系统自动创建病程，或者点击反馈疑问按钮；

医生点击检验报告，则界面展示检验报告的完整信息、各种历史趋势对比；

该危急值霸屏弹窗界面上还展示从Elasticsearch或Oracle中调取如下填报助手信息：

a、该项目危急值的各项处理措施和对应的出现频次，供医生点击复用；

b、该项目危急值触发范围中不同区间出现危急值的频次，作为医生确认危急值的参考依据；

c、该项目的历史趋势对比分析图，以及该项目出现危急值时，其他也会同时出现异常的项目信息及其出现的频次；

d、该患者的其他历史参考信息，至少包括就诊历史信息、报告历史信息、危急值历史信息。

在危急值全流程管理系统中采用本发明的技术方案，建立“假的危急值”的处理方案，能在自动判断与人工反馈的不断磨合中，得到一个更精准的危急值触发范围，这样后续危急值到来时，就可以根据新的危急值触发范围进行判定，防止提醒过于频繁，所述“假的危急值”指的是处于老范围和新范围之间的危急值，即本来会被触发，但是因为范围被校准了，而不会被触发的危急值。

本发明在危急值反馈处理过程中，利用医生针对危急值做出一系列的干预措施以及相关联的数据信息形成知识库，将日常危急值的反馈处理措施进行存储，形成记忆，在危急值到来时，可以给予医护人员多样化提示，充当填写助手的作用。

本发明基于 Kafka + Flink + Elasticsearch架构，采用Kafka实现事件驱动架构，借助事件消息的通讯完成模块间的协作。由数据中心负责完整危急值信息存储，提供闭环展示和数据查询接口，收集各科室的危急值闭环数据，生成定向指标数据，方便定期追踪、分析、评价危急值指标，督导各科室发现并完善自身危急值处理，提升全院危急值反馈处理效率。本发明整个危急值处理过程基于模块化的设计理念，各模块只需要专注于自身业务逻辑，模块之间的通讯统一交由消息中心完成，最终达到模块解耦的目的。

附图说明

图1为本发明中危急值发送流程示意图；

图2为本发明中危急值事件医生处理流程示意图；

图3为本发明医生用户前端所展示的危急值霸屏弹窗界面。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

本发明提供一种实现危急值处理措施推荐和触发范围校准的方法，适用于危急值全流程管理系统，包括如下步骤：

步骤1、前置环境准备：

部署 Kafka 环境：Kafka作为消息中间件，负责提供生产者和消费者的协作模式，程序引入 Kafka 相关依赖，并进行相关配置与功能集成，定义“危急值发送”事件和“危急值反馈”事件，配置事件的消息入参格式与XSD校验文本，将该两个事件作为 Kafka 的两个Topic。

所述Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据(例如网页浏览、搜索和其他用户的行动),这些数据通常是基于吞吐量的要求而通过处理日志和日志聚合来解决。通过Kafka集群来提供实时的消息，即通过Hadoop的并行加载机制来统一线上和离线的消息处理，每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

部署 Elasticsearch 环境：程序引入 Elasticsearch 相关依赖，并进行相关配置与功能集成，Elasticsearch 定义若干索引结构，该索引结构包括措施记忆索引、反馈疑问索引、危急值触发范围分布索引、危急值原始数据索引、危急值扩展数据索引、危急值处理措施分布索引等，该索引结构作为危急值原始数据、关联数据、运算结果等内容的存储，并利用 Elasticsearch 特性进行统计分析，其中危急值原始数据包括患者信息、本次就诊信息、报告信息、危急值信息、处理措施等。本发明采用Oracle和Elasticsearch两种数据存储方式，将结构化的原始数据存在Oracle表中，比如危急值信息、报告信息、患者信息、就诊信息等，将通过计算统计得到的组装数据，存在Elasticsearch的索引结构中，所述组装数据，指的是组装为Key-Value的特定键值对结构的数据，可采用Map或JSON结构；

所述ElasticSearch是一个基于Lucene的搜索服务器，它提供了一个分布式多用户能力的全文搜索引擎。

部署 Flink 环境：程序引入 Flink 相关依赖，并进行相关配置与功能集成，Flink 充当呈上启下的衔接角色，一方面用于消费 Kafka 集群投递的主题消息，另一方面，通过相关 API，将数据运算结果输出存储到 Elasticsearch 中。

所述Flink是分布式流数据流引擎。该Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时，系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行；

步骤2、检验系统对检验报告中的项目数据进行判定，当系统发现危急值时，检查（验）者首先要确认检查仪器、设备和检验过程是否正常，核查标本是否有错，操作是否正确，仪器传输是否有误，在确认临床及检查（验）过程各环节无异常的情况下，及时复查（影像科室可根据实际情况决定是否需要复查），如两次复查结果相同，触发危急值发送流程；通过院内集成平台LIS发起对数据中心危急值发送接口的调用，首先进行危急值原始数据的存储，接着消息中心触发“危急值发送”事件，调用消息中心生产者接口，投递“危急值发送”Topic 数据至 Kafka；利用 Flink 订阅 Kafka 的“危急值发送” Topic，并利用 FlinkTransform API 对接收到的“危急值发送”主题数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，当新危急值到来时，可以给予医护人员多样化提示，充当填写助手的作用；经过核心服务的数据处理，调用用户后端接口，再利用 WebSocket 完成用户前后端消息推送，或由核心服务直接集成WebSocket 负责与医生用户前端交互，最终在医生用户前端展示出危急值霸屏弹窗界面和实现交互，至此，危急值发送流程结束，见图1所示；

所述消息中心生产者接口，用于“危急值发送”事件和“危急值反馈”事件，针对消息入参进行合理性校验、解析和处理，再通过调用 Kafka API 进行消息发送，利用生产者单例去完成消息发送，发送的 Topic 为“危急值发送”或“危急值反馈”；该提供给外部调用的接口是可选的，外部也可以自己触发Kafka；利用 Flink 消费 Kafka，即利用 Flink 的Flink Source API，添加 Kafka 作为数据来源，并订阅“危急值发送”或“危急值反馈”Topic；

所述利用 Flink Transform API 对接收到的“危急值发送”主题数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，具体包括如下步骤：

1）利用正则表达式提取消息入参中危急值的属性信息，包含但不限于危急值ID、报告ID、患者ID、就诊ID等，识别出各关键属性的code和value，进行数据组装；

2）利用上述属性信息，从Oracle中提取与危急值业务关联的报告信息、患者信息、就诊信息，以及上述内容的历史信息，以及从 Elasticsearch 中提取危急值区间分布信息、危急值处理措施分布等信息，并将这些内容进行数据组装；

3）利用 Flink Transform API 对上述组装后的数据进行加工处理得到运算结果，将运算结果组装成可利用的知识库数据存入Elasticsearch中；

所述核心服务的数据处理，指的是在危急值发送过程中，进行触发范围校准和处理措施推荐的如下运算：

a、获取项目危急值，判断该危急值是否符合当前危急值的上限和下限，二次校验危急值的发送是否符合触发条件，并非必要步骤；

b、查询并获取项目危急值的区间分布情况，判断该危急值所属的区间分布，做出更新，并将更新结果进行数据组装；

c、查询并获取项目危急值的历史处理措施分布情况，并通过运算得出按不同维度的不同处理措施出现的频次排列，这里是将危急值出现的次数，按不同区间范围做一个计数操作，以血小板为例，当前值是70，如果该项目的参考范围是125-350，当前值就属于危急值，若上次值是90也算危急值，则对[70-90]，[90-125]等区间内出现危急值的次数进行计数，将更新结果进行数据组装后存储到Elasticsearch的不同索引结构中，便于后续推送给医生用户前端，辅助医生参考和利用；

d、查询并获取项目危急值历史出现时，其他同样出现异常的项目，并通过运算得到这些项目和当前危急值项目之间存在的联动关系；

e、查询并获取项目危急值对应的历史值，做出趋势分析，并将结果组装；

f、查询并获取项目危急值的其他关联和扩展信息，将结果组装，用于辅助分析；

步骤3、如图2所示，若医生用户前端收到危急值发送通知，则在医生用户前端展示出危急值霸屏弹窗界面，医生根据危急值霸屏弹窗界面中展示的患者的危急值信息、报告信息、就诊信息等内容进行判断，若确认符合危急值范畴，则填写相应处理措施并提交，若确认不符合危急值范畴，则医生判断该危急值属于误报，点击反馈疑问按钮，所述填写处理措施并提交，或者点击反馈疑问按钮，都将结束危急值处理流程，并进入危急值反馈处理流程，投递“危急值反馈”Topic 数据至 Kafka，利用 Flink 订阅 Kafka 的“危急值反馈”Topic得到主题数据，并利用 Flink Transform API 对拉取到的 Kafka 的“危急值反馈”Topic数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中；

所述利用 Flink Transform API 对拉取到的 Kafka 的“危急值反馈”Topic数据进行加工处理，将运算结果组装成可利用的知识库数据，按照不同维度存储到Elasticsearch的不同索引结构中，具体包括如下步骤：

1）利用正则表达式提取消息入参中危急值处理的属性内容，包含但不限于危急值ID、处理方式、处理措施、处理人等，识别出各属性的code和value，并进行数据组装；

2）同危急值发送流程，利用上述属性内容，从知识库和 Elasticsearch 中提取关联信息，用于辅助分析；

3）利用 Flink Transform API 对组装后的数据进行加工处理，得到运算结果，将运算结果组装成可利用的知识库数据存入Elasticsearch中；

在上述危急值处理反馈过程中，进行触发范围校准和措施推荐的如下运算：

a、若医生针对该项目危急值给出处理措施，则代表该项目危急值触发范围的可信度增加，若该项目危急值属于现有触发范围内，则增加并更新现有触发范围的出现频次记录；若该项目危急值超出现有触发范围，则根据该项目危急值扩大触发范围，更新该项目危急值对应的触发范围，并记录出现频次；将医生的处理措施和原始危急值数据，存储到措施记忆索引中，该措施记忆索引记录包含但不限于如下内容：不同项目出现危急值所使用的处理措施，危急值属于哪个区间，历史触发的危急值包含哪些，关联患者的当前和历史的报告信息、就诊信息、危急值信息等；危急值反馈处理完毕后，根据创建的病程和护理记录等信息的详细操作生成模板并存储，医生下次处理同项目危急值时，可以快速选择模板复用，减少大量办公时间，降低错误率；

b、若医生针对该危急值给予了异常处理，例如点击了反馈疑问按钮，则代表危急值触发范围的可信度降低，分别插入并更新原始危急值数据到反馈疑问索引、危急值触发范围索引、危急值处理措施索引中；然后，往危急值范围区间索引中插入相关异常数据；最后，将更新处理措施索引，这些疑问内容都将在提供相应统计分析页面，人工进行最后裁定，危急值触发范围；

所述发送给医生用户前端展示出危急值霸屏弹窗界面，如图3所示，包括展示项目危急值对应的基本信息、报告信息、患者信息、处理措施填写窗口、反馈疑问按钮和已处理按钮；

医生可以在处理措施填写窗口内给出处理措施，点击已处理按钮，向检验系统发送已运算结果，并通知病历系统自动创建病程等等，或者点击反馈疑问按钮；医生若点击检验报告，则可以看到检验报告的完整信息、各种历史趋势对比等，该危急值霸屏弹窗界面上还展示从Elasticsearch或Oracle中调取如下填报助手信息：

a、该项目危急值的各项处理措施和对应的出现频次，医生可以快速点击复用处理措施；

b、该项目危急值触发范围中不同区间出现危急值的频次，作为医生确认危急值的参考依据；

c、该项目的历史趋势对比分析图，以及该项目出现危急值时，其他也会同时出现异常的项目信息及其出现的频次，该历史趋势对比分析图指的就是该患者某项指标的历史数据的图表展示；

d、该患者的其他历史参考信息，例如就诊历史、报告历史、危急值历史等信息。

专业人员应该还可以进一步意识到，结合本发明中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。