手术排期协同：术前准备少返工

这篇案例放在 医疗健康 场景里，讲的不是门诊咨询，也不是检查报告整理，而是一条医院里特别典型、也特别容易把多个岗位一起拖进反复确认的链路：
手术什么时候排、术前资料齐不齐、麻醉评估做没做、手术室和病区准备有没有撞车、家属沟通是否完成。

很多医院其实已经有 HIS、EMR、手麻系统、检验系统和排班表，但一到真实现场，大家还是会觉得这条流程“总差一口气”：

病区以为病人第二天能上台
手术室发现同时间段资源已经满了
麻醉科看到评估材料还缺一项
化验结果已经出来，但没有及时回到排期判断里
家属沟通没有完成，手术时间又得往后推

这条链最折腾人的地方，不是系统里没有数据，而是 每一个环节都知道一点，但没人持续把整条链看成一个正在变化的协同对象。

先看这个现场到底是怎么忙起来的

这是一家年手术量在中高位、专科与综合手术并行的医院。
平日就有大量择期手术，遇到节前、专家出诊集中日、病床周转波动时，排期压力会明显放大。

一条正常的手术准备链，至少会涉及这些角色：

病区医生：提出手术申请，判断病情和手术窗口
护士站：催资料、盯病人准备状态、和家属确认时间
麻醉科：查看评估材料，确认是否满足麻醉条件
手术室排班人员：统筹台次、手术间、器械和护理资源
检验/影像：提供术前化验、影像与会诊结果
医务或运营管理：盯高峰时段资源使用率和延误情况

纸面上看，这条流程像是“提交申请 -> 排台 -> 上台”，很直。
可真实现场里，它更像一条不断被信息变化打断的链：

今天上午刚定好的台次，下午又因为化验指标异常被卡住
某位专家门诊拖延，原本排在后面的病人准备时间被压缩
手术室排班表是新的，病区群消息里还是老版本
麻醉评估意见补进系统了，但护士站没及时看到
患者家属还在犹豫签字，病区已经按明早第一台去准备

所以医院最怕的，不是排不出表，而是 排出来以后不停返工。
返工多了，手术团队觉得累，病区也焦虑，患者体验还会明显受影响。

旧流程不是没人做事，而是每个人只在自己那一段拼命补洞

改造前，医院里的手术排期协同常常是这样推进的：

病区医生在系统里提交手术申请
护士站补录或催收术前材料
手术室根据申请量和资源先排一版台次
麻醉科、病区、手术室再分别确认是否具备上台条件
如果其中任何一步有变化，再通过电话、群消息、表格重新沟通

这条链真正的问题不在于“谁偷懒”，而在于每一步都可能发生变化，但变化没有被自动接续下去。

一线最常见的四种返工

1. 资料齐套状态判断太依赖人工追

术前检查、化验、影像、会诊、签字、麻醉评估，看起来都在系统里，但实际是不是齐套，往往还是护士站或病区医生一项项去对。

2. 排班版本传播慢

手术室更新了台次，不等于病区、麻醉科和器械准备端都同步拿到了同一版信息。
有时候不是没人通知，而是通知散在不同渠道里。

3. 高风险患者没有被前置标红

像凝血指标异常、既往麻醉史复杂、术前会诊未完成这类情况，如果不能在排期阶段就亮出来，后面往往会临时改台。

4. 手术取消或顺延的原因沉淀不下来

一台手术顺延了，现场可能都知道“今天没上”，但到底是因为病人准备不全、资源冲突、医生变更，还是材料未回齐，往往很难留下统一口径。

旧流程的一天，通常会这样被打乱

下面这个图不是理想状态，而是很多医院在高峰日更接近真实的状态。

flowchart TB
    A[病区提交手术申请] --> B[护士站人工核对术前资料]
    B --> C[手术室先排一版台次]
    C --> D[麻醉科、病区、手术室分别再确认]
    D --> E{是否发现资料缺失或条件变化}
    E -->|否| F[按排班准备上台]
    E -->|是| G[电话、群消息、表格重新确认]
    G --> H[改台 / 顺延 / 取消]
    H --> I[病区与患者家属再次沟通]
    I --> J[现场继续追下一版安排]

这个旧流程最消耗人的，不是表本身，而是后面那一串重复动作：

反复打电话问现在到底按哪一版
反复确认材料是不是已经补齐
反复解释为什么明明“已经安排了”，最后又改
反复在多个系统和群里追溯变化来源

派宝没有替医院决定谁先做手术，而是先把“能不能做、什么时候更稳、谁该先知道变化”接起来

这个项目里，派宝没有把自己包装成一个“自动排台黑盒”，而是把原来分散在不同系统和不同岗位之间的判断，接成一条连续的协同链。

第一层：先把术前条件收成同一份状态面

通过 多系统数据同步 和 表单数据采集，先把排期真正依赖的关键状态拉齐：

手术申请状态
术前化验与影像完成情况
麻醉评估意见
知情同意和重点签字状态
病区床位与患者准备情况
手术室台次资源状态

这里最重要的不是把数据搬一遍，而是把它们转换成能直接判断的状态，比如：

可直接排期
资料待补齐
高风险需复核
资源冲突待调整

第二层：让系统先盯住“最容易引发返工的变化”

风险预警 和 流程自动触发 在这里承担的是持续盯变化，而不是事后统计。

系统会优先关注：

某项关键术前检查超过时限仍未完成
麻醉评估意见变成待补充
同一时段手术间或关键护士资源撞车
计划在 24 小时内上台的患者资料仍不齐
手术顺延次数异常增加

一旦命中规则，不再等病区自己“想起来再去追”，而是把对应动作直接拉起来。

第三层：把通知和任务分派到正确的人，而不是群里泛泛喊一声

这里用到的是 工单创建、工单分派 和 任务提醒。

举个特别真实的例子：

如果某位患者的麻醉前评估补充材料未回齐，系统不会只在大群里发一条提醒，而是会：

给病区护士生成待补资料任务
给病区医生标注当前手术申请处于风险状态
在手术室排班端提示该台次存在条件不稳定
在到达时限仍未补齐时触发升级提醒

这样变化不再只是“被人知道过”，而是变成“已经有人接住并在处理”。

第四层：对高峰日做前置缓冲，而不是当天临时救火

医院真正难的不是普通日，而是高峰日。
派宝在这类项目里通常会把 未来 24 小时到 48 小时内的重点台次 单独拉出来，形成一层术前准备看板。

看板上不只是显示名单，而是会标出：

哪些手术最可能因为资料问题返工
哪些台次在资源上存在冲突
哪些患者已经满足全部条件可以稳定推进
哪些环节连续两次以上因为同样原因顺延

管理层和手术室协调岗看到的，就不再是一张静态排班表，而是一份“谁最值得现在先处理”的优先级视图。

新流程不是更复杂，而是变化一来不需要重新组织一次人海战术

flowchart TB
    A[手术申请、检验、影像、麻醉、病区、手术室数据进入协同层] --> B[多系统数据同步能力]
    B --> C[形成患者术前准备状态面]
    C --> D[表单数据采集能力<br/>补齐人工录入和现场确认信息]
    D --> E[风险预警能力<br/>识别资料缺失、资源冲突和高风险患者]
    E --> F[流程自动触发能力<br/>自动拉起后续动作]
    F --> G[工单创建 / 工单分派 / 任务提醒]
    G --> H[病区、麻醉科、手术室看到同一版风险状态]
    H --> I[排期调整和患者沟通更早发生]
    I --> J[顺延原因与处理结果被持续留痕]

试运行 8 周以后，最明显的变化是什么

这家医院在项目试运行时，没有一开始就把所有专科全部纳进来，而是先选了 高频择期手术 + 资源容易撞车的专科组合 做观察。
连续跑了 8 周后，一线最明显的反馈不是“系统更聪明”，而是：

终于不用每天把同一件事情在三个群里反复确认。

现场变化可以落在这些指标上

对比项	改造前	改造后
手术前 24 小时内才暴露的资料缺失	较多	下降约 43%
因术前准备不齐导致的临时顺延	高频出现	下降约 36%
手术室与病区围绕排班版本的重复确认	很频繁	缩短约 52%
高峰日台次协调耗时	偏长	明显下降
顺延原因沉淀清晰度	偏弱	明显提升
患者/家属被临时通知改期的比例	偏高	明显下降

这些数字最能说明问题的一点在于：
它们不是“某个岗位更拼命”换来的，而是因为流程里原本最容易反复返工的节点，被提前看见并接住了。

这类项目为什么会让医院觉得值

不是替医生做决定，而是替团队减少无意义返工

医院不会把临床判断交给系统。
真正值得投入的，是让系统把那些重复确认、状态追踪、条件提醒、版本同步的活先接过去。

它对患者体验的帮助很直接

患者最不喜欢的，不是术前准备严格，而是明明已经准备了一轮，又在最后一刻被通知改期。
只要风险能前置，很多不必要的临时改动就能压下来。

它会反过来提升管理层对资源的判断力

以前看上去像“手术室总在临时改”，实际上很多问题起点并不在手术室。
当顺延原因被稳定沉淀下来，管理层就能看出到底是：

资料问题多
麻醉评估衔接慢
高峰时段资源安排过紧
还是病区准备动作不一致

这比单纯多做一张日报更有价值。

这篇案例特别适合哪些医院场景

择期手术量大，病区和手术室经常反复确认台次
多专科并行，排期一改就牵动麻醉、器械和护理资源
术前准备资料散在不同系统，靠护士站人工追
管理层已经知道顺延很多，但说不清最主要原因在哪里