MedicalInsurance/openspec/changes/develop-mr-quality-control-analysis/design.md

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 与原逻辑一致。
5. 回滚：保留原 zPerformQCCheck 逻辑于分支；规则表为空时引擎退化为不产出 issue（安全）。

Open Questions

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