CDS Hooks - 規範 - 1

 HL7 CDS Hooks規範版本清單。本篇討論的是1.1的版本。

名詞定義

• CDS Service：透過RESTful API的機制，提供對病患之建議與指導的一種服務。API主要分成兩大類型：（我主要實作的部分。補充說明，是建置一個用於整合臨床決策支援系統之Gateway，不是臨床決策系統本身）
• Discovery：發布此CDS services提供了哪些服務。走GET Method。
• Service：真正提供決策支援服務的endpoint。走POST Method。
• CDS Clients：一般而言，就是電子病歷系統，或臨床資訊系統，會呼叫CDS Service來引用某決策支援服務。而這個呼叫流程，讓雙方連結起來的規範稱之為hooks。
• Cards：臨床決策支援系統回傳給CDS Client的內容所採用的規範稱之為cards。電子病歷系統可能(MAY)會將此內容轉譯並整合在使用者作業流程中。cards的內容包含有一些基本資訊外，可能會提供建議(suggestion)讓使用者接受(accept)或拒絕(reject)。也可能會提供一些外部連結(link)來提供額外的資訊，甚至可執行SMART app。(這邊還有一個東西是Feedback，如何處理使用者的回應)

Hooks

目前支援的Hooks如圖。其中兩個紅色叉叉是已經廢棄不用，第一個new-hook-template是你可以提出新的Hook需求。這是依據不同應用情境下，兩端系統對某些欄位之統一定義規範。目前大都是實作patient-view。

每一個Hook除了看看他的workflow定義外(知道應用情境)，主要還是看Context的內容。

這個內容是兩端共同的認知。CDS Service會說我的服務是用哪一個Hook，以patient-view為例，Key值就是圖中三個欄位。

接著CDS Service會在Prefetch Template(後敘)中告訴CDS Client，請提供哪些FHIR的Resource並利用上述鍵值完成查詢條件(當然不受此限，例如多上一些Code的限制)。

而CDS Client端，在使用者引發這個CDS服務時，也就是產生一個POST，就會再帶回這個Hook，但都已經有明確的值。

而Prefetch出來的FHIR Resource當然就是跟hook鍵值有關的資料。

==========

講到這邊，可能還是一頭霧水吧。標準這東西，乍看很難，說穿不值半毛錢。接著講細部規範，主要有三塊Discovery、CDS Service(HTTP Request)與Cards(HTTP Response)。
再來就是說明不用寫程式也可以測試的方法。
程式部分受限保密，也就不公開了。