EHR 是什麼？醫療 AI 讀懂病歷前要過4關

EHR 是把病人的診斷、檢驗、用藥與照護歷程集中保存，讓授權醫療人員在不同照護場域取用的電子健康紀錄；醫療 AI 要讀懂它，還得先通過資料語意、交換介面、個資授權與臨床責任四道關卡。有 EHR，不代表資料已經能直接餵給 AI。

這個差距會直接影響醫院採購。若正在規畫 AI 導入，可以先看醫療 AI 導入要過的五道臨床關卡，再把本文的 EHR 檢查項目放進需求書；FHIR 介接則可對照如何判斷醫療 AI 能否落地的 FHIR Box 檢核。

EHR 是什麼？先分清楚 EHR 與 EMR

美國國家衛生資訊科技協調辦公室（ONC）把 EHR 定義為紙本病歷的數位版本，內容會隨時間累積，包含診斷、檢驗結果、藥物、醫師紀錄等，並提供授權醫療專業人員存取。ONC 的 EHR 定義與功能說明也把即時取用、分享與分析列為電子化後的用途。

EHR 與 EMR 常被混用，實務上仍有一個好用的分界：ONC 說明，EMR 通常限制在單一醫療提供者或院所，EHR 則可涵蓋不同照護場域與提供者。ONC 對 EHR 與 EMR 的比較因此適合拿來理解「跨院」這個詞的範圍，但每家醫院的系統命名仍要回到產品文件確認。

從產品設計角度看，EHR 不是一個檔案，也不是一張可以直接丟給大型語言模型的表格。它通常連著醫院資訊系統、檢驗系統、醫學影像系統、藥品資料庫與人工輸入的臨床文字。AI 若只讀到某一段病歷摘要，可能缺少檢驗時間、用藥狀態、資料來源或醫師覆核資訊，輸出就無法和完整病程畫上等號。

醫療 AI 怎麼讀 EHR？中間要經過四層轉換

AI 讀 EHR 的流程，我會拆成四層：先從院內系統取資料，再把欄位與醫療術語整理成共同語意，接著依病人與時間脈絡組出模型輸入，最後把輸出放回醫療人員看得懂、也能追溯的工作流。

層次	系統要完成的事	AI 導入前要問的問題
取資料	從 HIS、檢驗、影像或藥品系統取得授權資料	誰能取用？取到哪個時間點？
統一語意	將欄位、代碼、單位與時間軸對齊	不同院所的同一個詞是否代表同一件事？
組合脈絡	把病人、觀察值、用藥與病程關聯起來	模型是否知道資料來源與最新版本？
回到工作流	將建議顯示給指定角色並保留覆核紀錄	醫師如何接受、修改、拒絕或停用？

HL7 將 FHIR 定義為電子交換醫療資訊的標準，基本單位是 Resource；不同 Resource 可以透過參照組合，形成病人、觀察值、用藥與照護流程的資料關係。HL7 FHIR Overview支持這個分層理解。

FHIR 解決的是資料交換與模型化，沒有替醫院完成所有語意治理。HL7 的規格也提醒，FHIR API 本身不直接處理身分驗證、授權與稽核蒐集。HL7 RESTful API 規格因此，系統「能抓到資料」與「有權抓資料、抓過程可追蹤」是兩個驗收項目。

台灣現況：EHR 介接已走向 SMART on FHIR 與臨床驗證

衛生福利部 2026 年 1 月舉辦 SMART on FHIR 工作坊，公開說明 SMART 與 FHIR 是為了讓應用程式能在不同電子病歷系統間跨平台運作，並邀請醫療資通訊業者參與應用生態。衛福部工作坊公告顯示，台灣的方向已從單院資料庫延伸到跨平台應用介接。

衛福部國家數位健康互通性與效能認證實驗室公開的規劃，則把 FHIR Box、實際電子病歷系統與虛擬病歷環境放進測試，並要求技術驗證與臨床驗證同時通過，才取得國家認證標章。認證實驗室公開頁面列出的測項包含國家資料標準、台灣核心資料群、跨院互通、真實 HIS 環境呼叫、AI 運算流程與 FHIR 回傳準確度。

這些公開內容屬於制度與導入規劃，不能直接解讀成每家醫院都已完成 EHR 標準化。醫院仍要逐院盤點資料欄位、代碼、病人識別、介接版本、權限與臨床使用者；同一個模型換院部署，也要重新確認資料分布與工作流。

EHR 接上 AI 前，四道關卡怎麼驗收

第一關：資料欄位與醫療語意

採購文件要列出 AI 需要的欄位、資料型態、單位、代碼系統、更新頻率與缺漏處理。FHIR 的 Resource 可以提供共同結構，但各院的 Profile、Extension、術語綁定與映射仍要逐項驗證；HL7 的 FHIR 資源說明也把結構化資料、版本與來源中繼資料列為 Resource 的一部分。

我的驗收標準是「每個輸入都說得出從哪裡來」。模型看到一個血壓值時，系統要能回到量測時間、裝置或紀錄來源、單位與病人身分；看到一個診斷碼時，還要知道它是問題清單、此次就醫診斷，還是申報用途的代碼。

第二關：授權、身分與稽核

病歷、醫療與健康檢查資料在《個人資料保護法》第 6 條列為限制較嚴格的個人資料，蒐集、處理或利用必須落在法律明文、法定職務必要範圍、研究去識別化或書面同意等法定情形。個人資料保護法第 6 條也要求相關利用不能逾越特定目的的必要範圍。

因此，AI 介接需求不能只寫「串 EHR」。需求書要寫清楚使用者角色、資料範圍、用途、保存時間、輸出對象、撤銷權限與查詢紀錄；若模型供應商能看到原始病歷，契約與系統設計也要把委託處理、資料留存和事件通報寫進去。

第三關：臨床流程與人工覆核

AI 輸出要放在哪個畫面、由誰看到、多久內處理、如何標示不確定性，都屬於 EHR 導入的一部分。衛福部認證實驗室的公開規劃把真實 HIS 呼叫、AI 運算流程與 FHIR 回傳準確度列入臨床驗證，公開測試流程已把「能在系統裡跑」與「符合醫療流程」放在同一個驗證框架。

醫院可以把驗收情境寫得更具體：急診分流提示是否會擋住原本的處置畫面，病歷摘要是否能讓醫師快速回看原文，模型失效時是否自動回到既有流程。這些測試要找實際使用者參與，工程團隊單獨在測試環境按出成功畫面，證據不夠。

第四關：產品用途與責任邊界

TFDA 的醫用軟體分類分級指引把電子病歷、醫院資訊系統等保存與查看病人資料的軟體列為一類常見樣態，並指出若軟體可取代醫療人員的診斷治療決定，判定會進入不同的醫療器材管理考量。TFDA 醫用軟體分類分級參考指引同時強調，指引是初步判斷參考，無法確認時仍應依個案申請分類分級判定。

這會影響產品宣稱、驗證資料、醫院責任與上線後監測。把系統定位成病歷搜尋、摘要或行政提醒，和宣稱能診斷、分流或提供治療建議，會是不同的風險與法規路徑；名稱都叫 AI，導入文件不能共用一套。

常見問題

EHR 和電子病歷一樣嗎？

EHR 就是 Electronic Health Record，中文常譯為電子健康紀錄；台灣現場也常以電子病歷泛稱院內數位病歷系統。ONC 的分法把 EHR 放在跨照護場域的範圍，EMR 則多指單一提供者或院所內的紀錄。

FHIR 能讓 AI 直接讀懂 EHR 嗎？

FHIR 提供 Resource、欄位與交換介面，能降低系統之間的格式差異。醫院仍要處理術語、欄位映射、資料品質、身分權限與臨床脈絡，FHIR 本身不會替模型完成這些工作。

醫院導入 EHR AI 最先該驗什麼？

先驗收資料來源與欄位對映，再驗收權限、稽核、臨床工作流與人工覆核。模型分數要放在這些條件之後判讀，否則容易得到一個測試集表現漂亮、現場卻無法安全使用的系統。