CDS Hooks - 規範 - 4

今天討論「CDS Response」

CDS Response

CDS Service --> CDS Client

Response的前置作業

這個過程其實沒有這麼簡單。當CDS Client決定要引用CDS Server哪個Service時，就得遵守規定，把FHIR相關資源準備好後，叫用Service時，用POST帶上。如果用Postman測試時，在BODY的部分可選擇x-www-form-urlencoded(可減少設定)。

CDS Server從Endpoint接受到資料後，要開始解析。整個作業流程應該要分成四個重要階段。

1. 檢核Post 資料正確性。也就是說，傳回來的Hook跟當初規定的是否一樣。
2. 要解析fhirAuthorization。你要設計好流程，到底還要再跟FHIR Server要什麼東西。因為Access Token一般都是有時間限制(當然，還會有個Refresh Token的機制)。另外一點就是，他會有Scope的問題，就是Resource.Interactions。
3. 要解析prefetch的內容。這塊要小心。一般而言，若Read，原則上你要什麼Resource就會回給你什麼Resource。若你是用Search，那就會是Bundle，要再進一步解析entry才是你想要的Resource。
4. 取你CDS真正要的資料進行運算處理，然後得到結果。這個結果才是用來組出Response Object的資料。

這段講得輕鬆，但FHIR技術關鍵就在這兒。

Web的技術關鍵是OAuth與CORS。

Response Object

回傳一個物件包含兩個欄位cards與systemActions，兩個皆是陣列。systemActions在1.0版沒有。所以，最簡單的範例：這個Card，是由CDS Client決定要如何呈現在他們的系統中。在EPIC他們稱之為Best Practice Advisory，會將Card的內容轉成HTML Web介面。

{ "cards": [] }

Card Object

這個是有點複雜，還會衍生出幾個物件出來。我就簡單描述，會做的應該一點就懂。

uuid

這個是可選欄位。若你有處理到feedback階段的話，那這個就很重要。在C#有個GUID物件，很簡單處理。

summary

這個是必要欄位。將你的結果簡單描述。字串長度要小於140個字元(我實作時有踢到這個鐵板) 。

detail

結果的詳細說明。若是Debug階段，一些訊息就放在這(別像我，以為summary是必要就放在那兒，結果是Bug的Bug)。

indicator

說明這個結果的重要程度。目前支援有info、warning與critical。理想上，應該是不同程度畫面要有所區別，但是要看CDS Client要不要實作。

source

這是用來宣告版權的，為必要欄位。其結構為：(不多加解釋，coding結構就是FHIR的資料型態)

suggestions

這個整個card的核心，卻是Optional。他的內容是suggestion物件陣列。用來描述，CDS所提供的可採取行動之建議。其結構為：

其中action欄位是實際描述「當CDS Client接受這個Suggestion時要如何處理」。其結構為：

 處理的方式不外乎create、update與delete(怎麼沒有retrive？啊你前面在幹嘛？)。resource就是處理的對象。就是Resource啦。這裡要注意你要處理的Resource，當初的Scope都要宣告到。不過，還是得看CDS Client有沒有支援啦(坦白說，FHIR的真還在發展中，就是因為發展中，那還不趕快跟上)。貼個EPIC支援的給各位參考。(剪圖關係未能全部）

 Source: https://fhir.epic.com/

selectionBehavior

如果你有suggestion欄位，那這個欄位就是必要。他只有兩種選項at-most-one，單選。與any，多選。哈～還是要看CDS Client有沒有支援啦。

overrideReasons

當CDS Client不接受你任何suggestion時，你可以用這個欄位讓他選擇不接受的理由。他是coding的陣列。還是一樣，要看CDS Client要不要支援。

links

這是提供給CDS Client一些建議網站或者APP實用的。他是Link物件陣列。其結構為：

範例

官方範例提供參考

{ "cards": [ { "summary": "Example Card", "indicator": "info", "detail": "This is an example card.", "source": { "label": "Static CDS Service Example", "url": "https://example.com", "icon": "https://example.com/img/icon-100px.png" }, "links": [ { "label": "Google", "url": "https://google.com", "type": "absolute" }, { "label": "Github", "url": "https://github.com", "type": "absolute" }, { "label": "SMART Example App", "url": "https://smart.example.com/launch", "type": "smart", "appContext": "{\"session\":3456356,\"settings\":{\"module\":4235}}" } ] }, { "summary": "Another card", "indicator": "warning", "source": { "label": "Static CDS Service Example" } } ] }

在實作的過程這個階段很痛苦。因為每一個CDS Client的支援程度與方式不盡相同，甚至容錯能力也不同。