外观
未入组与异常病例怎么排查
本章解决：一个病例未入组、结果异常或新旧版本不一致时，怎样按证据顺序排查，而不是先猜系统错误或先改编码。
1. 先给排查顺序
四步，按这个顺序走：
数据 → 编码 → 规则 → 系统| 步 | 查什么 | 谁能修 |
|---|---|---|
| 1 数据 | 必填字段缺没缺、格式对不对、0 与"不适用"有没有混用 | 信息／病案 |
| 2 编码 | 编码在当前版本有效吗、粒度够不够、主操作位次对不对 | 病案／编码 |
| 3 规则 | 地区与版本是不是预期的那个、有没有命中排除逻辑 | 医保 |
| 4 系统 | 同一输入重跑是否一致、批量与单例是否不同 | 信息 |
顺序不能反。 实务里原因分布恰好和直觉相反——绝大多数是数据和编码问题，规则和系统排最后。从"规则有问题"开始查，会绕最远的路，还容易把数据问题误判成医保的责任。
一个例子：它卡在第 2 步
某条肺炎病例返回未入组。按顺序走：
| 步 | 查了什么 | 结果 |
|---|---|---|
| 1 数据 | 主诊断、性别、年龄、住院日齐全，格式正常 | 排除 |
| 2 编码 | 主诊断填的是临床版编码，医保版目录里查不到 | 命中 |
| 3 规则 | — | 不用查了 |
| 4 系统 | — | 不用查了 |
四步只走了两步。 如果反着来，先去核规则版本、再核接口日志，最后才发现是一个编码版本问题——同样能找到，但多花几小时，而且中间会去问医保办"是不是你们规则有问题"。
这条病例的完整排查见灰码不入路径；编码版本这类问题单独有一章：临床版和医保版对不上时怎么办。
一条底线
任何为了"进目标组"而反向修改病历或编码的做法，都不属于本章方法。排查的目的是找出原因，不是让它入组。
下面几节是每一步的展开——遇到具体问题时按需查，不必顺读。
2. 先把问题说具体
“这个病例有问题”不能执行。应改写成：
- 为什么未入组？
- 为什么单例与批量结果不同？
- 为什么当前版与 预研口径结果不同？
- 为什么临床预期与规则结果不同？
- 为什么某条其他诊断没有形成 CC/MCC？
- 为什么有操作却进入保守治疗/内科路径？
问题写清后，再确定需要的规则版本、字段和证据。
3. 固定输入快照
至少保存：
| 类型 | 字段 |
|---|---|
| 环境 | 地区、DRG/DIP、规则版本、执行日期、页面/接口 |
| 病例 | 性别、年龄、体重（适用时）、住院日、离院方式（适用时） |
| 诊断 | 主要诊断、其他诊断、编码、名称和顺序 |
| 操作 | 主要/其他操作、编码、名称和顺序；无操作显式记录 |
| 支付 | 仅在任务确需模拟时记录参数、来源和单位 |
| 证据 | 输入 JSON、原始截图、标注截图、执行结果和复核人 |
每次修改一个字段，生成新快照。否则无法判断结果变化来自规则还是输入。
4. 第一层：数据和编码
数据检查
- 必填字段是否缺失？
- 空值、0 和不适用是否混用？
- 年龄和住院日单位是否正确？
- 单例和批量字段映射是否一致？
- 诊断/操作顺序是否在导入时丢失？
编码检查
- 编码在当前版本中是否有效？
- 是否使用灰码、过粗编码或名称代替编码？
- 主要诊断选择是否有完整病案依据？
- 其他诊断是否满足报告条件？
- 操作是否真实发生、编码正确、位次符合事实？
系统返回“可分组”不等于上述问题已经通过。
编码这一步还有一种情况容易漏
两套版本里这个码都有效，但它们不是同一个码——临床版与医保版之间的映射不是一一对应。这类问题在页面上表现为"编码无效"或"查不到"，但改码解决不了。
处理方式见临床版和医保版对不上时怎么办。
5. 第二层：规则路径
DRG
按 先期分组 → MDC → ADRG → DRG → CC/MCC/年龄等细分 逐层记录：
- 命中条件；
- 未命中条件；
- 排除关系；
- 页面或规则证据；
- 仍待病案确认的事实。
DIP
按 主要诊断 → 操作组合 → 当地目录 → 病种类型 → 分值 → 例外机制 逐层记录。
不要把广州、上海或其他地方目录外推成全国统一规则。
6. 第三层：最小化复现
当结果异常时：
- 复制原始输入。
- 只保留主要诊断和必要病例属性。
- 重跑并保存基线。
- 按原顺序逐条加入其他诊断和操作。
- 每次记录结果变化。
- 找到最小触发字段后，再回到完整病例验证。
最小化输入用于定位，不用于替代完整病案。
7. 真实页面案例怎样使用
一次走完四步的实测
填了一个大手术，为什么还是内科组是这套方法的完整演练：固定其余全部输入、只换主要操作，结果纹丝不动。第一步数据排除，第二步编码定位到原因——那个编码是灰码，关联 ADRG 为空，不参与分组路径。三、四步不用再走。
它用全国版执行，你可以自己跑一遍对结果。
北京 DRG 案例：版本与支付标准读取
北京 DRG 案例 在北京市 DRG 页面返回当前口径 ES35、RW 0.5271、支付标准（参考）¥10765.49，并提示 预研口径 ES45。它证明“版本必须作为输入保存”，也演示怎样从结果中同时读出 DRG 代码、RW 和支付标准（参考）。
郑州 DIP 案例：无操作与保守治疗
郑州 DIP 案例 使用郑州 DIP、J18.900、无手术操作，稳定返回 J18:BSZL、基层病种、383.12 分、支付标准（参考）¥3563.02（点值 9.3、系数 1）。它教学诊断—操作组合、病种类型、分值与支付标准计算。
版本对比案例：同一输入下的规则迁移
版本对比案例 使用与 C01 完全相同的输入，仅切换规则口径：北京市当前口径为 ES35，预研口径为 ES45。它证明解释版本迁移必须先固定输入，不证明医院总体迁移规模。
8. 问题病例记录表
| 字段 | 内容 |
|---|---|
| 问题编号 | 全局唯一 |
| 原始问题 | 未入组/异常入组/版本差异/单批不一致 |
| 输入快照 | 路径、哈希、生成时间 |
| 页面结果 | 原样记录 |
| 规则依据 | 文件、版本、规则路径 |
| 最小触发字段 | 诊断/操作/位次/年龄/其他 |
| 人工复核 | 临床、病案、医保、信息分别结论 |
| 问题归类 | 数据、编码、规则、产品、无法确定 |
| 处理动作 | 修正数据、补证据、提交规则/系统问题、保持原结果 |
| 不可推出 | 清算、诊疗、质量、绩效等边界 |
9. 常见错误和失败回退
| 错误 | 为什么危险 | 正确处理 |
|---|---|---|
| 先改主诊再解释 | 可能形成结果导向编码 | 回到主诊选择依据 |
| 把系统 CC/MCC 当临床诊断证明 | 混淆规则分类与病历事实 | 回到完整病案和排除关系 |
| 截图只保留最终代码 | 无法复现输入和版本 | 保存输入、结果、路径三组证据 |
| 单例与批量不一致就认定接口错误 | 可能是字段映射或顺序差异 | 固定同一 JSON 逐字段对照 |
| 试行版结果写成正式执行 | 误导结算和管理 | 并列标明版本状态 |
| 无法复现仍继续给原因 | 把猜测写成事实 | 标记“未定位”，保留证据并升级复核 |
10. 岗位分工
| 岗位 | 负责回答 |
|---|---|
| 临床 | 诊疗事实、诊断和操作是否真实发生 |
| 病案/编码 | 主次选择、编码、位次和报告条件 |
| 医保 | 当地版本、支付政策、例外和清算边界 |
| 信息 | 字段映射、版本配置、日志和单批一致性 |
| 运营/数据 | 批量规模、结构和趋势；不从单病例评绩效 |
11. 本章练习
任选 三个实测案例：
合格标准：他人能只凭记录复现结果，且不会把系统结果误写成编码、结算或临床结论。
12. 读完你应该能
- 问题是可执行的问题句。
- 地区、类型、版本、日期和输入可追溯。
- 数据、编码、规则、系统四层分开检查。
- 修改输入时一次只改一个变量。
- 原始结果、作者解释和岗位行动分开。
- 失败时有“停止解释并升级复核”的出口。
- 未从单病例外推科室或医院结论。
- 未为了入组结果调整病历事实。
13. 来源
- 国家医疗保障局：《国家医疗保障疾病诊断相关分组（CHS-DRG）分组与付费技术规范》。https://www.nhsa.gov.cn/module/download/downfile.jsp?classid=0&filename=a3cbb51dc6354dd4b6a5ab09bec18121.pdf
本书的实测依据
下面这些不是政策文件，是本书自己跑出来或整理的东西。可以用来理解方法，不要当规则引用——要写进正式材料，回到上面的官方来源。
- MedGroup 三个案例的生产页面执行、输入快照与证据记录，2026-07-27。
- MedGroup MCP 自动化手册事实核对与测试矩阵，合成病例辅助证据，2026-07-20。