外观
郑州 DIP 2.0→3.0：一次版本切换影响测算
任务：用一批合成演示数据，把 DIP 从 2.0 全国版切换到 预研口径，测算「会有多少病例换病种、哪些病种被改写、费用结构怎么变」。重点不是得到一个数字，而是学会带分母、带口径、带失效条件地表达一次版本迁移的测算。
关于本书出现的「3.0 预研结果」
国家按病种付费 3.0 版分组方案目前处于征求意见稿阶段。国家医保局公开口径为：3.0 版分组方案拟于 2026 年 7 月发布、2027 年 1 月正式执行（《医保支付方式改革有关情况介绍（第 2 期）》，2026-06-03）。
因此：
- 本书中标为「3.0 预研」的分组结果，由 MedGroup 依据 DRG 3.0 版分组方案征求意见稿与 DIP 3.0 版分组征求意见函构建，属实测数据（系统结果），不是官方文件级的政策事实。
- 这些结果不得用于测算、申诉、协商或结算沟通，也不能作为编码调整依据。
- 征求意见稿与最终发布版本可能不同。3.0 正式发布后，本书涉及 3.0 的全部表述与截图将统一更新，更新记录见更新日志。
- 与之对照的「当前全国版」是 MedGroup 页面当前使用的规则口径（产品内部映射为 CHS2.0），对应国家 2.0 版分组方案。
先读边界，再读数字
本案例的批次是合成演示数据（demo=true），不是任何真实医院的病例，也不含可识别患者信息。它用来演示「怎么算一次版本迁移影响」，不能外推为某家医院的清算结果。DIP 3.0 当前为**征求意见稿（预研）**口径，正式发布后本测算需重做。详见文末已知边界。
1. 案例问题
- 要解决的真实任务：当地准备从 DIP 2.0 切换到 3.0（预研），医院运营和医保办需要知道「这一切换大概会动多少病例、动在哪些病种、费用结构往哪偏」，以便提前做编码与病种管理准备。
- 为什么值得研究：版本切换不是「换个名字」，它会改变病种组合、特殊规则家族和分值结构。用同一批数据跑两版规则，能直观看到迁移规模和结构，而不是凭印象判断。
- 谁会使用结果：医保办、运营、病案编码、医院管理层；以及做专科与地区研究的分析者。
- 完成后的交付：一份「分母 + 改组率 + 特殊家族 + 按病种费用结构变化 + 失效条件」的测算说明，可作为本地版本迁移评估的样板。
2. 公开与隐私前检
3. 执行环境
| 字段 | 记录 |
|---|---|
| 执行方式 | 本地脚本批量分组（非 MedGroup 单病例页面） |
| 脚本 | 源归入「来源/2026-06-DIP3规则切换影响测算-demo/source/」的 run_zhengzhou_2026_dip_grouping.py 与 generate_dip3_impact_report.py |
| DIP 2.0 规则 | 全国版分组规则 |
| DIP 3.0 规则 | 3.0 征求意见稿（预研）生成规则包 |
| 执行日期 | 2026-06-06 |
| 地区 | 全国版（2.0/3.0 口径对照）；另以郑州市 2026 本地规则做适用性分组 |
| 数据规模 | 21,970 例合成演示批次 |
| 登录状态 | 不涉及（本地脚本 + 本地规则包） |
4. 输入快照
本案例的「输入」不是一个个病例，而是一批已经结构化的病例集合，外加两套规则口径。
| 输入项 | 值 | 来源/构造方式 | 是否敏感 | 说明位置 |
|---|---|---|---|---|
| 批次规模 | 21,970 例 | 合成演示 fixtures | 否 | aggregate-summary.json |
| DIP 2.0 规则 | 全国版分组规则 | 公开发布 | 否 | 规则包 |
| DIP 3.0 规则 | 3.0 征求意见稿（预研） | 公开发布 | 否 | 规则包 |
| 点值 / 系数 | 未给定 | — | 否 | 本测算不折算金额 |
| 郑州市 2026 本地规则 | 郑州本地 DIP 目录 | 公开发布 | 否 | 适用性分组用 |
结构化输入的聚合值保存为：
json
{
"batch_case_count": 21970,
"rule_dip2": "DIP 2.0 全国版",
"rule_dip3": "DIP 3.0 征求意见稿（预研）",
"point_value_given": false
}完整路径无关聚合值见 assets/evidence-data/aggregate-summary.json。
5. 执行步骤
| 步骤 | 动作 | 预期 | 实际结果 | 失败回退 |
|---|---|---|---|---|
| 1 | 载入 21,970 例合成演示批次 | 批次可读 | 21,970 例载入 | 校验批次 schema |
| 2 | 用 DIP 2.0 全国版规则批量分组 | 返回 2.0 病种 | 入组 18,677 例 | 检查规则包版本 |
| 3 | 用 DIP 预研口径规则批量分组 | 返回 3.0 病种 | 入组 18,798 例 | 检查规则包版本 |
| 4 | 逐例比对两次分组结果 | 输出改组清单 | 改组 10,070 例 | 抽样复核 |
| 5 | 用郑州市 2026 本地规则分组 | 输出本地病种 | 入组 21,791 例，未入组 179 例 | 核对本地目录版本 |
每次重新执行记录日期、规则包版本与差异；规则包版本变化时需要重做本测算。
6. 系统返回
6.1 原样记录（路径无关聚合值）
| 返回字段 | 系统显示值 | 是否版本敏感 |
|---|---|---|
| 批次规模 | 21,970 例 | 否 |
| DIP 2.0 入组 | 18,677 例 | — |
| DIP 3.0 入组 | 18,798 例 | — |
| 改组例数 | 10,070 例（占批次 45.8%） | 是 |
| 特殊规则改写 | 4,004 例 | 是 |
| 规则提示命中 | 1,331 例 | 是 |
| 执行耗时 | 17,708 ms | 否 |
6.1.1 五类迁移，分母写在最前面
分母是 21,970——参与测算的全部病例，不是"能在两版都入组的病例"。 这一点必须先说，否则下面每个百分比都无法比较。
| 迁移类型 | 例数 | 占全批 | 含义 |
|---|---|---|---|
| 未变化 | 11,900 | 54.16% | 两版落到同一病种 |
| 基础规则变化 | 4,180 | 19.03% | 病种码变了，走的是基础规则 |
| 特殊规则改写 | 4,004 | 18.22% | 命中被显式重写的特殊规则 |
| 新版未入组 | 1,046 | 4.76% | 旧版入组，新版进不去 |
| 新版新增入组 | 840 | 3.82% | 旧版未入组，新版能进 |
| 合计 | 21,970 | 100% |
五类相加正好等于分母，没有遗漏也没有重复计数——这是迁移矩阵最基本的自检，做不到说明分类逻辑有重叠。
改组率 45.84% 就是后四类之和（4,180 + 4,004 + 1,046 + 840 = 10,070）。
最后两类容易被合并处理，但它们方向相反
「新版未入组」1,046 例是能力倒退——这批病例在旧版有归属，新版没有了，需要逐条查是规则收紧还是数据问题。
「新版新增入组」840 例是覆盖扩大——旧版进不去的病例现在有组了。
把它们一起算进"改组"会掩盖这个方向差异。 交给病案复核时，这两类的处理路径完全不同。
按特殊家族拆分：
| 特殊家族 | 例数 | 变更例数 | 变更率 |
|---|---|---|---|
| 无（基础规则） | 17,966 | 6,066 | 33.8% |
| tumor_treatment（肿瘤治疗联合） | 3,859 | 3,859 | 100% |
| high_resource（高资源） | 60 | 60 | 100% |
| burn（烧伤） | 54 | 54 | 100% |
按病种取前 5（表内 avg_fee 为批次中病例自带费用字段的均值，反映病种归集后的费用结构，不是支付标准，也不含点值折算）：
| DIP2 病种 | DIP3 病种 | 变化类型 | 迁移例数 | 2.0 均费 | 3.0 均费 | 均费差 |
|---|---|---|---|---|---|---|
| NA | NA | 未变化 | 2,126 | 19,652.23 | 17,836.77 | −1,815.46 |
| Z51.1:99.2503 | Z51.1+ADX(C00-C75):99.2503 | 特殊规则改写 | 2,214 | 6,935.12 | 6,724.88 | −210.24 |
| I63.9:BSZL | I63.9:BSZL | 未变化 | 541 | 10,448.24 | 10,366.77 | −81.47 |
| Z51.0:92.2900x001 | Z51.0:92.2900x001 | 未变化 | 137 | 37,859.00 | 37,859.00 | 0.00 |
| Z51.0:92.2400x003 | Z51.0:92.2400x002|003|005 | 基础规则变化 | 124 | 38,848.69 | 38,068.14 | −780.55 |
6.2 作者解释
- 改组率 45.8% 是「同一批病例在 2.0 与 3.0 下落到不同病种」的比例。它衡量的是结构迁移规模，不是金额影响。
- 特殊规则改写 4,004 例、命中率 100% 的肿瘤/高资源/烧伤家族，说明 3.0 的主要变化集中在几类被显式重写的特殊规则上，而不是均匀散布——这正是版本迁移「先盯特殊家族」的方法依据。
- 表 6.1 的
均费差是病种归集后病例费用字段均值的差异，来自同一批病例被分到不同病种后，各组构成变了。它不表示支付差额，也不表示利润，因为：① 这是费用字段不是支付标准；② 本测算未给定点值/系数，没有折算成金额；③ 演示批次的费用分布与真实医院不同。 - 郑州市 2026 本地分组 用同一批数据得到 21,791 入组、179 未入组、唯一病种码 2,466 个，说明本地目录与全国版口径并不一致——这正呼应「换地区就换规则」的纪律：全国版结论不能直接套到郑州。
6.3 管理建议
- 版本迁移评估先按特殊家族拆分，再谈总体改组率；肿瘤治疗、高资源、烧伤这类被显式重写的家族要单独做编码与临床路径核对。
- 不要把「改组率 45.8%」或「均费差」直接说成「影响多少钱」。影响金额 = 病种分值变化 × 当地当期点值，这一步必须补上点值/系数才能成立。
- 本地适用性要单独验证：用本地目录重跑，确认未入组病例与异常病种，避免把全国版迁移结论平移到本院。
- 以上均为分析结论，不构成编码、结算、绩效或临床决策的最终依据。
7. 结果复核
| 复核项 | 方法 | 证据 | 结论 |
|---|---|---|---|
| 分母一致性 | 三份汇总文件的 case_count / rowCount 比对 | aggregate-summary.json | 一致：21,970 |
| 规则版本 | 规则包标识与执行日期记录 | 执行环境表 | 2.0 全国版 vs 预研口径 |
| 改组率 | 10,070 / 21,970 复算 | 汇总文件 | 45.8% ✓ |
| 边界 | 模拟与清算、全国与本地分开表述 | 6.2 / 已知边界 | 未混用 |
| 路径安全 | 源文件不含本机/内部路径 | 来源目录复核 | 通过 |
8. 截图与素材清单
本案例为批量数据分析，不依赖 MedGroup 单病例页面截图。证据以结构化汇总文件形式留存：
| 素材 | 路径 | 说明 |
|---|---|---|
| 路径无关聚合值 | assets/evidence-data/aggregate-summary.json | 本案例全部数字来源 |
| 病种级迁移汇总（源） | 来源/2026-06-DIP3规则切换影响测算-demo/dip2-dip3-compare-output/dip2_dip3_migration_summary.json | 逐病种费用结构 |
| 特殊家族汇总（源） | .../dip2_dip3_family_summary.csv | 按特殊家族拆分 |
| 病例级对照（源） | .../dip2_dip3_case_level.json | 逐例 2.0/3.0 对照 |
原始批次与含路径的源汇总已做脱敏，不随案例公开。
9. 已知边界
- 数据边界：批次为合成演示数据，费用字段分布不代表任何真实医院；结论不能外推为真实清算结果。
- 版本边界：DIP 3.0 为征求意见稿（预研）口径，正式发布后需重做本测算。
- 参数边界：未给定点值/系数，结论只到病种与费用字段层面，不折算为金额；要算金额必须补当地当期点值。
- 地区边界：全国版与郑州市 2026 本地规则结论不同，不可平移。
- 模拟/清算边界：表内均费是病例费用字段均值，不是支付标准，也不等于最终清算。
- 失效条件：若 3.0 正式规则、本地目录版本或批次结构变化，本测算不再成立，需重跑并记录。
- 仍需人工复核：真实迁移评估应叠加本院真实病案与当地正式点值，本案例仅提供方法样板。
9.1 想自己复现的话：一个会静默出错的坑
病例级对照产物是一份 21,970 行的 CSV。其中 98 行含内嵌逗号——中文诊断名里本身带逗号，例如：
text
"阴道上皮内肿瘤,Ⅰ级"文件本身完全合规：这些字段都正确加了引号，用任何标准 CSV 解析器读都没问题。
但如果你用 cut -d, 或 line.split(',') 处理，这 98 行会静默错位——列数从 21 变成 22 或 24，后面所有字段整体右移。它不报错，只是给你 98 行错误数据。
python
# 对的
import csv
rows = list(csv.DictReader(open(path, encoding='utf-8')))
# 错的：98 行会错位，且不会有任何提示
rows = [line.split(',') for line in open(path)]自检方法：读完之后统计每行字段数，应该全部相等。不相等就说明解析出了问题。
这条经验的适用范围远超本案例——任何含中文文本字段的 CSV 都可能有这个问题，而诊断名、手术名、科室名恰好都是中文文本字段。
10. 案例完成自检
-
evidence.md