【醫院信息系統典型故障案例解析】系統程序代碼邏輯問題導致業務故障
《醫院信息系統典型故障案例解析》一書收集整理了53個醫院信息安全典型案例,內容涉及基礎設施、網絡設備、主機應用系統、數據庫、安全設備、虛擬化等各個方面。該書在CHIMA 2019大會發布后即受到醫療信息化同仁的一致好評。現CHIMA加印了第二版,同時在公眾號發布數期典型案例,為大家分享信息安全事故經驗,避免事故重現,共建醫院信息安全網絡。
【案例概述】
案例關鍵字:程序代碼 邏輯問題業務故障
相信很多醫院都會面臨這樣一個問題,某業務系統系統使用多年,系統用戶都已經習慣舊系統,相對來講運行穩定、出問題也少,但如果沒有原廠維護更新,一方面會導致系統功能無法滿足醫院日益發展的業務需求,另一方面很可能會在某些數據庫或者應用程序層面細節上有些“暗雷”,說不準哪天就會炸。小L就碰到了一個類似的問題,數據庫表里面某變量字段長度到達應用程序限值導致檢驗系統新增病人無法新開和執行檢驗項目,小L在測試驗證、聯系廠家核實之后,確定是程序代碼邏輯問題,后采取騰出未使用變量空間方法,解決故障。
【案例還原】
醫院檢驗系統與門診、住院系統都是通過接口調用進行交互,報障電話中,有檢驗科直接打過來的,也有臨床科室打過來的,門診也有,全院范圍受影響,該天剛巧科室小L值班,深諳服務器及數據庫運維工作的小L沉著應戰,根據報錯直接定位問題根源是檢驗系統數據庫故障無疑。
小L第一時間請求對檢驗業務系統熟悉的同事協助進行問題處理,并按照既有醫院信息化故障處理流程,直接向主管領導匯報故障情形。經查詢相關底層表,發現lis.patient表里int_cpi(VARCHAR(14))字段的變量值已使用到七個九,并未達到此字段長度上限,初步懷疑是此表主鍵出現問題,即報錯里面顯示的約束值,經過測試及追蹤,排除主鍵原因;18:30左右主管領導到現場,主管領導也是dba出身,首先要求小L在數據庫層面進行測試,在數據庫表中將int_cpi字段最大值加一,發現即刻就有新的操作生成了新的最大值,詢問臨床之后得知正常的新增操作依然無法進行,懷疑是此變量字段的長度受限。這就排除了數據庫背黑鍋的可能性,問題肯定是應用層面上了。幸虧科室有完善的廠家應急通訊錄,小L聯系廠家工程師查看底層代碼關于此字段變量的寫法,確認做了七位長度的限制。
查詢數據庫所有相關表,確認patient和masthead兩張業務表內有此字段,也只關聯了兩個觸發器;進一步查詢得知此字段七位長度只使用了1和9打頭的變量值,其余2至8打頭的七位長度變量值均未使用。
此時有兩種辦法解決,一個是將9打頭變量值全部減去同一數值騰出新增空間,一個是修改底層源代碼,將限制去掉,對比兩種方法,前者迅速但存在一定關聯性風險,后者穩妥但是需要更新版本,解決時間不定;主管領導果斷要求小L斷掉數據庫監聽,重啟數據庫,在機房現場進入數據庫執行語句,將七位長度9打頭int_cpi字段減去相應變量值變更為2打頭,隨后業務恢復正常。
【案例總結】
本文選自《醫院信息系統典型故障案例解析》
主 編 傅昊陽
副主編 馬麗明 賀嘉嘉 高峰