【FHIR應用實例：臺中榮總】瞄準精準醫療即時戰情室，中榮先以FHIR結合生理量測練兵

「我們要打造一套精準醫療即時戰情室！」臺中榮總資訊室資訊工程師暨智慧醫療AI小組組長范承佑說道。去年開始，臺中榮總瞄準精準醫療，要建立一套戰情室來即時彙整病人各種生理量測數值，並以一套儀表板來呈現數值走勢，幫助醫護人員即時決策。而戰情室的關鍵資訊，不只來自院內醫療資訊系統（HIS）資料，還包括了各種外部IoT醫療設備的連續性資料，譬如像是生理量測機、呼吸器、穿戴式裝置等。

但是，「要整合這些資料且即時更新資訊，可不簡單。」范承佑指出，不像院內醫療資料，可輕易從核心資料庫撈取，這些來自外部廠商的IoT生理量測設備資料，會因為資料格式和量測數值內容的不同，而難以整合。

比如，一些廠商的IoT設備資料格式，可能採JSON、XML，或者是自訂的資料格式；而同樣是生理量測機，一些廠牌可能只顯示心率、呼吸值，另一些可能顯示呼吸次數、波型資訊等。

這對IT人員來說，就有兩個挑戰。首先，工程師必須想辦法整合不同格式的生理量數值，因此得花時間理解每臺量測機的所有資料欄位，再將所需的資料轉換為醫院統一格式；同時，工程師也得理解不同廠牌生理量測機所產生的資訊，並從中撈取醫院所需要的資訊，而非全盤接受。也因此，「醫院每新增一款生理量測機，工程師就得挪出更多時間來處理資料介接問題。」

臺中榮總資訊室資訊工程師范承佑指出，團隊以MongoDB自建一套FHIR伺服器，希望透過FHIR RESTful API將中央站生理量測數值轉換為FHIR格式，存入FHIR伺服器。圖片來源／臺中榮總

以FHIR打破資料隔閡，先從小規模病房試驗

為解決資料標準不一的問題，臺中榮總IT團隊找尋不同解決方案，後來看上新一代國際醫療資料交換標準FHIR，決定以FHIR來串接不同設備的資料。FHIR問世九年，由專門制定醫療資料交換標準的國際HL 7協會設計，目的是要解決前幾代標準（如CDA）的問題，比如將複雜資料欄位規範簡化、可支援臨床和非臨床類型資料，以及支援更多資料格式，像是XML、JSON和Turtle。

更重要的是，FHIR遵照HTTP網路通訊協定，以行動裝置常見的RESTful API來介接資料，因此，只要是支援網路傳輸技術的IoT設備，就可以透過FHIR來交換資料，以彌補HL7 v2、HL7 v3、CDA的不足。透過FHIR，IT團隊就不必再一對一自訂API，來串接每款生理量測機。

正因為這些優點，臺中榮總決定以FHIR來打造即時戰情室，於是選定院內一間只有15臺生理量測機的病房，來小規模測試FHIR整合資料的能力。范承佑指出，還沒採用FHIR前，戰情室的資料處理流程是由每臺生理量測機收集心率、呼吸數值，再將這些數值統一彙整至一臺廠商提供的中央站，再由中央站將這些資料傳送至醫院接收端資料庫。這些資料經過醫院資料庫分析處理，就可透過UI儀表板來呈現數值變化，供第一線醫護人員參考。

有了FHIR，原本的資料處理流程就能以兩種理想情境來實現，一種是將中央站彙整的資料，以FHIR RESTful API來介接至醫院接收端的FHIR伺服器，最後在FHIR伺服器中分析數據，以儀表板來呈現即時數值變化。其中的中央站資料介接工作，可由醫院或廠商來進行。

另一個理想情境，則是直接在各IoT生理量測機端，以FHIR RESTful API將資料儲存至醫院接收端的FHIR伺服器，最後再以儀表板即時呈現數值變化。也就是說，在這個情境中，資料介接的地方從中央站改為每臺生理量測機，直接省略中央站。不過這種理想情境，還得在廠商設備支援FHIR的前提下才能實現。

與此同時，范承佑也研究了FHIR資料格式規範，像是生理量測常用的資料欄位定義Patient和Observation。同時，他也嘗試了不同的FHIR工具，包括免費開源的HAPI FHIR伺服器，以及付費的Azure API for FHIR、Google Cloud Healthcare API和AWS FHIR雲端平臺等，都試過了一遍。

不過，幾經考量，「我們決定自己來建立一套適合執行FHIR的環境，」范承佑說。

以Node.js和MongoDB自建FHIR環境，從嘗試中不斷修正

他解釋，這是因為，團隊想先熟悉FHIR整體運作流程。「我們想了解，資料從IoT設備端轉換為FHIR格式、進入資料庫，最後再以UI儀表板呈現數值變化的過程。」於是，臺中榮總以MongoDB自建FHIR資料庫伺服器，再以Node.js來打造呈現生理數值變化的UI儀表板。

由於院內IoT生理量測設備已有原本介接的資料庫，因此不得更動資料介接模式。臺中榮總想出一套解法，從原本資料庫中撈出所需資料並轉換為FHIR格式，儲存至MongoDB。圖片來源／臺中榮總

然而，正當團隊想要串接起FHIR資料傳輸流程時，卻發現3個問題。首先，臺中榮總現有的IoT生理量測機並未支援FHIR格式，因此無法直接以FHIR格式來傳輸資料；再來是通訊端點Socket問題，因為，這些IoT生理量測機原本已有一套介接方式，已由Socket指定特定IP位置，將資料傳送至院內資料庫，因此要將IoT設備資料介接到FHIR伺服器，就得重新設定Socket的介接IP位置。

范承佑指出，如果將資料接收端改為FHIR伺服器，會衍生出資料是否能正確傳送和顯示的問題。此外，如果要改變接收端環境，還得重新寫程式，較耗費時間。

而重新寫程式則會引發第3個問題，也就是程式改寫時，院內接收端會無法接收IoT生理量測資料，因此造成儀表板無法顯示資料，影響第一線醫護人員的工作流程。

於是，臺中榮總想出一套解法，在不更動現有工作流程的情況下，來進行FHIR資料格式轉換。也就是說，他們維持原本IoT生理量測機和中央站的資料處理流程，但在原本接收端的資料庫中，「將資料撈出來，轉換為FHIR格式，」並存入FHIR伺服器，最後再以Node.js來呈現生理量測數值變化。

進一步來說，團隊將FHIR資料轉換分為三步驟：首先是從原本資料庫抓取生理量測資料，並轉換為FHIR格式規範的Patient和Observation型式，再來將這些FHIR格式資料，以POST指令傳送至FHIR伺服器；這兩個步驟，都以程式語言Python來執行。完成這兩個步驟後，最後一步就是將FHIR伺服器中的生理量測資料，以GET指令撈出，再以Node.js來呈現數值變化。

臺中榮總資訊室資訊工程師范承佑指出，在資料轉換過程中，以Python從資料庫的大量生理量測數值中，抓取出病歷號、姓名、性別等資訊，並將這些資訊轉換為FHIR Patient資料型式。圖片來源／臺中榮總

除了Patient型式資料，臺中榮總也以Python從資料庫中撈取病歷號、量測時間、心率等生理量測值，並將這些值轉換為FHIR Observation型式，再將這些資料存入FHIR伺服器。圖片來源／臺中榮總

范承佑也以資料轉換實例，來說明從資料庫中，找出所需資料並轉換為FHIR格式資料的過程。比如以Python從資料庫中的大量生理量測數值，抓取出病歷號、姓名、性別等資訊，並將這些資訊轉換為FHIR Patient資料型式；另一個例子則是透過Python，從資料庫中撈取病歷號、量測時間、心率等生理量測值，並將這些值轉換為FHIR Observation型式，再將這些資料存入FHIR伺服器。

這些資料整合至FHIR伺服器後，便可清楚呈現撈取資料的類別和細節，包括一位病患的基本資料、生理量測資訊如心率和量測時間等。

最後，為了將這些資料呈現給第一線醫護人員，范承佑團隊也寫了支網頁程式，來呈現患者即時量測數據。在網頁首頁，使用者可以文字形式來閱覽病患姓名、病歷號、性別和量測記錄等資訊。如需要更詳細的資訊，使用者只需點擊病歷號，就可查看視覺化的患者連續生理量測數值變化，一旁還會以JSON檔案內容來對照，來確認數值。

臺中榮總將FHIR資料庫分析後的數值，以網頁介面呈現，除了顯示生理量測數值變化外，還會附上JSON檔資料內容，給第一線醫護人員參考。圖片來源／臺中榮總

FHIR實作反思：即時性資料量大是最大問題

在這場一年多的試驗中，臺中榮總IT團隊雖然成功以FHIR來整合院內資料和IoT設備量測數值，但也意識到不少實作問題。首先，「IoT生理量測機的即時性資料過於龐大，」如果只依靠FHIR Server作為儲存端，在轉換和傳送資料時，就可能發生傳送效能不佳或延遲的狀況。

這是因為，IoT中央站每分鐘會派送一次資料，而且每份資料都會先轉換為FHIR格式資料（比如心率存一套、呼吸值存一套），如此就大幅增加儲存容量。范承佑指出，就FHIR測試病房來說，每分鐘會派送15臺IoT生理量測機資料，而在轉換為FHIR的情形下，每天產生約為30MB的資料量；與之相比，原本同一病房在未採用FHIR的情況下，每周也才產生20MB的資料量。

也因此，為解決資料量大造成的傳送效能問題，范承佑團隊想出一個方法，也就是當IoT生理量測機以FHIR格式將資料傳送至指定地點時，只需存取所需資料即可，或於資料再次轉傳時，將資料轉為FHIR格式傳送即可。

至於儲存量大的問題，團隊思考，要是能將同一病患同一時間的生理量測資料整合為一，比如將心率和呼吸值合併為一筆資料來儲存，或是以Data Hub文字檔方式儲存（如JSON），也許能克服儲存空間不足的問題。

另外，由於前述每產生一筆生理量測資料，就會存為一份FHIR Observation格式資料，因此當資料過多時，容易發生前端解析Observation資料過久的狀況。對此，團隊打算將前端解析FHIR格式資料的工作，改為在後端接收IoT生理量測資料時，先將所需資料提出，再送到前端儀表板顯示。

不只如此，面對資料爆量問題，團隊也思考FHIR伺服器的佈建。范承佑指出，要是病房加入更多IoT生理量測機，他們計畫部建更多FHIR伺服器，來緩解設備過多造成的資料爆量問題；或是從機制上調整，先在FHIR伺服器接收IoT設備資訊時，撈出必要資訊，並直接送至儀表板介面來顯示。

FHIR公用樣板來檢測資料正確性，醫院與廠商更得有套合作模式

話鋒一轉，范承佑也思考到，未來IoT設備廠商開始支援FHIR資料格式後，醫院還會面臨一個問題，也就是「如何知道IoT設備傳出的FHIR格式和內容，是否正確？」

在他看來，臺灣今年首次舉辦的FHIR聯測，若透過聯測產生了公用FHIR樣板，臺中榮總就能用來打造自動檢測程式，來驗證醫院的IoT設備廠商資料格式是否正確。

除此之外，要使用FHIR互通資料，醫院與IoT量測設備廠商還得有套配合模式才行。對此，范承佑提出兩種合作模式，一是廠商在中央站集中IoT量測資訊後，以FHIR RESTful API將資料以POST指令傳送至醫院接收端，「如此一來，也能減輕醫院在FHIR 伺服器介接的工作量。」

另一種模式，則是IoT廠商不必設置中央站，直接在每臺生理機端產生FHIR格式資料，透過POST指令將資料送到FHIR伺服器，由醫院直接解析資料、將數值變化呈現在儀表板上。

有了這次FHIR戰情室先導專案經驗，臺中榮總IT團隊表示，還要持續改善即時戰情室的建置工作，期望在不久的將來落實於院內，來強化第一線即時醫療照護服務。

 相關報導  醫療資訊交換國際新標準FHIR