FHIR 導入的關鍵抉擇在於底層架構，Native 與 Façade 的選擇牽動資料同步、系統整合與長期維運，事先釐清權威來源與責任邊界，才能避免技術債累積。
口述／孫培然‧彙整校訂╱CIO 編輯室
投入臺灣核心實作指引（Taiwan Core Implementation Guide；TW Core IG）時，從標準理解、資料對應到系統整合，每一步皆具挑戰。本期專欄聚焦風險最高、影響最深的關鍵決策——底層架構選型。此決定影響眼前系統實作，以及未來的資料同步、系統整合、維護升級與技術債。架構選錯方向，後續將承擔資料流重構與維運成本攀升，幅度超出初期評估。
按部就班選擇架構
指引強調：架構選擇伴隨整個專案生命週期，一旦選錯，後續調整成本明顯偏高。FHIR 導入初期的架構決策，影響未來數年的開發方式、資料治理、系統維護，以及版本升級與架構轉型的難度。換言之，重點在於長期路線抉擇，單純的技術選擇居次。以下依序釐清：架構選型的風險位置、Native FHIR 與 Façade FHIR 的差異、資料同步的處理、技術債的避免，以及長期維護與升級的支撐性。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
先確認架構選型在 FHIR 導入過程中的風險位置。攤開前面談到的 24 個核心主題，部分議題風險可控。例如資料來源追蹤，初期設計不完整，後續仍可補強與調整。底層架構選型與既有 HIS 的即時資料同步，位於整體風險的最高區域。一旦確立，牽動後續資料流向、系統邊界、API 設計、同步機制與維運方式。低風險問題可邊做邊修，高風險架構問題無法以「先做再說」處理。架構走錯方向，後續成本涵蓋整套資料流與系統邊界的重新設計，超出修改幾支程式的範疇。撰寫程式前，先把架構想清楚，效益大於急著動工。
Native 與 Façade 架構的比較
架構選型屬高風險決策，須釐清 Native FHIR 與 Façade FHIR 的差異，以及實務選擇依據。此二種架構不存在絕對優劣，也無一套適用所有醫院的標準答案。評估重點在於既有 HIS 現況、資料移轉成本、系統整合能力，以及未來成熟度目標。本質在於現實限制下做出適合自身的取捨，屬於務實判斷，技術先進性居次。
Native FHIR 的核心在於資料直接以 FHIR Resource 形式存在，FHIR 成為主要資料模型與服務介面。優勢在於資料模型一致、FHIR 能力完整，適合長期朝標準化與雲端原生發展。現實挑戰在於：既有 HIS 怎麼辦？
對運作多年甚至數十年的醫院而言，既有病人、就醫、醫囑、檢驗、用藥等大量資料與流程全面轉換成 FHIR，範疇超越單純搬資料，涵蓋資料清理、Mapping、驗證、流程改造與新舊系統切換，移轉成本與風險偏高。
Façade FHIR 採取另一種思維：既有 HIS 不動，外層加上 FHIR 介面。外部系統透過 FHIR API 查詢時，Façade 即時向既有 HIS 取得資料，經 Mapping 與轉換，組成標準 FHIR Resource 回傳。對背負大量既有系統與歷史資料的醫院而言，此方式降低初期改造成本，較快建立對外的 FHIR 標準介面。核心挑戰在寫入環節。
「把 HIS 資料轉成 FHIR」相對單純；若透過 FHIR API 寫入並反向寫回既有 HIS，處理範疇超越格式轉換，涵蓋既有 HIS 的商業邏輯、資料驗證、交易控制、權限，以及跨系統一致性，複雜度快速上升。兩者差異可濃縮為一句話：Native FHIR 的難題在「移轉」，Façade FHIR 的難題在「寫回」。下一個棘手問題隨之浮現：資料該怎麼同步？
如何面對資料同步挑戰
此二種架構在實務上的最大分水嶺在於資料同步。實務常把「即時」掛在嘴邊，但背後隱含多種假設。動工前，首要釐清所需即時程度，至於如何做到即時居次。是 1 毫秒、1 秒，還是 10 分鐘？不同時間尺度對應不同架構複雜度、基礎設施成本與維運負擔。未先定義「即時」，後續架構設計容易一開始就走偏。
實作上，若目標為接近即時的資料同步並朝 Native FHIR 發展，可採用 CDC （Change Data Capture，資料異動擷取），搭配 NATS／Kafka 等訊息或事件串流平台。來源資料庫新增、修改或刪除時，CDC 即時捕捉異動並發布事件，後端服務完成資料處理、FHIR 資源轉換與同步，將更新時間差縮短到秒級。相較之下，傳統 Polling （輪詢）定期詢問來源系統「資料有沒有改變」，增加資料庫與系統負擔，且產生同步延遲。對強調即時性與事件驅動的 Native FHIR 架構而言，資料一改變就主動通知，屬於更符合現代化架構的設計，效益高於不斷詢問的輪詢做法。
[ 閱讀所有 孫培然 之專欄文章 ]
若採用 Façade 模式，優勢在「讀取」：外部系統發出 FHIR Request 時，即時從既有 HIS 取得資料，動態轉換成 FHIR Resource 回傳，無需另外維護同步的 FHIR 資料。困難在於寫回去。FHIR 寫回既有 HIS，無法以單純格式轉回作結，牽涉既有資料模型、商業邏輯、欄位驗證、交易一致性，以及各系統流程與權限控制。此差異說明「讀取轉換」相對容易，「雙向同步」複雜度大幅提高。
常見迷思需釐清：雙向同步屬可選目標，最終目標定位居次。分散式系統中，困難的核心在於兩端皆可修改資料時，最終資料權威的判定，資料是否送達另一端居次。務實做法是先定義每一類資料的 Source of Truth （權威資料來源），再決定哪些需即時同步、哪些只需單向同步、哪些不應同步，避免一開始就追求全面雙向同步。同步的重點在於先回答誰擁有此筆資料、誰有權改變，數量居次。
如何避免技術債
相較於一開始就挑戰高複雜度雙向同步，務實原則在於明確定義單一資料來源（Single Source of Truth）。此原則帶出實務常見提問：Native FHIR 移轉成本偏高、雙向同步複雜度偏高，若只採用 Façade 模式且初期規劃完整，是否已足夠？Façade 是否足以支撐需求？答案是肯定，在許多既有 HIS 環境下，Façade 屬相對務實的路徑，前提在於守住幾個架構原則。
第一，清楚定義既有 HIS 為唯一的權威資料來源（Source of Truth）；第二，Façade 層責任邊界清楚，原則上維持唯讀（Read-only），將既有 HIS 資料即時轉換成標準 FHIR Resource，提供外部系統存取。此層定位為讀取轉換，寫回與同步由既有 HIS 承擔。應避免邊界模糊的混合模式：有些資料從 HIS 即時轉換、有些存進 FHIR Server、有些又寫回 HIS。短期看似彈性，長期產生資料一致性、同步衝突與責任歸屬不清，形成難以清理的技術債。
Façade 屬過渡階段的務實選擇，定位為通往 Native FHIR 的橋樑，永遠停留舊架構屬次要想像。若未來循序漸進朝 Native FHIR 發展，第一階段應把 Façade 責任邊界切乾淨，維持唯讀介面，並將 FHIR API 與底層 HIS 解耦。未來特定領域從既有 HIS 移轉到 Native FHIR 時，上層系統仍使用相同 FHIR API，無需隨底層資料來源大幅修改。Façade 定位為橋，重點在銜接過渡，終點想像居次。橋蓋得乾淨，未來才有機會逐步走向 Native FHIR，避免留下更難處理的技術債。
務必考量長期維護與升級
把時間拉長來看：今天設計的架構，是否能承受未來 FHIR 版本演進的變化？目前 TW Core IG 主要建立在 FHIR R4 基礎上，FHIR 標準持續發展。新版本逐步成熟，系統升級屬遲早需面對的課題。關鍵在於現在架構是否預留安全、可控制的升級路徑，至於是否升級居次。此時，Native FHIR 與 Façade 二種架構挑戰各有不同。
Native FHIR 優勢在於資料本身以 FHIR Resource 儲存，架構一致性與資料存取效率較高；但遇到 FHIR 大版本升級時，影響範圍超越 API，涵蓋既有 Resource、Profile、Extension、Search Parameter、驗證規則，以及底層累積的大量資料。版本升級屬需審慎規劃的資料遷移工程。相較之下，Façade 若一開始就維持清楚責任邊界，並以唯讀（Read-only）為原則，底層 HIS 仍為唯一權威資料來源，面對 FHIR 版本升級時彈性較高。主要調整範圍集中在 Façade 的 API、Mapping 與轉換邏輯，無需大規模搬動既有 HIS 核心資料。
此差異說明，預算、人力與時間有限的情況下，設計良好的 Façade 屬更具韌性的過渡架構，退而求其次的想像居次。此架構讓醫院先取得 FHIR 標準化介面價值，同時保留未來逐步朝 Native FHIR 演進的空間。因此，畫下下一張系統架構圖前，應優先釐清：Source of Truth 定位在哪裡？每一層系統責任邊界是否足夠清楚？今天的設計，未來是否能被替換、升級、淘汰？無論選擇一步到位的 Native FHIR，還是循序漸進的 Façade，重點在於把資料來源、讀寫責任與系統邊界劃清楚，架構名稱居次。邊界清楚，架構才有演進空間；邊界模糊，今天的捷徑容易成為明天的技術債。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
