前言“处方点评系统”是合理用药系列产品中面向“事后统计与处方点评”场景的核心业务系统服务于医院药剂科对历史处方的合理性回溯审查。与实时拦截场景不同“处方点评系统”对响应时延不敏感但对数据整合能力和分析深度要求更高——“原始数据”侧提供的原始数据是多份互不关联的单一实体数据如何把它们整合成一份可供分级判断的完整处方数据是这个系统的工程难点。本文以”慧药通”品牌下”临床用药决策分析系统”为例梳理”处方点评系统”其数据流转链路的实现思路。说明文中涉及的隐私信息均已做脱敏处理仅保留架构层面的技术信息。一、处方业务数据对接“处方点评系统”接入医院时需按医院信息化要求对接业务数据。但医院侧提供给我们的并不是一张整合好的”处方全景表”而是多份各自独立、对应单一实体的数据数据来源方式包括数据库视图和接口调用等具体采用哪种由医院条件决定。这些数据之间大多未建立预先关联例如病人信息、处方信息、药品信息等各自独立存放必须借助病历号、处方号、就诊号等公共字段进行匹配才能将“某位病人在某次就诊中开具了什么处方、用了什么药、诊断是什么”等业务信息串联还原为完整记录。因此我们可以构建中间表将处方和医嘱数据按统一规则进行格式化处理完成分析前的数据准备工作。二、数据同步链路从原始数据到中间库以“慧药通”品牌数据库为例数据库采用二级分库分层存储架构依次为中间库、结果库在真正做业务关联之前这些原始数据要先经过两级同步落地图2-1 数据同步链路中间库定时作业每日从 ”原始数据”侧读取数据视图或接口等方式写入服务器数据库上的中间库通过中间库格式化处方和医嘱数据完成分析前的数据准备工作留存一份可回溯的原始数据快照。三、分析整合链路分析程序如何协同这一段涉及两个独立部署、职责不同的程序读取程序负责数据整合分析程序负责规则适配分析。真正完成数据整合把中间库中彼此独立的多张表按关联键拼接成完整业务记录的是读取程序分析服务则主要负责规则匹配判断处方触发了哪些审查规则、对应什么问题等级等。二者协同发生在中间库到结果库这一段。图3-1 分析整合链路具体来说分析程序会读取中间库中的处方数据从中间库里取出与某批处方相关的处方相关数据按关联键整合成完整业务记录以病历号、处方号、就诊号等字段为纽带把病人、处方、诊断、药品等原本孤立的数据关联起来整理成”某病人在某次就诊中开具了什么处方、用了什么药、诊断是什么”这样一条完整的业务记录写入结果库中的处方表、处方药品表等相关表调用分析程序做规则适配分析分析程序在完成数据整合后会把整理好的处方数据传给分析服务由分析服务执行规则匹配判断该处方触发了哪些审查规则、对应什么问题等级分析结论同样写入结果库的分析结果表。如下图为后台程序规则适配的可视化呈现图3-2慧药通分析程序这两步——分析程序自身完成的“整合业务记录”以及它调用分析服务完成的”规则适配分析”——是两个独立程序各自负责、协同并行发生的二者的结果最终都汇总进结果库共同构成一条处方相对完整的”业务信息 分析结论”。四、结果库与点评展示结果库是数据加工的最终输出层承担点评数据的归档与梳理职能。库内最终沉淀为标准化核心表如处方表、处方药品表、分析结果表等数据关联整合与问题等级计算均已落地形成结构清晰、可直接支撑合理用药分析的数据成果。“处方点评系统”展示层读取结果库不直接访问中间库“慧药通”的”临床用药决策分析系统”基于此支持多种点评模式如系统点评直接呈现结果库中的分级结果按等级标红展示需要重点关注的处方图4-1慧药通处方点评系统处方医嘱点评界面人工点评药师在系统点评结果的基础上进行复核和补充意见形成最终的处方点评工作表并可以导出。图4-2慧药通处方点评系统处方人工点评界面两种模式共用同一份结果库数据人工点评是在系统自动分级的基础上做二次校验而非另起一套独立的数据源保证了系统点评与人工点评的判断依据是一致的。五、小结处方点评系统的核心工程挑战其实是一个”多源异构数据整合”问题医院提供的”原始处方数据”口径不一需要先落实中间库留存快照统一格式再由分析程序按关联键完成跨表整合、还原出相对完整的处方业务记录同时调用独立部署的分析服务完成规则适配分析最终产出结构清晰的处方表、处方药品表、分析结果表等表供点评系统展示。这种”先落地、再关联、再分析”的处理顺序本质上是用工程手段把临床业务里天然分散的数据逐步收敛成一份可供药学专业判断的结构化结论。本文为医疗信息化系统技术架构经验分享文中涉及的具体配置信息已做脱敏处理仅供技术交流参考。
前言“处方点评系统”是合理用药系列产品中面向“事后统计与处方点评”场景的核心业务系统服务于医院药剂科对历史处方的合理性回溯审查。与实时拦截场景不同“处方点评系统”对响应时延不敏感但对数据整合能力和分析深度要求更高——“原始数据”侧提供的原始数据是多份互不关联的单一实体数据如何把它们整合成一份可供分级判断的完整处方数据是这个系统的工程难点。本文以”慧药通”品牌下”临床用药决策分析系统”为例梳理”处方点评系统”其数据流转链路的实现思路。说明文中涉及的隐私信息均已做脱敏处理仅保留架构层面的技术信息。一、处方业务数据对接“处方点评系统”接入医院时需按医院信息化要求对接业务数据。但医院侧提供给我们的并不是一张整合好的”处方全景表”而是多份各自独立、对应单一实体的数据数据来源方式包括数据库视图和接口调用等具体采用哪种由医院条件决定。这些数据之间大多未建立预先关联例如病人信息、处方信息、药品信息等各自独立存放必须借助病历号、处方号、就诊号等公共字段进行匹配才能将“某位病人在某次就诊中开具了什么处方、用了什么药、诊断是什么”等业务信息串联还原为完整记录。因此我们可以构建中间表将处方和医嘱数据按统一规则进行格式化处理完成分析前的数据准备工作。二、数据同步链路从原始数据到中间库以“慧药通”品牌数据库为例数据库采用二级分库分层存储架构依次为中间库、结果库在真正做业务关联之前这些原始数据要先经过两级同步落地图2-1 数据同步链路中间库定时作业每日从 ”原始数据”侧读取数据视图或接口等方式写入服务器数据库上的中间库通过中间库格式化处方和医嘱数据完成分析前的数据准备工作留存一份可回溯的原始数据快照。三、分析整合链路分析程序如何协同这一段涉及两个独立部署、职责不同的程序读取程序负责数据整合分析程序负责规则适配分析。真正完成数据整合把中间库中彼此独立的多张表按关联键拼接成完整业务记录的是读取程序分析服务则主要负责规则匹配判断处方触发了哪些审查规则、对应什么问题等级等。二者协同发生在中间库到结果库这一段。图3-1 分析整合链路具体来说分析程序会读取中间库中的处方数据从中间库里取出与某批处方相关的处方相关数据按关联键整合成完整业务记录以病历号、处方号、就诊号等字段为纽带把病人、处方、诊断、药品等原本孤立的数据关联起来整理成”某病人在某次就诊中开具了什么处方、用了什么药、诊断是什么”这样一条完整的业务记录写入结果库中的处方表、处方药品表等相关表调用分析程序做规则适配分析分析程序在完成数据整合后会把整理好的处方数据传给分析服务由分析服务执行规则匹配判断该处方触发了哪些审查规则、对应什么问题等级分析结论同样写入结果库的分析结果表。如下图为后台程序规则适配的可视化呈现图3-2慧药通分析程序这两步——分析程序自身完成的“整合业务记录”以及它调用分析服务完成的”规则适配分析”——是两个独立程序各自负责、协同并行发生的二者的结果最终都汇总进结果库共同构成一条处方相对完整的”业务信息 分析结论”。四、结果库与点评展示结果库是数据加工的最终输出层承担点评数据的归档与梳理职能。库内最终沉淀为标准化核心表如处方表、处方药品表、分析结果表等数据关联整合与问题等级计算均已落地形成结构清晰、可直接支撑合理用药分析的数据成果。“处方点评系统”展示层读取结果库不直接访问中间库“慧药通”的”临床用药决策分析系统”基于此支持多种点评模式如系统点评直接呈现结果库中的分级结果按等级标红展示需要重点关注的处方图4-1慧药通处方点评系统处方医嘱点评界面人工点评药师在系统点评结果的基础上进行复核和补充意见形成最终的处方点评工作表并可以导出。图4-2慧药通处方点评系统处方人工点评界面两种模式共用同一份结果库数据人工点评是在系统自动分级的基础上做二次校验而非另起一套独立的数据源保证了系统点评与人工点评的判断依据是一致的。五、小结处方点评系统的核心工程挑战其实是一个”多源异构数据整合”问题医院提供的”原始处方数据”口径不一需要先落实中间库留存快照统一格式再由分析程序按关联键完成跨表整合、还原出相对完整的处方业务记录同时调用独立部署的分析服务完成规则适配分析最终产出结构清晰的处方表、处方药品表、分析结果表等表供点评系统展示。这种”先落地、再关联、再分析”的处理顺序本质上是用工程手段把临床业务里天然分散的数据逐步收敛成一份可供药学专业判断的结构化结论。本文为医疗信息化系统技术架构经验分享文中涉及的具体配置信息已做脱敏处理仅供技术交流参考。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
