医疗行业案例

OCTO 文档中心 · 场景与案例

知识库产品/架构/部署/售前红线文档（active+draft）推导
05-use-cases/OCTO典型应用场景-v1.0场景一+场景二组合扩展
医疗行业私有化部署共性经验推导（已脱敏：不含任何客户可识别信息，规模细节模糊化）
08-presales-delivery/客户价值卡片/价值卡片-医疗-v1.0.md

案例5：医疗集团——私有化合规IM与医护协作

⚠️ 文档声明（使用前必读）

1. 🔴🔴 医疗表述总红线（本案例第一红线）：本案例定位是消息与协作平台落地医疗场景，不构成任何产品能力承诺。OCTO 是消息与协作平台：语音转文字（ASR）是转写工具（须人工校对）；Bot 的检查/用药/会诊提醒是流程自动化的消息触达与执行留痕，不含任何医疗建议内容；均不构成医疗诊断、治疗建议或辅助决策能力。严禁在任何售前沟通中出现"AI辅助诊断/智能诊疗/辅助决策/智能阅片/医疗大模型问诊"类表述（§8 硬口径#1）。（历史版本标题曾用"AI辅助诊疗"命名，已废弃）

2. 本案例为能力推导+医疗行业私有化部署共性经验推导型案例（confidence: medium），非客户实证；客户画像虚构合成、规模已模糊化，不指向任何具体客户，售前不得表述"某客户已落地"。

3. 🔴 合规责任边界：等保三级测评、《个人信息保护法》《数据安全法》合规是院方自身责任，OCTO 只提供技术支撑（§8 硬口径#3）。

4. 🔴 不得说"绝对零出网"：云 ASR、外部 LLM API、镜像拉取为可能出网面，须逐项处置并明示（§5.3）。

5. 能力描述以知识库 active/review 级文档为准（来源随文标注）；性能/规模数字均为经验估算，需 PoC 实测（PS-06）；AI 是平台能力需搭建，非开箱成品（PS-07）。

1. 客户画像

虚构合成画像，不指名、不影射任何具体医疗机构。

维度	画像描述
机构构成	三甲总院 + 区域医疗中心（分院），同一法人集团，院间专网互联
医护规模	医护及医技人员数千人规模（🔴 PS-06：具体规模不作承诺报出，实际并发需 PoC 压测）
合规要求	等保三级（建设目标）、个保法、数安法及卫健行业要求；患者信息极高敏感级，明确要求患者数据不出院内网络；信息安全科/病案室/医务科多重监管
存量系统	HIS（医嘱/排班）/LIS/PACS/EMR 齐备，部署院内核心区，接口经院内 API 网关；无统一院内 IM
沟通现状	电话+个人微信群混用：排班靠电话、会诊靠电话+纸质单、交班靠口头+纸质本；微信群内含患者信息讨论，数据流经第三方服务器
文档现状	病历质控靠纸质检查表+内网共享盘（版本混乱）；检查报告靠医生反复登录系统或电话追询
AI 现状	医护用公有云 AI 被安全科通报禁用；院内 GPU 规划中，无合规 AI 通道
IT 能力	信息科十余人规模+集成商；无 K8s 经验（PoC 期最小化单机部署）；有院内统一身份
核心诉求	不动存量系统前提下，私有化构建院内合规统一沟通平台：全数据院内驻留+语音转写提效+文档协同+Bot 流程通知，满足留痕审计与等保建设技术支撑

2. 痛点分析

2.1 痛点总览

#	痛点	具体表现	业务后果
①	医患/医护沟通效率低	排班/会诊/交班靠电话+口头+纸质混用；报告追询靠反复登录系统或电话	沟通成本高、信息滞后、交接遗漏风险
②	现有微信 IM 不合规	个人微信群讨论工作，患者隐私流经第三方服务器，无留痕无管控	患者数据出院内网络，违反个保法/数安法与院内制度
③	文档协作分散	质控纸质检查表；会诊记录手写再录 EMR；共享盘"最终版_v3"	质控无留痕、版本事故、文档与沟通割裂
④	AI 辅助无法落地	公有云 AI 不敢用于医疗数据；院内无合规通道	效率工具缺失、"影子 IT"风险持续

2.2 痛点 → OCTO 能力映射（来源随行标注；映射不到的如实标注边界）

客户需求	OCTO 能力（已确认）	说明（来源）
统一院内沟通入口	IM+群组+Thread；Web/PC/iOS/Android 全端；已读回执；@提及	排班/会诊/交班统一平台，Thread 不刷屏（典型应用场景 v1.0 §1.3）
交班口述快速记录	Speech 两链路：语音输入（全端，Web 长按左 Shift/移动端按住说话，转写填入输入框可编辑）；语音消息自动转写（结果对能看到消息的人可见、@mention 识别、口语化书面语优化）	夜班口述→自动转写（语音Speech模块 v1.0 §1.2/§1.3）
医疗术语转写准确率	Bot 语音纠错 API `/v1/bot/voice/context`（人名/专有名词/术语热词）	药品/设备/科室人名热词库（语音Speech模块 §1.7）
会诊/检查/用药通知	User Bot（`bf_`）+ type=17 互动卡片（FactSet+OpenUrl/Submit）	三张卡片模板见 §4.3（消息类型与发送 v1.0 §3.12）
排班变更推送	群入站 Webhook（外部系统→群消息）	🔴 Bot 收不到群成员变动事件——排班通知必须由 HIS 触发（Webhook与事件订阅 v1.0 §4）

客户需求	OCTO 能力（已确认）	说明（来源）
数据不出院内	全栈私有化（Docker/K8s），消息落院内 MySQL、附件落院内 MinIO；开源 Apache 2.0	院内沟通数据全部驻留院方设施（红线卡 G7；部署形态总览）
对话留痕	消息持久化 MySQL（octo 库）；Bot 可 `/v1/bot/messages/sync` 补拉	全量对话落库可查（Webhook与事件订阅 §1.5）
操作可追溯	card_action 事件含 `operator_uid`/`acted_at`/`inputs`；at-least-once+event_id 去重	谁何时确认会诊/提交执行记录全程可溯（同上 §2.6）
访问管控	Space 三档+群三档+系统角色（含 `dashboardReader` 只读）；anti-enumeration	质控/审计岗只读看板；越权被拒（权限模型 §2.1/§四）
统一身份与隔离	SSO 原生 OIDC/OAuth2；Space 唯一租户单元	🔴 AD/LDAP/SAML 需 Keycloak 桥接不承诺直连；🔴 多 Space 同库逻辑隔离非物理隔离，强隔离→一实例一部署（权限模型 §五/硬口径③）

客户需求	OCTO 能力（已确认）	说明（来源）
实时协同文稿	Docs：Hocuspocus+Yjs CRDT（WS `/docs-ws/`）冲突自动合并；5 种载体各有独立实现（doc 富文本 Tiptap/sheet 表格区域保护/board 白板/html_ppt/html 文档）	会诊记录用 doc 协同、质控检查表用 sheet（Docs模块 v0.3 §3.1/§3.2）
修订可回溯	全载体版本管理（manual/auto 快照）；restore 非破坏性回滚（回滚前自动存安全快照）	质控整改留版本痕迹（Docs模块 §3.3）
质控意见分级留痕	评论分级：`reader` 仅查看/`commenter`+ 可评论/`writer`+ 可 resolve	质控提意见、主管逐条 resolve 闭环（Docs模块 §3.4）
协同权限即时撤权	短期 JWT（HS256）+ `permission_epoch` 撤权 + `document_name` 绑定防重放	进修/轮转医师离科撤权即时生效（Docs模块 §3.1）
检查报告流转	Bot 通知卡（FactSet 脱敏摘要+OpenUrl 跳院内 PACS/LIS）+ 聊天附件（type=8 先上传后发送）	报告"出了→通知"，正文留源系统（消息类型与发送 v1.0）
文件归档	Drive：个人+共享空间、聊天文件一键转存（Web v2026.08.10+）	🔴 Drive 仅 Web 端；🔴 Bot 对网盘零面（`/v1/bot/drive/` 全仓 0 命中，Bot 仅 `chat/` 附件）（Drive模块 v0.3 P0 结论）
历史文档迁移	Docs 导入导出	🔴 仅确认 HTML/Excalidraw 导出；Markdown/Word/PDF 待确认（DOC-01）——历史 Word 迁移必须 PoC 实测（Docs模块 §3.7）

客户需求	OCTO 能力（已确认）	说明（来源）
AI 工具数据不出网	Bot API/卡片/事件底座全在院内 octo-server 私有化运行	医护助手 Bot 院内运行，数据不落第三方（部署形态总览）
语音不出网	`VOICE_LOCAL_ENABLED=true` 对接本地 ASR（默认 `localhost:8787`）	🔴 降级链本地→云端（本地失败 fallback 云 ASR），必须安全评审（语音Speech模块 §1.4；§5.3）
知识检索 AI（可选）	集成方 Bot 服务端对接院内 LLM；summary 等可经 LLM_API_URL 指院内端点	🔴 PS-07 不内置医疗知识问答成品；🔴 输出不构成诊疗建议
提醒自动化	Bot 事件触发 sendMessage（单目标单条，循环+错峰）	提醒是消息触达，不含医疗建议（红线卡 R6）

定位提醒（贯穿全文）：以上"AI 辅助"全部指效率工具与流程自动化，不构成诊疗辅助决策能力。OCTO 在本案例中不是 EMR、不是 PACS/LIS、不是危急值管理系统、不是随访系统——法定业务载体仍在院内存量系统，OCTO 定位为院内协作与消息底座。

3. OCTO 解决方案概览

3.1 平台架构（文字版架构图）

医护客户端（Web/PC 病区工作站 + iOS/Android 移动巡护）
  │ 院内网络（病区有线/院内无线/出差经院方 VPN——VPN 非 OCTO 能力）
  │ HTTPS 443（单端口，TLS 终结）
  ▼
nginx（院内应用区统一入口）
  ├─ /ws → WuKongIM（IM 长连接，客户端直连）
  ├─ /docs-ws/ → docs-backend:1234（协同 WebSocket）
  ├─ /{bucket}/{key}?X-Amz-* → MinIO（预签名 URL 直传直下）
  └─ 厚路由 → octo-server / docs:3000 / drive:8080
┌───────▼──────────────────────────────────────────────────────┐
│ OCTO 平台（院内应用区，全栈私有化）                             │
│  octo-server（单体 Go：消息/群/Thread/Bot API/卡片/权限）       │
│  octo-web / octo-admin / WuKongIM（IM 底座，三对齐）           │
│  MySQL 8（octo/octo_speech/octo_docs/octo_drive）             │
│  Redis 7 + MinIO（多 bucket 分域）                             │
│  可选 profile：speech（本地ASR）/ docs+docs-html / drive        │
│               / search / summary（需院内 LLM）                 │
├──────────────────────────────────────────────────────────────┤
│ 医护中台 Bot 服务（集成方开发，双实例，持多张 bf_ token）        │
│  · 长轮询 POST /v1/bot/events 收事件（🔴 非 WebSocket，R13）    │
│  · sendMessage + type=17 卡片触达（3 张模板见 §4.3）           │
│  · 事件源：HIS 医嘱/排班、LIS/PACS 报告、医务系统会诊           │
│  · 幂等去重（event_id）/ 429 退避 / 审计日志落院内库            │
└───────┬──────────────────────────────────────────────────────┘
        │ 东西向白名单（院内 API 网关，双向）
        ▼
院内核心区：HIS / LIS / PACS / EMR / 医务管理 / 院内统一身份(IdP)
        ▼
患者触达：院内既有短信网关/患者小程序/电话随访（🔴 非 OCTO 能力）

3.2 模块清单

模块	归属	必选/可选	承担角色	Profile
WuKongIM / octo-server / octo-web / octo-admin	开源（必选）	✅ 必选	IM 底座/单体核心/客户端/管理后台	默认启动
MySQL 8 / Redis 7 / MinIO / nginx	必选基础设施	✅ 必选	主数据（utf8mb4）/缓存队列（生产必须设密码）/对象存储/单端口路由	默认启动
Speech（ASR）	内部版	✅ 核心	交班口述转写、语音消息转写、本地 ASR	`speech`
Docs 文档协同	内部版	✅ 核心	会诊记录/质控协作/交班表	`docs`+`docs-html`
Drive 网盘	内部版	⚙️ 推荐	科室资料归档（🔴 仅 Web；Bot 零面）	`drive`
Search / Summary	内部版	⚙️ 二期可选	检索（资源开销显著）/会话沉淀（需院内 LLM）	`search`/`summary`
Fleet/Loop、Marketplace	内部版	❌ 不推荐启用	🔴 移动端无 Loop；技能分发二期再评估	—

🔴 授权硬口径：Docs/Drive/Speech 等为内部版独有，需明略商业授权；开源版含核心 IM+Bot API，不得表述"开源版全功能"。启用顺序：核心 7 件套 → smoke-test → speech → docs → docs-html → drive（部署形态总览 §3.5.3）。

4. 详细设计

4.1 用户旅程（5 个）

旅程 1：护士交班——语音转文字快速记录

1. 病区移动端在"交班群"按住说话，口述患者情况 → 语音消息
   （分段口述，单条 ≤60s/3MB）
2. 语音消息自动转写为文字（对能看到消息的人可见）：
   @mention 识别、口语化书面语优化
3. 白班护士查看语音+转写文字逐条核对
4. 正式交班记录写入 Docs sheet 交班表（区域保护：各责任组
   只编辑本组区域），转写文字人工校对后填入
5. IT 管理员经 /v1/bot/voice/context 维护热词库
   （药品名/设备名/科室人名）提升术语转写准确率
6. @白班责任护士（内联格式 @[uid:displayName]）+ 已读回执确认

🔴 转写须人工校对红线：转写文字不得直接作为正式交班记录，正式记录以人工校对后内容为准——ASR 不保证医学语义准确（§8 硬口径#4）。
两条语音链路按场景选：移动端"按住说话"发语音消息（收方自动转写）；Web 端不能发语音消息（源码确认），只能语音输入（转写填入输入框，发送前可编辑）（语音Speech模块 §1.2/§1.6）。首次使用 opt-in（设置→语音设置确认协议）；情感 emoji 标注默认开启（VOICE_EMOTION_EMOJI 可配），正式交班建议评估关闭。
音频保留：本地 ASR 下音频仅落本地日志目录（不进对象存储），默认 7 天（ASR_LOG_RETENTION_DAYS 可配）——院方安全科须确认该策略符合患者隐私管理要求（语音Speech模块 §2.3）。

旅程 2：医生病历协作——Docs 协同编辑与质控

1. Web 端「文档」创建病例讨论记录（doc 载体），邀请科内+进修
   医师为文档成员
2. 多人实时协同：Yjs CRDT 自动合并并发修改；鉴权链=短期 JWT
   + permission_epoch（进修医师出科撤权即时生效）
   + document_name 绑定（防跨文档重放）
3. 质控检查表用 sheet 载体（区域保护：质控组填检查列，
   临床组填整改列）
4. 质控专员 commenter 评论提意见（reader 仅看/commenter 可评/
   writer 可 resolve）；主管医师逐条 resolve
5. 修改前建 manual 版本快照；返工对照版本；大改可 restore
   （非破坏性回滚）
6. （可选配置）评论区 @质控 Bot 触发 doc_comment_mention 独立
   事件（非群聊通道），Bot 生成"整改清单"草稿回写评论线程
   ——🔴 需集成方开发，非内置（PS-07）
7. 定稿由文书按院内规范录入 EMR（法定载体），OCTO 保留
   讨论与质控过程留痕

🔴 OCTO 不是电子病历系统：正式病历法定载体是 EMR；OCTO Docs 承载讨论记录/质控协作/非正式文稿，不得暗示"病历写在 OCTO 里合规"。5 种载体各有独立实现（非"类 Notion 通用文档"）。
🔴 导入导出边界：仅 HTML/Excalidraw 导出已确认；Markdown/Word/PDF 待确认（DOC-01）——历史 Word 模板迁移必须 PoC 实测，不承诺格式保留。
Bot 操作文档边界：Bot Token 不能直调 /v1/bot/docs 类接口；仅评论 @Mention 链路，Bot 须先被加为文档成员、仅 User Bot、MVP 灰度门控（Docs模块 §3.4/§4.3）。移动端边界：Docs 入口已确认 Web 端，iOS/Android 待确认（DOC-07）——查房文档操作以 Web 工作站为主。

旅程 3：科室主任管理——Space 科室空间与群组管理

1. Space 规划：试点期全院单 Space（数千名医护同 Space），群组按
   科室/病区/职能组织（术语统一：租户单元=Space，无 organization）
2. 群组管理：科室群设主任（群主）+护士长+教学秘书（群管理员）
   ——群三档角色；疑难病例开 Thread 子区讨论不刷屏
3. 跨科室协作：与放射科建联合会诊群（同 Space 正常建群）；
   未来总院/分院拆 Space 后跨 Space 协作走外部群机制
   （is_external_group=1，通讯录隔离防越权邀请）
4. 排班变更：HIS → 群入站 Webhook 推送科室群——🔴 Bot 收不到
   群成员变动事件，调班通知必须由排班系统触发
5. 权限治理：Space 三档角色（member/admin/owner）；🔴 无自定义
   RBAC——岗位差异化权限靠群管理员+业务侧实现
6. 质控看板：病案室/质控办授 dashboardReader（看板只读）

🔴 权限变更 60s 缓存延迟：移除管理权限后最坏 60s 内仍可执行管理操作——医护轮转/离岗场景评估该窗口（权限模型 §2.4）。
🔴 多 Space 逻辑隔离：集团强隔离需求→一实例一部署，不做"同实例强隔离"承诺（权限模型硬口径③）。医护离职：Space 移除+SSO 禁用；🔴 无 SCIM 自动 provisioning，人员系统联动需定制或流程化（权限模型 §5.2）。

旅程 4：检查报告流转——Bot 通知卡与文件分享

1. PACS 报告发布 → 医护中台获知事件（LIS/PACS 回调或中台轮询
   院内接口——集成方按院内接口规范开发）
2. 中台 POST /v1/bot/sendMessage 向开单医生 DM 发送"检查结果
   通知卡"（§4.3-1：FactSet 脱敏摘要+OpenUrl 跳院内 PACS）
3. 病区护士站同步收群消息摘要（项目名+状态，无正文）
4. 医生点"查看报告详情"→ 院内 PACS Web 端（内网可达）
5. 会诊携带资料：报告 PDF/影像截图走聊天附件（type=8 先上传
   后发送；Bot 上传仅 chat/ 命名空间）；长期归档由用户 Web 端
   一键转存科室 Drive——🔴 Bot 对网盘零面，不能设计"Bot 自动
   存网盘"
6. 危急值：按院内规范电话通知（法定流程）+ 中台并行推送红色
   卡片留痕——电话为主、卡片为辅
7. 全程留痕：卡片消息落 MySQL；触达确认依赖消息已读回执

卡片不含检查结果内容（最小必要）：卡面仅床号/尾号/姓首字/项目/状态/时间，正文留 LIS/PACS——IM 通道不承载诊疗数据正文，本方案隐私核心决策。
🔴 患者本人触达不在 OCTO 范围：患者短信/小程序通知是院内既有通道，由集成方从中台或 LIS/PACS 侧对接；🔴 OpenUrl 目标必须院内可达，禁止外网链接入医疗通知卡。群摘要可用群入站 Webhook 或 Bot 直发；业务关键流推荐 Bot 直发（可控可审计）。

旅程 5：IT 管理员合规管理——权限、审计与数据驻留

1. SSO：院内身份支持 OIDC → 直接对接（DM_OIDC_*）；仅 AD/LDAP
   → Keycloak 桥接（🔴 不承诺原生直连）
2. 账号生命周期：入职建号、离职禁用+移出 Space（评估 60s 缓存
   窗口）；Bot（bf_）不占 Space 座位不占 License 人头
3. 数据驻留盘点（全部院内，清单见 §5.3）
4. 出网面审计（§5.3 表）：云 ASR/外部 LLM/镜像拉取逐项决策
   ——🔴 不得说"绝对零出网"
5. 审计取证：消息落库可查（/v1/bot/messages/sync 补拉）；
   card_action（operator_uid/acted_at/inputs）——用药执行/会诊
   确认可溯；dashboardReader 审计岗；
   🔴 无内置合规报表/审计导出（删号无 GDPR 导出）——按院内
   要求基于 MySQL 定制 ETL 到院内审计平台
6. 密钥管理：bot_token 密管保管+/revoke 泄露演练；
   COLLAB_TOKEN_SECRET 等 ≥32hex 由 preflight 启动校验
7. 等保支撑：按 §5.2 对照表提供架构与安全机制说明
   ——🔴 测评与备案由院方主导

4.2 卡片能力规范（先读再用）

三张模板遵守以下源码确认规范（Bot-API错误码与排障 v1.0 §三、消息类型与发送 v1.0 §3.12）：

规范项	值
消息类型/版本	`type: 17`（Bot 专属）；`card_version: "1.5"`+卡片内 `version: "1.5"`（不匹配直接拒绝）
硬限制	payload ≤ 512 KiB；节点 ≤ 200；嵌套深度 ≤ 16
Profile	纯展示卡（含 OpenUrl 本地动作）用 `octo/v1`；交互卡（输入+Submit）必须用 `octo/v2`（输入元素与 Submit 为 v2 专属）
元素白名单	展示：TextBlock/RichTextBlock/Image/ImageSet/Container/ColumnSet/FactSet/Table/ActionSet；输入(v2)：Input.Text/Toggle/ChoiceSet/Number/Date/Time；动作：OpenUrl/ToggleVisibility/CopyToClipboard+Action.Submit(v2)；🔴 不支持 Action.Execute/auto-refresh
探测与改卡	发送前 `GET /v1/bot/card/profile` 探测（不支持自动降级纯文本，G10）；动态改卡 `POST /v1/bot/message/edit`+`card_seq` CAS 锁状态防重复
校验方式	🔴 无独立校验端点，校验在发送入口内联——开发环境先发最简测试卡再逐步加元素

4.3 卡片模板示例（3 张，完整 JSON 可直接用）

均为 `POST /v1/bot/sendMessage` 完整请求体（Bearer `bf_` token），`channel_id` 替换为实际会话 ID；占位数据为脱敏示例；属性级校验以运行时 manifest 为准。

4.3-1 检查结果通知卡（octo/v1 展示卡：FactSet + Action.OpenUrl）

{
  "channel_id": "<开单医生DM会话ID>",
  "channel_type": 1,
  "payload": {
    "type": 17,
    "profile": "octo/v1",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "🩻 检查报告发布通知",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "您申请的检查项目报告已发布。本通知不包含检查结果内容，请通过院内系统查看完整报告。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "FactSet",
          "facts": [
            { "title": "患者", "value": "12床 李*（住院号 ****8321）" },
            { "title": "检查项目", "value": "胸部CT平扫" },
            { "title": "报告状态", "value": "已发布" },
            { "title": "报告时间", "value": "2026-09-22 15:42" },
            { "title": "报告医师", "value": "放射科 王医师" },
            { "title": "来源系统", "value": "PACS" }
          ]
        },
        {
          "type": "TextBlock",
          "text": "提示：危急值报告请按院内危急值管理流程电话确认，本通知仅为辅助留痕通道。",
          "isSubtle": true,
          "wrap": true
        }
      ],
      "actions": [
        {
          "type": "Action.OpenUrl",
          "title": "查看报告详情",
          "url": "https://pacs.hospital.intra/report/view?id=RPT-20260922-0417"
        }
      ]
    }
  },
  "client_msg_no": "notify-RPT-20260922-0417"
}

4.3-2 用药提醒执行确认卡（octo/v2 交互卡：Toggle + Submit）

{
  "channel_id": "<病区护理协作群会话ID>",
  "channel_type": 2,
  "payload": {
    "type": 17,
    "profile": "octo/v2",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "⏰ 医嘱用药执行提醒",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "以下医嘱已到计划执行时间。请责任护士按院内规范完成核对与给药后，在本卡片提交执行记录。医嘱内容以 HIS 为准。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "FactSet",
          "facts": [
            { "title": "患者", "value": "12床 李*（住院号 ****8321）" },
            { "title": "医嘱摘要", "value": "注射用头孢呋辛钠 0.75g 静脉滴注" },
            { "title": "计划执行时间", "value": "2026-09-22 16:00" },
            { "title": "开单医生", "value": "呼吸内科 陈医师" },
            { "title": "提醒来源", "value": "HIS 医嘱系统" }
          ]
        },
        {
          "type": "Input.Toggle",
          "id": "double_check",
          "title": "已完成双人核对（三查七对）并执行给药",
          "value": "false",
          "valueOn": "true",
          "valueOff": "false"
        },
        {
          "type": "Input.Text",
          "id": "exec_note",
          "label": "执行备注（选填）",
          "placeholder": "如患者主诉、异常情况、暂停原因（100字以内）",
          "isMultiline": true,
          "maxLength": 100
        }
      ],
      "actions": [
        {
          "type": "Action.Submit",
          "title": "提交执行记录",
          "data": {
            "action": "med_exec_confirm",
            "order_id": "ORD-20260922-01256",
            "patient_bed": "12"
          }
        }
      ]
    }
  },
  "client_msg_no": "med-ORD-20260922-01256"
}

4.3-3 会诊邀请确认卡（octo/v2 交互卡：事实 + 确认/请假）

{
  "channel_id": "<受邀会诊医师DM会话ID>",
  "channel_type": 1,
  "payload": {
    "type": 17,
    "profile": "octo/v2",
    "card_version": "1.5",
    "card": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        {
          "type": "TextBlock",
          "text": "🏥 会诊邀请",
          "size": "medium",
          "weight": "bolder"
        },
        {
          "type": "TextBlock",
          "text": "您收到一例会诊邀请，请确认是否按时参加。会诊安排以医务管理系统为准。",
          "isSubtle": true,
          "wrap": true
        },
        {
          "type": "FactSet",
          "facts": [
            { "title": "会诊时间", "value": "2026-09-23 10:30" },
            { "title": "会诊地点", "value": "住院部B座12层 示教室" },
            { "title": "会诊类型", "value": "科间普通会诊" },
            { "title": "申请科室", "value": "呼吸内科" },
            { "title": "患者", "value": "12床 李*（住院号 ****8321）" },
            { "title": "申请理由", "value": "肺部占位性质待定，协助制定进一步检查方案" }
          ]
        },
        {
          "type": "Input.Text",
          "id": "leave_reason",
          "label": "请假原因（请假时填写，50字以内）",
          "placeholder": "选填，仅请假时需要",
          "maxLength": 50
        }
      ],
      "actions": [
        {
          "type": "Action.Submit",
          "title": "确认参加",
          "data": {
            "action": "consult_accept",
            "consult_id": "CS-20260923-007"
          }
        },
        {
          "type": "Action.Submit",
          "title": "请假（转医务科协调）",
          "data": {
            "action": "consult_decline",
            "consult_id": "CS-20260923-007"
          }
        }
      ]
    }
  },
  "client_msg_no": "consult-CS-20260923-007"
}

5. 部署架构建议

5.1 部署形态与演进路径

阶段	档位与形态	资源（⚠️ 经验估算，非承诺）	说明
PoC 单科室	最小化单机部署（Docker Compose）	⚠️ 具体规格以压测为准	核心 7 件套+speech+docs/docs-html；drive/search/summary 暂不启用
试点扩展	最小化单机→Kubernetes 高可用集群过渡	视放量与实测调整	多科室上线后按实测扩容
生产全院	Kubernetes 高可用集群部署	以压测和交付方案为准	MySQL 建议主从；HA 拓扑以交付方案为准

🔴 档位与 HA 硬口径：① 具体资源规格无官方证据（PS-06），不作承诺报出；② 全院医护吞吐上限必须 PoC 压测（R10，无官方性能基准）；③ 高可用拓扑官方无公开基线（Y3），方案书表述为"交付阶段结合院方基础设施设计高可用拓扑"。

5.2 网络分区与等保三级考量

┌────────────────────────────────────────────────────────────────┐
│ 互联网区：患者触达（院内既有短信网关/患者小程序/电话随访，        │
│   🔴 非 OCTO 能力）；出差医护远程接入走院方既有 VPN/零信任       │
└──────────────┬─────────────────────────────────────────────────┘
               │ （推荐：OCTO 不直接暴露公网）
┌──────────────▼─────────────────────────────────────────────────┐
│ DMZ 区（可选）：仅当院方要求 Web 远程接入时，前置 WAF→nginx(TLS) │
│   推荐：不出 DMZ，医护全走院内网络/VPN，攻击面最小              │
└──────────────┬─────────────────────────────────────────────────┘
               │ 指定端口白名单
┌──────────────▼─────────────────────────────────────────────────┐
│ 院内应用区（OCTO 全栈）：octo-server/web/admin/WuKongIM、        │
│   MySQL 8（octo/octo_speech/octo_docs/octo_drive）、Redis、     │
│   MinIO、nginx、本地 ASR 服务、医护中台 Bot 服务（双实例）；      │
│   （二期）院内 LLM / Kafka+OpenSearch                           │
└──────────────┬─────────────────────────────────────────────────┘
               │ 东西向白名单（院内 API 网关，双向）
┌──────────────▼─────────────────────────────────────────────────┐
│ 院内核心区：HIS（医嘱/排班）/LIS/PACS/EMR/医务管理/统一身份      │
└────────────────────────────────────────────────────────────────┘

#	考量	OCTO 技术支撑	责任边界
1	网络隔离	全栈部署院内应用区，单端口暴露（nginx TLS）；与核心区东西向白名单	分区与防火墙由院方安全科实施
2	数据驻留	消息/附件/文档全落院内 MySQL/MinIO（G7）；出网面逐项处置（§5.3）	数据分类分级与 PIA 由院方主导
3	身份鉴别	OIDC SSO；生产强制改默认密码（preflight 拦截占位凭据）；Redis 密码	账号策略按院方制度
4	访问控制	三套角色+anti-enumeration；权限变更 60s 收敛	🔴 无自定义 RBAC/SCIM——岗位差异化管理在业务侧
5	安全审计	消息落库留痕；card_action 操作留痕；dashboardReader 审计岗；审计导出定制开发	审计策略/留存期由院方合规要求定义
6	通信加密	TLS 终结（nginx）；启用 HTTPS 须同步覆盖 MINIO_SERVER_URL / TS_MINIO_DOWNLOADURL / TS_EXTERNAL_BASEURL / OCTO_WK_WSS_ADDR（SigV4 一致性）	证书与院方 PKI 对接
7	入侵防范	部署含 PR#713 修复版本；smoke-test 11 步；OpenSearch/Kafka 启用时配置安全（默认无认证）	漏扫/加固/测评由院方/测评机构执行

🔴 责任表述红线：上表全部为"技术支撑"项。等保三级测评、备案、整改验收是院方自身责任；不得表述"OCTO 帮助医院通过等保三级/等保三级认证产品"。

5.3 数据驻留与出网面清单（售前必须逐项明示）

数据类别	驻留位置	备注
消息/群/用户/卡片	院内 MySQL `octo` 库	全量对话留痕
聊天附件	院内 MinIO（chat 等公共 bucket）	下载客户端直连 MinIO 预签名 URL（R11：downloadURL 必须医护客户端可达，防火墙清单显式放行）
文档正文/协同状态	院内 MySQL `octo_docs`+Redis	Yjs CRDT 状态
文档附件/网盘文件	院内 MinIO `octo-docs-attachments`/`octo-drive` 独立 bucket	两 bucket 不混用
语音音频	本地 ASR 日志目录（`ASR_LOG_DIR`），默认 7 天可配	不进 MinIO；`octo_speech` 库仅 4 张元数据表不存音频

出网路径	触发条件	全内网处置	残余风险明示
云 ASR	speech 默认引擎 Gemini/qwen/GPT 均云 API；且本地失败降级链 fallback 云端（源码确认：本地→后端 API→模型列表）	`VOICE_LOCAL_ENABLED=true`+自建本地 ASR（对接 localhost:8787）	🔴 fallback 云端必须安全评审：交班语音含患者信息，"本地失败自动上云"不可接受时需与产品团队确认禁用方案（待确认）；结论写入实施方案
外部 LLM API	summary 等 LLM 依赖默认调外部（claude 系）	LLM_API_URL/KEY/MODEL 指向院内端点；或本期不启用 summary	二期知识检索 Bot 直连院内 LLM
镜像拉取	部署/升级时从 docker.io 拉取	院内镜像仓库离线预导入	升级窗口协调

🔴 三类任一未处置前严禁说"绝对零出网"；全部处置后表述为"业务数据链路全内网，出网面已按清单处置并经安全评审确认"。

5.4 语音本地 ASR 选项与内网 LLM

配置项	值	说明
`VOICE_LOCAL_ENABLED`	`true`	启用本地转写
本地 ASR 地址	默认 `localhost:8787`	集成方部署本地 ASR 引擎（开源 ASR 或院内采购）
热词纠错	`POST /v1/bot/voice/context`	药品/设备/科室人名热词——医疗术语转写准确率关键手段
语音硬限制	60s / 3MB / 最短 1s	长口述分段；超限报错不静默截断
引擎降级	同引擎内多模型 fallback（非跨引擎）	云引擎与降级行为见 §5.3

医疗 ASR 选型注意：speech 引擎为 Gemini/GPT/Qwen（云）+本地 ASR（可选）三类（源码确认；Whisper/Azure/讯飞不是独立引擎选项）。院内商用 ASR 能否对接 8787 协议需 PoC 验证，不承诺任意 ASR 品牌开箱对接。

6. 实施路径

Phase 0：合规评估与安全评审（2~3 周，先于技术工作）

工作项	内容
数据分类分级	与安全科/病案室确认进入 OCTO 的数据范围（讨论记录/质控意见/通知摘要），EMR 法定数据不迁移
出网面评审	§5.3 三类逐项决策；本地 ASR fallback 云端行为专项评估（P0 合规项）
PIA	患者信息经 IM/ASR 处理的个人信息保护影响评估（音频 7 天保留、S-01 删除能力边界）
等保差距分析	院方主导；OCTO 提供 §5.2 技术支撑对照材料（🔴 测评主责在院方）
基础设施确认	院内 GPU/LLM 可用性；本地 ASR 选型与 8787 协议兼容性预验证；镜像离线导入通道

Phase 1：PoC 单科室（4~6 周）

周	工作项	关键产出
W1	核心 7 件套（最小化单机部署）+smoke-test 11 步；OIDC SSO 联调（AD 走 Keycloak 如需）；网络/防火墙落地（含 MinIO 放行验证）	可用 PoC 环境
W2	speech 启用+本地 ASR 对接+热词库初版；语音链路试点病区实测（准确率/60s 限制/情感 emoji 评估）	语音实测报告
W3	docs/docs-html 启用；交班表（sheet）+病例讨论 doc 模板；Word 模板导入实测（DOC-01 验证）	文档协作基线
W4	医护中台：3 张卡片+长轮询框架+HIS/LIS/PACS 接口联调；card_action 留痕落库	卡片链路闭环
W5~W6	试点科室（建议一个内科病区）全旅程试用；429 限流压测与吞吐摸底；安全整改闭环	PoC 验收报告（实测数据+风险清单）

Phase 2：试点扩展（2~3 个月）与 Phase 3：全院推广

阶段	工作项	出口标准/红线
P2-M1	多科室铺开（3~5 科室）；迁 K8s 或双节点（HA 以交付方案为准）；旅程 2 质控协作上线；审计导出定制开发（MySQL ETL 到院内审计平台）	灰度放量+科室信息员培训
P2-M2	5 旅程全覆盖；会诊邀请卡+医务系统集成；Drive 归档规范；dashboardReader 审计岗；限流水位监控	每周运营复盘
P2-M3	使用数据评估；容量复核；院内管理规范定稿（建群/命名/数据分级）	出口指标达院方内定目标（数字由院方设定，OCTO 侧不承诺具体数值）
P3 全院	全院医护分批覆盖（扩容以实测+压测为准，PS-06）；分院经院间专网接入同一实例，集团强隔离→分院独立部署实例（🔴 逻辑隔离红线）；微信工作群分批迁移/冻结（🔴 PS-08 无现成桥接工具，靠制度+引导）；二期评估 search/summary/技能分发；运维交接（院方独立升级/备份/扩容，token 轮换+/revoke 演练）	不承诺"完全替代微信全部用途"；扩容以试点实测为准

7. ROI 价值分析框架

🔴 只给框架与指标体系，不代入数字、不承诺 ROI 数值；变量以 PoC/试点实测代入；对外测算标注"基于院方试点数据的估算，非产品承诺"。

维度	核心指标	采集方式	备注
沟通效率	交班记录整理时长；报告获取时效（发布→医生知悉）；会话组织时长；电话沟通量	试点前后工时抽样+卡片消息落库时间戳 vs 报告发布时间	PoC 期采"电话+纸质"基线
合规风险收敛	患者数据流经第三方服务器事件数（微信工作群通报数）；审计取证时长	安全科通报对比；审计演练计时（消息库检索 vs 微信不可取证）	⚠️ 合规价值建议定性+事件计数，不作金额换算
协作与文档效率	质控意见闭环周期（提出→resolve）；质控返工率；版本事故数	Docs 评论线程/版本快照统计+病案室台账	试点前后对比

8. 售前注意事项（🔴 硬口径，违反即交付/合规事故）

#1~#6 为医疗行业专属红线（最高优先级），#7 起为通用硬口径；来源均为源码确认/知识库文档，售前沟通、方案书、投标应答均不得违背。客户追问统一话术：「这个能力当前版本的边界是 XXX，具体方案我们交付团队会评估。」

#	🔴 硬口径	禁止说法	正确口径	来源
1	医疗表述红线（医疗第一红线）	"AI 辅助诊断/智能诊疗/辅助决策/智能阅片/医疗大模型问诊/开单建议"	OCTO 是消息与协作平台：ASR 是转写工具（须人工校对）；Bot 提醒是消息触达与执行留痕；LLM 检索输出仅资料参考。不具备也不承诺任何诊断/治疗建议能力；诊疗决策类软件需求不在 OCTO 范围（如需医疗器械软件 SaMD 定位应咨询专业机构）	Speech模块 v1.0（纯STT源码确认）；PS-07
2	不得说"绝对零出网"	"数据绝对零出网/完全不出网"	云 ASR（含本地失败 fallback 云端）、外部 LLM API、镜像拉取为三类出网面，逐项处置并明示；处置后表述"业务数据链路全内网，出网面经安全评审确认"	部署形态总览；Speech模块 §1.4
3	合规责任边界	"OCTO 帮医院过等保三级/等保认证产品/保证合规"	等保测评/个保法/数安法合规是院方自身责任；OCTO 提供私有化/数据驻留/留痕审计等技术支撑并配合整改	本案例 §5.2
4	语音转写须人工校对	"转写结果可直接作为交班/护理/病历记录"	转写是辅助输入，正式记录以人工校对后内容为准；不保证医学语义准确	Speech模块 v1.0+本案例红线
5	患者触达渠道不内置	"OCTO 给患者发短信/小程序通知/患者版 App"	OCTO 客户端面向院内医护；患者触达由院内既有网关承担，集成方桥接	客户端支持矩阵；§3.1
6	紧急流程不迁移	"危急值/急会诊全部走 OCTO 通知"	危急值与急会诊按院内电话+法定流程；OCTO 卡片仅并行留痕辅助；普通会诊才走卡片确认	医疗安全设计（§4.3-3）
7	无自定义 RBAC	"自定义护士长/质控员/医务科角色、权限矩阵"	角色硬编码枚举（Space 三档/群三档/系统四档）；岗位差异化权限在业务侧实现	权限模型硬口径②
8	多 Space 逻辑隔离	"总院分院物理隔离/数据沙箱"	同库逻辑隔离（space_id 过滤）；强隔离→一实例一部署	权限模型硬口径③
9	SSO 仅 OIDC/OAuth2	"原生对接 AD/LDAP/SAML/硬件认证"	原生仅 OIDC/OAuth2；AD/LDAP 需 Keycloak 桥接；无 SCIM	权限模型 §5.2
10	移动端边界	"手机上用网盘/回路/市场"	🔴 Drive 仅 Web；移动端无 Loop/Marketplace；Docs 移动端待确认（DOC-07）——查房以 Web 工作站为主	Drive模块；场景文档硬口径#6/7
11	语音能力边界	"语音通话/会议转写/实时字幕/Bot 语音播报"	纯 ASR：≤60s/3MB；Web 不能发语音消息（仅语音输入）；Bot 不能发语音（无 TTS）；不支持实时流式/通话/会议转写；首次 opt-in	Speech模块 v1.0 §1.5/§3.7
12	语音数据治理	"语音数据可随时删除/不留痕"	音频仅本地 ASR 日志目录默认 7 天（可配）；用户删除语音能力待确认（S-01）——患者语音场景需 PIA 评估	Speech模块 v1.0 §2.3/§四
13	Bot 边界	"Bot 管理网盘/解散群/批量群发/WebSocket 收事件"	Bot 是普通群成员（R3）；解散群/改角色不开放（R4）；Bot 对网盘零面；事件是 HTTP 长轮询（R13）；sendMessage 单目标单条（R6）；卡片硬限 512KiB/200 节点/深度 16/card_version "1.5"（R8，limits 以运行时 manifest 为准）	Drive模块 P0；红线卡；错误码 §三
14	无内置合规报表/GDPR 导出	"一键导出审计报表/患者数据可携带导出"	无合规报表模块；删号无 GDPR 导出——审计导出基于 MySQL 定制开发，工作量入实施方案	场景文档硬口径#10
15	性能不承诺	"支持 1500 并发/QPS 保证 X"	无官方性能基准（R10）；档位经验估算（PS-06）；全院吞吐必须 PoC 压测	红线卡 R10
16	品牌与授权	"DMWork"对外；"开源版含全部模块"	对外统一称 OCTO（R14/G1）；Docs/Drive/Speech 等内部版需商业授权；生产锁 tag（R12）	红线卡；案例1 PS-01

9. 已知限制与待确认项

方案承诺前必须逐项确认；集中追踪于 `00-inbox/open-questions.md`，PoC 启动前由产品管家/Owner 复核闭环。

9.1 影响本方案的待确认项

编号	待确认项	影响	缓解设计
S-01	用户主动删除自己语音数据的能力（无源码证据）	患者语音场景个保法"删除权"边界	Phase 0 PIA 评估；涉患者语音场景暂缓；7 天自动清理兜底
ASR-fallback	本地 ASR 失败后 fallback 云端能否禁用（降级行为已源码确认，禁用开关未见）	交班语音含患者信息，fallback=数据出网	Phase 0 安全评审 P0 项；与产品团队确认处置；不可接受则语音功能降范围使用
DOC-01	Docs Markdown/Word/PDF 导入导出（私有仓）	历史 Word 模板/质控表迁移	PoC W3 实测；不承诺格式保留
DOC-07	Docs iOS/Android 入口是否实现	查房移动端文档操作	旅程 2 以 Web 工作站为主，不依赖移动端 Docs
D-02	Drive 预览格式清单/大小限制	医学影像文件在线预览	预览为 302 重定向直下；DICOM 不承诺在线预览，走下载+院内专业阅读器
D-03	Drive 分享链接高级功能（密码/有效期/权限粒度）	科室资料外发管控	🔴 不基于"分享密码/有效期"设计外发管控；外发按院内制度+既有手段
D-08	Drive 文件版本管理/回收站	归档防误删	重要归档双份（共享空间+院方备份）；不依赖 Drive 版本能力
P1-05/BA-07	限流桶默认参数	早间报告批量发布高峰吞吐	PoC 压测；system_setting 确认配置；错峰+卡片合并
P1-06	Webhook 回调失败重试机制	LIS→群 Webhook 可靠性	业务关键流走中台 Bot 直发；Webhook 仅辅助
P1-03	长轮询事件保留 TTL	中台宕机恢复窗口	事件先落库再 ACK；`/v1/bot/messages/sync` 补拉兜底

9.2 已确认边界（按已知限制管理）

边界	影响	对策
Bot 收不到 reaction/群成员变动/网盘事件	"调班感知/成员变动通知"类设计	由 HIS/排班系统经 Webhook 触发，不设计为 Bot 监听
群聊不 @Bot 的普通消息是否投递 Bot 待确认	中台不依赖群内"喊话"触发	Bot 交互一律 @Bot 或 DM；事件源来自系统对接
无独立 `in_reply_to` 顶层字段	会话上下文解析	中台以业务 ID（order_id/consult_id/report_id）管理状态
Bot 文件上传仅 `chat/` 命名空间	报告附件归档	用户手动转存 Drive（Web）；OpenUrl 跳源系统为主通道
撤回消息独立端点未见路由	误发更正	审计口径"以落库消息为准"（不可撤反利好留痕）；误发发更正消息
speech-admin 功能极窄（仅 App+Key 生命周期）	语音运营管理预期	热词经纠错 API+运维脚本，不承诺管理台功能
Docs Bot 评论链路 MVP 灰度门控	质控 Bot 自动化	旅程 2 步骤 6 标注"可选配置"，主流程不依赖

10. 附录：文档索引

#	文档	路径	本文引用点
1	语音Speech模块 v1.0（active）	`01-product/模块说明/语音Speech模块.md`	纯 ASR 无 TTS、两链路、opt-in、本地 ASR/降级链、60s/3MB、音频 7 天、热词 API、S-01
2	文档协同Docs模块 v0.3	`01-product/模块说明/文档协同Docs模块.md`	5 载体、Yjs CRDT、JWT+permission_epoch、评论分级、非破坏性回滚、doc_comment_mention、DOC-01/07
3	Drive网盘模块 v0.3	`01-product/模块说明/Drive网盘模块.md`	仅 Web、Bot 零面、预览 302、聊天转存、D-02/03/08
4	权限模型与鉴权体系 v0.1	`02-architecture/权限模型与鉴权体系.md`	三硬口径、三套角色、60s 缓存、dashboardReader、OIDC、PR#713、anti-enumeration
5	OCTO部署形态总览 v1.1	`03-deployment-ops/OCTO部署形态总览.md`	7 件套、profile 顺序、单端口、三对齐、HTTPS 四变量、smoke-test、离线待确认
6	售前红线卡 v0.1	`08-presales-delivery/售前红线卡-v0.1.md`	G1/G7/G10、Y3、R1~R14
7	OCTO典型应用场景 v1.0	`05-use-cases/OCTO典型应用场景-v1.0.md`	场景一/二能力、PS-06/PS-07、移动端/GDPR 硬口径
8	案例1-大型制造企业 v1.0	`05-use-cases/客户案例/案例1-大型制造企业-私有化AI协作办公平台.md`	结构对标、PS-01/02/08、LLM 内网对接、出网三类
9	案例2-金融机构 v1.0	`05-use-cases/客户案例/案例2-金融机构-智能客服与业务Bot自动化.md`	结构与卡片 JSON 规范对标、长轮询框架、card_action、群入站 Webhook
10	Bot-API错误码与排障 v1.0	`04-api-integration/Bot-API错误码与排障-v1.0.md`	卡片硬限、403/429
11	消息类型与发送 v1.0	`04-api-integration/消息类型与发送-v1.0.md`	type=17 双 profile、白名单、动态改卡 CAS、type=8
12	Webhook与事件订阅 v1.0	`04-api-integration/Webhook与事件订阅-v1.0.md`	群入站 Webhook、card_action payload、messages/sync、Bot 收不到的事件
13	待确认项统一追踪清单	`00-inbox/open-questions.md`	§9 编号来源（S-01/DOC-01/07/D-02/03/08/P1-03/05/06）

11. 客户价值亮点

11.1 核心价值亮点

11.2 可复用售前话术

话术1：「OCTO 帮医院在院内网络搭一套合规统一沟通平台——医护沟通、语音转写、文档协同、报告通知、执行留痕都在一个平台上，消息和文档全部落院内设施、全量留痕可审计。个人微信群讨论工作导致患者数据外流的合规风险，从平台架构层面解决。」
话术2：「需要特别说明，OCTO 是消息与协作平台，不是医疗 AI 也不做辅助诊断。语音转写是效率工具（必须人工校对），Bot 通知是消息触达和执行留痕，正式病历仍然以 EMR 为法定载体，危急值仍然按院内电话流程走。我们做的是把医护的沟通协作效率提上去，同时让每一步操作都留痕可追溯。」
话术3：「企业知识管理（知识库）和协作文档是 IM 原生能力，不是外挂系统——交班表、质控检查表、会诊记录直接在聊天旁边协同编辑，质控意见挂在段落上，版本快照自动保存。质控专员不用再追着共享盘找'最终版_v3'。」

11.3 关联阅读

对应价值卡片：[医疗行业客户价值卡片](../../08-presales-delivery/客户价值卡片/价值卡片-医疗-v1.0.md)
语音 Speech 模块说明：[01-product/模块说明/语音Speech模块.md](../../01-product/模块说明/语音Speech模块.md)
文档协同 Docs 模块说明：[01-product/模块说明/文档协同Docs模块.md](../../01-product/模块说明/文档协同Docs模块.md)
售前红线速查：[08-presales-delivery/售前红线卡-v1.0.md](../../08-presales-delivery/售前红线卡-v1.0.md)

11.4 相似行业参考

[案例2-金融机构-智能客服与业务Bot自动化](./案例2-金融机构-智能客服与业务Bot自动化.md)：金融行业同样有强合规、全量留痕审计、私有化部署、智能对话机器人（Bot）自动化触达的共性需求，对高敏感行业的合规落地与 Bot 集成模式有较高参考价值。

版本记录

版本	日期	变更	作者
v0.1	2026-09-22	初版。基于 Speech/Docs/Drive/权限模型/部署形态/红线卡/场景文档（含案例1/2 对标）+ 医疗行业私有化共性经验（已脱敏）推导。10 章节：客户画像（虚构不指名）/4 痛点×能力映射（来源随文标注）/方案概览（架构图+患者触达不内置等诚实边界）/5 用户旅程（护士交班语音转写/医生病历 Docs 协作/科室主任 Space 群组/检查报告 Bot 通知卡/IT 合规管理）+3 张完整卡片 JSON（通知卡 octo/v1、用药确认卡与会诊邀请卡 octo/v2）/部署架构（四区网络+等保三级考量+数据驻留与出网面清单+本地 ASR）/实施路径（合规评估→PoC 单科室→试点→全院）/ROI 框架（不承诺数字）/售前硬口径 16 条（医疗专属 6 条置顶）/已知限制（S-01、ASR-fallback 专项）/文档索引。confidence: medium（能力推导+行业经验推导型，非客户实证）。	twb-knowledge-octo
v0.2	2026-09-22	精修：更新元信息（octo_version→v2026.09+待确认，sensitivity→internal合成案例，source 增加价值卡片）；PS-06 人数/规格数字模糊化（医护人数改为"数千人规模"，信息科人数改为"十余人规模"，部署统一使用"最小化单机部署"/"Kubernetes高可用集群部署"，删除具体核数/内存/台数）；术语统一（Bot=智能对话机器人，Agent=可编排智能代理，知识库=企业知识管理）；新增第11章客户价值亮点（核心价值亮点/可复用售前话术/关联阅读/相似行业参考）	twb-knowledge-octo