口述／孫培然·彙整／CIO編輯室
在醫療資訊系統（HIS）與臨床決策支援服務（Clinical Decision Support；CDS Service）之間進行資料傳輸時，整體流程必須遵循標準化的資料格式與資訊安全機制，以確保傳輸過程中的正確性與完整性。這樣的資料交換設計不僅提升系統間的互通性，也為臨床決策提供了穩固的資料基礎。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 IG，與全球CIO同步獲取精華見解 ]
CDS Service 結構五大要素
整體資料架構可歸納為五大核心要素。流程起始於 HIS 系統觸發一筆 Hook 事件，並指派一組全域唯一識別碼（UUID）。接著，HIS 將相關資訊整合封裝，包括 FHIR Server 的連線位址、Hook 結構內容、OAuth 授權資訊、上下文內容（Context）以及預取資料（Prefetch）。分述如下：
- FHIR Server 位址
首先，系統需指定目標 FHIR Server 的端點 URL。CDS Service 將透過此連線位址與 FHIR Server 溝通，以擷取與病人相關的醫療資源，支援後續的決策分析。 - Hook 訊息結構
Hook 是 CDS Hooks 標準中關鍵的觸發機制，用來描述當前的臨床情境，例如病人資料檢視（patient-view）、處方開立（medication-prescribe）等。每筆 Hook 請求必須包含 Hook 名稱、一組由 HIS 系統產生的唯一 Hook Instance ID、事件觸發的時間戳記，以及發起者的使用者識別資訊。這些資料能幫助 CDS Service 精確理解觸發背景並作出對應分析。 - OAuth 授權資訊
為了確保資料存取的安全性與授權合法性，CDS Service 必須遵循 OAuth 2.0 認證流程，以取得 FHIR Server 的授權憑證。相關授權資訊包含：access token、token 類型（通常為 Bearer）、有效期限（expires_in）以及授權範圍（scope），例如 patient/*.read。透過這樣的設計，系統能有效防止未經授權的資料查詢行為。 - Context（上下文內容）
Context 是此次臨床情境的核心描述，涵蓋病人識別碼（patientId）、執行操作的使用者 ID（如主治醫師帳號）、就診紀錄 ID（Encounter ID）等。視情境需求，也可加入如 MedicationRequest 等特定資源的參考，提供 CDS Service 足夠的背景資料作為判斷依據。所有 Context 資訊皆應依照 FHIR Resource 的參考格式建構，以利後續資源存取。 - Prefetch（預取資料）
為提升反應速度與整體體驗，HIS 系統可主動將預期會被使用的 FHIR 資源資料一併打包於請求中，這稱為預取機制（Prefetch）。透過 JSON 格式，將例如病人基本資料（Patient Resource）、處方資訊（MedicationRequest Bundle）等提前載入，讓 CDS Service 不需再逐一向 FHIR Server 查詢。這不僅減少 API 呼叫次數，也降低資料庫負載，有助於系統效能與穩定性的提升。
透過上述五大資料結構元素的整合與標準化實作，HIS 系統與 CDS Service 可實現高效率、高安全性的資料交換機制。這是推動智慧醫療與臨床決策自動化的重要基礎，亦是未來各類醫療決策支援應用得以發揮效益的關鍵架構。
最終透過 HTTP POST 請求傳送至 CDS Service 的端點。CDS 端收到請求後，會進行授權驗證與資料解析，並執行相應的決策模型，回傳建議卡片內容，例如警示訊息、處方替代建議或過敏提醒等，協助醫師做出更安全、準確的臨床判斷。
Context 與 Prefetch 的核心功能與應用
當談到 CDS Hooks 在智慧醫療中的運作架構時，Context（上下文內容）與 Prefetch（預取資料） 可說是整體臨床決策支援（CDS）服務得以即時、準確運作的兩大核心支柱。這兩項機制分別負責提供情境導向的資源指引，以及預先備妥的臨床資料，使得 CDS Service 在接收到 HIS 系統的請求後，能立刻啟動判斷與建議生成的流程，而不需再回頭重複查找或等待資料取得。
Context 的角色就像是一張路線圖，清楚標示出此次決策場景中有哪些關鍵角色與資源參與。像是病人的識別碼、主責醫師的帳號 ID、或者本次就診的紀錄 ID，都會以符合 FHIR 標準的格式，例如 “patient”: “Patient/12345″，一併附加在請求中。這樣的設計讓 CDS Service 可以直接使用這些資源參考，從指定的 FHIR Server 取得所需資料，不需再向 HIS 發出額外請求。
實際運作中，這樣的 Context 設計能讓系統依據不同臨床情境自動取得所需資訊。例如在醫師開啟病人畫面時，系統便會透過病人 ID 自動擷取病史資料；在開立處方的階段，CDS Service 則可根據看診紀錄分析當下處方的合理性；當醫師查閱檢驗報告時，Context 也能導引系統查詢該病人最新的檢驗結果，並即時給予風險警示。
至於 Prefetch，則可視為系統事先打包好的一組臨床資料行李。它的設計理念是：既然 HIS 已能預見 CDS Service 接下來可能會需要哪些資料，那麼不如在請求發送之前就一併準備好，主動將這些 FHIR 資源一起送出。這樣一來，CDS Service 接手時便可立即進行分析判斷，而不需再分次呼叫 API 查詢相關資料。
總結來說，Context 就像是引導 CDS Service 找到關鍵資源的導航系統，而 Prefetch 則像是事先備妥、隨時可用的資料行囊。兩者相輔相成，只要在系統設計時善加利用，便能顯著提升 CDS 應用的即時性與可靠性，不但減輕醫護人員操作上的負擔，也為智慧醫療的落地鋪出更有效率且更安全的道路。
CDS Cards 建議卡片的功能與應用價值
在 CDS Hooks 的整體架構中，當 CDS Service 完成資料擷取與分析後，會回傳一組稱為 CDS Cards（建議卡片） 的結果，用以即時支援醫師在臨床上做出判斷與決策。這些卡片不僅僅是資訊的呈現介面，更是醫師在看診或處置時的重要參考依據，能有效提升診療效率與病人安全。
根據功能定位與互動程度的不同，CDS Cards 可分為三種類型，每種類型皆對應不同的臨床應用情境，並具備特定的設計邏輯與目的。
首先是資訊卡（Information Card），這類卡片的設計重點在於提供關鍵的背景說明與風險提醒，讓醫師能更全面掌握當下病人的醫療狀況。資訊內容可能包括藥物費用、自費比例、病人生理指標異常等。例如：「該藥物費用為 $200，病人自付額為 $30」，或是「病人的腎功能指數（eGFR）偏低，建議審慎評估用藥風險」。資訊卡通常不具備互動按鈕，其目的並非引導即時行動，而是提供補充資訊作為決策的背景參考。
其次是建議卡（Suggestion Card），這類卡片具備互動性，醫師可依臨床判斷點選「接受」或「忽略」等選項。常見的應用情境像是當系統偵測目前處方藥品價格偏高時，會建議改用具相同療效但成本較低的藥物；又或是在偵測病人腎功能下降時，提示應調整藥物劑量，如將 Metformin 劑量由 1000mg 減為 500mg。若醫師接受建議，HIS 系統可自動修改處方、更新內容並送出，無需額外操作，實現「建議即執行」的一站式流程，大幅減少重工與潛在錯誤。
最後是智慧連結卡（Smart App Link Card），這種卡片通常出現在 CDS Service 資料尚不足以產出明確建議時，系統會引導醫師前往可信的外部資源或應用程式查詢更多資訊。例如系統可能提供高血壓臨床指引（如 JNC 8）的連結，或引導醫師使用腎功能計算工具（如 GFR Calculator）進一步評估病人狀況。這類卡片通常整合 SMART on FHIR 標準，點選後可直接開啟外部應用，無需跳離 HIS 系統介面，讓使用者在不中斷診療流程的前提下，取得更具深度的專業支援。
綜觀這三種卡片的應用模式，不論是用於資訊提醒、具體建議，或外部資源導引，CDS Cards 的彈性與即時性皆能有效提升臨床決策品質。這套設計也正體現了智慧醫療的核心精神：以技術輔助醫師做出更快、更準、更安全的診療判斷，進而落實數位轉型的醫療願景。
CDS Service互動式臨床決策支援情景
在實際臨床看診情境中，CDS Hooks 的設計核心，正是為了讓醫師能在不中斷原有看診流程的前提下，即時取得決策輔助。這樣的設計理念，使得 CDS Service 能夠無縫地整合至 HIS 系統操作中，不再是額外流程或負擔，而是診療過程的自然延伸。
整體互動體驗極為直覺，醫師在 HIS 系統中查看病人資料或開立處方時，系統會自動觸發對應的 CDS Hook，將相關資料打包傳送至 CDS Service。接著，CDS Service 分析資料後回傳一張或多張建議卡（CDS Cards），由 HIS 系統即時在原畫面中顯示，醫師可直接採取行動，無需切換系統或另外查詢。這種設計不僅提升使用便利性，也強化醫師對智慧輔助機制的接受度與依從性。
以糖尿病病人的視網膜篩查為例，傳統流程中，醫師若想確認病人是否在過去一年內完成視網膜攝影，往往需手動切換至檢驗報告系統，查詢病人是否曾接受相關檢查或轉診記錄。若查無結果，還需進一步跳轉至其他系統以開立篩查檢查單或轉診申請。整個過程繁瑣，不僅容易中斷門診節奏，也降低了臨床效率與準確性。
然而，透過 CDS Hooks 的智慧輔助機制，這樣的作業可被大幅簡化。當醫師進入病人畫面時，patient-view Hook 即被自動觸發。CDS Service 隨即根據病人 ID 從 FHIR Server 擷取相關關鍵資訊，包括最近一次的 HbA1c（糖化血色素）檢查結果，以及病人在過去一年內是否曾接受視網膜檢查。若發現病人尚未接受篩查，系統將回傳一張警示卡片，明確提示：「病人未於過去一年內接受視網膜檢查，建議立即安排」，並附上「安排視網膜篩查」的操作按鈕，醫師只需一鍵點選，即可完成檢查單開立的流程。若進一步偵測到病人的 HbA1c 大於 7%，代表血糖控制不佳，卡片也會同步強調：「病人血糖控制不佳（HbA1c > 7%），建議優先安排視網膜檢查」，提升醫師對風險的敏感度與警覺性。
[ 閱讀 孫培然 所有專欄文章]
這樣的設計，讓醫師得以專注於病人本身，不需再為查找資料與系統跳轉分神。系統會主動完成檢查資料的分析、建議卡片的產出、與後續檢查流程的串接。醫師只需根據提示採取行動，檢查單便可自動送出，或是直接更新醫囑內容，真正實現資料與決策的無縫串連。
這個案例具體展現了 CDS Hooks 在臨床場景中的價值：不只是被動呈現建議，而是能主動整合資訊、驅動行動、優化流程。它讓智慧醫療從願景走向實踐，也證明在提升診療效率與病人照護品質的路上，CDS Hooks 架構具備極高的實用性與可延展潛力。未來無論應用於高血壓管理、慢性腎病追蹤，或其他慢性病照護情境，皆可依相同邏輯進行擴展與延伸，成為智慧決策支援不可或缺的基礎骨幹。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
