需求文档.md 51 KB
doc_id: PRD-202605-001 feature_id: FEAT-202605-001-ai-future-hospital-platform type: prd title: 医梦 AI 未来医院整体解决方案 status: approved owner: 医梦研发团队 created_at: 2026-05-29 updated_at: 2026-05-29 reviewers: [] related_docs: [] related_modules:
- emoon-openplatform
- emoon-ai-agent
- emoon-ai-card
- emoon-ai-mcp
- emoon-ai-device tags:
- AI未来医院
- 总体方案
- 门诊
- 住院 ---
医梦 AI 未来医院整体解决方案｜深度汇总分析版
版本：v2.0 深度汇总分析版
日期：2026-05-29
适用范围：内部战略统一、管理层汇报、医院甲方沟通、后续会议讲解、研发拆解、设备生态谈判、商务报价前置材料
基础资料：前序核心分析答案 + 5 份 Markdown 文档 + AI 门诊/AI 住院原方案 + 商业模式与能力值定价方案 + 最新会议纪要与录音逐字稿
核心定位：门诊整体总包 + 住院 AI 大脑层协同 + 统一入口控流量 + 设备适配平台 + 鸿蒙服务找人试点
0. 执行摘要
0.1 本轮方案变化的本质
本轮会议确认的变化不是“AI 门诊多加几个设备”，也不是“机器人方案扩大化”，而是医梦在医院项目中的控制位发生变化。
此前医梦的定位更接近：
AI 医院软件方案商 / AI 智能体能力提供商 / 部分机器人与设备接入方。
现在应升级为：
门诊软硬件整体入口总包方 + 住院 AI 大脑层协同方 + 医院多终端统一入口控制方 + 设备生态准入与适配方 + AI 场景持续运营方。
这意味着医梦不再只是把 AI 接进医院，而是要把医院门诊和部分住院场景中的“人机交互入口、AI 能力入口、设备入口、业务闭环入口、数据回流入口”统一收敛到自己的平台体系中。
0.2 最新总口径
建议后续所有方案、PPT、商务话术和技术说明统一使用以下总口径：
医梦 AI 未来医院方案由 场景层、AI 层、鸿蒙协同层 三层构成。
场景层 面向门诊与住院两大核心业务，其中门诊由医梦主导软硬件整体解决方案建设，住院侧与既有迪耐克/鸿蒙病房体系协同；
AI 层 由医梦 AI 中台、智能体中心、统一入口客户端、设备适配平台、MCP 工具网关、Card Runtime、知识库与规则引擎共同构成，负责把各类终端、设备、业务系统和 AI 能力统一调度；
鸿蒙协同层 以国产化设备生态、近场感知、设备互联和“服务找人”为亮点，打造可演示、可验收、可复制的智慧就医体验。
医梦的核心价值不是单点 AI 能力，而是 平台 + 专精模型 + 场景交付 + 设备入口 + 持续运营。
0.3 门诊和住院边界必须清晰
| 维度 | AI 门诊 | AI 住院 |
|---|---|---|
| 项目定位 | 医梦主导整体总包 | 医梦负责 AI 大脑层与互通层 |
| 硬件责任 | 医梦主导设备规划、准入、选型、统一入口适配、联调验收 | 住院硬件以迪耐克/鸿蒙病房既有体系为主，医梦不抢病房硬件总包 |
| AI 责任 | 导诊、预问诊、分诊、挂号、签到叫号、诊中辅助、诊后随访 | 预住院评估、智慧病历、CDSS、护理任务、IoMT 预警解释、出院小结、随访 |
| 设备入口 | 导诊屏、自助机、机器人、叫号屏、医生介绍屏、诊室屏、四诊仪等 | 护士 PDA、床头屏、护理白板、病区机器人、IoMT 设备等通过迪耐克体系互通 |
| 控制目标 | 控制门诊流量入口和终端入口 | 控制住院 AI 能力、智能体逻辑和数据闭环 |
| 优先级 | 最高优先级 | 同步推进，但避免硬件责任扩散 |
必须避免一个错误：把门诊和住院都做成“全硬件总包”。当前战略更合理的边界是：
- 门诊：攻入口，做总包，控制流量。
- 住院：控 AI，大脑协同，打通闭环。
0.4 三个最关键战略产品
| 战略产品 | 为什么重要 | 对应工作 |
|---|---|---|
| 统一入口客户端 | 所有屏幕、机器人、自助机、医生屏、护士屏都通过它加载医梦能力 | 多设备运行时、虚拟形象、语音交互、智能体绑定、UI 模板 |
| 设备适配平台 | 设备厂家会很多，没有适配平台会被硬件拖死 | Device Registry、Device Adapter、设备 SDK、远程配置、状态监控 |
| AI 中台 / Agent 中心 | 真正承载医梦医疗 AI 价值 | OpenPlatform、Dify Workflow、MCP、Card Runtime、知识库、计量、审计 |
0.5 后续会议讲解建议
后续会议不建议直接讲“AI 医院总体架构”，容易过大。建议按以下顺序讲：
- 为什么医梦定位变了：从 AI 软件商到门诊入口总包方。
- 门诊为什么优先：流量入口、设备入口、患者入口都在门诊。
- 统一入口客户端为什么是战略产品：不是 App，而是多终端运行时。
- 设备适配为什么必须独立成线：否则中台会被硬件联调拖死。
- 住院为什么不抢硬件总包：迪耐克已做鸿蒙病房，医梦要做 AI 大脑层。
- 鸿蒙服务找人怎么做成可落地 POC：主动签到、候诊提醒、检查导航。
- 商业上怎么收费：项目实施费 + 设备集成费 + 统一入口授权 + 能力值 + 综合运营服务费。
1. 第一主题：医梦 AI 未来医院最新总体方案 v2
1.1 总体定位
医梦 AI 未来医院方案的最新定位应统一为：
面向医院的 AI 未来医院软硬件一体化建设方案。门诊侧由医梦主导整体入口总包，住院侧与迪耐克/鸿蒙病房体系互通，医梦通过 AI 中台、智能体中心、统一入口客户端和设备适配平台控制医院 AI 服务入口、设备入口和持续运营入口。
这里需要注意三个关键词：
| 关键词 | 正确理解 | 错误理解 |
|---|---|---|
| 门诊总包 | 门诊软硬件入口统一规划、建设、接入、适配、运营 | 医梦生产所有硬件 |
| 住院 AI 大脑 | 医梦提供 AI 能力、智能体、闭环逻辑、数据互通 | 医梦接管迪耐克病房硬件 |
| 统一入口 | 所有终端加载医梦统一客户端和智能体能力 | 只做一个患者 App |
1.2 新旧方案对比
| 维度 | 原方案 | 最新方案 | 影响 |
|---|---|---|---|
| 公司定位 | AI 医院软件方案商 | 门诊总包 + 住院 AI 大脑 + 设备入口控制方 | 商业控制位显著提高 |
| 门诊范围 | 导诊、预问诊、机器人、医生站 | 所有门诊带屏设备、机器人、自助机、叫号、诊室终端、四诊仪 | 需要设备规划和供应商管理 |
| 住院范围 | AI 住院全流程 + 部分设备设想 | 与迪耐克/鸿蒙病房互通，主做 AI 层 | 边界收缩，风险降低 |
| 中台职责 | 调用智能体、连接 HIS | 控制多终端入口、智能体路由、设备事件、计量运营 | 中台需要增加设备维度 |
| 硬件职责 | 部分自研、部分接入 | 门诊设备准入、适配、联调、验收；住院协同互通 | 需要设备适配团队 |
| 鸿蒙价值 | 未单独成层 | 国产化 + 近场感知 + 服务找人 | 适合做标杆亮点 |
| 商业模式 | AI 能力 + 项目交付 | AI 能力 + 项目实施 + 设备集成 + 入口授权 + 运营服务 | 收费项需要扩展 |
1.3 三层对外架构
1.3.1 场景层
场景层面向医院业务人员和管理者，必须简单：
flowchart LR
A[AI 未来医院] --> B[AI 门诊\n医梦整体总包]
A --> C[AI 住院\n医梦 AI 大脑层协同]
B --> B1[导诊/预问诊]
B --> B2[分诊挂号]
B --> B3[签到叫号]
B --> B4[诊间辅助]
B --> B5[诊后随访]
C --> C1[预住院评估]
C --> C2[智慧病历]
C --> C3[护理任务]
C --> C4[IoMT 预警解释]
C --> C5[出院随访]
对外表达：
门诊由医梦作为整体方案主导方，从导诊大屏、自助机、机器人、叫号屏、诊室屏到 AI 中台统一建设；住院与既有鸿蒙病房体系互通，医梦提供住院 AI 大脑层能力。
1.3.2 AI 层
AI 层是医梦真正的控制层。
| 模块 | 核心职责 | 为什么必须做 |
|---|---|---|
| OpenPlatform 统一入口 | 统一认证、租户、会话、权限、日志、业务网关 | 多终端接入没有统一入口会失控 |
| Agent 智能体中心 | 管理导诊、病历、质控、护理、随访等智能体 | 让不同设备加载不同智能体 |
| Dify Workflow 编排 | 编排 AI 流程、工具调用、知识库问答、多步骤任务 | 快速配置业务流程 |
| MCP Tool Server | 封装 HIS、EMR、LIS、PACS、叫号、支付、床位等工具 | 防止 AI 直接操作业务系统 |
| Card Runtime | 承载挂号、签到、缴费、报告、任务等确定性动作 | 所有关键动作必须可控、可审计、可回滚 |
| 统一入口客户端 | 所有屏幕与机器人运行医梦客户端 | 控制流量入口 |
| Device Registry | 管理设备身份、位置、型号、能力、状态 | 支撑大规模设备治理 |
| Device Adapter | 适配不同厂家、系统、屏幕、SDK、驱动 | 避免项目被硬件联调拖死 |
| IoMT Event Hub | 接收设备事件、预警事件、护理事件 | 支撑住院 IoMT 闭环 |
| Metering / Billing | 能力值计量、设备维度计量、场景计量 | 支撑商业闭环 |
1.3.3 鸿蒙协同层
鸿蒙层不是 AI 本体，而是方案亮点和国产化抓手。
对外不建议说：
“我们基于星闪实现所有设备自动互联。”
更稳妥的说法是：
医梦优先适配鸿蒙生态设备，结合近场感知、设备发现、统一身份、业务状态判断和事件触发能力，打造“服务找人”的智慧就医体验。
鸿蒙层的核心落地不应是“大而全”，而应是 1-2 个可演示的 POC：
| POC | 场景 | 展示效果 | 技术关键 |
|---|---|---|---|
| 主动签到提醒 | 患者到诊室门口 | 手机主动弹出签到卡片，一键确认签到 | 近场感知 + 叫号系统 + HIS 签到 |
| 检查路线提醒 | 患者到检查区域 | 推送检查准备和路线 | 位置感知 + 检查预约 + 室内地图 |
| 候诊状态同步 | 患者在候诊区 | 手机、叫号屏、机器人同步显示状态 | 叫号系统 + 设备事件总线 |
| 医生上下文准备 | 患者进入诊室 | 医生屏自动准备预问诊、报告摘要、病历草稿 | 患者身份 + 就诊状态 + EMR/LIS/PACS |
1.4 对外建设原则
| 原则 | 解释 | 工程约束 |
|---|---|---|
| 医生主导 | AI 只做助手，临床决策权在医生 | 诊断、处方、医嘱、出院小结必须人工确认 |
| 统一入口 | 所有设备入口都应接入医梦客户端或协议 | 避免各设备各自为政 |
| 场景驱动 | 不按技术模块卖，而按门诊/住院闭环落地 | 每个场景必须有业务指标 |
| 设备可治理 | 不只是接入，还要可监控、可升级、可验收 | Device Registry 必须先建 |
| 业务可审计 | AI 输出、工具调用、人工修改都要留痕 | 日志审计必须进入第一期 |
| 商业可计量 | 能力值、设备、场景、科室维度可统计 | Metering 必须与中台绑定 |
| 分阶段实施 | 医疗场景不能大爆炸上线 | P0 闭环先打穿 |
2. 第二主题：门诊软硬件统一建设清单与职责边界
2.1 门诊为什么是优先级最高的战场
门诊是医院最典型的高频入口场景：
- 患者流量最大；
- 入口设备最多；
- 问答、导诊、挂号、缴费、签到、叫号、报告、导航等需求高频；
- 甲方可见度最高；
- AI 效果最容易被院领导、患者、科室感知；
- 一旦统一入口形成，后续新增门诊业务都可能通过医梦平台扩展。
所以门诊不是单个 AI 导诊项目，而是入口控制项目。
2.2 门诊整体建设对象
2.2.1 门诊大厅
| 设备/入口 | 核心职责 | AI 能力 | 医梦责任 | 优先级 |
|---|---|---|---|---|
| 导诊大屏 | 院内信息查询、导诊问答、路径引导 | FAQ、导诊、导航、分诊入口 | 统一客户端、知识库、UI、语音 | P0 |
| 自助机 | 挂号、缴费、签到、报告查询 | 挂号 Agent、缴费 Agent、报告解读入口 | 对接 HIS/支付/LIS/PACS | P0 |
| 门诊机器人 | 问答、导诊、带路、挂号引导 | 语音问答、导航、带路 Agent | 机器人应用、语音、导航、联调 | P0 |
| 桌面服务屏 | 快速查询、人工导诊辅助 | FAQ、叫号、科室查询 | 可作为轻入口 | P2 |
| 综合服务屏 | 展示医院服务、AI 宣教 | 宣教、活动、服务引导 | 内容管理与展示 | P2 |
2.2.2 门诊分区 / 候诊区
| 设备/入口 | 核心职责 | AI 能力 | 医梦责任 | 优先级 |
|---|---|---|---|---|
| 叫号大屏 | 排队状态、过号提醒、候诊展示 | 叫号智能体、候诊提醒 | 对接叫号系统，展示状态 | P0 |
| 候诊屏 | 科室信息、候诊说明、宣教 | 科室宣教、预计等待时间 | 内容编排、叫号状态联动 | P0 |
| 诊区自助机 | 签到、改签、缴费、报告查询 | 签到 Agent、缴费 Agent | 自助机客户端适配 | P1 |
| 诊区机器人 | 局部导诊、带路、候诊提醒 | 科室 FAQ、带路、叫号提醒 | 机器人场景配置 | P1 |
2.2.3 诊室门口
| 设备/入口 | 核心职责 | AI 能力 | 医梦责任 | 优先级 |
|---|---|---|---|---|
| 医生介绍屏 | 医生简介、专长、当前叫号 | 医生画像、患者教育 | 对接排班/叫号 | P1 |
| 诊室门口小屏 | 签到、叫号、候诊提醒 | 服务找人、主动签到 | 与鸿蒙 POC 绑定 | P0/P1 |
| 候诊提醒屏 | 当前患者、过号提醒 | 状态同步 | 对接叫号系统 | P1 |
2.2.4 诊室内
| 设备/入口 | 核心职责 | AI 能力 | 医梦责任 | 优先级 |
|---|---|---|---|---|
| 诊室桌面屏 | 诊中 AI 辅助主屏 | 语音病历、CDSS、质控 | 诊间客户端、EMR 对接 | P0 |
| 诊室副屏 | 展示患者摘要、检查结果、患教 | 预问诊摘要、报告摘要 | 多屏联动 | P1 |
| 医生站插件 | 嵌入医生工作流 | CDSS、病历生成、质控 | EMR/HIS 插件或侧边栏 | P0 |
| 麦克风阵列 | 采集问诊语音 | ASR、医患分离、结构化 | 语音服务与转写 | P0 |
| 四诊仪 | 中医特色采集 | 舌诊、面诊、脉诊、问诊 | 专精模型与设备接入 | P1/P0（中医科） |
2.3 门诊 P0 试点闭环
第一期不应把所有设备一次性铺开。建议 P0 闭环固定为：
患者触达 → 导诊问答 → 预问诊 → 分诊推荐 → 挂号预约 → 到院签到 → 叫号候诊 → 诊间语音病历/质控 → 诊后小结/随访
2.3.1 P0 硬件清单
| 类别 | 设备 | 目的 |
|---|---|---|
| 入口 | 导诊大屏 | 控制到院入口 |
| 入口 | 自助机 | 挂号/缴费/签到闭环 |
| 展示 | 叫号屏/候诊屏 | 候诊状态可视化 |
| 交互 | 门诊机器人 | 展示性强，医院明确要求 |
| 诊中 | 诊室桌面屏/医生站插件 | 体现临床价值 |
| 采集 | 诊室麦克风 | 语音病历基础 |
| 特色 | 四诊仪 | 中医专精模型抓手 |
| 鸿蒙 | 诊室门口近场设备/小屏 | 服务找人 POC |
2.4 设备-场景-智能体绑定模型
门诊总包最关键的不是买设备，而是让设备加载正确的智能体和 UI。
| 设备 | 场景 | 默认智能体 | 可调用工具 | 输出结果 |
|---|---|---|---|---|
| 导诊大屏 | 门诊大厅 | 导诊问答 Agent、院内知识库 Agent | 科室查询、地图查询、排班查询 | 科室建议、路线、FAQ 答案 |
| 自助机 | 门诊大厅/诊区 | 挂号 Agent、缴费 Agent、报告查询 Agent | HIS、支付、LIS/PACS | 挂号单、缴费结果、报告解释 |
| 机器人 | 大厅/诊区 | 语音导诊 Agent、带路 Agent | 地图、叫号、科室 FAQ | 语音回复、带路、导航 |
| 叫号屏 | 候诊区 | 叫号状态 Agent、候诊提醒 Agent | 叫号系统、排队系统 | 当前叫号、预计等待 |
| 医生介绍屏 | 诊室门口 | 医生画像 Agent、患者提醒 Agent | 排班、叫号、医生档案 | 医生介绍、候诊提醒 |
| 诊室桌面屏 | 诊室内 | 语音病历 Agent、CDSS Agent、质控 Agent | EMR、LIS、PACS、药典 | SOAP 草案、诊疗建议、质控问题 |
| 四诊仪 | 诊室内 | 舌诊 Agent、面诊 Agent、脉诊 Agent、问诊 Agent | 四诊设备 SDK、专精模型 | 四诊分析、辅助辨证 |
| 患者端小程序 | 全流程 | 随访 Agent、报告解读 Agent、用药提醒 Agent | LIS/PACS、处方、随访系统 | 诊后小结、报告解释、随访问卷 |
2.5 设备准入标准
未来医院会有大量设备厂家想进入项目。如果没有准入标准，医梦会承担不可控责任。
建议建立 A/B/C/D 四级准入：
| 等级 | 标准 | 能否进入核心闭环 | 医梦责任 |
|---|---|---|---|
| A 级 | 支持医梦统一客户端，开放 API/SDK，支持远程运维和日志 | 可以进入核心闭环 | 医梦深度适配与验收 |
| B 级 | 支持 Web/H5 嵌入或标准接口，能完成基础业务 | 可进入部分闭环 | 医梦轻量适配 |
| C 级 | 只能播放内容或展示页面，不开放接口 | 不进入核心闭环 | 仅展示，不承诺业务闭环 |
| D 级 | 无接口、无系统、无法远程管理、稳定性差 | 不建议采购 | 建议替换或排除 |
2.6 门诊验收标准
不能以“设备通电、系统能打开”为验收标准。门诊总包应按照业务闭环验收。
| 验收项 | 验收标准 |
|---|---|
| 统一入口 | 所有 P0 设备能加载医梦统一客户端或标准接入协议 |
| 导诊问答 | 常见问题命中率、错误率、人工转接机制符合要求 |
| 预问诊 | 能生成结构化病史、主诉、过敏史、用药史 |
| 分诊推荐 | 能给出科室推荐、紧急度判断、可解释依据 |
| 挂号签到 | 能完成号源查询、挂号、签到、叫号状态同步 |
| 机器人 | 能完成语音问答、导诊、带路或至少局部导航 |
| 诊中病历 | 能生成 SOAP 草案，医生可修改确认 |
| 病历质控 | 能提示完整性、逻辑性、时限性问题 |
| 诊后服务 | 能生成患者版小结、用药提醒、随访任务 |
| 审计 | AI 输出、工具调用、人工修改全链路可追溯 |
3. 第三主题：AI 中台补充建设方案
3.1 为什么原 AI 中台不够
原来的 AI 中台如果只解决“智能体调用、知识库、MCP 工具、计量”，在新方案下是不够的。原因是：
- 设备数量大量增加；
- 不同设备有不同系统、分辨率、输入方式、接口能力；
- 每个设备需要加载不同智能体；
- 机器人、自助机、屏幕、医生站、护理白板等都需要统一入口；
- 设备状态、版本、日志、异常告警需要统一管理；
- 商业计量需要按设备、科室、场景、智能体统计。
因此 AI 中台必须升级为：
AI 中台 + 统一入口客户端 + 设备注册中心 + 设备适配平台 + 场景编排器 + 设备事件总线 + 计量运营系统。
3.2 新版中台能力地图
flowchart TB
A[统一入口客户端 Terminal Runtime] --> B[OpenPlatform 统一入口]
C[设备注册中心 Device Registry] --> B
D[设备适配层 Device Adapter] --> B
E[虚拟形象/语音交互引擎] --> A
F[Scene Orchestrator 场景编排器] --> A
B --> G[Agent 智能体中心]
B --> H[Dify Workflow 编排]
B --> I[Card Runtime 卡片运行时]
B --> J[MCP Tool Server 工具网关]
B --> K[Knowledge / Rules 知识库与规则]
B --> L[IoMT Event Hub 设备事件中心]
B --> M[Metering / Billing 计量结算]
J --> N[HIS/EMR/LIS/PACS/支付/叫号/床位/护理]
3.3 统一入口客户端设计
3.3.1 产品定位
统一入口客户端不是普通 App，而是：
医梦部署在所有终端设备上的多设备 AI 场景运行时。
它要解决的问题不是“展示一个网页”，而是：
- 在不同设备上加载不同 UI 模板；
- 根据设备位置和角色绑定不同智能体；
- 支持语音、触控、扫码、摄像头、打印等设备能力；
- 支持虚拟形象和统一 AI 人设；
- 支持与中台统一会话、统一身份、统一权限；
- 支持远程升级、远程配置、异常上报。
3.3.2 统一入口客户端配置模型
DeviceProfile:
deviceId: EMOON-OPD-KIOSK-001
deviceType: self_service_kiosk
vendor: xxx
os: android/harmony/windows/web
screen: 27inch_touch
input:
- touch
- scan_code
- id_card
- voice
output:
- screen
- speaker
- printer
location:
building: 门诊楼
floor: 1F
area: 门诊大厅
sceneProfile: outpatient_registration
agentBindings:
- registration_agent
- payment_agent
- report_query_agent
permissions:
- query_schedule
- lock_number
- create_payment_order
- query_report
这个模型对研发非常关键。没有这个抽象，后续每台设备都会变成定制开发。
3.3.3 多设备技术形态
| 设备类型 | 推荐技术形态 | 原因 |
|---|---|---|
| 大屏/叫号屏 | Web 全屏 / Chromium kiosk | 部署简单，统一更新 |
| 自助机 | Android 壳 + WebView / 原生 Bridge | 需要扫码、打印、读卡能力 |
| 机器人 | 原生机器人 SDK + 医梦场景客户端 | 需要底盘、导航、语音、传感器能力 |
| 诊室桌面屏 | Web / Electron / 医生站插件 | 便于与 EMR 联动 |
| 医生站插件 | iframe/侧边栏/桌面插件 | 贴近医生工作流 |
| 护理白板 | Web 大屏客户端 | 任务看板适合 Web 化 |
| 床头屏 | 由迪耐克能力决定，优先 Web/H5 嵌入 | 不抢硬件主责 |
| PDA | Android/Harmony App 或 H5 | 需要扫码、任务确认 |
3.4 Device Registry 设备注册中心
3.4.1 为什么必须先做
设备注册中心是设备治理的基础。如果没有它，项目会出现：
- 不知道哪些设备在线；
- 不知道设备在哪个科室；
- 不知道设备加载了哪个智能体；
- 无法远程配置；
- 无法统计设备使用量；
- 出问题时无法定位责任。
3.4.2 设备注册中心字段
| 字段 | 说明 |
|---|---|
| deviceId | 医梦全局唯一设备 ID |
| hospitalId | 医院 ID |
| departmentId | 科室 ID |
| location | 楼栋、楼层、区域、诊室、床位 |
| deviceType | 导诊屏、自助机、机器人、叫号屏等 |
| vendor | 厂商 |
| model | 设备型号 |
| os | 系统类型 |
| capabilities | 支持的能力：屏幕、语音、打印、扫码、摄像头等 |
| agentBindings | 绑定的智能体 |
| uiTemplate | 加载的 UI 模板 |
| status | 在线、离线、异常、维护中 |
| version | 客户端版本 |
| lastHeartbeat | 最后心跳时间 |
| slaLevel | SLA 等级 |
3.5 Device Adapter 设备适配层
设备适配层要把不同厂家的差异收敛成医梦标准能力。
flowchart LR
A[第三方设备 SDK/API] --> B[Device Adapter]
C[自研机器人驱动] --> B
D[自助机读卡/打印/扫码] --> B
E[四诊仪采集接口] --> B
F[迪耐克病房接口] --> B
B --> G[医梦标准设备能力协议]
G --> H[统一入口客户端]
G --> I[AI 中台]
3.5.1 标准设备能力协议
| 能力 | 标准动作 |
|---|---|
| 屏幕显示 | renderCard、showPage、showAlert |
| 语音采集 | startRecord、stopRecord、sendAudio |
| 语音播放 | playTTS、stopTTS |
| 摄像头 | captureImage、scanFace、scanQRCode |
| 打印 | printReceipt、printWristband、printReport |
| 读卡 | readIdCard、readMedicalCard |
| 导航 | startNavigation、stopNavigation、getLocation |
| 机器人 | moveTo、followPatient、speak、returnDock |
| IoMT | subscribeEvent、ackEvent、closeEvent |
3.6 Scene Orchestrator 场景编排器
场景编排器解决一个核心问题：
同一个设备，在不同位置、时间、用户、业务状态下，应该加载哪个智能体、展示哪个界面、调用哪些工具。
示例：诊室门口小屏
| 条件 | 加载内容 |
|---|---|
| 开诊前 | 医生介绍、科室介绍、当日排班 |
| 候诊中 | 当前叫号、候诊队列、预计等待 |
| 患者靠近 | 主动签到提醒、就诊准备提醒 |
| 医生暂停 | 停诊/延迟说明、改签引导 |
| 异常情况 | 人工导诊入口、服务台电话 |
示例：机器人
| 场景 | 智能体 | 能力 |
|---|---|---|
| 大厅咨询 | FAQ Agent | 院内常见问题 |
| 症状咨询 | 分诊 Agent | 症状采集、科室推荐 |
| 患者迷路 | 导航 Agent | 路线规划、带路 |
| 挂号引导 | 挂号 Agent | 号源查询、自助机引导 |
| 老年患者 | 人工转接 Agent | 转人工导诊 |
3.7 Card Runtime 设计
AI 不能直接改业务系统，必须通过确定性卡片动作。
| 卡片 | 场景 | 动作 | 审计要求 |
|---|---|---|---|
| 科室推荐卡 | 分诊后 | 展示推荐科室、理由、备选科室 | 记录推荐依据 |
| 号源卡 | 挂号 | 选择医生/时间/号源 | 记录查询与选择 |
| 锁号卡 | 挂号 | 锁定号源 | 幂等、防重复 |
| 支付卡 | 缴费 | 创建支付订单 | 防重复扣款 |
| 签到卡 | 到院 | 确认签到 | 记录位置与确认人 |
| 报告解读卡 | 诊后/检查后 | 展示报告解释 | 标注 AI 仅供参考 |
| 病历草案卡 | 诊中 | 生成 SOAP 草案 | 医生确认后写回 |
| 质控问题卡 | 病历提交前 | 展示问题、修改建议 | 记录医生处理结果 |
| 护理任务卡 | 住院 | 生成护理任务 | 护士确认执行 |
| 预警工单卡 | IoMT | 展示预警、建议处理 | 闭环关闭 |
4. 第四主题：AI 医院整体解决方案技术规划会议纪要深度解读
4.1 会议核心共识拆解
共识 1：门诊由医梦整体包掉
会议中的真实含义是：
- 门诊设备谁能进，医梦应有技术建议权和准入权；
- 门诊所有带屏设备应接入医梦统一入口客户端；
- 门诊机器人、自助机、导诊屏、叫号屏、诊室屏、四诊仪都应成为医梦中台的终端节点；
- 医院未来门诊新增 AI 服务、新增终端、新增场景，应优先通过医梦平台扩展。
这不是“我们生产所有设备”，而是“我们控制设备入口标准”。
共识 2：住院不做硬件总包，做 AI 大脑层
住院侧已经有迪耐克/鸿蒙病房体系，医梦如果强行做住院硬件总包，会带来三个问题：
- 与既有厂商冲突；
- 承担过多硬件运维责任；
- 项目范围爆炸。
正确策略是：
医梦提供住院智能体、AI 大脑层、IoMT 预警解释、护理任务生成、病历质控、出院随访，与迪耐克的床头屏、护理白板、护士站、病房设备互通。
共识 3：“机器人无处不在”不是到处放机器人
会议中提到“机器人无处不在”，真正应解释为：
AI 机器人能力无处不在。
也就是说：
- 在门诊大厅，它表现为实体机器人；
- 在导诊屏上，它表现为虚拟形象；
- 在自助机上，它表现为挂号/缴费助手；
- 在叫号屏上，它表现为候诊提醒智能体；
- 在诊室屏上，它表现为病历/质控助手；
- 在床头屏上，它表现为虚拟护士；
- 在护理白板上，它表现为护理任务和预警助手。
这是一套 AI 能力的多终端分身，而不是物理机器人 everywhere。
共识 4：统一入口客户端是战略控制点
会议中“把所有流量入口做到我们手上”这句话非常关键。它意味着：
- 医梦未来不是只卖 Agent；
- 医梦要控制患者与 AI 的第一触点；
- 医梦要控制设备上显示什么服务；
- 医梦要控制设备与中台之间的协议；
- 医梦要控制用量、日志、运营、持续服务。
这会带来长期商业价值，但也带来研发压力：统一入口客户端必须产品化，而不是项目临时页面。
共识 5：鸿蒙层的价值是“服务找人”
鸿蒙层在方案中不能只写“国产化适配”，否则价值弱。它必须转化为业务体验：
患者不是去找机器、找窗口、找二维码，而是医院服务主动找到患者。
最适合讲给甲方的故事是：
- 患者到诊室附近；
- 手机收到“是否签到”提醒；
- 患者一键确认；
- 叫号屏、诊室屏、医生站、手机状态同步；
- AI 推送候诊提醒、医生介绍、就诊准备。
4.2 会议场景逐项拆解
4.2.1 门诊大屏场景
| 项 | 内容 |
|---|---|
| 用户 | 初次到院患者、家属、老年患者 |
| 痛点 | 不知道挂哪个科、不知道去哪、不知道流程 |
| AI 能力 | 导诊问答、科室推荐、院内导航、FAQ |
| 设备能力 | 大屏触控、语音输入、二维码展示 |
| 关键系统 | 科室知识库、室内地图、排班系统 |
| 输出 | 科室建议、路线、挂号入口、二维码转手机 |
| 风险 | 大屏输入隐私问题；复杂症状不能强行给诊断 |
| MVP | FAQ + 科室推荐 + 路线展示 + 扫码到手机 |
4.2.2 自助机场景
| 项 | 内容 |
|---|---|
| 用户 | 到院办理挂号、缴费、签到、报告查询的患者 |
| 痛点 | 自助机菜单复杂、不会操作、排队长 |
| AI 能力 | 意图识别、挂号辅助、缴费解释、报告解读入口 |
| 设备能力 | 读卡、扫码、打印、支付、触摸屏 |
| 关键系统 | HIS、支付、LIS/PACS、叫号系统 |
| 输出 | 挂号单、缴费凭证、签到结果、报告查询 |
| 风险 | 支付和挂号必须幂等；不能重复扣款/重复挂号 |
| MVP | AI 引导挂号 + 缴费 + 签到 + 报告查询入口 |
4.2.3 门诊机器人成景
| 项 | 内容 |
|---|---|
| 用户 | 患者、家属、老年患者、外地患者 |
| 痛点 | 找不到科室、不会操作自助机、需要人工导诊 |
| AI 能力 | 语音问答、导诊分诊、FAQ、导航、带路 |
| 设备能力 | 底盘、避障、定位、语音、屏幕、表情 |
| 关键系统 | 室内地图、科室知识库、叫号/挂号系统 |
| 输出 | 语音回答、路线、带路、挂号引导 |
| 风险 | 导航稳定性、噪声环境、老人识别、跌倒碰撞安全 |
| MVP | 门诊大厅 FAQ + 局部带路 + 挂号引导 |
机器人必须保留，但定位要清楚：
它是门诊入口的强展示终端之一，不是全部方案本身。
4.2.4 叫号屏 / 候诊屏场景
| 项 | 内容 |
|---|---|
| 用户 | 候诊患者、护士、分诊台 |
| 痛点 | 不知道还要等多久、过号后不知道怎么办 |
| AI 能力 | 候诊解释、预计等待、过号引导、宣教推荐 |
| 设备能力 | 大屏展示、状态刷新、语音播报 |
| 关键系统 | 叫号系统、排队系统、HIS |
| 输出 | 当前叫号、候诊列表、预计等待、过号处理 |
| 风险 | 显示隐私；不能泄露诊断信息 |
| MVP | 叫号状态 + 预计等待 + 过号处理说明 |
4.2.5 诊室门口屏 / 医生介绍屏场景
| 项 | 内容 |
|---|---|
| 用户 | 候诊患者、医生、护士 |
| 痛点 | 患者不了解医生、找不到是否到号、签到麻烦 |
| AI 能力 | 医生介绍、主动签到提醒、候诊提醒 |
| 设备能力 | 小屏展示、二维码、近场感知 |
| 关键系统 | 排班、叫号、HIS、鸿蒙/近场能力 |
| 输出 | 医生介绍、当前叫号、签到卡片 |
| 风险 | 自动签到误触发；必须患者确认 |
| MVP | 医生介绍 + 当前叫号 + 手机主动签到提醒 |
4.2.6 诊室桌面屏 / 医生站场景
| 项 | 内容 |
|---|---|
| 用户 | 门诊医生 |
| 痛点 | 病历书写耗时、检查结果分散、质控滞后 |
| AI 能力 | 语音转写、SOAP 草案、CDSS、病历质控、报告摘要 |
| 设备能力 | 桌面屏、麦克风、EMR 插件 |
| 关键系统 | EMR、HIS、LIS、PACS、药典、质控规则 |
| 输出 | 病历草案、诊疗建议、质控问题、患教材料 |
| 风险 | 医生必须确认；AI 建议不能直接成为诊断/处方 |
| MVP | 语音病历 + 病历质控 + 检查报告摘要 |
4.2.7 四诊仪场景
| 项 | 内容 |
|---|---|
| 用户 | 中医科医生、患者 |
| 痛点 | 中医望闻问切主观性强，数据难沉淀 |
| AI 能力 | 舌诊、面诊、脉诊、问诊综合分析 |
| 设备能力 | 图像采集、脉象采集、音频采集、结构化问诊 |
| 关键系统 | 四诊仪 SDK、专精模型、EMR |
| 输出 | 舌象分析、面象分析、脉象特征、辅助辨证 |
| 风险 | 中医结论必须是辅助；模型需要持续校准 |
| MVP | 舌诊 + 问诊 + 医生确认报告 |
4.2.8 护理白板场景
| 项 | 内容 |
|---|---|
| 用户 | 护士长、责任护士、病区医生 |
| 痛点 | 任务多、风险患者难追踪、交班信息分散 |
| AI 能力 | 护理任务生成、风险分级、交班摘要、重点患者看板 |
| 设备能力 | 大屏展示、触控、任务状态更新 |
| 关键系统 | 护理系统、EMR、IoMT、迪耐克病房系统 |
| 输出 | 护理任务、风险患者、未完成事项、交班摘要 |
| 风险 | 医梦不能对迪耐克屏幕硬件故障承担主责 |
| MVP | 护理任务 + IoMT 预警 + 交班摘要嵌入 |
4.2.9 床头屏场景
| 项 | 内容 |
|---|---|
| 用户 | 住院患者、家属、护士 |
| 痛点 | 患者频繁询问费用、检查、报告、医生、注意事项 |
| AI 能力 | 床旁问答、报告解读、宣教、检查提醒、满意度调查 |
| 设备能力 | 触屏、语音、呼叫、视频播放 |
| 关键系统 | 迪耐克床头屏、HIS、LIS/PACS、护理系统 |
| 输出 | 费用查询、检查提醒、报告解释、宣教内容 |
| 风险 | 屏幕硬件和基础呼叫功能不归医梦主责 |
| MVP | AI 服务嵌入床头屏：FAQ + 报告解读 + 宣教 |
4.2.10 病区机器人场景
| 项 | 内容 |
|---|---|
| 用户 | 住院患者、护士 |
| 痛点 | 病区问答、物品配送、巡视提醒、人手不足 |
| AI 能力 | 病区 FAQ、虚拟护士、巡房提醒、风险提示 |
| 设备能力 | 移动底盘、语音、屏幕、导航、载物 |
| 关键系统 | 护理系统、床位系统、IoMT、迪耐克系统 |
| 输出 | 问答、提醒、巡查记录、任务反馈 |
| 风险 | 送餐/购物等场景容易超出医疗主线，第一期不宜扩大 |
| MVP | 病区问答 + 呼叫响应 + 简单巡视提醒 |
5. 第五主题：医梦新增职责与实施路线
5.1 医梦新增职责总表
| 新职责 | 具体内容 | 必要性 | 风险 |
|---|---|---|---|
| 门诊总体方案主责 | 方案、设备、系统、AI、验收 | 控制门诊入口 | 范围过大 |
| 设备选型与准入 | 制定准入标准、推荐厂商、验收设备 | 控制硬件质量 | 合规风险 |
| 统一入口客户端 | 多设备运行时、虚拟形象、语音、UI 模板 | 控制流量入口 | 研发复杂 |
| 设备适配平台 | 设备注册、SDK、远程配置、状态监控 | 防止联调失控 | 需要专门团队 |
| 第三方设备生态 | 供应商规范、接入测试、联合验收 | 门诊总包必须做 | 商务边界复杂 |
| 住院 AI 互通 | 对接迪耐克、护理系统、IoMT、床头屏 | 保持住院控制力 | 边界不清会背锅 |
| 鸿蒙服务找人 POC | 主动签到、检查提醒、候诊状态同步 | 标杆亮点 | 技术实现不确定 |
| 商业计量运营 | 能力值、设备授权、运营服务 | 支撑长期收入 | 计量体系复杂 |
5.2 团队拆分建议
不能让一个研发组同时做中台、机器人、设备、医生站、鸿蒙、住院互通。建议拆成以下小组：
| 团队 | 阶段人数 | 核心职责 |
|---|---|---|
| AI 中台组 | 3-5 | OpenPlatform、MCP、Card、计量、权限、审计 |
| 智能体/医疗场景组 | 2-4 | 门诊/住院 Agent、知识库、Dify 流程、医学规则 |
| 统一入口客户端组 | 3-5 | 多终端 UI、虚拟形象、语音交互、设备模板 |
| 设备适配组 | 2-4 | Device Registry、Adapter、SDK、驱动桥接、远程运维 |
| 机器人组 | 2-3 | 机器人导诊、导航、语音、硬件驱动 |
| 项目集成/PMO | 2-3 | 医院接口、供应商联调、验收、排期管理 |
| 供应链/生态合作 | 1-2 | 设备准入、厂商谈判、合同边界 |
| 测试与运维 | 1-2 | 设备测试、场景测试、压力测试、上线保障 |
5.3 三阶段实施路线
阶段 0：两周边界锁定
| 任务 | 输出 |
|---|---|
| 门诊存量设备盘点 | 存量设备清单、系统能力、接口情况 |
| 门诊新增设备规划 | P0/P1/P2 设备清单 |
| 迪耐克接口摸底 | 住院互通接口清单、责任边界 |
| 鸿蒙 POC 可行性确认 | 主动签到场景技术方案 |
| 统一入口客户端 PRD | 多设备运行时需求 v1 |
| 设备准入标准 | A/B/C/D 分级与验收标准 |
阶段 1：1-2 个月，门诊 MVP
| 任务 | 输出 |
|---|---|
| AI 中台补设备维度 | 设备注册、场景绑定、智能体绑定 |
| 统一入口客户端 MVP | 导诊屏/自助机/机器人/诊室屏可运行 |
| 门诊导诊 Agent | FAQ、分诊、挂号引导 |
| 机器人导诊 | 语音问答、局部导航、带路 |
| 叫号/签到对接 | 签到候诊状态同步 |
| 诊室屏 | 语音病历、病历质控基础版 |
| 鸿蒙服务找人设计 | 进入开发准备 |
阶段 2：2-4 个月，打穿闭环
| 任务 | 输出 |
|---|---|
| 门诊分诊挂号闭环 | 预问诊、科室推荐、号源推荐、签到 |
| 诊中语音病历 | 医生站/诊室屏联动 |
| 四诊仪接入 | 舌诊/问诊/脉诊进入诊间 |
| 诊后小结/随访 | 患者端闭环 |
| 迪耐克住院互通 | 护理白板/床头屏/IoMT 事件接入 |
| 护理任务闭环 | AI 生成任务，护士确认执行 |
| IoMT 预警解释 | 风险分级、处置建议、闭环记录 |
阶段 3：4-6 个月，标杆方案
| 任务 | 输出 |
|---|---|
| 门诊多设备统一运营 | P0/P1 设备纳入管理后台 |
| 鸿蒙服务找人上线 | 主动签到/候诊提醒示范 |
| 运营看板 | 设备、流量、智能体、业务效果统计 |
| 能力值计量 | 按智能体、设备、科室、场景统计 |
| 供应商生态 | 设备准入、第三方适配、联合验收 |
| 标杆汇报材料 | 甲方快乐图、演示视频、验收报告 |
6. 门诊全流程深度方案
6.1 门诊主线
患者到院/线上触达
→ AI 导诊问答
→ 多模态预问诊
→ 风险分级与科室推荐
→ 医生/号源推荐
→ 挂号缴费
→ 到院签到
→ 叫号候诊
→ 诊中语音病历 + CDSS + 质控
→ 检查检验/缴费/报告解读
→ 诊后小结
→ 用药提醒
→ AI 随访
→ 复诊推荐
6.2 门诊导诊意图分流设计
| 意图类型 | 判断依据 | 后续动作 | 风险控制 |
|---|---|---|---|
| 症状咨询 | 患者描述身体不适 | 多轮症状采集、风险分级、科室推荐 | 红旗症状转急诊/人工 |
| 院内 FAQ | 问科室位置、费用、流程 | 院内知识库回答 | 不涉及诊疗建议 |
| 挂号预约 | 明确想挂号/找医生 | 号源推荐、锁号、支付 | 幂等、防重复 |
| 报告解读 | 查询检验/影像报告 | 报告通俗解读、异常提示 | 标注需医生确认 |
| 缴费/导航 | 问缴费、检查地点 | 查询待缴费、室内导航 | 支付动作可追溯 |
| 投诉/人工 | 情绪强烈或无法识别 | 转人工服务台 | 不强行 AI 回复 |
6.3 诊前预问诊设计
输入
- 主诉；
- 现病史；
- 既往史；
- 过敏史；
- 用药史；
- 家族史；
- 检查报告；
- 患者既往就诊记录；
- 文本、语音、结构化选项。
输出
| 输出 | 用途 |
|---|---|
| 结构化预问诊报告 | 给医生诊前浏览 |
| 分诊建议 | 推荐科室/医生 |
| 紧急度等级 | 急诊/优先/常规 |
| 就诊准备清单 | 检查资料、空腹、证件 |
| 患者画像 | 后续随访和复诊 |
6.4 诊中协同设计
诊间语音病历
| 环节 | 说明 |
|---|---|
| 采集 | 诊室麦克风阵列采集医患对话 |
| 转写 | ASR 实时转文字，区分医生/患者 |
| 抽取 | 抽取症状、体征、诊断、药品、检查 |
| 生成 | 生成 SOAP 草案、主诉、现病史 |
| 确认 | 医生修改确认后写回 EMR |
CDSS
| 能力 | 说明 |
|---|---|
| 辅助诊断 | 根据症状、体征、检查给出鉴别诊断 |
| 检查推荐 | 推荐必要检查，避免过度/不足检查 |
| 合理用药 | 提示禁忌、相互作用、剂量异常 |
| 治疗建议 | 给出指南路径，但医生主导 |
病历质控
| 质控类型 | 示例 |
|---|---|
| 完整性 | 缺少主诉、诊断依据、过敏史 |
| 逻辑性 | 症状与诊断不匹配 |
| 时限性 | 病历未及时完成 |
| 内涵质控 | 跨段落、跨文本、跨就诊记录矛盾 |
7. 住院全流程深度方案
7.1 住院主线
门诊/急诊发起入院建议
→ 预住院评估
→ 入院办理
→ 床位调度
→ 病区接收
→ 医生查房/智慧病历
→ 护理风险评估
→ 护理任务派发
→ IoMT 事件采集
→ AI 风险解释
→ 护士处置闭环
→ 出院条件评估
→ 出院小结/康复计划
→ AI 随访/远程管理
7.2 预住院评估设计
| 输入 | 输出 |
|---|---|
| 门诊诊断、入院建议 | 入院必要性评估 |
| 患者病史、症状、过敏史 | 结构化预评估报告 |
| 检查检验结果 | 检查补充建议 |
| 护理风险因素 | 护理等级建议 |
| 床位与资源状态 | 入院时间建议 |
7.3 医生工作流设计
| 场景 | AI 能力 | 写回方式 |
|---|---|---|
| 查房记录 | 语音转写、结构化摘要 | 医生确认后写回 EMR |
| 病程记录 | 自动生成病程草案 | 医生修改签名 |
| 手术记录 | 根据术式模板生成草案 | 医生确认 |
| CDSS | 辅助诊断、检查、治疗建议 | 仅展示，不自动医嘱 |
| 病历质控 | 实时/终末质控 | 医生处理后归档 |
| 出院意向 | 触发出院准备 | 医生确认 |
7.4 护理工作流设计
| 场景 | AI 能力 | 执行终端 |
|---|---|---|
| 入科宣教 | 自动生成宣教内容 | 床头屏/护士 PDA |
| 风险评估 | 压疮、跌倒、VTE、谵妄评分 | 护士 PDA |
| 任务派发 | 翻身、输液巡视、生命体征、宣教 | 护理系统/PDA |
| 交班摘要 | 重点患者、未完成任务、风险事件 | 护理白板 |
| 预警闭环 | 预警工单、处置建议、关闭记录 | PDA/护理白板 |
7.5 IoMT 事件闭环设计
| 环节 | 说明 |
|---|---|
| 设备采集 | 生命体征、输液、毫米波雷达、床垫压力 |
| 网关归一 | 统一患者 ID、床位 ID、设备 ID、时间戳 |
| 事件识别 | 离床、跌倒、输液异常、体征异常、压疮风险 |
| AI 解释 | 结合病历解释风险含义和处置优先级 |
| 工单生成 | 生成护理任务或预警工单 |
| 护士处置 | 护士确认、处理、关闭 |
| 审计回流 | 记录响应时间、处置结果、闭环状态 |
关键原则：
设备事件不是业务闭环，护士确认处置后才是业务闭环。
8. 鸿蒙服务找人专题方案
8.1 核心定义
“服务找人”不是设备自动控制患者，而是：
根据患者身份、位置、预约状态、叫号状态、检查任务等上下文，让医院服务主动以卡片、提醒、屏幕联动或机器人交互的形式触达患者。
8.2 主动签到 POC
sequenceDiagram
participant P as 患者手机
participant N as 近场设备/诊室门口屏
participant A as 医梦 AI 中台
participant Q as 叫号系统
participant H as HIS/签到系统
P->>N: 到达诊室门口区域
N->>A: 上报患者靠近事件
A->>Q: 查询当前队列与患者状态
A->>H: 查询是否可签到
A->>P: 推送签到服务卡片
P->>A: 一键确认签到
A->>H: 调用签到接口
A->>Q: 同步叫号状态
A->>P: 返回候诊提醒
8.3 技术兜底路径
不要把方案写死为“必须鸿蒙 + 星闪”。应设计多种路径：
| 路径 | 用途 | 风险 |
|---|---|---|
| 鸿蒙生态设备发现 | 标杆展示 | 取决于设备生态成熟度 |
| 星闪/近场通信 | 低延迟设备发现 | 医院设备覆盖有限 |
| BLE Beacon | 低成本定位 | 精度和授权问题 |
| Wi-Fi/院内定位 | 区域判断 | 信息科配合度 |
| 二维码/NFC | 最低成本兜底 | 体验不如主动触达 |
| 小程序位置授权 | 患者端兜底 | 用户授权率问题 |
9. 商业模式与收费补充
9.1 原有商业口径
医梦商业模式原本已经形成：
- 三层合作模式：L1 标准能力接入、L2 院级场景建设、L3 区域平台运营；
- 四类收费口径：接入开通费、项目实施费、综合运营服务费、能力值包/合理不限量服务包；
- 两种用量选择：按量版、合理不限量版；
- 一套能力值定价标准。
9.2 新方案需要增加的收费项
| 收费项 | 原因 | 建议归属 |
|---|---|---|
| 设备集成服务费 | 门诊设备大量增加，接入、适配、测试成本高 | 项目实施费扩展项 |
| 统一入口客户端授权费 | 每台设备运行医梦客户端 | 按设备/场景/年度授权 |
| 设备运维服务费 | 设备巡检、状态监控、远程配置、升级 | 综合运营服务费扩展项 |
| 供应链管理服务费 | 医梦做设备选型、准入、采购建议、验收 | 项目服务费/管理服务费 |
| 鸿蒙化试点建设费 | 服务找人 POC 需要独立设计、联调、验收 | 标杆亮点专项 |
| 机器人场景服务费 | 机器人导诊、带路、语音服务有持续成本 | 硬件费 + 服务费 + 能力值 |
| 第三方设备准入测试费 | 厂家接入医梦生态需要测试验收 | 生态合作服务费 |
9.3 合规口径替换
内部可以讨论商业收益，但对外不能出现“回扣”等高风险词。
| 禁用表达 | 正式表达 |
|---|---|
| 回扣 | 渠道合作折扣 / 生态合作服务费 |
| 谁给钱谁进 | 符合准入标准并通过联调验收 |
| 我们说哪家进哪家进 | 医梦提供技术准入评估和推荐选型，最终由医院采购流程确定 |
| 设备利润 | 供应链服务收益 / 集成服务收益 |
| 不给回扣不让进 | 不符合技术准入和交付保障要求，不纳入推荐清单 |
10. 风险分析与纠偏建议
10.1 范围爆炸风险
当前项目同时涉及：门诊总包、住院互通、机器人、统一入口客户端、设备适配、鸿蒙、AI 中台、Dify、MCP、Card、HIS/EMR/LIS/PACS、迪耐克对接、供应链。
如果不做边界控制，项目会失控。
纠偏：
| 第一阶段只做 | 暂缓 |
|---|---|
| 门诊 P0 设备闭环 | 智能镜 |
| 机器人大厅导诊 | 全院机器人巡逻 |
| 诊室语音病历 | 复杂 3D 虚拟人 |
| 诊室门口主动签到 | 全院鸿蒙化 |
| 住院迪耐克互通 | 医梦自建住院硬件总包 |
10.2 设备适配风险
| 风险 | 处理 |
|---|---|
| 厂商不开放接口 | 不进入核心闭环 |
| 屏幕只支持播放 | 降级为展示屏 |
| SDK 不稳定 | 建立验收测试和责任边界 |
| 设备离线 | Device Registry + 心跳监控 |
| 版本碎片化 | 统一客户端版本管理 |
10.3 住院边界风险
必须提前明确：
| 问题 | 主责 |
|---|---|
| 床头屏硬件故障 | 迪耐克/设备方 |
| 护理白板无法显示 | 迪耐克/设备方 |
| AI 服务不可用 | 医梦 |
| 接口字段缺失 | 双方按接口协议确认 |
| IoMT 原始数据异常 | 设备方/迪耐克 |
| AI 风险解释错误 | 医梦负责解释逻辑，医护最终确认 |
10.4 鸿蒙过度承诺风险
不要承诺：
- 全院所有设备鸿蒙化；
- 所有患者自动识别；
- 无需授权自动签到；
- 所有手机都能无感服务找人。
建议承诺：
- 在试点诊区实现“服务找人”演示闭环；
- 支持鸿蒙生态优先，同时保留 BLE/NFC/二维码兜底；
- 所有签到、支付、挂号等动作必须患者确认。
11. 后续会议拆解提纲
11.1 第一场：战略边界会
| 议题 | 目标 |
|---|---|
| 医梦最新定位 | 统一门诊总包 + 住院 AI 协同口径 |
| 门诊和住院边界 | 防止住院硬件责任扩散 |
| 统一入口价值 | 确认客户端是战略产品 |
| 设备生态规则 | 确认医梦有技术准入权 |
| 第一阶段范围 | 锁定 P0 闭环 |
11.2 第二场：门诊业务闭环会
| 议题 | 输出 |
|---|---|
| 门诊患者旅程 | 患者从入院到诊后的完整流程 |
| P0 设备清单 | 导诊屏、自助机、机器人、叫号屏、诊室屏等 |
| 导诊分诊逻辑 | 症状、FAQ、挂号、报告、缴费导航 |
| 诊中协同 | 语音病历、CDSS、质控 |
| 验收指标 | 按业务闭环验收 |
11.3 第三场：AI 中台与设备适配会
| 议题 | 输出 |
|---|---|
| 统一入口客户端架构 | 多设备运行时方案 |
| Device Registry | 设备注册字段和接口 |
| Device Adapter | 设备能力标准协议 |
| Agent Binding | 设备与智能体绑定规则 |
| 运维与计量 | 设备在线、日志、能力值统计 |
11.4 第四场：住院互通会
| 议题 | 输出 |
|---|---|
| 迪耐克接口清单 | 床头屏、护理白板、IoMT、护士站接口 |
| AI 大脑层职责 | 医梦负责哪些智能体 |
| 护理任务闭环 | AI 生成、护士执行、白板展示 |
| IoMT 预警解释 | 设备事件到护理工单 |
| 责任边界 | 医梦/迪耐克/医院各自责任 |
11.5 第五场：鸿蒙服务找人 POC 会
| 议题 | 输出 |
|---|---|
| POC 场景选择 | 主动签到优先 |
| 技术路径 | 鸿蒙/近场/BLE/NFC/二维码兜底 |
| 业务流程 | 患者确认、叫号同步、日志留痕 |
| 演示脚本 | 给院领导看的完整演示 |
| 验收方式 | 可用性、准确率、误触发率 |
12. 结论
医梦当前最重要的不是继续扩写“AI 门诊”和“AI 住院”的功能清单，而是完成以下战略动作：
- 把门诊总包边界锁死：医梦主导门诊软硬件入口、设备准入、统一客户端、AI 中台和业务闭环。
- 把住院边界收敛：医梦做 AI 大脑层和迪耐克互通，不抢病房硬件总包。
- 把统一入口客户端提升为核心产品：所有带屏设备都要加载医梦统一入口。
- 把设备适配平台尽快立项：没有 Device Registry 和 Device Adapter，设备越多项目越乱。
- 把鸿蒙服务找人做成一个小而硬的标杆 POC：主动签到最适合第一期。
- 把商业模式从 AI 能力收费升级为：项目实施费 + 设备集成服务费 + 入口客户端授权 + 能力值 + 综合运营服务费。
- 把后续会议拆成专题会，不要在一个会里同时谈战略、设备、AI、鸿蒙、住院和商务。
最终要形成的不是一堆智能设备，而是一套可控的医院 AI 入口体系：
患者从哪里进入，医梦就在哪里出现；医生在哪里工作，医梦就在哪里辅助；设备在哪里产生事件，医梦就在哪里解释；医院在哪里需要运营，医梦就在哪里计量和闭环。
这才是本项目真正的商业和技术控制位。