孫培然博士目前擔任私立醫療院所協會醫院資訊暨智慧醫療發展促進會會長，也任職於中國醫藥大學附設醫院資訊室副主任，正進行體系HIS再造工程，是一位勇於接受挑戰及洞燭先機採用新技術的領導者，亦曾在中山醫大附設醫院任職資訊室主任時，回收委外HIS系統，重新改造的成功案例。
很多人會問，HIS（Hospital Information System，醫院資訊系統）執行的好好的，為什麼要打掉重練？
主要的原因包括開發工具太老舊，找不到相關人才；畫面雜亂無章，操作步驟繁雜，使用介面不夠友善，資訊需求也沒有做好整體規畫，導致當前的HIS就像一隻大恐龍，想要修改時，不但修改時間會很長，往往還會碰到改了一個問題，卻有更多的問題冒出來，根據了解就像某些醫院，程式碼已經到不能編譯的程度了，不可能做什麼修改，只能重新撰寫。
[ 下載 2020-21 CIO大調查報告，掌握最新企業IT導入趨勢 ]
台灣的醫療院所不敢動HIS，因為工程太浩大，但是不去改，系統速度就會愈來愈慢，到最後只能用升級硬體來應付，大概每三年就得更換一輪。但是現在又碰到一個窘境，二三十年前在Windows 32位元版本開發的系統，開始會碰到不相容的問題，因為現在的Windows已經發展到64位元，但很多當年採購的軟體，供應商都已經倒了，自己改又很容易碰到問題，根本就沒有辦法解決，所以HIS不是為了重做而重做，是真的已經到了不重做不行的時候了。
當前HIS面臨的問題
我當年被邀請參與幾家大型醫學中心體系醫院的HIS整合專案時，因為每一家醫院的架構都不同，就連同樣的病名或衛藥材，編碼都各不相同，系統過於複雜很難整合，這個專案沒辦法結案，到最後只能不了了之。同一個體系的醫院都很難執行修改，更何況是不同體系的醫療院所？
醫療院所現在該怎麼辦？為了加速HIS系統資料庫效能，線上資料庫只能保存一定年限的資料。所以資料如果累積到一定的量，就得做備份，每個月或每年都得進行資料維護，把累積的資料搬到另一個地方，如果醫師有需要查詢，程式就得寫成到A主機抓三年前的資料，如果還要更早的資料，再到B主機去抓，於是資料不斷的封存，程式也不斷的改寫，長期下來都可能會變成問題。
許多醫院的關聯式資料庫也是個問題，例如原本是十個欄位的表格(Table)，因為需求而要增加一個欄位時，如果這個表格資料太大做資料結構異動時也非常困難，最後只能利用臨床作業的離峰時間，通常是凌晨四點到五點停機去增加欄位，增加不少時間成本。
[CIO都在讀： 醫療業關鍵基礎設施資安進入落實階段 ]
HIS系統架構參差不齊，很多還不能共用，IT人員就得去管理很多系統，修改時還會彼此牽連，相互性衝突很多，這是最痛苦的部分。有一些醫院，光是前端電腦就有上千多台，光是升級就是一個大工程。而且升級還可能碰到失敗，後續的工作負擔也變得更重。控制變數也變多，有任何人亂刪東西或亂動資料，都需要IT人員去維護，非常浪費人力。
醫院如果有一百多台伺服器，還得一台一台的監控主機健康狀況，太難了。如果HIS屬於單體架構，就只能預估未來三到五年的成長量。不能像雲端或VM架構，需要多少就可以用多少，彈性不足也是個問題。現在的主機一旦當機，downtime時間很難預估，如果是用虛擬主機，就比較能夠預估何時能夠正常運作。
現在每個醫院體系的分院，都有自己的機房，每個機房都需要安排維護人員，如果能夠變成雲端架構，整合成一個醫療雲，資源運用可以變得更有效率。
我們的未來願景是HIS採用混合雲架構，醫院自己有私有雲，然後異地備援可以用公有雲。不需要建立兩套系統，一旦私有雲有問題，馬上切到公有雲，公有雲有問題，也可以馬上切到私有雲，而且能夠符合方圓40公里以外的備援距離要求。
現代化HIS具備的架構特性
現代化HIS應該要以病人為中心，用戶會提出各種需求，但有時只是為了資訊化而資訊化，沒有考慮成本效益，應該要有輕重緩急的概念，如為了病人安全就應該優先處理。
以前的HIS是為了申報批價而用，但健保實施之際，很多系統其實是趕鴨子上架，並沒有考慮到整合，健保運作至今，已經有非常完整的經驗，HIS應該要全面性整合最佳化，重新檢視作業流程，精實流程，操作介面統一化及人性化，讓操作者只要學會一套系統的操作介面，就會使用其他系統，同時要有可重用性的模組化概念，並且符合健保需求及評鑑需求。
HIS的資料格式及醫學詞彙要統一標準，一種是交換的標準，一種是詞彙的標準，應該要盡量以國際化為優先，如HL7 FHIR、SNOMED CT等，才能夠跟國際接軌。
[ 加入 CIO Taiwan 官方LINE，與全球CIO同步獲取精華見解 ]
病歷及檢查報告應該要能即時直接標記（Labeling），尤其現在正在發展人工智慧及大數據，許多數據都是非結構化，必須要請醫師標記重點，資訊系統應該要能讓醫師在打報告時就能下標記，就像是在寫文章一樣，以後真的要製作AI相關應用，需要搜尋資料時，只要搜尋關鍵字就可以了。
如果要將非結構化資料結構化，而且要防呆，避免「Garbage in, garbage out」，造成很多資料不正確。事實上，在做AI時，有80%的時間都是花在淨化資料（Clean Data），所以要盡量在輸入時，就能夠檢核資料的正確性。如何透過區塊鏈技術，讓電子病歷等重要資料具備不可否認性，就是值得思考的方向。
從醫療IT的角度來看，應該是怎麼將AI順利落地能夠跟臨床做結合，能夠讓醫師應用AI支援臨床決策輔助，以及如何應用AIoT來做流程自動化，避免有人為疏失而導致錯誤，進而達到閉環管理(Closed-loop) 的目標。
主機要做到虛擬化，提升高可用性及延展性。HIS最痛苦的地方，就是主機因為沒有虛擬化，很難掌控硬體的狀況，即使半夜當機一樣得趕到機房處理。但主機如果虛擬化，就不怕主機突然當機。
以微服務形成體系醫療雲
HIS的原始程式碼要進行管控，做到統一版本。許多醫院雖是同一體系醫院，但卻每一個分院因為都有自己的原始碼，現在想要整合就會變得很困難。
醫院體系要整合，HIS必須要有高容錯度，並可承受高併發量，達到延展性高、擴充性、可攜性及可用性高，要以微服務架構，形成體系醫療雲。
新的HIS架構應該一開始就做好整合，會配合體系分院的特殊性，如不同的院區、不同的藥名、不同的診斷、不同的適應症狀等等，運用Rule Engine進行規範。系統應該要採取Web base，希望可以達成Any Device、Any Where、Any Time、Any Run的目標。同時採用敏捷開發方式，才可以做到持續交付整合及持續部署。
如現在的系統常常需要查詢各種檢驗報告，傳統的方式就是為每一種需求，護理、醫療、檢驗等都建立一套檢驗報告，其實很難管理，也很耗費資源。
所以系統功能應該要能夠隨插即用，將程式分成很多的小元件服務，再透過NPM(Node Package Manager)的概念，把小元件服務包裝成各種不同的系統，有點類似積木的概念，只要將每一塊積木組合起來，就是一個完整的作品，可以隨插即用。
HIS系統採用微服務的優點
以前很多需求都是被動式，為了要看檢驗報告內容有無異常，只能不停的去抓有沒有異常。新世代HIS應該是一旦察覺檢驗報告內容有異常，就會寫成事件驅動（Event driven），不管是醫囑、護理，任何需要這份檢驗報告的人，只需要訂閱，就會收到檢驗報告的異常通知，從被動化為主動，才能符合臨床作業需求。
微服務架構採用的敏捷開發，可以實現團隊的自治（SCRUM），每次在檢視每一個衝刺期（Sprint），兩周之內就可以產出一個微服務。每個服務因為相對較小，只有單一職責，所以易於開發和維護，若干個微服務就可以構建出整個應用，讓整個應用可以被維持在一個可控狀態，不會因為修改一個項目就牽動另一個項目，可以讓複雜HIS達到持續交付及持續部署，就可以縮短系統上線時間。
如此一來，HIS不但可以很快速的得到用戶回應，也才可以快速回饋，服務可以快速、獨立部署及擴展。更重要的是，可以預測何時可以上版、更版、擴充，更可以做到自動化，不用像現在一樣要等到線上沒有人才能更版，可以更快速的上版、更版，做到不影響使用者操作的無縫更版。
微服務架構因為是鬆散耦合的結構，比一步到位全面重構上線的成本低很多，也比較沒有壓力，可以做即時有效監控微服務運作健康狀況。而且許多服務的部署一旦標準化，就可以更快速的發現問題，而不用去抽絲剝繭的花很多時間發現問題在哪裡。
將所有的資源變成一個資源池，不用擔心硬體資源不足，可以按需收縮，根據需求增減記憶體，升級CPU或者增減節點。硬體投資成本因此大幅降低，可以充份利用主機資源，提高資源使用率。更好的容錯性，可以承受高併發量。
因為單個微服務程式碼量較少，所以啟動會比較快。每個服務可以由不同的團隊獨立開發，可以將錯誤與資料隔離，假設其中一個服務出現問題，不會導致整個系統錯誤或資料異常。微服務容許異質性技術，相互協同合作。更容易實驗和採納新技術，技術棧不受限，可以持續前進，不會受困停留在幾十年前的技術。
管理您的應用程式，不要把應用程式當成寵物，害怕應用程式隨時會死掉，而是要當成是家畜，應用程式就算死掉，也會馬上有程式跟上遞補。讓應用服務從私雲至公雲，可以做到無縫接軌，於混合雲之間游刃有餘。系統要做到速度快、不怕死、易移動，讓新舊系統可以做到無縫接軌的境界。
導入微服務應循序漸進
所以醫院應該要謀定而後動循序漸進的最佳化再造HIS，可以大幅降低醫院的壓力，進可攻退可守。醫院可以動態擴展所需要的應用程序，無縫地推出新功能，還可以限制硬體所需資源的使用為最小量，不會因為某個服務突然爆發，而影響到其他服務的能量。
但首先要拋開既有的觀念及包袱，一切歸零，重新學習及領悟。因為以前的HIS只有幾個資料庫，但微服務架構的HIS，一個服務就會有一個資料庫，觀念都需要重構。要重構HIS，得先培養種子教官，把整個組織及文化逐步擴散渲染，可以從小系統開始做起。
一切要回歸真實面及實務面。以前是跟用戶談完之後，先把用戶需求正規化成為關聯式資料庫，再寫程式及介面，讓用戶可以存取。若是採用NoSQL資料庫以後用戶有什麼需求，就直接存進資料庫，不需要正規化，較趨近於真實情況。
程式也必須要標準化、統一化及模組化。採用敏捷開發方式，才能達到微服務，並採用物件導向的SOLID概念。前、後端程式語言及技術盡量統一，日後的人員訓練會比較容易，且開發的元件服務可以重複引用。
我建議可以先從小系統做起，循序漸進發展。系統改造應該要採用加法，先建後拆。必須要乾坤大挪移，虛實合競，要將本來是一個單體的系統，依照不同商業邏輯領域拆解成一個個的服務。必須要採用分散式架構，以螞蟻雄兵的概念，一個伺服器可以扛一百個用戶，用戶成長到一千個，就用十個伺服器來扛來應付。進入點只需要負責收取用戶需求，後面交給分散式架構處理，所以雖然是分散式架構，但其實是要做到即集中又分散。
要做微服務，得先打造HIS鋼骨結構基礎，上下進攻，同步進行，不需要從下往上一步步建構，導入事件驅動(Event driven)來設計程式。而且要擁抱Open Source，導入Source Control (git)，還得同時導入容器化服務的Kubernetes(K8S)，才能做微服務，不然很難管理。導入中台服務的概念。導入NoSQL資料庫，並且要做到分片集群(Sharing Cluster)，才能在服務量爆發時，隨時分散出去。
（本文授權非營利轉載，請註明出處：CIO Taiwan）
