病歷可以給 AI 處理，但前提是用途、資料範圍、模型位置、授權與人工覆核都先寫清楚。把整份病歷貼進公開聊天機器人，不能因為刪掉姓名就自動變成合規；醫院與病人要先分辨資料要交給誰、為什麼交、會留下什麼紀錄。
這個判斷落在兩條線上：台灣《個人資料保護法》把病歷、醫療與健康檢查列入個人資料定義，並對這些資料設下特別限制；醫療機構導入生成式 AI 時，衛福部則要求做資料保護評估、風險盤點與輸出覆核。個資法第 2、5、6 條與衛福部《醫療機構應用生成式人工智慧指引》要一起看。
病歷交給 AI，先分清楚 4 種情境
「給 AI」包含幾種不同動作。病人把檢驗報告貼到聊天機器人、醫師在院內系統叫出單一病人的 FHIR 資源、醫院把去識別資料交給研究模型、供應商替醫院維運生成式 AI，資料流、授權對象和責任都不同。衛福部指引也把病歷撰寫輔助、臨床決策支援、行政文書與病人溝通列為不同醫療機構使用情境。指引的適用範圍已把這個差異寫進導入前評估。
| 情境 | 主要資料邊界 | 我會先問的問題 |
|---|---|---|
| 病人自行理解報告 | 個人把自己的資料輸入第三方服務 | 服務商會保存、訓練或分享輸入嗎？ |
| 院內文書輔助 | 病歷在醫療機構控制的流程中被處理 | 誰能看輸出，誰要審核與簽章？ |
| 臨床決策支援 | AI 取得病人脈絡並影響醫療判斷 | 輸入是否完整，錯誤怎麼攔截？ |
| 研究或模型訓練 | 多名病人的資料被整理、分析或重複利用 | 有沒有合法目的、適用例外與去識別證據？ |
這也是醫療 AI 病歷上雲或留本機的架構比較應該放在前面的問題。雲端、本機與 RAG 只是部署或檢索選擇，不能代替資料用途與責任設計。
第 1 關：這筆資料是不是特種個人資料？
台灣個資法第 2 條把病歷、醫療、基因與健康檢查列入個人資料；第 6 條則規定這些資料原則上不得蒐集、處理或利用，只有法律明文、法定職務必要且有安全措施、特定研究且無從識別，或當事人書面同意等例外。這代表「去掉姓名」只能是資料處理的一步，還要看能否透過其他欄位重新辨識，以及使用目的有沒有超出原本範圍。全國法規資料庫第 2、5、6 條是判斷的起點。
「我同意了」也沒有把所有問題一次解完。第 6 條要求書面同意，且同意不能逾越特定目的必要範圍；個資法第 8 條還要求告知蒐集者、目的、資料類別、利用期間、地區、對象與方式。實務上，醫院或服務商若只寫「用於改善服務」，卻沒有交代模型供應商、保存區域與是否再訓練，資料主體很難知道自己同意了什麼。個資法第 6、8 條提供了這些告知欄位。
第 2 關：資料送到哪裡，誰拿得到？
衛福部 2026 年 5 月發布的醫療機構生成式 AI 指引，把資料保護評估定義成導入前要檢查蒐集、處理、儲存與利用過程對隱私和資料安全的風險；指引也要求醫療機構盤點資料流向、保存政策、模型版本、已知風險、資安防護與事件通報機制。指引第 2 頁與第 6 頁已把這些項目列成導入前要索取的資訊。
我會把資料流畫成 6 個節點：輸入端、去識別化、權限判斷、模型推論、輸出儲存、人工覆核。每個節點都要回答「誰可以讀、讀哪些欄位、保存多久、能不能刪、出事誰通報」。供應商只回答「資料不拿去訓練」還不夠，還要把次處理商、備份、日誌、跨境傳輸、服務中斷與版本更新寫進契約；衛福部指引對供應商管理也要求揭露模型服務商、版本、部署型態、限制與更新通知機制。指引第 8 頁
第 3 關：FHIR 串得起來，授權有沒有跟上？
FHIR（Fast Healthcare Interoperability Resources）是醫療資訊電子交換標準，基本單位是可組合的 Resource；它處理資料怎麼表示與交換，沒有替醫院決定誰可以看資料。HL7 FHIR Overview把 FHIR 定位為交換醫療資訊的標準，也明確把安全、隱私與一致性列為實作時要處理的模組。
SMART on FHIR 再往前處理應用程式授權。應用程式向 EHR 申請特定 scope，授權伺服器依使用者、醫院政策與請求範圍決定核准或拒絕；SMART 規格要求應用程式把請求範圍限在最低必要資料與期間。SMART App Launch v2.2.0的範例甚至把單一病人的 Patient 與 Observation 讀取權拆開申請。
這個差異很實際。臨床摘要工具可能只需要目前就診的 Encounter、近期 Observation 與用藥紀錄，不需要整份長期病史；若系統一開就是 patient/*.read，工程上很方便，治理上卻留下過度取用的問題。FHIR 負責「怎麼交換」，SMART 協助「怎麼授權」，醫院仍要把最小必要欄位、角色權限與每次取用紀錄落成規則。
第 4 關：台灣現在走到哪裡？
台灣的醫療資料互通已經進入國家級基礎建設階段。衛福部 2026 年公告，透過 FHIR、TWCDI 與 TW Core IG 推動跨院病歷即時、安全、標準化流通，並表示長庚、馬偕與中山三大醫療體系在 2025 年底完成跨院病歷互通，資料可支援 AI 臨床決策。衛福部全國醫療資料互通公告提供了這個政策與技術進度。
醫院端也開始把驗證流程做成服務。台大醫院臨床 AI 取證驗證中心公開的設計包含跨院資料整合、研究倫理審查、聯邦學習、FHIR 串接與資料清理；其中聯邦學習讓資料留在院內，FHIR 則讓支援標準的 AI 產品呼叫 API 取得驗證所需資料。台大醫院臨床 AI 取證驗證中心的描述顯示，現場卡點已經從「有沒有資料」轉成資料能否在合法、可追溯的流程裡被使用。
這段進度不能被解讀成病歷已經可以自由餵給任何模型。衛福部指引仍要求醫療機構在導入前做風險盤點，對高風險應用採分階段試辦，並保留暫停、回復既有流程與替代服務的門檻。指引第 5 至 9 頁把「能串接」和「能上線」分成兩件事。
第 5 關：輸出誰審，錯了怎麼退回？
醫療 AI 的資料問題，最後會回到工作流。衛福部指引要求醫療機構以代表性案例與工作流程訂定驗收標準，記錄測試流程、資料與結果；若是高風險應用，先在隔離環境驗證，再於有限場域試辦，設定擴大或暫緩門檻。指引第 7 至 9 頁也要求模型版本、變更測試、異常通報與 rollback 程序。
醫師或病人不能只拿到一個看似完整的答案。院內系統至少要留下輸入資料版本、模型版本、取用權限、輸出、覆核者、覆核時間與後續處置；病歷文書仍由具資格的醫事人員審核與簽章。衛福部指引寫明，生成式 AI 在醫療場域只能作為輔助工具，臨床醫師、行政主管或其他決策人員負最終判斷責任。指引第 10 至 12 頁把這條責任線畫得很清楚。
我會要求採購案在上線前交出 5 張表：資料欄位表、資料流向表、角色與 scope 表、輸出覆核表、停用與回復表。這五張表若填不出來，模型分數再漂亮也還沒到臨床導入的時間；若填得出來，團隊才有辦法討論哪些資料該留在院內、哪些任務能交給雲端、哪些輸出必須停在草稿。
給病人與醫院的直接答案
病人若只是想理解自己的檢驗報告，先遮掉姓名、身分證字號、病歷號、電話、地址、條碼與能拼回身分的日期，再查清楚服務商的資料保存與使用政策；遇到用藥、診斷、急症或治療選擇，AI 輸出不能取代醫療判斷。這是降低暴露面的自保做法，不能把公開聊天機器人當成醫療機構的受管控系統。
醫院若要正式導入，先從低決策風險、可人工覆核的任務開始，例如行政摘要或病歷草稿，再往臨床決策支援移動。這個順序也接得上醫療 AI 驗證不能只看準確率的驗收框架：先定義預期用途，再驗資料、流程、人工角色與上線後監測。
對我來說，FHIR 是一條好用的資料管線，SMART 是一個合理的授權起點，兩者都不能代替合規判斷。病歷能不能給 AI，最後要看五件事是否同時成立：目的說得清楚、資料取最少、接收方可控、輸出有人審、出錯能退回。少一格，系統就不該直接碰臨床決策。
常見問題
病歷可以直接貼到 ChatGPT 或其他 AI 嗎？
不建議把可辨識的完整病歷直接貼到公開聊天機器人。先確認服務商的資料保存、跨境處理與再利用政策，並把資料範圍縮到完成任務所需的最低程度；用藥、診斷與急症判斷仍要回到醫療專業流程。
病歷去掉姓名後就可以拿來訓練 AI 嗎？
去掉姓名不等於一定無法辨識個人，也不會自動滿足個資法第 6 條。還要檢查日期、病歷號、影像、罕見病史等欄位能否拼回身分，並確認研究或訓練用途的法律依據、告知內容與安全措施，個資法第 6 條列出的例外要逐案對應。
FHIR 能不能保證醫療 AI 使用病歷合法？
不能。FHIR 是醫療資訊交換標準，SMART on FHIR 可把應用程式的授權與存取範圍做得更細，但醫院仍要決定用途、最低必要欄位、角色權限、保存期限、人工覆核與責任分工。
