臺中榮總採用FHIR進行即時戰情室先導專案，選定院內一間擁有15臺生理量測機的病房，來測試FHIR整合不同生理量測值的能力。（iThome文件照）
「我們要打造一套精準醫療即時戰情室！」臺中榮總信息室信息工程師暨智慧醫療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團隊表示，還要持續改善即時戰情室的建置工作，期望在不久的將來落實於院內，來強化第一線即時醫療照護服務。