台灣跨院 FHIR 互通：HIE 聯邦式架構與病人識別、同意授權、信任三支柱

tw-core-ig-fhir-layered-architecture 那篇談的是單一機構內的標準堆疊:資料怎麼從 HIS 變成 FHIR、
怎麼被加值應用取用。這篇接續往外一步——跨院。當中山醫、林口長庚、馬偕各自都有 FHIR Server,
要讓同一個病人的病歷在不同醫院之間即時互通,就需要一個跨院交換層(HIE),以及支撐它的三支柱。

HIE 是什麼?

HIE = Health Information Exchange,健康資訊交換。指的是讓病人的健康/醫療資料能在不同醫療機構之間
依規範、經授權地電子化流通的機制與基礎建設。它要回答的核心問題是:

「病人這次在 B 醫院就診,醫師能不能即時、安全地調到他先前在 A 醫院的檢驗、影像、用藥紀錄?」

HIE 同時是兩個意思:

機制/服務:一套讓資料跨院流動的規則、流程與信任框架。
基礎建設:實作這套機制的中介平台(本文圖中央的「跨院交換 / HIE」節點)。

要注意的是,HIE 不是「把所有病歷集中存到一個大資料庫」。在台灣採用的聯邦式設計裡,
HIE 比較像「接線生 + 守門員」:它負責確認病人身分、檢查病人是否同意、驗證來敲門的對象可信,
然後把查詢轉接到真正持有資料的那家醫院;病歷本身仍留在各院的 FHIR Server,不複製到中央。
(這也是為什麼下圖每家醫院都有自己的 FHIR Server。)

三種容易混淆的縮寫:HIE 是「跨院交換的機制/平台」;HIS 是醫院內部的資訊系統;
HIE ≠ HIS。而 FHIR 則是 HIE 用來交換資料的標準格式。

全景架構圖

和單機構版本最大的差別:中央多了一個 跨院交換 / HIE 節點,底下是多家平行的醫院
(每家都有自己的 FHIR Server / API、各自前接 HIS/EMR、LIS、RIS/PACS、醫令),
上層的 SMART on FHIR App 可由任一醫院 Launch。

為什麼需要 HIE?(聯邦式,不是集中式)

台灣的跨院互通走的是聯邦式(federated)而非「把所有病歷搬到一個大資料庫」的集中式:

資料留在各院:醫院 A、醫院 B 各自保有自己的 FHIR Server,病歷不必複製到中央。
HIE 當中介:跨院交換層負責「找到對的病人、確認對的授權、信任對的來源」, 再把查詢路由到持有資料的醫院。
好處:各院維持資料主權與責任歸屬;中央不持有巨量 PHI,資安暴露面較小; 新醫院加入只要符合同一套標準與信任框架即可接上。

這正是圖中每家醫院都有獨立 FHIR Server、而非共用一台的原因。HIE 是「目錄與守門員」,
不是「資料倉庫」。

跨院交換的三支柱

圖中 HIE 節點掛著三個標籤,正是跨院互通最難、也最關鍵的三件事:

1. 病人識別(Patient Identity / 病人比對)

跨院第一個問題:醫院 A 的「王小明」和醫院 B 的「王小明」是不是同一人?

各院的病歷號(MRN)互不相同,需要可信的身分對應機制 (台灣可借重身分證字號等全國級識別,搭配主索引 MPI 概念)。
對應錯誤的代價極高:把別人的病歷送錯人,是嚴重的醫療與隱私事故。
對應到 FHIR,即跨院的 Patient 資源識別與比對(對應 IHE 的 PIX/PDQ 概念)。

2. 同意授權(Consent / 授權)

病人是否同意讓 A 院的資料被 B 院或某 App 讀取?

跨院調閱須有病人同意為前提(對應 FHIR 的 Consent 資源與 SMART 的 Scopes)。
授權要可記錄、可撤回、可稽核:誰、在什麼情境、調了哪些範圍的資料。
與 OAuth2 / SMART on FHIR 的權限範圍(Scopes)結合,把「同意」落到每一次 API 呼叫 (機制見 fhir-oauth2-pkce-data-exchange)。

3. 信任機制(Trust Framework)

B 院憑什麼相信「來敲門的這個 App / 這家醫院」是合法的?

需要一套全國級信任框架:憑證、用戶端註冊、機構身分認證,確保只有經認證的節點能參與交換。
衛福部規劃把授權、傳播、認證納入機制,未來並列入醫院評鑑,用制度面強制信任的一致性。
對應技術:TLS/憑證、OAuth2 client 註冊與認證、稽核軌跡。

SMART on FHIR App「可由任一醫院 Launch」

圖上方標註 SMART on FHIR App「可由任一醫院 Launch」,這是聯邦式的關鍵體驗:

同一支 App(例如某臨床決策支援工具)不必為每家醫院各寫一版,而是符合 SMART on FHIR 的 OAuth2 + Launch 規範後,從哪家醫院的 EHR 啟動,就拿那家的授權與情境。
App 透過 HIE 或直接對該院 FHIR Server 取資料(圖中實線走 HIE、虛線可直連), 授權範圍由當次 SMART Launch 的 Scopes 決定。
這讓「一次開發、跨院可用」成為可能,是加值應用生態能規模化的前提。

標準堆疊在跨院場景的角色不變

圖左側仍是同一套標準堆疊(由上而下依賴),跨院並沒有改變它的職責:

A. TWCDI — 定義要交換什麼資料(病人、診斷、檢驗...)。
B. TW Core IG — 定義用 FHIR 怎麼表達(Profiles、ValueSets)。對齊於 TWCDI。
C. TWPAS(例) — 特定業務規格(Claim / ClaimResponse)。建構於 TW Core IG。

跨院能成立的前提,正是每家醫院都遵循同一套 TW Core IG ——
否則 A 院的 Observation 和 B 院的 Observation 欄位/代碼不一致,HIE 也無從互通。
標準是跨院互通的共同語言。

聯邦式拓撲(示意)

flowchart TB
    subgraph APPS[加值應用]
        SMART[SMART on FHIR App<br/>OAuth2 + Launch<br/>可由任一醫院 Launch]
        CLIN[臨床 / 病人加值應用]
        BI[BI / 分析應用]
    end

    HIE{{跨院交換 / HIE<br/>病人識別 · 同意授權 · 信任機制}}

    subgraph HA[醫院 A]
        FA[FHIR Server / API<br/>OAuth2 / SMART Launch]
        FA --- SA[HIS/EMR · LIS · RIS/PACS · 醫令]
    end
    subgraph HB[醫院 B]
        FB[FHIR Server / API<br/>OAuth2 / SMART Launch]
        FB --- SB[HIS/EMR · LIS · RIS/PACS · 醫令]
    end

    APPS --> HIE
    SMART -.可直連該院.-> FA
    SMART -.可直連該院.-> FB
    HIE --> FA
    HIE --> FB

HIE 不存病歷,只做「識別、授權、信任」與路由;真正的資料仍各自留在醫院 A / B 的 FHIR Server。

落地實例:三大醫學中心即時互通

衛福部於 113 年(2024)11 月公告「電子病歷 FHIR 資料標準化與跨院轉換」試辦計畫, 11 家醫學中心報名、經兩輪評選,選出中山醫學大學附設醫院、林口長庚、馬偕三家,12 月啟動。
三家完成 FHIR 電子病歷萃取工具部署後,於 2026-01-15 的跨院 FHIR 資料平台成果發表會宣告達成即時病歷互通。
後續規劃:擴及全國醫學中心,把授權、傳播、認證納入機制,並列入醫院評鑑。
資料標準以 TWCDI 1.0 / TW Core IG(20 大類、109 個交換變數)為全國基準。

和單機構版本的對照

面向	單機構(前一篇)	跨院 / HIE(本篇)
FHIR Server	一台,服務院內	每家醫院各一台,聯邦式
中介層	無(直接對 FHIR API)	多一層 HIE(識別/授權/信任)
主要挑戰	資料對標準、Profile 一致	病人比對、跨院同意、機構信任
App 啟動	院內 SMART Launch	可由任一醫院 Launch
資料位置	集中於該院	留在各院,HIE 不持有