HackMD學習FHIR的各個角度 - 學習地圖
學習FHIR的困難點在於不同的角色所認知的HFIR會有很大的差異。同時，FHIR相關知識所牽涉的廣度太大，彼此之間又環環相扣，如果沒有一張學習地圖，很容易迷失在技術細節。
我們將FHIR的相關知識區分成三層：基礎知識、設計開發與影用發展，希望透過一張簡單的學習地圖，將FHIR相關知識串聯起來。
基礎知識
FHIR的核心是Information Model，簡單的說，就是所有FHIR相關物件定義。Information Model由Resource組成，以R4為例，共計約146個Resource。
Resource的分類
由於Resource數量眾多，Resource的分類就相對重要。官方網站將Respource分成五類(Layer)分別是Foundation、Base、Clinical、Financial和Specialized。詳細訊息可參考：Resource分類清單然而，Resource本身就是一個容易造成誤解的概念，官方說明如下：This specification defines a series of different types of resource that can be used to exchange and/or store data in order to solve a wide range of healthcare related problems, both clinical and administrative.
換句話說，Resource包含兩種概念：clinical和administrative，這也是為什麼Patient是一個Resource，StructureDefinition也是一個Resource。就使用上來說，Patient和StructureDefinition是截然不同的概念。
Foundation類的Resource官方說明如下：Foundation resources are the most rudimentary, foundational resources. They are often used for infrastructural tasks. Although not prohibited, they are not always referenced by other resources.，又可區分為五種：Conformance、Terminology、Security、Documents和Others。
Foundation Resource應該特別處理，和其他Resource的用法完全不同。一個簡單的思考方式是將Foundation Resource視為FHIR系統所需要的設定檔，相關的機制使用Foundation Resource設定完成後，再透過FHIR Server(或其他機制)完成。也就是說，當FHIR系統要新增特殊功能時，第一步就是新增Foundation Resource資料，由FHIR Server實作對應功能。
Conformance
Terminology
Security
Documents
Resource的使用
這張圖顯示在官方網站首頁，我剛開始學習FHIR的時候，一直解讀成FHIR的分類說明，其實不然。我目前的解讀是將這張圖視為"Resource的使用說明"，如果將圖上的說明列為清單就會更清楚：
- Level 1: Basic Framework on which the specification is built
- Level 2: Supporting implementation and binding to external specifications
- Level 3: Linking to real world concepts in the healthcare system
- Level 4: Record-keeping and Data Exchange for the healthcare process
- Level 5: providing the ability to reason the healthcare process
換句話說，這張圖說明了在不同的情境下如何操作，從基礎框架、實作支援與真實世界連接；接下來從醫療流程討論紀錄保留、資料交換以及決策推理。
Resource、Element和Data Type
雖然目前廣泛被討論使用的FHIR版本是R4，但在R5規範FHIR Type Framework所定義的Base類別，更能清楚說明Resource、Element和Data Type之間的關係。
對R4而言，Element(定義為ElementDefinition)和Resource(定義為StructureDefinition)是兩個完全沒有關係的概念。Primitive data types、Complex data types和BackboneElement都直接繼承Element。Resource則由Element構成，透過Resource與DomainResource(繼承Resource)，建構其他Resource。如果用物件導向的用語，Element和Resource是part of的概念，Primitive data types、Complex data types和BackboneElement和Element則是kind of的概念。這樣的關係可以從下圖觀察到。然而，Data Type在R4版本並沒有清楚定義。這就是為什麼我認為R5的FHIR Type Framework有較清楚的說明。
設計開發
了解FHIR Information Model的下一步就是如何使用。可以從兩個角度來看這件事
- 系統設計：如何產生特殊情境下所需要的Information Model
- 系統開發：如何產生特定情境下的Informatio model資料並使用相關資料
可以從這兩個面向瞭解FHIR如何設計與開發
FHIR Constraint Model
Constraint Model的意義在於對既有FHIR Resource做適當規範，讓他符合某些國家或特定領域需求。簡單的說，StructureDefinition定義了一般Resource和Profile之間的關係，CapabilityStatement說明FHIR Server所提供的功能，ImplementationGuide所有的東西整合在一起。
FHIR Usage
使用FHIR資料包含Server端和Client端，相關議題說明如下：
FHIR伺服器
FHIR 伺服器是實現FHIR API並使用FHIR Resource交換資料的軟體(A FHIR REST server is any software that implements the FHIR APIs and uses FHIR resources to exchange data.)以下為FHIR Server應具備的功能：
- CRUD
- Search
- History, Version
- Validation
- Custom operations
- Subscription
- Terminology
- Messaging
- Auditing
- Bulk Data Export
- SQL on FHIR
FHIR RESR API
討論REST API之前，我們先來了解兩個特殊的Resource：
- Bundle：多個Resource的集合，Resource存放在Entry中鐘。嚴格來說，Bundle並不是一個單一用途的Resource，甚至可以說，不同type的Bundle可視為不同的Resource。Bundle Type總共定義了九種Bundle Type如下：
若type為document或message會在相關章節說明，其他與REST API相關的type說明如下：- transaction/batch：使用於一次寫入多筆資料的情境，必須搭配各entry之Request使用，於Request定義資料寫入的方法及Resource種類。
- transaction/batch response：寫入資料的回應，搭配各entry之Reponse使用，Response也包含了OerationOutcome，說明資料處理的結果。
- searchset：REST Search API的回傳結果，顯示多筆resource。當回傳結果需要分頁時，可搭配Link(next)使用。
- OperationOutcome：REST API或Operation操作失敗時的回傳值。相關內容與說明如下：
REST API主要提供FHIR Resource資料處理功能，包含基本CRUD與Search。
FHIR Document
在台灣，電子病歷交換單張所使用的機制就是Document。我們可以使用一個實際的案例來了解Document。
首先，Document的主體就是Boudle，_type=document表示這個Bundle是一個Document。Bubdle為多個Resource的集合，第一個Resource必須為Composition，可視為Document的目錄，說明Document所包含其他Resource之間的關係。
FHIR Messaging
Message在台灣的應用案例是臺灣傳染病檢驗報告，和Document相同，Message是一個type=message的Bundle，第一個Resource必須是MessageHeader，定義整個Bundle的內容與操作模式。
Subscription
簡單說，Subscription就是事件驅動，當規範的事件發生時，發告警通知外部系統。
R4版本Subscription功能很單純，因此對應的Resource也相對簡單。以下圖為例，Subscription定義如下：
我們使用一個簡單的情境說明相：當醫院內部有兩套以上系統需要做病患資料同步，Patient Resource 上傳時，將觸發Subscription發送通知Patient已上傳，並傳送Patient內容另一系統。所需要的Subscription Resource內容如下：
- criteria：伺服器用於確定何時為此訂閱生成通知的規則，必須為search criteria 。
- channel：到符合條件的資源時向何處發送通知，目前支援rest-hook | websocket | email | sms | message
若希望追蹤是否已發送通知可對於特定資源(或特定版本)，可以查看AuditEvent Resource。
Validation
比較嚴格的說法是profile validation，每一個IG都會提供其package壓縮檔供使用者下載，壓縮檔包含了IG所定義(或包含)的Resource清單，例如StructureDefinition、CodeSystem、ConceptMap、SearchParameter、ValueSet等。由於，驗證所需要的定義檔都涵蓋在內，因此Client端就可以透過解析Package相關內容完成驗證功能。具體做法可參考Firely Validation。
FHIR SDK
因為REST API並非物件導向，且跟特定語言綁定不深，因此實務上會使用SDK開發，而非直接使用REST API。以C#為例，官方推薦使用的Firely .NET SDK即是一個很好的例子。一般SDK會提供以下基本功能：
- FHIR Model
- REST Client
- Parsing and Serialization
內容大致涵蓋Resource物件化、FHIR Server連接與API處理、JSON/XML物件處理等。
某些特殊功能並非所有SDK都會提供，以Firely .NET SDK為例，除了基本功能之外，同時提供了以下功能：
- FHIRPath
- Validation
- CQL
- Package
應用發展
FHIR相關應用發展可區分為兩種模式，第一種是根據特殊應用，依據FHIR的邏輯，建立IG並發展相關應用。目前較知名的應用有PACIO、IPS、Da Vinchi等等。
另外一類應用則是不同規範之間的整合，Smart on FHIR、SQL on FHIR都屬於這一類。
FHIR相關規範
FHIR並不是一個獨立存在的規範，許多其他規範都會跟FHIR有直接的相關。
FHIRPath
由於FHIR Resource可視為一樹狀形結構，因此需要類似xPath這樣的描述語言，但由於FHIR可使用的格式包含JSON、XML與Turtle，因此xPath並不是完全適合，才有FHIRPath的制定。對於FHIR而言，FHIRPath主要的用途如下：
- StructureDefinitions
- Invariants (boolean result)
- Search Parameters
另外，FHIRPath也適用於CQL，可使用FHIRPath Lab 驗證FHIRPath的語法是否正確。
CQL
CQL全名是Clinical Quality Language，目前台灣的使用狀況還僅在剛起步，未來預期將使用在rule library的定義。相關參考資料如下：
CDI
資料交換的最小範圍，以USCDI為例，官方說明如下：United States Core Data for Interoperability (USCDI)The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange.
USCDI會定義相關data class/data element與FHIR Resource/Element之間的對應關係。
