南陽市宛城區醫療健康服務集團信息化平臺采購項目

項目實施方案

目錄

1. 綜述 4

2. 整體建設內容 4

2.1. 軟件產品采購清單 4

2.2. 軟件開發、實施服務采購清單 6

2.3. 建設范圍 7

3. 實施團隊組織機構及人員配備 8

3.1. 實施團隊組織機構 8

3.2. 各級組織單元職責 8

3.3. 實施過程職責劃分 9

3.4. 擬投入本項目實施團隊主要人員構成表 11

3.5. 指導原則 12

4. 實施周期（進度）計劃 13

4.1. 第一階段：南陽市第二人民醫院總院建設 13

4.2. 第二階段：一級醫療機構接入建設，其他子系統接入，電子病歷五級報名、互聯互通四甲報名 15

4.3. 第三階段：院內?？粕罨?、二級機構接入 17

4.4. 第四階段：電子病歷6（省級文審）互聯互通5乙（省級文審）智慧服務三級。 17

4.5. 實施范圍：電子病歷6（省級文審）互聯互通5乙（省級文審）智慧服務三級 17

5. 實施周期（進度）保障措施 18

5.1. 實施周期（進度）管理的核心理念 18

5.2. 實施周期（進度）管理方法 18

5.3. 組織保障 19

5.4. 進度控制要素 19

5.5. 進度控制措施 20

5.6. 關鍵路徑實施進度管理 22

6. 項目實施流程（工程程序）與保證措施 24

6.1. 全生命周期管理實施流程 25

7. 項目管理與保證措施 32

7.1. 項目管理基本要素 32

7.2. 項目實施響應 33

7.3. 項目溝通與匯報管理 34

8. 項目質量保證體系及措施 35

8.1. 建設質量目標 36

8.2. 質量保障要素 36

8.3. 軟件的質量標準、測試手段 37

9. 項目風險分析及控制 46

9.1. 風險因素 46

9.2. 風險管理內容 47

9.3. 風險管理流程 48

9.4. 風險字典庫 48

9.5. 項目變更管理原則 50

10. 項目實施重點、難點分析 52

10.1. 系統集成（重點、難點一）解決方案 53

10.2. 電子病歷6級評審（重點、難點二）解決方案 77

10.4. 互聯互通5級評審（重點、難點三）解決方案 83

11. 總院實施落地方案 106

11.1. 關鍵工作項 106

11.2. 需求調研 106

11.3. 環境搭建 106

11.4. 數據初始化 107

11.5. 系統集成 107

11.6. 數據割接方案 107

11.7. 系統試運行 109

11.8. 系統切換方案 110

11.9. 系統切換步驟 111

11.10. 系統切換應急預案 112

1.綜述

武漢盛博匯信息技術有限公司在南陽市宛城區醫療健康服務集團信息化平臺采購項目中，已對南陽市宛城區醫療健康服務集團信息化平臺有充分的理解，對于本期項目建設內容，對于本期項目與各子系統的內在關系等理解深刻，并在技術文件中給出了詳細的運行流程及方案?；诖吮尘俺鼍叩捻椖繉嵤┓桨竷热萑婵茖W、針對性強、設計合理確實可行。具體內容如下：

1.“總體實施框架及目標”、“項目實施范圍”、“實施團隊組織機構及人員配備”中詳細的闡述了本項目的管理框架及人員分工。

2.“實施周期（進度）計劃”、“實施周期（進度）保障措施”中合理安排了本次項目的工期及相應的保證措施。

3.“項目實施流程（工程程序）與保證措施”中全面的講述了本次項目的管理程序、制度及相應的保證措施。

4.“項目管理與保證措施”中全面闡述本項目具體的實施方案及措施、文檔資料移交內容。

5.“項目風險分析及控制”、“項目實施重點、難點分析”、“項目重點、難點具體解決方案”中例舉了本次項目的具體風險源、風險處理的措施；方案中針對項目重點、難點（電子病歷6級評審）提出了具體、可行的解決方案。

6.“項目質量保證體系及措施”中完善的闡述了本項目的質量控制、保證體體系及相應的保證措施。

2.整體建設內容

2.1.軟件產品采購清單

序號 系統名稱 建設方式 三級醫院 二級醫院 一級醫院

1 門診醫生工作站 新建 √ √ √

2 住院醫生工作站 新建 √ √ √

3 門診電子病歷 新建 √ √ √

4 住院電子病歷 新建 √ √ √

5 ?？撇v 新建 √ 部分新建

6 移動醫生站 新建 √ √

7 臨床路徑（門診、住院） 新建 √ √

8 門診護士工作站 新建 √ √ √

9 住院護士工作站 新建 √ √ √

10 護理交互大屏 新建 √ √

11 臨床檢驗信息系統 新建 √ √ √

12 全院輸血流程管理系統 新建 √ √

13 抗菌藥物管理系統 新建 √ √ √

14 臨床輔助決策支持CDSS系統 新建 √ √ √

15 靜脈栓塞VTE管理系統 新建 √ √

16 全科醫生工作站 新建

17 患者自助服務系統 利舊對接 √ √ √

18 全院預約平臺 新建 √ 部分新建

19 互聯網醫院 新建 √ √ √

20 單病種質量管理系統 新建 √ √

21 人事管理系統 新建 √ √ √

22 集團化供應鏈管理 新建 √ √ √

23 物資管理系統 新建 √ √ √

24 固定資產管理系統 新建 √ √ √

25 設備管理系統 新建 √ √ √

26 成本核算系統 新建 √ √ √

27 報賬管理系統 新建 √ √ √

28 財務業務一體化系統 新建 √ √ √

29 預算管理系統 新建 √ √ √

30 DRG/DIP運營管理系統 新建 √ √ √

31 醫保智能審核 新建 √ √ √

32 醫保結算清單質控系統 新建 √ √ √

33 門診辦公室管理 新建 √ √ √

34 醫保管理工作站 新建 √ √ √

35 藥房管理系統 新建 √ √ √

36 藥庫管理系統 新建 √ √ √

37 輸液室管理系統 新建 √ √ √

38 物價管理 新建 √ √ √

39 電子發票系統 升級對接 √ √ √

40 門急診掛號收費管理系統 新建 √ √ √

41 一卡通管理系統 新建 √ √ √

42 入院登記管理 新建 √ √ √

43 住院收費管理 新建 √ √ √

44 醫技工作管理系統 新建 √ √ √

45 分診叫號管理系統 新建 √ √

46 CA電子簽章系統 新建 √ √ √

47 門診應急收費管理系統 新建 √ √

48 ESB服務總線 新建 √ √ √

49 集成平臺管理與監控 新建 √ √ √

50 患者主索引 新建 √ √ √

51 主數據管理 新建 √ √ √

52 單點登錄 新建 √ √ √

53 統一用戶與認證管理 新建 √ √ √

54 大數據管理平臺 新建 √ √ √

55 臨床數據中心 新建 √ √ √

56 運營數據中心 新建 √ √ √

57 統一云平臺管理系統 新建 √ √ √

2.2.軟件開發、實施服務采購清單

序號 服務內容 建設方式 三級醫院 二級醫院 一級醫院

1 移動護理 升級 √ √ √

2 護理管理 升級 √ √ √

3 PACS 升級 √ √ √

4 全院心電/電生理 升級 √ √ √

5 營養膳食管理 升級 √

6 合理用藥管理 升級 √ √ √

7 處方點評管理 升級 √ √ √

8 前置審方管理 升級 √

9 手術麻醉管理 升級 √ √

10 外聯平臺 升級或新建 √ √ √

11 院感管理 升級 √ √

12 消毒供應室管理 升級 √ √ √

13 靜脈配置中心管理系統 升級 √

14 體檢管理 升級 √ √

15 HQMS上報平臺 升級 √ √

16 病案統計管理 升級 √ √ √

17 病案示蹤管理 升級 √ √

18 病案首頁質控管理 升級 √ √

19 無紙化病案管理 升級 √ √

20 病案翻拍管理 升級 √ √

21 檢查檢驗互認協同 新建 √ √

22 協同應用 新建 √ √ √

23 日間手術管理 新建 √ √

24 治療過程管理 新建 √ √

25 觸摸屏導醫 新建 √ √ √

26 處方安全流轉 新建 √ √ √

27 遠程會診 新建 √ √ √

28 雙向轉診 新建 √ √ √

29 入院準備中心 新建 √ √

30 陪護配送管理 新建 √ √

31 患者管理 新建 √ √ √

32 隨訪管理 升級 √ √ √

33 醫務管理 新建 √ √ √

34 會診管理 新建 √ √ √

35 不良事件管理 新建 √ √ √

36 臨床危急值管理 新建 √ √ √

37 疾病監測管理上報、傳染病上報 新建 √ √ √

38 報卡管理 新建 √ √ √

39 閉環管理 新建 √ 部分實現

40 質量指標可視化管理 新建 √ √ 部分實現

41 系統改造服務

42 接口總集管理

2.3.建設范圍

序號 機構名稱 機構級別

1 南陽市第二人民醫院 三級甲等

2 南陽市兒童醫學中心 二級

3 鴨河工區醫院 二級

4 南陽市第二人民醫院太平鎮醫院 二級

5 南陽市第二人民醫院官莊分院 二級

6 海南省五指山市中西醫結合醫院 二級

7 官莊工區赤虎街道社區衛生服務中心 一級

8 官莊工區東興街道澗河社區衛生服務中心 一級

9 官莊工區官莊鎮衛生院 一級

10 南陽交通醫院 一級

11 南陽理工學院附屬醫院 一級

12 財局社區診所 診所（一級）

13 公安社區診所 診所（一級）

14 看守所診所 診所（一級）

15 檢察院社區 診所（一級）

16 陽光家園臨檢中心 診所（一級）

17 宛城區一院 二級

18 宛城區中醫院 二級

19 宛城區婦幼保健院 二級

20 南陽醫專第三附屬醫院 二級

21 紅泥灣鎮中心衛生院 一級

22 瓦店鎮中心衛生院 一級

23 金華鎮衛生院 一級

24 茶庵鄉衛生院 一級

25 黃臺崗鎮衛生院 一級

26 高廟鎮衛生院 一級

27 溧河鄉衛生院 一級

28 漢冢鄉衛生院 一級

29 宛城區仲景街道辦事處仲景第二社區衛生服務中心 一級

30 宛城區新華街道辦事處社區衛生服務中心 一級

31 宛城區東關街道辦事處東關社區衛生服務 中心 一級

32 宛城區漢冶社區衛生服務中心 一級

33 五里堡社區衛生服務中心 一級

34 新店鄉衛生院 一級

35 白河鎮衛生院 一級

36 宛城區棗林街道辦事處棗林社區衛生服務中心 一級

37 醫共體衛生室 診所（一級）

3.實施團隊組織機構及人員配備

3.1.實施團隊組織機構

3.2.各級組織單元職責

項目委員會工作職責：

?總體指揮項目的進展；

?協調項目中出現的重大問題及與其它項目的沖突；

?項目的啟動和動員工作

?決定項目任務和方向；

?決定項目任務和方向；

?決定有關任何項目方面的政策；

?決定項目范圍、時間和資源

項目管理小組工作職責：

?項目的啟動和動員工作；

?指導每個工作小組能協調地展開工作；

?負責項目實施計劃的執行工作；

?協調各項目任務需要的資源和人員；

?調解沖突；

?對交付物進行質量審核；

?項目的變更管理

醫院項目專家組工作職責：

?負責需求的最終確認簽字；

?負責調解需求功能沖突；

?項目需求的變更管理；

?對交付物的質量進行驗證

醫院各科室信息管理員工作職責：

?梳理本科室業務需求或要求；

?配合需求調研，提供調研需要的相關資料或文檔

項目執行小組工作職責：

?按計劃推動和執行階項目實施任務；

3.3.實施過程職責劃分

本次醫院信息化建設項目需院方與項目承接方高度配合協調才可能成功，而配合協調的前提是職責明確，為此在本說明書中就相關項目實施方在實施過程各階段應配合事項加以劃分說明，供項目各層人員有效執行，避免因各方配合不利造成的進度延遲。

階段 目的 院方職責 武漢盛博匯職責 外圍系統廠商職責

項目啟動階段 啟動項目，組建項目團隊、協調資源配備到位。 由院方總指揮正式啟動本項目，所有項目組成員確保職責內工作落實與推進到位，有計劃高效率的開展工作。召開項目啟動會，明確項目目標，獲取醫院各級領導支持，傳達會議精神。

成立院方項目小組，明確項目組成員、醫院各診療職能科室的接口人、聯系方式、工作職責和流程； 承接方總指揮進行合同執行分析，制定項目章程，明確項目執行策略和思路，授權并任命項目經理，由項目經理組建項目組，明確項目組職責，明確與院方的工作協調配合方式（需求評審確定、變更、資源協調），明確交付現場管理制度。 　

項目規劃階段

（項目總體計劃及項目范圍細節） 了解醫院、部門、業務級目標，明確項目范圍，最終形成項目總體實施方案。 院方各職能管理部門、各科室相關管理人員：提供承接方需求調查小組需了解的業務說明資料。

計算機中心：提供項目組展開工作必須的工作場地、軟硬件環境；

完成項目總體規劃，確定項目范圍和客戶化開發范圍，參予總體實施方案制定與討論。確定第三方系統采購計劃。

院領導：確認項目總體實施方案。

院方總體情況和業務了解；

確定項目范圍細節；

客戶化開發范圍討論；

制定及討論項目總體實施方案。 　

項目準備階段

（安裝部署+培訓） 完成硬件環境及衛生健康監管平臺、區域運營數據中心、區域臨床數據中心、資源共享協同等產品部署，確定客戶化開發需求 計算機中心：負責組織協調；衛生健康監管平臺、區域運營數據中心、區域臨床數據中心、資源共享協同等系統部署必備軟硬件環境準備，滿足測試環境、研發環境、培訓環境的要求；產品驗收。

醫院業務科室：完成整理初始化數據，指標確認；參與基礎產品培訓并與承接方人員確認客戶化開發需求。 對院方相關人員進行基礎產品培訓；

以基礎產品為依托確定客戶化開發需求。 　

客戶化開發階段 根據調研結果，完成客戶化開發及調試 醫院相關業務科室：負責提供系統設計時的業務專業知識；與需求分析師合作制定業務問題的解決方案，審核需求分析師是否準確理解了相關需求，負責解答需求分析師對業務方面的疑問，并對需求進行最終簽字確認。

計算機中心：保障遠程協同的IT環境，深度參予業務需求解決方案的制定，適度參予部分開發工作，及時確認變更需求和變更工作量，確認客戶化開發進度，組織階段性驗收并簽署階段性驗收報告。 業務分析與設計師：負責分析業務、負責及時與醫院相關人員溝通，確保系統實現不偏離應用要求。

開發人員：按照設計要求進行服務開發與組裝，確保程序質量（準確性與高性能）；

性能測試組：對新開發的代碼進行壓力測試，確保不因代碼修改出現性能阻塞點。

功能可用性測試組：對軟件成品進行可用性測試，確保軟件成品與需求一致，并保證高易用性。

配置管理組：確保客戶化需求的功能特性，能夠正確發布到應用環境； 　

系統聯調與培訓階段 對所有上線的各個環境的系統進行流程協同的聯調工作，確保上線各個環節準備完畢（含應用系統與IT環境的聯調）；培訓各個崗位的應用系統使用者骨干掌握系統的操作及各種情況的處理方法。 計算機中心：確保聯調需要的各方資源組織到位；確保使用者按要求參加培訓，制定并嚴格執行培訓紀律和培訓考核；

醫院使用者：確保按要求參加培訓，并熟練掌握系統的使用及各種問題的處理方法。 負責現場培訓與培訓效果評估；

現場確保聯調工作的順利進行；

確保聯調過程中數據初始化、模板及時調整。 確保現場聯調工作的順利進行。

上線及驗收階段 確保醫院醫療秩序。確保醫療全過程全環節不因任何類型的問題受到阻滯。 計算機中心：規劃上線總體安排，協助乙方制定項目上線計劃，完成項目上線所需的準備協調工作，緊扣項目上線目標控制項目需求，與承接方一道組成問題統一處理中心，確保及時調度各廠商相關人員及時解決上線問題；組織系統上線驗收及整體驗收工作進行；傳達驗收整改意見、參與整改方案討論、確認整改應對結果；簽署上線驗收報告。

醫院相關部門，例如門辦等部門：組織人員配合項目上線，安排好患者引導工作，參與整體驗收。

院領導：參與整體驗收并簽署驗收報告。 制定項目上線計劃，增派研發和實施人員保障上線的順利進行；

提交整體驗收申請，配合上線驗收及整體驗收完成；

應對驗收整改意見。 派駐實施或開發人員支援上線。

基于業務功能需求，完成集成接口上線確認。

上線后的運維階段 保障系統的穩定運行。 計算機中心：對已經修復的bug及時反饋給科室。 派駐現場工程進行系統運維，同時對發現的bug及時提交開發進行修復，并根據緊急程度進行系統升級安排。 　

3.4.擬投入本項目實施團隊主要人員構成表

擬投入本項目實施團隊主要構成人員如下表：

擬派總人數 20人

項目

負責人 姓名 張樂樂 年齡 32

職稱 項目經理 經歷 高級項目經理，在公司就業8年，擔任河北華奧醫院項目經理

擬投入本項目的其他人員 姓名 職位 資格證 從事該專業的時間

胡鐵 項目總監 有 10

李杰 研發經理 無 9年

趙鵬飛 系統運維組長 無 6年

余明 互聯網項目經理 無 6年

李金俊 HRP項目經理 無 6年

陳豪 大數據項目經理 無 6年

劉龍 PMO 有 10年

王宇 實施工程師 無 5年

李詩俊 實施工程師 無 5年

周凌峰 實施工程師 無 3年

高亮 高級運維工程師 無 9年

趙朋旺 商務協調人員 無 10年

上表為擬投入南陽市宛城區醫療健康服務集團信息化平臺采購項目主要管理及技術人員。在項目實施過程中，在保證上述人員配置外，我司將根據各實施工序及進度需求增配實施人員，以保證整個項目部署合理有序、按質按量地進行及完成。

3.5.指導原則

院領導把握全局，堅定的推行系統的更換及應用

在新系統上線和熟悉過程中，由于醫護人員已經習慣于老系統的使用方式或者新系統的細節處理不夠完善，甚至偶爾有系統報錯，有些醫護人員在使用時，難免出現一些抵觸和不滿的情緒。

院領導、各科室領導及信息科負責人，需要對本次系統更換的必要性和具體內容，進行上線前動員，并讓每個醫護人員都明白新HIS&EMR云平臺系統的上線是支撐醫院未來10-20年發展的“利劍”，讓全體醫護人員積極努力的適應新系統，短期內盡快達到熟練使用。

制定上線計劃，堅定不移推行，確保上線成功

為保障上線成功，現場實施團隊及后臺公司技術支持中心應在信息科的指導下，精心制定上線計劃，并在上線過程中，迅速平穩過渡，事前認真分析風險點，事中嚴格把控，確保上線成功。

1、時間短、任務重，為保障上線的成功，原則上對程序不做改動，待上線穩定后優化和提升相關合理性需求，軟件系統版本將在2024年3月20日封版。

2、自2024年3月20日-4月1日為上線周期，在此期間，除特別急迫的需求或者影響醫務人員完成其主要業務流程的需求，項目組不再安排新需求的研發。

上線應秉承“整體規劃、穩步實施、通力協作、關注重點”的思路，對于上線過程中的BUG或功能需求，如不影響主業務流程的需求，均在項目上線期穩定后，再根據用戶反饋、評估、改進。

切實做好數據備份和網絡安全工作

在新系統的上線過程中，為避免系統故障導致后臺數據的錯誤、崩潰等極端情況發生。需要切實做好數據庫的備份工作，保護醫院基本醫療業務數據。同時為保證系統正常運行，不影響基本醫療業務的使用，網絡的安全也是必要的。

4.實施周期（進度）計劃

第一章 第二章 第三章 第四章 第五章 4.1.第一階段：南陽市第二人民醫院總院建設

4.1.1.實施周期：6個月

4.1.2.實施范圍：南陽市第二人民醫院總院、南陽市兒童醫學中心

4.1.3.實施內容：

序號 第三方 服務內容 建設方式 南陽二院一期建設任務清單

1 第三方 移動護理 升級 √

2 第三方 護理管理 升級 √

3 第三方 PACS 升級 √

4 第三方 全院心電/電生理 升級 √

5 第三方 合理用藥管理 升級 √

6 第三方 處方點評管理 升級 √

7 第三方 前置審方管理 升級 √

8 第三方 手術麻醉管理 升級 √

9 第三方 外聯平臺 升級或新建 √

10 第三方 院感管理 升級 √

11 第三方 消毒供應室管理 升級 √

12 第三方 靜脈配置中心管理系統 升級 √

13 第三方 體檢管理 升級 √

14 第三方 HQMS上報平臺 升級 √

15 第三方 病案統計管理 升級 √

16 第三方 病案示蹤管理 升級 √

17 第三方 病案首頁質控管理 升級 √

18 第三方 無紙化病案管理 升級 √

19 第三方 檢查檢驗互認協同 新建 √

20 第三方 治療過程管理 新建 √

21 第三方 觸摸屏導醫 新建 √

22 互聯網 遠程會診 新建 √

23 HIS 患者管理 新建 √

24 第三方 隨訪管理 升級 √

25 HIS 醫務管理 新建 √

26 HIS 會診管理 新建 √

27 HIS 不良事件管理 新建 √

28 HIS 臨床危急值管理 新建 √

29 HIS 閉環管理 新建 √

30 HIS 門診醫生工作站 新建 √

31 HIS 住院醫生工作站 新建 √

32 HIS 門診電子病歷 新建 √

33 HIS 住院電子病歷 新建 √

34 HIS 門診護士工作站 新建 √

35 HIS 住院護士工作站 新建 √

36 第三方 臨床檢驗信息系統 新建 √

37 第三方 全院輸血流程管理系統 新建 √

38 第三方 臨床輔助決策支持CDSS系統 新建 √

39 第三方 患者自助服務系統 利舊對接 √

40 互聯網 互聯網醫院 新建 √

41 HRP 人事管理系統 新建 √

42 HRP 集團化供應鏈管理 新建 √

43 HRP 物資管理系統 新建 √

44 HRP 固定資產管理系統 新建 √

45 HRP 設備管理系統 新建 √

46 HRP 成本核算系統 新建 √

47 HRP 報賬管理系統 新建 √

48 HRP 財務業務一體化系統 新建 √

49 HRP 預算管理系統 新建 √

50 第三方 DRG/DIP運營管理系統 新建 √

51 HIS 門診辦公室管理 新建 √

52 HIS 醫保管理工作站 新建 √

53 HIS 藥房管理系統 新建 √

54 HIS 藥庫管理系統 新建 √

55 第三方 輸液室管理系統 新建 √

56 HIS 物價管理 新建 √

57 第三方 電子發票系統 升級對接 √

58 HIS 門急診掛號收費管理系統 新建 √

59 HIS 一卡通管理系統 新建 √

60 HIS 入院登記管理 新建 √

61 HIS 住院收費管理 新建 √

62 HIS 醫技工作管理系統 新建 √

63 第三方 分診叫號管理系統 新建 √

64 第三方 CA電子簽章系統 新建 √

65 HIS ESB服務總線 新建 √

66 HIS 集成平臺管理與監控 新建 √

67 HIS 患者主索引 新建 √

68 HIS 主數據管理 新建 √

69 HIS 單點登錄 新建 √

70 HIS 統一用戶與認證管理 新建 √

71 HIS 統一云平臺管理系統 新建 √

4.2.第二階段：一級醫療機構接入建設，其他子系統接入，電子病歷五級報名、互聯互通四甲報名

4.2.1.實施周期：10個月

4.2.2.實施范圍：一級醫療機構信息化建設

基礎醫療機構接入清單

序號 機構名稱 機構級別

1 官莊工區赤虎街道社區衛生服務中心 一級

2 官莊工區東興街道澗河社區衛生服務中心 一級

3 官莊工區官莊鎮衛生院 一級

4 南陽交通醫院 一級

5 南陽理工學院附屬醫院 一級

6 財局社區診所 診所（一級）

7 公安社區診所 診所（一級）

8 看守所診所 診所（一級）

9 檢察院社區 診所（一級）

10 陽光家園臨檢中心 診所（一級）

11 南陽醫專第三附屬醫院 二級

12 紅泥灣鎮中心衛生院 一級

13 瓦店鎮中心衛生院 一級

14 金華鎮衛生院 一級

15 茶庵鄉衛生院 一級

16 黃臺崗鎮衛生院 一級

17 高廟鎮衛生院 一級

18 溧河鄉衛生院 一級

19 漢冢鄉衛生院 一級

20 宛城區仲景街道辦事處仲景第二社區衛生服務中心 一級

21 宛城區新華街道辦事處社區衛生服務中心 一級

22 宛城區東關街道辦事處東關社區衛生服務 中心 一級

23 宛城區漢冶社區衛生服務中心 一級

24 五里堡社區衛生服務中心 一級

25 新店鄉衛生院 一級

26 白河鎮衛生院 一級

27 宛城區棗林街道辦事處棗林社區衛生服務中心 一級

28 醫共體衛生室 診所（一級）

4.2.3.實施內容：

序號 第三方 系統名稱 建設方式 南陽二院二期建設任務清單

1 HIS 專科病歷 新建 √

2 互聯網 移動醫生站 新建 √

3 HIS 臨床路徑（門診、住院） 新建 √

4 第三方 護理交互大屏 新建 √

5 第三方 抗菌藥物管理系統 新建 √

6 第三方 靜脈栓塞VTE管理系統 新建 √

7 HIS 全科醫生工作站 新建 √

8 HIS 全院預約平臺 新建 √

9 第三方 單病種質量管理系統 新建 √

10 第三方 醫保智能審核 新建 √

11 第三方 醫保結算清單質控系統 新建 √

12 HIS 門診應急收費管理系統 新建 √

13 大數據 大數據管理平臺 新建 √

14 大數據 臨床數據中心 新建 √

15 大數據 運營數據中心 新建 √

16 第三方 營養膳食管理 升級 √

17 第三方 病案翻拍管理 升級 √

18 HIS 協同應用 新建 √

19 HIS 日間手術管理 新建 √

20 互聯網 處方安全流轉 新建 √

21 互聯網 雙向轉診 新建 √

22 HIS 入院準備中心 新建 √

23 第三方 陪護配送管理 新建 √

24 HIS 疾病監測管理上報、傳染病上報 新建 √

25 HIS 報卡管理 新建 √

26 大數據 質量指標可視化管理 新建 √

27 HIS 系統改造服務 　 　

28 HIS 接口總集管理 　 　

4.3.第三階段：院內?？粕罨?、二級機構接入

4.3.1.實施周期：8個月

4.3.2.實施范圍：二級機構接入

包含：鴨河工區醫院、南陽市第二人民醫院太平鎮醫院、南陽市第二人民醫院官莊分院、宛城區一院、宛城區中醫院、宛城區婦幼保健院、南陽醫專第三附屬醫院。

注：若醫院開業未在時間節點，實施進度將根據醫院運營情況進行實施。

4.3.3.實施內容：

? ? ? ?分院區接入

4.4.第四階段：電子病歷6（省級文審）互聯互通5乙（省級文審）智慧服務三級。

4.4.1.實施周期：6個月

4.4.2.實施范圍：電子病歷6（省級文審）互聯互通5乙（省級文審）智慧服務三級

4.4.3.實施內容：

? ? ? ? 文審要求。

5.實施周期（進度）保障措施

項目實施總工期：要求工期24個月內。

5.1.實施周期（進度）管理的核心理念

實施周期管理的核心理念是：專業、提升、規范。結合項目實施專業能力，運用豐富的管理知識、軟件應用經驗，依據規范化項目管理的原則，根據項目具體情況設計項目實施路線和計劃，科學周密地組織項目實施與項目管理，按計劃開展實施工作，提高項目實施質量和效果，實現客戶長期的管理提升和全面信息化。

按照項目實施方法論開展項目實施，可以達到：

基于工作對象的分配模式，提高項目團隊成員的效率；

充分細致的對象定義及分配，可清晰地分解對象及相互依賴；

實施方法的可視化描述和計劃使客戶能夠更好的理解項目過程和進展情況；

減少監督、協調工作量以降低實施成本；

階段化的審批機制，使得項目組織結構會能清晰準備地介入項目執行過程。

5.2.實施周期（進度）管理方法

先進、科學的項目管理是項目成功的關鍵。我方在醫院信息系統建設過程中積累了豐富的項目管理經驗，特別是對大型中心醫院的信息系統建設有深刻的理解，并針對性地提出了具有醫療信息化行業特色、符合醫院信息系統建設要求的整套項目管理方法和策略。

我方的項目管理方法論基于可交付的原則，即把所有管理和技術過程置于一個有序的體系下，每個環節均是標準化、可控的；當所有環節均能夠按照預定的質量、進度要求達到其目標后，則同時就意味著實現了整體系統的成功交付。

公司一直在積極探討軟件工程化管理的有效途徑，經過CMMI咨詢公司的建設性指導、國際先進技術研發咨詢公司ThoughtWork的技術與管理思想的引入，加上公司多年的軟件工程管理實踐經驗，總結出了鐵盒實際的軟件工程管理之道，可把軟件的整個生命周期（LifeCycle）涉及的研發計劃、需求分析、系統設計、程序編寫、測試、實施、運行維護等步驟，通過行之有效的智能化管理途徑串聯起來，形成可量化、可監控、可持續優化的閉環管理模式。

為保障本項目順利進展，按期完成工作，我們將采用Scrum敏捷開發納入到項目開發工程化管理過程中，通過采用適當的自動化管理工具，以技術手段來保障項目管理的科學性、連續性、閉環可監控性。

5.3.組織保障

成立進度管理小組，建立工程進度監測系統。本工程成立由項目經理為組長、技術負責人、項目部主要負責人、施工隊負責人的進度管理小組，對項目實施部署過程中的進度情況實行全過程管理。建立進度監測系統，收集項目進度信息，及時作出統計、分析、比較，并根據實際情況在第一時間作出調整。

5.4.進度控制要素

本項目應在保證項目質量和安全的基礎上，確保項目進度。項目中以總進度網絡計劃為依據，按不同項目階段、不同專業分解為不同的進度分目標，以各分項管理、技術措施為保護手段，進行項目全過程的動態控制。

（一）進度控制的方法

1.按項目階段分解，突出控制節點。

以關鍵線路和次關鍵線路為線索，以計劃中起止里程碑為控制點，在不同項目階段確定重點控制對象，制定項目細則，達到保證控制節點的實現。

2.按專業分解，確定交接時間。

在不同專業的任務之間，要進行綜合平衡，并強調相互間的銜接配合，確定相互交接的日期，強化工期的嚴肅性，保證項目進度不在本專業造成延誤。通過對各專業完成的質量與時間的控制達到保證各分部項目進度的實現。

3.按總進度網絡計劃的時間要求，將項目總進度計劃分解為年度、季度、月度和旬期進度計劃。

（二）實施項目進度計劃的動態控制

項目進度計劃的控制是一個循環漸進的動態控制過程，項目現場的條件和情況千變萬化，項目經理部要及時了解和掌握與項目進度有關的各種信息，不斷將實際進度與計劃進度進行比較，一旦發現進度拖后，要分析原因，并系統分析對后續工作將產生的影響，在此基礎上制定調整措施，以保證項目最終按預定目標實現。

（三）保證按時開工措施

周密、細致的項目準備工作是確保項目準時開工，以及開工后形成連續項目能力的前提。公司組織項目團隊入駐現場，與院方共同開展項目管理與執行工作，制定周密的項目進度計劃表，并嚴格按照計劃開展工作。

（四）項目組織保證措施

把好系統驗收、調試關。試運轉前期的準備工作愈充分，系統投用就愈順利，保護校驗愈徹底、重現性愈好，系統投用后的可靠性就愈高。在這方面，我們是有成熟的經驗和業績予以保證的。

（五）以質量保證進度措施

質量和進度即相互矛盾又相互依存，離開質量的進度是肥皂泡的進度，離開了進度的質量是無效用的質量，因此在本項目中，我方將強化質量管理和質量保證措施，以優質的質量來保證項目進度的準點。

在跟蹤項目進度的同時，加強現場質量檢驗人員的管理，針對不同專業的質量難點，會同各方技術人員進行研究攻關、制定對策措施，預防在先。

（六）后勤保障措施

我方將加強后勤管理，制定各方面的后勤保障措施。

對本項目我方將采用全天候工作制，合理安排項目人員的休息，做好后勤供應工作確保作業面不間斷項目。

（七）獎懲措施

我方將按階段采用獎罰分明的考核制度，保證項目進度的準點完成。

制定項目進度考核辦法，運用經濟杠桿的調節作用，經濟分配與進度完成情況掛鉤，獎懲分明。

我方在執行合同內容延誤工期而承擔罰金的條款的同時，將向全體員工進行嚴格履行合同的宣傳教育，使每個員工清楚地認識到履約的責任和義務，從而認真地執行保證工期的各項措施。

5.5.進度控制措施

為了確保項目按期完成，公司將對項目的進度進行持續的監控管理。通過制定項目計劃和對計劃的定期回顧檢查，按照一定的匯報機制，管理項目的執行情況，并根據實際情況，對項目計劃進行必要的調整。我們所建議的進度管理主要手段包括：

（一）項目例會

由項目經理每周召集舉行項目例會，對項目的實施工作完成情況進行總結并確定下周計劃，同時在會上對提出的爭議和問題進行討論。項目周例為每周五的上午舉行，參加人員是雙方項目組成員（雙方項目經理必須參加）。例會結束后整理《周項目總結報告》，發送給雙方項目管理負責人。

由項目經理根據項目情況召集舉行項目月度例會，主要討論總體的項目進展、問題和變更的狀態、后續的工作進程和任務分配等并形成會議紀要。參加人員是項目經理及項目組核心成員。雙方的項目經理應在月末提交《項目狀態報告》至雙方項目項目管理負責人。

在實施過程中發生的臨時性會議，視情況隨時召集，參加人員是項目經理及項目組核心成員，結果報告雙方項目總監，由雙方高層協商確定。

所有會議均應在會議結束后產生《會議紀要》，通知雙方的項目經理，具體參見《項目會議指南》。

（二）項目狀態報告

在項目實施過程中，項目經理根據項目的情況，應定期（周或月）向軟件工程部經理提交項目狀態報告并抄送保證部經理，匯報項目的進度、質量、成本方面進展以及完成、未完成工作、存在問題、下一步的工作計劃等內容，并在此基礎上形成對客戶方的項目狀態報告，具體的格式參見相應的模版。

（三）項目里程碑/階段評估驗收

在項目里程碑點或者階段點，項目經理組織雙方相關人員進行評估和驗收，就本階段/里程碑完成情況進行確認，如果需要進行變更則進行溝通和協商，結束后形成《會議紀要》、《階段驗收報告》，并提交給雙方項目管理負責人，由雙方高層協商確定。

里程碑名稱 主要工作 主要工作產出 計劃達成時間 備注

合同簽訂 合同簽訂 合同 2023.12

模擬環境搭建 搭建模擬演示環境 演示環境搭建確認書 2023.12 (硬件環境就緒后)

生產環境搭建 搭建生產環境，用于上線后的生產使用 生產環境搭建確認書 2024.1 (硬件環境就緒后)

系統上線 完成總院核心系統上線 上線確認書 2024.4

系統建設完成 合同全部內容和范圍建設完成 上線確認書 2025.12

項目整體驗收 完成合同整體 驗收報告 2026.6

（四）項目審計

項目過程中，公司質量保證部門將定期或不定期對項目情況進行審計，從進度、成本、質量等方面進行報告，以第三方的形式總結項目問題，并提交《項目審計報告》給公司質量保證負責人和公司項目管理委員會。

5.6.關鍵路徑實施進度管理

5.6.1.關鍵路徑識別

對于一個信息化項目而言，只有項目網絡中最長的或耗時最多的活動完成之后，項目才能結束，這條最長的活動路線就叫關鍵路徑（Critical Path），組成關鍵路徑的活動稱為關鍵活動。其通常做法是：?

1）將項目中的各項活動視為有一個時間屬性的結點，從項目起點到終點進行排列；?

2）用有方向的線段標出各結點的緊前活動和緊后活動的關系，使之成為一個有方向的網絡圖；?

3）用正推法和逆推法計算出各個活動的最早開始時間，最晚開始時間，最早完工時間和最遲完工時間，并計算出各個活動的時差；?

4）找出所有時差為零的活動所組成的路線，即為關鍵路徑；?

5）識別出準關鍵路徑，為網絡優化提供約束條件；?

它具有以下特點：?

1）關鍵路徑上的活動持續時間決定了項目的工期，關鍵路徑上所有活動的持續時間總和就是項目的工期。?

2）關鍵路徑上的任何一個活動都是關鍵活動，其中任何一個活動的延遲都會導致整個項目完工時間的延遲。?

3）關鍵路徑上的耗時是可以完工的最短時間量，若縮短關鍵路徑的總耗時，會縮短項目工期；反之，則會延長整個項目的總工期。但是如果縮短非關鍵路徑上的各個活動所需要的時間，也不至于影響工程的完工時間。

4）關鍵路徑上活動是總時差最小的活動，改變其中某個活動的耗時，可能使關鍵路徑發生變化。

5）可以存在多條關鍵路徑，它們各自的時間總量肯定相等，即可完工的總工期。?

關鍵路徑是相對的，也可以是變化的。在采取一定的技術組織措施之后，關鍵路徑有可能變為非關鍵路徑，而非關鍵路徑也有可能變為關鍵路徑。

5.6.2.關鍵路徑實施進度保障措施

關鍵路徑識別出來后，接下來就需要設法確保關鍵路徑上的關鍵任務在指定時限內完成，具體措施如下：

一、關鍵路徑工期保證措施

1、成立技術專家組，與現場管理人員共同制定嚴密、科學、經濟、實用合理的實施方案和方法，保證工期，提供技術保障。

2、投入足夠數量、狀態良好的實施人員，保證實施工作順利進行。

3、加強實施現場的協調和指揮，保證工序間緊密銜接，下道工序的準備時間在上道工序完成，減少工序準備時間。

4、加強實施現場技術管理和質量管理，杜絕質量返工事件的發生。

二、重點控制任務的工期保證措施

1、為保證重點控制任務按期完成，根據項目實際，劃分盡可能多的工作面，安排技術能力強的人員實施。

2、對控制工期的任務，盡量提早開工。

3、編制重點控制任務實施施工組織設計，實行動態管理，及時調整各小組進度計劃和資源配置。合理使用資源，并滿足工期計劃的要求。

三、組織管理措施

1、成立精干的項目經理部，實行項目經理負責制，設置強有力的項目管理系統，實施對項目的全面管理。

2、建立健全組長負責制，強化一線組織領導和指揮。

3、根據項目需要及實施組織設計，及時按計劃安排實施，根據項目的實際要求增加所需的資源。

4、利用項目進度管理軟件適時調整作業計劃，保證月、旬計劃的實現。

四、技術保證措施

1、制定詳細的項目實施性組織設計，實施中不斷優化，做到科學施工，信息反饋及時，適時調整和優化施工計劃，確保各工序和分單位工程按時或提前完成。

2、發揮技術管理的業務指導和保障作用，細審核、嚴交底、勤檢查、抓落實。對難度較大的技術問題，會同產品研發部門、業主共同研究解決方案。

3、產品核心研發人員，要深入一線跟班作業，及時搞好技術交底，并做到發現問題及時解決。

五、應對意外情況的工期保證措施

1、為確?？偣て诘膶崿F，除做好實施組織安排，工期計劃合理排列，加強施工管理外，還需做好應對意外情況的思想準備、組織準備和資源準備。

2、工期安排依據先緊后松的原則，緊湊合理的安排好分項工程間的工期銜接，實施時間留有余地，實施過程中緊緊抓住關鍵線路不放，及時做好工期調整，制定新的實施方案，以保證項目進度滿足工期要求的實際需要。

3、經常開展實施進度協調會，及時解決實施中出現的各種問題，使項目進展緊張有序，安排科學合理。

4、做好方案論證，通過可靠的技術措施、技術方案確保工期。

5、做好培訓教育，定期對員工進行防范意外情況發生的教育和動員。

6、充分做好防范意外情況發生的各種準備，有預防，有人抓，有人管，有力量，從而將意外情況對工期的影響降低到最低限度。

6.項目實施流程（工程程序）與保證措施

本次南陽市宛城區醫療健康服務集團信息化平臺采購項目實施流程總體如下圖：

6.1.全生命周期管理實施流程

階段 目的 方式 相關參予人及職責 出品及對項目 前置條件

項目啟動階段 正式啟動項目，任命項目經理、所有資源配備到位 重要會議形式宣貫并正式啟動 項目委員會、項目管理組、項目執行組、業務需求專家組全體人員參與。

由院方總指揮正式啟動本項目，所有項目組成員應確保職責內工作落實與推進到位，有計劃高效率的開展工作。

公司方總指揮授權并任命項目經理，由項目經理制定項目計劃和項目過程管理要求。 實施方案 　

需求疏理階段 了解醫院、部門、業務級目標，疏理業務流程及管控方式及管控點。最終形成項目完整的工作目標 職能部門、相關領導、科室管理者訪談；專題討論的方式，將管理目標分解成業務流程協同方案及相關專題處理方案。同時，挖掘出現有系統產品與用戶需求間的差異。及早進入客戶化修改程序開發。 醫院方各職能管理部門、各科室相關管理人員；負責：提出業務/管理思路，并對最終的解決方案進行確認；

醫院IT部門：負責組織協調，參予方案執定討論；

公司方：需求分析組長、現場實施經理、各業務線產品經理（需求分析與解決方案制定的負責人）；負責組織訪談、業務流程疏理、專題解決方案制定、需求規格說明書（作業文件）的撰寫； 需求規格說明--作業文檔；

功能/特性差異分析及解決方案。

作為整個項目的工作目標的依據。也是資源配置與工作安排等項目管理相關工作的依據。 項目已經立項，且項目實施計劃被批準。

數據初始化準備階段 根據前一階段形成的作業文檔設計數據方案，并輸入到系統，以驅動系統按南陽市第二人民醫院的模式運行 公司方實施經理與數據初始化工程師根據“需求規格說明書--作業文檔”分解成數據初始化方案，為用戶做數據規范培訓。各業務科室根據規范要求提供數據。 公司方：實施經理，初始化實施工程師；負責培訓數據初始化工具，指導醫院相關人員整理數據（需要的話），如果需要的話，整理現有系統數據并將其導入到新系統；

醫院方業務科室專員：負責整理業務數據提供給工程師。負責確認數據的準確性檢查；

醫院IT人員：負責組織協調。 新系統各字典數據完整準確錄機。 需求疏理的結果文檔被批準或原則通過。

客戶化開發階段 根據第一階段的出品：系統功能/特性差異化分析文檔，完成客戶化開發及調試 1、各業務域分析師分析需求，撰寫用例（使用場景）說明，并通過多次反復的溝通確認用例。

2、根據用例進行系統實現設計。

3、研發人員根據系統設計組裝后臺服務（必要時擴展原后臺服務實現，或重寫后臺服務），組裝界面操作實現；

4、階段成果及時與用戶溝通確認，以便及時發現問題及時修改，直到用戶確認為至。

5、質量保障--采用公司代碼質量檢查、基于測試的編碼規范、用例測試規范、性能測試規范。

6、工作模式：前后臺協同工作、遠程平臺協同、現場開發多種工作模式結合。 公司業務分析與設計師：負責分析業務、撰寫用例場景、系統實現方案設計，并負責及時與醫院相關人員溝通，確保系統實現不偏離應用要求。

公司開發人員：按照設計要求進行服務開發與組裝，確保程序質量（準確性與高性能）；

公司性能測試組：對新開發的代碼進行壓力測試，確保不因代碼修改出現性能阻塞點。

公司功能可用性測試組：對軟件成品進行可用性測試，確保軟件成品與需求一致，并保證高易用性。

公司配置管理組：確?？蛻艋薷牡男鹿δ芴匦裕軌蛘_發布到應用環境；

醫院相關業務科室專員：負責提供系統設計時的業務專業知識；與需求分析師合作制定業務問題的解決方案，驗證用例文檔是否準確表達了其需求愿意，審核需求分析師是否準確理解了相關需求，并負責解答需求分析師對業務方面的疑問。

醫院IT部門：保障遠程協同的IT環境，深度參予解決方案的制定，適度參予部分開發工作。 業務專題解決方案；

用例說明；

性能測試報告；

可用性易用性測試報告；

可運行的應用程序 需求疏理的結果文檔被批準或原則通過；

項目準備階段

（系統后臺安裝與調試） 提供培訓環境，溝通環境、測試環境、集成環境、生產環境、生產備份環境的系統安裝與調試工作 集成醫院提供的硬件及基礎軟件資源，按不同使用性質合理分配這些資源?，F場安裝環境，并對環境的應用情況進行監控（配套監控工具的使用） 公司配置管理與運維技術組：負責全部相關工作；

公司軟件開發部門：確保應用系統的開發工作按時按質完成

醫院IT部門：確保所需要的硬件及系統軟件資源及時到位。專職IT工程師與公司運維技術組工程師并肩工作，及早掌握相關技術技能。為長期運維打下堅實基礎。 系統安裝配置技術文檔；

系統能夠滿足相關工作運行要求 服務器與計算機硬件資源到位

不同應用環境相對應的應用系統軟件通過測試；

項目準備階段

（系統聯調與培訓） 對所有上線的各個環境的系統進行流程協同的聯調工作，確保上線各個環節準備完畢（含應用系統與IT環境的聯調）；培訓各個崗位的應用系統使用者骨干掌握系統的操作及各種情況的處理方法。 待上線的所有系統工程師駐場聯調。對于新開發的應用或系統，需要派駐開發人員駐現場；

現場培訓各業務線現場使用者骨干； 公司培訓組：負責現場培訓與培訓考核；

公司相關開發人員：現場確保聯調工作的順利進行；

公司實施人員：確保聯調過程中數據初始化、模板及時調整；

醫院IT人員：確保聯調需要的各方資源組織到位；確保使用者按要求參加培訓；

醫院使用者：確保按要求參加培訓，并熟練掌握系統的使用及各種問題的處理方法。 聯調結果文檔；

系統操作說明；

常用問題處理說明； 上線前所需要的所有工作準備就序并通過測試

上線階段 確保醫院醫療秩序。確保醫療全過程全環節不因任何類型的問題受到阻滯。 調動公司及醫院IT部門的實施、開發、運維、培訓資源現場保障。保證系統發生的問題及時處理； 公司：根據子項目要求配置人員保障，覆蓋每個業務環節；

醫院門辦等部門：患者引導工作；

其它廠商：派駐足夠的實施開發人員保障；

醫院IT部門：與公司一道組成問題統一處理中心，確保及時調度各廠商相關人員及時解決上線問題。 上線問題處理記錄。 　

上線后的運維階段 保障系統7*24的穩定運行；

應用系統持續發展 啟動運維后臺監控系統，實時監控應用服務器集群、數據庫服務器集群的性能；性能預警時，發送QQ、短信等消息給相關責任人，及時介入分析處理，確保將問題消滅在萌芽中。

功能、特性納入到規范的開發管理通道。 服務器環境集成提供商：提供運維監控平臺；每月給出服務器運行情況分析報告；給醫院IT部門提供要求性能瓶頸點，及涉及的應用供應商整改要求。

我公司：對新需求按系統開發規范進行分析、解決方案、設計開發、發布更新等工作。對于非合同范圍的需求，給出處理建議；響應服務器環境集成提供商提出的應用性能整改要求。

公司方：上線后第一次對帳工作的現場支持； 相關文檔 　

備注：

6.1.1.保證措施

在整個項目中，我公司承擔了多種角色，按照每種角色對應的任務不同，可將諸多角色分為兩大類，一類是核心系統的實施，這類任務主要第一階段進行；另一類是咨詢規劃和技術支持，這類任務貫穿整個實施周期。

核心系統實施是一項軟件系統實施任務，按照軟件系統實施項目管理理論，共分為以下階段：需求梳理、數據初始化、集成實施、客戶化（醫保）開發、項目準備階段（系統后臺安裝與調試、系統聯調與培訓）系統上線、系統運維。

咨詢規劃和技術支持是一項貫穿于整個項目生命周期的任務，對于這項工作的開展方式，主要是提交各類技術文檔，并和醫院一起進行各種非核心的信息系統采購和招標等工作。技術文檔包括：需求規格說明書、系統集成要求等，在系統采購和招標工作中，集成商承擔系統技術把關工作，在分系統進行實施階段，集成商和院方一起監督工程實施，監控實施進度和質量，確保系統能夠順利融入醫院信息系統框架并穩定運行。

6.1.2.統籌管理

由于本期醫院信息化建設的長期性和復雜性，本項目必須總體考慮,來組織運作整個項目的建設過程。我們承諾從項目的實際要求出發，運用各種管理、技術工具和統籌方法，積極協調項目相關方，有效展開各項管理和技術工作。

1．任命專門項目經理，對本項目總負責。項目經理組建項目部，組織展開具體項目工作。

2．根據醫院的現有基礎條件和未來發展戰略，進行信息化系統建設的總體策劃。

3．提出技術先進、現實可行的醫院信息系統整體解決方案，并組織開發、設計、安裝、調試、試運行直至系統上線運行。

4．從項目整體角度出發對項目的范圍、進度、費用、設備材料等進行統一管理，對開發、設計、施工、試運行等進行動態的過程管理，對各個專業分包子系統進行統一管理。

5．工作包含技術平臺及各子系統數據交換數據集成、子系統實施進度管理、子系統協助預驗收及總體質量管理。

6.1.3.項目實施過程管理

核心理念

基于項目管理的標準化實施規范，旨在規范項目實施全生命周期的各項任務的順利推進，指導并引導項目管理組有效開展項目活動，通過標準化任務包在項目啟動階段組織項目實施任務包，形成符合項目要求的目標實施指南，保障項目有效落實。

盛博匯實施方法的核心理念是：專業、提升、規范。結合項目實施專業能力，運用豐富的管理知識、軟件應用經驗，依據規范化項目管理的原則，根據項目具體情況設計項目實施路線和計劃，科學周密地組織項目實施與項目管理，按計劃開展實施工作，提高項目實施質量和效果，實現客戶長期的管理提升和全面信息化。

按照項目實施方法論開展項目實施，可以達到：

?基于工作對象的分配模式，提高項目團隊成員的效率；

?充分細致的對象定義及分配，可清晰地分解對象及相互依賴；

?實施方法的可視化描述和計劃使客戶能夠更好的理解項目過程和進展情況；

?減少監督、協調工作量以降低實施成本；

?階段化的審批機制，使得項目組織結構會能清晰準備地介入項目執行過程；

基本要素

?明確的項目范圍與目標：包括業務需求范圍、功能范圍、涉及的組織實體范圍、技術范圍等。項目范圍和目標明確是項目成功的關鍵因素，項目經理如果接手的項目范圍不明確，首先應該和客戶溝通，明確項目范圍和目標。

?高層的關注與推動：醫院信息化項目不但涉及管理模式和流程的變更，也會涉及權力和利益和變化，實施過程中經常需要高層的決策、推動和分壓，缺少高層推動的項目實施經常會中途停滯而半途而廢，也經常會導致項目目標的偏離。

?科學的項目管理：盛博匯公司項目經理通過項目計劃來確定各階段劃分和工作層次，并確立項目里程碑。盛博匯公司的系統集成方法論將貫穿整個項目實施過程的始終，這將保證各項必要的任務可以在第一時間以正確的方法完成。

?數據與流程的準確性：注重各上線階段的數據方案、數據準備、數據檢查和確認，并將與真實業務場景比較接近的模擬數據和流程的方案測試貫穿于項目每個上線階段，避免在上線之后，出現不必要的軟件或數據錯誤；另外，上線后要定期做流程執行情況檢查與優化，確保執行效果。

?第三方系統廠家的配合：醫院信息化建設必然涉及到同多個系統連接使得整個信息化能夠順暢。與第三方系統交互的業務流程和數據進行集成整合，第三方廠商的積極配合是信息化建設項目成功的關鍵。

?管理和控制客戶需求和工程變更：項目實施的整一個過程中，項目的變更幾乎是不可避免的。有關項目的變更包括，由于用戶需求的改變而造成的項目范圍的擴大或縮??；雙方人力安排的改變而造成的項目進度計劃的改變，等等。盛博匯方的項目經理將與院方的項目經理一起對項目的進度和狀態進行評估、協商和決策。

?模擬系統先行：項目實施過程要求在系統正式上線前，在醫院搭設模擬運行系統，請醫院重要科室的管理和技術人員參與，對系統進行充分的試用。一方面可以發現系統功能可能存在的不足，同時科室人員在使用過程中也逐漸熟悉了新業務功能，有利于系統穩定上線。

7.項目管理與保證措施

7.1.項目管理基本要素

明確的項目范圍與目標：包括業務需求范圍、功能范圍、涉及的組織實體范圍、技術范圍等。項目范圍和目標明確是項目成功的關鍵因素，項目經理如果接手的項目范圍不明確，首先應該和客戶溝通，明確項目范圍和目標。

高層的關注與推動：醫院信息化項目不但涉及管理模式和流程的變更，也會涉及權力和利益和變化，實施過程中經常需要高層的決策、推動和分壓，缺少高層推動的項目實施經常會中途停滯而半途而廢，也經常會導致項目目標的偏離。

科學的項目管理：我公司項目經理通過項目計劃來確定各階段劃分和工作層次，并確立項目里程碑。我公司的系統集成方法論將貫穿整個項目實施過程的始終，這將保證各項必要的任務可以在第一時間以正確的方法完成。

數據與流程的準確性：注重各上線階段的數據方案、數據準備、數據檢查和確認，并將與真實業務場景比較接近的模擬數據和流程的方案測試貫穿于項目每個上線階段，避免在上線之后，出現不必要的軟件或數據錯誤；另外，上線后要定期做流程執行情況檢查與優化，確保執行效果。

第三方系統廠家的配合：醫院信息化建設必然涉及到同多個系統連接使得整個信息化能夠順暢。與第三方系統交互的業務流程和數據進行集成整合，第三方廠商的積極配合是信息化建設項目成功的關鍵。

管理和控制客戶需求和工程變更：項目實施的整一個過程中，項目的變更幾乎是不可避免的。有關項目的變更包括，由于用戶需求的改變而造成的項目范圍的擴大或縮小；雙方人力安排的改變而造成的項目進度計劃的改變，等等。我方的項目經理將與院方的項目經理一起對項目的進度和狀態進行評估、協商和決策。

模擬系統先行：項目實施過程要求在系統正式上線前，在醫院搭設模擬運行系統，請醫院重要科室的管理和技術人員參與，對系統進行充分的試用。一方面可以發現系統功能可能存在的不足，同時科室人員在使用過程中也逐漸熟悉了新業務功能，有利于系統穩定上線。

7.2.項目實施響應

（一）我公司根據對項目的理解作出項目實施的初步計劃，成為合作企業方后提交正式工作方案，明確商談項目工作的方式、方法、過程步驟、按階段分解的詳細計劃、對應計劃應提交的工作成果、需要院方協調與配合的事項，并經院方審核、批準。

（二）在項目實施過程中，由項目經理負責具體項目管理工作，周密、高效地制定項目計劃，并按周、月的方式開展項目監控與執行，同時提交進度報告。針對項目問題及進度延遲，進行分析并歸納原因說明，制定合理的解決措施并有效執行。

（三）承諾在本投標文件中闡述項目溝通計劃，確保投標方與業主之間信息溝通順暢。

7.2.1.工期響應

（1）根據招標書中的時間要求，在中標后的安排項目經理與實施、技術人員進場。

（2）合同簽訂后，根據招標的要求，系統在合同簽訂后24月內完成合同范圍內系統上線。

7.2.2.項目進場人員響應

我公司承諾進場項目經理人員有兩個同類項目實施經驗,且固定人員，直至項目驗收；項目組核心成員在項目建設中不撤換。

7.2.3.質量管理響應

(1)我公司按ISO9001質量管理體系規范要求，針對本項目實施過程及交付結果進行質量規劃、管理、控制。

(2)我公司提交正式的質量計劃，明確質量控制點、控制內容、質量要求、檢查記錄要求，并經院方審核、批準。

(3)我公司在項目實施過程中應開展質量保證活動，所提交的進度報告包括質量報告內容，對質量問題制定改進措施并有效執行。

(4)我公司承諾接受院方的質量監督檢查，提供真實有效的相關質量活動記錄、證據，無條件接受院方提出的質量問題整改要求，承擔質量責任及因質量問題導致的進度延遲責任。

(5)我公司承諾提供詳細測試方案，包括采用測試技術、測試方法和測試報告提交形式。在工程實施過程中，承諾制定測試方案，具體到每一個測試步驟，與用戶討論通過后，按計劃進行測試。

7.2.4.文檔交付響應

(1)系統集成應嚴格按照國家有關規定進行，我公司提供驗收規范、產品文檔、質保書、設計文檔、施工文檔、檢測文檔、項目管理文檔等有關文檔。

(2)應用系統開發應嚴格按照國家軟件工程規范進行，我公司根據開發進度及時提供有關文檔，包括：

①準備階段：《實施計劃》；

②需求分析階段：《需求分析說明書》；

③設計階段：《概要設計說明書》、《數據庫設計說明書》；

④測試階段：《測試計劃》、《測試報告》；

⑤上線階段：《試運行/上線報告》、公司自有產品源代碼；

⑥培訓文檔：《培訓計劃》；

⑦交付使用：《用戶手冊》；

⑧與工程相關的其他文檔。

說明：本項目數據資產歸醫院所有

7.3.項目溝通與匯報管理

7.3.1.決策制定與問題上報

本項目將以下述原則來處理如何制定決策，問題匯報上報的機制：

?醫院和盛博匯的項目經理負責項目日?；顒拥臎Q策，他們應盡力解決在其職責權限范圍內的所有問題。

?項目委員會應關注與在不同項目階段之間的指導工作；為此，項目委員會會議應在階段性開始/結束，或有異常情況發生時進行。

?在每一個階段內，項目委員會可以在不要情況下為項目管理給予臨時方針。

?所有問題將被記錄在JIRA管理平臺中，對每一個問題的活動計劃，將定義具體的決議的“負責人”以及目標完成日期。當問題得以解決后，項目管理組應將相關信息通知所有該決議相關人員。

7.3.2.匯報

項目匯報過程應遵循以下流程：

項目委員會和項目管理組

?醫院和盛博匯項目經理一起將每兩周向項目委員會提交項目要點報告，通報項目進展；并在必要情況下發起非正式的突發議題的討論。

?在一個階段結束時，項目經理撰寫結束階段報表提交項目委員會。

?如果出現臨時突發問題，將向項目委員會發送項目異常報告。

?項目管理組和項目執行組

?盛博匯的項目經理和項目成員一起，將根據盛博匯應承擔的崗位職責，通過項目任務分解設定具體的工作目標交付物。

?盛博匯項目組成員至少以周為周期，通過項目周例會（報告）的形式匯報（撰寫）項目進展。

?項目組成員應根據情況緊急程度盡早報告項目中出現的問題。

7.3.3.問題管理

基于JIRA管理平臺，構建軟件產品研發過程的缺陷跟蹤、客戶服務、需求收集、任務跟蹤、敏捷管理的項目管理事務跟蹤平臺，可清晰了解每一個工作任務的處理進度與狀態。

?項目組成員應在項目管理會議上評審和更新項目相關問題的進展，對必要的問題進一步上報。

?項目經理負責維護和管理問題全過程跟蹤，項目組成員根據可能出現的問題，應上報項目經理。

7.3.4.溝通管理渠道

序號 溝通渠道

1 建立工作QQ群，保障及時通信環境；

2 建立遠程視頻環境，保障隨時的會議討論，確保異地協同模式無障礙進行；

3 每周工作會議，檢查計劃執行情況，評估風險，推進工作落實；

4 在網絡知識管理平臺上開放項目共享空間，共享項目文檔；

5 在任務管理平臺上，開放項目管理專題，隨時獲得任務完成情況統計或詳細內容；

8.項目質量保證體系及措施

經過多年來實際工程的磨練，公司培養并且引進了一批成熟的技術設計人員和項目管理人員，因此在開發過程中我們遵循CMMI規范和ISO9001質量管理體系，并在項目全生命周期內遵循ISO/IEC27001信息安全管理體系，針對項目特點進行分析，制定嚴格的項目管理體系，從人員的組成、職能分工、匯報流程、項目過程控制等做到層層控制，通過流程的控制和監管來減少我們的開發風險，為客戶提供優秀的軟件產品和高度負責人的服務要求。

8.1.建設質量目標

質量管理具體目標要求包括：

(1)按照ISO9001質量管理體系規范要求，針對本項目實施過程及交付結果進行質量規劃、管理、控制。

(2)提交正式的質量計劃，明確質量控制點、控制內容、質量要求、檢查記錄要求，經項目組內部確認并形成相應文檔，并經院方審核、批準。

(3)承諾項目實施過程中應開展質量保證活動，所提交的進度報告應包括質量報告內容，對質量問題制定改進措施并有效執行。

(4)承諾接受院方的質量監督檢查，提供真實有效的相關質量活動記錄、證據，無條件接受院方提出的質量問題整改要求，承擔質量責任及因質量問題導致的進度延遲責任。

(5)承諾提供詳細測試方案，包括采用測試技術、測試方法和測試報告提交形式。在工程實施過程中，公司擬定測試方案（具體到每一個測試步驟），與用戶討論通過后，按計劃進行測試。

8.2.質量保障要素

8.2.1.加強質量管理意識

為確保項目的實施質量，對所有人員進行培訓，明確系統開發環節的各自負責內容的質控和流程發布，從每個實施及編碼人員明確開發過程中的質量控制。。

8.2.2.建立質量管理體系

本項目的質量目標（即驗收標準）是通過電子病歷應用水平分級評價5級和醫院信息互聯互通標準化成熟度測評4級乙等。滿足用戶信息化平臺部署的質量要求和期望。實施部署質量控制是項目管理的重要內容，以先進的技術和經濟的方法將各種生產要素有效的組合，按招標要求及意圖，根據我公司質量控制文件對實施部署的全過程進行有效的控制。

1、制訂嚴格的項目管理制度。項目經理部項目質量責任制應明確規定項目領導和全體管理人員的質量責任及從各項質量管理人員的責任和權限。

2、項目部專設有質量控制平臺，有明確的開發過程中從需求的提出確認、到代碼的編寫、測試、試運行、正式發布都有嚴格規定。做到質量管理機構落實、人員落實、制度落實、管理落實、獎懲落實。

8.2.3.項目質量管理制度

本項目對實施質量有嚴格的要求，實施如出質量問題會造成不可彌補的損失。我們在實施管理中嚴格執行質量測試、質量監督，對發生的質量問題及時處理。

每一個系統完成的每一階段，都必須經過技術指標測試，完全滿足使用需求后才允許進入下階段系統的全面部署，各系統進入全面部署后完成后對項目整體進行測試。

質量監督由院方、項目部和監理小組共同負責。實施人員的責任要求每一個人員按照實施規范進行部署，項目部現場管理員除了完成抽樣測試之外，還要檢查各實施人員的管理工作和實際部署是否按要求執行，項目管理辦公室定期對實施人員和現場管理員的工作進行檢查，對所發生的質量事故做出處理決定。測試員執行完善的質監制度，對不負責任的實施人員教育批評處罰、重新部署，嚴重者開除處理。發文要求及時采取補救措施確保項目按時、按質、按量完成 。

當發生質量問題和質量事故時，由現場管理員通知同類子系統的實施部署暫停，由現場管理員和實施技術人員一起進一步驗證和查找質量問題出現的原因。原因查明后共同提出解決辦法。當原因不明時管理員應及時向項目部報告，由項目部組織有關方面的技術人員到場進行技術分析，直到查明原因。

8.3.軟件的質量標準、測試手段

測試是保證信息化系統軟件質量的重要手段，為保證系統的質量，將會采用下列標準軟件測試手段：測試原則、測試種類、測試準備、測試方法、測試對象、測試流程和問題處理流程來進行。

8.3.1.測試原則

角色

本文檔在組織中實施所涉及的角色

角色名稱 定義/職責

測試設計員 制定和維護測試計劃，涉及測試用例和測試過程，生成測試分析報告

測試員 執行集成測試和系統測試，記錄測試結果

設計員 涉及測試需要的驅動程序和穩定樁

編碼員 編寫測試驅動程序和穩定樁，執行單元測試

進入準則

進入準則描述

軟件項目立項被批準

輸入

輸入名稱 輸入描述 參考

軟件項目計劃 軟件項目計劃是一個綜合的組裝工件，用來收集管理項目時所需和所有信息。 《項目開發計劃》

軟件需求工件 描述軟件需求的文檔，如軟件需求規約文檔或利用case工具建模生成的文檔。 《需求規格說明書》

軟件架構設計工件 架構設計文檔主要描述備選設計方案、軟件子系統劃分，子系統建接口和錯誤處理機制等。 《概要設計說明書模版》

軟件詳細設計工件 詳細設計文檔主要描述架構設計轉化為最小實施單元，產生可以編碼的設計。 《詳細設計說明書模版》

軟件程序單元 包含了所有編碼員完成的程序單元源代碼。

軟件集成計劃 軟件工作版本的定義、工作版本的內容、繼承的策略以及實施的先后順序等。

軟件工作版本 按照集成計劃創建的各個集成工作版本。

活動

序號 活動名稱 角色 活動描述 參考

1 制定測試計劃 測試設計員 制定測試計劃的目的是收集和組織測試計劃信息，并且創建測試計劃。

確定測試需求-根據需求工具收集和組織測試需求信息，確定測試需求。

制定測試策略-針對測試需求定義測試類型、測試方法以及需要的測試工具等。

建立測試通過準則-根據項目實際情況每一個層次的測試建立通過準則。

確定資源和進度-確定測試需要的軟硬件資源、人力資源以及測試進度。

評審測試計劃-根據同行評審規范對測試計劃進行同行評審。 《軟件測試計劃模版》

2 設計測試 測試設計員 設計測試的目的是為每一個測試需求確定測試用例集，并且確定執行測試用例的測試過程。

設計測試用例

對每一個測試需求，確定其需要的測試用例。

對每一個測試用例，確定其輸入和預期的結果。

確定測試用例的測試環境配置，需要的驅動界面或穩定樁。

編寫測試用例文檔

對測試用例進行同行評審。

開發測試過程

根據界面的原型為每一個測試用例定義詳細的測試步驟。

為每一步驟定義詳細的測試結果驗證方法。

編寫測試過程文檔

對測試過程進行同行評審

在實施測試時，對測試過程進行更改 《軟件測試用例模版》

《軟件測試過程模版》

輸出

輸出名稱 輸出描述 參考

軟件測試計劃 測試計劃包含項目范圍內的測試目的和測試目標的有關信息。此外，測試計劃確定了實施和執行測試時的策略，同時確定了所需的資源。 軟件測試計劃模版

軟件測試用例 測試用例視為特定的目標開發的測試輸入、執行條件和預期結果的集合。 軟件測試用例模版

軟件測試過程 測試過程是對給定的測試用例（或測試用例集）的設置、執行和結果評估的詳細說明的集合。 軟件測試過程模版

測試結果日志 測試結果是記錄測試期間測試用例的執行情況，記錄測試發現的缺陷，并且用來對缺陷的跟蹤。 測試日志模版

測試分析報告 測試分析報告時對每一階段（單元測試、集成測試、系統測試）的測試結果進行分析和評估 測試分析報告模版

驗證與確認

驗證與確認名稱 驗證與確認細節 參考

軟件測試計劃評審 由項目經理、測試組、其它相關組對測試計劃進行評審

軟件測試用例評審 由測試組、其它相關組對測試用例進行評審

軟件測試過程評審 由測試組、其它相關組對測試過程進行評審

測試結果評估 由測試組、其它相關組對測試結果進行評估

測試分析報告評審 由項目經理、測試組、其它相關組對測試分析報告進行評審

SQA 驗證 由SQA人員對軟件測試活動進行經營分析

退出準則

退出標準描述

滿足組織/項目的測試停止標準

8.3.2.測試種類

本系統是一個極其復雜的應用系統，因此，在系統投產前的充分測試是保證系統質量和健壯性的最重要手段。按照軟件工程的標準和各項規范，在系統開發過程中，項目組將嚴格執行以下測試工作：

單元測試：單元測試集中在檢查軟件設計的最小單位—模塊上，通過測試發現該模塊的實際功能預訂一改模塊的功能說明不符合的情況，以及編碼的錯誤；

集成測試：集成測試是將模塊按照設計要求組裝起來同時進行測試，主要目標是發現與接口有關的問題。如數據穿過接口是可能丟失；一個模塊與另一個模塊可能有由于疏忽的問題而造成有害影響等；

確認測試：確認測試的目的是向未來的用戶表明系統能夠向預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

數據測試：由于系統大量的數據來源與業務系統，因此，除了對功能進行測試之外，還必須對系統處理的數據進行測試。數據測試的工作包括：對采集進入系統的數據正確性，以及系統加工處理后的數據正確性進行測試。數據測試實際上是對系統的算法和邏輯進行測試。

性能測試/壓力測試，性能測試、壓力測試、以及下面安全測試/恢復測試統稱為系統測試。其中，性能測試是指模擬在最終的運行環境中，用戶使用該系統所得到的響應速度或者系統的處理速度，以及對資源的使用情況；壓力測試則是為了檢查在預定的系統環境中，應用系統正常運行時所能承受的最大壓力邊界，包括：同時并發的最大客戶數，以及同時能夠處理的最大數據量等；

安全測試/恢復測試：安全測試是對系統的安全性是否達到系統設計的目標，某些應用系統對安全要求非常高時，這一測試就顯得很重要了，包括：功能的權限控制、數據的權限控制、應用系統的日志、數據傳輸的加密等；恢復測試則是測試在異常情況下，系統自我恢復的能力，尤其是數據部分的備份與恢復。

8.3.3.測試準備

制定全面、詳盡的測試方案

組織相關的技術人員和業務人員準備測試；

準備測試硬件平臺；

硬件平臺按照應用軟件系統的要求進行適當配置；

網絡系統及配置準備；

準備系統軟件平臺，并進行適當配置；

安裝應用系統，進行應用系統的初始化和配置；

根據測試的類型、程度等的要求，準備測試平臺。

8.3.4.測試方法

從測試手段方面來談，將采用以下類型的測試方法：

模擬實施運行環境與條件進行測試；

組織大量的業務數據進行測試；

從測試類型方面來談，將采用如下測試方法：

白箱測試；

黑箱測試。

8.3.5.測試對象

測試的對象包括以下部分

設計開發文檔測試；

源代碼測試；

構件功能測試；

子系統組裝測試；

應用系統組裝測試；

界面測試；

應用功能度測試；

操作容錯性測試。

8.3.6.測試流程

按照軟件工程的要求，測試工作將貫穿軟件生命周期每一個階段中，從而能夠檢驗各階段的成果是否接近預期的目標，盡可能早的發現錯誤并加以修正。如果不在早期階段進行測試，錯誤的延時擴散常常會導致最后成品測試的巨大困難。

為此，項目組將專門成立測試小組，負責各階段測試方案的設計與實施。在測試過程中，將提交相應的測試文檔，包括測試計劃、測試報告、以及測試過程中的詳細記錄。其中，測試計劃詳細規定測試的要求，包括測試的目的和內容、方法和步驟，以及測試的準則和案例等；測試報告用來對測試結果的分析說明，經過測試后，證實了軟件具有的能力，以及它的缺陷和限制，并給出評價的結論性意見，這些意見即是對軟件質量的評價，又是決定該軟件能否交付使用的依據；而測試過程中的測試內容及結果詳細記錄，將形成《軟件修改報告》。

測試計劃

詳細設計文檔被認證后，制定《測試計劃》，測試計劃需由質量經理、開發經理、設計負責人、測試負責人共同簽字認可。

測試計劃將作為測試工作的依據。

測試計劃的撰寫工作應在系統提交測試前完成。

測試計劃包括代碼審查、規范審查、單元測試、組裝測試、系統測試、回歸測試。

測試設計及測試案例

測試計劃通過認可后，測試人員開始編寫測試設計及測試案例文檔。

根據產品測試計劃制定具體測試設計及測試案例，測試設計及測試案例文檔需經設計負責人及測試負責人共同簽字認可。

測試設計及測試案例文檔的撰寫應在系統提交測試前完成。

測試的設計方法包括邊界值測試法、等價類劃分、功能覆蓋、分支覆蓋。

系統測試

按照《測試計劃》、《測試設計及案例》的要求對系統進行測試。

測試人員應該記錄測試事件，記錄測試日志，并通過測試日志及時與開發人員進行交流，測試日志可作為測試工作進行或停止的依據。

測試過程中如需進行程序修改，則必須暫?；蛲Ｖ箿y試工作。

測試工作暫停、停止、啟動的條件

暫停條件：測試工作是否暫?？捎蓽y試員與開發人員協商決定，暫停時間原則上不能超過兩個工作日。

停止條件：測試工作如無法按照測試計劃正常進行下去，則必須停止，要停止的測試工作必須由測試員出具《階段測試總結報告》并由開發經理認可，在階段測試報告中必須注明再啟動時間，如無法估計時間則必須注明再啟動條件。

系統測試報告

測試報告分為《階段測試總結報告》和《測試總結報告》兩種。其中《階段測試總結報告》主要作為程序修改的依據；《測試總結報告》主要作為系統驗收的依據

測試工作停止時測試人員必須撰寫《階段測試總結報告》，提交開發人員進行程序修改，如修改后無設計變動或變動不大（測試案例仍然可用），可以在產品測試環節內部循環，但必須保留每一次的《階段測試總結報告》。

如《階段測試總結報告》提交后設計變動較大，則應視具體情況決定下一步的測試工作。對于測試案例不可用的情況需要重新制定測試設計和測試案例；對于設計變動影響了測試計劃的可用性的需重新根據詳細設計文檔制定測試計劃。

8.3.7.問題處理流程

一般處理流程:

前提: 當進入系統測試階段,發布第一個測試版本時；按照嚴格測試問題處理流程操作。

版本狀態：

問題單處理流程圖

1、版本初始化:

開發員 ____提交相關代碼

配置管理員 ____給出版本發布計劃,建立測試基線版本(代碼編譯?)

測試經理 ____給出版本測試計劃

2、問題處理流程:

測試員 ____測試員執行測試

|

|___測試員發現問題

|

|___開發人員定位（對于不能確認，或者比較難重現的問題必須步驟）

|

|___記錄詳細測試情況->問題單提交問題測試經理(每個測試工作日)

測試經理 ____對每日提交的問題審核,給出審核意見(每個測試工作日)

|

|___對審核通過的問題->問題單提交給開發經理

配置管理員____對每日提交的問題審核, 給出審核意見(審核描述問題清楚)

|___對審核通過的問題->問題單分配給相關軟件小組長

|___對沒有通過審核的問題->問題單返回測試經理

小組長 ____對每日提交的問題審核, 給出審核意見(評估是否問題)

|

|___對審核通過的問題->問題單分配給相關開發人員

|

|___對沒有通過審核的問題->問題單返回配置管理員

開發員 ____對每日提交的問題審核, 給出問題處理意見(評估是否處理方式)

|

|___修改問題,開發測試

|

|___提交修改代碼到配置庫->問題單返回配置管理員

3、回歸測試版本:

配置管理員____給出版本發布計劃

|

|___對上一版本->所有修改問題提交給測試經理

測試經理____給出新版本測試計劃(一般來說是回歸測試)

|

|___對上一版本->所有修改問題分配給相關測試員進行回歸測試

測試員 ____測試員執行回歸測試

測試經理____給出版本測試總結,評估是否可以發布版本（否則？）。

配置管理員____給出測試問題統計結果；為測試經理版本評估提供統計數據。

重大問題處理流程

在重大問題處理流程上增加開發經理處理流程。由配置管理員直接提交給開發經理，由開發經理對問題做出處理決策。

缺陷處理流程

對于測試和開發沖突問題，或者解決不了的問題，由質量控制小組評審決定是否作為版本缺陷處理。

問題跟蹤表

參考《軟件測試問題跟蹤列表》。

問題處理流程約束

問題處理流程是針對所有測試活動，包括開發和業務人員的測試。在版本受控的情況下，無論是開發還是業務人員測試，所發現的問題，都必須按照問題處理流程，提交變更需求。

9.項目風險分析及控制

項目風險存在于工程項目管理中，由于受到變更，社會，政府，法律，市場及不可預測性等因素影響，我們本著“防范為主、積極回避”的方針，在項目實施過程中對實現管理存在很大差異，因此項目風險管理至關重要。

根據現階段我公司的整體實力，制定風險管理目標：“降低風險管理成本、提高利潤，樹立信譽、擴大影響，拓寬業務渠道”。

本項目將運用風險管理方法以管理項目執行中的各項活動。風險管理計劃將對風險的類型、等級、可見性做出評估，對項目的成功實施至關重要。

隨后應制定備選方案，采取應對措施來防范風險的影響，安排指定負責人應對風險的跟蹤，對風險征兆提前預判，并執行應對措施。風險應對可以是提前進行預防（隨著所執行的活動隨時進行）或特別應對的（風險發生時執行）。

公司與醫院一起同意使用風險評估機制來定義每一個風險項，以日志形式記錄每個風險的分析和應對。項目經理負責維護風險日志。

9.1.風險因素

（1）項目定位

由于本項目系統建設的內容較多，必須明確項目首要目標，合理控制系統范圍，避免“貪大求全”，保證實現最核心的功能系統，同時兼顧未來的發展。

（2）專業配合

專業配合方面既要考慮總集成服務方、專業分包方與客戶方的配合，還要考慮醫學專業與信息專業的配合，以往的項目經驗證明，專業之間的鴻溝很難跨越，而科室和醫護專業人員的配合是應用系統成功的關鍵。

（3）資源配置和人員能力

項目完成后是否能達到期望值，與參與項目人員的經驗、閱歷等有很大關系，人的因素是比較大的風險和困難之一。我公司承諾為本項目配備技術能力強、行業經驗豐富的人員，同時保證項目團隊的穩定性，以保證項目的順利進行。

9.2.風險管理內容

1）項目經理及項目組成員識別風險時機

項目啟動時

項目經理遍歷《組織風險列表庫》，識別出本項目可能存在的風險項，并進行記錄在《風險管理計劃及跟蹤表》中。

項目成員填寫個人周報時

項目成員填寫每周個人周報時，列出個人認為可能存在的風險。

項目召開周例會時

項目經理收集個人周報中項目組成員列出的可能存在的風險，登記在《項目周報中》，供大家在周例會上討論，討論通過后記錄在《風險管理計劃及跟蹤表》中。

項目經理可以擴大周例會的規模，邀請更多的干系人，共同參與識別風險。

項目經理及項目組成員有責任定期或實時重復識別本項目的風險，直到項目結項為止。

2）風險識別方法

選用模型法。建立一個項目風險數據庫，集中軟件開發和項目實施過程中可能遇到的風險，項目經理參照此模型歸納其所負責項目的風險，并且不斷完善風險數據。

3）風險分析

對已經識別出來的風險，項目經理及項目組成員評估每個風險的嚴重性、可能性，計算出風險系數，并按照風險系數從高到低的順序排列風險。新識別的風險及其評估值追加到《風險管理計劃及跟蹤表》中。對于風險系數較大的風險，必須分析其性質及其觸發條件。

為了便于量化管理，我們給風險定義3個參數：

風險嚴重性：指風險對項目造成的危害程度。

風險可能性：指風險發生的幾率。

風險系數：是風險嚴重性和風險可能性的乘積。

4）風險管理策略

1)設定每個已識別風險的初始觸發條件，觸發條件是專業技術人員根據經驗或者是以往項目的參考數據制定的，它是風險啟動的門限值，是風險處理的一個預警信號。當風險的系數超過設定的觸發條件時，風險必須進行處理。

2)風險系數在20以上，必須立即最優先處理，采取處理措施并跟蹤處理直到解決為止；如果無法解決，則形成項目問題上報高層經理。

3)風險系數為10-20之間，也需要采取緩解措施進行處理，同時進行跟蹤；

4)風險系數小于10，此類風險可以酌情確定當前時間是否處理。不處理的，要在以后的風險重復識別中重新評估。

9.3.風險管理流程

項目風險管理流程一般分為風險識別、風險衡量、風險處理與風險防范對策四個階段，各階段及其內容如下圖：

項目風險管理流程示意圖

9.4.風險字典庫

我們在信息質量體系的項目過程標準庫中提供了一個高風險區檢查單，參見下表：

商業風險

風險源 檢查項

政治

法律

市場 政府或者其它機構對本項目的開發有限制嗎？

有不可預測的市場動蕩嗎？

競爭對手有不正當的競爭行為嗎？

是否在開發可能虧本的產品？

客戶 客戶的需求是否含糊不清？

客戶指定的需求和交付期限在客觀上可行嗎？

客戶對產品的健壯性、可靠性、性能等質量因素有非常過分的要求嗎？

客戶的合作態度友善嗎？

與客戶簽的合同公正嗎？雙方互利嗎？

客戶的信譽好嗎？例如按客戶的需求開發了產品，但是客戶可能不購買。

管理風險

風險源 檢查項

項目計劃

項目監控 對項目的規模、難度估計是否比較正確？

人力資源（開發人員、管理人員）夠用嗎？合格嗎？

項目所需的軟件、硬件能按時到位嗎？

項目的經費夠用嗎？

進度安排是否過于緊張？有合理的緩沖時間嗎？

進度表中是否遺忘了一些重要的（必要的）任務？

進度安排是否考慮了關鍵路徑？?

任務分配是否合理？（即把任務分配給合適的項目成員，充分發揮其才能）

項目團隊 項目成員團結嗎？是否存在矛盾？

是否絕大部分的項目成員對工作認真負責？

絕大部分的項目成員有工作熱情嗎？

團隊之中有“害群之馬”嗎？

技術開發隊伍中有臨時工嗎？

本項目開發過程中是否會有核心人員辭職、調動？

是否能保證“人員流動基本不會影響工作的連續性”？

上級領導

行政部門

合作部門 本項目是否得到上級領導的重視？

上級領導是否隨時會抽調本項目的資源用于其它“高優先級”的項目？

上級領導是否過多地介入本項目的事務并且瞎指揮？

行政部門的辦事效率是否比較底，以至于拖項目的后腿？

行政部門是否經常干一些無益于生產力的事情，以至于騷擾本項目？

機構是否能全面、公正地考核員工的工作業績？

機構是否有較好的獎勵和懲罰措施？

本項目的合作部門的態度積極嗎？是否應付了事？或者做事與承諾的不一致？

技術風險

風險源 檢查項

需求開發

需求管理 需求開發人員懂得如何獲取用戶需求嗎？效率高嗎？

需求開發人員懂得項目所涉及的具體業務嗎？能否理解用戶的需求？

需求文檔能夠正確地、完備地表達用戶需求嗎？

需求開發人員能否與客戶對有爭議的需求達成共識？

需求開發人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？

綜合技術能力，包括：設計、編程、測試、評審等 開發人員是否有開發相似產品的經驗？?

待開發的產品是否要與未曾證實的軟硬件相連接？

對開發人員而言，本項目的技術難度高嗎？

開發人員是否已經掌握了本項目的關鍵技術？

如果某項技術尚未實踐過，開發人員能否在預定時間內掌握？

開發小組是否采用比較有效的分析、設計、編程、測試工具？

分析與設計工作是否過于簡單、草率，從而讓程序員邊做邊改？

開發小組采用統一的編程規范嗎？

開發人員對測試工作重視嗎？能保證測試的客觀性嗎？

項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？

是否對所有重要的工作成果進行了同行評審（正式評審或快速檢查）？

開發人員懂得版本控制、變更控制嗎？能夠按照配置管理規范執行嗎？

開發人員重視質量嗎？是否會在進度延誤時降低質量要求？

風險識別與控制是項目跟蹤與監控的重要目的之一，跟蹤項目過程必須具備兩點要素：

（1）找出潛在的問題以預防他們發生；

（2）在出現嚴重危害前，準備好修復計劃。

本項目將運用質量體系提供方法與手段，對風險進行有效的管理。

風險識別策略

參照公司標準的高風險區檢查單，定期跟蹤檢查這些風險項，識別本項目存在的潛在風險，列出高風險區清單；

指定有經驗的人員對項目風險進行評估，確定風險大小及嚴重性；

定期跟蹤高風險區的變化情況，包括風險度量值的變化。

風險量化管理策略

風險管理采用量化管理，度量風險大小及嚴重性采用以下度量因子；

風險嚴重性（用LEVEL表示）：以進度延誤偏差率或成本超支率為度量值；

風險可能性（用CHANCE（%）表示）：以經驗判斷百分值為度量值；

風險系數（用RATIO表示）：指風險對項目成功實施帶來的威脅性，以RATIO = LEVEL×CHANCE（%）為度量值；

風險閾值（用THRESHOLD表示）：指對風險應該采取的戒備程度，根據風險系數值的大小，依次定義風險閾值為：警報、警戒、觀察、忽略；

項目風險指數（用DEFEAT表示）：指項目失敗的可能性。項目風險指數為風險系數大于IGNORE的各項風險系數之和DEFEAT = ∑RATIO

風險控制策略

當風險閾值為警報、警戒時，及時與風險源相關方討論制訂風險緩解計劃；

跟蹤風險緩解計劃實施情況；

及時組織資源進行風險控制；

風險緩解計劃實施各相關方或相關人員定期進行溝通；

及時通報項目組、用戶方及其他相關方的上層領導，進行相關協調工作。

9.5.項目變更管理原則

項目實施過程中，變更的發生是難免的，但對變更要加以管理，防止變更失控而帶來不可預見的風險影響。當需要對范圍、需求或進度進行變更時，填寫正式的變更單，雙方對變更內容進行評估后將變更導致的時間、成本等方面的變化進行說明。若雙方接受變更的帶來的影響則可以進行變更，否則變更不能進行。對不同類型的變更可以采用不同的控制方法，減少由于項目變更帶來的風險影響。

變更流程如下圖

微小變更：對流程有影響，對進度和資源無影響

1、項目團隊對變更進行討論，確認變更的必要性和可行性；

2、填寫變更記錄單，對變更的原因和討論結果加以記錄；

3、實施變更；

4、將變更提交項目指導委員會。

顯著變更：對項目進度和資源有影響

1、項目團隊對變更進行討論，確認變更的必要性和可行性；

2、填寫變更記錄單，對變更的原因和討論結果加以記錄；

3、評估變更影響的程度，并由專家組給出評審意見；

4、提交項目委員會，確定是否接受變更帶來的影響，包括估算項目功能、時間表、預算、以及預算的影響。由項目委員會做出是否同意該變更的執行；

5、對項目計劃和需求文檔進行調整并通知相關部門；

6、實施變更。

10.項目實施重點、難點分析?

根據我司多年信息化云平臺項目實施經驗，以本次招標使用需求及建設目標為準繩，結合目前南陽市第二人民醫院信息化平臺應用及運行情況，分析出本項目的實施重點與難點高度統一吻合，即實施重點即難點，難點即重點，主要包括以下幾點：

(一) 現總院信息化平臺基礎一般，原所部署信息化系統第三方廠商數量較多，這就要求本次信息化云平臺建設需以系統集成平臺為核心，替換或者集成院內各個異構的軟件系統，同時達到面向發展、方便集成以及與遠程、社區、區域系統資源共享的目的。實現一院多區、信息共享的建設要求。其實施難點主要為各廠商之間的協調，本項目在建設期間涉及到多個業務系統之間的對接，由于來自不同的廠商（見下表），在問題對接時難以及時進行有效的配合，難以快速完成與業務系統之間的對接。

（二）完成《電子病歷系統應用水平分級評價標準》6級評審工作。

（三）完成《醫院信息互聯互通標準化成熟度測評》5級乙等評審工作。

（四）各科室之間的協調以及對需求的管控，在上線期間，由于涉及到全院大部分科室，科室與實施人員之間的協調難度較高，難以要求所有科室對系統上線時做到高效的配合。難以對臨床科室對于需求的多變性，不準確性的把控，無法快速完成科室所提需求。

10.1.系統集成（重點、難點一）解決方案

10.1.1.系統集成概述

考慮到本項目的復雜性、多樣性，我公司作為集成商開展工作，承諾承擔以下信息系統集成內容：

制定集成計劃，明確集成范圍，并協同廠商開展集成開發工作；

開展信息集成平臺產品的培訓、實施、運維。

本次擬采購系統、醫院保留的信息系統與信息集成平臺的數據集成、業務集成，需求書中保留信息系統的改造以及區新增系統的數據集成、業務集成。

我公司承諾在項目組中單獨成立系統集成管理小組，用來開展項目管理標準化、數據標準化、服務標準化、業務流程標準化等工作，并形成統一用戶管理集成規范、醫院信息交換和信息系統集成規范等若干套標準和規范。

為指導第三方系統實現集團醫院業務支撐，并形成分別面向集團醫院建設的信息系統開發實施規范，指導第三方系統廠商的集團化業務改造。

我公司承諾在項目組中單獨成立系統集成管理小組，用來開展數據標準化、主數據同步，并形成集成規范，響應如下：

信息集成平臺軟件設計嚴格執行國家有關軟件工程的標準，保證系統質量，應用設計符合國際、國家、醫療衛生行業有關標準、規范和醫院自身的發展規劃。

信息集成平臺設計方案立足先進技術，采用先進的設計理念、技術路線和技術體系架構。

可以跨平臺運行，承諾使用通用的大型數據庫例如：SQLSERVER、ORACLE、CACHE，本項目我方采用的是ORACLE 12G以上版本

系統集成達到推進接入系統遵循面向服務的架構設計，能合理界定系統集成邊界；實現醫療服務信息全面的消息交互集成模式，支撐CDR的建設；提供完善的SOA服務治理方案，實現費用管理服務在非HIS系統中的覆蓋；支撐集團醫院醫療共享業務中心的建成。

系統集成能達到建立科學的管理體系，建立檢查、檢驗、輸血、手術、ADT、靜配、體檢、報告、危急值等業務流程規則；建設知識管理網站共享發布集成設計文檔，集中管理需求提交和實施反饋；建設工作流管理項目，所有需求提交、開發方案、測試和BUG修復均實現全程工作流管理；建立涵蓋集成前、中、后的全程項目管理模式。

系統集成能建立一套完善的集團化信息系統建設和改造的實施指南和技術標準，建立基于HL7 V2、HL7 V3、DICOM、IHE、ICD-10、LOINC、PDF、HL7 CDA等綜合的標準協議集并推進所有成員系統強制使用；建立覆蓋患者管理、患者導引和呼叫、醫囑、檢查、檢驗、病理、手術、護理、資源安排等領域的HL7本地化版本。

信息集成平臺系統能提供完善的操作日志與錯誤日志，操作日志要求記錄所有的基礎數據、基本字典、參數、授權的維護與修改操作，以及系統中所有關鍵操作及不成功的操作。

本項目采購的信息集成平臺產品我公司承諾與現有已經成熟運行并保留的系統進行集成（應用集成、數據集成、），且實現互聯互通；

我公司提供第三方廠商的集團醫院信息系統集成規范，并指導參與成員，應規范化各系統的建設、對如何部署、如何組織結構、需要如何改造等方面進行指導。

我公司承擔集成管理、項目協調、培訓相關工作。

項目集成管理小組工作具體內容：

我公司承諾將組成集成管理小組參與到信息處日常工作中，總體目標是最終實現協助信息處對業務系統供應商人員管理、后續產品選型、業務系統項目管理、業務流程與需求管理以及業務系統測試管理等工作綜合管理。

與信息處一起制定工程的詳細實施計劃、各分項工作的進度安排；

制定各廠商的職責分工、廠商之間的協調機制和流程；

制定實施的各項流程、規范和質量標準等；

制定各項工作的測試方案、驗收標準、驗收流程，協助信息處制作測試報告、驗收報告的標準模版；

審核各廠商的技術方案與最終使用產品符合度；

按照事先制定的質量標準，指導、管理各廠商的工作，把好質量關；

協調各廠商之間的配合工作；

組織每周定期的項目例會，及時通報項目進展情況，就項目中的問題進行溝通和處理；

以項目周報的方式將項目的最新進展及時通報給信息處和各廠商；

當項目進展發生變更時，配合信息處制定應對措施，并將變更及時通知項目相關各方；

對廠家實施人員進行效能評估、及時報告和提出更換低效的廠家現場人員；

配合信息處對各子系統進行測試，并形成規范的測試報告；

對業務模式進行評估，流程框架做分析梳理；

結合項目的進行，通過良好的項目管理和日常工作交流，并對信息處的項目成員進行知識轉移；

對項目進行風險評估、提出對應措施；

管理和監督廠家、確認項目交接工作；

針對患者信息安全和隱私保護提出有效的實施建議方案，并協助廠商改進系統數據安全性和強化數據使用審計機制。

文檔資料管理

文檔是保證項目的實施連貫性的重要保證，要提供完善的文檔，并對項目進行過程中的文檔進行有效的管理，接受用戶方對各階段評估分析和監督管理。

整個過程貫穿ISO9001和CMMI5的規范，使用國家標準碼，提供齊全的項目管理、設計和測試、操作說明等書面文檔和電子版。

10.1.2.系統集成工程化管理

基于信息集成平臺的第三方系統集成，是本項目建設的核心訴求之一，通過平臺化的集成，在IHE、DICOM、HL7等國際標準的基礎上，制定覆蓋醫療所有業務流程的系統集成規范。開發基于規范的系統集成平臺，為遺留的以及未來的系統提供了一個統一標準的數據交換、“微服務”調用和工作流協同的平臺。

盛博匯公司成立之初，就致力于開展醫療行業的總包總集成服務，經過多年的集成實施經驗總結，制定了圍繞平臺化開展標準集成的實施規范標準。完成了《集團化信息系統實施與集成入場指南》、《集團化管理統一用戶授權管理系統集成指南》、《集團化信息系統實施指南》三個重要的集成工作指導性規范。依此規范實現了以患者電子病歷的信息采集、存儲、交換和集中管理為基礎，實現集團各院區內部不同業務信息系統之間的統一集成、互聯互通、業務協同、信息整合和信息共享；并支持跨機構醫療信息共享和業務監管的功能擴展，支持與上級平臺實現可靠的信息交換（包括電子健康檔案、電子病歷等信息交換共享和跨機構醫療業務協同）。

10.1.2.1.總則

系統集成項目流程共分為五大過程和11個實施階段，如下圖所示：

10.1.2.2.啟動過程

基于前期需求調研完畢后，根據調研的系統情況整理集成需求形成集成需求規范并以此完善集成標準手冊。

第一階段：成立項目組。進行任務分解，明確項目組成員職責。這是系統集成項目的第一個里程碑節點。集成項目組一般由如下相關人員組成：

名稱 職務 聯系方式 其它

醫院信息中心 總協調

技術支持

網絡支持

集成方（盛博匯公司） 項目經理

組長

集成負責人

集成技術人員

第三方公司A 接口開發

現場實施

10.1.2.3.計劃過程

第二階段：制定計劃。根據合同要求，制定項目實施計劃，確定進度安排，計劃一般將分為集成規范培訓、集成研發、聯調測試、集成聯調、空轉測試、集成驗收幾個大流程節點。

第三階段：計劃評審。這是系統集成項目的第二個里程碑節點。評審未通過的，返回第二階段，對計劃進行修訂。

10.1.2.4.執行過程與控制過程

第四階段：集成規范培訓。在建設方現場和信息中心、第三方廠商講解集成思想和集成規范概要，集成培訓期間將完成如下幾項工作：

集成規范的講解及文檔下發；

集成廠商通訊錄建立及統一項目管理賬號分配；

集成相關資料收集；

集成管理制度下達（給信息中心一套標準化項目管理的方案建議）

第五階段：集成研發。各廠商根據集成規范進行接口研發，各公司遇到問題及時與信息中心及集成方進行溝通解決。信息中心可以采取項目周會、周報制度對項目進度盡心及時監控，周報包含但不限于如下方面：已完成內容、下周計劃工作內容、需要協調事項：

第六階段：聯調測試。開發階段聯調測試，在第三個里程碑時間節點，所有廠商到醫院現場進行聯調測試，集成方和信息中心聯合制定聯調計劃并記錄問題并給出詳細的聯調測試結果，如下為計劃和測試結果范例：

第七階段：安裝調試。各廠商根據自己的軟硬件要求，安裝部署由院方提供的生產環境。

第八階段：集成調試。這是系統集成項目的第四個里程碑節點。聯調測試只是廠商之間兩兩接口調試的過程，集成調試將完成所有廠商之間的大流程測試，如：醫囑的開立、收費（預約）、執行（醫技執行+分診叫號等）、報告等醫囑閉環流程。

10.1.2.5.結束過程

第九階段：生產空轉。為了保障系統能完善穩定的運行，集成調試后將組織所有廠商在生產環境用測試賬號進行全流程測試，用真實用戶和真實基礎數據進行最后一輪驗證。

第十階段：系統驗收。

第十一階段：項目結項。這是系統集成項目的第五個里程碑節點。由項目經理提交項目結項申請，報公司領導審批。

系統集成項目結項后，要進入實施轉運維接口，向公司項目管理委員會提交運維申請和項目技術文檔以保證后續系統持續穩定運轉。

10.1.3.新建與利舊系統集成

10.1.3.1.概述

根據醫院管理要求，針對現有使用情況良好的專業系統，予以保留，在利舊過程中，需要基于集成平臺，實現基于統一集成接口服務的對接模式，在接口通訊方式方面，將通過統一標準和通用的交互方式開展。

10.1.3.2.實現

現有醫院的信息化建設，都已經建成了一些信息系統，如常用的PACS、超聲等信息系統，均已通過原有的集成方式，如數據庫直連，中間表等方案對系統之間的信息集成進行了初步的對接連接，實現初步的信息共享。在這樣的情況下，要上線集成平臺時往往會出現一些情況，從系統切換的角度出發，來說明系統切換的實施步驟與方案。

場景一

主要的步驟如下：

確定新的集成方案；

討論是否需要進行業務流程的調整；

基于新業務流程、新集成方案，確定集成規范文檔；

雙方根據集成規范進行開發；

在開發完成后，需搭建與真實環境基本一致的聯調測試環境進行驗證走通；

確定切換時間；

將測試環境遷移到正式環境中，遷移完成后，小部分業務開始圍繞新集成環境集成，采用兼容方案；

小部分業務出現的問題進行排查解決；

擴大試點范圍直至全院；

完成問題修復與上線報告，完成上線。

10.1.4.第三方系統集成規范

擬提供的第三方廠商的集團醫院信息系統集成規范，舉例如下

10.1.4.1.PACS（含超聲、內鏡等）

工作流程

1、醫囑下達者申請流程-住院

說明：上圖為醫囑下達者對住院患者開檢查醫囑的申請流程。第一步：由醫護終端下達醫囑（申請單），集成平臺被觸發并發送病人信息(ADT^A01)，得到PACS響應后再發送檢查申請信息(ORM^O01(ORC-1=NW))，并得到PACS響應檢查申請消息；第二步，在PACS工作站上完成病人預約安排，并將預約通知消息（SIU^S12）發送到集成平臺，集成平臺給出消息響應，集成平臺將消息推送到醫護終端，供其查看預約情況；第三步，病人開始檢查后，PACS系統發送ORM^O01（ORC-1=SC,ORC-5=SC）表示檢查已經開始，PACS系統發送ORM^O01（ORC-1=SC,ORC-5=CM）表示檢查結束，PACS系統發送ORM^O01（ORC-1=SC,ORC-5=DA）表示已完成圖像匹配；第四步，PACS發送計價信息(DFT^P03)，集成平臺返回響應ACK，并將檢驗計價信息發送到HIS計價系統，HIS返回確認信息；第五步，PACS返回檢驗結果初步報告 (ORU^R01 初步報告OBR-25=P)，集成平臺返回響應ACK，并查詢和修改醫囑系統中的檢查狀態；PACS返回檢驗結果確認報告 (ORU^R01 Z最終報告OBR-25=F)，集成平臺返回響應ACK，并查詢和修改醫囑系統中的檢查狀態。

2、醫囑下達者申請流程-門診

說明：上圖為醫囑下達者對門診患者開檢查醫囑的申請流程。

3、醫囑下達者作廢申請流程

說明：上圖為醫囑下達者作廢申請的流程。

4、醫囑執行者申請流程

說明：上圖為醫囑執行者申請檢驗流程。

5、醫囑執行者作廢申請流程

說明：上圖為醫囑執行者作廢申請流程。

狀態約定

狀態值 狀態名稱 說明

0 申請中 新開的申請初始狀態為0；

1 申請成功 外圍系統收到申請后，集成平臺更新EMR申請狀態到申請成功

C 申請失敗 由于一些技術或者業務原因，檢查申請信息在到達對方系統后或者一直未到達對方系統，導致消息重試次數超限制，該狀態在EMR中被標記為申請失敗

D 作廢中 由EMR主動發起的作廢申請請求

6 作廢成功 外圍系統收到作廢申請，并進行作廢操作反饋操作成功后，EMR將該狀態更新為作廢成功

E 作廢失敗 由于一些技術或者業務原因，檢查申請作廢消息在到達對方系統后或者一直未到達對方系統，導致消息重試次數超限制，該狀態在EMR中被標記為申請失敗

7 已預約 當外圍系統進行醫囑的預約，并反饋時，EMR保存該狀態。

8 已到檢 收到申請后，收到申請后將狀態設置成8，不能被取消。

通過集成平臺主動查詢獲取申請需要調用狀態更新接口，以避免下次再次提取到該申請單，通過集成平臺接口可將狀態重新更新為申請中；

通過HL7集成，不需要馬上回復ORM^O01(SC)到檢狀態，可在真正到檢時回復。

2 已執行 說明檢查已經執行，不能被取消，不能被回退到申請中；

注意：外圍系統無需調用更新狀態接口將申請單狀態更新到該值，在進行檢查影像提交時，會自動判斷狀態，并進行更新

3 初步報告 已生成初步報告，不能被取消；

注意：外圍系統無需調用更新狀態接口將申請單狀態更新到該值，在進行檢查報告提交時，會自動判斷報告狀態，并進行更新

4 確認報告 報告已確認，不能被取消；

注意：外圍系統無需調用更新狀態接口將申請單狀態更新到該值，在進行檢查報告提交時，會自動判斷報告狀態，并進行更新

接口列表

此處羅列所有的接口名稱，具體的HL7接口規范

HL7 2.4 ADT^A01住院病人信息接口（集成平臺發送，PACS接收）

HL7 2.4 ADT^A04門診病人信息接口（集成平臺發送，PACS接收）

HL7 2.4 ADT^A08患者更新接口（集成平臺發送，PACS接收）

HL7 2.4 ORM^O01（NW）新建醫囑接口（集成平臺發送，PACS接收）

HL7 2.4 ORM^O01（CA）HIS端醫囑作廢接口（集成平臺發送，PACS接收）

HL7 2.4 ORR^O02，響應ORM^O01（SN）消息（集成平臺發送，PACS系統接收）

HL7 2.4 ORM^O01（SC）醫囑狀態確認接口（PACS發送，集成平臺接收）

HL7 2.4 SIU^S12預約通知接口（PACS發送，集成平臺接收）

HL7 2.4 ORU^R01報告返回接口（PACS發送，集成平臺接收）

HL7 2.4 DFT^P03計費信息接口（PACS發送，集成平臺接收）

10.1.4.2.LIS

工作流程

醫囑下達者申請流程-住院

說明：上圖為醫囑下達者對住院患者開檢驗醫囑的申請流程。第一階段：由醫護終端下達醫囑（申請單），集成平臺被觸發并發送病人信息(ADT^A01)，得到LIS響應后再發送檢驗申請信息(OML^O21(ORC-1=NW))，并得到LIS響應檢驗申請((ORL^O22)Accept:ORC-1=OK Unable Accept:ORC-1=UA)；LIS改變檢驗申請狀態，并將修改檢驗狀態消息 (OML^O21(ORC-1=SC))發送到集成平臺，集成平臺返回響應(ORL^O22)ORC-1=OK，并查詢和修改醫囑系統中的申請單狀態。第二階段：LIS返回檢驗結果初步報告 (OUL^R21 初步報告OBR-25=P)，集成平臺返回響應ACK，并查詢和修改醫囑系統中的檢驗狀態；LIS返回檢驗結果確認報告 (OUL^R21 確認報告OBR-25=F)，集成平臺返回響應ACK，并查詢和修改醫囑系統中的檢驗狀態；LIS發送計價信息(DFT^P03)，集成平臺返回響應ACK，并將檢驗計價信息發送到HIS計價系統，HIS返回確認信息。第三階段：LIS返回檢驗結果修改報告(OUL^R21 修改報告OBR-25=C) ，集成平臺返回響應ACK，并查詢和修改醫囑系統中的檢驗狀態。流程完成。

醫囑下達者申請流程-門診

說明：上圖為醫囑下達者對門診患者開檢驗醫囑的申請流程。

醫囑下達者作廢申請流程

說明：上圖為醫囑下達者作廢申請的流程。

醫囑執行者申請流程

說明：上圖為醫囑執行者申請檢驗流程。

醫囑執行者作廢申請流程

說明：上圖為醫囑執行者作廢申請流程。

狀態約定

狀態值 狀態名稱 說明

F 申請中 新開的申請初始狀態為F；

1 申請成功 外圍系統收到申請后，集成平臺更新EMR申請狀態到申請成功

C 申請失敗 由于一些技術或者業務原因，檢驗申請信息在到達對方系統后或者一直未到達對方系統，導致消息重試次數超限制，該狀態在EMR中被標記為申請失敗

D 作廢中 由EMR主動發起的作廢申請請求

6 作廢成功 外圍系統收到作廢申請，并進行作廢操作反饋操作成功后，EMR將該狀態更新為作廢成功

E 作廢失敗 由于一些技術或者業務原因，檢驗申請作廢消息在到達對方系統后或者一直未到達對方系統，導致消息重試次數超限制，該狀態在EMR中被標記為申請失敗

0 生成條碼 當外圍系統對檢驗申請進行條碼打印后，反饋該狀態

8 標本核收 收到申請后，收到申請后將狀態設置成8，EMR不能再作廢檢驗申請。

A 標本登記 LIS系統進行標本登記時，即：開始檢驗前，反饋該狀態

2 已執行 說明檢驗已經執行，不能被取消，不能被回退到申請中；

檢驗系統在檢驗已經執行完成后反饋該狀態

3 初步報告 已生成初步報告，不能被取消；

4 確認報告 報告已確認，不能被取消；

接口列表

此處羅列所有的接口名稱，具體的HL7接口規范

HL7 2.4 ADT^A01住院病人信息接口（集成平臺發送，LIS接收）

HL7 2.4 ADT^A04門診病人信息接口（集成平臺發送，LIS接收）

HL7 2.4 OML^O21(NW)檢驗申請接口（集成平臺發送，LIS接收）

HL7 2.4 OML^O21(SC)檢驗狀態變更接口（LIS發送，集成平臺接收）

HL7 2.4 OML^O21(CA) 醫囑下達者作廢申請接口（集成平臺發送，LIS接收）

HL7 2.4 OML^O21(SN) 醫囑執行者下達醫囑接口（LIS發送，集成平臺接收）

HL7 2.4 OML^O21(OC) 醫囑執行者作廢申請接口（LIS發送，集成平臺接收）

HL7 2.4 DFT^P03計費信息接口（LIS發送，集成平臺接收）

HL7 2.4 OUL^R21檢驗報告返回接口（LIS發送，集成平臺接收）

HL7 2.4 ORL^O22檢驗響應信息（集成平臺發送，LIS接收）

HL7 2.4 ACK響應消息（集成平臺發送，LIS接收）

10.1.5.集成工作規劃流程

集成工作規劃是在合同簽訂后，與院方項目負責人就集成工作的開展確定工作原則、流程、職責，并作出總體工作計劃。

1. 確定集成范圍

合同簽訂后，集成組首次進場，應向醫院提供總體業務集成咨詢，了解院方關于對多系統協同工作的期望，并盡早請醫院確定集成范圍；

2. 確定集成工作職責和流程

集成工作的順利推行，需要信息科、各診療/管理科室、我方及各第三方廠商密切配合，共同完成。任何一方對工作支持不力，均會導致集成工作進展緩慢。

在集成組首次進場后，必須取得院方的支持，就各方協同工作的職責和流程達成一致，并作為以后工作的指導方針。

3. 集成規范確定

集成組應當與院方明確對接的接口規范，應以我方提供的全院級集成規范為準，因我方有多個項目驗證的標準接口，且為了保障項目進度和接口的規范性，不可能為每一個第三方廠商定制開發接口。

4. 集成總體計劃

分析院方的期望，根據醫院業務需求、項目工期和集成組人力資源，劃分輕重緩急，形成集成總體工作計劃，明確廠商進場時間、集成對接時間、系統聯調時間和完成時間。

5. 撰寫集成工作總體規劃

將上述工作成果，形成《集成工作總體規劃》文檔，發送給廠商確認，并在隨后工作中，提醒各方按照此文檔確定的精神，開展工作。

10.1.6.集成對接流程

1. 分析情況和了解需求

1) 了解廠商的合同情況；分析是否屬于合同范圍內、廠商對本項目的態度和策略、廠商技術人員的經驗和實力、廠商在院方的背景和關系等，并登記《集成平臺項目情況匯總表》；

2) 第三方業務系統應當與醫院職能科室確定了其業務需求范圍和流程（包括跨院區方案、多廠商協同工作的完整業務流程等），嚴禁在第三方廠商功能需求尚未明確時就直接展開對接，這意味著一旦第三方廠商功能的增加或流程改變，導致集成工作大量的增加。對于某些業務流程，必要時可與第三方廠商和業務科室一起調研需求、討論集成細節，這些流程包括但不限于：

a) 標準的集成規范落地比較困難的業務流程：輸血、Ouivas、體檢、急診、血透；

b) 初次對接的業務流程或者尚未成熟的集成規范；

3) 集成組聽取第三方廠商對其軟件支持的業務流程的詳細描述，分析特異性需求，注意區分偽需求，把握到業務的真實本質，防止需求泛濫。

4) 廠商培訓包括不限于以下內容：

a) 廠商初次接觸時，明確集成工作的職責、業務流程和關鍵點（以我方提供的集成規范為準，不根據廠商需要，定制接口）；

b) 集成規范的解讀

c) 代碼的開發樣例（按照HL7官方包方式去解析，避免逐字逐句的解析）

d) 聯調工具使用

2. 方案制定

1) 集成組提供標準集成方案（同時，在本項目svn集成空間備份），請第三方廠商評估對接流程圖和接口標準規范，形成對接方案，并請醫院信息處和第三方廠商代表簽字確認（以會議紀要的形式）

2) 后期因第三方系統功能需求，要求修訂接口均視為需求變更，應按需求變更流程處理；

3) 如需要研發新接口，應提交到集成規范負責人，討論通過后，協調研發完成。

3. 環境配置

廠商進場配置，即使用Confluence管理第三方廠商，包括：配置集成通訊錄、Confluence集成賬戶、系統集成標識等，提供廠商培訓視頻；

4. 集成計劃與跟蹤

1) 廠商所提交的集成工作計劃，必須要滿足集成總體規劃的要求（如不滿足，則提示重新給出計劃，必要時提請院方介入），且集成組應當注意適當分配工作，嚴禁將所有的工作都放在上線前完成；

2) 集成主管應至少每周更新集成周報，并發送給建設方負責人、主要聯系人以及項目經理，抄送給交付部集成部門領導，格式參見《項目周報（匯總）》。

5. 對接聯調

1) 提供必要的技術指導，完成對接聯調；

2) 多系統聯調：以完整的業務流程（包含異常和分支流程）為依據，將相關的HIS、EMR、多個第三方廠商業務系統串聯調試。（注意：業務線完整后，立即開始多系統聯調，而不是等待上線前。）

6. 集成驗收

集成驗收按先后順序分為：集成工作確認、業務流程驗收及總體驗收

1) 集成工作確認（可選）

第三方廠商完成集成對接后，要求集成組給出驗收報告。此時集成組應與院方一起，使用《集成工作確認單》，對第三方廠商的工作進行確認，即已初步完成某些工作，但不能涉及驗收字樣。

另：系統上線后，集成組應請示項目經理，是否就集成組的工作，要求院方簽訂《集成工作確認單》。

2) 業務流程驗收（必做）

業務流程驗收應至少同時滿足以下三個條件：

a) 第三方廠商所涉及的所有業務線均已通過多系統聯調；

b) 業務流程上線一個月經過生產驗證；

c) 業務流程無遺留問題且業務科室也無新需求。

此時，院方、集成組和第三方廠商一起完成業務流程驗收，三方在《集成業務驗收單》上簽字。

3) 總體驗收（可選）

項目進入驗收階段，集成組應根據項目經理的統一安排，提供所有已簽訂的《集成業務驗收單》，請院方就集成組的整體工作做一次確認，形成《集成總體驗收單》，并把此材料作為項目的驗收材料。

10.1.7.重點注意事項

10.1.7.1.問題處理及集成規范維護流程

1. 由集成組提交的問題，其執行跟蹤（包括需求、issue提交、方案、計劃、變更單簽訂、發版的跟蹤、集成測試、客戶確認等）由集成組負責。如在此過程中，需要項目組其他人員參與，集成組應提前安排，取得工作承諾并跟蹤；

2. 集成組應密切注意issue的變動，及時協調任務的下一個責任人完成，促進工作進展。

3. 集成組在項目現場，可能因現場情況的不同，會產生不同的集成方案。且集成部門應及時將現場集成方案進行歸納和總結，補充或修訂集成規范。

10.1.7.2.執行要點

在項目集成工作開展過程中，以下幾個關鍵點需要把控：

1、基礎：集成工作的職責、流程和集成工作的總體規劃

2、核心：集成方案的制定直接關系到工作目標的達成，要求集成方案一經確定，即不可更改。如需更改，則應提請《工作變更單》；

3、原則：以已確定的集成規范為準，項目組要把握好一個度：既不盲目答應第三方廠商或客戶的需求，又要吸收合理需求豐富集成規范；

4、重點：把控總體進度，協調醫院、第三方廠商以及研發配合工作。

a) 醫院的商務進度慢，可采取的手段包括但不限于：項目組每周周報向院方匯報（包括何時進場、集成耗時）；項目組每周至少向院方反饋商務緩慢已影響項目總體進度；對于無法滿足上線要求的，項目組提交到公司，由公司發文通知院方；

b) 第三方廠商進度慢：廠商入場培訓后，應提交工作計劃且計劃必須符合上線要求；第三方廠商應每周向包括院方和我方在內的相關干系人提交周報；廠商第一個接口我方可提供聯調測試，其他接口按確定的集成規范一次性開發完成后再聯調，避免廠商研發一個聯調一個的情況發生；

c) 項目組：及時與項目開發經理一起跟蹤研發進度（JIRA跟蹤計劃執行），確保研發按期按質完成接口調整，防范研發進度滯后帶來的風險；及時進行集成規范整理，跟蹤集成方案和對接接口的成熟度；

10.2.電子病歷6級評審（重點、難點二）解決方案

10.2.1.項目組織與分工

10.2.1.1. 項目領導/指導團隊

由院方信息科領導和公司領導組成。

職責：聽取項目匯報，對項目進行總體規劃和提出指導性意見，決定項目期間的原則性、方向性問題，為項目的順利執行提供資源保障。

10.2.1.2.院方（信息科）

由信息科成員組成。

職責：

1.研讀《電子病歷系統應用水平分級評價標準（試行）》、《電子病歷系統應用水平分級評價管理辦法（試行）》2018修訂版文件，對比評分條件，分析醫院信息化總體建設情況，并提出改造意見，具體包括：平臺硬件基礎設施、網絡及網絡安全情況、業務應用系統（生產系統）建設情況、應用建設情況及利用情況。

2.識別項目缺失的軟件系統、軟件功能，并規劃功能、采購、上線以及工作協調；

3.協調各第三方業務系統，包括檢查、檢驗、手麻、護理、急診、病案等，按照《電子病歷系統應用水平分級評價標準（試行）》對齊標準；

4.協調醫務科、護理部等，推進院方流程方案落地以及軟件的改進；

5.其他需要信息科參與的工作。

10.2.1.3.項目經理（研發實施組）

由我方人員擔任。

職責：

1.根據電子病歷六級的總體時間節點要求，給出項目的總體工作分解及安排；

2.對比電子病歷六級評級指標，組織專家、研發技術人員、現場項目管理人員，分析現場情況，討論并得出技術解決方案，并安排人員進行研發和實施；

3.根據項目進度，協調項目組組；

4.識別項目風險，對項目風險進行評估，并及時向項目領導、指導團隊反饋，尋求支持，得出解決方案；

5.其他需要研發實施組參與的工作。

10.2.1.4.其他業務系統

由各業務系統技術人員擔任。

職責：

1.按照《電子病歷系統應用水平分級評價標準（試行）》對齊標準，進行必要的功能補充和調整；

2.識別項目技術方案細節內容和缺項，并及時反饋，以期得到解決；

10.2.2.工作流程

10.2.2.1.1電子病歷六級建設總體流程

11.2.2 電子病歷六級建設注意事項

序號 事項 詳述 注意事項 時間節點

1 分析醫院現況 1）醫院現在電子病歷應用水平，是否有過評級，將要評幾級，對接的第三方系統；

2）醫院的電子病歷評級計劃，了解醫院的訴求；

3）根據公司以往項目的過級情況，評估現過級醫院的時間節點； 1）申報的工作的時間節點慣例是在年底進行，如2018的申報是在2018年年底，2019年測評。

2）醫院以往未申報過評級，可以直接申報五級，但不能超過五級，直接申報五級的醫院，需要經過省級初審之后才能進行國家級評審。五級以上需要逐級申報。 在未申報前做評級準備

2 準備文審資料 1）醫院確定過級等級，確定該級選擇項滿足的條目，不能少于評級的最低要求；

2）院方、廠商熟悉評級標準、評級要求，廠商自評各自系統功能是否滿足要求；

3）根據確定的級別準備基本項、選擇項、數據質量三份說明材料；

4）在整理說明材料時，不滿足要求的點進行匯總，總結醫院達到評級要求的差距。

5）不滿足要求的點，需要院方與廠商共同協商方案，并且提供材料說明，包含功能截圖。 1）在準備文審材料評估醫院的評級差異，評級標準不能從確定的級別進行核實，需要從3級開始到評級的級別一并核實。考量的是評級的級別以及之前的低級別都需要滿足要求。

2）一般在進行評級申報前一個月準備文審材料。 一般在進行評級申報前一個月準備文審材料

3 網上申報 醫院訪問http://sjzx.niha.org.cn進行注冊，填寫醫院基本信息注冊后提交平臺審核，審核通過后會通過填寫的電子郵箱告知進度。 醫院可以提前注冊賬號，在規定的時間進行評級申報。 申報的工作的時間節點慣例是在年底進行，如2018的申報是在2018年年底，2019年測評。

4 1）院方使用注冊的賬號登陸http://sjzx.niha.org.cn，分別填寫基礎數據、EMR數據、數據質量評估，數據上報后平臺給出自評級別評定；

2）上報成功后根據平臺評定的級別，如果已經達到醫院的評級目標，則可以進行后續的準備工作；如果沒有達到醫院的評級目標，在評價平臺資料下載，下載數據修改申請書 在數據未填寫完整時切忌提交上報，數據上報之后只有一次修改的機會。

5 提交文審材料 1）提交文審材料：基本項、選擇項、數據質量三份說明材料需要轉換為pdf文件上傳到平臺；

2）數據提取列直接在平臺上填寫統計數據。

3）高級別（5級及5級以上）的醫院，之前未進行過評級，第一次可以申報五級，但不能超過五級，并且需要經過省級初審。省級初審通過之后才進入國家級資料審核。之前已經評級過四級或者更高級別的醫院直接進入國家級資料審核。 1）文審資料：基本項、選擇項、數據質量三份說明材料要求以pdf格式上傳的電子病歷分級評價平臺。

? 一般在評審當年的2月初

6 系統改造 1）在審核期間根據在準備文審材料總結的評價差異，整理出任務列表，廠商配合制定改造計劃；

2）在系統改造過程中，需要逐步核實改造的功能點以及數據質量是否滿足評級要求；

3）系統改造必須在專家現場查驗前完成，并且確認有3個月的有效數據。 如果改造的內容中涉及到之前沒有功能點需要將優先級提高，上線功能產生業務數據，評級考量的是有3個月的業務數據。 在省級初審、國家級資料審核階段完成改造

7 省級初審 1）省級初審只審核上報的數據以及提交的文審材料，檢查文審材料中說明的功能是否滿足評級標準，如果有存在不滿足的點，省里面會通過郵件反饋。不滿足的點需要繼續在規定的時間內提供補充材料說明 提供到省里面的補充說明材料不會提交到衛健委，只會作為備案文件。 一般在評審當年的2月底

8 國家級資料審核 國家級資料審核，審核通過后，會告知審核結果。如果審核不通過，會告知不滿足要求的點，醫院配合在規定的時間內提供補充材料說明。 只有一次補充說明材料的機會，需慎重 根據當年評審醫院的多少來定

9 國家級現場審核 1）院方在接收到查驗的通知時間后，需要在醫院內組織查驗演示以及確定查驗當天配合演示的各科室人員；

2）現場查驗一般一天內完成，查驗進程包括：醫院向專家組介紹電子病歷六級建設的工作情況；專家組就文審材料問題進行咨詢和核實；專家組走訪醫院，查驗醫院信息化建設的軟硬件環境、管理制度等 根據國家級資料審核時間來定

10 級別評定 現場查驗后，專家組給出最終評級評定結果，通過審核，評級結果得到認證；未通過審核，數據駁回自動降級。五級及以上高級別醫院評級結果官方正式公布 根據國家衛健委時間來定

10.3.

10.3.互聯互通5級評審（重點、難點三）解決方案?

10.3.1.項目組織與分工

10.3.1.1.項目領導/指導團隊

由院方信息科領導和公司項目組領導組成。

職責：聽取項目匯報，對項目進行總體規劃和提出指導性意見，決定項目期間的原則性、方向性問題，為項目的順利執行提供資源保障；

10.3.1.2.院方（信息科）

由信息科成員組成。

職責：

1.研讀《醫院信息互聯互通標準化成熟度測評》文件，對比評分條件，分析醫院信息化總體建設情況，并提出改造意見，具體包括：平臺硬件基礎設施、網絡及網絡安全情況、業務應用系統（生產系統）建設情況、應用建設情況及利用情況、平臺聯通業務范圍。

2.識別項目缺失的軟件系統、軟件功能，并規劃功能、采購、上線以及工作協調；

3.協調各第三方業務系統，包括檢查、檢驗、手麻、護理、急診、病案等，按照電子病歷基本數據集的規范，提供生產數據視圖；

4.協調醫務科、護理部等，推進電子病歷模板改進、試用和推廣，推進軟件的改進；

5.其他需要信息科參與的工作。

10.3.1.3.項目經理（研發實施組）

由我方人員擔任。

職責：

1.根據互聯互通評測的總體時間節點要求，給出項目的總體工作分解及安排；

2.對比互聯互通評測指標，組織專家、研發技術人員、現場項目管理人員，分析現場情況，討論并得出技術解決方案，并安排人員進行研發和實施；

3.根據項目進度，協調研發實施組，包括標準解讀專家、數據集/CDA建設團隊、交付服務建設團隊、平臺服務研發團隊、現場支持團隊協同工作，按計劃達成工作目標；

4.識別項目風險，對項目風險進行評估，并及時向項目領導、指導團隊反饋，尋求支持，得出解決方案；

5.其他需要研發實施組參與的工作。

10.3.1.4.其他業務系統

由各業務系統技術人員擔任。?

職責：

1.按電子病歷基本數據集規范，給出數據集視圖；

2.按照項目需求，進行必要的功能補充和調整；

3.識別項目技術方案細節內容和缺項，并及時反饋，以期得到解決；

10.3.2.工作流程

10.3.2.1.差距分析與項目規劃流程

通過逐項對比互聯互通測評標準，結合醫院信息化建設的實際情況，發現醫院信息化建設的薄弱點或者不符合項，并進而討論解決方案，得出互聯互通項目的總體工作思路和指導思想。這是項目得以成功實施的關鍵。

建議總體規劃的時間為每年的3~4月份。

10.3.2.2.項目實施流程

10.3.2.3.進度安排

項目里程碑

1.項目進場：2023年12月

2.系統環境搭建：2023年12月

3.需求確認：2023年12月25日?

4.定制研發：2024年1月5日

5.試運行：2024年3月13日

6.上線：2024年4月1日

7.子系統接入：2024年5月

8.一級機構單位接入：2024年7月

9.電子病歷報名：2024年8月

10.互聯互通報名（電子病歷五查驗）：2024年12月

11.啟動二級機構醫院接入:2025年2月

12.互聯互通4查驗：2025年5月

13.電子病歷五級查驗：2025年10月

14.完成分院及醫共體成員單位接入：2025年11月

15.電子病歷6（省級文審）、互聯互通5乙（省級文審）、智慧服務三級：2026年6月? ?

項目詳細計劃

序號 項目計劃 開始時間 結束時間

1 南陽市宛城區醫療健康服務集團信息化平臺采購項目實施計劃 2023/12/11 2026/6/30

2 項目啟動階段 　 　

3 項目情況分析 2023/12/7 2024/12/15

4 組建項目核心團隊 2023/12/7 2024/12/15

5 項目資料交接,項目核心團隊熟悉和分析項目情況 2023/12/7 2023/12/15

6 院方初次拜訪與項目情況實地調研 2023/12/7 2024/12/15

7 確認項目目標、范圍、組織架構、執行策略、風險、難點 2023/12/8 2023/12/15

8 編寫實施方案 2023/12/8 2023/12/15

9 撰寫總體實施方案 2023/12/8 2023/12/15

10 項目職責、協同工作流程 2023/12/8 2023/12/15

11 工作任務分解及制定項目總體計劃 2023/12/11 2023/12/20

12 項目分/子計劃 2023/12/11 2023/12/20

13 人力資源計劃 2023/12/11 2023/12/20

14 溝通計劃 2023/12/15 2023/12/20

15 研發工作計劃 2023/12/15 2023/12/20

16 風險評估 2023/12/15 2023/12/20

17 版本與部署計劃 2023/12/15 2023/12/20

18 總體計劃和分/子計劃集成 2023/12/15 2023/12/20

19 成本預算 2023/12/12 2023/12/20

20 實施方案評審 2023/12/14 2023/12/20

21 實施方案評審（公司內部） 2023/12/14 2023/12/20

22 客戶確認 2023/12/15 2023/12/22

23 交付啟動 2023/12/20 2023/12/22

24 交付啟動公告 2023/12/20 2023/12/22

25 成本初始化 2023/12/20 2023/12/25

26 績效初始化 2023/12/20 2023/12/25

27 演示環境服務器搭建階段 2023/12/8 2023/12/20

28 服務器到位 2023/12/8 2023/12/11

29 搭建初始化環境 2023/12/11 2023/12/14

30 搭建開發環境 2023/12/11 2023/12/15

31 搭建演示培訓環境 2023/12/15 2023/12/15

32 搭建驗證環境 2023/12/17 2023/12/20

33 服務器維護交接 2023/12/17 2023/12/22

34 流程確認階段 2023/12/18 　

35 編制流程確認計劃 2023/12/18 2023/12/20

36 準備流程確認所需重點問題清單 2023/12/18 2023/12/22

37 流程確認 　 　

38 功能培訓及確認8.8 　 　

39 醫療管理流程講解與確認 2023/12/25 2024/1/5

40 醫務管理流程講解與確認 2023/12/25 2024/1/5

41 醫技管理流程講解與確認 2023/12/25 2024/1/5

42 藥房管理流程講解與確認 2023/12/25 2024/1/5

43 材料&藥庫管理流程講解與確認 2023/12/25 2024/1/5

44 財務管理流程講解與確認 2023/12/25 2024/1/5

45 護理管理流程講解與確認 2023/12/25 2024/1/5

46 流程確認 　 　

47 住院流程確認 2023/12/25 2024/1/5

48 門診流程確認 2023/12/25 2024/1/5

49 流程分析 　 　

50 功能分析報告撰寫 2023/12/25 2023/12/31

51 范圍評審（公司內部） 2023/12/31 2024/1/5

52 流程簽字 　 　

53 流程確認與簽字（客戶） 2023/12/31 2024/1/5

54 客戶化開發階段 　 　

55 醫保開發 　 　

56 新醫保接入 　 　

57 醫保初步調研 2023/12/15 2023/12/25

58 醫保接入開發 2023/12/25 2024/3/10

59 醫保DLL開發 2023/12/25 2024/3/10

60 醫保接入聯調 2023/12/25 2024/3/10

61 生產問題處理 2023/12/25 2024/3/10

62 單據開發 　 　

63 收集和分析財務等科室相關輸出樣式和流程匹配度（即單據，含計劃） 2023/12/25 2024/1/25

64 單據方案設計 2024/1/25 2024/1/31

65 單據調整與開發 2024/1/5 2024/3/1

66 病歷模板制作 　 　

67 病歷模板調研 2023/12/15 2024/1/5

68 知情同意書制作 2024/1/5 2024/2/29

69 病案首頁制作 2024/1/5 2024/2/29

70 病程制作 2024/1/5 2024/2/29

71 專科電子病歷調研 2023/12/15 2024/1/5

72 ?？齐娮硬v模板制作 2024/2/29 2024/3/20

73 集成平臺工作 　 　

74 集成總體規劃 2023/12/18 2023/12/20

75 集成需求調研與集成方案制定 2023/12/20 2024/1/5

76 主要對接系統 　 　

77 移動護理系統 　 　

78 廠商進場 2023/12/20 2023/12/25

79 集成需求調研與集成方案制定 2023/12/25 2024/1/31

80 集成接口開發 2024/1/10 2024/2/8

81 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

82 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

83 互聯網醫院 　 　

84 廠商進場 2023/12/20 2023/12/25

85 集成需求調研與集成方案制定 2023/12/25 2024/1/31

86 集成接口開發 2024/1/10 2024/2/8

87 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

88 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

89 全院心電/電生理 　 　

90 廠商進場 2023/12/20 2023/12/25

91 集成需求調研與集成方案制定 2023/12/25 2024/1/31

92 集成接口開發 2024/1/10 2024/2/8

93 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

94 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

95 PACS系統 　 　

96 廠商進場 2023/12/20 2023/12/25

97 集成需求調研與集成方案制定 2023/12/25 2024/1/31

98 集成接口開發 2024/1/10 2024/2/8

99 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

100 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

101 患者自助服務系統 　 　

102 廠商進場 2023/12/20 2023/12/25

103 集成需求調研與集成方案制定 2023/12/25 2024/1/31

104 集成接口開發 2024/1/10 2024/2/8

105 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

106 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

107 消毒供應室管理 　 　

108 廠商進場 2023/12/20 2023/12/25

109 集成需求調研與集成方案制定 2023/12/25 2024/1/31

110 集成接口開發 2024/1/10 2024/2/8

111 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

112 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

113 手術麻醉管理 　 　

114 廠商進場 2023/12/20 2023/12/25

115 集成需求調研與集成方案制定 2023/12/25 2024/1/31

116 集成接口開發 2024/1/10 2024/2/8

117 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

118 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

119 支付平臺 　 　

120 廠商進場 2023/12/20 2023/12/25

121 集成需求調研與集成方案制定 2023/12/25 2024/1/31

122 集成接口開發 2024/1/10 2024/2/8

123 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

124 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

125 LIS系統 　 　

126 廠商進場 2023/12/20 2023/12/25

127 集成需求調研與集成方案制定 2023/12/25 2024/1/31

128 集成接口開發 2024/1/10 2024/2/8

129 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

130 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

131 輸血 　 　

132 廠商進場 2023/12/20 2023/12/25

133 集成需求調研與集成方案制定 2023/12/25 2024/1/31

134 集成接口開發 2024/1/10 2024/2/8

135 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

136 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

137 電子發票系統 　 　

138 廠商進場 2023/12/20 2023/12/25

139 集成需求調研與集成方案制定 2023/12/25 2024/1/31

140 集成接口開發 2024/1/10 2024/2/8

141 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

142 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

143 病案統計、示蹤、首頁質控、無紙化 　 　

144 廠商進場 2023/12/20 2023/12/25

145 集成需求調研與集成方案制定 2023/12/25 2024/1/31

146 集成接口開發 2024/1/10 2024/2/8

147 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

148 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

149 排隊叫號 　 　

150 廠商進場 2023/12/20 2023/12/25

151 集成需求調研與集成方案制定 2023/12/25 2024/1/31

152 集成接口開發 2024/1/10 2024/2/8

153 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

154 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

155 合理用藥管理、處方點評 　 　

156 廠商進場 2023/12/20 2023/12/25

157 集成需求調研與集成方案制定 2023/12/25 2024/1/31

158 集成接口開發 2024/1/10 2024/2/8

159 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

160 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

161 院感管理 　 　

162 廠商進場 2023/12/20 2023/12/25

163 集成需求調研與集成方案制定 2023/12/25 2024/1/31

164 集成接口開發 2024/1/10 2024/2/8

165 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

166 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

167 DRG/DIP運營管理系統 　 　

168 廠商進場 2023/12/20 2023/12/25

169 集成需求調研與集成方案制定 2023/12/25 2024/1/31

170 集成接口開發 2024/1/10 2024/2/8

171 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

172 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

173 治療過程管理 　 　

174 廠商進場 2023/12/20 2023/12/25

175 集成需求調研與集成方案制定 2023/12/25 2024/1/31

176 集成接口開發 2024/1/10 2024/2/8

177 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

178 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

179 隨訪管理 　 　

180 廠商進場 2023/12/20 2023/12/25

181 集成需求調研與集成方案制定 2023/12/25 2024/1/31

182 集成接口開發 2024/1/10 2024/2/8

183 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

184 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

185 CA電子簽章系統 　 　

186 廠商進場 2023/12/20 2023/12/25

187 集成需求調研與集成方案制定 2023/12/25 2024/1/31

188 集成接口開發 2024/1/10 2024/2/8

189 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

190 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

191 靜脈配置中心管理系統 　 　

192 廠商進場 2023/12/20 2023/12/25

193 集成需求調研與集成方案制定 2023/12/25 2024/1/31

194 集成接口開發 2024/1/10 2024/2/8

195 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

196 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

197 人事管理系統 　 　

198 廠商進場 2023/12/20 2023/12/25

199 集成需求調研與集成方案制定 2023/12/25 2024/1/31

200 集成接口開發 2024/1/10 2024/2/8

201 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

202 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

203 HRP 　 　

204 廠商進場 2023/12/20 2023/12/25

205 集成需求調研與集成方案制定 2023/12/25 2024/1/31

206 集成接口開發 2024/1/10 2024/2/8

207 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

208 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

209 次要對接系統 　 　

210 檢查檢驗互認協同 　 　

211 廠商進場 2023/12/20 2023/12/25

212 集成需求調研與集成方案制定 2023/12/25 2024/1/31

213 集成接口開發 2024/1/10 2024/2/8

214 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

215 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

216 護理管理 　 　

217 廠商進場 2023/12/20 2023/12/25

218 集成需求調研與集成方案制定 2023/12/25 2024/1/31

219 集成接口開發 2024/1/10 2024/2/8

220 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

221 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

222 觸摸屏導醫 　 　

223 廠商進場 　 　

224 集成需求調研與集成方案制定 2023/12/15 2024/1/31

225 集成接口開發 2024/1/10 2024/2/8

226 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

227 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

228 臨床輔助決策支持CDSS系統 　 　

229 廠商進場 　 　

230 集成需求調研與集成方案制定 2023/12/15 2024/1/31

231 集成接口開發 2024/1/10 2024/2/8

232 集成第一輪聯調（系統接入聯調） 2024/1/10 2024/2/8

233 集成第二輪聯調（多系統業務流程聯調） 2024/1/20 2024/3/18

234 報表開發（三個階段：調研、開發、上線修正） 　 　

235 報表收集(含計劃) 2023/12/15 2024/1/5

236 報表分析與客戶確認 2024/1/2 2024/1/5

237 報表開發 2024/1/5 2024/3/15

238 醫保報表分析及開發 2024/1/5 2024/3/15

239 就診卡 　 　

240 讀卡設備接入 2024/1/5 2024/1/25

241 讀卡設備調研與調試 2024/1/25 2024/2/5

242 定制需求研發 　 　

243 合并合同范圍中的其它院區功能 2024/1/5 2024/3/15

244 定制開發范圍中的功能 2024/1/5 2024/3/15

245 現場實施階段 　 　

246 初始化數據整理 　 　

247 數據初始化計劃 2023/12/11 2023/12/22

248 第一輪數據初始化調研 2023/12/11 2023/12/15

249 第一輪初始化數據整理 2023/12/15 2024/1/25

250 第二輪數據初始化調研 2024/1/5 2024/1/25

251 第二輪初始化數據整理 2024/1/25 2024/2/20

252 第三輪數據初始化調研 2024/2/20 2024/2/22

253 第三輪初始化數據整理 2024/2/22 2024/3/5

254 培訓院方，完成醫囑套餐、臨床路徑、病歷模板的配置 2024/2/20 2024/3/5

255 初始化數據上線前后檢查與確認 2024/3/5 2021/3/15

256 上線期間，初始化數據調整 2024/4/1 2024/4/7

257 系統割接 　 　

258 割接方案撰寫及論證 2024/3/10 2024/3/12

259 割接演練及上線 2024/3/10 2024/3/20

260 本部院區、兒童醫學中心上線階段 　 　

261 生產環境搭建 　 　

262 生產環境等安裝調試 2024/1/19 2024/1/29

263 角色工作臺搭建，母盤制作 2024/1/29 2024/2/3

264 上線測試及空轉 　 　

265 空轉&培訓計劃 　 　

266 第一輪空轉 2024/3/9 2024/3/11

267 第一輪空轉總結、問題修復及測試 2024/3/11 2024/3/3

268 第二輪空轉 2024/3/14 2024/3/15

269 第二輪空轉總結、問題修復及測試 2024/3/16 2024/3/19

270 第三輪空轉 2024/3/19 2024/3/20

271 上線培訓 　 　

272 培訓計劃 2024/2/19 2024/3/12

273 第一輪現場培訓 2024/2/19 2024/2/29

274 第二輪現場培訓（上機實操） 2024/3/1 2024/3/12

275 編制上線計劃 　 　

276 上線環境的調研、打印機等設備準備 2024/3/10 2024/3/11

277 整理需求、確定上線范圍 2024/3/10 2024/3/11

278 編制上線計劃與協調確認 2024/3/10 2024/3/12

279 部門審核與客戶確認 2024/3/10 2024/3/12

280 上線啟動會準備及召開 2024/3/12 2024/3/12

281 上線 　 　

282 上線前的核對 2024/3/10 2024/3/12

283 上線及上線穩定（研發與交付人員值守） 2024/4/1 2024/4/7

284 電子病歷五級 　 　

285 電子病歷版本改造 2024/5/1 2024/7/31

286 電子病歷子系統接入 2024/5/1 2024/7/31

287 電子病歷報名材料準備 2024/8/1 2024/9/1

288 電子病歷定量審查 2024/12/1 2024/12/31

289 電子病歷定性審查 2025/10/1 2025/10/30

290 互聯互通四甲 　 　

291 互聯互通版本改造 2024/7/1 2024/9/31

292 互聯互通系統接入 2024/7/1 2024/9/31

293 互聯互通報名材料準備 2024/12/1 2024/12/31

294 互聯互通查驗 2025/5/1 2025/6/31

295 一級機構接入（27+） 　 　

296 初始化 2024/7/1 2024/10/1

297 子系統集成 2024/5/1 2024/10/31

298 系統上線 2024/8/1 2024/12/1

299 二級級機構接入（6+） 　 　

300 初始化 2025/2/1 2025/8/1

301 系統上線 2025/4/1 2025/9/1

302 電子病歷6（省級文審） 2026/1/30 2026/6/30

303 互聯互通5乙（省級文審） 2026/1/30 2026/6/30

304 智慧服務三級 2026/1/30 2026/6/30

10.3.3.測評流程

總體測評流程圖

10.3.3.1.測評申請階段

10.3.3.1.1.目的

申請機構向其行政隸屬的管理機構提出醫院信息互聯互通標準化成熟度測評的申請；管理機構根據《人口健康信息互聯互通標準化成熟度管理辦法》對申請機構進行審核和管理。

10.3.3.1.2.階段流程

測評申請階段流程圖

1.申請機構根據本院的信息集成平臺和信息管理系統的現狀，通過網上申請注冊提交醫院信息互聯互通標準化成熟度測評申請，且填寫《醫院信息互聯互通標準化成熟度測評申請材料》、《醫院信息互聯互通標準化成熟度測評評估問卷相關證明材料》，準備審查材料，并提交；?

2.管理機構對申請機構已提交成功的測評申請信息進行合理性和資質的審核； 如果審核結果為通過時，則向申請機構和檢測機構發送審核通過通知；

3.檢測機構在接收到審核通過通知后，在規定的時間內，與申請機構溝通，明確本次測評的范圍、內容、級別和所測醫院平臺或信息管理系統的現狀；

4.檢測機構與申請機構簽訂《標準化成熟度測試合同或協議》；進入測試準備階段。

10.3.3.1.3.輸入輸出

輸入：《醫院信息互聯互通標準化成熟度測評申請材料》（含機構法人證書副本、組織機構代碼證、醫療機構執業許可證、項目承建公司工商營業執照、知識產權證明等復印件）、《醫院信息互聯互通標準化成熟度測評評估問卷》、《醫院信息互聯互通標準化成熟度測評評估問卷相關證明材料》

輸出：已簽訂的《標準化成熟度測試合同或協議》。

10.3.3.2.測評準備階段

10.3.3.2.1.目的

測評準備階段，申請機構改造被測系統，準備測試樣本數據和相關技術文件，并準備測試環境和測試平臺；檢測機構組建測試隊伍，包括確定技術專家；檢測機構進行測試策劃與設計，配備測試工具和準備測試設施，準備測評實施。

10.3.3.2.2.階段流程

測評準備階段流程圖

1.申請機構根據標準化成熟度測評的要求，對被測系統進行測試改造，以適用于標準化成熟度定量指標測試和定性指標評審的要求；?

2.管理機構根據申報醫院情況，進行測評的總體安排；

3.檢測機構準備測評的策劃與設計，并準備測試設施和測試工具。

10.3.3.2.3.輸入輸出

輸入：《標準化成熟度測試合同或協議》；?

輸出：《醫院信息互聯互通標準化成熟度測評計劃》；準備好的測試環境和工具。

10.3.3.3.測評實施階段

10.3.3.3.1.目的

檢測機構負責醫院信息互聯互通標準化成熟度測評項目的組、策劃、設計、實施和總結工作；

申請機構為測試實施提供環境、系統配置和醫院平臺或信息管理系統的演示工作；

測評實施階段主要完成實驗室評測、專家文件審查、現場查驗和測評總結。檢測機構根據測試數據和專家評審結果，提交總檢報告。?

10.3.3.3.2.階段流程

測評實施階段流程圖

1.實驗室測評：申請機構（含廠商）為配合測試組的測試工作需要，提供相關技術文檔、演示被測系統等； 配置維護現場測試環境和測試平臺，補充和修改完善測試數據樣本。申請機構按照標準化成熟度測評的數據樣本格式的要求，設計測試數據樣本和醫院平臺或信息管理系統的技術文件，并提交給檢測機構。 檢測機構進行定量指標測試和定性指標評審；

2.專家文審：實驗室測評通過后，管理機構組織申請機構進行專家文審工作，專家根據《醫院信息互聯互通標準化成熟度測評專家評審表》對定性指標進行評審,并填寫記錄后進行結果匯總形成《醫院信息互聯互通標準化成熟度測評文審結果匯總表》；?

3.現場查驗：

1）專家文審通過后，管理機構組織技術專家到申請機構現場對部分定性指標進行現場查驗，包括：技術架構及互聯互通應用情況等；每個專家各自對被測系統進行測評，并填寫《醫院信息互聯互通標準化成熟度測評現場查驗記錄表（一）》。?

2）檢測機構到申請機構現場進行定量指標測試，并填寫醫院信息互聯互通標準化成熟度測評現場查驗記錄表（二）》。 查驗工作組長負責匯總分析測試和測評的結果數據，填寫《醫院信息互聯互通標準化成熟度測評現場查驗結果匯總表》、《醫院信息互聯互通標準化成熟度測評評分匯總表》；?

3）管理機構根據兩個階段測評情況，填寫《醫院信息互聯互通標準化成熟度測評總檢報告》。

10.3.3.3.2.1.實驗室評測

實驗室測評即產品測試，基于測試環境，采用黑盒測試方法。根據測試工具執行測試用例后所得的測試結果，對指標進行綜合評分。詳細測試方法見《電子病歷與醫院信息平臺標準符合性測試規范》。

測試內容包括數據集標準符合性測試、共享文檔標準符合性測試、互聯互通標準符合性測試以及產品技術架構測試。

1.數據集標準符合性測試

采用“黑盒測試”的方法，向測評對象輸入測試數據，測試數據經測評對象處理后，輸出到測試工具，測試工具進行校驗得到測試結果。

具體方式為：

1）測試人員在測試工具中選擇測試用例，將測試數據輸入到測評對象；

2）測評對象將對輸入測試數據的處理結果返回給測試工具；

3）測試工具判斷測評對象的返回信息是否符合期望要求；

4）測試工具向測評對象發起對輸入數據的查詢請求，測評對象處理查詢請求返回查詢結果；

5）測試工具判讀返回結果是否符合期望要求，并判斷測評對象是否符合電子病歷數據標準，并打印測試結果。

備注：尚未摸索出標準評測方式，2018年未執行，暫時以共享文檔測試結果為準，即只要通過共享文檔測試即默認數據集測試通過。

2.共享文檔標準符合性測試

采用“黑盒測試”的方法，通過測試工具將共享文檔樣本輸入測評對象和接收測評對象生成共享文檔的輸出兩個方向進行“雙向驗證”，驗證測評對象的電子病歷共享文檔是否符合標準的要求。

具體方式為：

1）測評對象生成共享文檔的輸出測試：首先測試工具輸入測試數據至測評對象，然后測評對象利用輸入的測試數據生成一份電子病歷共享文檔，將該共享文檔輸出到測 試工具中，測試工具接受該文檔后，驗證該共享文檔是否符合標準的要求。

2）測評對象共享文檔輸入測試：測試工具生成正確（或錯誤）的電子病歷共享文檔實例，并輸入至測評對象，檢測測評對象能否準確判斷共享文檔的正確性，作出正確的響應，包括：解析、保存、注冊到文檔庫等。

備注：2018年執行的模式為將共享文檔樣本輸入測評工具，進行正確性測試。

3.互聯互通標準符合性測試

采用“黑盒測試”方法，將信息平臺視為“黑盒”，通過測試工具向測評對象發送服務請求；測評對象處理服務請求并返回處理結果給測試工具；測試工具分析校驗返回的結果，判斷測評對象是否符合醫院信息平臺技術規范。

4.產品技術架構測試

主要采用定性測試的方式，根據指標體系中對技術架構的要求描述，檢測機構通過審核相關技術文檔、測試測評對象等形式對產品的技術架構進行測試，并給出測試結果。

10.3.3.3.2.2.專家文審

專家對產品應用于具體項目中的標準化水平、技術架構、業務應用、互聯互通效果等定性指標根據證明材料所進行的審查。

主要針對互聯互通標準化建設中的技術架構、基礎設施建設以及互聯互通和創新服務應用效果等定性指標，結合申請機構提交的評估問卷及相關證明材料，采用文件審查、答疑等方式由專家對每個定性指標進行評審。

10.3.3.3.2.3.現場查驗

專家組及測試人員到申請機構，在實際生產環境對測評對象進行的測試和評審。

現場查驗包括定量指標的抽測和定性指標的評審。

1）定量指標的抽測主要包括對數據資源標準化建設的數據集、共享文檔指標以及互聯互通標準化建設的互聯互通服務功能指標在項目應用中的抽樣測試，以及對平臺運行性能的現場測試。

2）定性指標的評審主要包括對文審階段專家質疑指標的現場查驗以及對平臺實現的互聯互通和創新服務應用效果進行現場核實等，采用聽取匯報、查閱材料、訪談、參觀演示等方式，由專家對現場查驗指標進行評審。

現場查驗為期一天，以專家組到醫院進行實地考察的形式完成。包括以下工作：

1）院方、專家組（負責定性測試）和測評機構（負責定量測試）召開測評啟動會議，指定專家組組長；

2）測評機構在信息處，現場抽查共享文檔和交互服務在生產環境的運行情況；

3）專家組考察醫院互聯互通建設成果（包括門診大廳、藥房、急診、門診診區、檢查檢驗科、患者服務中心等），查驗醫院信息化建設的軟硬件環境、管理制度等；

4）專家組到信息處，聽取互聯互通建設匯報，并就文審材料問題進行咨詢和核實；

5）測評結束會議：專家組長按照定量和定性兩方面的測評結果，對醫院互聯互通成熟度進行定級（具體參見等級評定階段—定級），并宣布專家組評定的等級（此等級評定結果尚需申報管理機構確認）。

10.3.3.3.2.4. 輸入輸出

輸入：設計完成的測試數據樣本、配置完成的測試環境；以及被測醫院信息系統的設計、結構、應用等相關的文件。

輸出：《醫院信息互聯互通標準化成熟度測評專家評審表》、《醫院信息互聯互通標準化成熟度測評文審結果匯總表》；《醫院信息互聯互通標準化成熟度測評現場查驗工作方案》、《醫院信息互聯互通標準化成熟度測評現場查驗記錄表（一）》、《醫院信息互聯互通標準化成熟度測評現場查驗記錄表（二）》、《醫院信息互聯互通標準化成熟度測評現場查驗結果匯總表》、《醫院信息互聯互通標準化成熟度測評評分匯總表》、《醫院信息互聯互通標準化成熟度測評總檢報告》。

10.3.3.4.等級評定階段

等級評定階段流程圖

10.3.3.4.1.目的

管理機構在審核檢測機構提交的總檢報告和專家評級意見后，確認申請機構的等級，并頒發證書；并且解決申請機構提的爭議和復議。

10.3.3.4.2.階段流程

管理機構接收檢測機構提交的《醫院信息互聯互通標準化成熟度測評總檢報告》后，組織相關人員進行測評結果的評定，審定由技術專家推薦的申請機構的標準化成熟度的等級；?

1）如果評定通過，管理機構向申請機構頒發《醫院信息互聯互通標準化成熟度測評等級證書》，并在網上公布標準化成熟度等級結果；?

2）如果評定未通過，管理機構通知申請機構評定結果；?

10.3.3.4.3.定級

醫院信息互聯互通標準化成熟度評價分為七個等級，由低到高依次為一級、二級、三級、四級乙等、四級甲等、五級乙等、五級甲等，每個等級的要求由低到高逐級覆蓋累加，即較高等級包含較低等級的全部要求。

表：測評內容的指標達標要求表

三級 四級乙等 四級甲等 五級乙等 五級甲等

2.1數據標準建設情況（滿分15分） 15分 15分 15分 15分 15分

2.2共享文檔建設情況（滿分15分） 13分 14分 14分 15分 15分

3.1平臺技術架構（滿分10分） 6分 7分 8分 10分 10分

3.2平臺服務功能（滿分25分） 9.5分 12分 18.7分 21分 25分

3.3運行性能（滿分5分） 5分

4.1硬件基礎設施情況（滿分5分） 3分 3.8分 4分 4.9分 5分

4.2網絡及網絡安全情況（滿分5分） 3.6分 4.4分 4.8分 5分 5分

4.3信息安全情況（滿分2分） 1.4分 1.6分 1.7分 1.8分 2分

4.4業務應用系統建設情況（滿分3分） 1.5分 1.9分 2.2分 2.5分 3分

5.1基于平臺的業務應用建設情況（滿分9分） 6分 8分 8分 9分 9分

5.2平臺聯通業務范圍（滿分6分） 1分 2.3分 3.6分 5.8分 6分

各等級最低等級分（達標分數） 60分 70分 80分 90分 100分

表：醫院信息互聯互通標準化成熟度分級方案

等級 分級要求

四級乙等 初步建成基于電子病歷的醫院信息平臺；

建成基于平臺的電子病歷共享文檔庫，門（急）診部分電子病歷共享文檔符合國家標準； 平臺實現符合標準要求的注冊服務以及與上級平臺的基礎交互服務； 平臺上的應用功能（公眾服務應用、醫療服務應用、衛生管理應用）數量不少于 13 個； 連通的業務系統（臨床服務系統、醫療管理系統、運營管理系統）數量不少于 15 個；聯通的外部機構數量不少于 3 個。

四級甲等 建成較完善的基于電子病歷的醫院信息平臺；

建成基于平臺的獨立臨床信息數據庫； 平臺實現符合標準要求的電子病歷整合服務、就診信息查詢及接收服務，基本支持醫療機構內部標準化的要求；連通的業務系統（臨床服務系統、醫療管理系統、運營管理系統）數量不少于 24 個；聯通的外部機構數量不少于 4 個。

五級乙等 法定醫學報告及健康體檢部分共享文檔符合國家標準；

平臺實現符合標準要求的術語和字典注冊、與上級平臺交互的共享文檔檢索及獲取服務； 平臺實現院內術語和字典的統一，實現與上級平臺共享文檔形式的交互； 平臺上的應用功能（公眾服務應用、醫療服務應用、衛生管理應用） 數量不少于 15 個；平臺初步實現與上級信息平臺的互聯互通； 聯通的外部機構數量不少于 5 個。

五級甲等 平臺實現符合標準要求的與上級交互的術語和字典調用及映射服務、預約安排及預約服務；通過醫院信息平臺能夠與上級平臺進行豐富的交互，實現醫院與上級術語和字典的統一； 平臺實現豐富的跨機構的業務協同和互聯互通應用； 聯通的外部機構數量不少于 6 個。

《醫院信息互聯互通標準化成熟度測評指標體系》中規定的每個指標均有其權重分值，滿足其對應要求則得到相應分值，不滿足相應要求則不得分。

對于定量指標根據產品測試報告的測試結果對每個指標進行評分；現場查驗時抽測定量指標，如抽測不通過，該指標最終不得分。

對于定性指標則需對所有定性指標進行評審并給出相應得分。專家組每位成員分別對每個定性指標進行評分后由檢測機構進行結果匯總。結果匯總原則為：對于專家文件審查時已確認的指標根據奇數專家組中半數以上專家給出的得分為該指標得分；對于現場查驗時的指標根據奇數專家組中半數以上專家給出的得分為該指標得分。最終匯總專家文件審查指標得分和現場查驗指標得分得出每個定性指標的得分。

10.3.3.4.4.輸入輸出?

輸入：《醫院信息互聯互通標準化成熟度測評總檢報告》。?

輸出：《醫院信息互聯互通標準化成熟度測評等級證書》。

11.總院實施落地方案

11.1.關鍵工作項

總院實施落地的關鍵路徑如下：

路徑 內容

需求調研 2023-12-25 對照標準流程全面梳理用戶需求，制定解決方案

環境搭建 2023-12-20 搭建開發、測試、準生產、生產等環境

數據初始化 2024-1-05 梳理醫院“機構、床位、診療目錄、藥品目錄，初始化導入

三方集成 2024-1-05 第三方系統集成方案制定與對接聯調

系統培訓&考核 2024-2-19 培訓醫、護、藥、劑、財務等人員熟練使用系統

數據割接 2024-3-10 將舊系統的歷史數據進行清洗、轉換、并裝載到新系統

試運行 2024-3-13 組織醫護人員在生產系統上模擬患者門診、住院看診，熟悉系統功能、評估上線風險

系統上線 2024-4-1 正式切換上線

11.2.需求調研

需求調研對于一個應用軟件開發來說，是一個系統開發的開始階段，它的輸出“軟件需求分析報告”是設計階段的輸入，需求調研的質量對于一個應用軟件來說，是一個極其重要的階段，它的質量在一定程度上來說決定了項目實施結果的好壞。

總院的需求調研步驟分為：1、分模塊系統演示講解，需求收集。2、差異化分析，回訪調研。3、需求規格說明書輸出。4、上機培訓，二次需求收集。5、持續收集需求，優化。

11.3.環境搭建

通常我們搭建4套以上環境完成開發，測試，試運行，系統切換上線等工作，保障各項工作獨立開展。

開發環境：開發環境用于系統開發，單元測試，代碼管理

測試環境：測試環境用于各類需求開發后系統測試

準生產環境：準生產環境用于系統試運行，集成聯調測試，數據遷移，初始化比對

生產環境：生產環境服務啟動后，完成數據遷移，按計劃執行切換

11.4.數據初始化

系統初始化過程中，將各類靜態數據，參數類數據，基礎數據提前搜集并遷移至新系統，在盛博匯過往的實施經驗中，我們積累了大量的經驗，過程資產，工具腳本，以保障數據初始化的準確性與高效性。

針對總院的數據初始化，制定如下方案步驟：

需求分析：根據項目交付的模塊，分析數據初始化需求，切分初始化模塊，制定初始化計劃。

方案設計：分析老系統數據庫，確定不同類型數據的初始化方案，包括1.數據庫導入。2.腳本導入。3.人工錄入。4.增量錄入。5.前端維護幾個途徑。

腳本開發：根據數據初始化方案，開發數據導入腳本，SQL，校驗工具，導入功能等。

數據搜集：明確各科室智能，從業務科室搜集各類初始化數據，包括組織機構名稱，組織機構編碼，科室代碼，物理地點，核算單元編碼，院區編碼，授權分組，權限數據等。

計劃執行：各科室共同完成數據比對核驗，數據準備完成，執行數據初始化工作，執行預訂計劃任務，完成數據初始化工作。

持續更新：對初始化數據進行校驗，核對，對錯誤數據進行修訂，補錄。在上線前持續搜集數據更新，同步在新系統進行更新。

上線值護：新系統切換上線過程中，對于突發的流向，權限，編碼問題，進行即時調整，確保新系統上線當天業務不受影響。

11.5.系統集成

盛博匯集成平臺的標準化流程：8大業務域、300+個外部系統適配、1000+個流程定義，支持國內各大主流廠商集成適配。

系統集成工作的解決方案詳見11.1章節。

11.6.數據割接方案

我們通過識別數據遷移范圍；針對不同類型數據，制定不同的遷移策略已方案；制定詳細的割接計劃與精確執行，來保障數據遷移目標成功達成。

針對總院的數據割接工作，分為以下幾個步驟。

數據割接規劃：制定割接方案，明確數據割接步驟、范圍、策略。

數據割接的范圍：

數據種類 數據分類 數據表

即時遷移數據 患者就診卡 患者建檔信息表

導引介質表

導引介質校驗表

賬戶索引表

賬戶明細表

住院患者信息 患者入院記錄表

住院患者醫保登記信息 醫保登記信息表

基本信息表?

住院患者費用明細數據 費用明細表?

盤存補錄 庫存數據 材料數據

藥品數據

即時數據割接的步驟：

步驟 內容

1：數據割接映射 數據庫字段映射

關聯系統影響分析

數據清洗方案

2：數據割接方案 數據遷移方案

數據遷移環境要求

數據遷移工作計劃

重點業務專題方案

重點技術專題方案

3：數據割接設計 數據遷移邏輯設計

數據清洗邏輯設計

數據遷移驗證邏輯設計

?字段比對

?邏輯比對

?抽樣方案

?功能驗證

數據遷移邏輯業務確認

4：數據割接開發 數據清洗程序開發

數據遷移程序開發

數據遷移驗證程序開發

現有系統生產數據快照準備

5：數據割接演練 數據遷移方案優化

數據遷移邏輯修正

數據遷移結果抽樣確認

數據遷移驗證窗口確認

6：系統割接 D-1日停服務

D-1日數據遷移

D-1日數據手動記錄

D日數據補錄

庫存數據割接的步驟：

時間 內容

D-1日 23：00 材料/藥品盤存

D-1日 23：00- 00：00 手動記賬

D日 新系統啟用 數據補錄

11.7.系統試運行

系統試運行：醫護人員熟悉真實系統功能與流程，院方及項目組評估上線風險重要手段。試運行將完成核心重點業務的全流程閉環運行，從而驗證系統的可用性與穩定性。系統試運行需院方各臨床業務科室共同參與，才能提供最完整的測試結果，最小化新系統上線風險。

目的 檢查內容

明確目標 ?功能檢查流程是否符合醫院要求

?票據，報表查驗

?驗證團隊協作能力，應急能力

?風險評估

?系統性能驗證

確定范圍 ?門診：建檔、掛號、病歷書寫、患者就診等

?住院：床位預約、患者入科、患者專科、患者出院、患者手術等

?用藥：檢查用藥、手術用藥、藥品采購入庫等

?其他：醫保結算、病歷解檔，歸檔流程

計劃執行 時間：

?模擬門診相關流程

?模擬住院相關流程

?模擬其他相關流程

?試運行問題整理及整改

地點、人員：

?人員科室地點確認

?人員分工與職責定義

流程：

?硬件準備->數據準備->人員準備->試運行執行->逆流程執行

檢查改進 ?制定處理缺陷/事件的適當程序和方法

?Bug即時解決

?針對使用問題制定進一步培訓計劃

?針對協作問題與相關各方制定溝通計劃

11.8.系統切換方案

對比 門診住院整體切換 新老系統并行

切換方法 全面啟用新系統，關停老系統。已住院患者在老系統中辦出科 ，新系統中辦理入院。 老系統中掛號、辦住院的患者在老系統中完成就診過程。新到醫院的門診或住院患者在新系統中完成就診過程。

優勢 醫護人員只需要支持一套系統，工作比較簡單便。藥品、耗材只需要在新系統中維護庫存管理，盤點簡便。切換時間短，見效快 系統切換壓力小，切換比較平穩。

挑戰 切換壓力大，切換過程需要醫院及公司的資源較多。在老系統個別需要退費用患者需要手工處理。在院患者需要跨系統處理資料和數據遷移 新老系統并存時間長，兩套系統需要同時支持并行，需要使用兩套系統，工作繁雜。周邊配套體系統需要同時對接兩套系統，工作量比較大。業務報表、藥品、耗材不準等，需要手工合并。

典型案例 連云港第一人民醫院

貴州省人民醫院、甘肅省婦幼醫院 武漢同濟醫院

……

11.9.系統切換步驟

D-1日：各事務時間窗口在23:30前逐步關停，24:00老系統正式停止服務D日：00:00起所有業務切換至新系統，完成數據補錄，藥品補錄；急診對外服務啟動；8：00，正式對外服務。

工作項階段 內容 計劃開始時間 計劃完成時間

1. （D-7日）切換準備 切換公告通知 - D-7

預住院患者停診 - D-7

在院患者出院 - D-7

完成數據初始化 - D-7

完成環境準備 - D-7?

2. （D-1日）老系統業務逐步關停 重點設備調試 D-1 11:00 D-1 18:30

藥房庫存盤點 D-1 18:30 D-1 23:30

檢查系統科室硬件更換（采集卡.腳踏板.電腦系統 ） D-1 18:30 D 8:00

老系統住院業務關停 D-1 21:00 D-1 23:00

老系統完成結算 D-1 21:00 D-1 23:00

檢查檢驗系統停止 D-1 21:00 D-1 23:00

歷史數據割接 D-1 21:00 D-1 23:30

老系統急診業務關停 D-1 23:30 D 00:00

各醫技系統全面切換 D-1 23:30 D 00:00

藥品手動記錄 D-1 23:30 D 00:00

3. （D日）新系統上線 急診掛號就診 D 00:00 -

患者住院接診 D 00:00 -

新系統患者開醫囑 D 00:00 -

檢查檢驗系統開啟 D 00:00 -

藥品補錄 D 00:00 D 01:00

新系統門診就診 D 08:00 -

11.10.系統切換應急預案

11.10.1.主要設備故障應急預案

1.1.1.11.10.1.1.服務器故障應急預案

1.主服務器不能啟動，應作如下應急工作：

1)通知使用部門關閉所有HIS程序，并向病員做好解釋工作。

2)切換到備用服務器。

3)通知工作站重新登錄HIS程序，進入原工作流程。

4)通知相應科室恢復工作。

5)修復主服務器。

2.主服務器數據故障，應作如下應急工作：

1)通知使用科室關閉所有HIS程序，并向病員做好解釋工作。

2)停止主服務器的數據服務。

3)用最近可用的數據庫恢復。

4)通知相應科室恢復工作。

3.由于主備服務器均構建在CAS虛擬化平臺之上，所以，當主、備服務器均不能啟動，應作如下應急工作：

1)通知使用科室關閉所有HIS程序，并向病員做好解釋工作。

2)維修CAS云平臺服務器或通過其他方式恢復服務狀態。

3)待服務器恢復后啟動服務器上相應作業。

4)通知使用科室使用原有HIS程序。

4.存儲損壞，此種情況可能造成數據丟失，應作如下應急工作：

1)告知使用科室關閉所有HIS程序，并向病員做好解釋工作。

2)將主服務器、備服務器全部關閉。

3)關閉磁盤陣列。

4)若是單塊硬盤損壞，取下損壞硬盤，換上新硬盤。

5)重新啟動陣列及服務器，等待系統自動重灌數據。

6)若是多塊硬盤損壞，取下損壞硬盤，換上新硬盤后，重新做服務器系統，并還原數據庫至正常。

7)重新啟動數據庫服務，通知使用部門恢復工作。

5.毀滅性災害，應作如下應急工作：

1)關閉全院所有工作站。

2)啟動手工模式。

3)維修服務器或通過其他方式恢復服務狀態。

4)服務器恢復后啟用計算機相應作業。

5)下班后或空閑時補錄所有未進入系統的費用和處方，并完成藥品下賬。

服務器故障大致可分為以上五種情況，其中第一種和第二種情況計算機網絡系統故障恢復較快，對全院業務工作影響較小，但第三、第四、第五種情況計算機網絡基本處于癱瘓狀態，將嚴重影響醫院正常醫療工作秩序，必須避免這三種情況發生的同時，還應做好以下應急方案：

1)每天檢查各服務器運行狀態。

2)設置數據庫每天作一次數據備份。

3)異地服務器每天做好異地備份。

11.10.1.2.工作站故障應急方案

1.及時處理故障計算機工作站。

2.若問題當時無法處理，用備用計算機替代故障計算機。（建議醫院備用10臺應急工作站主機）

3.維修故障計算機。

11.10.1.3.供電系統故障（停電）應急方案

1.計算機網絡中心供電故障：

1)不間斷電源自動對機房的服務器、主交換機等進行供電。

2)及時通知后勤保障部進行維修。

2.收費、藥房計算機工作站供電設備故障：

1)啟用手工模式。

2)來電后補錄數據。

3.病區工作站供電設備故障：

1)設備暫時停止使用。

2)若要急用，到相鄰病區進行操作。

3)科室及時通知后勤保障部進行維修。

11.10.1.4.操作系統故障應急方案

1.服務器操作系統故障的應急方案：使用備用服務器。

2.工作站操作系統故障的應急方案：關閉故障計算機工作站，用備用計算機替代故障計算機，重新安裝故障計算機操作系統。

11.10.1.5.感染病毒應急方案

計算機網絡安全是十分重要，不僅給計算機管理人員帶來巨大的工作量還將嚴重影響醫院的正常醫療工作秩序，因此，必須控制計算機感染病毒，必須與外部網絡物理隔離，禁用U盤，一旦計算機感染病毒，應采取以下應急方案：

1.斷開計算機工作站與服務器的連接。

2.將感染情況匯報院領導。

3.查找計算機病毒感染源和殺毒。

4.對服務器進行殺毒。

5.對其他工作站殺毒。

6.處理肇事計算機使用科室及人員。

11.10.2.信息系統故障應急預案

1.2.11.10.2.1.系統級軟件故障

應急準備：主服務器采用雙服務器，服務器電源采用雙路不間斷電源交叉供電，備用交換機、網絡上使用的各設備，并定期檢查各設備，每天數據全備份。

應急措施：當班人員應立時向上級有關領導報告并通知有關部門。在崗人員不能處理或人手不夠時，應立即聯絡其他人員，各人員應盡快到位。

首先查明系統故障原因，根據故障原因采取相應的措施。若服務器必須重啟，向應急領導小組匯報后，通知關鍵部門(門診住院收費、中西藥房等)以及相關部門退出操作關機，必要時切斷與下面終端的網絡聯接。對故障處理應根據當時情況先保證恢復使用為先決條件，在對系統影響盡可能小的時間再作后續處理。對于硬件故障若不能立即排除，則采用備用設備替代。故障排除后，立即通知應急領導小組、總值班(非行政班時間)、門診收費處、門診中西藥房、住院收費處、住院藥房、急診室、財務科、醫務科、護理部、門診辦公室、檢驗科、放射科等關鍵部門。協助各部門完成后續工作，補錄數據，恢復相關數據。

11.10.2.2.各應用子系統故障

應急準備：每天數據全備份

應急措施：

1.HIS主系統出現故障：分析故障原因，查看近期是否有軟件變更，立即通知相關軟件人員處理，不能立即處理的，則立即啟用備用服務器，若是終端查詢引起的故障，關閉故障終端，并根據具體情況決定是否啟動應急方案。

2.檢查、檢驗系統出現故障，HIS系統能正常運行： HIS系統運行不變，檢查、檢驗系統即檢驗科、放射科按原手工方式操作，并立即與軟件供應商聯系，排除故障。并根據具體情況決定是否啟動應急方案。

3.HIS醫保模塊出現故障，查明是醫保中心故障還是電信線路故障，根據故障原因作出相應處理，并與相關單位聯系。

4.其它子系統故障：立即與相應系統的各軟件供應商聯系，并根據具體情況決定是否啟動應急方案。

11.10.2.3.HIS門診

應急準備：

門診收費處各手工操作憑證單據，醫院診療收費目錄，手工處方單、各種檢查治療單、化驗單。

應急措施：

藥房和收費處啟動本地劃價系統;醫生收取手工號表，開手工處方、手工檢查治療單據，并蓋上自己科室和個人專用章；到藥房劃價并在處方上記錄就診卡號;收費處對診療項目劃價，手工掛號、開手工發票，并在發票和掛號單留底上記錄就診卡卡號、開單科室和醫生代碼，對于需售就診卡的，給病人一張就診卡，并記錄卡號以及就診卡需填寫的信息。檢查治療科室接到手工開的診療單和發票，保留診療單和發票，并匯總上交，對電腦上開的無法核收的則記錄就診卡號或住院號，在系統恢復正常后補核收。

系統恢復正常運行后，由藥房和收費處補錄數據：藥房補錄處方并確認發藥;收費處由系統管理員啟動補錄系統，收費員補錄所有自己收退費發票、號表和出售的就診卡信息并打印，所有手工和電腦憑證一起上交。各診療科室門診辦公室協助收集匯總各醫生手工號表和診療收據，上交財務科，由財務科作后續處理。

醫保系統故障，門診收費處對醫保病人收現金，開普通現金發票，并與醫保中心聯系，讓醫保病人到醫保中心報銷。

11.10.2.4.HIS住院病區

應急準備：病區收費處各手工操作憑證單據、病歷紙、各種檢查治療記錄單、化驗單

應急措施：

按原手工方式記錄執行醫囑，手工統藥向病區藥房借藥，入院、醫囑、記賬及醫技科室的核收補收等有關電腦上的操作可在系統恢復正常后再補充處理，入院可先交款開收費憑證，系統正常運行后補辦手續并用電腦打印收據換回手工收費憑證，病人出院結帳則需在系統恢復正常后處理。

11.10.2.5.LIS系統故障

應急準備：各種空白報告單

應急措施：LIS系統出現系統故障，HIS系統能正常運行，在HIS上關閉與LIS的聯接，HIS系統運行不變，LIS系統即檢驗科按原手工方式操作。病區因沒有產生條形碼，按手工方式貼標簽附檢驗單送檢;門診的檢驗可根據收費處打印的項目處理，門診報告單由檢驗科原取單窗口提供。LIS系統恢復運行后，HIS打開與LIS的聯接，檢驗科處理好之間的銜接，并保留所有手工憑證。系統恢復運行后，補錄病人信息。

11.10.2.6.PACS系統故障

應急準備：各種紙質的空白報告單

應急措施：PACS系統出現系統故障，HIS系統能正常運行：HIS系統運行不變，PACS系統相關查檢科室按原手工方式操作，圖像及報告存儲在本地，保留各手工憑證。PACS系統恢復正常運行后，上傳存儲在本地的數據，各影像科室要處理好系統之間的銜接。

故障1：系統接口故障，不能正常獲取申請單，且半小時內無法解除故障。? ? ?

?應急預案：立即啟動手工登記模式輸入檢查申請。

?故障2：數據服務器故障，不能正常進行數據交換，且半小時內無法解除故障。

?應急預案：立即人工收取檢查申請單，給申請單進行編號，安排患者先行進行檢查，在系統正常后補錄檢查數據及報告。

?故障3：影像服務器故障，不能正常接受影像數據，且半小時內無法解除故障。

? 應急預案：按正常狀態接診處理業務，系統恢復后補傳影像數據。系統在1小時無法正常啟動，可以啟用備用服務器。

11.10.3.電子病歷系統故障

應急準備：各種紙質病歷紙、記錄單、檢查單、化驗單

應急措施：電子病歷系統出現故障，其它系統能正常運行，按原手工方式處理，系統恢復正常運行后，補錄信息。

11.10.4.信息系統回退應急預案

為了保障云平臺的順利上線，我們制定了總體切換方案和詳細的切換指南。但可能因準備不充分，導致切換失敗，為了保證醫院業務的正常運行，制定了如下原則：

1.從2020年5月30日晚23:00點開始切換，如到2020年5月31日凌晨5點門診或者住院業務仍然處于癱瘓狀態，則停用新系統，重新啟用老系統，各醫技系統重新啟用原有服務。

2.在系統回退后，未就診急診患者在老系統重新掛號開單就診。

3.在系統回退后，住院患者重新在老系統開單就診。

11.10.5.問題處理流程

在新系統剛開始運行時，部分內容準備的不充分，例如電子病歷各科室特殊模板的遺漏，一些問題可能會非常集中地出現。如果不能及時解決這些問題，這些集中出現的問題反復出現可能就會影響到醫院正常的醫療工作，危及信息系統正常的使用。這時必須及時建立起處理問題的機制，確保系統運行的平穩。

本次新系統上線，對系統問題的處理方式，進行分級管理?？剖揖唧w工作人員，在使用系統中發現問題后，需要及時反饋到科室信管員處，科室信管員對問題進行分類，如操作使用上的某些問題，科室信管員可直接解決。其他不影響當前使用的問題，科室信管員需要做筆記對問題進行匯總。匯總后，每天統一提交給項目上線實施組，由實施組對具體問題進行統一處理。如果是影響系統使用的問題，需要立即上報項目上線實施組進行處理。