OpenAI给ChatGPT for Healthcare装上了两个新接口：一个连Epic电子病历系统，一个叫Healthcare Public Data，直连PubMed、CMS Coverage等九个官方医疗数据库。医院终于能让AI在获授权范围内读懂病人从上次就诊到现在的变化,也能一次性查到临床试验入组标准、药品说明书、医保覆盖政策。听起来像是补上了医疗AI最大的一块短板——数据散在不同系统里,谁都要来回切换查。
但翻开权限设置会发现，OpenAI这次给自己留了很大余地：Epic接入是单向只读，不能下医嘱、不能写病历、不能给患者发消息，个人版账号也用不上，只对机构工作区开放。这决定了它现在更像一个帮医生"读病历、划重点"的秘书，离能替医生动手写字的助手还有距离。
只读接入：能看，不能动手
机构要接通Epic，得配置Epic FHIR R4基础URL、OAuth客户端ID和密钥，申请经批准的只读FHIR范围，每位医生还要用自己的Epic账户单独认证一次。这套流程等于把Epic原有的权限体系原样搬进ChatGPT，没有绕开任何一道门。
限制也卡得很死：不能写病历、不能下医嘱、不能发患者消息，个人版ChatGPT for Clinicians用户完全用不了这项功能。医生能拿到的是一份"变化摘要+来源标注"，最终判断还是要回到病历本身核实。
只读是安全阀，也是能力边界。
公共数据插件：好用，但藏着一条原文没提的红线
Healthcare Public Data插件实际连了九个源：PubMed、ClinicalTrials.gov、DailyMed、RxNorm、openFDA、CMS Coverage、CMS Open Data、Medicare Care Compare、NPI Registry——比OpenAI官网通稿里列出的几个更完整。插件本身不额外收费，但每个数据源要管理员单独开通，装了插件不等于九个源全通。
真正的坑在合规层面：这些检索请求会发送到外部数据源运营方那里，不在医院和OpenAI签的BAA保护范围内。换句话说，如果医生在查询里带上患者姓名、病历号，这条信息就跑出了HIPAA合规边界，OpenAI的BAA管不到PubMed或CMS那一端。
- 风险.Public Data插件的检索一旦带入患者身份信息，就脱离了BAA保护，责任边界不清晰。
数字好看，评委是自己请的
OpenAI公布的评估数据确实扎眼：与60个国家、26个医学专科的数百名医生合作，累计评审超过70万条模型回复；针对27个临床用例的4363次评分中，99.1%的回复被判定为安全；针对5个已连接数据源的独立测试，超93%的回复达到"良好"及以上准确度。
这些数字都是真的，但打分的医生是OpenAI自己合作招募的团队，不是独立第三方审计，样本场景数量也有限，不能等同于大规模真实部署后的结果。
横向看行业选择也不一样：微软走的是"环境听写"路线，Dragon Copilot主打问诊现场把对话直接转成结构化病历；谷歌MedLM是模型平台，让机构自己拼应用。OpenAI这次选的是横向工作台——把EHR、公共数据库、SharePoint、Salesforce都接进同一个入口，广度优先，深度目前还很浅，只读、不下医嘱正是这条路线现阶段的代价。
一线的怀疑：省时间，还是换了一层审核
医疗IT社区对这套集成的态度更谨慎。Epic里的病历本身就存在字段不一致、大量复制粘贴痕迹的问题，AI摘要的质量取决于原始数据质量，很可能只是把"翻病历"的负担挪成了"核对AI摘要对不对"，省下的时间不一定像宣传那样多。
美国医学会的政策立场也提到，AI相关的责任应该更多分配给最有能力预防或减轻伤害的一方，不该全压在一线医生身上——这也是为什么目前"只读+人工复核"是唯一被普遍接受的部署方式。相比官方集成，员工绕开审批直接用消费级ChatGPT处理患者信息的"影子AI"，被认为是更紧迫的风险；官方接入至少把使用轨迹留进了审计日志。
首批落地的AdventHealth、Cedars-Sinai、HCA Healthcare等机构接下来怎么用、出不出岔子，比任何自评数字都更值得盯着看。