FHIR發展藍圖

FHIR(Fast Healthcare Interoperability and Resource)為下一世代醫療資訊交換的標準，相較於前一世代其他標準，FHIR擁有許多優點其涵蓋面也不限於資料交換，而是包含系統開發、資訊安全、物聯網、行動裝置等各種面向。也因為FHIR的涵蓋面過廣，不同角度看待FHIR的結果會完全不同。

本文希望提供一個Top Level的角度說明FHIR的發展，讓發展團隊與相關人員在過程中除了專注在各自的領域之外，也能夠有一個整理的概念，如此更能清楚了解各自工作的重要性與彼此之間的關聯性。

同時也希望提供公司(或其他醫療機構)打造次世代醫療平台一個完整的發展藍圖，在整個發展過程中，擁有一份清楚可依循的設計指引。我們希望達成以下目的：

1. 說明次世代醫療平台的範疇與實作方法
2. 根據次世代醫療平台需求，導入必要之工具與技術，工具包含商用軟體與自行開發
3. 了解技術與規格發展趨勢，讓次世代醫療平台成為創新應用之基礎

次世代醫療平台發展

• 平台建構
  協助醫療機構打造以FHIR為基礎的數據中台與應用中台。數據中台以Data Lake為核心，提供後續人工智慧、大數據相關數據應用基礎，應用中台則是以FHIR Server為核心，提供標準開發工具如SDK與API，成為醫療機構後續醫療應用程式開發之基礎。

平台建構可區分為三個步驟：資料建模、資料管理與資料匯入。嚴格來說，應該將FHIR視為一個”定義標準的標準”。HL7協會定義的145個Resource，而每一個國家根據實際需要，在既有Resource之上定義國家標準(Core IG -Implementation Guide，實作指引)，而每一個醫療機構也可以根據實際需要，在Core IG之上，定義專屬之IG。我們將這樣的流程視為資料建模的過程，也就是定義我們平台所通用的資料模型。台灣的國家標準是TW Core IG TW.GOV.MOHW.TWCORE\首頁 - FHIR v4.0.1，透過TW Core IG整合與專屬IG之制定，成為醫療平台上共通使用的資料模型。

醫療資料管理(或資料治理)區分為兩部分：Data Lake和FHIR Server。Data Lake以JSON格式儲存資料，提供後續AI與數據分析應用；FHIR Server則是提供符合標準之FHIR API與SDK，支援後續醫療應用程式開發。

醫療資訊系統已經發展很久，也累積了許多資料，因此建構平台的一個重要工作就是資料匯入，將既有HIS、NIS、LIS等系統資料匯入到次世代醫療。由於平台必須考量共通性與方便性，因此平台將提供FHIR Gateway，讓使用者已設定方式，不需要修改程式就可以將既有系統的資料轉換成FHIR格式並儲存於Data Lake與FHIR Server。

• 應用開發
  應用發展大致可區分為兩個方向：醫療應用程式發展、人工智慧與數據分析應用。FHIR Server提供標準FHIR API；另外，也有許多開源軟體提供不同語言的FHIR SDK介面(dot net、java、python…)。應用程式開發可依據實際需要，選擇不同的方式。Open Source Implementations - FHIR - Confluence (hl7.org)
  次世代醫療平台提供人工智慧與數據分析應用的資料來源。

構成元件說明

次世代醫療平台由以下元件構成，分別說明如下：

• FHIR Server：醫療應用程式的資料來源，提供API與SDK，開發人員可以用來開發醫療應用程式。可以產生Swagger/OpenAPI相容文件，並與APIM工具整合。根據實際應用程式需求，平台內可同時存在多個FHIR Server，但多個FHIR Server會伴隨著資料同步的問題，實作時需考量資料的一致性與即時性。
• FHIR Data Lake：提供資料管理與治理功能，保存平台內最完整的數據，為人工智慧、大數據分析與醫療應用程式的資料來源。為保持最大彈性，Data Lake將以JSON格式儲存FHIR資料。
• FHIR Façade：由於平台允許一個以上的FHIR Server存在，如果應用程式(報表或儀表板)所需要的資料需要跨FHIR Server，FHIR Façade提供Data Aggregation功能，將多個FHIR Server的資料彙整再一起，產生對應的報表或儀表板。
• FHIR Gateway：雖然平台資料以FHIR格式呈現，但大多數的既有系統並非如此。此時FHIR Gateway就扮演了資料格式轉換的腳色，透過設定方式，將既有系統資料以批次或即時方式，轉換成FHIR格式，並儲存於Data Lake/FHIR Server。
• AI Data Source：人工智慧程式所需要的資料來源，平台並沒有特定之選擇，而是依據資料科學家需求，將相關資料搬移到所需之資料來源。一般而言，會配合醫院(機構)之MLOps流程而有所不同。
• BI Data Source：商業智慧或資料倉儲所需要的資料來源，平台並沒有特定之選擇，但由於相關應用通常會建構在關聯式資料庫之上，因此需要再一次的ETL作業，將Data Lake的資料搬移到所選擇之關聯式資料庫。

自有產品開發

從既有系統將資料匯入平台為每一個醫療機構必須解決的問題。由於平台使用FHIR為資料模型基礎，因此這個問題將簡化為如何將各醫療機構既有的資料模型與TW Core IG對應。進一步思考這個問題，如果能將欄位對應以設定檔方式解決，開發一個通用型的Gateway就可以適用於所有的醫療機構，這也是我們開發FHIR Gateway的原因。希望能結合FHIR專業知識與產品導入，協助各醫療機構快速將既有資料轉換至平台。

FHIR Gateway開發必須考慮幾個技術問題：

• 資料相依性，每一個FHIR Resource/Profile並非完全獨立，換句話說，資料匯入必須有順序性。
• 必須考慮FHIR資料的特殊規定，舉例來說，FHIR標準規格允許Choice、Extensions、Components、Bundle等特殊的資料結構，這些都必須在FHIR Gateway實作。
• 效能考量，考慮資料數量與多樣性，FHIR Gateway必須具備一定的效能要求。
• 資料匯入必須支援real-time、polling與on demand等模式。

工具介紹

除自有產品開發外，更多的工作是整合既有的工具。使用成熟穩定的開源軟體或商用軟體，建構穩定、開放據擴充性之次世代醫療平台。

• FHIR Server
  FHIR Server在平台中扮演一個特殊的角色。以三層式程式架構為例，FHIR Server扮演資料層(Data Layer)角色，將實體資料庫隱藏在後，另外也實作了OR-Mapping的功能，對於上層的商業邏輯層而言，程式開發所對應的是標準的FHIR API/SDK，不用考慮實際資料儲存的方式。這樣當然簡化程式開發的負責度，但整體效能與可用度將大幅度取決於FHIR Server的選擇。

另外，由於FHIR Server相當於一個具備領域(醫療)知識的資料層，因此FHIR Server同時可扮演資料驅動(Data Driven)的啟動者。當特殊的醫療資料(病患、用藥…)存入FHIR Server時，FHIR Server可以觸發相關程式，通知人員手動或自動處理相關事件。

平台必須使用符合FHIR標準之資料伺服器，目前平台建議使用Smile Digital Health/HAPI FHIR與Firely Server。FHIR Server主要功能清單如下：

HAPI FHIR	Firlely Server
Supports all FHIR resources and major releases of the FHIR	specification.
Repository or Facade (Hybrid) model	Bulk Data Export
Support for ANSI SQL database	Bulk Import via Firely Server Ingest
Custom Search Parameter	Terminology services
FHIR subscriptions	Custom Operations
FHIR validation	Custom Resources
Implementation Guide Package Manager (NPM)	Custom Search Parameters
Terminology	Subscriptions
Forwards & Backwards compatibility	X-Provenance header
Master Data Management (MDM) / Enterprise Master Person Index (EMPI)	OpenAPI

以上資料來自官方網站，但由於不同公司對於”Key Features”的定義不盡相同，因此上表並不具備比較意義。舉例來說，Bulk Data Export對於Firely Server是基本功能，但只有商用版的Smile Digital Health才具備此項功能。綜合來說，FHIR Server基本功能為FHIR RESTful API、FHIR Subscription、FHIR Validation與Terminology Service。

• Data Lake
  資料湖扮演數據中台角色，提供單一資料來源，由於平台使用FHIR為資料模型，因此數據治理工作會較為單純。資料的”消費者”可區分為三類：AI、BI與基於FHIR Server的應用程式。

AI使用者一般為一次性，但使用對象較廣，必須考慮資料使用權限與回收的機制。Bi使用情境資料傳輸多為單向(資料湖  BI Source)，一般而言，會使用資料庫或資料倉儲當作BI的Data Source。應用程式的狀況會較為複雜，因為資料流為雙向，應用程式所產生的資料必須回饋回資料湖。另外，不同應用程式之間也會使用資料湖當作Data Hub，不建議應用程式之間直接做資料交換。從系統架構的角度，會希望維持架構的單純性，因此所有應用程式都應使用FHIR Server當作資料來源，不建議直接使用資料湖做為應用程式的資料來源。

FHIR資料格式為半結構性的JSON檔案，另外，由於資料湖的定位為醫療機構單一之資料來源，考慮醫療機構資料量，橫向擴充為必備之功能。平台建議使用的資料湖為Hadoop/HPE Ezmeral Data Fabric與MongoDB，詳細功能非本文件之目的，不在此說明。

• APIM
  APIM並非必要選項。FHIR RESTful API為應用程式與FHIR Server溝通之主要手段，因此若FHIR Server與應用程式之間為一對多關係，則需要APIM協助管理API的使用；反之，若FHIR Server與應用程式間關係為一對一，則可以簡化架構，不需要採用APIM。常見的APIM包括3Scale/APICast、Kong等。

FHIR軟體生命週期

傳統的軟體開發生命週期包括系統分析、設計、開發與測試等不同階段。由於FHIR提供了標準的資料建模與API/SDK資料存取標準，應用程式建置在標準的基礎之上，使用共同資料模型與API，讓開發流程標準化。同時資料模型不須重新定義，只要根據應用程式的特性，定義對應的IG即可。另外，應用程式需要的機制，包括認證、授權、訊息通知等，都有標準定義。

FHIR軟體生命週期

以使用Firely產品為例，系統分析師主要的工作為制定IG，開發團隊使用FHIR Server所提供的開發工具(API/SDK)，依據IG內容進行程式開發。由於FHIR對資料建模已經有標準作法，開發團隊只需要針對業務需求開發，不用針對資料模型做額外之說明與溝通。

FHIR程式開發步驟

1. 需求分析與IG制定：需求分析階段與一般程式開發相同，系統分析師提供畫面雛型設計並與使用者確認操作流程。FHIR程式開發流程將以IG制定取代一班程式開發之資料模型設計。這樣的做法具備以下優點：

• 標準文件：制定IG後將提供網站版本之標準格式文件。
• 標準資料模型：IG制訂將基於FHIR Resource與TW Core IG標準，所有欄位名稱、術語、Value Set都依循國家標準定義。
• 版本控制：IG更版均提供使用者詳細記錄，並提供必要之版本變更說明。

2. FHIR Server設定與IG匯入：系統工程師根據IG定義，建立開發需要的測試環境。
3. FHIR Gateway設定與(測試)資料匯入：資料工程師根據IG內容，撰寫FHIR Gateway設定檔，並根據實際開發需要將所需之測試資料匯入測試環境。
4. 開發環境建置與程式庫匯入：統工程師建置測試環境所需之AP伺服器，並與開發工程師共同確認測試環境是否符合FHIR Resource/TW Core IG/專案IG之標準。同時，配合開發工具/語言使用，提供必要之程式庫。
5. 程式開發：開發工程師撰寫程式，完成單元測試，於定版後納入程式版本管理流程。
6. 開發/測試流程：測試工程師根據需求文件，執行系統整合測試，系統工程師協助建立正式環境並納管。
7. 發行：測試成功後，版本控制人員將程式碼發行至正式環境。

FHIR程式應用

FHIR應用案例可以區分以下類型：

• 數據彙整：醫療資訊系統普遍存在資料孤島現象，這是因為過去的系統設計是以醫療行為為主。將資料彙整到FHIR Server後，就可以從病患、機構、醫師等不同面向發展應用程式。
• 資料交換：跨機構或同機構內跨系統之間的資料交換，過去往往因為沒有共同的標準而造成許多重工與不便。FHIR為醫療系統的統一標準，將大量簡化資料的工作，只要定義領域應用IG就可以解決跨系統資料交換問題且未來可重複使用。
• 資料驅動：FHIR Server除被動接收FHIR資料外，也可以當作一個事件驅動者，當接收到特定資料時，FHIR Server可自動觸發相關事件，通知相關訂閱者。利用這個特性，可結合問題通知與處理，形成一個閉環系統。
• 系統整合：現階段醫院內部存在龐大的既有HIS系統，由於系統彼此之間耦合度高，面對創新科技的發展，既有HIS已經無法符合相關需求。”小核心、大週邊”正是因應這樣的現況產生的概念。不用一次更換龐大的HIS系統，而是將資料以FHIR格式匯出，並將創新的應用建置在FHIR Server之上，各醫療單位可以依照自身HIS更新的步調，逐步將HIS功能轉移至FHIR應用，最後再考慮是否替換HIS核心系統。

FHIR與CQL

當FHIR被廣泛應用時，資料格式與代碼一致意味著後續的資料應用將會簡化且標準。資料使用者只要定義好相關邏輯，就可以取得所需要的資料且確保資料內容的正確。因此，CQL(Clinical Quality Language)的應用也就應運而生。CQL使用示意圖如下：

最上層是CQL，定義為領域專家為特殊應用所撰寫的語言；中間層為ELM(Expression Logic Model)，透過XML方式，將CQL轉換微電腦容易實作的語言，透過ELM的界接，不同的程式語言(CQL、Java、C#…)都可以發轉專屬的轉換機制，將ELM轉換成系統開發所需的語言或程式庫。由於中間層與底層的轉換可透過工具自動執行，這代表著領域專家可以透過CQL的撰寫與工具的應用，自由存取FHIR伺服器所儲存的資料。

最明顯的應用是CDS(Clinical Decision Support)與CQM(Clinical Quality Measurement)。

參考官網 https://ecqi.healthit.gov/fhir 可知eCQM是以標準電子格式指定的測量，使用從電子健康記錄（EHR）和/或健康資訊技術（IT）系統電子提取的數據來衡量提供的醫療保健質量。

eCQM由三個主要組件組成：

• 數據模型（Data Model）：這是eCQM的基礎，定義了需要收集的數據類型和格式。
• 表達邏輯（Expression Logic）：這是eCQM的核心，它描述了如何使用數據模型中數據來計算測量結果。
• 結構（Structure）：這是eCQM的框架，它確定了測量結果的呈現方式。

• 現行eCQM：包括QDM數據模型、CQL邏輯和HQMF eCQM。報告部分則包括QDM數據模型、QRDA I和QRDA III。
• eCQM與FHIR：包括QI-Core profiles、CQL邏輯和FHIR eCQM。報告部分則包括QI-Core profile、DEQM individualDEQM summary。FHIR相關的Implementation Guide包括Quality Measure Implementation Guide和Data Exchange for Quality Measures(DEQM) Implementation Guide。

FHIR與資安

Grahame Grieve在2017年HL7 FHIR DevDays中提到，Security Problem Space包含以下議題，以下說明以Grahame Grieve 2017演講為基礎，屬於概念說明。實際狀況會適時補充說明。

• Basic Web Security
  由於FHIR資料交換主要還是透過RESTFul API，基本網路資安必須考量的議題都是FHIR必須考量的議題。詳細技術細節不在本文說明範圍。

• 認證/授權/存取控制(Authentication / Authorization / Access Control)
  建議採用Two layer OAuth，將OAuth Server區分為Health Records Server(HRS)與Identity Server(IS)，HRS提供”What healthcare records should this application get access to”，IS則是負責”Identification information about the patient”，Grahame提到IS建議提供國家級的Identity server。

Smart App Launch則說明了概念性的流程與做法，包含Client端如何啟動、Client與Server如何互動以及提供Smart App Launch Scopes定義通過認證與授權之Client所擔任的角色以及資料存取範圍。HRS將回傳 [class]/[type].[mode]形式之Smart App Launch Scopes，其中
• Class = patient | user | system
• Type = * or a FHIR resource type
• Mode = * | read | write
定義Client的角色、FHIR資料存取範圍以及資料處理權限。但如同Grahame Grieve後來說明，FHIR並沒有提供一個標準的Access Control Layer，實際的作法仍取決於開發人員。後來相關的技術發展與標準，則是以SMART on FHIR為主。

• Digital Signatures
  FHIR透過Signature Data Type來實現數位簽章的需求，包含兩個應用情境：Provenance.signature與Bundle.signature。Signature Data Type定義如下：

定義了解釋數位簽章所需要的metadata，數位簽章則是以blob方式儲存。

• Audit Trail / Provenance tracking
  Audit Trail即為事件的紀錄，包含Login/logout、RESTful API transaction以及Higher level event (RWE)。通常只有產生，不會修改或刪除，必須考慮防竄改機制(Grahame提到區塊鏈技術，但應只是思考而非建議)。

Provenance tracking則是說明資料的來源，從5W(Who, What, When, Where and Why)角度提供相關說明，Client程式可從REST API之http header取得相關資訊。伺服器端則是以AuditEvent紀錄並儲存。

就目前所知的技術發展，這一部分並不完整。

• Security Labels
  雖然triple – A機制已經提供了資料保護的措施，但由醫療資料本身具有強烈的機敏性，仍有些特殊狀況需要做特別處理，例如VIP Patients、Confidential records以及Restricted use data(僅使用於研究而不是用於治療)，Security Labels定義了相關的適用性以及建議作法。

就目前所知的技術發展，這一部分並不完整。

FHIR於GCP之應用

GCP提供了基本的FHIR Server應用(FHIR Store)，同時結合GCP其他的應用如Google Cloud Storage, Cloud Function, Big Query, Pro/Sub等功能。整體來看，結合公有雲的特性，GCP適用於多個醫療機構資料彙整，中小型系統使用各自獨立的FHIR Server，透過資料同步與清洗機制，所有資料即可彙整於雲端之FHIR Server。

延伸閱讀

HAPI FHIR測試環境建立
FHIR REST API介紹
International Patient Summary (IPS)
HAPI FHIR介紹