本项目是一个专为医保基金监管设计的规则健壮性验证工具。它不依赖人工穷举或黑盒测试，而是将医保审核规则（如费用超限、诊疗冲突、适应症不符、重复收费等）形式化建模为一组逻辑约束条件，再调用 Google OR-Tools 中的 CP-SAT 求解器，系统性地搜索满足「违规但能通过当前规则审核」的最小数据组合，即所谓「最小暴露骗保路径」。生成结果是一份结构化测试用例清单，每条含明确的输入字段值（如就诊类型、药品编码、诊断代码、费用金额）、触发的规则编号、以及该用例为何能绕过现有审核逻辑的技术解释。交付形态为命令行工具（CLI），支持本地运行、批量生成、JSON/CSV 导出，适配医保局、定点医疗机构信息科、第三方审计机构在规则上线前验证、存量规则复检、跨统筹区规则比对等典型场景。底层技术栈聚焦确定性求解：Python 3.9+、OR-Tools 9.8+、标准医保业务术语体系（如医保药品分类与代码、疾病诊断ICD-10国标映射、医疗服务项目编码），不引入机器学习或概率模型，确保每条用例可复现、可追溯、可归因。

定位与能力范围

我们不做通用测试平台，也不覆盖全量医保业务流。本项目的边界非常清晰：只处理「规则已存在、但尚未验证其防御完备性」这一环节。换句话说，当医保办刚起草一条新规则（例如“同一次住院中，同一药品日剂量超过说明书最大推荐量3倍的，应拦截”），或发现某类骗保行为屡查屡犯却未被规则捕获时，本工具就介入，它不判断规则是否合理，而是忠实地回答：“在当前所有规则共同作用下，是否存在一组合法输入，能让这笔费用既符合全部显性条件，又实质构成违规？”

这种能力区别于传统测试：
- 不靠人工编写用例，避免经验盲区；
- 不做模糊匹配或统计拟合，拒绝「大概率会出错」这类不确定结论；
- 不模拟真实患者行为，只关注规则逻辑本身的缝隙；
- 输出不是「可能有问题」，而是「这条数据一定绕过审核，且仅需改动这3个字段即可复现」。

因此，它的核心服务对象是三类人：医保智能审核系统建设方（需上线前压测规则集）、医保基金监管人员（需定向筛查高风险规则）、以及参与DRG/DIP支付改革的医院信息科（需自查本院规则配置是否留有套保空间）。

核心功能

本项目提供四项不可替代的能力，全部围绕「从规则到反例」的单向推导链展开：

• 规则语法解析与约束翻译
  支持将医保业务人员编写的自然语言规则（如“西药费占比＞70%且无相应手术记录的门诊慢特病处方，应预警”）半自动转译为 CP-SAT 可执行的布尔/整数约束。翻译过程保留原始规则编号与上下文注释，便于回溯。

• 最小暴露路径枚举
  在给定规则集合下，求解器会穷尽搜索满足「所有规则判定为‘通过’，但至少一项业务含义为‘违规’」的数据实例，并优先返回字段变动最少、数值偏离最温和的用例（例如仅将药品数量从2支改为3支，就使总费用跨过某阈值）。

• 多规则冲突归因报告
  当生成用例同时绕过多条规则时，报告会标注每条规则在此用例下的具体判定结果（True/False）及失效原因（如“规则R23因未校验诊断与药品适应症映射表而未触发”），而非笼统说“全部失效”。

• 测试用例可执行验证模块
  生成的每条用例均附带标准医保结算报文格式（参考国家医保信息平台接口规范），可直接导入本地稽核引擎或沙箱环境进行闭环验证，确认其确实无法被当前规则捕获。

使用与配置

整个流程分三步，无需编程基础，但需理解医保业务字段语义：

1. 准备规则定义表
       按照说明文档中提供的模板，整理当前生效的所有审核规则。每行一条规则，至少包含：规则ID、适用场景（门诊/住院/药店）、触发字段（如“总费用”“药品数量”“诊断编码”）、操作符（>、=、IN、NOT IN）、阈值或枚举值、逻辑关系（AND/OR）。示例：
   R105,住院,药品编码,IN,["X01AB02","C07AB03"],AND
   R105,住院,诊断编码,NOT IN,["I10","I11"],AND

2. 声明字段约束域
       创建一个 domain.yaml 文件，定义每个字段的合法取值范围。这不是业务规则，而是数据可行性边界。例如：
   诊断编码:
     pattern: "^[A-Z][0-9]{2,3}(\.[0-9]{1,2})?$"
     examples: ["J45.902", "I10", "E11.9"]
   费用金额:
     min: 0.01
     max: 999999.99
     step: 0.01

3. 运行生成命令
       所有操作通过 CLI 完成，无 Web 界面依赖：

insurance-redteam generate \
  --rules rules.xlsx \
  --domain domain.yaml \
  --output testcases.json \
  --limit 50 \
  --timeout 300

其中 --limit 控制最多生成多少条用例，--timeout 是单次求解最长等待秒数。生成完成后，testcases.json 可直接用 Excel 打开，也可用 insurance-redteam validate --case testcases.json --engine local 调用本地稽核服务做二次确认。

工程结构

项目采用极简分层设计，所有模块均围绕「规则→约束→解→用例」主线组织：
- core/constraint_builder.py：规则语法解析器，将表格规则转为 OR-Tools 的 model.Add() 调用链；
- solver/redteam_engine.py：CP-SAT 求解主控，内置最小化目标函数（如最小化字段修改数、最小化数值偏离度）；
- io/exporter.py：负责 JSON/CSV/XML 多格式导出，字段命名严格对齐《国家医疗保障局医疗保障信息业务编码规则》；
- cli/main.py：命令行入口，参数校验与错误提示面向医保信息人员优化（如“字段‘手术编码’在domain.yaml中未定义，请检查拼写”而非抛出Python traceback）。

没有前端、没有数据库、不连云服务。整个包体积小于 800KB，安装只需 pip install insurance-rule-red-team，离线可用。

数据与扩展

本项目不采集、不存储、不上传任何真实医保结算数据。所有输入均由使用者本地提供，所有输出均保存至指定路径。扩展性体现在两个层面：
- 规则维度：支持通过新增 .xlsx 表格接入地方特色规则（如某省特有的中医诊疗项目加成规则），无需修改代码；
- 字段维度：只要在 domain.yaml 中补充新字段的取值范围定义（如新增“高值耗材唯一标识”字段），求解器即可将其纳入约束空间。

说明文档中提供了常见医保字段的标准映射表（如医保版ICD-10与国标ICD-10的对照、医保药品分类与ATC代码的映射），这些表以纯文本 CSV 形式提供，可按需更新。

限制与说明

我们明确告知用户本工具的适用前提与当前能力边界：
- 仅支持静态规则，不处理时间序列类规则（如“近30天内同一患者在不同机构重复开同一抗生素”）；
- 不替代人工规则评审，生成的用例需由业务专家判断是否确属风险场景；
- 对含模糊语义的规则（如“明显不合理”“频繁发生”）无法建模，需先由医保办转化为可量化条件；
- CP-SAT 求解性能取决于规则复杂度与字段组合爆炸程度，超10条强耦合规则时建议分组求解；
- 所有生成用例均基于输入的字段取值范围，若 domain.yaml 中漏设关键约束（如未限定诊断必须与药品适应症匹配），可能导致用例脱离临床实际。

这些限制不是缺陷，而是设计选择：我们坚持让工具服务于人的判断，而非试图替代专业共识。

项目地址：
https://github.com/nexorin9/insurance-rule-red-team-generator