Taiwan Medical Medical Tourism medical travel
系統當機並不罕見，郵局、臺鐵或桃園機場等各種大型組織都發生過，臉書、Line也難逃這種無預警事件，動輒影響上億用戶，或造成無數交易中斷，但這些都不比醫院系統當機還可怕，畢竟醫院系統攸關的不僅是交易，更是病患的生命安危，就連臺大醫院等級的大型醫院都經歷過慘痛的系統當機事件。
新光吳火獅紀念醫院（簡稱新光醫院）資訊室主任湯慎元表示，他們也遇過系統當機，當時為配合政府推動的系統雲端化政策，資訊部門在測試從醫院診間系統連線到衛福部系統的網路，沒想到IT人員只是輸入一個平常常用的指令，卻意外導致核心網路交換器斷線，花了5分鐘重新連線。
重新連線後，開發端系統也跟著當機，由於當時醫院門診交易量大，資料還原失敗，雖然有備援機制卻還是無法立即啟用，因此他們先切斷原本當機的系統連線，重新接到備援系統，讓備援系統單獨運作。
資訊部門花了2小時緊急救火，才讓系統及時恢復，不過這之中大約有1個多小時都在找問題，若以平時下午門診約2千多人來估算，相當於影響了上千人。湯慎元回想事發當時仍心有餘悸，電話響個不停，民眾抱怨及高層關切電話蜂擁而至，資訊部門面臨巨大壓力，差一點就被迫要取消當日的夜間門診。
事發之後，趁著假期醫院休診時，湯慎元親自帶隊進行全院演練，模擬整個系統當機事件的發生與排解流程，從網路層怎麼修改、資料層怎麼轉換，他帶著整個資訊部門重頭演練一次，找出最佳解決方案，他說，之後若再發生，預估3～5分鐘可以搞定。
「這是一次很好的機會教育，」湯慎元表示，「任何廠商開發出來的軟硬體都有Bug，而且你永遠都不知道什麼時候會踩到地雷。」就像這次事件，只是一般IT人員常下的指令，並無特別之處，但卻引發了後續的系統當機，事後美國原廠才告知是系統Bug，需更新軟體版本。
湯慎元認為，只要有資料庫都可能會發生資料不見或是系統當機，就算有SOP或是演練過都未必有用，因此，臨場的緊急應變非常關鍵，事發當下如何用最短的時間排除問題、恢復系統，取決於IT人員對資料庫的熟悉程度，以及足夠的技術和Know How，不只要對資料庫設計原理有一定程度的了解，還需要日積月累的資料庫管理經驗，才能迅速判斷出正確的解決方案。
而高速公路就是資料庫最好的寫照，湯慎元說，即使一直拓寬道路、加建新高速公路，車流量問題仍然存在，需要高乘載、夜間免費等配套措施，一旦發生交通事故，更得在最短時間內進行事故排解，以免交通癱瘓，而這些車流量就如資料庫的I/O，CPU和記憶體則是高速公路本身的硬體建設。
他指出，資料庫看似簡單，但實際上挑戰很多，企業內部的資料庫管理者（DBA）與程式設計人員之間無法達成共識，找不出程式改善和資料庫調校作法，往往最後便花錢採購新設備來提升系統效能，但湯慎元認為，這是治標不治本的方法，3～5年後資料量暴增時又會再面臨同樣的問題，這些企業始終不了解資料庫真正的問題癥結。
那到底資料庫問題該怎麼破解，湯慎元從20多年資料庫管理經驗中，歸類出幾個重點。首先，從數學原理來解，湯慎元解釋，要思考如何讓SQL指令盡可能縮小檢索範圍（Narrow Search），因為SQL指令多寡是直接影響到資料庫效能的關鍵，此外，資料庫每個成員被SQL指令選中的機率（Cardinality基數值），也會影響效能。
湯慎元以新光醫院內部的實際資料庫調校應用為例，他們有一套供高階主管使用的EIS決策管理系統，這套系統中的資料庫SQL語法，便決定主管查詢資料所需的時間。其中，有一個批價碼的資料表包含了2,500萬筆資料，每執行一個SQL Getpage動作，需要13萬次I/O，平均查詢時間要花30～40秒，這是因為原本的Cardinality值太大，並沒有達到Narrow Search原則。
湯慎元解釋，資料庫會根據數據條件提供最佳存取路徑（Access Path），但是有時候資料庫可能會算錯，或是使用者資料輸入錯誤，導致算出的最佳解未必是最好的解，但是若考慮到上述的兩個數學原理，只要加個一行短短的指令（OR 0=1）之後，讓工程師可以自己做決定，選擇另外一個存取路徑，就能避開錯誤的選擇。
他認為，如何在不修改程式邏輯與SQL前提下，引導資料庫選擇Narrow Search，就是對DBA的一大考驗。而經過調整之後，新光醫院這個資料庫每次執行SQL Getpage的I/O數只需要不到3萬個，查詢時間也因此大幅降低到3～4秒之內，速度差了10倍。
另一個則是新光醫院掛號系統的例子。通常民眾看病時，若需要回診，醫生會直接透過電腦系統幫病患預約下次門診時間，湯慎元說，這是新光醫院內部使用率最高的系統，每天4～5千個門診量，醫生時常會用來查詢其他時段的門診資訊。
而湯慎元將Boolean函數概念納入這個系統的SQL語法設計，來判斷更精準的最佳路徑。在使用布林語法來取代多重索引查詢後，該系統平均每30分鐘的SQL Getpage從123萬次I/O變成只要12萬次，節省了10倍的I/O數。
此外，資料表及索引的比例，以及重整（Reorg）資料庫的時機和頻率這兩件事情也很重要。湯慎元表示，新光醫院目前的資料表與索引比例平均約為1：7，每新增一個索引，都經過非常縝密的評估，因為索引越多，不只是新增、刪除、更新的速度越慢，重整資料庫和還原速度也越慢。
他也指出，SQL和索引設計兩者脣齒相依，且無規則可循，DBA需判斷該資料表相關的SQL程式有多少，以此來調整索引設計，然而他也說，業務需求每天都在變動，尤其以醫療體系來說，要因應國家各種政策、健保法規、病人藥物管控與交互作用、營運策略，甚至是千百種儀器的資料導入，SQL難免要不斷配合修改，因此，定時監控索引設計也是一大課題。
此外，為減省更多I/O，他也建議可以將常被選取且很少更新的小資料表（Small Table）放到記憶體內，或是將資料壓縮。
他說，資料庫基本原理是要以最小I/O成本來考量，也就是最佳路徑來存取資料，因此需要有最佳的索引設計。他認為兩個重要的關鍵因素，一是要讓索引設計滿足SQL 程式碼設計要求，有效控制索引數量，另一則是寫出Narrow Search，相對減少鎖定情況，以及記憶體、I/O和CPU運算量的使用。除此之外，在資料庫中，Optimizer決定存取路徑，因此要提供足夠的資訊給Optimizer，若資訊不足時，Optimizer就可能選擇錯誤的存取路徑。
湯慎元表示，要設計出好的索引沒有標準答案。然而他發現很多社會新鮮人即使學了資料庫原理，卻仍無法分辨上述這些做法的原理和差別，像是叢集索引及非叢集索引、Matching Index及Non-matching Index、主索引鍵（PrimaryKey）及唯一索引（Unique Index），也不清楚資料表中定義Null值的用意為何。
他強調，要管好資料庫，基本功非常重要，得徹底搞懂最根本的設計原理，且不只要熟悉資料庫，其他系統和各方面技術也得有一定的了解。當對架構和原理有一定程度的了解後，便能藉由系統監控工具達到有效管控，但若對資料庫了解不夠深入，單靠監控工具，只能解決一時，問題依舊存在。
新光醫院7成醫療資訊系統Web化
除了將根本的資料庫問題一一解開，湯慎元另一方面也全力推動醫院資訊系統Web化。他進到新光醫院後有三大任務，除了Y2K及民國百年蟲問題之外，就是要全面將醫院的資訊系統Web化，並開發行動化應用。湯慎元表示，他們平均一年做一次使用量最多的大宗儀器導入，依序把最常用的系統Web化，目前完成7成左右。
此外，他們也在2015年導入自行開發的智慧病房及智慧就診兩大系統，智慧病房包括護理站的電子白板系統、病房的床邊服務系統及點餐系統。而智慧就診系統則整合自動報到系統及病患看診前的心跳、血壓測量資訊。對於現在很多醫院都導入的自動批價繳費系統，湯慎元則表示，由於新光醫院當初系統開發以現金制為主，導入自動批價繳費需要系統大改，因此並未列入第一優先導入的項目。
在開發行動化應用上，新光醫院在2013年推出了第一個行動App，稱作健康防癌App，可提供病人看病查詢，湯慎元也說，最近有另外兩個全新的App已經開發完成，即將在今年2月上線。
其中一個App是給醫生專用，讓醫生可以在手機中瀏覽所有檢驗報告跟影像，並能快速查看病人新住院時的住院摘要（Admission Note），湯慎元解釋，當病患抽血檢驗結果顯示有癌症資訊時，以前醫生無法立刻知道，不過現在他們可以透過App即時收到通知，並立刻回覆或是採取適當處置。
另一個則是給全院員工使用的緊急事件回報App，當發生火災、水災及大量傷患等緊急危難事件時，醫院會把資訊通報給全院員工，並設定自動回覆機制。湯慎元表示，未來，他們將持續進行無紙化、行動化、病歷資訊化，並開發通用所有載具的應用，讓醫生和所有內部員工都可以很方便地透過各種管道來取得資訊。
CIO小檔案
湯慎元
新光吳火獅紀念醫院資訊部主任
● 學經歷：臺北護理健康大學資管碩士畢業，擔任職業軍人長達11年，曾於後勤管理中心擔任電子資料組系統組組長、平臺設計與分析師，1992年進到新光醫院擔任系統組襄理，並於2007年接任資訊部主任至今，先後處理過Y2K及民國百年蟲問題，並全面將醫療系統Web化，開發行動化應用
參考資料
http://www.ithome.com.tw/people/103333
留言列表
