Brown Health：先治理，再让临床 AI 上线

一个不断扩张的医疗系统，和一个越来越难维持的文档流程

Brown Health 是罗德岛州最大的医疗系统，服务约百万人口，承担着该地区的核心医疗保障功能。自 2024 年起，这家机构经历了一轮显著扩张——收购两家马萨诸塞州医院、合并一家大型学术医师执业组织，同时统一电子病历和核心运营平台。规模在变大，但压力也在同步放大：财务约束持续收紧，劳动力短缺加剧，老龄化患者越来越多地依赖急诊科获取在其他渠道无法得到的医疗服务。

在这些结构性压力之上，最直接的痛点是临床文档。急诊科医生每天面对大量急性需求患者，需要在诊疗过程中同步记录、在下班后补齐文档。Landman 在官方案例中引用行业研究数据指出，某些专科的医生倦怠率可达 40% 甚至更高——这是行业层面的统计，并非 Brown Health 内部测量值，但它说明了文档负担在临床倦怠中的结构性角色。过去几年，Brown Health 尝试过多种方案——人工抄录员、语音转写工具、模板化记录——每种都只提供了边际改善，没有从根本上改变诊疗与记录并行的工作模式。

Landman 在官方案例中的表述很直接：机构面临持续的财务压力，同时希望达到甚至超越高质量医疗服务的期望。AI 被视为更广泛变革中的一个关键推动因素，而不是一个独立的技术项目。这个定位决定了后续的实施路径——不是先建平台再找场景，而是从临床人员负担最重的环节开始。

环境式记录如何进入急诊科

急诊科医生 Anthony Napoli 在官方案例中描述了一个典型场景：一位老年患者在走廊里低声描述头晕、心悸和心率升高的症状。过去，他需要一边判断病情、一边速记细节、一边保持与患者的交流——在嘈杂的急诊环境中，这种多任务并行几乎不可避免地导致信息遗漏。

Dragon Copilot 的介入方式是"环境式记录"：在获得患者许可后，工具在后台捕捉医患对话，并生成结构化临床记录。官方案例描述了 Landman 本人的使用流程——在手机上启动一个会话、将手机放在台面上，约 20 秒后一份草稿记录就出现在电子病历中。Napoli 的描述是，"文档记录与患者交流并行发生"，他可以把注意力集中在判断病情和倾听患者上。这不是一个需要医生学习新界面的独立系统，而是嵌入到临床人员已经使用的工作环境中。

早期试点覆盖了 420 名多专科临床人员，官方表述试点"产出了强结果"（produced strong results），并有一份 Brown Health 2026 年春季内部分析作为支撑（见官方案例脚注），但该内部分析的具体内容未公开。Napoli 推动急诊医生团队成为全国最早全面启用环境式记录的临床科室之一。截至官方案例发布时，超过 400 名临床人员在使用 Dragon Copilot，官方表述是"减少记录负担和下班后工作"。需要注意的是，官方材料没有披露具体的时间节省量、文档编辑比例或临床准确率数据——"400+ 活跃用户"是一个部署规模指标，不是效果指标。420 名试点人员与 400+ 活跃用户之间的关系（是否为同一批人、是否存在时序递进）官方未明确说明。

从记录工具到运营智能体：24 个场景如何展开

临床记录只是第一步。Brown Health 在 2025 年 5 月迎来了首任 AI 与信息服务总监 Matthew Butler，他的评估是机构此前"并没有一个 AI 战略"。Brown Health 随后建立了 AI 卓越中心，前六个月的重心不是快速上线更多工具，而是建立治理框架——制定政策、定义可接受用途、构建负责任 AI 框架，并争取各部门领导的支持。值得注意的是，团队使用了 Microsoft 365 Copilot 中的 Researcher agent 来加速 AI 治理政策的制定，官方案例称这使得政策草案在 4 个月内完成，而非原先预期的 1 年。

在治理框架就位后，团队使用 Copilot Studio 构建了 24 个以上的医疗与运营智能体。官方案例提到的场景包括急诊指导、路由、翻译、排班和运营流程。Butler 对工具集成理念的解释是：AI 只有在能够有意义地融入人们实际工作的地方才能发挥作用——员工已经广泛使用 Microsoft 产品，因此 Microsoft 365 Copilot 和 Copilot Studio 成为自然的起点。

但"24 个以上智能体"这个数字需要谨慎理解。官方案例没有区分这些智能体中有多少已进入生产环境、多少仍在试点或概念验证阶段，也没有披露各智能体的使用频率、权限设计或审计机制。这是一个建设规模指标，不能等同于 24 个场景都已产生可量化的业务结果。

按风险决定验证深度：临床 AI 的治理取舍

Brown Health 的 AI 卓越中心采用了一套基于风险的评估方法。官方案例的表述是：每个用例都根据临床和运营风险及潜在价值进行评估；高风险工具——特别是可能影响临床决策的工具——需要更深入的准确性测试和明确的性能指标。数据科学家 Ali Chambers 在官方案例中有独立引述，负责风险评估框架的具体执行，包括多阶段测试流程（原型→结构化测试→试点）。

这意味着不同类型的 AI 应用走不同的验证路径。一个帮助员工查询医院政策的知识助手，和一个在急诊分诊中提供指导建议的智能体，面对的验证要求完全不同。前者可以快速试点，后者需要更严格的准确性测试。这种分级策略在医疗 AI 领域并不罕见，但 Brown Health 的具体分级标准、通过门槛和回退方案，官方材料未披露。

在环境式记录这个具体场景中，人机分工的边界相对清晰：AI 负责捕捉对话并生成结构化草稿，临床人员负责复核、编辑和签署。记录在临床人员确认之前不会进入正式病历。官方案例还提到培训员工以"审慎使用者"（suspicious user）的心态批判性地使用 AI 输出。但官方材料没有披露编辑比例（即临床人员平均需要修改多少内容）、记录被拒绝或重写的频率，以及当 AI 生成的记录出现重大错误时的具体升级流程。

对于 24 个以上智能体，官方材料同样没有披露各智能体的权限边界、数据访问范围和异常回退方式。在医疗场景中，这些细节对于评估系统的安全性至关重要——一个翻译辅助智能体和一个急诊分诊指导智能体，需要完全不同的权限设计和错误容忍度。

两个部署规模数字，和它们不能回答的问题

Brown Health 官方案例披露了两个核心数字：超过 400 名临床人员使用 Dragon Copilot，以及 24 个以上已构建的 AI 智能体。这两个数字需要分别理解其口径和局限。

"400+ 临床人员"是活跃用户规模，官方表述是这些用户"减少了记录负担和下班后工作"。但这是一个定性描述，不是量化的效率指标。官方没有披露每次访视节省的文档时间、下班后工作减少的小时数、或者与使用前的对比基线。官方脚注提及 Brown Health 2026 年春季内部分析，但该分析内容未公开，无法据此评估效果量级。

"24+ 智能体"是建设规模，涵盖急诊指导、路由、翻译、排班和运营等场景。官方没有区分已上线和在建的智能体数量，没有披露各智能体的使用频率和业务结果，也没有提供任何智能体的准确率或用户满意度数据。

换句话说，这个案例展示的是一个部署路径和治理框架，而不是一组经过验证的效果数据。对于评估 Brown Health 的 AI 投入是否产生了预期回报，现有公开信息不足以得出结论。

对其他医疗系统的迁移判断

DataHub 判断：Brown Health 案例中最值得其他医疗机构关注的不是具体的工具选择，而是两个实施决策——从文档负担最重的急诊科切入以降低早期阻力，以及在扩展到更多场景之前先建立治理框架和风险分级方法。这一判断的前提是：机构已经统一了电子病历和核心运营平台（Brown Health 在 AI 部署前完成了这一步），有能力组建专职 AI 治理团队，并且愿意接受早期阶段没有量化 ROI 的不确定性。

DataHub 判断：对于尚未完成信息系统整合的中小型医疗机构，直接复制这个路径的前置成本可能被低估。任何考虑在临床场景部署环境式记录的机构，都应当在试点阶段就建立记录准确率的测量基线、定义临床人员编辑比例的可接受范围、并明确当 AI 生成内容出现系统性偏差时的回退方案——这些是 Brown Health 官方案例中没有披露、但对安全部署不可或缺的环节。