---
doc_id: MTG-202606-001
feature_id: FEAT-202605-001-ai-future-hospital-platform
type: meeting
title: 空海医院会议对 AI 未来医院方案的影响说明
status: approved
owner: 医梦研发团队
created_at: 2026-06-03
updated_at: 2026-06-03
reviewers: []
related_docs:
  - PRD-202605-001
  - ODS-202606-001
  - DDS-202606-001
  - API-202606-001
related_modules:
  - emoon-openplatform
  - emoon-ai-device
  - emoon-ai-agent
tags:
  - 空海医院
  - 动线感知
  - 会议纪要
---

# 空海医院会议对 AI 未来医院方案的影响说明

| 项目 | 内容 |
| --- | --- |
| 文档定位 | 会议结论到需求、架构、接口设计的映射说明 |
| 会议资料 | `back-info/会议总结.md`、`back-info/空海医院信息科主任.md`、空海医院演示 PDF 与功能清单 |
| 适用文档 | `概要设计.md`、`详细设计.md`、`MVP接口契约.md`、OpenAPI v1.2 |
| 更新时间 | 2026-06-03 |

## 1. 核心结论

空海医院会议把方案重点从“AI 中台接多种设备”推进到“动线 + 感知”：

```text
感知：知道患者是谁、设备在哪、当前业务状态是什么、设备能做什么、哪些动作有风险
动线：判断患者处于就医流程哪个阶段，下一步该得到什么服务
AI 中台：把感知事实转化为可确认、可审计、可计量的智能体服务
统一入口客户端：在机器人、自助机、导诊屏、诊室屏等设备前把服务外显出来
```

对外表达应统一为：

> 医梦 AI 未来医院不是简单接入智能设备，而是通过统一入口客户端和 AI 中台，把患者身份、当前位置、业务状态和设备能力统一感知起来，再基于患者全流程动线主动推送下一步服务，实现“患者少找路、少找窗口、少找设备，医院服务主动找人”。

## 2. 甲方关注点

| 关注点 | 方案影响 |
| --- | --- |
| “服务找人要外显化” | 统一入口客户端必须有动线区和下一步服务卡片，不应只是聊天页 |
| “同一设备，不同用户能力不同” | `sceneProfile` 必须结合 `userContext/journeyState` 裁剪 `allowedAgents/allowedCards` |
| “门槛越低越好，不能假设每家医院有星闪、蓝牙信标” | 感知能力必须分级，P0 从扫码/NFC/刷卡/人工确认起步 |
| “只要能起步，先干一个场景，不要贪多” | 第一阶段只做诊区签到、缴费/检查提醒、路线导航等关键节点 |
| “智能化和信息化结合是空白点” | 价值不在位置技术本身，而在 HIS/叫号/卡片动作/设备事件合并判断下一步 |
| “物联网边界先确定” | 医梦不做全院物联平台，物联能力像 HIS 一样通过 MCP/Adapter 接入 |

## 3. MVP 设计取舍

| 能力 | P0 做法 | 暂不做 |
| --- | --- | --- |
| 身份感知 | 扫码、刷卡、NFC、患者确认绑定 `patientId/visitId/deviceId/sessionId` | 无授权人脸识别、长期腕带体系 |
| 空间感知 | 设备点位 + 诊区/诊室门口服务区域事件 | 全院连续轨迹、高精度室内定位 |
| 业务状态感知 | HIS/Mock、叫号、卡片动作、任务状态共同推导 | 跨系统大数据画像 |
| 动线阶段 | `VisitTimeline + TaskState + DeviceContext + DeviceEvent + CardAction` 推导 `journeyState` | 独立复杂流程引擎、全院路径优化 |
| 服务找人 | 主动签到、候诊提醒、缴费/检查/报告卡片 | 自动签到、自动缴费、自动诊断 |
| 设备能力差异 | 后端返回 `allowedAgents/allowedCards/perceptionCapabilities/journeyPolicy` | 前端自行放开能力 |

## 4. 文档修改映射

| 文档 | 变更章节 | 已更新内容 |
| --- | --- | --- |
| `概要设计.md` | §1.5、§1.5.1-§1.5.4、§4.1、§4.6、§5.10.3 | 新增“动线 + 感知”主轴、Scene/Router 边界、感知事件安全模型、运维配置闭环、服务找人触发表和 P0 验收标准 |
| `详细设计.md` | §0.1、§2.2、§3.1、§3.2、§7.1 | 将统一入口客户端定义为“患者动线承载端 + 多设备 AI 场景运行时”，补充动线区、感知状态、服务端 `journeyState` 和 Router 动线优先 |
| `MVP接口契约.md` | §3.3、§4.1-§4.3、§8 | 增加可选 `perceptionContext`；明确 `journeyState` 只由服务端返回；`journey_updated` 为 P0；补充事件 payload 约束 |
| `医梦AI中台开放平台接口-v1.2.openapi.yaml` | `PerceptionContext`、`JourneyState`、`AgentChatRequest`、`AgentChatData`、`DeviceSceneData`、`DeviceEventRequest` | 新增感知上下文、服务端只读动线状态、场景感知能力、动线策略和事件 payload 说明 |
| `前端工程启动指南.md` | §2、§3、§5、§7 | 明确前端布局、动线区、感知状态、P0 `journey_updated` 处理、禁止前端自行推断动线阶段 |

## 5. 执行原则

1. 先做节点感知，不做全院定位。
2. 先做服务卡片外显，不做无感自动业务动作。
3. 先做门诊关键动线，不扩展住院硬件责任。
4. 先复用 OpenPlatform、Device Registry、TaskState、Card Runtime，不新增独立微服务。
5. 先以患者确认和人工兜底保证安全，再逐步提升自动化体验。