## Context

DRG 入组准确性依赖病案首页/结算清单质量。当前实现 `src.DRG.QC:zPerformQCCheck` 将 5 条质控规则硬编码为顺序 `if` 语句，修改规则需改代码重编译；编码类(05)检查的 `GetDiagnosisList` 为空壳未生效；统计接口 `02010304` 仅返回 typeStats/levelStats，缺聚合总数与科室维度；前端 `api/qc.ts` 为空、`pages/` 无质控页面。

本项目已有成熟可复用资产：`User.BSDRGWarningRule`（规则表范式）、`pages/Warning/Center.tsx`（KPI/Tab/合计行/处理弹窗范式）、`useHospitalOptions`/`CustomPagination`/`useDict`、`BasicData` 已建 ICD10/ICD9CM3 字典。本设计目标是将这些资产组合，形成**配置化规则库 + 引擎驱动 + 分析 UI** 的闭环。

## Goals / Non-Goals

**Goals:**
- 质控标准沉淀为 `BS_DRGQCRule` 数据，运营/医保办可通过界面增删改规则。
- 检查逻辑引擎化：`zPerformQCCheck` 读表循环，按 `CheckerType` 分发到 5 个统一 handler。
- 规则类型可扩展：新增类型仅需加字典项 + handler，不改表结构；复杂规则用 `RuleExpr` 表达式引擎零代码。
- 提供 4 个分析页面（看板/问题管理/单份检查/规则配置），复用现有前端范式。
- 补全统计接口与新增规则保存接口。

**Non-Goals:**
- 本期不做规则审批流、规则版本管理。
- 本期规则配置页对 Expression 类规则提供文本输入，不做可视化规则编排器。
- 不重建 ICD 字典（复用 BasicData 已有）。
- 不做实时 HIS 嵌入（医生端预演留作后续扩展）。

## Decisions

### D1: 规则表同构 BSDRGWarningRule
新建 `User.BSDRGQCRule` 复用 `BSDRGWarningRule` 的字段范式（RuleCode/RuleName/IsActive/SeqNo/MDCCode/DRGCode 等），并新增质控语义字段（RuleType/CheckerType/FieldName/CompareField/Operator/ThresholdType/ThresholdValue/RuleExpr/SuggestValue/IssueLevel/IssueCategory）。
- 理由：与项目既有规则表风格一致，降低维护认知成本。
- 备选：独立新结构 → 拒绝，重复造轮子。

### D2: CheckerType 枚举 + 分发引擎（核心扩展点）
定义 5 种 CheckerType：`01 RequiredField`/`02 CompareField`/`03 ValueRange`/`04 DictExist`/`05 Expression`。`zPerformQCCheck` 改为 `SELECT * FROM BS_DRRGQCRule WHERE IsActive='1' ORDER BY SeqNo` 循环，调用 `DispatchCheck(checkerType, ruleRow, mr)` 分发。
- 理由：把"规则是什么"与"怎么检查"解耦；新增类型只需加 handler + 字典，老数据照跑。
- 备选：保留硬编码 if → 拒绝，无法扩展。

### D3: RuleExpr 表达式引擎（终极扩展点）
`CheckerType=05` 时，`RuleExpr` 存储 ObjectScript 表达式字符串（如 `TotalFee > ..GetDRGAvgFee(DRGCode)*2`），由 `EvalExpression(expr, mr)` 统一 `$zcvt`/间接执行求值。
- 理由：让非程序员也能加复杂规则，彻底零代码。
- 风险：表达式执行需做白名单/安全约束，禁止任意 `$system` 调用。

### D4: 问题级别用数字（对齐预警模块）
`IssueLevel` 取 1/2/3（提示/警告/严重），与预警 `WARNING_LEVEL` 一致；文档 06 原 `high/medium/low` 字符串说明以代码为准，需同步修正文档。
- 理由：前端已有数字级别渲染范式，避免双套。

### D5: 前端页面克隆 Center.tsx 范式
Issues 页直接克隆 `Center.tsx` 结构（KPI 卡片 + Tab + 高级搜索 + 合计行 + 处理弹窗），改字段映射；Dashboard 复用其 KPI 卡片样式。
- 理由：节省 60% 工作量且体验一致。

### D6: 接口字段顺序契约
所有 QC 接口入参用 `$lg(params,N)` 按位置取，`qc.ts` 数组顺序严格对应 `.cls`；文档化于 tasks。

## Risks / Trade-offs

- [Risk] 重构 zPerformQCCheck 改变原行为 → Mitigation：保持原 5 条规则的 RuleType/IssueLevel/IssueCategory 映射一致，初始化数据 1:1 还原。
- [Risk] 02010304 前后端字段口径不一致（当前仅 typeStats/levelStats）→ Mitigation：先改后端补齐聚合字段，再联调前端。
- [Risk] RuleExpr 表达式执行安全 → Mitigation：EvalExpression 做关键字白名单校验，禁止 `$system`/`^`/JS 注入。
- [Risk] 编码类规则依赖 ICD 字典完整性 → Mitigation：规则仅校验编码是否在字典存在，字典缺口由 BasicData 维护。
- [Risk] 大批量病案检查时规则表循环性能 → Mitigation：规则表规模小（数十~数百条），单份检查可接受；批量接口(02010305)留作后续分页批处理。

## Migration Plan

1. 部署 `User.BSDRGQCRule.cls` + 初始化 SQL（写入 7 条规则）。
2. 替换 `src.DRG.QC.cls` 的 zPerformQCCheck，新增 handler / DispatchCheck / EvalExpression / zSaveQCRule，补全 zQueryQCStats。
3. 前端填充 `api/qc.ts`、新增 `pages/QC/*`、注册路由菜单、补 3 字典。
4. 回归：对一条已知坏病案跑 02010301，确认产出 issue 与原逻辑一致。
- 回滚：保留原 zPerformQCCheck 逻辑于分支；规则表为空时引擎退化为不产出 issue（安全）。

## Open Questions

- 02010305 批量质控是否本期实现？（方案建议延后，仅预留接口位）
- Expression 规则的错误提示信息是否支持变量替换（如 `{field}`）？本期固定文本。