口述／孫培然‧彙整／CIO 編輯室
台灣醫師的普遍心聲，就是電腦速度很慢，常常感覺是人在等電腦，或是電腦常常中毒，或是要重灌系統，或可能被駭客索取高額的維護費。
電腦有問題時，醫師也常抱怨叫不動資訊人員。但我要幫資訊人員講一句公道話，並不是資訊人員叫不動，是因為有太多的前端問題要處理，所以真的是忙不過來。我的同事常常接到很多電話，對方常常很不高興的說，我的電話還要轉幾次？但是坦白講，我們不是很多人負責一個系統，而是一個人負責很多系統，所以每一個系統負責人，不見得就懂另外一個系統負責人的系統，所以電話一定會轉來轉去。
醫師對醫院系統的怨言，還有說電腦系統很笨，不夠聰明，還要停機維護；系統可不可以穩定一點，不要再當機了；看個病歷要切換很多畫面，沒辦法一目了然。太多非結構化的資料，沒辦法做臨床分析；病人的記錄資料都是片段，無法持續記錄及追蹤。
系統更換原本便難以一次到位
我們何嘗不想改，但是在台灣有個狀況，每到 3~5 年，醫院 HIS 的效能就會慢慢變差，通常就是先換硬體，以解燃眉之急，如換主機伺服器、加大 CPU、擴充記憶體、硬碟改成 SSD 提升 I/O 效能及提升網路頻寬等，但這麼做其實是治標不治本。
醫院為什麼遲遲不敢換 HIS 系統？因為新舊系統的結構不同，更換系統如果想要一次到位，往往要花很多人力去處理，很多系統在更換時，也會碰到新舊資料同步會造成資料延遲之類等問題。
[ 推薦閱讀：孫培然專欄所有文章 ]
但目前台灣的醫院更換 HIS 系統的做法，通常還是希望一次到位，但想要一次到位，假設更新系統時，所有的軟體、硬體跟資料都不會出現問題，這個挑戰已經是天方夜譚了，更何況很多病人跟醫護人員面對新的流程跟操作都不熟悉都是問題，所以趕鴨子上架更換系統的那一天，通常就是造成整個醫院「亂、亂、亂！」的亂象。
台灣醫院有 90% 以上的 HIS 系統都是屬於 Client/Server 架構，遇到的問題就是系統老舊，開發人才短缺，系統老舊想要支援 AI，當然事倍功半。使用者介面整合度差，不夠友善；系統疊床架屋，系統整合難度高；系統連接多，穩定性不佳；沒辦法跨平台，只能在 Windows 上執行，沒辦法支援行動裝置，這些都是台灣許多醫院 HIS 所存在的問題，已經到了窮途末路，進退兩難的地步。
HIS 優化再造 不須一步到位
所以我希望能創造一個名詞，叫做「HIS 優化再造」。也就是說我們可以一步一步的去翻寫 HIS，不需要一次到位，以免造成人仰馬翻。因為醫療照護必須以病人安全為第一，不可以有任何閃失，所以新舊系統的轉換要做到無縫接軌。但要做到無縫接軌卻是一個很浩大的工程。各位可以想像一下，如果要在高速公路上蓋一座路橋，不可能說在這個路段全面停止行駛半年，先來蓋路橋，所以要如何在不中斷高速公路行駛，又可以將陸橋一點一滴地蓋好，是個艱鉅任務。
所以我才要提出 HIS 優化再造的工法，我稱為「都更計畫」。如圖一所示舊有的 HIS 就像老舊的眷村或社區，我希望先把未來新的 HIS 大樓的鋼構先蓋起來，這個鋼構就是未來新的 HIS 的資料結構（Data Schema），再透過新舊資料做到即時同步後，若我們有充分人力資源就可以從地下最底層樓跟地上一樓同時開工，若人力少時就先從有問題的系統去汰舊換新。用此工法就可以不用一次到位全部把舊有系統換掉，而是可以慢慢的去蓋。中國醫藥大學附設醫院的 HIS 優化再造就是用這樣的工法，慢慢的汰舊換新 HIS 系統。
接下來，我們可以開發一個給醫師使用的行動查房整合系統（如圖二），把所有鋼構轉換過來的資料，透過電子病歷查詢系統，讓醫師可以去確認轉過來的資料是不是對的。系統的操作介面設計可以採用九宮格的概念，讓醫師可以自己設定第一眼想要看到的重要資訊。
啟動微服務架構的優先順序
想要透過微服務架構來做 HIS 優化再造，以下是我提出的啟動優先順序：
（1）新的服務或專案；
（2）舊系統找不到原始程式碼時；
（3）程式維護事倍功半；
（4）系統不穩定，常出問題；
（5）醫院的核心業務系統，如醫師使用的醫囑系統；
（6）使用者較多人的系統，如護理系統會有兩三千個人在用。
再來用微服務架構把前端、後端的程式做分離，這樣子就可以慢慢的把舊系統循序漸進的安全轉移到新的微服務架構，總而言之：「沒有失敗，只有成功，沒有最好，只有更好」。
也只有採用微服務架構，醫院才有機會趁著 HIS 優化再造之際，把醫院的整個流程重新再造，透過 AI 及 IoT 來精實醫療流程，提升整個智慧醫療。各位試想，二十幾年前的系統流程，跟二十幾年後的系統架構是完全不一樣的，所以我們應該要重新檢視整個流程，搭配 AI 及 IoT 來做到全面自動化及智慧化。
緊接著，就是要全面數位轉型，包括全院無紙化、無片化，以及所有儀器全面連線；第三步是要完成閉環管理（Closed-loop management），也就是說每一個流程不需要透過人員輸入，而是透過掃條碼方式自動帶入，可以提升效率，減少錯誤。最後是在流程當中提供醫護人員一些臨床 AI 的決策支援，經過不斷持續改進來做到精準醫療，再提升整個智慧醫療的最佳化。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球 CIO 同步獲取精華見解 ]
如中國附醫導入的門診注射室智慧藥櫃的閉環管理，在過去，醫師在門診幫病人開了一個注射處方，會由門診藥局先調配藥劑，藥劑調配完後，由傳送人員送到門診注射室，病人再到門診注射室去執行施打。一旦有某一個關卡有疏失，就會造成醫療糾紛，這種就是非閉環式的作業流程。
經過作業流程再造之後，我們把五個流程變成三個流程，醫師開完處方以後，病人只要拿著這個處方到門診注射室給護理師，他只要刷處方上的 QR Code，智慧藥櫃就會自動彈出病人所要施打的藥品，再由護理師填充完注射液後，直接跟病人施打。這樣子的作業流程可以減少給錯藥打錯針的問題，這種方式就叫做閉環式管理。不但流程減少了，又可以提升效率，又可以減少錯誤。所以未來 HIS 的流程再造，就必須要以閉環式管理的方式去考量。
目前在中國附醫的住院醫囑跟藥囑系統也都已經上線，頗受臨床醫師的好評，給我們資訊團隊的回饋就只有兩個字，「快」與「美」。快 ─ 操作簡單快速，扁平化結構，一鍵到位，容易上手；美 ─ 畫面整齊一致，個人化設定，一目了然，資訊量多。
透過微服務架構形成一個中國醫藥大學 ─ 醫療體系的私有雲，未來可以讓各個附設醫院及分院，透過網路連回總院私有雲使用 HIS 系統；另外，藉由微服務架構的事件驅動機制，來加速實現醫療 AI 的落地。以中國附醫發展的智抗菌平台為例，我們大概有六個部門進行跨領域團隊整合，首先將檢驗部的細菌報告系統，由非結構化報告重新改寫為結構化報告，檢驗師在發報告時，會將報告發布到訊息佇列（Message Queue），再由三個 AI 中心來訂閱相關報告訊息事件，一旦有新的報告訊息事件時，就會主動推播到 AI 中心的系統去做演算分析，而 AI 分析完成的結果，也會再發布到訊息佇列中，提供給 HIS 來訂閱。當接收到 AI 的預測結果後，直接整合顯示在 HIS 畫面上，讓醫師可以一目了然看到所有的病歷資料及 AI 預測，協助臨床診斷決策之參考依據。
透過 K8s 管理微服務架構
有了微服務架構，我們可以跨任何程式語言，跨任何平台，就不怕找不到人才了。但微服務架構雖然有那麼多好處，但同時也帶來了挑戰，比如說我有那麼多服務，要怎麼發現，要怎麼觀察，怎麼連接？還有資安跟監控的問題，這些都是需面對的挑戰。
所以「合久必分，分久必合」，現代分散式的雲端平臺，就要透過 Kubernetes （以下簡稱 K8s）的方式來管理微服務，就不用怕服務會死掉，因為服務死了它會自動起來，一旦有高爆發量導致程式死掉，也不用怕，它可以自動擴增（Auto Scaling）多個服務來處理。
也就是說，我們可以透過行動化、模組化、虛擬化跟雲端化，把各個醫院的系統整合在一個私有雲上。這個私有雲就是我們可能在總院有一個私有雲，那我們希望達到一個 Any Device、Any Where、Any Time、Any Run，也就是說不管你是用 Windows、用平板、用手機，在任何時間地點，你都可以去使用你的系統。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
