【中國附醫HIS再造：應用實例】10支微服務，如何串聯5部門實現一站式智抗菌平臺

問起中國附醫HIS微服務再造之旅中最經典的實例，中國附醫資訊室副主任孫培然自豪地說：「智抗菌平臺。」這個平臺整合了中國附醫自行研發的敗血症風險預測AI、細菌抗藥性預測AI、抗生素投藥建議系統，以及個人抗菌譜系統，這些跨部門的知識和資訊，透過微服務架構，與HIS相連，成了一套一站式的大平臺。其中的抗藥性預測AI，更拿下不少獎項。

中國附醫團隊去年3月完成智抗菌平臺串接，就感受到微服務架構的好處，像是透過事件驅動（Event driven）設計，讓HIS與AI主動溝通，而非傳統做法只能被動交換資料。在開發過程，他們也遭遇不少挑戰，小至資料清理、大至開發人員心態改變，最後一一克服了。

預測細菌抗藥性，挑戰醫界難題

智抗菌平臺主要的3大功能環環相扣，一方面，透過敗血症風險預測，醫護可先確認患者是否需加強治療，如有需要，得及時給予抗生素和輸液治療。這時，細菌抗藥性預測和投藥建議機制，能根據每位患者狀況，來給予適合的抗生素建議，協助醫院實現精準治療。後兩項機制也能單獨使用，不一定要搭配敗血症風險預測機制。

這個細菌抗藥性預測和抗生素投藥建議，可說是醫界難題。因為，能提前了解細菌抗藥性和進行精準投藥，不只能避免抗生素濫用造成的超級細菌反撲，還能大幅縮短病患等待時間，提高生存率。可是，急性傷口感染病患送進醫院時，得先進行細菌培養，再以質譜儀分析細菌菌種，之後透過抗藥性鑑定儀器分析，這個過程需要24小時至48小時，才能確認細菌抗藥性來進行開藥。

在報告產出前，醫師只能綜合患者病歷和當下狀況，憑經驗先開藥，來緩解病況。但醫師經驗並非每次都靈驗，開錯抗生素，更可能讓感染惡化；而延緩開藥時間，甚至可能有生命危險。

跨部門打造一站式抗藥性預測系統，最快1小時就知道

中國附醫院長周德陽和智慧醫療科技創新中心主任游家鑫團隊發起抗藥性預測專案，聯手感染科醫師、檢驗醫學部、藥劑部、大數據中心等部門來打造細菌抗藥性預測模型和投藥建議系統。

因細菌抗藥性是隨時間而改變的，他們用自家2018年至2019年的質譜儀資料和抗藥性鑑定儀器資料，來訓練模型。該模型在前年成型，能針對8種常見且危險性最高的細菌判斷抗藥性。

經過幾次優化，模型最快能在1小時內預測6種細菌抗藥性（以血液培養的細菌為前提），比主流抗藥性鑑定儀器所需的24小時至48小時，快上許多倍。他們也以自家2020年的資料，以及北、中、南、東的代表醫院，包括雙和醫院、部立豐原醫院、臺大雲林分院和花蓮慈濟醫院2018年至2020年的資料，來驗證模型。結果顯示，判斷模型表現的AUC數值，分別是0.88、近0.8、0.85和0.86，表現優異。

與此同時，中國附醫也根據細菌抗藥性預測結果，打造一套條件式的投藥建議系，推薦醫師相對應的抗生素，並依醫院規則來排序。此外，大數據中心也打造一個個人抗菌譜功能，來顯示病患先前做過的細菌分析資料，作為下次就醫、檢測結果尚未出爐前的開藥參考。

這種抗藥性預測和投藥建議系統，在臺灣，只有林口長庚醫院、中國附醫開發相關應用，而中國附醫用來訓練、驗證模型的資料量，是最大量也最多元的。這個成果，後來還寫成論文發表到美國微生物學會期刊上。

這次專案中，孫培然也設計一套一站式的抗生素治療臨床決策輔助系統（即智抗菌平臺），一口氣整合了人工智慧醫學診斷中心開發的敗血症風險預測AI、智慧醫療科技創新中心打造的細菌抗藥性預測AI和投藥建議，以及大數據中心開發的個人抗菌譜功能，讓各單位的使用者不必來回切換系統，在同一個畫面就能查看所需資訊。他所用的整合串接技術，就是微服務。

10支微服務撐起智抗菌平臺，用訊息佇列作為交換中心

進一步來說，孫培然將智抗菌平臺資訊流程梳理為3部分，首先是檢驗醫學部系統產出細菌檢查報告，將報告資訊發送至訊息佇列（Message queue）。這個訊息佇列就像訊息交換中心，接收新資料後，會觸發事件驅動機制，通知敗血症風險預測AI、細菌抗藥性預測AI和個人抗菌圖譜這3大系統，讓這3個系統透過RESTful API，來抓取檢查報告中所需的資料，進行運算。

3套系統各自運算完成後，透過RESTful API，將結果傳送至智抗菌平臺，在相對應的表單欄位中顯示。整個智抗菌平臺，用了約10支微服務來串接，在去年3月正式上線。

這10支微服務，意味著智抗菌平臺底層切分了10個功能。「這就是功能解耦，」孫培然指出，這種方法讓應用程式顆粒度切分得更細緻，不僅運算資源容易調度，解耦後，各功能利用訊息佇列作為共用的溝通管道，各自獨立運作，不必像傳統方法，兩個系統單靠API互相溝通，反而互相牽制。

克服責任歸屬、資料即時更新問題

採用微服務和事件驅動機制，也解決了責任歸屬問題和時效性問題。首先，這套智抗菌平臺整合了跨部門的3套系統，如採用傳統單體式架構，得一一與各部門溝通，先釐清「誰呼叫誰」的順序才能運作，最後還得一一測試所有串接。

此外，多個系統上線後，若其中一個故障，其他系統若缺乏非同步機制，只能等待故障系統傳送的資料，就會跟著停擺，進而影響了整體流程的運作。而且，在傳統架構中，很難釐清哪個環節出問題，「不知道是我沒呼叫你，還是我呼叫了，你沒回應，」孫培然形容，這正是難以找出責任歸屬的關鍵。

另一方面，單體式架構難以即時提供AI系統所需的資料。因為，傳統架構中，AI系統每隔幾分鐘，就得主動發送請求到HIS資料庫，來撈取新資料，更容易增加HIS資料庫工作負載。

孫培然指出，改用微服務和事件驅動的設計，這些問題就可迎刃而解。因為，用訊息佇列作為共通的訊息交換中心，當A系統產出新資料，就會發送至訊息佇列，也會觸發事件驅動機制，就像訂閱通知一樣，主動通知其他有資訊需求的系統，可以來訊息佇列即時存取所需資料了。這就有別於傳統定時撈取資料庫的做法。「除了降低資料庫工作量，也化被動為主動，透過主動通知，讓服務更即時獲取新資料。」

而且，訊息佇列還會記錄各微服務行為，一旦有微服務故障，沒有執行資料存取，訊息佇列也會留下記錄，IT人員能清楚找出哪一支服務發生問題，來快速修復。

推動資料結構化、改變開發觀念

不過，在智抗菌平臺開發過程中，資訊室也遇到不少挑戰，其一是資料結構化。過往，檢驗醫學部產出的細菌抗藥性報告，都以非結構化的自由書寫方式，來描述細菌檢測結果。之後，治療病患的醫師會根據這份報告，來開給相對應的抗生素。但這種書寫方式，並不利於自動化的資料分析。

於是，為了方便AI系統抓取資訊和分析，團隊將原本非結構化的報告格式，改為結構化資料，重新設計一套制式表單，來讓AI系統快速分析。

解決了資料非結構化問題，另一個挑戰則是開發者心態。孫培然表示，傳統IT開發方式屬於集中式，而微服務架構則需要分散式的開發方式，這兩種開發方式更有許多互相違背的做法和設計，因此，在開發微服務前，IT得先放下實行已久的集中式開發習慣。

「唯有歸零，重新學習微服務概念，才能成功開發，」他說。

以微服務架構撐起智抗菌平臺，這個成功經驗，不會是中國附醫HIS優化再造旅程中的唯一案例。由於微服務低耦合、資料隔離、可獨立部署的特性，讓開發模式可複製，至今，中國附醫已有不少HIS翻新成微服務架構，像是健檢系統、採購系統、醫囑系統、護理系統，以及部分教學系統和人事系統等。

去年底上線的網頁版藥囑系統，也是一例。去年3月，這個新版藥囑系統經種子醫師測試後，正式上線。這時，舊系統也仍並行運作，醫護逐步熟悉新系統介面的同時，團隊也根據使用者回饋來改善新系統。直到去年底，新系統優化完成後，他們才開始陸續關閉護理站舊系統。直到今年初，他們關閉了最後2臺護理站的舊系統。至此，使用20幾年的舊系統正式退役，由微服務新系統接棒，而這還只是中國附醫HIS微服務化藍圖中的一步，接下來還有更多新系統要上線。文⊙王若樸

 相關報導