[开源] 国谈药双通道保障联动检测器：面向医保与药学协同的断裂链识别工具，自动定位「目录有、库存无、处方开」三重错配
本项目是专为医院医保办、药学部与信息科联合设计的闭环质控工具，解决国家谈判药品（国谈药）落地过程中长期存在的「双通道目录已纳入、院内药房无库存、临床照常开方」这一典型断裂问题。我们不替代HIS或SPD系统，而是以轻量级独立模块方式，交叉比对医保支付目录（标注双通道属性）、药房实时库存台账、近30天处方明细三路数据，精准识别出「医保目录中标注双通道 + 药房库存数量为零 + 近30天存在有效处方」的异常药品清单，并自动生成符合行政文书规范、可直接盖章递交给医保主管部门的《药品保障异常告知函》。系统提供Web交互界面与标准RESTful API双入口，前端基于React+TypeScript构建，后端由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_date（ISO 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列表 | Python（pandas + openpyxl），独立于Node.js运行时 |
src/shared/ | 全局类型定义，确保前后端对drug_code、dual_channel等字段语义一致 | TypeScript interface 文件，如 |
所有模块共享同一套类型契约，避免因字段名微小差异（如“drugcode” vs “drug_code”）导致检测失败。
数据与扩展
系统对输入数据格式保持务实兼容，不强求完美结构化，但要求关键字段存在且语义明确：
数据源 | 必填字段 | 说明 | 示例值 |
|---|---|---|---|
医保目录 | drug_code, | dual_channel必须为中文“是”或“否”，不接受1/0、Y/N、True/False | "drug_code": "H20200001", "dual_channel": "是" |
药房库存 | drug_code, | stock_quantity为数值型，负数视为零库存 | "stock_quantity": 0 |
处方明细 | prescription_id, | prescribed_date需能被Python | "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