FHIR程式開發 - 從IG到程式碼
===

一般應用型IG(非正式名稱，表示非Core IG)通常是定義一個Bundle將多個Resource聚合再一起，可根據資料交換模式將Bundle.type定義為Document、Message或Collection。開發這一類型的IG的FHIR應用程式，可歸納以下步驟：


以下為各步驟知詳細說明：

下載IG Package檔案
---
可從[臺灣健保癌症用藥事前審查實作指引](https://twcore.mohw.gov.tw/ig/pas/downloads.html)下IG所對應之package檔案。
Package檔為一壓縮檔，解壓縮後為IG所對應之JSON檔案，包含StructureDefinition、SearchParameter、ValueSet等相關定義檔案。

IG分析
---
* 視覺化邏輯模型解讀：從視覺化邏輯模型了解Bundle所包含的Profiles以及Profile間的關係。
以[癌要事前審查]為例，可知臨床資料可區分為八大類，IG所定義的Profiles共31項。
* Package(StructureDefinition)解析：可以使用Firely Package程式庫，解析StuctureDefinition內容：
* IG包含profiles以及profile之間的關係 --> 確認Profile(資料)匯入順序。
* Bundle所包含的profile內容與是否必填 --> 了解Bundle的內容以及必須填入的Resource。

資料來源分析
---
* 視覺化邏輯模型與臨床資料對應
以[癌要事前審查]為例，從視覺化邏輯模型可知，產生IG所需要的臨床資料(部分)如下：

舉例說明，在評估資訊中，病人狀態評估包含四個項目：[病人狀態評估項目代碼]、[病人狀態評估結果]、[病人狀態評估日期]與[評估項目醫事人員身分證號]。
我們比對IG中病人狀態評估(Observation Patient Assessment TWPAS)可得到以下關係：

從[LOINC + NHI-健保事前審查-病人狀態評估項目值集](https://twcore.mohw.gov.tw/ig/pas/ValueSet-pat-ast.html)可以知道[病人狀態評估項目代碼]可選擇的項目
另外，從Profile的Constraint定義可知[病人狀態評估項目代碼]與[病人狀態評估結果]的填寫規則：

若病人狀態評估項目代碼(code)為88020-3，結果值(valueString)須填寫class1/class2/class3/class4其中一項
若病人狀態評估項目代碼(code)為98153-0，結果值(valueString)須填寫A/B/C其中一項
若病人狀態評估項目代碼(code)為89247-1，結果值(valueInteger)須填寫0~5其中的值
若病人狀態評估項目代碼(code)為89243-0，結果值(valueInteger)須填寫0~100其中的值
若病人狀態評估項目代碼(code)為IPS，結果值(valueInteger)須填寫0~7其中的值
若病人狀態評估項目代碼(code)為PDAI，結果值(valueInteger)須填寫0~263其中的值
若病人狀態評估項目代碼(code)為CIRS，結果值(valueInteger)須填寫0~56其中的值
若病人狀態評估項目代碼(code)為75633-8，結果值(valueInteger)須填寫0~10其中的值
若病人狀態評估項目代碼(code)為HCTCI，結果值(valueInteger)須填寫0~26其中的值

根據以上分析，臨床人員就可以清楚該如何提供病人狀態評估的資料，以下為一個可能的範例：

狀態：final
病人狀態評估項目代碼：Functional capacity NYHA (LOINC + NHI-病人狀態評估項目值集 #88020-3)
病人：Patient/pat-min
病人狀態評估日期：2024-01-01
評估項目醫事人員身分證號：Practitioner/pra-min
病人狀態評估結果：class1

* 臨床資料與HIS對應
醫事人員可從視覺化模型得知IG所需要的資料內容，並產生IG所需欄位與HIS DB Schema對照表。

資料匯入
---
根據Package解析結果，取得必需之範例資料檔並依據順序匯入FHIR伺服器。
* HIS到Staging DB
1. Staging DB的設計目的在降低醫院資訊人員的開發門檻，每一個Staging DB所定義之Table對應到單一的FHIR Resource，換言之醫院資訊人員不用瞭解FHIR複雜規格，只要專注在HIS DB與Staging DB的對應之轉換程式開發。
2. 根據資料特性，通常會將區分為兩部分：Master Data和IG Data。Master Data主要包含Organization、Practitioner與Patient，IG Data則會以某一個profile為核心，搭配其他輔助資料，以[癌要事前審查]為例，Claim即為核心之Profile，其他profile可視為補充Claim的說明資料。
3. Element的基數(Cardinality)設定可說明資料的必要性，但並不是唯一要遵守的邏輯。Profile的Constraint會定義較複雜的條件，以[癌要事前審查]為例，[Claim需要的Constraint](https://twcore.mohw.gov.tw/ig/pas/StructureDefinition-Claim-twpas.html)如下：
其中appType、diagosis與suportinginfo等都是邏輯性的定義，在匯入資料同時，除資料格式外，也必須遵守相關規定。

* Staging DB到FHIR Server
這一部分的資料轉換，會趨近於標準化，主要是將Staging DB的資料轉換為FHIR IG所定義的標準格式。

FHIR應用
---
* Bundle程式撰寫可使用FHIR SDK(如Firely .NET SDK)完成相關程式開發。

當Bundle.type為Document與Message時，第一個profile (Composition或MessageHeader)可視為整個Bundle的目錄，但collection並沒有這樣的Profile。因此，在實作上，對於collection type的Bundle需要更多的訊息才能確保產出的Bundle完整性。因此，對於collection type的Bundle，我們需要進一步的分析。

另外，雖然在各別profiles已經定義了各自的資料邏輯，但組成Bundle時，仍必須考量profile之間的關係，以以[癌要事前審查]為例，[Bundle](https://twcore.mohw.gov.tw/ig/pas/StructureDefinition-Bundle-twpas.html)定義了許多跨profile的檢查條件，由於數量繁多，這邊只舉一個例子說明：
文字內容說明如下

若申請案件類別(Claim.priority)為自主審查報備(#3)時，須填寫核定日期、核定數量及核定註記。

以FHIRPath表示，則可得到以下表示式：

(Bundle.entry.select((resource as ClaimResponse).created).exists()) or 
(Bundle.entry.select((resource as ClaimResponse).item.adjudication.value).exists()) or 
(Bundle.entry.select((resource as ClaimResponse).item.adjudication.reason).exists())  
implies (Bundle.entry.select((resource as Claim).priority.coding).exists(code='3'))

換句話說，使用SDK所產生的Bundle必須通過Constraintn所定義的FHIRPath驗證其資料正確性，才是一筆符合IG定義的Bundle資料。