[开源] 国谈药双通道保障联动检测器:面向医保与药学协同的断裂链识别工具,自动定位「目录有、库存无、处方开」三重错配
本项目是专为医院医保办、药学部与信息科联合设计的闭环质控工具解决国家谈判药品国谈药落地过程中长期存在的「双通道目录已纳入、院内药房无库存、临床照常开方」这一典型断裂问题。我们不替代HIS或SPD系统而是以轻量级独立模块方式交叉比对医保支付目录标注双通道属性、药房实时库存台账、近30天处方明细三路数据精准识别出「医保目录中标注双通道 药房库存数量为零 近30天存在有效处方」的异常药品清单并自动生成符合行政文书规范、可直接盖章递交给医保主管部门的《药品保障异常告知函》。系统提供Web交互界面与标准RESTful API双入口前端基于ReactTypeScript构建后端由Express提供服务层核心检测逻辑由Python引擎驱动支持Excel/CSV/JSON多格式输入所有数据处理均在本地完成不上传云端。定位与能力范围我们不做全院药品目录管理也不做库存预警或采购建议那些是SPD和ERP的事。本项目唯一聚焦的是医保政策执行层面的「保障断点」识别。所谓断点不是泛指缺货而是特指某药已在国家医保药品目录中明确标注为「双通道」药品即患者可在定点医疗机构或定点零售药店两种渠道购药报销但该院药房当前库存为零而过去30天内该药品仍被医生开具了至少一张有效处方。这种组合意味着患者实际无法在本院完成购药-结算-用药闭环既违反医保基金使用合规性要求也构成临床用药安全隐患。我们只回答一个问题哪些药正在发生这种「政策有、实物无、行为在」的三重错配答案以可审计、可申诉、可归档的结构化清单和正式文书形式交付。核心功能系统围绕「检测—确认—输出」主线构建三层能力三源交叉比对严格按药品编码drug_code对齐医保目录、药房库存、处方明细三张表不依赖药品名称模糊匹配规避同名异码、别名混用等常见数据噪声断裂链自动标记仅当同时满足三个条件时触发告警① 医保目录中 dual_channel “是”② 库存表中 stock_quantity ≤ 0③ 处方表中存在 prescribed_date 在最近30天内的记录行政文书一键生成输出PDF-ready的《药品保障异常告知函》含医院抬头、异常药品列表含编码、名称、双通道标识、库存数、最近处方日期、依据条款引用如《国家医保谈判药品“双通道”管理机制实施指南》第X条、申述建议路径支持导出Word/PDF并加盖电子签章LLM辅助为可选模块若启用系统在生成告知函正文时调用本地部署或API托管的轻量级语言模型将原始检测结果转化为更严谨、更符合公文语境的表述例如将“库存为0”转述为“截至检测日该院药房未储备该药品无法满足临床即时调配需求”但所有关键字段药品编码、数量、日期保持绝对不可篡改LLM仅润色说明性文字。使用与配置整个流程无需部署数据库不依赖外部中间件所有数据以文件形式导入适合在医保办办公室电脑或信息科测试机上单机运行# 安装Node.js依赖前端API服务 npm install # 安装Python依赖检测引擎 pip install -r requirements.txt启动分两步需两个终端窗口# 终端1启动后端API服务 npm run api # 终端2启动前端Web界面 npm run web访问 http://localhost:5173 即可进入操作界面四步完成全流程上传医保目录Excel或CSV必须包含 drug_code、drug_name、dual_channel 三列dual_channel 值为“是”或“否”上传药房库存CSV必须包含 drug_code、stock_quantity 两列stock_quantity 为数字支持小数上传处方明细JSON数组格式每项含 prescription_id、drug_code、prescribed_dateISO 8601格式如2024-05-20T09:15:00点击「开始检测」按钮系统返回异常药品清单表格并提供「生成告知函」按钮生成的告知函默认采用医院通用红头模板字段位置与字号符合《党政机关公文格式》GB/T 9704-2012基本要求可直接打印盖章提交。工程结构与职责划分项目采用清晰的分层架构各模块边界明确便于医院信息科技术人员理解与二次适配模块路径职责说明技术实现src/api/提供统一RESTful接口接收上传文件、触发检测、返回结果Express TypeScript路由覆盖 /api/detect、/api/gaps、/api/notice 等src/web/前端交互界面含文件拖拽上传、检测状态反馈、异常表格渲染、告知函预览与导出React Vite TypeScript响应式布局适配平板与笔记本src/engine/核心检测逻辑读取三源数据、按drug_code关联、应用断裂规则、生成结构化gaps列表Pythonpandas openpyxl独立于Node.js运行时src/shared/全局类型定义确保前后端对drug_code、dual_channel等字段语义一致TypeScript interface 文件如DrugItem.ts、GapRecord.ts所有模块共享同一套类型契约避免因字段名微小差异如“drugcode” vs “drug_code”导致检测失败。数据与扩展系统对输入数据格式保持务实兼容不强求完美结构化但要求关键字段存在且语义明确数据源必填字段说明示例值医保目录drug_code,drug_name,dual_channeldual_channel必须为中文“是”或“否”不接受1/0、Y/N、True/Falsedrug_code: H20200001, dual_channel: 是药房库存drug_code,stock_quantitystock_quantity为数值型负数视为零库存stock_quantity: 0处方明细prescription_id,drug_code,prescribed_dateprescribed_date需能被Pythondatetime.fromisoformat()解析prescribed_date: 2024-05-22T14:30:00如需对接医院现有系统可通过API批量推送数据调用/api/drug-list、/api/stock、/api/prescriptions接口分别写入三源数据再调用/api/detect触发检测全程无需人工上传文件。限制与说明本项目明确划定能力边界不承诺以下事项- 不提供库存实时同步能力所有库存数据以上传CSV快照为准不连接SPD数据库监听变更- 不校验处方合理性不对适应症、用量、配伍禁忌等临床逻辑做判断仅关注“是否开了”这一行为事实- 不替代医保申诉材料准备生成的告知函为标准化模板具体申诉理由、佐证材料、整改时限等需医院医保办依规补充- 不处理跨院区聚合当前版本按单院区建模多院区需分别运行并合并结果异常判定中的「近30天」为固定窗口不可配置如需调整需修改engine/下Python脚本中DAYS_WINDOW 30常量并重新构建。所有配置项集中于代码内无外部配置文件降低运维复杂度。项目地址https://github.com/nexorin9/drug-channel-detector