[开源] 医嘱最小合规改动路径枚举系统：面向临床开方与医保质控的反事实推理工具-编程实验室

本项目是医嘱反事实合规路径枚举与最小改动建议系统，专为解决医生收到医保拒付通知后「知道违规、不知如何改对」这一真实断点而建。我们不输出禁止清单，而是基于结构化医保审核规则知识图谱，用反事实推理引擎联合 CP-SAT 约束求解器，从被拒医嘱出发，自动枚举所有「剂量微调、途径替换、时间重排、药品置换」等维度的最小必要改动组合，输出可落地的合规处方区间，包括安全剂量范围、允许给药途径、互斥诊断规避建议、DRG费用约束下的可行组合等。系统提供 Python CLI 彩色报告、Web 可视化热力图与路径图、标准 REST API 三种交付形态，技术栈以 Python（OR-Tools CP-SAT）、TypeScript（Express + D3.js）双主线支撑，规则全部由 YAML 显式定义，便于医院信息科或医保办按本地政策持续维护。

定位与能力范围

我们聚焦一个明确边界：当一条医嘱已被医保系统标记为拒付时，它不是要重写诊疗指南，也不是替代审方药师做终审，而是成为医生在开立环节就能调用的「合规沙盘」。输入是一条结构化 JSON 医嘱（含药品 ID、剂量、途径、频次、诊断编码、住院天数等字段），输出不是「× 违规」，而是「✓ 改这三项中的任一组合即可过审」：比如将「头孢曲松 2g IV q12h」改为「头孢曲松 1g IV q12h」（剂量下调）、或「头孢曲松 2g IM q12h」（途径变更）、或「头孢曲松 2g IV q24h」（频次拉宽），三者均落在当前规则图谱所允许的合规处方区间内。这个区间本身是多维张成的，不是单点建议，而是覆盖剂量、时间窗、联合用药、诊断适配、费用权重的联合可行域。

系统不处理未结构化的手写医嘱图像识别，也不对接HIS实时拦截；它假设你已有标准化医嘱数据（如 FHIR 或自定义 JSON），且规则已按rules/insurance_rules.yaml格式完成本地化配置。它的价值不在「全自动化闭环」，而在把模糊的经验判断，转化为可验证、可追溯、可教学的显性路径。

核心功能模块

系统能力由五个核心模块协同实现，各司其职又紧密耦合：

模块	职责说明	关键输入/输出
规则知识图谱（kg/）	将医保审核规则转化为图结构：RuleNode 表示单条规则（如「限诊断 Z51.8 才可用帕博利珠单抗」），RuleEdge 表示规则间逻辑关系（冲突、依赖、优先级）；DrugGraph 则建模药品间相互作用与禁忌	YAML 规则文件 → 图谱内存实例
数据适配层（adapters/）	统一转换不同来源医嘱格式（HIS导出JSON、FHIR Bundle、测试样本）为内部标准 OrderSchema，确保后续引擎不感知上游异构	原始医嘱数据 → 标准化 Order 对象
反事实推理引擎（reasoning/）	计算当前医嘱到各合规节点的「改动距离」：支持语义距离（如「IV→IM」比「IV→PO」改动更小）、数值距离（剂量差值归一化）、组合距离（多字段联合扰动代价）	当前医嘱 + 规则图谱 → 候选改动集及其距离分
CP-SAT 约束求解器（cpsat/）	将合规性要求形式化为布尔约束与整数约束（如「若诊断为 I25.1，则阿司匹林剂量 ≤100mg」），调用 OR-Tools 求解器搜索满足全部约束、且总改动距离最小的解集	候选改动集 + 约束表达式 → 最小改动方案列表
合规处方区间生成器	对每个可行解，沿各维度向外扩展至边界，输出连续区间（如剂量：50–150mg；时间窗：用药起始日 ≥ 入院第3天且 ≤ 第7天）	最小改动方案 → 多维合规区间描述

所有模块均通过接口契约解耦，例如CounterfactualEngine不直接调用RuleGraph方法，而是依赖RuleGraphInterface抽象，便于未来接入图数据库或规则引擎替换。

使用与配置

你无需从零构建规则图谱。项目已预置典型医保规则模板，位于rules/insurance_rules.yaml，支持以下六类声明式配置：

药品-药品互斥（如「氯吡格雷」与「替格瑞洛」不可同用）
剂量限制（如「伏立康唑」成人日剂量上限 400mg）
给药途径禁忌（如「万古霉素」禁止皮下注射）
时间窗口互斥（如「术后预防用抗菌药物」须在切皮前 120 分钟内开始）
诊断-药品强关联（如「EGFR T790M 突变阳性」为「奥希替尼」必要前提）
DRG 权重与费用约束（如「某DRG组内，单日静脉营养费用不得超总费用 35%」）

CLI 是最快上手方式。安装后执行：

cd order-counterfactual-pathfinder pip install -r requirements.txt # 分析单条医嘱，输出彩色终端报告 python -m cli.main --order-id ORD001 # 以表格形式呈现合规区间（适合粘贴进质控台账） python -m cli.main --order-id ORD001 --output table # 批量分析拒付医嘱集合 python -m cli.main --batch --input-file data/samples/orders_rejected.json

Web 可视化服务独立运行，便于科室共享查看：

cd web npm install npm run build npm start # 打开 http://localhost:3000，上传 JSON 或输入 order_id 即可交互式探索

API 调用同样简洁，支持集成进医院审方插件或质控看板：

curl -X POST http://localhost:3000/api/analyze \ -H "Content-Type: application/json" \ -d '{"order_id": "ORD001"}'

返回 JSON 中compliant_intervals字段即为各维度合规范围，minimal_modifications列出前三条最小改动路径，每条含field（修改字段）、from_value/to_value（变更前后）、distance_score（改动代价）。

工程结构与技术选型

我们坚持「规则可读、逻辑可验、部署轻量」三原则选型：

Python 主线
：承担规则加载、图谱构建、距离计算、CP-SAT 求解等 CPU 密集型任务。选用 OR-Tools 因其 CP-SAT 求解器对混合整数+布尔约束表达力强，且社区对医疗排程、资源分配类问题有大量验证案例；YAML 规则语法贴近业务人员理解习惯，避免 DSL 学习成本。
TypeScript/Node.js 前线
：负责 CLI 命令解析与 Rich 彩色渲染、Web 服务路由与 D3.js 可视化。Express 提供稳定 REST 接口，D3.js 实现热力图（按科室/药品聚合拒付率）、路径图（节点=医嘱状态，边=改动操作）、仪表盘（合规区间分布直方图）。
架构分层清晰
：src/下严格按领域划分kg/（知识）、reasoning/（推理）、cpsat/（求解）；cli/与web/作为独立入口，不侵入核心逻辑；data/samples/提供带注释的真实感模拟数据，开箱即测。

这种双语言分工，既保障了规则引擎的严谨性与可调试性，又兼顾了终端交互的响应速度与可视化表现力，医生在 Web 端看到的每一条热力图渐变，背后都是 Python 内核完成的数百次约束验证。

数据与扩展机制

所有规则定义、样本数据、报告模板均外置于代码逻辑之外：

规则源：rules/insurance_rules.yaml，支持嵌套条件与注释，例如： ```
id: "rule_drg_cost_001" description: "某DRG组内，单日静脉营养费用占比≤35%" condition: drg_code: "MS-DRG 123" constraint: field: "iv_nutrition_cost_ratio" max: 0.35 unit: "fraction" ```
样本医嘱：data/samples/orders_rejected.json，字段与实际 HIS 输出对齐，含diagnosis_codes、medications（含 dose, route, frequency）、admission_date、discharge_date等关键字段。
报告模板：templates/下 HTML 与 Markdown 模板，支持定制医院抬头、合规依据引用格式、PDF 导出样式。

新增规则只需编辑 YAML 文件并重启服务（或触发热重载）；扩展新维度（如增加「患者年龄分层限制」）只需在OrderSchema中添加字段，在ModificationDistance中定义距离函数，在cpsat中补充约束表达式，无侵入式修改。