HIS系統上線穩定后，版本升級需要納入計劃。上線階段的升級就像急診手術，沒有太多的顧慮和試錯，直擊病灶解決問題，但后遺性較多;上線穩定后不能再這樣蠻干，臨床使用人員的神經已經被折磨得很脆弱了。

　　當前HIS系統的版本控制大體分為兩類：一類是全公司統一一套版本，醫院個性化的需求通過參數和專用部件來實現，特點是公司的維護成本降至很低，但各醫院的升級難度很大;一類是公司有一個公共版本，各醫院在此版本上發展為獨立版本，特點是不受其他醫院需求影響，升級相對較易。在微服務架構下的HIS產品，有些融合這兩種優勢，可以復用部分組件，又可以滿足醫院個性化需求，但也可能發生結構性變化時，重新適配的難度將超級困難。世上沒有一種技術可以解決所有的問題，所以人的管理才顯得更為重要。

　　無論是統一版本，還是先進架構，對單體醫院來講，自家的HIS系統都是獨一無二的。每一個細小功能的升級，背后可能牽扯多個不同廠家的子系統，HIS作為醫院最核心的主線數據流，有牽一發而動全身的能量，此時要慎之又慎。

　　嚴控版本要首先從嚴控需求開始，需求是版本升級的源頭，沒有新需求自然就不會有版本升級。上線穩定后的需求，主要集中在新政策需求、新上其他子系統接口、原有功能重整優化、使用人員易用性需求等，除政策性需求有不可抗力的時間要求之外，其他都可以列入計劃性排期，當然政策性需求也需要倒排工期，優先級別最高。此時使用部門的需求不會太多，要嚴格要求他們通過OA系統來提交需求單。原因很重要：1.防止需求隨意化。此時要求需求提出者對所提需求負責，需求要達到的目的要明確，要有具體實現的內容或要求達到的效果，難以描述的最好配圖表說明，流程必須經過科室主任或護士長、職能部門領導審批后，再流轉到信息科;2.需求可追溯。上線期間需求滿天飛，一切以解決當前的問題為主，所以很多需求記錄不及時、不準確，導致漏掉一些需求沒有響應，引起醫護人員不滿，說“我們提了一堆需求，信息科都沒有去做”。現在正是補救的時機，我們必須承認之前的遺漏，但也必須強制要求新需求必須通過OA申請，以便于追溯查證;3.控制需求變更。變更需求在項目管理中也是常見現象，但必須加以控制，不然費力費時費錢。人嘴一說，往往不用負責任，叫“口說無憑”，填寫OA系統的需求申請單就是正式的工作方法，所以寫需求的人，會自覺考慮所寫的內容是否合理、表述是否準確，況且還要上級領導審批。那么，有哪些需求變更是合理的呢?例如：新政策變化、醫院新的管理要求、有新的合理需求加入、原來考慮尚有遺漏等。對于不穩定的需求內容，即業務流程都還沒有理順的需求，最好先放一放，讓業務科室人工先做，形成穩定運行模式后，再考慮用信息化實現。例如：我院新成立創傷救治中心，醫務科一開始就希望我們用信息化手段來管理，這里面存在大量不確定性，至今業務流程都還在調整，我們先當做一般門診急診流程處理，保證能接收到病人、收費、發藥就可以了;再例如很多醫院在推行“全院一張床”管理，這也不是信息科和信息化能夠解決的問題，不然就真成為背鍋俠了，我們做了一張全院床位使用情況明細查詢表，完事。

　　管理好需求，是信息主任不可推卸的責任。

　　管理好單一功能應用性需求還不是本事，如何把所有應用性需求歸類整合成軟件修改性需求才見真功夫。這已經不是一個人的事，而是涉及此次版本需求修改波及范圍內的各子系統負責的工程師和廠家，影響范圍小的，2、3個人碰個頭可以決議，影響大的可能要召開各子系統多部門的專題會議，來討論程序修改方案，力求做到既照顧各方需求實現，又能讓軟件系統設計最優。

　　嚴控版本，還在于對升級內容的選擇。一次升級的內容不要太多太雜，上線后驗收前的升級還適用小步快跑，同一類型或模塊的修改最好放在一起升級，便于在升級出現問題后可以方便回退，而不影響其他子系統運行。如果需求明確、程序員水平過硬，測試工程師嚴謹，一次也可以升級多個不同類型或模塊的內容。對于某些需求修改動作較大的，影響其他子系統運行的，最好單獨一個版本升級，也是便于及時回退。著急的需求可以單獨拎出來與已經測試好的需求一起升級。不穩定的需求或嘗試先改一個版本的需求，選在空閑時升級。

　　嚴控版本，還在于對升級時機的選擇。之前章節我們也講過升級的時機選擇，在此說一些不一樣的內容。政策性需求對升級有嚴格的時點要求，不能過早，例如：1月1日凌晨0點開始，取消藥品加成，就只能在這一刻升級;為配合醫院新的管理制度和流程執行，需要提前幾天升級，觀察效果，預留整改的時間;上線后系統運行較穩定，也可以固定某個時間點進行升級，如每周三下午4點。不建議常態下晚上升級，一是出現問題后，資源難于協調;二是第二天早晨病人較多，有隱藏的問題此時才曝露，容易造成醫療秩序混亂。例如：我們有幾次自助機的程序員晚上加班干活，自己測試完成后，就更新了版本，第二天自助機開機后自動升級，然后就用不了。分析原因就是工程師沒有做現場測試，忽略掉一些環節，當聯系到程序員時，他還在睡覺，然后門診病人都圍在自助機前面，醫院需要組織工作人員疏導病人到人工窗口取號繳費，給正常醫療秩序造成一定混亂。現在我們都禁止各公司的軟件晚上升級。

　　C/S架構的產品，程序運行在本地硬盤。服務器端升級以后，客戶端一般在重新登錄時才會復制服務器端的升級文件包到本地，有些客戶端很長時間不關機也不退出系統，造成一直使用舊版本，所以當有重大升級內容時，還要設置強制升級的策略。

　　B/S架構的產品，程序運行在服務器端，客戶端通過瀏覽器調用，比較容易部署和更新版本。客戶端只要重新訪問服務器端就是最新的版本。回退版本也更容易，這是B/S架構自帶的優勢，但在運行速度方面稍遜于C/S架構。

　　版本回退機制。無論測試多么認真，都會有不可預知的錯誤出現，特別是HIS系統與N多個不同公司的子系統相關聯，測試庫不可能完整復制當前的生產環境。當不能通過再發布一個新版本及時解決時，為了保持醫療秩序不長時間混亂(一般30分鐘以內)，就必須要回退版本，所以要記錄每次升級包的內容，能夠重新導回。對于新增表、字段或字段擴容，則無需回退腳本，因為對舊程序影響不大，這里也要求不能隨意更改表結構的屬性。

　　總之，此階段的版本升級，重在求穩少犯錯誤，寧可花多一些時間，也不要引起醫療秩序混亂和臨床使用人員的抱怨，最好在他們無感之中逐步感受到HIS系統越來越好用。

　　作者簡介

　　郭揚帆，CHIMA委員，軟件工程碩士，高級工程師，南方醫科大學順德醫院信息科主任。廣東省首席信息官協會醫療分會副會長，廣東省衛生經濟學會信息分會專家，廣東省醫療信息安全專業委員會副主委，順德醫學會醫學信息學分會主委等。主編著作二部《醫療衛生信息化項目管理實務》、《醫院網絡安全建設指引》，擔任多部著作編委。1997年從事醫院信息化工作，先后經歷過多次甲方、乙方角色換位，積累了豐富的項目管理經驗。