门诊加号协同：高优先级患者少在窗口来回跑

这篇案例来自 医疗健康 场景，讲的是门诊里一个特别常见、也特别容易让患者情绪迅速上来的现场：
患者已经到了医院，但原有号源不够、情况又比较急，前台、护士站、医生之间都在协调加号，可到底该不该加、先加谁、怎么通知，经常缺少一条清楚的协同链。

门诊加号表面上像一个简单动作，真实现场里却经常牵动多个因素：

• 患者是复诊、首诊还是外院转来
• 当前症状是否需要优先处理
• 医生今天的接诊负荷已经到什么程度
• 同专科其他医生是否还有承接余量
• 前台和护士站拿到的信息是不是同一版

一旦这些信息不同步，现场就会很容易出现这种让患者和医护都很累的局面：

• 患者在窗口、诊室门口、护士站之间来回跑
• 前台说去问医生，医生那边并不知道患者具体情况
• 护士站觉得应该优先处理，窗口又不知道怎么改排
• 患者只感受到“大家都在忙，但没人告诉我接下来怎么办”

这类问题为什么不是单纯“多放几个号”就能解决

很多门诊加号场景并不是资源绝对不足，而是 优先级判断和承接路径不清楚。

真实现场里，常见参与角色包括：

• 导诊或前台：接住第一轮诉求，判断是否进入加号协调
• 护士站：辅助判断紧急程度和接诊顺序
• 医生：决定是否加号、是否转其他时段或其他医生
• 患者与家属：补充病情背景、检查材料、外院建议

问题在于，患者诉求进入系统前，往往还是一句口头描述。
如果没有一条统一协同链，现场就只能靠前台临时解释、护士站临时判断、医生临时插空。

老办法最大的问题，是加号这件事高度依赖“谁当下刚好有空处理”

改造前，很多门诊现场处理加号大致是这样：

1. 患者到窗口提出加号需求
2. 前台或导诊先口头了解情况
3. 再去护士站或诊室外询问
4. 医生根据现场感受决定是否加号
5. 前台再回来改排或解释

这条链不是不能跑，而是非常依赖现场个人经验和沟通效率。

最常见的几个摩擦点

1. 前台拿不到足够信息

患者会说“我这个比较急”，但前台无法快速判断到底属于：

• 常规加号
• 高优先级需要尽快处理
• 应该转急诊
• 或者适合转其他门诊

2. 医生接到的是碎片化信息

到了医生那边，常常只剩一句“外面有个患者想加号”，但病情背景、既往记录、检查单并没有被整理好。

3. 现场插队感和公平感都容易受影响

如果没有清楚规则，其他患者会觉得为什么有人能插进来，被加号患者也不知道自己到底排在什么位置。

4. 相同类型诉求反复人工处理

同一种加号需求，今天这个前台能处理，明天换个人又要从头问一遍。

旧流程为什么总像在把患者往不同窗口之间推

flowchart TB
    A[患者到窗口提出加号需求] --> B[前台口头了解情况]
    B --> C[前台或导诊去问护士站 / 医生]
    C --> D[医生临时判断是否加号]
    D --> E{是否可以接诊}
    E -->|是| F[前台重新改排或手工插入]
    E -->|否| G[患者再被引导去其他窗口或时段]
    F --> H[现场继续解释和安抚]
    G --> H

旧流程最典型的低效，不在加号本身，而在信息和动作没有被一次性整理好。

派宝在这里做的，不是替医生决定加不加，而是先把加号判断前需要的信息收齐

第一步：把患者诉求从口头描述变成结构化申请

通过 表单数据采集，前台或导诊不再只是听一句“想加号”，而是快速收集：

• 就诊目的
• 是否复诊
• 当前主要症状
• 是否带有检查结果或外院建议
• 是否已做基础分诊

这样加号诉求就不再是一句模糊口头说明，而是一份可被后续角色快速理解的申请。

第二步：把高优先级对象先识别出来

这里会用到 风险预警 和 客户意向判断 这类能力思路，不过在门诊场景里更像“就诊紧急程度和承接优先级判断”。

系统会帮助区分：

• 需要尽快进诊室的高优先级诉求
• 可安排普通加号的诉求
• 更适合转其他专科或其他时段的诉求

这一步并不是替医生诊断，而是把现场最需要先处理的人先筛出来。

第三步：把沟通和改排动作正式推进

这里最关键的是 任务提醒、流程自动触发 和 工单创建 的思路。

系统可以把动作拆成不同路径：

• 通知护士站和医生查看结构化加号申请
• 若同专科其他医生有可承接余量，给前台推荐转诊路径
• 若决定加号，自动推动前台完成改排和患者通知
• 若不适合门诊加号，自动生成更清楚的下一步指引

这样患者就不会在“去那边问问”里反复打转。

新流程最值钱的地方，是把加号这件事从临场协调，变成可重复执行的规则链

flowchart TB
    A[患者提出加号需求] --> B[表单数据采集形成结构化申请]
    B --> C[风险预警识别高优先级就诊对象]
    C --> D[流程自动触发推送给护士站 / 医生 / 前台]
    D --> E{当前医生能否承接}
    E -->|能| F[任务提醒推动改排并通知患者]
    E -->|不能| G[推荐其他门诊 / 时段 / 更合适入口]
    F --> H[患者接收更清楚的就诊路径]
    G --> H

一段时间跑下来，门诊最先感知到什么变化

在一个复诊患者多、外院转诊和临时加号都比较常见的专科门诊里，连续运行 6 周后，最明显的变化不是所有人都能被加号，而是：

真正需要优先处理的患者，更快被看见了；不适合加号的患者，也更快拿到了清楚解释。

一组更贴近现场的变化

对比项	改造前	改造后
患者为加号需求往返多个窗口的情况	常见	明显下降
前台人工反复询问和转述病情的时间	很高	缩短约 45%
医生接到碎片化加号请求的频率	较高	明显下降
高优先级对象的前置识别速度	不稳定	明显提升
患者对“为什么能加 / 不能加”的理解度	偏低	明显提升

这些变化说明，门诊加号最缺的不是一个额外按钮，而是一条把申请、判断、改排和解释接起来的链。

为什么这个案例很值得做

因为它直接影响门诊第一线体验

很多患者对医院的第一印象，不是来自诊疗本身，而是来自“现场有没有人把我的问题接住”。

因为它非常适合用规则去减少重复问答

同类加号场景每天都在发生，越标准的部分越适合先被系统接走。

因为它还能继续长出很多邻近场景

比如：

• 检查插队审批
• 专家门诊临时承接
• 外院复诊资料预审
• 特殊病种绿色通道

本案例关联能力

• 表单数据采集
• 任务提醒
• 工单创建
• 流程自动触发
• 风险预警
• 客户意向判断