醫療AI病歷該上雲還是留本機？三種架構怎麼選

醫療AI開始能直接連接電子健康紀錄（Electronic Health Record, EHR）。病歷該送進受管控的雲端、由院內 RAG 檢索，還是交給本機模型推論？

這個問題要先定義清楚。機構須決定資料與模型的位置、存取者、答案回查及中斷備援。只比模型或價格，會漏掉資料治理。

一、病歷上雲與留本機，真正差別在哪裡？

核心差別是敏感資料與推論工作跨越哪些信任邊界，以及機構能否控制每一次存取、保存與刪除。 模型能力只是決策條件之一。

「雲端連接器、RAG、本機模型」並非互斥的產品類別。前者描述如何接入 EHR，RAG 描述如何檢索資料，本機模型則描述推論位置。一套系統可以同時使用三者。

RAG 是 Retrieval-Augmented Generation，中文稱「檢索增強生成」。它先查找經授權的病歷或知識庫，再交由模型作答。RAG 可提供來源，卻不保證檢索完整，也不會修正原始資料。

FHIR（Fast Healthcare Interoperability Resources，快速健康照護互通資源）是 HL7 的醫療資訊交換標準。它不會代替權限、資料品質或臨床驗證。機構仍要查輸入是否完整、輸出能否回指紀錄，以及錯誤由誰處置。

二、雲端 EHR 連接器能帶來什麼？

它較適合需要強大模型能力、快速整合與企業級管理功能，且能確認資料地點、契約、權限及稽核均符合要求的機構。 適用性須以實際部署條件判斷。

OpenAI 於 2026 年 9 月公布 ChatGPT for Healthcare 的 Epic 整合，可帶入經授權的病人脈絡，也能嵌入支援的 EHR。用途包括就診前摘要、檢驗變化、用藥調整與待追蹤事項，回答可指回病歷。

官方產品評估涵蓋 27 種情境與 4,363 次評分，99.1% 回應獲醫師評為安全；另一評估中，五個資料源各有超過 93% 回應獲「良好」以上準確度。結果限於特定產品與流程，不能換算成本院診療準確率。

OpenAI 的產品評估顯示，EHR 脈絡連接可在指定工作任務中維持高比例安全評分；該結果仍需由每家機構以自身資料、流程與驗收門檻重新驗證。資料來源：OpenAI，2026。

雲端可減少大型推論叢集的維護，但工作會轉移到契約、稽核與供應商管理。機構須確認傳輸、暫存、日誌、備份、保存期限與次處理商，也要預備模型版本變更或外部服務中斷時的人工流程。

三、RAG 知識庫能否兼顧準確性與隱私？

RAG 可縮小模型取得的資料範圍並提供可追溯來源，但效果取決於索引品質、權限過濾與檢索評測。 它是一個控制層，並非準確或隱私的保證書。

院內 RAG 可讓原始病歷留在機構資料庫，只把經權限檢查的相關片段送往模型。搭配去識別與最小必要原則，可減少外送內容。

問題為什麼仍會發生？病歷分散於欄位、文字、掃描文件與影像報告。切塊過短會失去上下文，過長會帶入多餘個資；縮寫、時間軸及否定語句也會影響搜尋。漏掉關鍵內容後，模型仍可能生成流暢答案。

Mistral Agentic Search 採多步檢索。FinanceBench 從 26.7% 提升至 86%，OfficeQA Pro 從 6.3% 提升至 51.9%。它顯示長文件多步檢索可能優於一次取回，但評測並非病歷問答。

臨床問題若橫跨多次就診，一次取回固定片段可能不足。系統應能重查、核對日期及來源，證據不足便停止生成。Hugging Face 的 Funes 雖非醫療評測，但其本地嵌入與可追溯片段設計可供參考。

RAG 還要維護文件解析、FHIR 對應、索引更新、刪除同步、權限繼承及檢索評測。病歷更正後若索引未同步，模型仍可能引用過期內容。

四、本機模型是否代表資料最安全？

本機模型能減少資料離開院內環境的機會，但安全性仍取決於端點、帳號、更新、日誌、備份與維運能力。 缺乏管理的院內系統同樣可能外洩或被濫用。

本機模型把推論放在院內伺服器或隔離環境，適合極敏感資料、網路受限、延遲須可預測或須自行控制模型版本的情境。Ollama 官方案例顯示，桌面應用可切換本地或雲端模型，前端工具與推論位置可以分離。

Ollama 整合只是技術展示，沒有醫療準確性或臺灣合規證明。本機執行可縮短資料流，個別用途仍須驗證。

本機成本包含 GPU、備援、修補、監測與人力。院方可鎖定版本，也須承擔更新。提示與輸出仍可能進入日誌或備份，資料分級、最小權限與稽核仍不可少。

五、三種架構怎麼比較？

應以用途、資料敏感度、可驗證性與維運能力共同評估。 多數機構會採混合架構。

比較面向	雲端 EHR 連接器	院內或受控 RAG	本機模型
主要價值	模型與企業管理能力	限縮資料並回指來源	控制推論與版本
準確性關鍵	資料完整度、院內驗證	檢索、權限、索引更新	模型、硬體、任務調校
隱私重點	傳輸、儲存地、次處理商	索引個資、片段外送	端點、日誌、備份
維護負擔	契約、整合、回歸測試	文件管線與檢索評測	GPU、修補、監測、備援
適合起點	低風險摘要與整理	需引用病歷的問答	高敏感、隔離、低延遲任務
常見盲點	企業控制不等於合規	有引用不等於正確	不出院不等於安全

實務上可依敏感度分層：公開資料由受治理的雲端處理，院內文件由 RAG 提供，可識別病歷先做權限檢查與最小必要擷取；不得離開隔離區的任務再用本機推論。

混合架構可設計降級：雲端中斷便回到 EHR；RAG 證據不足只顯示原始資料；本機處理高敏感任務。

• 雲端、RAG、本機描述的是不同架構層次，可以組合使用。
• 高評測分數只對指定模型、資料與任務有效，院內仍須重新驗證。
• 資料保存位置只是隱私的一部分，權限、日誌、備份與刪除同樣重要。
• 較適合的架構應能保留人工覆核、來源追溯、服務降級與版本回復。

六、臺灣法規如何影響架構選擇？

可以在符合規範的條件下運用雲端，但電子病歷雲端資料原則上須存於臺灣境內，服務提供者也須符合主管機關認可的資安驗證要求。 個別方案仍須依資料流與用途進行適法性確認。

《個人資料保護法》第 6 條特別保護病歷、醫療與健康檢查資料。處理須符合列明事由並採安全措施；第 5 條也要求不得逾越特定目的必要範圍。

《醫療機構電子病歷製作及管理辦法》規定，委託建置、管理或使用雲端服務時，責任仍在醫療機構。契約須涵蓋保密、稽核、事故通知、終止後資料處理與再委託。第 8 條要求風險管控、營運持續、業者監督及退場移轉；資料原則上存於境內，例外須核准，服務商也須通過主管機關認可的資安驗證。

HIPAA、零資料保留或不用資料訓練等聲明，仍不足以判定符合臺灣要求。院方須驗證資料位置、子處理商、管理員存取、刪除與通報。

衛福部 2026 年生成式 AI 指引屬行政指導，並非強制規定。它要求導入前完成資安與資料保護評估，上線前做整合、壓力及臨床安全測試，上線後監測偏誤、錯誤與中斷。

衛福部 2026 年指引要求，凡涉及臨床判斷、病人安全、病人溝通或醫療紀錄的使用情境，應由具相應專業資格且在執業範圍內的醫事人員負最終確認、審核與責任。

若主要功能涉及診斷、治療、緩解或直接預防疾病，還須判斷是否屬醫療器材。架構選擇不能取代用途判定；行政文書與臨床決策的風險等級可能不同。

七、醫療機構如何做出可稽核的決策？

先定義單一使用情境與可接受風險，再畫出逐欄位資料流，最後用院內案例驗證。 不宜先選模型，再回頭尋找可套用的臨床問題。

1. 定義用途：列出使用者、輸入、輸出、後續行動及 AI 禁止事項。
2. 盤點資料流：記錄欄位、識別程度、目的地、日誌、備份、保存與刪除。
3. 查核法規與廠商：核對目的、資料地點、再委託、資安驗證、通報與退場條款。
4. 建立院內評測集：納入科別、語言、縮寫、缺漏與時間軸，測量召回、引用及重大遺漏。
5. 設計覆核與降級：指定核准者、停用條件與服務中斷時的替代流程。
6. 分階段上線：版本變更前後做回歸測試，監測錯誤、延遲與異常存取。

病歷摘要須測重大診斷或藥物遺漏、時間順序與否定語句。RAG 要分開測是否找對資料，以及模型是否忠實使用資料，才能定位錯誤來源。

機構應要求供應商揭露模型版本、部署型態、已知限制、資料政策與變更通知。產品平均分數只供初篩，院方要依臨床風險、病人族群與流程另訂門檻。行政整理、病歷摘要及臨床決策支援應分開驗收，以免權限過寬。

八、常見問題

常見疑問集中在 RAG 是否等於安全、本機是否免除法遵，以及雲端評測能否直接採信。 三者都需要回到資料流、用途與院內驗證回答。

常見問題

Q1: 使用 RAG 後，病歷就不會送到雲端嗎？

不一定。取回的病歷片段仍可能送到雲端模型，須查看端點、日誌、備份與次處理商的資料流。

Q2: 病歷去識別後，可以自由拿來測試模型嗎？

不能只看姓名。日期、罕見疾病與事件組合仍可能間接識別個人，高風險測試應經院內法務、資安及資料治理程序確認。

Q3: 本機模型不連網，就不需要做資料保護評估嗎？

仍然需要。帳號、日誌、備份與管理權限仍可能暴露資料，也要評估錯誤、中斷及誤用。

Q4: 供應商公布 99% 安全評分，可以直接用於臨床嗎？

不可以。數字只適用指定評測，院方仍須按科別、病人族群、資料缺漏與用途設定門檻並由專業人員覆核。