FHIR IG導入與FHIR資料平台
===

目前我們處於FHRI的萌芽期，絕大多數的醫療資訊資料並不是FHIR的格式。希望將醫療資料FHIR化，大致有兩個方式：從源頭Push或是使用端Pull。一種方式是希望將原始的資料盡可能FHIR化，之後發展FHIR相關應用；另一個角度則是從應用出發，制定新的IG，然後逐步將資料FHIR化。平心而論，這兩種方式殊途同歸，但畢竟優先順序不同，作法自然也有差異。


如果醫院採取先將資料FHIR化，那首要的工作就是FHIR建置資料平台(如上圖棕色部分)，然後使用類似ETL的方法，將原始資料轉換成FHIR格式後匯入FHIR平台。雖然這樣的作法較為全面，也同時建立醫療大數據的基礎，但實務上這樣的方式也需要立即投入較大量的人力、物力資源才能達到預期的效益。

這樣的做法會有一個潛在問題，由於過去醫療資訊系統所蒐集的資料並不夠全方位，也就是說，發展IG應用時，如果遇到IG所需要的資料並非存在於既有系統，醫院先了解IG的真正需求，然後新增或修正既有HIS的功能/流程，才能順利產生資料，符合IG規範。如果從軟體生命週期的觀點來看，就是醫院必須先完成系統分析工作，才能開始開發IG的應用。

另一個做法則是從FHIR應用出發，先符合官方要求，再逐步將醫療資料FHIR化。這樣的做法缺點在於對FHIR並沒有一個全方面的解決方案，同時過程中無可避免會產生許多重複性的資料。因此，我們將過程拆解，提供一個IG導入的標準作業流程，希望能以漸進式的作法，同時兼顧醫院短期(符合IG需求)與中長期(全方面FHIR化)目標。

導入IG第一個困難是了解IG Profile相關欄位與既有系統的對應。一般而言，我們會從IG規範與範例資料開始，清楚每一個Profile/Element意義，同時使用醫院真實的驗證資料嘗試去產生符合IG規範的FHIR Bundle檔案。如果這個過程順利，就可以確認我們清楚醫院既有資料與IG規範的關係，同時了解哪些資料並不存在於既有系統之中，接下來才是醫療資訊系統的功能增修。

這個流程需要很多人工作業，上圖綠色的部分則是說明如何使用工具將這樣流程自動化(半自動化)。包含三個主要元件：IG Analyzer、[FUME](https://github.com/Outburn-IL/fume-community)與IG Cooker。

IG Analyzer的輸入為IG package，根據IG所定義的規範內容，產生FUME所需要的設定檔(FLASH)同時轉換為對應之ConceptMap並上傳至FHIR資料平台。操作畫面如下圖：

FUME提供了將JSON檔案轉換為標準FHIR Resource的功能，也就是說，結合FUME與IG Aanlyzer所產生的ConceptMap，就可以將簡單的JSON檔案，透過IG Cooker轉換為FHIR Resource檔(如下圖)。


如果搭配衛福部提供的Excel檔案，我們就可以將驗證資料逐步輸入IG Cooker並產生IG所需要的Profile與Bundle。

IG Analyzer另一個功能則是根據既有的FHIR資料，逆向產生FHIR資料平台所需之測試資料，也就是說當我們使用驗證資料產生FHIR Bundle的同時，我們也可以產生FHIR資料平台所需要的測試資料，這些測試資料可使用於HIS資料匯入與FHIR資料平台導入IG的開發。