FangJi DRG
2024
方济 DRG 是给临床医生和医保科用的 DRG 数据与入组系统。它有两条主要路径：批量预审看一批病例的整体质量，单病例查询负责录入参数、查看分组结果和继续调整。
我负责产品界面设计，参与了现状梳理、信息架构、核心流程、界面方案、组件规范和开发跟进。改版时我一直盯着一个问题：用户看到结果后，能不能马上找到原因、理解建议，并完成下一步。
设计重点不在增加更多规则，而在把同一份 DRG 判断分别翻译成总览、病例详情和单病例查询三种工作视图。临床医生先定位异常，医保人员再确认分组依据和调整影响，三种视图始终使用同一套结果和状态语言。
先把两条业务线理清楚
旧系统已经有批量预审和单病例查询，但两条路径的组织方式不像一套产品。批量场景要先看整批数据有没有问题，单病例场景则要查清楚某个病例为什么异常、改哪里更合适。原来的页面把结论、原因、建议和明细挤在一起，用户只能来回跳，自己拼出判断。
先把问题收窄
我把问题归成三个重点：结果、原因和建议没有主次；入组状态和异常原因不够醒目；批量和单病例的处理路径也接不上。所以我先把阅读顺序定下来：看结论，再看解释，最后进入明细。异常要能定位、处理，之后还能回查；两条业务线的状态和反馈也用同一套规则。
从信息层级开始改
页面里的阅读顺序先改了：结论先出现，解释和字段明细往后放。异常处理按“要不要处理—看建议—推演—记录”往下走，建议再分成推荐和可选。结果卡、建议卡、推演弹窗和问题聚类卡也用同一套状态语言，换到另一个页面，用户不用重新学。
导航先服务任务切换
这类后台经常要同时处理几个批次和病例。旧版侧栏、标签和内容区挤在一起，切换一次任务就要重新找位置。我把稳定模块放回侧栏，顶部标签页只负责并行任务。这样从智能入组预审切到病例查询时，不用重新适应页面结构，内容区也能留给当前任务。
批量预审先给总览
批量入口先给总览：累计处理量、综合入组成功率、QY/歧义组占比和平均 CMI。趋势图用来判断问题有没有变多，历史批次则留给回查。用户先知道整批数据的状态，再决定要不要打开某个批次。
把病例详情拆成两个阶段
病例列表和详情分成两段：先看入组结果摘要，再进入病例详情分析。前者负责全局判断和风险聚合，后者负责筛选异常病例、处理问题和回查记录。建议的存档与追溯也放在这条路径里，用户不用在总览和详情之间来回找。
异常要能继续处理
详情页先放分组结果、QY/歧义和未入组状态，字段明细往后收。建议卡、调整前后对比和抽屉详情放在同一处，用户可以边看边推演。方案 A 和 B 对比后，我保留了 B：定位、处理、回查各有位置，长任务里更容易保持顺序。
批量流程要覆盖中间状态
批量预审不只画最终结果，上传、处理中、完成、病例列表和结果抽屉都要有对应状态。等待时告诉用户系统正在处理什么，完成后给出下一步入口，历史批次负责回查。这样用户不会卡在“到底有没有跑完”。
单病例查询改成左右分屏
单病例查询把录入和结果放到同一屏。左侧填写主要诊断、手术、住院天数等参数，右侧显示分组结果、调整建议和费用影响。改一个条件，结果就能马上对照，不用在两个页面之间来回切。没有结果时也显示等待和空状态，用户知道系统是在算，还是还没开始。
组件也要跟着落地
组件重构先从分类开始：业务、反馈、导航、布局和数据呈现分别整理，再统一组件的类型、尺寸和状态。设计侧分阶段替换旧组件，前端先搭基础组件，新的需求再往上加。状态、交互和尺寸说明一起写进规范，后面不用每个模块重新发明一套。
试点结果与复盘
为期 2 周的试点覆盖 60 个批次（约 2.1 万病例），其中异常病例约 1050 条，并收集了 7 名临床医生和 12 名医保科人员的反馈。与原有流程相比，异常病例处理效率提升 35%；单次核查从 2.6 分钟降到 1.7 分钟，批量问题定位从 2.1 分钟/批次降到 0.7 分钟/批次，同一病例在 10 分钟内重复打开抽屉或重复修改筛选条件的次数下降 37%。
从试点结果看，变化主要发生在路径上：先看整批状态，再定位问题，最后进入病例处理。下一步还可以补上批量标记、导出、建议采纳记录和参数变更回放，让异常处理留下完整记录。