在前面一篇文章《需求分級，緊快趕慢》中，我們將需求分為四個階段：1.進場階段的懷舊性需求;2.培訓階段的易用性需求;3.上線階段的各類爆發性需求;4.運維階段的優化性需求。現在進入的是第四個階段，此階段顯得較為從容一些。

　　我院HIS項目從2020年2月進場開始，第一階段收集了約100個懷舊性需求和35個上線前必做的接口，開始培訓時又增加約200個易用性需求，第三個階段又爆增2000個有效需求，截止到2021年國慶前終于全部干完，將臨床使用部門一直催改需求扭轉到我們主動向臨床征集需求，到了這個階段我心中大石才緩緩落定。期間壓力非常之大，特別是HIS上線后，問題太多，改了這里又錯了那里，剛解決完一個問題，又引發多個問題，每天都升級幾個版本，臨床的意見又反饋到醫院領導那里，領導又批評信息科，“下面很大意見，怎么不到一線去收集解決問題?”天呀!手頭上還壓了一堆需求沒有解決，下到臨床收集回來也沒法快速解決，收集的效果比不收集要好。但領導始終想不明白為什么臨床科室這么大意見，你們信息科為什么不到一線去解決問題。后來我想明白了，這是兩種職業思維做事的方式不同，醫院領導大都是醫生出身，解決問題都是與病人面對面、人與人交流。信息科解決問題是與程序面對面、人機交流。并且解決問題也有一個排序，當機器里面還存有一堆需求時，就不愿意與人再溝通新需求。

　　HIS系統進入穩定運行階段的標志性事件，就是信息科開始在OA上發布需求征集。我院在HIS驗收前，共計發布過7次需求征集，前3次是專項收集，分別是臨床路徑、新住院和新門診系統，后4次是全院范圍內收集。專項收集例如臨床路徑系統，我們是上線5個月后發布的，當時為了三甲評審倉促上線，又為了達到一定入徑率，所以沒有照顧臨床個性化需求，強制要求入徑給臨床工作帶來較大的麻煩，這次專項討論就是對臨床問題做一次全面的梳理，從病種入徑標準設置到路徑模板設置，從醫囑白名單設置到庫存不足提醒，從臨床路徑基本數據項定義到各類統計報表輸入格式等等，做了一次較大的優化升級。

　　專項討論一直存在于項目實施的各個階段。HIS上線前，一般是關于流程規則的討論，上線中一般是接口和功能性錯漏的討論，上線后一般是優化完善的討論。

　　專項討論內容可大可小。一、大的專項如：危急值管理。跨越門診、住院、檢驗檢查全流程全院性的需求，統籌的難度也相當大，像我院沒有獨立的危急值管理軟件，由哪家公司來主導就是一個首要問題，產生危急值最多的是檢驗和檢查結果，但處理危急值的又是臨床醫生，但醫生們都很忙，最先接收危急值消息就是護士了，護士們也很忙的情況下，又必須設置發送后多少分鐘沒有回復，醫技科室必須電話通知接收，住院還好一些，總有值班的人在科室，門診病人出現危急值，而看診的醫生又下班了，如何通知到醫生?打電話不接、自動發短信不回怎么辦?我們又設定在下班期間，自動將信息發送到急診科搶救室的兩臺固定電腦上，下屬門診部則設置一個固定的人和手機號碼，時刻關注短信內容。事實上問題遠不止上述這么多，我們前后開了多次專項會，現在基本上已運作正常。二、中等的專項如：VTE，當時醫務科想做，找到深圳某大型三甲醫院遠程看了一下他們的界面，國內做這套專業軟件的公司不多，價格也幾十萬。醫務、質控、護理和信息科多次專項討論之后，醫院出臺了《南方醫科大學順德醫院 醫院內靜脈血栓栓塞癥防治管理辦法(試行)(2022版)》，包括目標、意義、組織架構、職責、防治管理(含流程圖)、質量控制、應急預案，附：VTE相關評估表，高危科室名錄等，全套方案較為完善，就差信息系統來輔助支撐。我們分析了相關流程，主要涉及到住院HIS系統、住院電子病歷系統、LIS、PACS、手術麻醉系統等，重點在電子病歷系統制作評估表，其他系統以取值為主，實際功能、接口和流程處理并不復雜，我們聯合相關公司很快就做出了院內VTE功能，為醫院節約了不少資金。三、小的專項如：檢查申請單。其中有一個小功能，放射科主任為了提升診斷的準確率且具備一定的科研價值，要求臨床醫生在開具申請單時必須填寫檢查目的，HIS系統原本就有這個字段，但沒有強制必填，由醫療總監組織的專項討論會，她也認為臨床醫生有必要給檢查醫師一個明確的目的，他們在做檢查時會更關注臨床醫生的訴求，原來臨床醫生都簡單寫一個“XX查因”，甚至不寫。當時討論也很激烈，醫生們不愿意多寫字，信息科也認為改為必填在執行時比較困難，最后醫療總監拍板必填，我們也做了會議紀要，然后修改更新程序，接著醫生們立馬就炸了鍋，為維護會議決議的嚴肅性，我們堅決不改，鬧到后面有的醫生開始吵鬧，醫務質控部門也頂不住了，又找放射科主任協商，因為改了必填，有的醫生就亂填，也沒有達到原來的目的，最后都放棄抵抗了，把必填又改回非必填。

　　專項會議因為目標性較強，準備得也相對充分，往往都能達成一定的成果，但并非每次討論都是正確的，也不是一次會議就可以完成的，可能開始以為是二、三個科室的事情，后面越深入參加的科室就越多，因為不了解其他科室的政策規范、業務流程，原以為很容易的事情，最后都變得很不容易，重大專項內容，甚至要上升到醫院領導辦公會決議通過。

　　再說廣征需求，其實是信息科表明一個態度，我們敞開懷抱讓大家來提意見，再者也不要怕大家提意見，據我們多次發布OA通知來看，提意見的科室寥寥無幾，這是人之常態，例如很多征求意見稿，有心回復意見的人真不多。但有人提一定要重視，要對得起人家付出時間和精力來幫助我們完善信息系統，我們的做法就是每一條意見都會專人跟進，一時說不清楚的或有一定價值的需求，我們會約他們過來信息科一起商議，共同制訂解決方案，同時我們也會聯系職能部門的負責人一起參加，因為會涉及到這個需求是普遍性的還是個性化?是否要做還要由職能部門的負責人決定，不能完全聽某個科室或某個人的意見。當達成一致意見后，我們還要求在OA上提交一份應用程序需求修改單，由提需求的科室發起，科室主任或護士長簽名同意，對應的職能科室主任同意，涉及到多個科室的再由信息科主任轉會簽給他們，最后才將需求轉給負責的工程師，由他們提交給對應的公司去修改程序。

　　在需求管理方面，我們做得一直十分規范、嚴謹，基本上沒有重復修改的功能點，所以HIS公司的程序員在醫院現場過得比較舒心，加之順德美食比較多，一些程序員在醫院呆著都不想回公司了。這也算是一個多贏的局面。

　　作者簡介

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