Epic EHR 接入 ChatGPT：医疗团队部署与治理指南

医疗团队如今可以把 Epic EHR（电子健康记录）中已获授权的上下文直接带入 ChatGPT，无需再手工复制病历数据。OpenAI 于 2026 年 9 月 1 日上线了这项连接，同时推出 9 个公共医疗数据应用。Epic 连接仅支持读取，并沿用每位临床医生现有的访问权限；它既可在 ChatGPT 内使用，也能在受支持的部署中嵌入 EHR 工作流。这样一来，医生不必再花大量时间拼接病程记录、检验结果、用药信息和专科更新。但有一条底线不能动：任何答案都只是草稿，必须由临床医生核对原始病历、相关日期以及可能缺失的信息后才能采用。

Epic EHR 接入 ChatGPT 的简明答案：建立两条受控数据通道

在此次发布中，“连接 EHR”指的是为获批的组织工作区配置 OpenAI 的 Epic 插件，并不意味着 ChatGPT 可以接入所有 EHR。插件只会调取当前登录的 Epic 用户原本就有权查看的病历信息，不能回写病历、下医嘱、向患者发送消息，也不会扩大病历权限。OpenAI 的 Epic 配置指南是判断资格与配置方式的权威依据。

另一条通道是 Healthcare Public Data 插件。它包含 9 个只读应用，可检索 PubMed、ClinicalTrials.gov、DailyMed、RxNorm、openFDA、CMS Coverage、CMS Open Data、Medicare Care Compare 和 NPI Registry。这些应用查找的是公共信息，而非患者病历。患者姓名、病历号、出生日期、会员编号以及其他身份标识都不应出现在此类检索中。

可以把这套架构想成通往同一间临床工作室的两扇门：Epic 这扇门使用每位临床医生自己的工牌开启，公共数据这扇门则通向一座资料库。即使工作区已经签署商业伙伴协议（BAA），把患者标识符带进资料库依然是走错了门。

一份经得起安全审查的部署清单

真正合格的部署成果，不是一张“答案很好用”的截图，而是一条完整证据链：哪些数据符合使用条件、谁可以访问、权限如何收紧、临床医生核验了什么，以及上下文不完整时系统如何处理。

1. 先确认工作区与法律资格

先形成书面的“上线”或“不上线”决定。Epic 插件仅面向获批的 ChatGPT for Healthcare 和启用 HIPAA 的 Enterprise 工作区，具体还受组织上线安排与 Epic 配置限制；个人版 ChatGPT for Clinicians 账户无法使用。

在受保护健康信息（PHI）进入工作流之前，需要确认适用的商业伙伴协议（BAA）——也就是规范 PHI 受监管处理方式的合同——以及符合条件的工作区和功能、Epic 授权，并核实预定用途所需的其他协议。功能可用并不等于自动纳入 BAA。OpenAI 的 HIPAA 合规功能清单划分得非常具体，其中明确指出，“增强记忆”不受 BAA 覆盖；即使管理员启用了它，也不应向该功能提供 PHI。

审批记录应明确 4 位责任人：工作区负责人、Epic 管理员、隐私或安全负责人，以及有权叫停试点的临床负责人。

2. 连接之前，先盘点全部数据源

建立一张来源矩阵，每个系统或应用单列一行。对于 Epic，要记录环境、获批的 FHIR 资源、患者范围、用户角色，以及 ChatGPT 是在独立工作区运行，还是采用受支持的 EHR 内嵌布局。FHIR 是请求健康记录资源所使用的标准接口地址；它只是一扇入口，本身不代表授权。

对于公共数据，应分别审批这 9 个应用。插件可用、应用启用、角色授权和用户连接是彼此独立的开关；安装插件并不会自动连接所有应用。公共数据配置指南还提醒，查询请求可能会离开工作区，交由数据源运营机构处理，因此数据保留和数据驻留假设也要单独审查。

矩阵中必须划出清晰红线：Epic 可以承载已获授权的患者上下文，公共数据检索则不得包含 PHI。如果某项工作流同时需要两类信息，应先以通用、不含 PHI 的方式提出公共问题，再由临床医生在获批的患者上下文工作流中，将带有引用的公共答案与病历进行比对。

3. 将访问权限绑定到真实身份

工作区管理员和 Epic 管理员需要使用组织的 FHIR R4 基础 URL、OAuth 客户端 ID、OAuth 客户端密钥，以及配置过程中显示的准确回调 URL 来设置 EHR 应用。OAuth 是一套登录授权交接机制，Epic 可借此授予访问权限，而无需把密码放进聊天中。

随后，每位临床医生都要连接自己的 Epic 账户。为某个角色安装插件，并不等于替任何人连接账户，也不会扩大该用户在 Epic 中的权限。凭据、客户端密钥和访问令牌必须留在获批的配置与登录流程内，绝不能放进 ChatGPT 对话或 Codex 任务。

临床试点开始前，要覆盖新员工入职、角色变更和员工离职三类测试。SAML 单点登录与 SCIM 账户配置可以管理工作区身份生命周期，但验收测试还必须证明：当用户被移出某个 Epic 角色后，其通过 ChatGPT 访问相应病历的权限也会随之消失。

4. 把最小权限落实到具体配置

“只读”确实能降低风险，却不等于最小权限。如果角色与授权范围过宽，只读用户依然可能看到不该看到的信息。

Epic 插件只能对获批角色设为 Available 或 Installed。每一项 OAuth scope 都要与 Epic 管理员共同核查。OpenAI 列出的常见读取范围包括患者、诊断状况、过敏信息、药物申请与配发、观察结果、文档、诊断报告、就诊记录及相关二进制文件。只有获批工作流确有需要时，才增加预约、操作、免疫接种或照护计划等范围。

公共数据应用也应逐个按需授权给相应角色。药学团队可能需要 DailyMed 和 RxNorm，研究团队可能需要 PubMed 和 ClinicalTrials.gov；两者都不应因此自动获得所有 CMS 数据集。每项权限由谁批准、何时再次复核，都要留档。

5. 让临床核验成为输出的一部分

每个患者上下文模板都应强制包含 5 项内容：

1. 发生了什么变化。
2. 支撑结论的病历条目。
3. 相关日期。
4. 缺失或无法获取的上下文。
5. 临床医生的决定与签署确认。

OpenAI 表示，Epic 返回的回答会指向相应病历依据，并要求临床医生在依赖答案前查看底层记录和相关日期。核对来源本身就是关键控制措施；如果一份摘要看起来很完整，却无法追溯到病历依据，就应判定审核不通过。

OpenAI 报告称，在 27 个 EHR 连接用例中，医生将 4,363 条回答中的 99.1% 评为安全。这是有价值的评估证据，但并不意味着可以跳过本地验证。“安全”也不等同于对某位患者而言完整、最新或正确。

6. 留存审计证据；上下文缺失时默认关闭

应用对话可通过 Compliance API 提供给治理系统导出，应用调用则会记录在 Compliance Logs 中。上线前，先验证审计人员需要的字段是否确实存在。证据包至少要把用户、角色、应用、时间、来源类别、用例模板、审核结果和异常工单串联起来，同时避免把超出审计目的所需的 PHI 再复制到另一个系统。

回退机制必须在工作流中清楚可见。实际可用的数据取决于 Epic 配置、获批资源以及用户现有的病历权限。当患者记录或必要资源缺失时，输出应明确标注“上下文缺失”，指出缺少哪一类来源，并引导临床医生回到 Epic 查看；不能凭记忆补空，也不能用公共数据检索来填补。

如果公共数据源没有返回结果，应缩小或调整不含 PHI 的查询，检查该来源声明的覆盖范围；若提供方暂时不可用或正在限流，则稍后再试。没有结果，并不等于相关研究、警示、政策或医疗服务提供者记录不存在。

全面铺开之前，先算清商业账

OpenAI 尚未公布 ChatGPT for Healthcare 的统一标价。价格取决于组织规模和部署需求，Enterprise 工作区的高级功能用量则来自合同级共享额度池。因此，可信的商业论证必须建立在正式报价和实测试点上，而不是泛泛比较单席位成本。

可使用下面的公式：

monthly workflow value = completed reviews x verified minutes saved x loaded clinician cost / 60

然后扣除全部运营成本：企业合同、Epic 与 OAuth 配置、安全审查、工作流设计、培训、临床验证、审计运营和支持。同时衡量经纠正的摘要数量与升级处理次数，而不能只看节省了多少时间。如果更快生成的草稿反而增加了核验工作，就不算节省。

邻近市场提供了一个可参考的价格锚点。Freed 官方定价显示，其包含患者上下文和 EHR 推送功能的 Premier 临床医生套餐为每月 $119，按年付费则为每月 $104。这与医疗系统级部署并非同类价格，但至少说明，临床医生已经愿意为“整合就诊上下文”这项工作付费。ChatGPT 的经济性问题在于：一个受治理的工作区能否在获批的临床、研究和运营流程中完成这项工作，同时避免再引入一个割裂的工具。

7 个用例：按潜在运营回报排序

1. 复杂患者的就诊前复核

面对病历很长的患者，基层或专科临床医生可以询问：上次就诊后发生了哪些变化、哪些近期检验结果值得复核、用药是否调整，以及哪些专科建议仍未落实。ChatGPT 可以根据已获授权的病程记录、药物、诊断状况、就诊记录和检验结果整理出简报草稿，并回链至病历依据。

这一用例排在首位，是因为每次相关预约前都会重复发生，而且占用成本高昂的临床注意力。真正有效的工作流不是“把全部内容总结一遍”，而是生成一份简短的变化简报，附上日期、来源链接，并明确列出上下文缺失项。

2. 轮班与诊疗服务交接

负责住院患者的医生或代班临床医生可以针对已获授权的患者，请求生成近期就诊、当前问题、用药变化和未完成随访的时间线。接手的临床医生在接受交接前，仍需逐项对照病历核验所有重要内容。

当照护从一人转交给另一人时，它能提供更一致的起点；相应的失效模式也很清楚：如果某类病程记录或就诊信息不在获批范围内，交接内容必须指出缺口，而不是让人误以为病历完整无缺。

3. 用药变更复核

药学或临床团队可以对照 Epic 中当前的药物申请、配发记录、过敏信息、近期检验结果和相关病程记录，再单独查询 DailyMed 或 RxNorm，获取公共药品标签与标识符信息。患者数据通道回答“这份获授权病历里有什么？”，公共数据通道回答“官方资料怎么说？”

这样的分工既能减少在标签页之间来回切换，也能守住 PHI 与公共查询之间的边界。它不会代替人决定剂量、可替换性、处方集覆盖或治疗方案，这些判断仍由具备资质的临床人员负责。

4. 转诊与未解决事项跟踪

照护协调员可以要求系统从已获授权的记录中找出近期转诊、专科建议和待完成的随访，并将其整理成行动清单，为每一项附上支撑病程记录和日期。

这样可以减少在冗长病历中手工查找的时间。但协调员仍须确认相关任务是否已在其他系统中完成，因为连接的资源未必覆盖每一次排期、消息沟通或外部医疗事件。

5. 事先授权证据准备

授权团队可以利用已获授权的病历上下文，起草支持申请所需的患者具体事实，再通过一条独立、不含 PHI 的公共查询，在 CMS Coverage 中查找相关政策版本。任何材料提交之前，均由人工审核人员核对两部分内容。

这可以压缩资料收集与起草所需的时间，但无法判定个人保障范围。覆盖政策来源本身存在范围和版本限制，最终申请必须遵循支付方的现行规则。尚未准备好采用企业级 EHR 连接的小型诊所，或许能先从 AI 驱动的牙科诊所自动化 中介绍的简化工作流获得更直接的价值。

6. 临床试验与证据初筛

研究团队可以使用 ClinicalTrials.gov 查找正在招募的研究并比较入组标准，同时通过 PubMed 补充相关研究。随后，临床医生可以把这些公开标准与已获授权的病历进行比对，而无需将患者标识符放入公共数据查询。

它的价值在于更快完成分散来源的第一轮筛查。不过，试验状态和入组资格仍须向研究团队确认，而且来源记录可能发生变化。

7. 人群健康项目规划

规划糖尿病、心脏疾病或用药安全项目时，人群健康团队可以汇集公共研究、活跃试验、Medicare 覆盖信息、机构指标以及医疗服务提供者记录。这样无需在公共应用中使用患者级数据，也能为项目负责人制作一份来源清晰的简报。

它对即时回报的贡献排名较低，因为这类工作按阶段开展，并非每次就诊都会发生；但它有望提升研究与运营规划的质量和可追溯性。

围绕这项连接，值得打造的 2 款产品

1. 最值得投入的方向：EHR 部署证据控制台

可以为医疗系统 IT、隐私与临床治理团队打造一个控制平面，也就是统一管理部署的位置。它负责盘点获批数据源、角色、Epic scopes、测试用例、异常和审计导出，并为每次工作流发布生成可直接用于审查的证据包。

对这样一个细分基础设施任务而言，需求信号出奇地商业化。关键词“EHR integration”在美国每月约有 590 次搜索，单次点击成本为 $42.25；“EHR integration services”每月约有 140 次搜索，单次点击成本为 $80.68，页首竞价最高可达 $78.96。买家已经在主动寻找帮助，供应商也愿意投入高价触达他们。

最小可销售版本只需支持 1 个 Epic 环境和 1 个 ChatGPT 工作区。它能够导入或记录已批准的 FHIR scopes 与基于角色的访问控制（RBAC）矩阵，运行固定的验收测试库，保存签署确认，并导出异常报告。必须坦诚的是，企业销售周期很长，平台也在持续变化。这款产品不能取代 BAA、本地风险分析或临床问责；真正的护城河应来自高质量的证据模型和实施资料库，而不是一个徒有其表的仪表盘。

2. 带来源核验的就诊前工作流套件

可以面向复杂照护诊所，打造一套可复用的 ChatGPT for Healthcare 模板，并配套审核协议。每份简报都应在临床医生签署前，列出变化、用药、检验结果、随访、病历引用、日期和“上下文缺失”区块。

关键词“AI medical assistant”在美国每月约有 140 次搜索，具有商业意图，单次点击成本为 $24.01。Freed 每月 $119 的 Premier 套餐包含就诊摘要、患者上下文和 EHR 推送，这直接证明了市场愿意为这类任务付费，尽管它与这里的部署模式并不完全相同。

MVP 可以由 3 套专科模板、1 张角色图、1 份来源与日期核验清单，以及 1 张试点评分卡组成。初期应把它作为部署服务包销售，而非独立软件。难点在于如何形成壁垒：模板很容易被复制，只有叠加变更管理、验证和专科治理后，这项工作才真正具备价值。

这项连接解决不了什么

它非常适合做信息综合与复核，却不适合自主作出医疗决定或在后台静默执行工作流。

• 它无法连接所有 EHR。目前有文档支持的患者记录集成对象是 Epic。
• 它不能回写病历、下医嘱或向患者发送消息。
• 它不保证上下文完整。实际可用内容取决于配置、获批资源和用户权限。
• 它不会因为签署了 BAA，就让所有功能或第三方服务自动获得一揽子批准。
• 它不会让公共数据集变成针对具体患者、完整无缺或足以独立决定临床处置的资料。
• 它不会免除临床医生核对原始病历与日期的责任。
• 它也不能证明现有审计字段已经满足组织的证据要求。

这里的隐私逻辑，与其他需要大量上下文的 ChatGPT 功能并无二致：访问越充分，功能越有用，因此权限设计与数据保留边界只会更重要，不会更次要。ChatGPT 计算机使用历史与隐私 从另一个高上下文场景分析了这种取舍。

99.1% 的安全评分，以及 5 个受测公共数据源分别高于 93% 的“良好或更佳”准确率，都是令人鼓舞的评估结果。但它们不能替代针对本组织角色、资源、专科与失效场景开展的本地测试。

常见问题

EHR 集成是什么意思？

EHR 集成，是把电子健康记录连接到另一个获批系统，使已获授权的数据可以在两者之间流转。在此次 ChatGPT 发布中，有文档支持的 EHR 路径是只读 Epic 插件，并且会沿用每位用户现有的 Epic 权限。

如何完成 EHR 集成？

对于 ChatGPT，第一步是确认工作区属于获批的 ChatGPT for Healthcare 或启用 HIPAA 的 Enterprise 工作区，并具备必要的法律覆盖。之后与 OpenAI 和 Epic 管理员协作，使用 FHIR R4 URL 与 OAuth 信息配置工作区专用 EHR 应用，复核 scopes 和角色，发布应用，再由每位获批用户连接自己的 Epic 账户。

EHR 集成服务包括什么？

这类实施服务负责连接、保护、测试和运营 EHR 与另一系统之间的数据流。对于本次部署，有价值的服务包括 Epic 应用配置、身份设置、scope 与 RBAC 设计、临床验证、审计映射、培训和异常处理。

EHR 面临的三大关键挑战是什么？

对于连接 EHR 的 AI 工作流，最重要的三大挑战是上下文不完整、访问权限过宽和输出未经核验。对应的务实控制措施，是显示明确的上下文缺失状态、采用最小权限角色与 scopes，并由临床医生核对底层记录和日期。

本周一就做这件事

召集首席医疗信息官（CMIO）、隐私负责人、Epic 管理员、工作区负责人和 2 位一线临床医生，安排一次联合工作会议。选定 1 项反复发生的复核任务，只映射它真正需要的数据；先用获批的测试或培训记录进行验证，测试集应包含完整病历、受限资源、登录过期和结果缺失等情形。在输出能够明确指出缺失上下文、来源链接通过复核、访问权限按预期失效，并且审计导出能回答谁在何时访问了什么之前，不要扩大试点。

如果您的组织希望落地上述任何一种受治理的医疗集成，可查看 AI 生产系统。