口述╱孫培然‧彙整校訂╱CIO 編輯室
前一篇談到 Native FHIR 與 Façade FHIR 的架構選擇，但架構選定之後，真正的考驗才開始。
FHIR 在初期導入時，資料量通常不大，使用情境也多半集中在資料交換、API 串接或驗證，因此許多架構上的問題不容易立即顯現。當系統正式上線，Patient、Encounter、Observation、DiagnosticReport、MedicationRequest 等臨床資料持續累積，查詢條件也愈來愈複雜，原本可以正常運作的架構，就可能逐漸出現效能問題。
如果再進一步導入 Clinical Quality Language（CQL，臨床品質語言）與 Clinical Decision Support（CDS，臨床決策支援），FHIR Server 面對的就不只是資料交換，而是必須在臨床作業過程中，快速提供決策所需的資料。
因此，本篇延續前一篇的架構討論，進一步從資料規模、查詢效能、CQL／CDS，以及系統維運四個面向，討論 FHIR 從介接服務走向正式臨床應用後，需要注意的幾項問題。
架構選擇後的效能代價
對仍使用既有 HIS 的醫院而言，Façade FHIR 是相對務實的導入方式。既有資料不需要全面搬移，可以透過 API Gateway、Connector 或 Mapping Layer，將 HIS 資料轉換成符合 FHIR Profile 的 Resource，再提供給外部系統使用。
這種方式可以降低初期系統改造與資料移轉的成本，但隨著使用情境增加，轉換層所承擔的工作也會跟著增加。
例如原本只是查詢 Patient，後來可能增加 Encounter、Observation、MedicationRequest，再進一步出現多個 Search Parameter、跨資料表 Join、_include、_revinclude 或跨 Resource 關聯。Façade 除了查詢既有 HIS，還必須完成資料轉換、Mapping、Resource 組裝與輸出，效能調校會逐漸變得複雜。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
Native FHIR 則不同。當資料本身就是以 FHIR Resource 為主要模型時，可以直接依照 FHIR 的查詢方式設計 Search Parameter、索引、快取與資料存取策略，在大量查詢及後續擴充上通常有較大的調整空間。
但 Native 也有明顯成本。對累積多年歷史資料的醫院而言，要讓 FHIR Server 逐步成為主要資料來源，必須處理資料清理、轉換、驗證、移轉，以及既有 HIS 的改造問題，不適合只從效能角度決定是否採用。
因此，對多數仍有舊 HIS 的醫院而言，初期先採 Façade，建立清楚的資料與讀寫邊界，再依系統改造進度將適合的領域逐步往 Native FHIR 移動，會是比較容易落地的方式。
需要特別注意的是混合架構。如果部分資料由 HIS 維護，部分資料又直接寫入 FHIR Server，就必須明確定義各類資料由哪一套系統負責維護，以及資料的讀寫與同步邊界。如果沒有事先釐清，後續很容易衍生雙向同步、資料衝突與資料不一致等問題。
迎戰海量資料擴張
當 FHIR 資料開始大量累積，架構差異就會逐漸反映在實際效能上。
FHIR Server 的效能問題不只來自寫入。資料規模增加之後，更常遇到的是查詢路徑、Search Parameter、資料庫索引，以及跨 Resource 關聯所產生的成本。
當資料從數十萬筆增加到數百萬、數千萬筆時，如果仍沿用系統初期的索引設計，即使增加 CPU、Memory 或資料庫資源，改善效果也可能有限。
以 Observation 為例，臨床上很常出現這樣的查詢：patient + date + code，也就是查詢「某位病人在某一段期間內，特定檢驗或觀察項目的結果」。
這類查詢本身並不特殊，但資料量大之後，如果 patient、date、code 只有個別索引，而沒有依照實際查詢模式規劃適當的複合索引（Composite Index），資料庫可能需要掃描大量資料，再進行篩選或排序。
[ 閱讀所有 孫培然 之專欄文章 ]
因此，FHIR Server 的索引不應只依 Resource 欄位逐一建立，而要回到實際的臨床使用情境，分析哪些 Search Parameter 經常一起出現，再決定複合索引或覆蓋索引（Covering Index）的設計。
Façade FHIR 在這裡會多一層考量。因為底層 HIS 的資料結構原本不一定是為 FHIR Search 所設計，同一個 FHIR 查詢可能需要轉換成多個舊資料表的 Join，再進行 Mapping 與 Resource 組裝。資料量愈大，這一層的成本就愈需要注意。
Native FHIR 在這方面通常有較大的調校空間，可以依 FHIR 的實際存取方式規劃索引、Cache、讀寫分離，必要時也可以搭配 Elasticsearch 等搜尋引擎處理特定搜尋需求。
另外，FHIR API 本身也有一些容易被忽略的最佳化方式。例如使用 _summary 或 _elements，只回傳實際需要的欄位，可以減少 Resource 序列化、網路傳輸及前端處理的資料量。
除了查詢效能之外，另一個需要提早規劃的是資料生命週期。
Patient、Encounter、Observation、MedicationRequest 等 Resource 會隨著臨床使用持續增加；如果系統同時保留 Resource Version History、Provenance、Audit 等資料，實際儲存量與索引規模還會持續成長。
不見得所有資料都需要長期放在成本最高、查詢速度最快的儲存層。因此，可以依照資料使用頻率與保存需求，規劃 Hot、Warm、Cold 分層。
Hot Layer 放置近期且經常被臨床查詢的資料；Warm Layer 保存查詢頻率較低，但仍可能需要快速調閱的歷史資料；Cold Layer 則可以依醫院保存政策，處理較少使用的歷史版本、稽核或長期保存資料。
實際分層方式仍需配合醫院的法規、臨床需求、FHIR Server 特性及基礎設施能力，不能只用資料年份作為唯一條件。
臨床決策支援對效能的要求
如果一般 FHIR Search 是在測試資料查詢能力，那麼 CQL 與 CDS 則進一步把效能問題帶進臨床工作流程。
當醫師開立處方、醫囑或進行診療決策時，CDS 必須取得病人的相關資料，執行規則判斷，再把結果回傳給使用者。這時系統效能就不只是資訊室關心的技術指標，而會直接影響醫師的操作經驗。
許多既有 HIS 並不是以 CDS Hooks 的事件模式設計，因此導入 CDS 時，通常需要額外建立 CDS Service，負責接收 Hook、取得 Context 或 Prefetch 資料、執行 CQL 或其他臨床規則，再將結果回傳給 HIS 前端。
這類服務最需要注意的是 Latency（延遲）。
如果醫師每開立一筆醫囑，都必須等待數秒鐘才能取得 CDS 回應，久而久之不但影響操作流程，也可能降低使用者對提示訊息的接受程度。
因此，高即時性的 CDS 應以低延遲為設計目標。實際要求必須依醫院流程與應用情境訂定；如果專案內部將 500 ms 設定為效能目標，就必須把這 500 ms 視為整條服務鏈共同使用的時間預算，而不是只計算 CQL Engine 本身的執行時間。
從 HIS 觸發 Hook、取得資料、FHIR Search、資料轉換、網路傳輸、執行 CQL，到最後產生 CDS Card，每一個步驟都會增加延遲。
這也是 CDS Hooks Prefetch 值得重視的原因。
如果 CDS Service 所需要的 Patient、Encounter、Condition、Observation、MedicationRequest 等資料，可以在第一次請求時透過 Context 或 Prefetch 一併準備，就可以減少 CDS Service 在執行規則期間反覆呼叫 FHIR Server。
這時 Native 與 Façade 的差異又會出現。
Façade 在收到請求後，可能還需要從既有 HIS 的多個資料表查詢資料，完成 Join、Mapping 與 FHIR Resource 組裝，再交給 CDS Service。這不代表 Façade 無法支援 CDS，而是需要更仔細規劃 Cache、Prefetch、預先計算及資料同步策略。
Native FHIR 因為資料已經以 FHIR Resource 為主要模型，在 Search、Prefetch、Cache 與索引最佳化方面通常比較直接。
所以在規劃 CQL／CDS 時，不應只測試「規則能不能執行」，還要測量從臨床事件發生到結果回到使用者畫面的 End-to-End Latency。這個數字才比較接近使用者真正感受到的系統效能。
技術之外的維運風險
FHIR 專案還有一項容易被低估的問題，就是知識集中。
FHIR 的導入牽涉醫療流程、HL7 FHIR、TW Core IG、Profile、Extension、Terminology、Search Parameter、API、資料庫與系統架構。如果團隊只有少數人了解整體設計，一旦人員異動，系統後續維護與升版就可能受到影響。
軟體工程常以 Bus Factor（公車因子） 描述這類風險。重點並不是團隊一定要有很多 FHIR 專家，而是關鍵知識不能只存在某一位工程師的腦中。
因此，FHIR 專案從一開始就應該同步建立文件，包括架構決策紀錄（Architecture Decision Record, ADR）、FHIR Profile 與 HIS 欄位 Mapping、Terminology 對應、API 規格、資料流、部署方式、測試案例，以及重要的例外處理原則。
文件也不能只在驗收前補齊。當 TW Core IG、FHIR Package、Terminology 或內部 Mapping 調整時，相關文件應跟著版本更新。
團隊內部則可以透過 Code Review、技術分享及實作案例累積共同經驗，同時持續追蹤 TW Core IG 與相關規範的更新，必要時與 HL7 Taiwan 或相關社群交流。
回到本篇的主題，當 FHIR 從資料交換逐步走向正式臨床應用，真正需要處理的已經不只是「FHIR Server 能不能跑」，而是資料量增加之後能不能維持合理的查詢效能，以及進入 CQL、CDS 等臨床決策情境後，能不能提供足夠穩定且低延遲的服務。
對仍有大量既有 HIS 的醫院而言，Façade FHIR 仍然是務實的起點；但在設計之初，就應該保留未來往 Native FHIR 演進的空間，同時把 Search、Index、資料生命週期與 CDS 的效能需求納入架構規劃。
FHIR 架構的價值，不在於今天採用了多少新的技術，而在於幾年之後，當資料規模增加、規範持續演進、臨床需求改變，甚至團隊成員更替時，這套系統仍然能夠維護、調整與持續演進。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
