FHIR資料平台之Data Pipeline與功能模組說明
===

重新整理一下FHIR資料平台的資料流說明，希望能釐清各個不同技術在FHIR資料平台的重要性與其所扮演的角色。

資料蒐集
---
資料來源包括軟體系統(HIS/NIS/LIS...)、醫療儀器與穿戴裝置(雲端介接)，一般而言，這些資料來源並不會提供FHIR格式的介面，因此將資料FHIR化將會是資料平台的工作。

通常不同的資料來源需要不同的客製化，資料FHIR化的會遇到兩個問題：代碼的差異和欄位的對應。為降低客製化的工作量同時隱藏FHIR的複雜性，FHIR資料平台會將工作分成兩階段：先將原始資料轉換為FHIR平台定義的Staging Data，再將Staging Data以標準做法，轉會為符合規範的FHIR Data。方便起見，我們先說明標準部分。

* Staging Data轉換為標準FHIR資料：FHIR資料平台所提供之標準化工具-FHIR Transformer，負責將FHIR平台定義之Staging Data格式轉換為標準FHIR資料，驗證後儲存至FHIR Storage。FHIR標準的JSON檔案是一個"深層"且複雜的樹狀資料結構，以病患身分證號(A123456789)為例，FHIR資料的呈現如下圖：
對於接收FHIR資料的系統，不需要其他額外任何文件說明，就可以清楚了解這筆資料所代表的意義，詳細解讀如下：
* http://terminology.hl7.org/CodeSystem/v2-0203 代表代碼系統為identifierType
* NNxxx代表National Person Identifier
* https://www.moi.gov.tw/ 說明的主管機關是中華民國內政部
* A123456789則是該病患的身分證號

這樣的做法，充分解決了資料交換的問題，但對於資料轉換而言，卻多了許多重複性且非必要的工作。FHIR資料平台提供了將這些工作隱藏的功能，讓資料轉換工作專注在必要的部分。

以上述身分證號為例，FHIR資料平台可定義Staging Data如下：

  {
    "idCardNo" = "A123456789"
  }

後續的轉換工作即由FHIR Transformer負責。另一個Transformer要解決的問題是代碼對應，使用者必須將院內碼/健保碼與國際碼之間的Mapping Table匯入FHIR Terminology Service，提供FHIR Trasformer使用。如此一來，Transformer就可以根據使用者提供的Staging Data，轉換為符合規範的FHIR資料。

除資料格式轉換外，Transformer另一個功能就是提供FHIR資料格式驗證。結合FHIR IG規範，確保最後產生的FHIR資料都符合IG所需要的定義，同時也完成資料清洗的工作。透過FHIR Transformer，我們將問題簡化為原始資料轉換為FHIR資料平台所定義的Staging Data，代碼則是透過Mapping Table方式匯入。

另外，由於IG的規範會隨著應用的增加而不斷更新，為符合持續更新/新增的IG規範，FHIR Regular Base提供了相關IG模板，一旦有新的IG產生，FHIR資料平台可根據IG規範，新增相關模板，確保FHIR Transformer可符合新增的規範。

* Staging Data產生：FHIR資料平台提供標準Staging API供外部系統將原始資料匯入FHIR資料平台使用。我們將Staging API分成兩個部分：Master Data API與IG Data API。Master Data API要求使用者提供方便辨識/取得的唯一值，IG Data API則無特殊需求。

目前台灣FHIR應用的作法會以Bundle為中心，這樣的需求在實務上會需要使用者提供額外的訊息才能讓FHIR資料平台確保最後產生FHIR資料時可以正確產出使用者所需要的Bundle資料。

資料儲存
---
用怎樣的格式存資料，是一個兩難的問題。如果考慮資料本身的特徵，非結構化的JSON格式會是較好的選擇，但如果從後續資料分析的角度來看，傳統RDB工具與生態系的發展，則會遠遠超過JSON的現況。目前FHIR資料平台規劃還是以非(半)結構化JSON為主，但透過OMOP on FHIR相關技術，希望能同時兼顧雙方的優點。

考量資料量與實際FHIR應用，實作FHIR Storage時可由單一HAPI FHIR或HAPI DHIR+Mongo DB(DataLake/DataLakeHouse)組成。驗證過後之FHIR資料可同步儲存，若FHIR資料平台提供Data Lake，則資料以Data Lake為主反之則以HAPI FHIR為主。

這樣的設計主要考量醫療單位對於FHIR應用的期望不一，對於以資料交換為主之醫療單位而言，HAPI FHIR已經可提供必要的相關功能，如果考慮後續資料分析，則應該同步考量建置DataLake。

除單純JSON資料儲存外，FHIR資料平台亦可考量同步建立OMOP平台，透過OMOP on FHIR技術(如下圖)，整合FHIR(HL7)與OMOP(OHDSI)相關資源。
詳細資料可參考[OMOP on FHIR for Data Analytic Application Platform](https://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=resources:omoponfhir_for_data_analytics.pdf)

另一個資料儲存會導入FHIR資料平台的技術是CQL，使用者可透過官方提供或自行撰寫的CQL匯入FHIR資料平台後，取得特定目的的FHIR資料，供後續應用。CQL也可以做為CDS Hook的基礎，提供FHIR應用程式主動的FHIR資料訊息或提供告警。

CQL相關訊息可參考：
* [CQL 101](https://lnkd.in/gZyVe3Md)
* [cql-translation-service介紹](https://hackmd.io/@hongyu0324/cql-to-elm-service)
* [CQL程式Walkthrough](https://hackmd.io/@hongyu0324/cqlwalk)
* [Cooking with CQL 69 - Colorectal Cancer Concepts](https://hackmd.io/@hongyu0324/CookingCQL069)

資料應用
---
FHIR應用開發可參考
* [FHIR程式開發 - 從IG到程式碼](https://hackmd.io/@hongyu0324/ig2code)
* [FHIR平台應用程式開發](https://hackmd.io/@hongyu0324/FHIRAppDev)
* [FHIR IG應用開發](https://hackmd.io/@hongyu0324/FHIRIGApp)

資料介接
---
FHIR資料平台可提供外部系統與醫療單位系統介接的解決方案，FHIR資料平台提供每一個外部系統一個FHIR Endpoint，透過標準FHIR API外部系統可以無痛整合。只要依循Smart on FHIR標準，FHIR資料平台提供必要之Client ID與Client Secret即可，不需要額外的討論或其他文件提供。

FHIR Endpoint資料同步必須依靠FHIR Pump，FHIR資料平台提供兩種FHIR Pump：MD Pump負責Master Data同步；ID Pump則是提供IG Data同步的功能。