跳转到内容

影像检查预约协同:大设备排班少空转

这篇案例来自 医疗健康 场景,关注的是医院里一种特别典型的资源协同难题:
CT、MRI、增强检查、特殊影像检查这些设备很贵、时间窗很紧,可真正让设备利用率掉下来的,往往不是没有患者,而是预约前后那条准备链没有接稳。

现场里常见的抱怨通常有两种:

  • 检查中心觉得患者总是准备不全、迟到、爽约
  • 门诊和病区觉得预约规则复杂、改期太频繁、患者不容易配合

但如果把这条链拆开看,会发现它不是单点问题,而是一串连续动作没对齐:

  • 医生开单后,患者是否匹配正确检查类型
  • 检查前准备是否讲清楚
  • 造影、空腹、肾功能等前置条件是否满足
  • 当天时段安排有没有和其他治疗动作撞车
  • 患者是否真的能按时到场

只要其中一段没接稳,大设备排班就很容易出现两头难受的情况:

  • 患者排了很久,结果当天做不了
  • 设备明明很满,实际时段却被空转吞掉

这条链为什么看似标准化,实际上很容易失真

Section titled “这条链为什么看似标准化,实际上很容易失真”

影像检查预约表面上像一个时间分配问题,真实现场其实至少包含四层协同:

  • 临床侧:开什么检查、有没有禁忌、是否紧急
  • 检查中心:设备时段、造影安排、人员班次
  • 患者侧:到院时间、准备事项、理解程度
  • 院内其他流程:抽血、会诊、用药、手术、住院安排

一名患者能不能顺利完成检查,取决于这些条件能否在同一时间点对齐。
可旧流程里,这些条件往往分别散在:

  • 医生说明
  • 预约单
  • 短信通知
  • 检查中心口头交代
  • 患者自己记忆

于是就很容易出现这种特别典型的现场:

患者确实来了,但准备不合格;
设备时段留出来了,但最后没用上;
后面排队的患者还在继续等。

老办法的问题,不是没有预约系统,而是预约系统管不了“准备是否真的就绪”

Section titled “老办法的问题,不是没有预约系统,而是预约系统管不了“准备是否真的就绪””

改造前,大多数医院已经有排号或预约模块,但现场依然会出现下面这些高频返工。

1. 检查类型和实际适应症匹配不稳

Section titled “1. 检查类型和实际适应症匹配不稳”

临床开单没有错,但在增强、平扫、特殊序列、联合检查等细分场景里,后续仍可能反复确认。

2. 前置条件没有在预约前被提前校验

Section titled “2. 前置条件没有在预约前被提前校验”

像肾功能、空腹、既往过敏史、金属植入、孕期风险等,如果等到患者到场才核对,就已经太晚了。

医院以为通知了,患者以为自己记住了,可到了现场才发现:

  • 该空腹没空腹
  • 该停某类药没停
  • 该提前到院没提早

设备利用率看起来不高,但到底是爽约多、准备不全多、规则解释不清多,往往没人说得准。

旧流程在高峰日里,为什么特别容易把设备时段“看着排满,实际上打折”

Section titled “旧流程在高峰日里,为什么特别容易把设备时段“看着排满,实际上打折””
flowchart TB
    A[医生开立检查申请] --> B[预约系统先分配时间]
    B --> C[患者收到时间和简单说明]
    C --> D[当天到院后再核对准备条件]
    D --> E{是否满足检查要求}
    E -->|是| F[进入检查]
    E -->|否| G[改期 / 顺延 / 重新解释]
    G --> H[设备时段被部分空转]

如果站在检查中心负责人角度看,这条链最大的痛点不只是有人没来,而是:

  • 来了也不一定能做
  • 做不了的原因事前没被识别
  • 后续也不知道最该改哪段规则

派宝在这里做的,不是替设备排班,而是把“能不能顺利检查”这件事提前算清楚

Section titled “派宝在这里做的,不是替设备排班,而是把“能不能顺利检查”这件事提前算清楚”

先把预约依赖的关键条件统一到同一张准备面

Section titled “先把预约依赖的关键条件统一到同一张准备面”

通过 多系统数据同步表单数据采集,先把预约真正依赖的条件收束起来:

  • 检查项目类型
  • 紧急程度
  • 近期相关化验
  • 过敏与禁忌信息
  • 患者联系方式与到院方式
  • 其他治疗冲突情况

这样预约不再只是一个时间槽,而是一份“当前是否具备顺利执行条件”的状态对象。

再把高风险未准备充分的情况前置识别

Section titled “再把高风险未准备充分的情况前置识别”

这里会用到 风险预警流程自动触发

系统提前盯住的,通常是这些风险:

  • 检查前必需条件仍未满足
  • 患者尚未确认到院
  • 同一时间段设备负荷过高
  • 患者当天还有其他高冲突流程
  • 某类项目连续出现爽约或准备不全

这样很多问题会在前一天甚至更早暴露,而不是等到机器旁边才发现。

这一步重点不是多发消息,而是针对不同角色发不同动作:

  • 给患者发清楚的准备说明和到院要求
  • 给病区或门诊提醒需要补的前置条件
  • 给检查中心提示哪些预约存在较高改期风险
  • 给协调岗提示哪些空档可以提前释放给候补患者

这类动作通常会落在 短信消息发送任务提醒企业微信通知 这些能力上。

只有当系统能稳定记录:

  • 因准备不足导致的改期
  • 因患者爽约导致的空档
  • 因流程冲突导致的顺延

管理端才能真正知道,到底是规则没讲清、流程没接稳,还是设备安排需要优化。

新流程的价值,不是让机器更忙,而是让有效检查占比更高

Section titled “新流程的价值,不是让机器更忙,而是让有效检查占比更高”
flowchart TB
    A[申请单、化验、禁忌信息、患者确认数据进入协同层] --> B[多系统数据同步]
    B --> C[形成检查前准备状态面]
    C --> D[风险预警识别准备不足和排班冲突]
    D --> E[流程自动触发推送不同角色待办]
    E --> F[短信 / 企业微信 / 任务提醒推动准备动作]
    F --> G{是否满足检查条件}
    G -->|是| H[按预约顺利检查]
    G -->|否| I[提前改期并释放或调整时段]
    H --> J[沉淀有效利用率数据]
    I --> J

一段时间运行下来,现场最明显的变化在哪里

Section titled “一段时间运行下来,现场最明显的变化在哪里”

在一个 MRI、增强 CT 和部分特殊检查并行的中心里,连续运行 6 周后,最直观的变化不是预约总量大涨,而是:

设备时段的无效占用明显少了。

对比项改造前改造后
因准备不全导致的当天改期较多下降约 35%
患者到院后才发现不满足检查条件常见明显下降
检查中心人工电话二次确认时间很高缩短约 44%
设备时段因爽约或条件不满足而空转时有发生明显下降
改期原因统计清晰度偏弱明显提升

这些变化最有价值的地方在于,医院终于能把“排班问题”进一步拆成真正可处理的准备问题。

为什么这类案例很适合做成可复制方法

Section titled “为什么这类案例很适合做成可复制方法”

因为它天然就是高价值资源与高频细碎准备的交叉点

Section titled “因为它天然就是高价值资源与高频细碎准备的交叉点”

设备贵、时段紧、患者多,只要准备链没稳,就很容易放大浪费。

因为它特别适合用规则把动作前移

Section titled “因为它特别适合用规则把动作前移”

哪些检查前要空腹、哪些必须先看化验、哪些患者要提前确认,都是很适合规则化推动的动作。

因为它不只改善设备利用率,也改善患者感受

Section titled “因为它不只改善设备利用率,也改善患者感受”

患者最讨厌的不是要求多,而是明明排到了号,到了现场却做不了。
只要这类情况下降,体验改善会非常明显。