3. 远程访视业务流程设计

远程访视不是“打开视频聊几句”这么简单。它是一条跨越患者端、平台服务端、医护工作台与外部系统（支付、药房、急救、可穿戴设备）的端到端业务链。如果只把视频通话当作核心，忽略预约、签到、候诊、医嘱、随访与转诊之间的状态衔接，就会出现“患者已进入候诊但医生看不到”“医嘱已下达但药房未收到”“紧急转诊时急救中心拿不到定位与生命体征”等断链问题。因此，本节的重点是把远程访视拆解为可编排、可观测、可回滚的状态机，并明确每个状态的进入条件、退出条件、超时策略与异常分支。

一、端到端流程的六个阶段与关键状态

一条完整的远程访视流程可归纳为六个阶段：预约、签到、候诊、视频问诊、医嘱与随访、紧急转诊。每个阶段内部又包含若干状态。以预约为例，状态可细分为“待确认—已确认—已改期—已取消—已爽约”。签到阶段则包含“未签到—已签到—身份核验中—核验通过—核验失败”。候诊阶段包含“排队中—即将叫号—已叫号—超时未响应”。视频问诊阶段包含“连接中—通话中—暂停—结束”。医嘱与随访阶段包含“草稿—已签署—已发送—药房已接收—随访计划已生成”。紧急转诊阶段包含“触发—评估—转诊中—已接收—已闭环”。

这些状态不是孤立标签，而是由事件驱动的迁移。例如，患者点击“签到”触发“未签到→已签到”；身份核验通过后触发“已签到→核验通过”；系统按预约时间与医生空闲度将患者放入队列，触发“核验通过→排队中”。医生点击“叫号”触发“排队中→已叫号”，患者端弹出视频邀请，触发“已叫号→连接中”。只有双方媒体流建立成功，才进入“通话中”。

二、状态机的设计要点：事件、守卫与超时

状态机落地时，不能只画状态框，必须为每条迁移定义三要素：触发事件、守卫条件、动作。以“排队中→已叫号”为例，触发事件是医生点击“叫号”，守卫条件是“患者在线且核验通过”，动作是“向患者端推送视频邀请并启动30秒倒计时”。如果30秒内患者未接听，则触发“已叫号→超时未响应”，系统自动将患者放回队列头部并记录一次未响应事件。若连续两次超时，则标记为“需人工介入”，由护士电话联系。

超时阈值需要按业务场景配置，而不是写死在代码里。例如，签到窗口通常设为预约时间前30分钟至后15分钟；候诊超时设为叫号后30秒；视频连接超时设为15秒；医嘱签署后药房接收超时设为5分钟。这些参数应放在配置中心，支持按科室、医生、患者类型覆盖。下面是一段状态迁移配置的示例，用JSON表达，便于平台动态加载：

{
  "state": "WAITING",
  "transitions": [
    {
      "event": "DOCTOR_CALL",
      "guard": "patient.online == true && patient.verified == true",
      "action": "pushVideoInvite(patientId, 30)",
      "next": "CALLED"
    },
    {
      "event": "TIMEOUT",
      "guard": "elapsed > 30",
      "action": "requeue(patientId, priority=high)",
      "next": "WAITING"
    }
  ]
}

守卫条件必须可测试、可审计。例如“患者在线”不能只依赖前端心跳，而应结合信令通道的WebSocket连接状态与最近一次媒体质量上报。否则会出现“显示在线但实际无法建立媒体”的假在线问题。

三、医嘱下达与随访计划的衔接

视频问诊结束后，医生在问诊界面直接开具医嘱。医嘱状态从“草稿”到“已签署”需要医生二次确认，防止误触。签署后，系统根据医嘱类型自动路由：药品类医嘱发送至药房系统，检查类医嘱发送至预约中心，康复类医嘱触发随访计划生成。随访计划不是简单的一条提醒，而应包含随访时间点、随访方式（视频/电话/量表）、随访内容模板与责任人。例如，高血压患者出院后随访计划可设为“第3天视频随访+血压上报、第7天电话随访、第30天视频随访+用药依从性量表”。

这里的关键是“医嘱—随访”的映射规则要可配置。平台应提供规则表，将医嘱编码、患者标签、随访模板关联起来。当医嘱签署事件发生时，规则引擎匹配并生成随访任务，写入任务队列。如果匹配失败，则进入“待人工配置”状态，由随访护士处理，而不是静默丢弃。

四、紧急转诊的触发与闭环

紧急转诊是远程访视中最不能出错的分支。触发条件通常包括：患者主诉胸痛/呼吸困难/意识改变、可穿戴设备上报危急值（如血氧低于90%、心率持续高于130）、医生在问诊中判断需要立即线下处置。触发后，系统应在一个动作内完成四件事：锁定当前问诊记录、抓取最近生命体征、获取患者定位、向急救中心发送转诊单。转诊单状态从“触发”到“已接收”再到“已闭环”，每一步都需要回执确认。如果急救中心在60秒内未确认接收，系统应自动升级通知，同时向患者发送“保持通话、不要移动”的指导语。

五、可观测性与状态一致性

状态机上线后，必须能回答三个问题：当前有多少患者在排队？平均候诊时长是多少？哪个状态的迁移失败率最高？因此，每个状态迁移都应产生结构化事件，写入事件流，并附带患者ID、医生ID、时间戳、耗时、结果码。基于这些事件，可以构建实时看板与告警规则。例如，“核验失败率超过5%”触发身份核验服务告警；“视频连接失败率超过3%”触发媒体服务告警；“紧急转诊未确认超过60秒”触发最高级别告警。

状态一致性方面，患者端、医生端与服务端可能因网络延迟出现短暂不一致。解决思路是服务端作为唯一事实源，客户端只做乐观展示，并以服务端推送的状态为准。每次状态变更都带版本号，客户端收到旧版本事件时丢弃，避免“已叫号”被“排队中”覆盖。对于关键操作如签到、签署医嘱、触发转诊，必须使用幂等键，防止重复提交产生重复状态。

最后，流程设计要留出人工兜底通道。无论状态机多完善，都可能出现患者设备故障、网络中断、身份核验异常等情况。平台应为护士工作台提供“强制签到”“手动排队”“代患者接听”“转诊补录”等操作，并记录操作人与原因。这些兜底操作同样进入事件流，保证事后可追溯、可复盘。远程访视的业务流程设计，本质上是在自动化效率与临床安全之间找到可配置、可观测、可回退的平衡点。