OpenAI将ChatGPT接入Epic与九大医疗数据库：AI助手开始进入临床核心工作流

AI 前沿观察 · 每日精选

AI FRONTIER

OpenAI将ChatGPT接入Epic与九大医疗数据库：AI助手开始进入临床核心工作流

AI 前沿观察 · 临床工作流专题

过去，医生使用通用AI助手时，常常需要在电子病历、医学数据库和聊天窗口之间来回切换，再把零散信息拼成完整判断。现在，OpenAI正试图把这段“手工搬运”压缩掉。

9月1日，OpenAI宣布为ChatGPT for Healthcare推出两项连接能力：一项接入Epic电子健康记录系统，另一项通过Healthcare Public Data插件连接九个官方公共医疗数据源。前者面向患者个体资料，后者面向研究、药品、医保与医疗机构等公共信息；在受支持的部署中，ChatGPT还可以嵌入电子病历界面，让临床人员不必离开患者病历就能调用AI。OpenAI官方公告

这不是简单地给聊天机器人增加几个搜索入口。更值得关注的变化是：AI助手正在从临床工作流外围的问答工具，向电子病历这一核心信息入口靠近。

两条数据通道，解决两类问题

首先需要澄清一个容易产生误解的地方：Epic集成和Healthcare Public Data插件是两个相互独立的产品，并不是把患者病历汇入公共数据库。

Epic集成连接的是医疗机构内部、且当前用户有权查看的患者资料。根据OpenAI披露的信息，临床人员可以让ChatGPT协助梳理病史、近期变化、实验室结果、用药情况以及专科记录，并查看支撑回答的原始信息。TechCrunch的报道还提到，在部分部署中，它可以用于就诊前审阅以及构建临床时间线。TechCrunch报道

另一条通道连接的是九个官方公共来源：PubMed、ClinicalTrials.gov、DailyMed、RxNorm、openFDA、CMS Coverage、CMS Open Data、Medicare Care Compare和NPI Registry。它们大体覆盖医学论文、临床试验、药品说明与标准名称、监管信息、医保政策、医疗机构质量和执业者登记等资料。Healthcare Public Data使用说明

这意味着，医生可以在同一个对话环境里处理两类上下文：一类是“这位患者发生了什么”，另一类是“外部医学与政策资料怎么说”。例如，资料显示公共数据插件可用于核查临床试验资格、药物标识符、医保覆盖政策版本及医疗服务提供者记录。

需要强调的是，上述内容是产品能力和可支持场景，并不等于ChatGPT能够自行完成临床诊断或治疗决策。

真正的产品跃迁，是进入病历界面

医疗AI并不缺少演示效果出色的问答系统，长期难点在于它们能否进入医生每天实际使用的软件，并在不增加额外操作负担的情况下提供帮助。

此次变化的重要性，就体现在“无需离开患者病历界面”这一点上。过去，即使模型能够总结医学知识，临床人员仍可能需要复制病历、切换窗口、重新解释上下文。现在，在受支持的部署中，患者资料可以在既有权限框架内被调用，AI由此获得了更接近真实临床任务的上下文。

基于资料的推断是：产品竞争的重点可能正在从“谁能回答医疗问题”，转向“谁能以更低摩擦嵌入临床流程”。模型能力仍然重要，但身份认证、权限继承、信息回引以及部署治理，也将共同决定系统能否真正被医院采用。

这种嵌入还有另一层价值。电子病历中的有效信息通常分散在多次就诊、检验结果、药物清单和不同专科记录中。AI若能把这些内容组织成可核查的时间线或摘要，潜在价值未必是替医生作决定，而是降低信息整理成本，把医生的注意力留给判断、沟通和处置。

只读，是限制，也是现阶段的安全边界

OpenAI帮助文档给出了清晰边界：Epic连接目前为只读，不能修改病历、下医嘱或向患者发送消息，也不能绕过原有电子病历权限。临床人员只能访问其Epic账户本来就获准查看的资料；医院管理员还需要配置FHIR R4基础URL、OAuth客户端信息和获批权限范围。Epic插件使用说明

因此，这套系统当前更接近“读取、检索、归纳与辅助核对”，而不是能够直接执行医疗操作的自主代理。只读设计会限制自动化程度，却也把潜在影响控制在较小范围：模型的回答不会直接写回正式病历，更不会自动形成医嘱。

公共数据插件同样是只读工具，只检索公开信息，不读取患者病历。官方文档明确要求，用户不得在公共数据检索中提交患者姓名、出生日期、病历号或其他受保护健康信息。插件安装、九个应用的连接和权限启用彼此独立，管理员可以按角色控制访问。

此外，Epic集成并非面向所有ChatGPT用户。官方资料显示，它适用于获批的ChatGPT for Healthcare工作区和启用HIPAA相关功能的Enterprise工作区，不向个人ChatGPT for Clinicians账户开放；符合条件的美国个人临床用户则可以使用公共医疗数据插件。

99.1%安全，不等于临床上可以放手使用

OpenAI公布了一项内部评估：医生针对27类临床用例进行了4,363次评分，其中99.1%的回答被评为安全。OpenAI官方公告

这是一个值得记录的产品测试结果，但必须准确理解其性质：它来自厂商披露的内部评估，资料没有提供足够信息让外界独立验证其在不同医院、科室和患者人群中的实际表现。安全评分也不等同于回答完全正确，更不代表系统已经能够承担临床责任。

TechCrunch对此提出了现实提醒：医疗场景容错率很低，即使不安全回答所占比例很小，落到具体患者身上仍可能造成伤害。尤其当AI生成的摘要语气流畅、结构完整时，人更容易忽略遗漏、过期资料或错误关联。

官方文档因此仍要求临床人员核对原始病历，并由医务人员对医疗决策负责。换句话说，信息回引不是装饰功能，而是这类产品能否安全使用的核心机制。医生需要知道答案依据了哪项化验、哪次记录或哪份外部资料，并能迅速回到原文复核。

我们的观点是：衡量临床AI不能只看平均安全率，还应关注高风险错误如何被发现、权限如何审计、资料更新是否及时，以及用户在多大程度上会对系统产生自动化依赖。这些问题在现有来源中尚无完整答案，也将是后续部署最值得观察的部分。

医疗AI的下一阶段：上下文、治理与责任

九大公共数据库的意义，并不只是数量达到“九个”。更关键的是，它们把论文、试验、药品、监管、医保和机构信息组织到同一个查询入口。Epic则补上患者个体上下文。两者结合，形成了“患者记录—外部证据—人工复核”的基本信息链条。

但连接数据并不会自动消除风险。不同来源的更新频率、定义和适用范围可能不同；患者是否符合某项试验，也不能仅靠表面条件匹配；医保覆盖政策更可能受到时间、地区和具体方案影响。AI能够缩短查找路径，却不能替代对原始资料及适用条件的核验。

进一步推断：医院评估此类工具时，重点可能不再只是模型回答得像不像专家，而会转向三个更具体的问题：它能读取什么、回答依据是什么、出错后由谁发现并负责。对供应商而言，进入病历系统意味着获得更高价值的上下文；与此同时，也意味着必须接受更严格的权限、安全和治理要求。

结语

OpenAI接入Epic与九大官方医疗数据库，标志着ChatGPT for Healthcare向临床核心工作流迈出了一步。它现在能够在受控环境中读取获授权病历、查询公共医疗资料，并在部分部署里直接出现在电子病历界面中。

不过，这一步的准确含义不是“AI开始替医生看病”，而是“AI开始更贴近医生获取和整理信息的现场”。目前的只读权限、原始资料回引和人工责任边界，都说明它仍然是一套辅助系统。

真正决定这次变化价值的，不会只是一次漂亮的演示或一个安全率数字，而是它能否在真实医院中持续减少信息负担，同时让每个结论保持可追溯、可复核、可问责。AI已经走到诊室门内；至于能否成为可靠的临床基础设施，接下来的部署实践才是关键。

OpenAI将ChatGPT接入Epic与九大医疗数据库：AI助手开始进入临床核心工作流

两条数据通道，解决两类问题

真正的产品跃迁，是进入病历界面

只读，是限制，也是现阶段的安全边界

99.1%安全，不等于临床上可以放手使用

医疗AI的下一阶段：上下文、治理与责任

结语

参考资料