CDS Hooks - 程式開發 - 簡易說明

開發CDS Hooks，其實不難，難的是你要提供什麼服務。

在此架構中，EHR是需求端，CDS Hooks是服務(回應)端。之間只有資料層面的交換，並沒有UI（網頁）內容呈現。（若有，那請走Smart on FHIR架構） 

本次系統開發採用C# DotNet 9，用Web API專案範本。（若Smart on FHIR就需MVC或Blazor） 

依據CDS Hooks規範，需要提供下列服務(Endpoint)

1. Discovery：讓EHR端知道CDS端提供了哪些CDS項目。 CDS端要告知每一項服務會走什麼Hook(這個會決定Context內容)，其id編碼是什麼（如Patient Id, Encounter Id）。然後可以順便告知，要使用這項服務的話，需先準備哪些FHIR Resource。上述內容CDS端會回傳services這個json檔。
2. CDS Service：有了上述服務清單，EHR端的使用者就要決定採用哪一項服務。EHR決定要呼叫那個服務時，就得先準備好幾項東西，例如Fhir Server在哪（若還要再撈其他資料，例如遇到Reference型態），fhirAuthorization相關資訊（若需要的話），還有Conttext所要求的Id內容，另外，當初在Discovery時，CDS端告知需要事先準備的FHIR Resource。CDS端收到資料後，經過處理，然後回傳card這個json檔。EHR端要負責解析呈現這個card json檔內容。
3. Feeback:：上一階段回傳的card內容，其實包含了很多按鈕宣告。而CDS端則需要接收EHR使用者到底按了那個按鈕的訊息，然後進行下一個步驟。例如刪除Resource或者新增Resource。

雖然，表面說來很容易，但為了系統彈性等因素，相關配套物件設計就不能少。例如：

1.  Prefetch的宣告：重點就是如何宣告一個Resource的查詢URL，而能夠效率最佳化。（不用一來一往，重複存取）
2. Hooks的選用：目前這塊也不是很穩定。向CDS Hooks Sandbox他也只支援patient-view與order-select。這塊會影響到Perfetch能產生多複雜的查詢語法。
3. Authorization設計：CDS Hooks與Smart on FHIR架構差距此為重要一點。CDS Hooks是請EHR端準備好Access Token相關資料，請一併送過來。而Smart on FHIR則是需要一段一段交握中取回。
4. Card的設計：這個是最困難的部份，因為要配合CDS端的設計，畢竟Card能夠處理的是有限的。CDS設計了太複雜的回應結果，是很難用Card來完整呈現。再來，Card是有EHR負責Render，所以，呈現的結果可能不會是CDS端所想要的。
5. Feeback設計：EHR端的回饋，其實是由CDS端決定的。也就是把按鈕設計在Card中。問題就是，能設計到多複雜，要細分到什麼程度？後續的處理模式刪除或新增，這個還得問問FHIR Server是否有開放支援。

總之，CDS Hooks並非像有些人口中所言，可以輕輕鬆鬆完成的事情。