學習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分類清單](https://hl7.org/fhir/R4/resourcelist.html)然而，Resource本身就是一個容易造成誤解的概念，[官方說明如下：](https://hl7.org/fhir/R4/resource.html)*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](https://hl7.org/fhir/R4/bundle.html)：多個Resource的集合，Resource存放在Entry中鐘。嚴格來說，Bundle並不是一個單一用途的Resource，甚至可以說，不同type的Bundle可視為不同的Resource。[Bundle Type](https://hl7.org/fhir/R4/valueset-bundle-type.html)總共定義了九種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](https://hl7.org/fhir/R4/operationoutcome.html)：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之間的關係。

[檢驗檢查 - 視覺化邏輯模型](https://twcore.mohw.gov.tw/ig/emr/ICvsmodel.html)

### FHIR Messaging
Message在台灣的應用案例是[臺灣傳染病檢驗報告](https://twidir.cdc.gov.tw/twidir/examples.htm)，和Document相同，Message是一個type=message的Bundle，第一個Resource必須是MessageHeader，定義整個Bundle的內容與操作模式。

### Subscription
簡單說，Subscription就是事件驅動，當規範的事件發生時，發告警通知外部系統。


R4版本Subscription功能很單純，因此對應的Resource也相對簡單。以下圖為例，[Subscription](https://hl7.org/fhir/R4/subscription.html)定義如下：


我們使用一個簡單的情境說明相：當醫院內部有兩套以上系統需要做病患資料同步，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](https://hackmd.io/@hongyu0324/FirelyValidationn)。

### FHIR SDK
因為REST API並非物件導向，且跟特定語言綁定不深，因此實務上會使用SDK開發，而非直接使用REST API。以C#為例，官方推薦使用的[Firely .NET SDK](https://docs.fire.ly/projects/Firely-NET-SDK/en/latest)即是一個很好的例子。一般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 ](https://fhirpath-lab.com/fhirpath)驗證FHIRPath的語法是否正確。

## CQL
[CQL](https://build.fhir.org/ig/HL7/cql/)全名是Clinical Quality Language，目前台灣的使用狀況還僅在剛起步，未來預期將使用在rule library的定義。相關參考資料如下：

* [Colorectal Cancer Concepts](https://hackmd.io/@hongyu0324/CookingCQL069)
* [CQL 101](https://hackmd.io/@hongyu0324/cql101)
* [CQL程式Walkthrough](https://hackmd.io/@hongyu0324/cqlwalk)
* [cql-translation-service介紹](https://hackmd.io/@hongyu0324/cql-to-elm-service)

## CDI
資料交換的最小範圍，以[USCDI](https://www.healthit.gov/isp/united-states-core-data-interoperability-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之間的對應關係。