臺中榮總採用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團隊表示,還要持續改善即時戰情室的建置工作,期望在不久的將來落實於院內,來強化第一線即時醫療照護服務。

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


熱門新聞

Advertisement