TW Core IG 與台灣 FHIR 互通分層架構：從 TWCDI、TW Core 到 TWPAS 與加值應用

台灣推動全國級醫療資料互通(National EHR Data Hub),核心是一套分層、由上而下依賴的標準堆疊。
這篇用衛福部官方 臺灣核心實作指引(TW Core IG) 為基準,
拆解整張架構圖的每一層在做什麼、彼此怎麼依賴,以及為什麼加值應用「不必各自直連 HIS」。

全景架構圖

整張圖由下而上是資料的旅程,由左而右是標準的依賴關係。下面逐層拆解。

四個層次

1. 來源系統層(資料從哪來)

最底層是醫院既有的營運系統,也是資料的原始產生者:

• HIS / EMR — 醫院資訊系統與電子病歷,病人主檔、就診、診斷、醫令。
• LIS — 檢驗資訊系統,抽血、生化、微生物等檢驗結果。
• RIS / PACS — 放射資訊系統與影像儲傳系統,影像檢查與報告。
• 藥品 / 醫令系統 — 處方、給藥、醫囑。

這些系統格式各異、彼此孤立(過去就是所謂「數位孤島」)。互通的第一步,是把它們的內容
對應到三大國際術語標準:檢驗用 LOINC、臨床概念用 SNOMED CT、藥品用 RxNorm,
轉換後上傳到 FHIR Server。

2. FHIR Server / API(資料的統一出入口)

各來源系統的資料轉成 FHIR 之後,集中由 FHIR Server / API 提供標準化存取。圖中標出四個關鍵能力:

• Resource — FHIR 的基本資料單位(Patient、Condition、Observation、MedicationRequest...)。
• Profile — 在通用 Resource 上加台灣在地約束(由 TW Core IG 定義,見下)。
• Search — 標準查詢參數(如 Patient?identifier=、Observation?code=&date=)。
• Terminology — 術語服務,負責 LOINC/SNOMED/RxNorm 等代碼的綁定與驗證。

關鍵價值:加值應用只要會講 FHIR,就能透過這個統一介面取資料,
不必為每家醫院、每套 HIS 各寫一支介接。這正是圖右上角那句註解的意思。

3. 標準與指引層(由上而下的依賴)

這是整張圖的核心,也是最容易混淆的地方。三個層次由上而下依賴,各自回答不同問題:

A. TWCDI — 定義要交換什麼資料

TWCDI(Taiwan Core Data for Interoperability)是語意層的資料集清單,參考美國 USCDI 的模式,
規範「全國互通至少要能交換哪些資料項目」。目前定義約 20 大類、109 個 EHR 交換變數,
涵蓋:病人基本資料、過敏、用藥、臨床紀錄、檢驗與影像、處置、生命徵象、保險與健康社會決定因素(SDOH)等。
TWCDI 只談「要有哪些欄位、語意是什麼」,不綁定技術格式。

B. TW Core IG — 定義用 FHIR 怎麼表達

TW Core IG 是 TWCDI 的技術落地,用 HL7 FHIR 把那些資料項目「翻譯」成可驗證的結構。它:

• 基於 FHIR R4.0.1,參考國際病人摘要 IPS 1.1.0 與 US Core IG。
• 定義一組 Profiles(在通用 Resource 上加在地約束),例如 TW Core Patient、TW Core Condition、 TW Core Observation Laboratory Result、TW Core Observation Blood Pressure、TW Core MedicationRequest 等。
• 定義 Extensions(在地擴充欄位)、ValueSets(可用代碼集合)與驗證規則。
• 規範每個欄位的 cardinality(基數)、資料型別、代碼綁定與查詢參數。
• 標註 Must Support:資料若存在於送方系統,就必須能處理/呈現;部分欄位為 Mandatory(必填)。

換句話說:TWCDI 說「要有過敏資料」,TW Core IG 則說「過敏用 AllergyIntolerance 這個 Profile、
這些欄位必填、代碼綁這個 ValueSet」。TW Core IG 對齊於 TWCDI(圖中 B → A 的「對齊於」)。

C. TWPAS — 專案型實作指引(建構於 TW Core IG 之上)

最上層是針對特定業務情境的實作指引,圖中以 TWPAS(臺灣健保事前審查實作指引,健保署)為例。
它建構於 TW Core IG(圖中 C → B 的「建構於」),沿用 TW Core 的 Profile,
再針對事前審查這個流程補上專用結構:

• 事前審查流程、Claim / ClaimResponse(申請與審查回覆)、DiagnosticReport、Bundle。
• 官方文件見 臺灣健保事前審查實作指引(TWPAS)。

這種「通用核心 + 專案擴充」的分工,讓各業務(事前審查、電子處方箋、電子病歷交換單張...)
不必各自重新發明病人/診斷/檢驗的表達方式,共用 TW Core 的地基即可。

4. 加值應用層(資料給誰用)

最上層是真正面對使用者的應用,透過 FHIR API 取資料:

• SMART on FHIR App — 標準化的醫療 App 框架,用 OAuth2 + Scopes 控制存取權限與範圍 (授權與資料安全細節見 fhir-oauth2-pkce-data-exchange)。
• 臨床決策支援(CDS) — 用即時資料提供用藥/檢驗提醒。
• 病人加值服務 — 病人端查詢自己的健康資料。
• BI / 分析應用 — 跨院、群體層級的統計與分析。

這些應用共用同一個 FHIR 介面,不需各自直連底層 HIS,大幅降低介接成本與資安暴露面。

依賴關係總覽

flowchart TB
    subgraph APP[加值應用層]
        SMART[SMART on FHIR App<br/>OAuth2 + Scopes]
        CDS[臨床決策支援]
        PAT[病人加值服務]
        BI[BI / 分析應用]
    end

    subgraph API[FHIR Server / API]
        R[Resource]
        P[Profile]
        S[Search]
        T[Terminology]
    end

    subgraph STD[標準與指引層]
        C[C. TWPAS 等<br/>專案型實作指引]
        B[B. TW Core IG<br/>用 FHIR 怎麼表達]
        A[A. TWCDI<br/>要交換什麼資料]
    end

    subgraph SRC[來源系統層]
        HIS[HIS / EMR]
        LIS[LIS]
        RIS[RIS / PACS]
        MED[藥品 / 醫令]
    end

    SRC -->|對應 LOINC/SNOMED/RxNorm 後上傳| API
    APP -->|標準 FHIR 介面存取| API
    C -->|建構於| B
    B -->|對齊於| A
    API -.受指引約束.- STD

注意兩個方向:資料流是「來源系統 → FHIR Server → 加值應用」;
依賴流是「TWPAS 建構於 TW Core IG、TW Core IG 對齊於 TWCDI」。前者是運行期,後者是規範期。

為什麼這樣分層?(設計意涵)

• 語意與技術分離:TWCDI 管「要什麼」、TW Core IG 管「怎麼表達」。資料政策可獨立於 FHIR 版本演進。
• 核心與專案分離:TW Core 當共用地基,TWPAS 等專案指引只補各自的業務差異,避免重複定義。
• 來源與應用解耦:FHIR Server/API 當中介層,加值應用不綁定特定醫院的 HIS,換院、擴點成本低。
• 可驗證的一致性:Profile + Must Support + ValueSet 讓「資料合不合規」可被機器驗證, 而非靠各院自行解讀。
• 資安內建:存取走 SMART on FHIR(OAuth2/Scopes)而非直連資料庫, 權限、稽核與最小揭露都在標準層處理(PHI 防護見 FHIR Box PHI 資安實作指南)。

名詞對照

官方文件

• 臺灣核心實作指引(TW Core IG)v1.0.0 — 衛福部
• 電子病歷交換單張實作指引(EMR-IG) — 衛福部
• 臺灣健保事前審查實作指引(TWPAS) — 健保署

延伸閱讀

• 台灣跨院 FHIR 互通：HIE 聯邦式架構與三支柱
• FHIR 用 OAuth2 + PKCE 交換資料的運作機制
• FHIR Box PHI 資安實作指南