ChatGPT 现在可以连接电子健康记录（EHR）及其他医疗行业数据，让临床人员在对话中访问可信的患者上下文、医学研究等信息。真正值得关注的变化，不只是“模型能读取更多数据”，而是医疗机构可以把对话式 AI 接入受治理的数据链路，减少临床人员在多个系统之间检索、复制和整理信息的负担。
不过，医疗数据接入不能等同于把整个病历直接发送给模型。身份校验、最小权限、患者范围限制、来源引用、审计记录和人工复核，仍然决定了系统能否进入真实工作流。
从通用问答转向有依据的临床辅助
没有患者上下文时，模型只能给出一般性医学信息。连接可信数据后，临床人员可以围绕当前患者提出更具体的问题，例如：
- 汇总近期就诊、用药和检查结果。
- 从较长的病历中定位与当前症状相关的信息。
- 将患者上下文与机构允许访问的医学研究资料结合起来。
- 为交接、查房或病例讨论准备结构化摘要。
这里的关键是“有依据”。一份临床摘要不仅要给出结论，还应标明数据来自哪次就诊、哪份报告或哪个研究来源。缺少出处的流畅回答很难被复核，也不应成为临床决策的唯一依据。
数据新鲜度同样重要。EHR 中可能同时存在已确认诊断、历史问题、患者自述、待签署记录和被更正的结果。连接层需要保留时间戳、状态和来源系统，而不是把所有字段压成一段失去语境的文本。
安全边界应该放在模型之前
合理的架构通常会在 ChatGPT 与医疗数据源之间设置受控连接层。它负责验证用户身份、检查患者访问关系、过滤字段、记录调用，并只返回完成当前任务所需的数据。
Clinician
|
v
ChatGPT / conversational workflow
|
v
Healthcare data gateway
|-- identity and role checks
|-- patient-scope authorization
|-- field filtering and redaction
|-- audit logging
|-- source metadata
|
+--> EHR
+--> clinical knowledge sources
+--> approved industry data
这条链路至少要回答几个问题：谁在访问、为什么访问、可以访问哪位患者、允许读取哪些数据、响应是否包含敏感字段，以及事后能否还原完整访问记录。
“临床医生可以查看病历”也不意味着模型连接可以默认读取全部病历。药物核对可能需要用药、过敏和近期检验数据，却未必需要完整的心理治疗记录。权限应绑定具体任务和字段，而不只是一个宽泛的“医务人员”角色。
可以这样实践：用网关限制一次患者摘要请求
下面是一个可改造的概念示例。假设机构已经部署内部医疗数据网关，并提供 /v1/patient-context 接口；端点名称和字段是示例，不代表来源中公布了这套 API。运行前需要替换网关地址、访问令牌和患者标识。
网关策略可以写成一份可审查的 YAML：
version: 1
policies:
- name: clinician-patient-summary
allowed_roles:
- attending_clinician
- care_team_member
purpose_of_use: treatment
resources:
- encounters
- medications
- allergies
- observations
denied_fields:
- internal_billing_notes
- unrestricted_free_text
constraints:
require_active_care_relationship: true
maximum_lookback_days: 365
include_source_metadata: true
log_request_and_response_metadata: true
经过授权的客户端可以这样请求最小化上下文：
export HEALTH_GATEWAY='https://health-gateway.example.internal'
export HEALTH_TOKEN='replace-with-a-short-lived-token'
export PATIENT_ID='replace-with-an-authorized-patient-id'
curl --fail-with-body \
--request POST \
--url "$HEALTH_GATEWAY/v1/patient-context" \
--header "Authorization: Bearer $HEALTH_TOKEN" \
--header 'Content-Type: application/json' \
--data "{
\"patient_id\": \"$PATIENT_ID\",
\"purpose_of_use\": \"treatment\",
\"task\": \"medication_review\",
\"requested_resources\": [
\"medications\",
\"allergies\",
\"recent_observations\"
],
\"include_provenance\": true
}"
网关返回给对话工作流的数据也应保持结构化，并携带出处，而不是只返回拼接后的病历文本。例如：
{
"patient_id": "scoped-reference",
"context": {
"medications": [],
"allergies": [],
"recent_observations": []
},
"provenance": [],
"generated_at": "2025-01-15T10:30:00Z"
}
提示词可以明确约束模型只使用提供的上下文，并暴露不确定性：
你是临床信息整理助手。仅根据提供的患者上下文生成摘要。
要求：
1. 不推断上下文中不存在的诊断、药物或检查结果。
2. 每项关键事实附带来源标识和记录时间。
3. 明确指出冲突、缺失、过期或未确认的数据。
4. 不替代临床判断，不生成未经医生确认的治疗指令。
5. 如果证据不足，直接说明需要查阅哪些记录。
任务：整理本次药物复核所需的信息，按“当前用药、过敏、相关检验、待确认问题”输出。
这种设计把数据选择留在确定性的授权和查询层，把摘要、归纳和自然语言交互交给模型。即使模型回答不理想，敏感数据暴露范围仍由网关控制。
上线前检查的不只是模型效果
医疗机构可以从窄场景开始，例如病历导航、交接摘要草稿或研究资料检索，而不是直接把生成结果写回关键临床字段。试点阶段应同时评估准确性、遗漏率、引用可追溯性和临床人员复核时间。
上线清单至少包括：
- 使用短期令牌、角色权限和患者级授权限制访问。
- 为每次请求记录用户、患者范围、用途、数据类别和时间。
- 验证删除、更正和延迟同步的数据能否正确反映。
- 对提示词注入、越权查询和批量导出进行安全测试。
- 在界面上清晰区分原始记录、模型摘要与临床人员确认内容。
- 为错误响应、连接中断和权限拒绝设计可预期的降级路径。
- 让隐私、安全、合规、临床和信息治理团队共同审批工作流。
连接 EHR 让 ChatGPT 更接近真实临床工作，但连接本身不是终点。可采用的系统必须把可信数据、严格授权、来源追踪和人工判断组合起来。最稳妥的落地方式，是选择一个边界清楚、可人工复核的任务，证明它确实减少检索和整理成本，再逐步扩大数据范围与使用场景。