口述／孫培然‧彙整／CIO編輯室
電子病歷如果要上雲，大家可以想像的就是，系統要從本地端連到遠端的公有雲，也就是要通過網際網路（Internet）上網。但網際網路的穩定性及品質可靠嗎？此外，大家都在搶網際網路有限的頻寬，網路傳輸常常會有延遲的情形，可能你就是要等等等，一直要等；再來是在有限的頻寬之下，大家如果要搶就會塞車，這也是一大問題。
由於你無從得知網際網路後面的整個網路架構，沒有像我們在醫院裡的網路架構那麼單純，可能會有很多複雜的網路架構，網路之間的連結盤根錯節，讓你沒有辦法去處理。另外，在網際網路上會有很多的駭客在那邊等著你，對外網路真的安全嗎？
[ 推薦閱讀：ChatGPT 打開全新企業服務篇章 ]
在醫院內部使用區域網路，你高興下載多少資料到你的電腦都沒有問題，現在若透過網際網路到外部的公有雲下載資料，你每一次下載或者是瀏覽都需要成本，會遠比我們在院內自己架設區域網路的費用還要高。這些都是電子病歷上雲後所需要面臨的挑戰，
目前醫院資訊系統上雲的應用情境
縱觀整個醫院的資訊系統要上雲的情境，本文所談的電子病歷，大概就泛指醫院的資訊系統（Hospital Information System，HIS）以及電子病歷系統（Electronic MedicalRecord，EMR）。至於電子郵件伺服器、電子教學、衛教影音及官網等，通常稱為一般應用。
衛生福利部於 2022 年 7 月 18 日已公告電子病歷可以上雲，台灣的醫院現階段可以馬上做到的應用，就是將電子病歷備份到公有雲上的異地備份，將醫院每天產生的病歷資料，直接透過備份軟體儲存到雲端上，而不用備份到，再運送到遠處地方去保存。
以中國醫藥大學附設醫院為例，將每天產生資料先備份到磁碟，再透過院內交通車送到北港附設醫院保存。其原因是為了因應醫院評鑑規定要異地備份到方圓 30 公里以外的地方，主要是怕地震，如果地震震垮了，資料就都不見了。但不是每個醫院都能做到的，還好現在電子病歷上雲已經合法化了，所以各醫院就可以將每天產生的資料直接備份到境內的公有雲上，實現符合醫院評鑑要求的電子病歷異地備份的機制。
[ 2023年企業IT投資重點為何？資安、人才、ESG如何部署？下載 CIO大調查報告 立即揭曉！]
一般應用如果是經常對外服務的系統，則是可以直接部署到公有雲上，這樣的好處是可以減少 IT 人員的管理負擔，並且提高安全性及穩定性。至於要將電子病歷部署到公有雲端，目前台灣還沒有任何一家醫院可以放上去，甚至想要做到系統異地備援，也就是說本地端主機一旦當掉，可以馬上切到公有雲上，也都還沒有醫院做得到。
如果遇到高爆發量的時候，例如突然有大量傷患進來，院內的主機設備不堪負荷時，能否利用雲端來平衡負載，目前台灣的電子病歷相關系統也都還沒有辦法做到。
總結歸納，目前台灣醫院資訊系統上雲的應用情境，如圖一所示，只能做到電子病歷的雲端異地備份及一般應用程式部署到公有雲，而圖中所提到的電子病歷相關系統部署到公有雲、雲端異地備援及雲端負載平衡等，到目前都還沒有辦法做得到，因此，醫院未來重構HIS系統一定要有長遠之計，個人強烈建議導入微服務重構現代化HIS架構，只要邏輯性的系統架構對了，未來不管要放在私有雲、公有雲，甚至混合雲皆可。
台灣醫院資訊系統架構落後
為什麼只有電子病歷的雲端異地備份，以及將一般應用部署到公有雲這兩項可以馬上做到？因為綜觀整個資訊系統的架構演進，雖然已從 1 層式（1-Tier）、2層式（2-Tier）、3層式（3-Tier）演進到雲原生（Cloud Native）架構，可請參考本期刊 2023 年 2 月號，「既分且合的資訊架構演進史」專欄詳細說明，但坦白講，台灣醫療資訊系統架構的演進，已經大概落後兩代至三代的時代。
不管是各大醫學中心，或是區域醫院、地區醫院、甚至基層診所等，有 90% 以上的醫療院所的 HIS 系統都還是停留在 Client/Server 架構，大概都還沒有到 Cloud Native 或是微服務架構。也很可惜近年來，有部分的醫學中心與區域醫院，耗費很大人力與成本來重新改寫 HIS 系統，但還是以集中式單體的 Client/Server 或三層式架構為主。
[ 推薦閱讀：孫培然專欄所有文章 ]
目前中國醫藥大學醫療體系由本人所負責的新一代HIS 4.0就是採用微服務架構來優化再造HIS系統將系統運行於容器化維運管理的 Kubernetes 上，讓系統可以靈活快速地遷移到公、私雲上。並且計畫未來利用公、私有雲來做到互相備援，降低資訊基礎建設的投資成本，又可以做到更具靈活性的應變能力，以及面對不確定性狀況發生時，系統可以靈活地快速遷移到公有雲上，讓系統服務持續營運不中斷，提高敏捷韌性（Resilience）的醫療照護應變能力。
最近幾年，由於本人極力推廣以微服務重構現代化 HIS 架構，也到各醫院巡迴演講採用微服務架構的好處，受到各醫院資訊主管正面的回應，目前據了解已有很多醫院計畫未來採用微服務架構，來優化再造 HIS 系統（如：成大、北榮、北醫、中榮、中山、義大、童醫院、國泰、和信癌症醫院…等），透過循序漸進的方式，無縫接軌安全轉移，可以很有彈性地上公私有雲。
內部網路與網際網路的差異
醫院的資訊系統，過去因為都只是在醫院裡面使用，所以只要把醫院的網路做好，也就是透過內部網路（Intranet）來使用，因為只有內部的人會使用，所以傳輸速度一定是很快，不會延遲，通信品質也是非常穩定。網路的容錯能力也會比較高，設計跟維護都非常的簡單。
但如果要上雲，醫院就要透過網際網路（Internet）的方式來溝通。網際網路會有哪些問題？第一個是它傳輸的資料量很低，速率很差，而且因為屬於公有，很多駭客會虎視眈眈的想要害你。
網際網路的速度絕對比內部網路還慢，常常會有延遲的狀況，網路常常會偶爾瞬斷，容錯能力也很低，如果剛好有人在挖馬路，不小心把電信網路挖斷了，很抱歉，你就只能等到它修復以後才能繼續，但醫院那有可能容忍這種狀況。設計跟維護也是非常的困難，所以一旦要上雲，我們就要考慮清楚，如果不行，那就不要輕舉妄動。
單體式架構 vs. 微服務架構
由於台灣的 HIS 有 90% 是屬於 Client/Server 架構，就是把很多的企業邏輯規則及操作畫面寫在一起，這種方式又可稱為單體式（Monolithic）架構。如果要將這麼大的東西上雲，就可能會像恐龍這種龐然大物一樣，吊在半空中，上不了雲。
所以有人形容台灣目前的 HIS 是大恐龍，當然就會上不了雲，必須要把它發展成微服務架構，把程式寫成一支一支小小的服務程式。
微服務的好處是可以輕巧的上到雲端，它可以秒級運行啟動服務。一旦服務有問題死掉了，它可以自我修復。再來就是遇到大災難整個機房或網路毀損，或者是遇到高暴發量的時候，可以自動搬移到可用雲端，也就是前面講的雲端平衡負載。
此外，傳統的資訊系統架構，屬於同步機制，也就是說會有很多程式在需要存取資料庫時，正在運行的服務如果沒有做完，後面的程式就只能一個一個的排隊，等到前面的服務做完，才能輪下一個，等到做完再輪到下一個。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球 CIO 同步獲取精華見解 ]
所以有時候在資訊系統作業的巔峰時期，你會發現為什麼「存檔」鍵按下去要等好幾分鐘？因為它是同步的，只有一條線，你必須要排隊，這就是集中式單體架構的缺點，如果程式上雲端，但雲端的頻寬有限，是不是每一個人都要排隊？
所以要做到不排隊，就要做非同步，才能減少擁塞。譬如：醫院的收費櫃檯不能只開一個，而是機動性伸縮開放櫃檯數量，一旦人比較多時，就開另外一個櫃檯，幫忙消化這些排隊的人，避免塞車的情形發生。
Client/Server 架構是一種有狀態服務（Stateful Service），所帶來的問題存在已久，也就是程式在執行的時候，必須要先回到伺服器去問，目前的狀態是什麼，再將這個狀態記錄在伺服器上。但如果現在網路剛好遇到瞬斷的情形發生，就算只是瞬斷一毫秒，這個實例（Instance）身上保存的狀態也會消失，導致程式必須要重新啟動才能再繼續運行，使用者一定會抱怨。
所以我們要改成微服務架構，也就是無狀態服務（Stateless Service），程式只要一開始執行，就會把狀態記錄在程式上面，也就不會受到干擾。就算網路瞬斷也沒關係，因為服務實例都已經有記錄剛才的狀態是什麼。
Clinet/Server 架構上雲只是自找麻煩
反觀 Client/Server 架構的前端應用程式跟後端資料庫，都是在本地端，但為了要上雲，必須要將資料庫搬到雲端，等於是自找麻煩，因為本地端的前端應用程式每一次都要跟雲端資料庫溝通，網際網路的速度偏偏又慢且不穩定，勢必常會延遲或者瞬斷，容錯率又低，還必須要付出高昂的通信費用。所以台灣的醫院 HIS 架構不改變，真的上不了雲，上雲只是自找麻煩而已。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
