電子病歷實作技術: CDS Hooks - 程式開發

當EHR叫用cds-services得知目前CDS Server支援了哪些CDS項目。接著就依據Id名稱，正式叫用服務。但，這時候已經把兩邊搞的天翻地覆了。

EHR要依據CDS Hooks端的要求，把所有資料準備好，接著用POST方式叫用服務。

CDS Hooks端收到資料後，就得開始找出真正提供CDS服務者。這個過程有點複雜，因為使用的Hooks不同，FHIR Resource會出現在不同的地方。另外，會有Reference Datatype的問題，不過這個可以在一開始Prefetch時，把查詢的URL先搞定。

這篇只說明呼叫時的運作，還沒有到CDS Service。

===== Call Service ====

根據CDS Hooks的規範書可知，選定服務後在/cds-services/{service.id} 。

30: 根據傳進來的service.id來取得他的Hook內容。

32: 需要一個負責回應Card內容的類別Responses，呼叫啟始設定函數InitHook()。

33: 再呼叫GetResponseContent()。注意，這個函數要處理很多事情，包含去呼叫對應的CDS，然後產生適當的Card出來。

40~44: 這是要符合CDS Hooks規範要求。

===== Hooks =====

這個類別上次就看過，在這邊是已知Service.Id之下，來找出對應的Hook內容。

===== Responses.InitHook() =====

這裡的重點不是函數本身，而他ParseRequestModel();

在EHR送過來的資料中，有三個非常重要的東西其型態卻是object。分別為context,

prefectch與fhirAuthorization。避免複雜fhirAuthorization部份不實做。

利用ParseRequestModel()來拆解內容，並給後續步驟使用。

還有一個因素是FHIR Resource都有可能在Context與Prefectch中。前者是草稿中，後者是已結案的。

===== Responses.GetResponseContent() =====

目前這個函數的內容是暫時的，因為真正提供CDS服務的類別還沒完成，所以Card的內容都不會有。

這邊使用到一個CardService，他是用來與CDS溝通，並產生Card類別提供給EHR端。目前先用他的一個產生空白Card的函數。

這邊有個CardModel，這是依據CDS Hooks規範要求所設計。

===== CardModel =====

他衍生了很多類別，這邊就不多說。會有專篇來討論Card這個複雜的傢伙。

===== CardService =====

這個類別以後會很複雜，目前就單純先給個CreateEmptyCard的還是來做驗證之用。

另外，我也沒有使用Sandbox進行測試，所以Body資料是空的，只能一步一步寫，一步一步解說。

===== BMICalculation =====

===== HeartRateMonitoring =====

電子病歷實作技術