HIS上線的幕后英雄是一幫日夜奮斗在信息科辦公室(或公司研發中心)的“程序猿”們，所有來自一線的需求和壓力，都是由他們在鍵盤上用一行行代碼來解決的。雖然聽不到醫生們的牢騷和病人的抱怨，但實施“攻城獅”們著急的表述，不斷催促“搞好了沒有?”“還不行啦?”“下面頂不住啦!” 他們真的連喝口水的時間都沒有。

　　20年前上HIS系統，再大的三甲醫院，可能就只有一個或幾個實施工程師在現場，程序開發人員只在公司進行遠程支持。現在，稍有規模的醫院換HIS系統，程序員都要派駐醫院現場，至少3人以上，分別負責門診、住院、藥劑系統，還要加上1名測試工程師。我們醫院日常駐場的程序員都有5人，實施工程師20多人。上線時第一周，公司安排人員達到50人，也算是較大兵團作戰。

　　實施項目經理，負責收集、匯總、分析一線實施人員提交的需求，主要來源有：微信群、電話、現場收集等。上線第一周，一線出現的問題，原則上都由區域網格內的工程師負責現場勘察和反饋，共性問題的解決方法，我們都會通過微信群及時公告處理的方法，暫時無法通過程序解決的，也告知注意的要點或臨時解決的辦法。

　　亦有公司比較教條，在上線初期，要求嚴格登記需求，上線第一周每天可能產生幾百條需求，問題都解決不過來，哪有時間按規范的格式一條條登記?我們采用最簡單的EXCEL表格，按不同的子系統進行登記，需求就是一句話，最多配上出錯的截圖，后面有幾項內容明確后再補填寫，如：解決方案，完成人，完成時限等。但再簡單每條需求都應有編號，相同的需求會在后面備注排在前面的編號，合并的需求，會備注合并后的編號。

　　剛開始需求會比較混亂，沒有關系。有解決了沒有登記的，有登記漏的，我們也常聽到醫生們抱怨，需求提了好久都沒有解決，一查，需求登記表上沒有。有可能是醫生與現場工程師溝通后提出來的，也可能是在會議上、吃飯期間、路上碰到，隨口一提的。真想解決問題的醫生，會再次提出來，只想吐槽的醫生，就會到處抱怨，甚至會跟領導投訴，說提了很多問題信息科都不解決，現在不提了。領導一聽又很著急，質問信息科為什么不解決臨床的需求，我說我們每天都解決幾十個，現在已經解決了幾百個需求呀，哪個醫生提的?請領導讓他直接來信息科，我來親自解決，真實情況沒有一個醫生過來找過，這些在領導面前吐槽的醫生可能只是為了表達自己的不滿或表現個人在信息化方面的“能力”，這是阻礙信息化項目上線的小撮人，他們不是真正想解決問題的。當然，我們的信息系統一定會存在他說的某個問題，但這些問題都可以通過協商的方式解決，IT技術也不是萬能的，人想到的電腦不一定都能做到，要綜合考慮時間成本、開發成本、實現的風險、真正的價值等等。很多時候需要換位思考，醫療也不是萬能的，大多數人不是死于意外就是死在醫院，是藥都有三分毒;手術都有風險，還讓病人簽一堆的知情同意書。我們HIS上線這個“超級大手術”有讓臨床簽過知情同意書嗎?

　　以上內容僅是吐槽，并不能讓臨床來理解我們做信息化人的苦衷!

　　版本升級是有技巧的。醫院一般上午的病人比較多且集中，不適宜更新版本，但一些出錯性的、重要的、影響操作流程的，還是會更新后讓對應的科室重啟系統進行升級，無需升級的如：存儲過程、報表等，則隨時進行修正。下午病人較少，我們一般在3:30或4:00進行版本更新，因為有些需求還需要一定數量的病人進行驗證，這時升級的版本可能是多個相關聯的子系統同步修改的內容。門診系統，晚上只有急診科和發熱門診上班，這是修改需求升級版本的最佳時間，只有這頓晚飯，程序員們可以稍慢一點吃，還可以邊吃邊討論一些技術實現的細節。一些需要增加字段改變數據結構的需求，最好在晚上進行，白天還累積了一大堆的需求，這時需要逐條梳理，確定修改方案、完成時限、任務分工后，又開始在鍵盤上忙碌了。出錯性的、重要的、嚴重影響第二天操作的需求，我們在當晚一定要完成，以保證第二天醫生們的體驗感好一些，他們的問題我們已收到并快速解決了。復雜的、重要但不緊急的、改動太大且會引發更多問題的、還未找到更好解決方案的、臨床各科室尚有爭議的、易操作性但修改較為麻煩的、極個性化的需求等，我們先記錄下來，后面再慢慢來收拾。

　　傳統HIS，無論是C/S還是B/S架構，最好有一個專項升級工具，能夠方便退出HIS或重啟電腦，再登錄時就可以自動完成版本更新，也可以自主回退到之前某個版本。上線期間，為了解決某個問題，而引發出更大的問題，這在外行看來不可思議，但在應用軟件行業可謂是司空見慣的事情，回退版本是常規穩妥的做法。現在HIS軟件進入新一代技術開發，采用微服務架構的產品，可以進行灰度發布，讓一部人先用起來，如果出現問題則立即撤回，這是技術發展的先進性，但本質上仍不可避免每個版本發布均沒有錯誤。跟測試不全面有關，跟測試環境與正式環境存在差異有關，跟多個子系統子模塊緊密關聯有關，其實HIS系統就是一套精密復雜的不能間斷運行的系統，牽一發則動全身。而在臨床要求又十分緊迫的情況下，往往只能做到功能性測試，再多就是對波及的子系統做流程測試，達到需求的目的，就向外發布版本。對于隱藏的規則、反向操作、極值測試、壓力測試等，往往無法兼顧或考慮不到。升級后真正使用時，才發現還有漏洞，有些漏洞可以再打一個補丁版本進行升級解決，有些影響較為嚴重的，則只能回退版本，保證當前的醫療流程還可以繼續。

　　需求版本，一日三變。是指上線初期，版本升級比較頻繁，一切只是為了更快地解決問題。我們HIS的穩定期只用了一周時間，每天都有多次版本升級;后面每天會升級一次，一般放在下午或晚上;三個月后，一周升級兩次，一般不會在周一和周五升級，周一病人太多，周五大家都想好好休息一下;再后來每月根據需要升級若干次，且不會在國家法定節假日前一天做版本升級;春節前一周和元宵節前禁止版本升級。記住一點：在保證基本醫療流程運作正常的情況下，升級操作盡量在合適的條件下進行。

　　作者簡介

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