醫學文獻網路分享

口述／孫培然·彙整／CIO編輯室

CDS Hooks（Clinical Decision Support Hooks）是由 HL7 提出的標準化臨床決策支援框架，透過整合數據、醫學知識庫和機器學習等資源，為醫療人員提供即時建議，提升臨床決策的精確性與效率。

[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球CIO同步獲取精華見解 ]

CDS Hooks 允許 HIS 在特定情境下觸發外部臨床決策支援服務（CDS Service），例如 AI 或近期廣受關注的 AI Agent，這些服務可透過 Hook 機制無縫嵌入 HIS，強化臨床輔助能力，使醫師能夠更快、更準確地獲取關鍵資訊，優化診療流程。

需要 CDS Hooks 的原因

為什麼需要 CDS Hooks？CDS Hooks 的必要性在於現代醫療系統每日需處理大量病人數據，包括診斷結果、檢驗數據、用藥記錄等，資訊量極為龐大，使臨床醫師難以在有限的診療時間內完整分析所有資訊。然而，診斷時間有限，傳統 HIS 難以即時提供臨床決策支援，導致醫師可能遺漏重要資訊。

因此，透過臨床品質語言（Clinical Quality Language, CQL）、AI 或大型語言模型（Large Language Model, LLM）結合 FHIR，可提供即時且精準的臨床建議。

透過 CDS Hooks，可以實現 HIS 及 AI 的無縫整合，進一步強化決策支援應用。例如，在 HIS 中，CDS 可在特定事件（Hook）發生時，自動向外部系統發送請求，執行藥物交互作用分析、醫囑檢查、自動分析病人病史，並提供個人化建議。如此一來，AI 便能直接為臨床決策提供有價值的資訊，醫師無需額外查詢資料，即可根據最新的醫學知識輔助臨床診斷，減輕醫療決策負擔，提升診療效率與病患照護品質。

CDS Hooks 的運作原理

CDS Hooks 的運作原理可分為下列幾個步驟，如圖所示：

第一步：事件觸發（Hook 觸發）
當醫師在開立處方、檢視病歷或開立醫囑時，HIS 會根據這些事件觸發對應的 Hook，啟動臨床決策支援流程。
第二步：請求 CDS 服務
HIS 透過 RESTful API 向 CDS 服務發送請求，並包含病人相關的 FHIR 資源（如病史、檢驗結果、處方等），以便 CDS 服務獲取完整的病人背景資訊。
第三步：分析與決策支援
CDS 服務接收 HIS 傳送的 API 請求後，根據傳入的 FHIR 資料，整合臨床品質語言（CQL）、人工智慧（AI）或大型語言模型（LLM）進行分析，並依據臨床知識庫、風險評估模型或機器學習演算法產生適當的決策建議。
第四步：顯示建議與醫師決策
產生的決策建議會以建議卡片（Cards）形式呈現在 HIS 介面上，供醫師查看、採納或忽略，同時 HIS 也會記錄醫師的決策結果。建議卡片可分為三種類型：
˙資訊卡（Information Card）：提供相關資訊供醫師參考。
˙建議卡（Suggestion Card）：提供具體的建議方案供醫師選擇。
˙應用程式連結卡（App Link Card）：提供連結至應用程式（通常是 SMART 應用），醫師可在其中獲取詳細資訊或執行進一步操作。

這些步驟協同運作，旨在提升臨床決策的精確性與效率，確保醫師在診療過程中獲得即時且有價值的支援。

當醫師開立某項處方藥品時，系統會觸發名為 medication-request 的 Hook，這個 Hook 代表 HIS 系統中的特定行為或事件。除了開立處方，還可能包括開啟病人紀錄、查看檢驗檢查報告等。實際上，這個過程就是透過 CDS API Endpoint 呼叫 CDS Service，以處理 medication-request。

[ 推薦文章：即插即用的醫療資訊系統 ]

CDS Service 會查詢 FHIR Server 以獲取病人數據，並執行 AI Agent 決策引擎，分析病人是否適合該處方，或根據最新的臨床指引提供建議。最終，CDS Service 會以資訊卡、建議卡或智慧連結卡的形式回傳決策建議，呈現在醫師的 HIS 畫面上，幫助醫師更精準地做出臨床決策。

接下來，系統會根據建議卡提供的資訊，產生 JSON 格式的回應，並依照建議卡片的內容動態生成使用者介面。這個介面將呈現在 HIS 系統中，供醫師參考並進行臨床決策，使醫師能夠根據建議選擇採納、忽略，或進一步查看相關資訊，從而提升決策的精準度與診療效率。

CDS Hooks 核心元件

CDS Hooks 可以分為三大核心元件，首先是臨床決策服務清單（CDS Service List），提供給使用者查詢可用的 CDS Service，讓 HIS 瞭解有哪些決策支援服務可以使用。每個 CDS Hooks 服務都需要有一個固定的 Endpoint，供 CDS Client（如 HIS）請求可用的 CDS Service 清單。其中每個服務都對應一個特定的 Hook（如 patient-view），並提供具體的決策支援內容。

這個清單需遵循一定的規範結構，也就是第二個核心元件 – CDS Service 資料結構。CDS Service 必須符合規範的結構，才能在透過 AI 或臨床知識庫分析後，正確產生決策建議，確保資訊的完整性與一致性。

當 CDS Service 完成分析後，會產生第三個核心元件 – CDS Cards（建議卡片）。這些建議卡片向臨床醫師提供相關資訊或決策建議，並可進一步觸發其他應用程式（如 SMART on FHIR 應用），協助醫師獲取更深入的輔助資訊，讓臨床決策更精準、更有效率。

提高反應速度的 Prefetch 機制

為了減少 API 調用次數並提升決策支援的反應速度，CDS Service 註冊時可以定義一組預取模板（Prefetch Template），用來指示 HIS 等客戶端在呼叫 CDS Service 之前，應預先取得哪些 FHIR 資源，這就是 Prefetch 機制。

Prefetch 機制的優勢在於，HIS 可以提前獲取所需的 FHIR 資料（如病人資訊），避免每次請求時 CDS Service 還需要額外查詢 HIS，進而減少延遲。同時，也能真正實現解耦，使 CDS Service 不受特定 FHIR Server 的限制，提升系統的靈活性與適應性。

[ 閱讀孫培然所有文章]

舉例來說，當 HIS 需要評估某種特定藥物（例如 Toprol XL）是否適合病人時，CDS Service 會先收到來自 HIS 的請求，其中包含處方計劃、病人的基本資訊及診斷碼。CDS Service 隨後會從請求中提取 Prefetch 數據，如病人的性別、年齡和診斷碼，並根據這些數據進行評估。例如，病人的診斷碼為 I21（心肌梗塞），根據臨床指南，CDS Service 可能建議該病人使用阿司匹林作為二級預防。

CDS Service 接著會生成建議卡片（Cards），提示醫師考慮使用阿司匹林，並提供相關的資訊卡片，例如心臟病個案應用的連結。最後，CDS Service 將建議回傳至 HIS，醫師便可在 HIS 介面上查看建議，並依據結果做出決策。

(本文授權非營利轉載，請註明出處：CIO Taiwan)