基于互聯網+的非在職人員管理平臺的建設與應用

馬群圣，袁駿毅，金永春，岑星星

上海市胸科醫院 a.信息中心；b.后勤保障部，上海 200030

引言

醫院的正常運行和健康發展依賴于醫院職工以及各部門非在職人員的共同協作，職能部門、工勤人員、外包人員等作為緊密聯系臨床一線科室不可或缺的力量，在醫院的日常運行中起到關鍵作用[1]。隨著醫院業務量的不斷增加，各科室對于外包、駐場人員等的需求量也不斷上漲。但是，醫院目前對于非在職人員的管理通常由各職能部門單獨進行相關操作，如進修生、研究生歸屬科教部管理，信息外包歸屬信息中心管理等。在管理過程中，由于統一集中管理平臺的缺失，可能會出現分配臨時工號重復、統計困難、管理難度高等問題。因此，對于各類人員的閉環統一管理顯得尤為重要。然而，因為各部門人員管理信息化程度的不同、各系統間互聯互通機制的缺失，使得人員管理過程中的信息孤島問題較嚴重。這就迫切需要醫院管理者推動職能管理部門對于非在職人員管理與服務理念的轉變和升級，努力使用新興技術提高管理水平、提升服務效率和質量[2]。

近年來，受益于互聯網技術快速發展、醫療機構對信息化投入逐年增長等因素，醫療機構的信息化水平得到快速提升，信息系統的建設趨于一體化、移動化以及智慧化[3]。在醫院人員信息系統建設方面，孫秀秀[4]完成了互聯網+醫院人事管理信息化系統構建分析，旨在通過信息化系統實現院內人員信息集中管理、數據高效利用以及信息數據安全保障，但并未覆蓋到院內職工以外人員的信息化管理；在信息系統架構方面，劉景娜等[5]完成了基于SSH框架的醫院人事管理系統開發及應用，但系統架構未考慮到移動端的需求。

因此，本研究擬針對上述現存的問題使用Vue和WebAPI技術，利用信息化手段搭建非在職人員管理平臺，從移動端、PC端等多種形態終端實現人員管理效率的最大化，以期為醫院人員的精細化管理提供有力的保障。

1 需求分析

非在職人員管理平臺不僅涵蓋后勤外包人員還涉及其他科室人員，人員來源復雜，牽扯部門眾多，本研究在經過與后勤保障部、科教部、護理部及臨床研究中心等各職能部門多次的會議討論后，確定平臺建設具體需求。

非在職人員管理平臺的建設分為2大部分：非在職人員移動端申請和非在職人員后臺管理系統。其中，移動端申請部分，需要申請者關注醫院微信公眾號，通過非在職人員入口進行個人信息填寫，查看申請結果及完成個人識別碼展示。后臺管理部分，各個職能部門可對所屬的非在職人員信息進行修改、審核等操作，根據所屬部門人員類型確定是否開啟科室初審、是否一鍵審核等功能。當開啟科室初審后，該類型非在職人員需要進行3次審核，包括科室初審、職能初審及職能終審；不開啟科室初審時，科室初審默認審核通過。開啟一鍵審核功能時，職能初審及職能終審人員一致時，進行職能初審時將同時進行職能終審。職能部門審核權限列表如表1所示。

表1 職能部門審核權限列表

數據層面，作為基礎數據建設的一部分，平臺提供統一公共接口服務，與第三方系統進行數據共享。通過對人員類型的分析，非在職人員平臺初始數據來源于各個職能部門目前已經維護的人員信息，通過Excel進行批量導入。數據來源方式如表2所示。

表2 數據來源方式

2 系統設計

2.1 系統架構

為適應技術和業務發展需求，前后端分離技術已成為移動互聯網領域不可或缺的技術[6]。本研究系統采用了基于Vue+WebAPI+企業服務總線（Enterprise Service Bus，ESB）的前后端分離技術，Vue負責前端展示，WebAPI負責后端的搭建與業務邏輯，ESB負責WebAPI的封裝、接口的實時監控。開發工具采用Microsoft Visual Studio 15.0、.Net framework 4.5，數據庫存儲采用的是Microsoft SQL Server 2016。基于網絡安全及數據安全考慮，Vue前端系統部署在醫院前置機，WebAPI部署及數據存儲均在醫院的內部網絡。

當非在職人員通過掌上醫院微信公眾號填寫人員基本信息并提交后，借助互聯網代理服務器向醫院外網請求http服務，醫院外網的互聯網信息服務（Internet Information Services，IIS）接收到http請求后，利用從醫院內網映射到醫院外網的ESB服務，確保醫院內外網之間通過網閘物理隔離，將審核消息推送到職能部門審核人員手機上。審核人員通過手機端或PC端完成申請人員信息的審核。審核成功后，申請者可以在手機端以HTML5的頁面查看審批過程及個人識別碼。系統架構圖如圖1所示。

圖1 系統架構圖

2.2 核心技術

系統應用前后端分離模式，在前后端分離的框架選型中，系統前端技術采用Vue框架，后端采用WebAPI，前端與后端的耦合度較低。Vue是一個小型、高性能、組件化的JavaScriptMVVM庫，是一套創建用戶界面的漸進式框架，其通過數據分析驅動及組件化的思維創立，本研究采納自底向上增量開發的設計。Vue是借助API實現的數據綁定來開發，和Model后臺展開數據分析交互，具有承前啟后的指導作用。后端采用WebAPI接口，返回前端所需的數據，不再渲染HTML頁面及控制前端，僅進行邏輯處理對外提供數據。在前后端分離的應用模式中，可以加快整體的響應速度，快速定位問題，同時水平擴展前后端服務器，減少后端服務器的并發/負載壓力[7]。前后端分離架構如圖2所示。

圖2 前后端分離的系統架構

本系統采用前后端分離架構可實現：① 分布式部署，提升系統的業務處理能力，減少后端資源壓力；② 復用組件，提升系統的可用性、擴展能力和可維護性；③ 生態完備，方便開發團隊的分工合作，提高開發效率[8]。

3 系統實現

3.1 業務申請流程

業務申請流程如圖3所示，非在職人員通過手機微信關注醫院公眾號，點擊“非在職人員登記”入口，校驗當前非在職人員是否已經填寫申請表單。若未填寫，則填寫姓名、性別、身份證號、手機號碼、學歷、所屬部門、公司名稱等個人基本信息，并上傳個人照片。部分科室對個人基本信息有特殊要求的，則需另外填寫補充信息，如歸屬科教部管理的研究生，則另外填寫職稱、班號、進修/實習科室、導師/帶教老師等補充信息。人員信息填寫完成后，可以在查看審核結果模塊中查看審核進度。審核通過后，在個人信息識別碼中查看個人唯一識別碼。若基本信息已填寫，則直接查看審核結果及個人信息識別碼。前端界面基于Vue框架實現，引入ElementUI控件，界面簡潔，有效提升用戶操作體驗；后端基于ESB封裝的WebAPI進行數據交互[9]。

圖3 業務申請流程

3.2 審核流程

非在職人員提交申請后，審核人員移動端會收到非在職人員的申請信息，并通過移動端或PC端進行人員信息的審核。若人員申請信息存在問題，則填寫審核不通過原因，審核結果通過則以短信和醫院公眾號消息推送的方式告知申請人員。審核人員審核流程如圖4所示。

圖4 審核人員審批流程圖

3.3 工號編碼規則

為便于規范管理各類人員，非在職人員的分類及工號編碼規則將由人力資源部統一制定，再由各相關職能部門在規定的編碼號段范圍內直接編碼。同時為確保信息系統中醫院人員相關信息的安全性和唯一性，工號編碼將由系統自動生成。系統將自動給予新進員工工號并往后順延，不再重復使用已用過的工號。因各部門編碼號段固定，為避免工號浪費，系統將會自動釋放被無效占用的工號，并將它們重新給予新進人員。非在職人員編碼規則如表3所示。

表3 非在職人員編碼規則

3.4 字典規范

非在職人員管理平臺作為醫院人員資源庫，為信息交換及最大限度實現資源共享，采用主數據管理系統中標準化的字典，進行統一化、規范化的處理[10]，如平臺中涉及民族、性別、政治面貌等，性別代碼參照GB/T2261.1-2003《個人基本信息分類與代碼 第1部分：人的性別代碼》[11]，未知的性別代碼為0、男性為1、女性為2、未說明的性別為9。同時，為第三方的應用提供標準化的接口服務，如院內餐卡系統、門禁卡系統等。

4 功能模塊

4.1 移動端申請提交及查看

申請者通過移動終端填寫個人基本信息、部門信息及補充信息等，表單采用結構化模板，院內工號由系統根據規則自動生成，保證數據完整性及可用性。申請者提交之后，可以查看審核進度。若審核未通過，需重新提交申請（工號需重新分配，之前占用的工號將會被釋放）；若審核通過則申請人可至個人識別碼頁面查詢個人識別碼信息，個人識別碼為院內人員身份標識的唯一碼，第三方應用可以通過個人識別碼進行相應的數據交互。非在職人員登記入口及個人識別碼的相應系統界面如圖5所示。

圖5 非在職人員登記入口（a）及個人識別碼（b）

4.2 部門審核

為方便部門對于非在職人員的管理，系統采用二級部門、三級審核模式。審核模式根據部門實際情況靈活審核，分為科室初審、職能初審和職能終審。如某部門不需要科室初審則可為其部門設置為默認科室初審通過狀態。審核不通過時，則需填寫不通過原因，便于非在職人員查看原因，及時進行修改。非在職人員離職后，再次來院，若人員類型變動，則需管理員注銷離職信息，申請者再次提交；若人員類型不改變，則可直接提交信息，通過審核后數據生效，非在職人員部門審核界面如圖6所示。

圖6 非在職人員部門審核

4.3 人員信息公共接口服務

為實現醫院人員信息統一對外提供服務，將非在職人員信息與院內職工信息進行數據整合，建立人員資源庫，進行人員網格化管理。對于第三方應用，統一提供標準的ESB接口服務，保證在不同系統或醫療服務提供者之間交換信息時的一致性、準確性和完整性，同時消除醫療信息在不同場合的差異[12]。

5 成效評價

5.1 研究對象

本研究選取2020年9月至2021年9月的非在職人員為對照組，采用人工方式錄入人員信息，通過手工記錄申請（n=1287）；選取2021年10月至2022年4月的非在職人員為觀察組，通過非在職人員移動端進行信息錄入，通過移動端申請（n=1184）。2組人員的基本資料（年齡、性別占比）無明顯統計學差異（P＞0.05），具有可比性。

5.2 評價指標

（1）數據完整性。將對照組和觀察組關鍵信息、非關鍵信息是否完整填寫進行對比，分析所建系統對于醫院管理水平的影響。其中的關鍵信息包括姓名、身份證號、性別、人員類型、手機號碼等；非關鍵信息包括學歷水平、居住地址、來院科室、在院狀態等。

（2）申請及審批用時。通過對照組和觀察組人員申請用時、職能部門人工審批及移動端或者PC端審批用時的對比，分析所建系統對于工作效率的影響。

（3）餐卡辦理用時。通過對照組和觀察組人員餐卡申請用時比較，進一步分析所建系統對于工作效率的影響。

5.3 統計學分析

應用SPSS 26.0軟件進行統計學分析，計數資料以n（%）表示，采用χ2檢驗，實驗的顯著性水平設為0.01，以P＜0.01為差異具有統計學意義；計量資料以±s表示，采用MannWhitneyU檢驗，0.2＜Cohen’s d≤0.5為小效應、0.5＜Cohen’s d≤0.8為中等效應、Cohen’s d＞0.8為大效應。實驗的顯著性水平設為0.01，以P＜0.01為差異具有統計學意義。

6 應用效果

6.1 對管理水平的影響

建設非在職人員管理平臺之前，各個職能部門通過手工或者Excel進行錄入和記錄非在職人員，往往存在記錄錯誤、記錄不完整的問題，數據無法達到標準化，數據統計耗費大量的人力與時間，并且易形成信息孤島，數據無法共享[13]。平臺建設之后，非在職人員申請模板標準統一、數據結構一致，數據完整性得到明顯提高。審核人員實時掌握非在職人員在院情況，動態制定非在職人員管理措施，實現了非在職人員的閉環管理，改進了管理水平。非在職人員手工錄入與系統錄入的數據完整性分析結果如表4所示，2種錄入方式中關鍵信息與非關鍵信息填寫是否完整存在顯著差異（P＜0.001）。

表4 非在職人員錄入數據完整性對比

6.2 對工作效率的影響

通過非在職人員管理平臺，職能部門可以實時獲知非在職人員基本信息，并有效管理人員在院情況，同時非在職人員平臺與院內餐卡系統的對接，實現了數據共享[14]，優化了辦理餐卡流程，有效節省雙方時間，提高了工作效率。非在職人員手工錄入與系統錄入的申請用時與職能部門審批用時分析結果如表5所示，2種錄入方式的申請用時與審批用時的結果存在顯著差異（Cohen’sd=14.032、14.558，均P＜0.001）。

表5 非在職人員申請用時及職能部門審批用時對比

手工統計的餐卡辦理用時為（11.000±1.413）min，系統填寫的餐卡辦理用時為（2.000±0.815）min，2種方式的用時差異存在顯著差異（Cohen’sd=7.785，U=152075，P＜0.001）。

7 討論與結論

人力資源是醫療行業中的核心競爭力[15]。本研究通過Vue+WebAPI等互聯網技術實現了非在職人員從申請、審批到數據應用的全流程信息化閉環管理，優化了非在職人員管理的整體流程，縮短了審批時間，有效提升了工作效率和數據質量，并為后續的第三方應用提供了統一的標準服務及數據基礎。在現代醫院人力資源管理中，醫療機構更多側重于院內職工的信息化研究，靖超等[16]、劉亞娟等[17]通過傳統的信息化技術對院內人力資源進行建設，利用了信息化的手段從傳統的人員管理轉變到PC端信息化管理，一定程度提高了信息化水平，但是在移動端等多形態中未進行研究。張帆等[18]在醫院員工360信息管理系統建設中，通過互聯網+建立基于人員基本信息的醫療、科教、醫德醫風等一體化的職工自我360管理，提供院內人員管理新思路，但在進修生、研究生等人員覆蓋面上并未涉及。通過與以往的研究進行比較，非在職人員系統采用了目前主流的互聯網+技術，為后續功能擴展預留了接口；同時在人員覆蓋面上，系統不僅包含各個職能部門的非在職人員，并且通過與人力資源系統的數據對接，形成了完整的醫院人力資源池，為后續的數據共享提供了數據基礎[19]。但是，在非在職人員管理平臺建設中，也存在不足，如人員覆蓋面上尚未與退休人員數據對接[20]，且關于醫療場景相關應用、相關技術的論述較少。

后續研究中，以非在職人員為基礎，繼續增加覆蓋人員范圍，為醫院不同類別人員網格化管理提供數據基礎，形成覆蓋醫院各類人員的人力資源池[21]。在未來的應用場景中，不斷拓展應用范圍，如與門禁卡、進出樓宇閘機、人臉識別等進行數據共享，進一步為醫院人員網格化的管理相關研究及建設提供參考。