導語
習慣了“有病去醫院”，你可曾想到醫院也會“生病”呢？
醫院生病，指的是陳舊落后的信息化建設給醫院良性運轉帶來的麻煩和風險。在醫院整體運作完全依賴IT信息化的今天，有沒有一位醫生，能為醫院根治這樣的“疾病”呢？
別慌，且聽“神醫”戴爾為您一診究竟！
望 醫院規模與信息化建設發展失調
中國醫療行業近年來發展迅猛，醫院規模急速擴張，一是醫院開始在原有基礎進行擴建，二是新的分院也在加緊建設，醫院運作模式開始出現集團化管理，新的業務系統也隨之增加，新的管理平臺應運而生，醫院整體運作已經完全依賴IT信息化，這給原有就不堪重負的信息科帶來了更大的挑戰，我們不經要問我們應該如何規劃我們的未來IT建設，怎么保障醫院正常良性的運轉。
聞 IT建設與維護氣息紊亂
首先回顧一下我們醫療行業原有的IT建設的思路，以前我們已經習慣于傳統粗放型IT建設，采用購買業內最知名的品牌設備來提高整體業務架構的安全性，同時在此基礎上，不斷通過集群系統、備份系統、災備系統來不斷完善現有結構，但是最終看到一個奇怪的現象，并不是把供應商推薦的方案都建設完后，就太平無事了，系統結構越來越復雜，對事故的結果越來越難控制，管理工作不但沒有減輕反而加重，人力資源也無法跟上信息化高速的發展，現有的生產系統還是會發生莫名其妙的問題，解決問題的復雜度隨之提升，解決問題的時間也變得越發不確定，采購的設備越多，維護管理的工作量隨之越大，原有的IT維護陷入一個惡性循環之中。
問 醫院規模與信息化建設發展失調
醫療行業又是一個對業務中斷非常敏感的一個行業，如何能有效的解決運維管理問題成了所有醫院信息科的痛。那以前的信息化建設歷程里，到底錯在哪里，還是命中注定就是這個結局呢。
我們仔細回顧以前醫療行業歷史的建設階段，第一階段，主導是ISV軟件供應商，有軟件開發商來負責整體應用業務環境的建設，這種模式對于院方會覺得比較簡單，整體業務系統全部交給一家去做，中間不會產生扯皮的事情，但ISV所擅長的業務流程的開發，對整體物理架構只是能用即可，不做太多的要求；
第二階段，在第一階段業務已經可以運行的基礎上，發生多多少少的業務意外中斷，數據丟失無法再生的問題，院方開始考慮引進專業的SI系統集成商來負責硬件環境的建設，增加了主機集群和數據備份環節，甚至災備系統，軟件供應商只專注業務流程的控制，各自發揮自身的特長，此種模式對信息化良性建設和管理提升了巨大的一步，此次模式一直被延續到今天；
但這種模式還是無法真正意義上滿足院方對醫療信息化高強度建設需要，雖然對第一階段信息化安全做了提升，但是還是無法確定現有信息化建設過程中業務中斷和數據丟失是否能精確有效解決，能否控制在院方的可承受的范圍內，醫院的事故解決的時間是和IT維護人員的責任關聯在一起；為此DELL提出了第三階段，既醫療行業IT信息化建設3.0版本，它所包含的內容豐富，是以醫院信息科運維管理為出發點，以業務應用為基礎，重新考慮如何能真正有效解決醫療行業第二階段過程中所遺留的歷史問題。
切 準確把脈六大難點
我們回顧醫療信息化建設的第二階段存在哪些實質性的問題。
1.是傳統意義上的主機集群模式已經被醫療行業廣泛使用，其分為雙機單柜和雙機雙柜兩種模式，安全級別逐漸遞增，它給整體業務應用提高了可靠性，但還不足以真正達到院方對業務要求，其主要問題是出現在集群軟件在業務發生問題切換過程中，存在很多不確定性，不是每次切換都能順利完成，這給院方帶來困惑，不用集群軟件吧，出了問題沒法切換，買了集群軟件吧，真出了問題還不一定能切換，結果不明確。
那是否有一種模式可以明確在出了問題后，一定能接管應用呢，而且時間是控制在院方的可承受的范圍內呢；
2.是業務數據丟失，這也是醫院非常痛苦的事，但又沒有好的方式來實現，傳統的數據備份一般只備份一些數據量不大的業務應用，而且傳統的數據備份強度較弱，一般一天只備一次，出了問題，最好的結果是回朔到昨天的那個備份記錄點，也許糟糕一點的要回退到周末的全備份點上，而且很多三級甲等醫院的PACS非結構化數據量巨大，目前一般都幾十TB的數據，五年增長到100TB在今天看來已經不是什么難事了。但從我們回訪的用戶看到，好一點的結果是一個月備份一次，中等的是三個月備份一次，糟糕一點的是不備份。從數據保護做的好一點的用戶了解到，其實他們對自己的那個一個月備份一次結果也不寄希望，實在是無奈之舉，一是不確認備份的幾十TB的數據是否可用，無法驗證，二是真的把這幾十TB恢復回來需要多長時間啊，業務等的起嗎，基本上不具備實用性，停留在形式上；
3.是雙機雙柜的建設已經是IT信息化建設頂級模式了，但還是碰到了問題，一是此種模式只防物理故障，不防邏輯故障，二是如果主機和存儲之間的鏈路不穩定，連續抖動的話，會把整個業務拖死，變成畫虎不成反類犬，適得其反；
4.是災備建設也變得異常簡單，只是將生產端的數據傳遞一份到災備端即完成了所謂的災備建設，此種模式也變得異常危險，一是如果生產端物理全部癱瘓，災備端的數據是否有效值得商榷，二是生產端數據出現邏輯問題，也會被隨之放大到災備端，導致災備端數據失效，兩頭不可用；
5.是按照傳統處理問題方法，先找原因，后處理結果的模式，往往變的異常艱難，時間控制上很不確定，難在對問題的分析判斷上，往往根據每位處理問題工程師經驗而定的，不確定因素太多，那是否有更好方式，不走這條路，能有效控制處理問題的時間呢，答案是有的；
6.是當用戶把以上全部建設完，整套系統的復雜度已經超出了用戶可管理的范圍，絕大部分需要借助外部力量來實現，這對管理上是一個巨大的風險，要借助外部力量，這對用戶來說也是不可控的因素，如果借助的得體，問題可能會有效解決，如果所依賴的外部力量較弱，可能會造成嚴重的后果，那是否能尋找到一條簡單維護，而不借助外力的方式呢，自身可以獨立控制風險呢。
如上，“戴”神醫已經通過望、聞、問、切四種手段，準確地診斷出了醫療行業信息化建設的癥結所在。
京公網安備 11010502049343號