ChatGPT 正式串接 Epic 電子病歷:醫療 AI 不只會回答問題,開始進入醫院工作流程
OpenAI 讓 ChatGPT for Healthcare 以唯讀方式連接 Epic 電子病歷,並整合 9 個官方公共醫療資料源。本文整理功能、限制與醫療 AI 落地風險。
OpenAI 正把 ChatGPT 從「回答醫療問題的聊天工具」,推進到醫療機構每天使用的工作系統。
2026 年 9 月 1 日,OpenAI 宣布 ChatGPT for Healthcare 新增 Epic 電子病歷整合,讓獲得授權的醫療人員能在 ChatGPT 中整理病歷、檢查近期變化,並回到原始紀錄核對。同時推出的 Healthcare Public Data plugin,則把 PubMed、ClinicalTrials.gov、DailyMed 等 9 個官方公共醫療資料源帶進 ChatGPT 與 Codex。
這項更新沒有讓 AI 自動看診,也沒有開放 ChatGPT 任意讀取病歷。它真正改變的是資訊取得方式:醫療人員不必先在多個系統找完資料,再複製到 AI 裡整理。AI 可以在既有權限與治理規則下,直接協助彙整可用資訊。
我的判斷是中性偏多。產品方向比單純提升模型分數更接近醫療現場的問題,但目前 Epic 連線仍為唯讀,而且公開成效主要來自 OpenAI 自己的評估。它能不能真的替醫師省下時間,還要看醫院部署後的錯誤率、覆核成本與實際使用數據。
ChatGPT for Healthcare 這次更新了什麼?
這次發布包含兩個彼此獨立的功能。第一個是 Epic integration,負責連接醫療機構內的病人資料。第二個是 Healthcare Public Data plugin,負責查詢對外公開的研究、藥品、臨床試驗與 Medicare 資料。
這個區分很重要。Epic 裡面可能包含特定病人的就診紀錄與檢驗結果,公共資料源則提供通用的研究與政策資訊。醫師準備看診時,通常要同時理解「這位病人發生了什麼」以及「目前證據與規範怎麼說」。
| 功能 | 讀取的資料 | 能解決的問題 | 目前限制 |
|---|---|---|---|
| Epic integration | 使用者原本有權限查看的病歷 | 整理病史、藥物、檢驗結果與就診變化 | 唯讀,不能改病歷或下醫囑 |
| Healthcare Public Data plugin | 9 個官方公共醫療資料源 | 查研究、試驗、藥品標籤、給付政策與機構資料 | 不可放入病人身分資料,也不會讀取病歷 |
換句話說,這套設計讓不同來源各自保留權限與用途,再由 ChatGPT 協助整理。它比「上傳一份病歷 PDF 給聊天機器人」更接近醫療機構真正能管理的工作流程。
Epic EHR 是什麼?為什麼串接電子病歷很重要?
EHR 是 Electronic Health Record 的縮寫,也就是電子健康紀錄。它不只是病歷文字,還可能包含用藥、診斷、檢驗結果、就診紀錄與其他臨床文件。Epic 則是美國醫療機構廣泛使用的 EHR 系統供應商。
過去,醫師要準備看診,可能得在長篇病歷中找出上次就診後的變化:哪些檢驗數字變了、是否換過藥、專科醫師提出了什麼建議、哪些追蹤還沒完成。ChatGPT for Healthcare 的新整合,就是要先把這些資訊整理成可閱讀的脈絡,再附上對應的病歷來源供醫師核對。
根據 OpenAI 的說明,醫療機構可以有兩種使用方式:把獲得授權的 EHR 資訊帶進 ChatGPT,或在支援的部署中,直接把 ChatGPT 放進 EHR 介面。後者尤其值得注意,因為醫師不用離開病歷畫面,AI 才有機會成為日常流程的一部分,而不是另一個需要切換的網站。
不過,這項整合目前是唯讀。它不能修改病歷、下醫囑、傳訊息給病人,也不能擴大使用者原本的病歷權限。醫師仍要檢查原始紀錄,並對醫療決策負責。
把寫入功能留在系統之外,是合理的第一步。醫療系統真正要避免的,是 AI 在沒有充分確認時執行不可逆的動作。先從整理與查找開始,比一開始就讓模型寫回病歷或執行醫療動作更容易控制風險。
OpenAI 官方示範醫療人員如何在 ChatGPT for Healthcare 中整理獲得授權的 Epic 病歷脈絡,並回到原始紀錄核對。 影片來源:OpenAI 官方公告;採官方 Vimeo Embed,不重新託管。
9 個官方醫療資料源有哪些?
Healthcare Public Data plugin 把 9 個唯讀的公共資料 app 放在同一個工作流程中。它們不會讀取病人的 Epic 病歷,也不需要另外申請各資料網站的帳號。
| 資料源 | 可以查什麼 |
|---|---|
| PubMed | 生醫研究、論文摘要與部分全文 |
| ClinicalTrials.gov | 臨床試驗、招募狀態、地點與資格條件 |
| DailyMed | 官方藥品標籤、成分、包裝與藥品識別資訊 |
| RxNorm | 標準化藥名、識別碼與藥品概念關係 |
| openFDA | FDA 公開的安全、召回與不良事件資料 |
| CMS Coverage | 美國 Medicare 全國與地方給付政策 |
| CMS Open Data | 部分 Medicare 支付、處方與醫療利用資料 |
| Medicare Care Compare | 醫療機構公開資訊與品質指標 |
| NPI Registry | 醫療人員與機構的公開識別資料 |
把資料源列在一起,看起來像是多了一個搜尋入口,但真正的價值在於跨來源比較。研究團隊可以先找正在招募的臨床試驗,再核對納入條件。藥事團隊可以查最新版藥品標籤與警語。規劃照護方案的人,也能把研究證據、試驗進度與 Medicare 給付政策放在同一份分析裡。
這些資料仍然需要專業判讀。例如,openFDA 的不良事件回報不能直接證明藥品造成該事件,NPI 編號也不能證明某位醫療人員目前持有有效執照。AI 可以縮短查找時間,但不能取消每個資料庫原本的使用限制。

OpenAI 官方示範 Healthcare Public Data plugin 如何查詢並比較公共醫療資料。 影片來源:OpenAI 官方公告;採官方 Vimeo Embed,不重新託管。
這不是一般版 ChatGPT,也不是個人醫師直接登入就能用
OpenAI 現在同時提供多種醫療相關產品,名稱相近,很容易混在一起。
| 產品 | 適合誰 | 這次能否串接機構端 Epic 病歷 |
|---|---|---|
| Health in ChatGPT | 想整理本人健康資料的個人使用者 | 否 |
| ChatGPT for Clinicians | 符合資格的美國個別臨床人員 | 否,可使用符合資格的公共醫療資料功能 |
| ChatGPT for Healthcare | 醫療機構的臨床、研究與行政團隊 | 可以,但要經組織核准與設定 |
Epic plugin 目前只提供給核准的 ChatGPT for Healthcare,以及支援 HIPAA 的 Enterprise workspace。醫療機構的管理者與 Epic administrator 必須先配置 EHR app、FHIR 連線與 OAuth 驗證,每位使用者也要用自己的 Epic 帳號登入。
FHIR 是醫療系統交換資料的標準。OAuth 則是讓使用者授權系統存取資料、但不必把密碼直接交給 ChatGPT 的驗證方式。這套流程代表安裝 plugin 並不會自動開放全院病歷,使用者只能看到自己在 Epic 中原本就有權限查看的內容。
對想立刻試用的個人來說,答案很直接:這不是打開一般 ChatGPT 就會出現的功能。它是一項需要醫療機構、資訊團隊與合規流程共同部署的企業產品。
OpenAI 公布 99.1% 安全評分,應該怎麼看?
OpenAI 表示,數百名來自 60 個國家、使用 49 種語言、涵蓋 26 個專科的醫師,已檢視超過 70 萬個模型回答。針對連接 EHR 脈絡的能力,醫師在 27 種臨床情境中完成 4,363 次評分,其中 99.1% 的回答被評為安全。
另一項兩輪評估則測試 5 個已連接的公共資料源。OpenAI 表示,每個資料源都有超過 93% 的回答獲得「良好」或更高的準確度評級。
這些數字說明 OpenAI 已經把病歷摘要、用藥檢視、交班摘要等實際任務放進測試,而不只考模型會不會回答醫學考題。不過,99.1% 指的是安全評分,不是診斷正確率,更不代表錯誤率只剩 0.9%。93% 的結果也來自 OpenAI 公布的產品評估,不能直接推論成醫院上線後的臨床成效。
我會把這些結果視為「值得進入受控試點」的證據,而不是「已可全面取代人工整理」的證明。真正會改變判斷的數據,是醫院實際部署後能省下多少時間、重要資訊遺漏率是否下降、醫師需要花多少時間覆核,以及錯誤會不會集中在高風險情境。
病歷交給 ChatGPT,隱私與 HIPAA 怎麼處理?
OpenAI 表示,ChatGPT for Healthcare 提供角色權限控管、單一登入與稽核紀錄等企業功能,組織資料預設不會拿去訓練模型。符合資格的客戶也可以與 OpenAI 簽署 BAA,也就是美國醫療機構與合作服務商處理受保護健康資訊時使用的協議。
但「支援 HIPAA 合規」不等於「只要開啟功能就自動合規」。醫療機構仍要確認 BAA 涵蓋的產品與功能、Epic 授權、工作區設定、使用者角色,以及每一項實際工作流程。OpenAI 也特別提醒,接受 plugin 警告或完成連線,並不會自動讓所有使用方式都受到 BAA 保護。
公共資料 plugin 還有另一條清楚界線:查 PubMed、openFDA 或 CMS 等公開來源時,不應把病人姓名、生日、病歷號或其他可識別資訊放進查詢。因為請求可能送往外部資料源,資料駐留與第三方服務條款也要另外審查。
因此,醫院評估這類工具時,不能只問「模型準不準」,還要問資料送到哪裡、誰看得到、操作是否留下紀錄,以及發生錯誤時如何追查。醫療 AI 的產品能力與資料治理,必須被當成同一件事設計。
這次更新對醫療 AI 的真正意義
過去醫療 AI 常把重點放在模型能不能回答醫學問題,但醫院真正缺少的,往往不是另一個會回答問題的視窗。臨床資料分散在病歷、檢驗、藥物、研究與給付系統中,醫療人員得先找到正確資料,才能開始判斷。
Epic integration 與 Healthcare Public Data plugin 嘗試解決的,就是這段「找到、整理、回查」的工作。這也代表 AI 產品競爭開始從模型能力,往系統整合、權限治理與流程入口移動。當 AI 能在醫療人員原本工作的畫面中提供來源,產品價值才有機會從偶爾問答變成穩定的日常效率。
我對這個方向中性偏多,原因有兩個。第一,OpenAI 沒有把產品包裝成自動診斷,而是從唯讀、可回查的資訊整理開始。第二,它同時連接病人脈絡與官方公共資料,比只靠模型記憶回答更符合醫療工作的查證需求。
最大的風險則是自動化偏誤,也就是使用者因為摘要讀起來完整,就忽略模型漏掉的關鍵細節。若醫師最後仍要從頭重讀所有病歷,AI 就沒有省下多少時間。反過來說,若醫師不再回查原始紀錄,錯誤又可能被放大。產品是否成功,取決於它能不能在這兩者之間找到可信任的工作方式。

結論:ChatGPT 進入病歷系統,關鍵不是「會不會看病」
ChatGPT 串接 Epic 最值得注意的地方,不是 AI 突然獲得醫師權限,而是 OpenAI 開始處理醫療 AI 最難落地的部分:把模型放進既有系統,同時保留資料來源、使用權限與人工責任。
目前它比較像醫療資訊的整理助手。它可以協助找出上次看診後的變化、整理藥物與檢驗結果,也能查詢 9 個官方公共資料源,但不能改病歷、下醫囑或取代醫師決策。
對醫療機構來說,這項功能值得從低風險、容易量化的工作開始試點,例如看診前摘要或交班整理,再追蹤節省時間、遺漏率與覆核負擔。只要這些數據還沒有公開,就不該把漂亮的安全評分直接當成臨床成果。
真正的分水嶺,不會是 ChatGPT 能讀多少病歷,而是醫療團隊能不能在不犧牲準確性與責任邊界的前提下,少花時間找資料,把更多時間留給病人。
FAQ
ChatGPT 現在可以直接讀取所有人的 Epic 病歷嗎?
不可以。這項功能只適用於核准的醫療機構工作區,且每位使用者都要以自己的 Epic 帳號登入。ChatGPT 只能讀取該使用者原本就有權限查看的病歷。
ChatGPT 可以修改病歷或替醫師下醫囑嗎?
目前不行。Epic integration 是唯讀連線,不能更新病歷、下醫囑、傳訊息給病人或繞過既有權限。醫療決策與病歷核對仍由臨床人員負責。
Healthcare Public Data plugin 會讀取病人的個人資料嗎?
不會。它查詢的是 PubMed、ClinicalTrials.gov、openFDA、CMS 等公開資料,與 Epic plugin 分開運作。使用者也不應在公共資料查詢中輸入病人姓名、生日、病歷號或其他受保護資訊。
一般 ChatGPT 使用者可以安裝 Epic plugin 嗎?
不行。Epic plugin 目前提供給核准的 ChatGPT for Healthcare 與符合條件的 Enterprise workspace,不提供給一般個人帳號或個人的 ChatGPT for Clinicians 帳號。
99.1% 安全是否代表 ChatGPT 的醫療回答有 99.1% 正確?
不是。99.1% 是 OpenAI 在特定 EHR 使用情境中公布的安全性評分,不能當成診斷正確率。醫院仍需要用真實部署數據衡量資訊遺漏、覆核時間與臨床風險。
資料來源
- OpenAI:Healthcare organizations can now connect EHR and additional industry data to ChatGPT
- OpenAI Help Center:Using the Epic plugin with ChatGPT and Codex
- OpenAI Help Center:Using Healthcare Public Data in ChatGPT and Codex
- OpenAI Help Center:ChatGPT for Healthcare
- OpenAI Help Center:HIPAA Eligible Products and Functionality
- OpenAI:Business data privacy, security, and compliance
- Karan Singhal 的原始 X 貼文