夜雨聆风在医院医保办与临床科室协同整改医保审核问题的过程中，一个高频痛点长期存在：医保局反馈的扣款原因以简短编码形式呈现（如 E003-大型检查阳性指征不符），但医生无法直接据此定位到具体哪一条医嘱存在问题。人工核对需反复比对 HIS 系统中的数千条医嘱记录，耗时、易错、难以归因。Medical Insurance Audit Translator 正是为此而生，它不是通用大模型应用，也不是粗粒度的报表工具，而是一个聚焦「医嘱级归因」的轻量级规则引擎驱动工具，专为医保审核整改闭环设计。
项目采用「规则引擎为主、LLM 辅助排序为辅」的技术路线，在保证结果可解释性与审计合规性的前提下，引入 LLM 提升模糊匹配场景下的候选排序质量。所有能力均围绕真实业务流构建：从解析医保局下发的 Excel/XML 审核文件，到关联本院 HIS 医嘱明细，再到输出 Ledger 式整改清单，全程可配置、可复现、可审计。
关键能力还原：面向真实整改流程的功能设计
项目功能严格对应医保整改工作流，不堆砌概念，不脱离场景：
医保审核结果解析支持医保局常见交付格式：Excel（
.xlsx）与 XML（.xml）两类审核结果文件。HIS 医嘱明细解析支持标准 Excel 格式医嘱导出表，字段需包含医嘱时间、项目名称、规格、金额、执行状态等关键信息。
扣款原因映射基于预定义规则，将
E001至E010等医保扣款代码映射为医嘱特征维度（如「检查类项目」「超适应症用药」「重复收费」等语义类别）。多条件医嘱匹配匹配逻辑分三层：精确匹配（药品名+规格+金额全等）、模糊匹配（关键词重合度 + Levenshtein 距离）、日期范围匹配（扣款日期 ± N 天内有效医嘱）。
LLM 辅助排序（可选关闭）对规则引擎输出的多个候选医嘱，调用 OpenAI API 进行置信度打分与重排序，提升最终推荐医嘱的合理性；可通过
--no-llm或配置项完全禁用，不依赖 LLM 亦可运行。Ledger 整改清单输出输出格式支持三种：CLI 表格（适合快速调试）、HTML（带样式表格，适配 Web 界面）、CSV（供 Excel 二次分析或导入 HIS 系统）。
可配置规则引擎所有映射逻辑通过 YAML 文件定义，支持自定义扣款代码、匹配字段、权重策略与过滤阈值，无需修改代码即可适配不同地区医保规则。
技术架构：清晰分层，职责明确
项目采用典型的三层架构，模块边界清晰，便于医院信息科或开发者按需定制或审计：
┌─────────────────────────────────────────────────────────────┐│ 用户交互层 ││ ┌──────────────┐ ┌──────────────┐ ││ │ CLI (Click) │ │ Web (Flask) │ ││ └──────┬───────┘ └──────┬───────┘ │└─────────┼───────────────────┼───────────────────────────────┘ │ │┌─────────┴───────────────────┴───────────────────────────────┐│ 核心引擎层 (AuditTranslatorEngine) ││ ┌──────────────────────────────────────────────────────┐ ││ │ Core (core.py) │ ││ │ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │ ││ │ │ Parser │→ │Rule Engine │→ │ Translator(LLM)│ │ ││ │ │ Module │ │ Module │ │ Module │ │ ││ │ └────────────┘ └────────────┘ └────────────────┘ │ ││ └──────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘ │ │ │┌─────────┴───────────────────┴───────────────────┴───────────┐│ 数据层 ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ ││ │ Parsers │ │ Rule Engine │ │ Output │ ││ │ parsers/ │ │ engine/ │ │ output/ │ ││ └──────────────┘ └──────────────┘ └──────────────────┘ │└─────────────────────────────────────────────────────────────┘各模块路径与职责如下：
src/parsers/ | AuditResultParser 与 HisOrdersParser，分别处理医保审核文件与 HIS 医嘱 Excel/XML | |
src/engine/ | python-constraint 构建规则引擎，完成扣款代码 → 医嘱特征 → 候选集生成全流程 | |
src/llm/ | OpenAILLMScoreProvider 与 MockLLMScoreProvider，支持生产环境与离线测试双模式 | |
src/output/ | LedgerTableRenderer，统一生成 CLI / HTML / CSV 三格式 Ledger 清单 |
数据流严格遵循四阶段：
- 解析阶段
： parsers/加载并标准化医保审核结果与 HIS 医嘱数据为统一 DataFrame 结构 - 匹配阶段
： engine/根据rules.yaml中定义的扣款代码规则，对每条审核记录生成一组候选医嘱 - 翻译阶段
： llm/（若启用）对候选医嘱进行语义相关性评分与重排序 - 输出阶段
： output/将最终结果渲染为结构化 Ledger 表格，含「扣款单号」「扣款金额」「扣款原因」「疑似医嘱」「匹配理由」「状态」六列
快速上手：安装、配置与运行
安装依赖
pip install -r requirements.txt项目依赖精简，核心为： - pandas + openpyxl：处理 Excel 数据 - python-constraint：实现可配置规则求解 - Click：提供健壮 CLI 接口 - Flask：内置轻量 Web 界面（无需额外部署） - PyYAML：加载规则与配置 - openai：仅当启用 LLM 功能时调用
配置方式
项目支持双重配置机制：YAML 配置文件 + 环境变量，优先级为「环境变量 > config.yaml > 默认值」。
复制示例配置：
cp config.yaml.example config.yamlcp .env.example .envconfig.yaml 关键配置项：
llm: api_key: "" # OpenAI API 密钥（也可通过 OPENAI_API_KEY 环境变量设置） model: "gpt-3.5-turbo" # 模型名称 base_url: null # 可选，用于对接兼容 OpenAI 的本地模型服务 temperature: 0.3 # 降低随机性，提升结果确定性 enabled: false # 默认关闭 LLM，保障纯规则可审计性rule_engine: default_rules_path: null # 自定义规则文件路径 match_threshold: 0.5 # 候选医嘱匹配得分低于此值则过滤logging: level: "INFO" format: "%(asctime)s - %(name)s - %(levelname)s - %(message)s" file_enabled: true启用 LLM 的环境变量写法（推荐用于测试）：
export OPENAI_API_KEY="sk-..."export LLM_ENABLED="true"CLI 使用示例
默认纯规则模式，输出终端表格：
python -m src.cli --audit-file data/audit_results.xlsx --orders-file data/his_orders.xlsx --format cli导出 CSV 供后续分析：
python -m src.cli --audit-file data/audit_results.xlsx --orders-file data/his_orders.xlsx --no-llm --output output/result.csv使用自定义规则文件：
python -m src.cli --audit-file data/audit_results.xlsx --orders-file data/his_orders.xlsx --rules-file data/rules.yamlWeb 界面启动
python -m src.web访问 http://127.0.0.1:5000，即可上传审核 Excel 文件，实时查看 Ledger 表格结果，并支持一键 CSV 下载。
输出即所见：结构化、可追溯的整改清单
项目输出始终围绕「让医生一眼看懂该改什么」这一目标，不抽象、不冗余。CLI 示例输出如下：
扣款单号 │ 扣款金额 │ 扣款原因 │ 疑似医嘱 │ 匹配理由 │ 状态─────────────┼──────────┼───────────────────────────────────┼───────────────────────────────────┼──────────────────────────────┼────────AUD20240001 │ ¥150.00 │ E003-大型检查阳性指征不符 │ 腹部B超检查（常规体检套餐） │ 检查项目与扣款原因描述相符 │ 待整改AUD20240002 │ ¥320.00 │ E005-药品超适应症用药 │ 注射用头孢哌酮舒巴坦钠(1.5g×2) │ 药品名称+规格+金额精确匹配 │ 待整改每一行均满足三个基本要求： - 可定位：扣款单号与 HIS 医嘱 ID（或完整描述）一一对应- 可解释：匹配理由字段说明为何被选中，非黑盒推荐- 可操作：状态列为「待整改」，医生可直接据此修正医嘱或补充病历依据
Web 界面在此基础上增强可读性：中文标签、响应式表格、悬停提示、导出按钮，降低使用门槛。
适用场景与注意事项
本项目适用于以下典型场景： - 医院医保办批量处理月度审核反馈，生成科室级整改任务清单- 信息科为临床科室提供自助核查工具，减少人工转译环节- 医保智能审核系统建设初期，作为规则验证与案例沉淀辅助模块
注意事项： - 规则先行：LLM 仅为排序辅助，核心匹配逻辑由 YAML 规则定义，需根据本地医保政策持续维护 rules.yaml- 数据准备：HIS 医嘱 Excel 需至少包含「医嘱时间」「项目名称」「规格」「金额」四字段，否则匹配精度下降- LLM 非必需：关闭 LLM 后仍为完整可用工具，所有功能不降级，仅损失部分模糊匹配场景的排序优化能力- 安全可控：敏感数据不出本地，LLM 请求仅发送脱敏后的医嘱文本片段与扣款原因描述，无患者身份信息
项目地址：https://github.com/nexorin9/medical-insurance-audit-translator国内仓库：https://gitee.com/nexorin9/medical-insurance-audit-translator
欢迎在 Issues 中提交规则适配建议、匹配逻辑优化点或实际使用反馈。
