本文要点
- 健康问答从依赖用户临时描述，变为可由用户选择接入 Apple Health 与受支持医疗记录。
- 产品在美国成年用户中开始分批推出，首轮限定 Web、iOS 和四类个人方案。
- 连接数据获得单独的训练与广告用途承诺，但聊天历史仍有独立删除路径。
阅读辅助
先看数字、证据和来源，再读正文。
ChatGPT Health 已开始推出，但首轮范围仅是美国成年登录用户的 Web 与 iOS。
2025-05-12 · OpenAI 发布 HealthBench，用多维评审框架评估模型对健康对话的回应质量。
把健康记录接进通用聊天助手，改变的不是输入框里多了一个附件入口，而是模型可能在多次对话中持续引用一个人的检查结果、用药、活动和睡眠信息。OpenAI 在 2026 年 7 月 23 日开始推出 ChatGPT Health，首次让符合条件的用户选择连接 Apple Health 与受支持的美国医疗记录。
这次发布的可用范围很窄而且边界清楚：对象是美国已登录、年满 18 岁的用户；入口先到 Web 与 iOS；方案覆盖 Free、Go、Plus、Pro；官方使用的是“beginning to roll out”，准确状态是开始分批推出，不是所有合格账户已经同时开通。Codex 暂不支持，Android 和美国以外市场也没有公布上线日期。
产品能力与产品效果需要分开。官方确认了连接对象、可用方案和数据用途政策，但没有公开支持医疗机构的完整名单、医疗记录互操作标准、真实世界错误率或独立临床验证。HealthBench 可以说明 OpenAI 已建立健康对话评测框架，却不能证明 ChatGPT Health 在个人真实病历上已经达到某种临床效果。
对普通用户而言，收益是少做重复说明：一次化验结果可以放回长期健康背景中理解，活动或睡眠变化也可以与过往记录一起讨论。风险同样来自这种连续性。一条被误读、过期或重复的记录若进入上下文，影响的可能不只是一轮回答；用户能否发现、纠正并阻止后续引用，会比单次回答是否流畅更关键。
这次上线到底开放了什么
ChatGPT 原本就承接大量健康问题。OpenAI 自报，每周有超过 3 亿人向 ChatGPT 提出健康相关问题。这个数字描述用户规模，不是问诊次数、付费人数或临床就诊替代量，也没有第三方统计可以独立复核。它能说明健康问答已经是高频用途，不能证明回答质量或医疗结果。
Health 增加的是一个独立体验和一组可授权的数据连接。用户可以选择连接 Apple Health，也可以连接“受支持的美国医疗记录”。公告给出的目标场景包括结合历史信息理解检查结果、观察健康变化，以及在对话中减少重复输入。Apple 的隐私说明表明，Health 涉及来自设备、应用与用户选择共享的数据；因此，连接 Apple Health 并不只意味着读取一个静态档案，它可能接触由不同来源持续写入的多类指标。
医疗记录一侧的信息仍不完整。OpenAI 没有在采集到的公告中列出支持的医疗机构、记录类别、数据字段、互操作标准或同步延迟。报道只能写“受支持的美国医疗记录”，不能扩大成“美国所有医院病历”，也不能假定每位用户都能连接自己的就诊机构。
首轮方案与模型也有区分。Free、Go、Plus、Pro 都在此次推出范围内；公告称免费用户可使用 GPT-5.5 Instant，付费用户可使用 GPT-5.6 Sol。页面还表示 GPT-5.6 系列在 HealthBench Professional 上优于 GPT-5.5，但没有给出一组可以跨所有任务概括的统一百分比。因此，不能把“使用更新模型”改写成“医疗准确率提高了某个固定幅度”。
| 维度 | 7 月 23 日已确认状态 | 尚不能据此推断 |
|---|---|---|
| 地区与用户 | 美国、已登录、年满 18 岁 | 全球用户或未成年人已开放 |
| 客户端 | Web 与 iOS 开始推出 | Android 已可用或所有账户已收到入口 |
| 方案 | Free、Go、Plus、Pro | Business、Edu、Enterprise 同步开放 |
| 数据连接 | Apple Health 与受支持的美国医疗记录 | 覆盖所有机构、所有记录类型 |
| Codex | 暂不支持 | Health 数据可被编码 Agent 调用 |
| 发布状态 | 开始分批推出 | 全量 GA 或已经完成覆盖 |
另一个值得注意的自报数字是超过 70%。OpenAI 称，在早期获得访问权限的人群中，超过 70% 的健康相关对话发生在独立 Health 体验之外。这个口径不能写成“70% 用户不用 Health”，因为分母是早期可用人群中的健康对话，统计对象是对话发生位置。它更可能说明健康需求散落在通用聊天中，专门入口并不会自动承接全部敏感信息。
这也提出一个产品边界问题：当用户在普通对话中提到健康信息时，系统如何区分普通聊天、Health 专属数据和已连接来源？官方明确把“使用连接数据的对话”纳入不用于基础模型训练或定向广告的承诺，但普通健康对话何时被识别为使用了连接数据、界面如何提示，仍需要产品实际开放后核查。
数据用途承诺不等于完整隐私答案
OpenAI 对连接数据给出了两项明确承诺。其一，已连接的医疗记录和 Apple Health 信息不用于训练基础模型或投放定向广告。其二，使用这些连接数据的对话也在同一政策范围内。这里的时态是当前政策状态，不应写成“以后绝不会改变”；若政策、产品或适用范围变化，仍需看后续条款与通知。
“不用于训练或广告”也不能简化成“不处理数据”。为了同步、检索并在回答中调用，系统必然需要处理相关信息；发布材料还明确存在保留与删除过程。用户真正需要知道的是：谁能访问、哪些子系统生成副本、模型回答是否记录引用来源、错误如何更正、撤回授权后哪些对象被删除，以及每一步有没有可核验的日志。
删除规则尤其容易被误读。用户断开某一 Health 数据来源后，从该来源同步的数据会在 30 天内从 OpenAI 系统删除。这句话同时限定了触发动作、删除对象和期限：
- 触发动作是断开具体数据来源，不是停止使用一段时间。
- 删除对象是该来源同步的数据，不是所有健康相关内容。
- 期限是 30 天内，不是点击断开后即时消失。
- 已经进入 ChatGPT 聊天历史的信息不会随来源同步数据一起自动删除。
最后一点决定了真实操作成本。如果一条化验结果已经被引用进若干对话，断开医院记录连接只会启动来源同步数据的删除流程；用户还要删除包含这些信息的相应对话，聊天历史中的副本才会按另一条路径处理。公告没有展开备份、副本、审计记录和机构侧原始记录的保留机制，因此不能进一步承诺“所有副本会在同一时间永久消失”。
| 用户动作 | 官方明确会发生什么 | 仍需用户留意什么 |
|---|---|---|
| 授权连接 | ChatGPT 可调用相应 Apple Health 或受支持医疗记录 | 授权粒度、字段范围和同步频率尚待实测 |
| 继续对话 | 连接信息可进入回答和聊天上下文 | 错误信息可能被后续对话继续引用 |
| 断开来源 | 该来源同步数据在 30 天内从 OpenAI 系统删除 | 聊天历史中的既有信息不会自动随之删除 |
| 删除对话 | 对话中的既有信息进入相应删除路径 | 是否覆盖导出、副本和审计日志需看具体规则 |
Apple Health 的资料在这里仅能提供产品背景：其数据可能来自设备、应用和用户选择的共享，并受 Apple 自身的隐私与权限机制约束。它不能证明 OpenAI 读取了哪些字段，也不能替 OpenAI 说明撤回授权后的服务端处理。两家产品的权限与删除机制必须分别核对，不能因为入口从 iOS 发起就把责任全部归给 Apple。
健康上下文的难题在纠错，不只在回答
通用模型处理一次健康问题时，用户可以在当轮发现明显误解并重新描述。接入纵向记录后，错误可能来自更多环节：机构记录本身填错，设备测量存在噪声，同一项目单位不一致，旧药物没有标停用，身份匹配把记录关联错，或模型把观察值误当诊断结论。任何一层出错，都可能被后续回答当成“历史事实”。
因此，理想界面不应只显示“已连接”，还应说明每个结论引用了哪条记录、记录来自哪个机构或设备、采集时间是什么、是否经过用户确认。若模型说“你的指标持续上升”，用户需要能展开查看使用了哪些数值，而不是只能相信一段生成式总结。
纠错机制也要区分来源。医疗机构记录出错，通常需要回到机构修正原始记录；Apple Health 中的设备数据可能需要调整来源优先级或删除特定数据；模型对正确记录的解释出错，则需要在对话层纠正。单一“这不对”按钮无法替代三种不同责任路径。
HealthBench 为理解 OpenAI 的健康评估思路提供了背景。该基准用多维标准评价模型对健康对话的回应，而不是只比较一个答案字符串。这种方法适合检查完整性、沟通质量和潜在风险，但公开基准仍与真实个人记录不同：真实数据会有缺失、冲突、时间序列、缩写和机构差异，也会出现紧急情况与责任升级问题。基准表现不能直接当作临床有效性证明。
产品后续如果只展示“回答更个性化”，很难衡量安全性。更有价值的指标应包括引用记录准确率、过期信息调用率、冲突记录提示率、紧急风险升级率、用户纠错成功率，以及断开和删除请求是否按时完成。这些指标可能不如模型分数醒目，却更接近长期健康上下文的真实故障模式。
ChatGPT Health 的关键跃迁，是把通用助手从“听用户这次怎么描述”推向“在授权后读取用户过去发生过什么”。长期上下文能减少重复解释，也会让一次数据错误拥有更长的影响半径。健康产品的竞争因此不会只看模型能回答多少问题，还要看系统能否解释自己用了什么数据。
OpenAI 给出的训练、广告和删除承诺是必要基础，但它们解决的是用途边界的一部分。更难的部分是可操作性：用户是否能按机构、数据类型和时间范围授权；是否能看到调用记录；发现错误后能否在来源层和对话层分别纠正；撤回时是否得到完成回执。没有这些能力，“用户可控”容易停留在一个总开关。
超过 3 亿周用户说明健康问答已经进入大众产品规模，恰恰意味着不能把 Health 当成普通新功能观察。即使极低比例的记录关联或解释错误，绝对影响人数也可能很大。厂商自报的 HealthBench 改进值得参考，却不能代替上线后的独立审计和真实世界错误报告。
这次发布最稳妥的结论不是“ChatGPT 已成为医生”，而是通用助手正在成为个人健康信息的新解释层。谁控制解释层，谁就同时承担来源透明、纠错、撤回和风险升级的产品责任。若这些机制跟不上连接能力，更多上下文未必带来更可靠的答案。
从使用到审计，下一步缺什么
首要观察点是数据覆盖。OpenAI 需要公布支持哪些医疗机构、记录类型与互操作标准，并在界面中让用户看到每次同步的时间和范围。只有“受支持的医疗记录”这一概括，无法让用户预判自己的病历是否完整，也无法判断一条缺失记录是机构未支持、字段未同步还是系统错误。
授权粒度将决定产品能否被真正信任。用户可能愿意分享活动和睡眠数据，却不愿开放全部病历；也可能只想让模型查看最近一次检查，而不是多年历史。按机构、记录类型、时间范围和用途拆分授权，比一次性全开更符合健康数据的敏感程度。
纠错与引用需要成为显式功能。每个基于记录的回答最好能标出来源、日期与字段，并允许用户指出“记录错误”“解释错误”或“已过期”。这些反馈不应只修改当前回答，还应明确是否影响后续上下文，以及是否需要回到医疗机构或 Apple Health 更正原始数据。
删除则需要从政策语言变成可验证流程。断开来源后的 30 天内删除、删除相应对话、删除账户是不同操作。产品若能分别显示待删除对象、预计完成日期和完成回执，用户才有机会确认授权确实被撤回，而不是只看到连接按钮从开变关。
最后要看独立质量证据。OpenAI 可以公布按风险分层的真实世界评估，外部研究者也需要能够测试记录冲突、异常单位、过期药物、紧急症状与错误身份关联等场景。ChatGPT Health 是否成功，最终不只由连接数量决定，而要看它能否在信息不完整时承认边界，在风险升高时停止泛化，并把用户引向适当的专业支持。