FHIR SDK （DotNet）- 思考

 什麼是SDK(Software Development kit, 軟體開發套件)，他與API的差異在需用於特定的軟體套件、軟體框架、硬體平台與作業系統。所以，這次開發的SDK僅能在DotNet平台下使用。

目前還沒打算開源，先以介紹SDK開發為主，等因緣具足時再來思考這個問題。

===============

FHIR SDK的目的就是協助軟體開發者，能透過一組元件輕鬆駕馭FHIR Resource。R5的Resource有157個，照趨勢發展未來可能還會更多。而SDK就是提供這些Resource的結構，能夠從XML/JSON的字串類型的資料，與物件相互對應。畢竟程式開發中，以物件形式來操作是比較容易的事情。

雖然有157個，其結構是類似的。所以這塊其實有寫了另一個專案，利用T4技術弄個程式產生器，利用程式來產生程式。也就是說未來有了R6，只要結構沒有重大變化，這個SDK可以馬上支援最新版本的FHIR。至於這部份的技術，就看這系列文章的發展，是否有機會也來介紹。

回來原點，雖然Resource有157個，其實他們有遵循了FHIR Type Framework。而SDK的重要核心技術，就是如何在你選定的程式語言下來實踐這個Framweork。

圖中看這個架構，好像一切理所當然，實際套映在程式語言時，有許多關鍵技術需要被克服。例如他的相互錯換宣告模式，下層繼承上層，而上層卻使用用到下層、FHIR資料型態與程式語言資料型態對應等等問題都需要克服。

首先，要先知道這個架構分成兩大部份，一個是基礎的資料型態系列，另一邊是Resource系列。Resource端比較容易理解，其實就是欄位屬性的宣告與使用。

資料型態端其實要分成四大類型。分別是Primitive Type、General-Purpose Datatypes、Metadata Types與Special Purpose Datatypes。但實踐上只有兩大類，Primitive Type與Complex Type。

Primitive Type就是最底層的值，而這個值就是要對應到程式語言的資料型態。他是沒有欄位，只是值的物件。

Complex Type就是有欄位的物件。

從C#程式語言的角度來說，Primitive Type就是「實質類型」，而Complex Type就是「參考類型」。

Resource類型原則上與Complex Type類似，屬於「參考類型」。

========
講到這，如何覺得很簡單，那你就錯了。
因為FHIR這個Extension架構，讓Primitive Type變得很複雜。因為Primitive Type繼承了Element，他卻是Complex Type結構。這部份FHIR有了新的定義。細節就留待下一篇了。

FHIR SDK (DotNet) - FHIR QB

 FHIR QB採用C#開發，基於DotNet 8。底層採用自行研發的FHIR SDK，目前支援FHIR R5。除了支援Open Server之外，也可透過SMART Backend Services方式，支援OAuth 2.0的FHIR Server。

1.  輸入FHIR Server URL後，點選[Connect]。順利連線，會取回CapabilityStatement Resource。當然，這部份會丟到FHIR SDK去解析，之後就可以透過物件方式，存取此Resource。
2. 這邊會列出此FHIR Server寫在CapabilityStatement中有支援的Resurce。圖中是選擇Encounter Resource。後續的內容都會依據CapabilityStatement來決定。
3. 此為查詢參數，分成一般與Resource兩大類。至於這部份的背景知識請參考官方文件。
4. 因應不同查詢參數類別，此區會出現相對應的欄位內容。依據自己查詢條件，逐一加入查詢清單。
5. 此為查詢清單，可透過[Add]新一個查詢條件，或者[Remove]刪除一個查詢條件， [Remove All]刪除所有查詢條件。
6. 此處可勾選_include或_revinclude的需求。
7. 點選[Modifying Results]可以設定相關參數。
   
   
   
8. 點選[Create]就能夠把所有設定參數建立查詢URL。點選[Search]就開始向FHIR Server查詢資料。
9. 此區為查詢結果。
10. 可以將結果複製，或者存檔。

如果是連接有支援OAuth 2.0的Server時。

1. 會出現[Get Token]按鈕。點選後就需要輸入相關資訊。在此走Backend Service情境。（相關技術不在本系列範圍）
   
   
   
2. 在此顯示SMART on FHIR的metadata。

完成JWT相關資料後，就會向授權服務器來取得Token。

1. Server回應的Token內容。
2. Resource部份，只會顯示當初申請時，所要求的Resource (Scope)。

其操過過程與一般無異，只是受到的限制比較多。

FHIR SDK (DotNet) - 背景故事

在於國外EMR奮戰的過程中發現，各家FHIR Server號稱標準，其實都不標準（IG只是理想，Profile只是說說）。為了找到一個最佳資料存取方法，常常需要測試各種查詢參數。一開始透過Postman是不錯的工具，但隨著查詢條件複雜化後，每次得去記那些參數實在有夠累。於是有了開發FHIR Query Builder （FHIR QB）的念頭。

FHIR QB的目的就是希望有點選的方式來產生查詢條件，並向FHIR Server取得資料，來確認是否與自己的預期相符。沒問題後，就可以把這樣子的查詢參數模式放在正式的程式中。

接著問題來了，要能有效發揮FHIR QB的功效，底層解析Resource的程式庫的需求也就浮現出來了。當然，市場上已經有各種程式語言的SDK可以下載，但對我來說，為什麼不自己也寫一套呢？因為，我的理想是建構一個FHIR Ecosystem，未來會有自己的FHIR Server、Authorization Server、EMR Lite、Profile base validater、CDS Hooks Service等。這些服務是不斷堆疊的，唯有掌握好底層技術，一切發展才能隨心所欲。

是的，從底層開始研發的FHIR SDK完成了；應用FHIR SDK的FHIR QB也完成了，其他部份也期望能在「默默」中實踐夢想。但是，看到很多人在努力推動FHIR，也許分享自己開發SDK的概念，會有拋磚引玉的效果，能激起一些漣漪。若能有更多人參與投入，讓國內FHIR的發展更加穩固，朝正確方向前進，那是最好的結果。

本系列文章將會先介紹FHIR QB的使用與SDK開發的思維邏輯與注意事項。至於原始碼是否公開，就一切隨緣吧。

FHIR Query Builder - without OAuth

FHIR Query Builder Part 1

FHIR Query Builder - with OAuth

FHIR Query Builder Part 2

[閒談FHIR] - 是好是壞？

這篇部落格FHIR (in)Consistency? Data, please，雖然這個主要是針對STU3，但整體趨勢是沒有改變的。

注意，曾在某論壇看到訊息說，R5只是中介版本。R6才會長期支援。
但R6仍在CI-Build階段，還要有段時間。
不用急著去看R6 (https://build.fhir.org/)，現階段還沒有什麼變動。
從我開始搞HL7到現在，可以這麼說FHIR是最不嚴謹的。

[閒談FHIR] - gRPC

最近看看gRPC的技術文章，也看到google定義了FHIR的protobuf。https://github.com/google/fhir
原本猜想FHIR會朝gRPC方向發展嗎？目前官方文件是沒有任何gRPC字眼，但有protobuf。如圖。
雖然如此，其實方向已經很明確了。
Resource中新增了SearchParameter，實做架構已了然於心。

如果對這些資料交換技術架構有疑慮者，建議可以看看這部影片。