～FHIR 風險評估及最佳實務（1）
口述╱孫培然‧彙整╱CIO 編輯室
如果你正在規劃導入 FHIR，或正面臨醫療資料整合與互通的挑戰，本文將提供一套實務導向的風險分析框架做參考。
FHIR 已成為全球醫療資訊互通的重要標準，但真正的挑戰是架構設計、系統整合、資料治理與實作細節。許多專案的問題，是初期架構決策失當，導致技術債持續累積，影響系統的可擴充性、互通性與長期維護成本。
本文以臺灣核心實作指引（TW Core Implementation Guide；TW Core IG）第一版為基礎，結合實務導入經驗，整理出 24 項核心風險議題，涵蓋基礎設施、效能與資訊安全、核心架構決策，以及 TW Core 在地化規範四大面向。
為了協助讀者快速掌握重點，本文採用風險分級（Risk-Based Approach）分析架構，依風險程度分為低、中、高風險及臺灣在地化規範四個層次，說明各項議題對專案的影響，以及相對應的最佳實務建議。
低風險的基礎設施前提
所謂「低風險」，指得是即使前期設計有所疏漏，後續仍有機會透過重構逐步修正，不致影響整體架構。然而，若能在專案初期建立完善的基礎設施，將能有效降低技術債（Technical Debt）的累積，並大幅減少後續維護、整合與除錯成本。
在這個階段，資料來源追蹤（Provenance）與資料驗證（Validation）是醫療資料交換最重要的兩項基礎能力，也是建立可信賴資料流的第一道防線。
以資料來源追蹤（Provenance）為例，建議從系統設計初期就建立一致性的來源管理機制，善用 Meta.tag 記錄來源系統、匯入管道及資料類型。這些看似不起眼的標記，在跨系統除錯、資料稽核或異常資料追蹤時，能快速定位問題來源，避免因資料來源不明而耗費大量人力與時間。
另一方面，資料驗證（Validation）應納入持續整合／持續部署（CI/CD）流程，系統應事先定義哪些情況僅產生警告（Warning），哪些錯誤必須直接拒絕（Reject），透過自動化驗證機制，在正式上線前即確保資料品質。
最後，在測試與驗證環境中，建議全面採用假名化（Pseudonymization）或其他適當的去識別化機制，兼顧測試需求、個人資料保護及法規遵循，建立符合醫療資訊治理要求的開發流程。
中風險的效能與資訊安全
如果說第一階段累積的是可逐步修補的技術債，那麼從這個階段開始，任何設計上的疏忽，都可能隨著系統規模擴大而快速放大，最終成為影響系統效能、穩定性與使用體驗的關鍵瓶頸。
首先，是查詢參數（Search Parameters）的設計。
FHIR 提供強大的查詢能力，但若在系統開發初期未妥善規劃查詢參數與索引策略，當面對病人、就醫日期、代碼等多條件組合查詢時，資料庫將無法有效利用索引，只能進行全表掃描（Full Table Scan），導致查詢效能大幅下降。
許多團隊習慣以全文檢索（Full-text Search）改善查詢速度，尤其是連鎖查詢（Chained Search）與反向連結查詢（Reverse Chaining），若缺乏完善的查詢策略與索引設計，在高併發環境下很容易耗盡系統資源，成為整體平台的效能瓶頸。
除了效能之外，資訊安全更是核心要求。
在 SMART on FHIR 授權架構下，每一個存取權杖（Access Token）都應明確定義可存取的資源、操作範圍及權限，避免任何越權存取的可能性。尤其在臺灣《醫療法》及《個人資料保護法》的規範下，所有涉及個人健康資訊（Protected Health Information；PHI）的存取，都應透過稽核事件（AuditEvent）完整記錄使用者、存取內容、時間及操作行為，以符合醫療資訊治理與法規遵循要求。
談到智慧醫療應用，則必須重視臨床決策支援（Clinical Decision Support；CDS）的效能。
在實作 CDS Hooks 時，建議遵循業界普遍採用的 500 毫秒法則。從臨床流程觸發決策支援，到系統完成回應，應盡量控制在 500 毫秒內，才能維持流暢的使用體驗。
因此，CDS 服務應避免於執行過程中再次大量查詢 FHIR Server，應預先準備所需資料，或透過快取（Cache）及事件驅動（Event-driven）架構降低延遲。若決策支援回應過慢，或因演算法準確度不足而頻繁產生不必要的警示，最終將造成警示疲勞（Alert Fatigue），使醫護人員逐漸忽略甚至關閉系統提醒，失去臨床決策支援應有的價值。
高風險的核心架構決策
這是整個 FHIR 專案最關鍵的分水嶺。許多技術問題可以透過重構改善，但核心架構一旦選錯，往往需要付出數倍以上的成本才能修正。因此，每一項架構決策都應以系統未來五年至十年的演進需求為考量。
首先，團隊必須回答一個根本問題：究竟應採用原生 FHIR（Native FHIR）架構，還是外觀模式（Facade Pattern）？
原生 FHIR（Native FHIR）以 FHIR Resource 作為唯一的事實來源（Single Source of Truth），所有核心業務皆建立在 FHIR 模型之上。雖然初期資料移轉與系統改造成本較高，但架構一致性佳、擴充容易，適合新建系統或大型數位轉型專案。
相較之下，外觀模式（Facade Pattern）是在既有 HIS 外建立一層 FHIR API，保留原有資料模型，快速提供資料交換能力。雖然導入速度快，但面對複雜查詢、多資源交易（Transaction）及雙向寫入時，系統複雜度將快速提高，也更容易累積技術債。若採用混合架構，更應明確定義資料主體（System of Record）、資料寫入權責及同步機制，避免責任邊界不清，造成後續維護困難。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
另一項攸關跨院資料交換的重要議題，是識別碼（Identifier）的設計。
FHIR Resource 的 ID 僅是 FHIR Server 內部的唯一識別碼，不應作為跨系統交換的業務主鍵（Business Key）。真正具有業務意義的識別方式，應建立在 Identifier.system 與 Identifier.value 的組合之上。此外，建立主病人索引（Master Patient Index, MPI）或主資料管理（Master Data Management, MDM）機制，也是跨院病歷整合不可或缺的基礎。
除了架構設計，資料生命週期管理（Data Lifecycle Management）同樣不可忽視。
以觀察（Observation）資源為例，病人多年累積的生命徵象、檢驗結果及穿戴式裝置資料，很容易讓資料量快速成長至數億筆。因此，建議依資料使用頻率採用分層儲存策略：熱資料（Hot Data）保留於線上提供高速查詢；溫資料（Warm Data）壓縮保存，必要時再還原；冷資料（Cold Data）則移轉至物件儲存（Object Storage）或封存平台，以兼顧法規遵循與儲存成本。
另一項影響資料即時交換的關鍵，是 HIS 與 FHIR 的同步機制。
建議優先採用變更資料擷取（Change Data Capture；CDC）技術，由 HIS 擷取資料異動，再透過 Debezium 讀取交易紀錄（Transaction Log），送至事件驅動的 串流平台，即時轉換為 FHIR Resource。若既有 HIS 不支援 CDC，而只能透過定時輪詢（Polling）同步資料，不僅系統負載較高，也難以滿足智慧醫療對即時資料交換的需求。
最後，也是最容易被忽略的風險──知識管理（Knowledge Management）。
許多專案最大的風險，是關鍵知識集中在少數人身上。一旦核心成員離開，後續維護人員往往需要重新理解系統架構，造成維護成本大幅增加。因此，建議將資料對應規格（Mapping Specification）、架構決策記錄（Architecture Decision Record；ADR）、FHIR Profile 設計原則及介接規格納入正式文件管理，讓架構知識成為團隊可持續傳承的資產。
高風險的核心架構決策，影響的除了系統是否順利上線，還包括未來的可擴充性、跨院資料交換能力及長期維護成本。對 FHIR 專案而言，真正昂貴的是錯誤架構決策所付出的長期代價。
台灣專屬：TW Core
最後，我們將焦點拉回台灣，探討臺灣核心實作指引（TW Core Implementation Guide；TW Core IG）在實務導入時最容易被忽略的關鍵議題。
相較於通用 FHIR 規範，TW Core 更著重於台灣醫療資料交換需求，因此除了遵循 FHIR 標準外，還必須兼顧版本治理、套件管理、驗證機制及資料標準的一致性。許多專案最大的挑戰是這些基礎治理工作沒有做好，導致系統無法真正互通。
首先，是版本治理（Version Governance）。
TW Core 持續演進，不同醫療資訊系統可能採用不同版本的 Profile、ValueSet 或 Extension。跨系統交換前，除了確認 TW Core 版本外，也應同步確認合作系統所使用的 Profile 版本及相依規格，避免因版本不一致而產生交換問題。
其次，是 FHIR 套件（FHIR Package）與驗證工具（Validator）的管理。
開發、測試與正式環境應使用相同版本的 FHIR Package、Validator 及相關相依套件。實務上，許多驗證失敗是不同環境使用了不同版本的套件或驗證規則，造成驗證結果不一致，增加除錯與維護成本。
最後，是臺灣核心資料交換標準（Taiwan Core Data for Interoperability；TWCDI）與資料對應規則（Mapping Rules）。
TWCDI 是台灣醫療資料交換的重要基礎，從代碼系統（CodeSystem）、值集（ValueSet）到各項資料元素，都必須依規範正確對應。既有 HIS 往往存在院內代碼、空值定義不一致或資料語意不明等問題，因此必須建立完整且文件化的 Mapping Rules，明確定義來源欄位、FHIR 元素、標準術語及例外處理方式，必要時也應善用資料缺失原因擴充（Data Absent Reason Extension）保留原始語意，避免資料在轉換過程中失真。
TW Core 的導入，是建立一套具備一致性、可治理且可長期維護的資料交換機制。
最後，值得所有 CIO、架構師與開發團隊思考的問題：
目前打造的系統，是真正具備原生 FHIR（Native FHIR）的延展能力，還是只是在既有 HIS 外層包裝了一組符合 FHIR 規範的 API？
外觀模式（Facade Pattern）若缺乏完善的版本治理、套件管理、資料標準及對應規範，很容易從短期解決方案演變為長期的技術負擔。
希望本文整理的風險藍圖，能協助各位重新檢視目前的架構設計、驗證流程與治理機制，打造真正具備互通性、治理能力與長期演進能力的醫療資訊架構。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
