人人人妻人人澡人人爽欧美一区,久久精品麻豆日日躁夜夜躁,国产女人被狂躁到高潮小说,国产一区二区三区成人

****綜合診治能力提升項目-集成平臺建設項目標前更正公告

****綜合診治能力提升項目-集成平臺建設項目標前更正公告

一、項目基本情況

原公告的采購項目編號：****

原公告的采購項目名 稱：****綜合診治能力提升項目-集成平臺建設項目

首次公告日期：2022年9月9日

二、更正信息

合同包1
更正事項：采購文件的技術和服務要求
更正原因：修改技術和服務要求
更正內容：

§1 項目概述

****在院區信息化建設過程中上線了各種技術架構、各種應用領域的專業信息化軟件，為醫院醫療業務的發展提供了強有力的信息化支撐。

但由于在國內信息化建設初期發展階段，各類信息系統缺乏統一的標準及技術互聯互通標準化架構，醫院現有信息系統平臺也逐漸暴露出了架構復雜、系統相對獨立、數據標準不統一，系統運行風險高且難以對全院數據進行有效的統一管理與利用。

醫院現需要通過引進一套集實用性、易用性、安全性、可靠性、開放性、可擴展性、****醫院信息集成平臺，輔助醫院構建具有國際先進管理理念，符合國內醫療未來發展方向的綜合管理體系，把醫院現有各臨床系統的歷史業務結果數據以及實時性業務交互數據都存儲在該數據平臺中，同時實****醫院信息平臺的互聯互通，消滅各系統間原先存在的接口，實現醫院各業務系統從原來的到所需業務系統中獲得****醫院信息平臺上獲得數據。并在此基礎上，對醫院所有數據進行重新的解構和處理，實現基于醫療大數據的挖掘和分析目標。還在開放式平臺和標準協議基礎上，將醫院現有系統環境統一集成在門戶系統平臺上，實現多平臺、統一體系結構的真正開放式平臺。

★為保證項目工程的順利實施，投標人必須進行客戶現場勘察，****醫院現有信息系統現狀，各種可預見問題投標人均應考慮到，對于系統對接等各類原因造成費用增加時，各投標人應綜合考慮在投標報價內，今后在服務時存在此原因造價不再調整中標價格。現場勘察完畢，采購人將出具已勘察過的潛在投標人的勘察證明，并在勘察證明原件上蓋章確認該投標人已勘察過現場，經確認的勘察證明應附在投標人的投標文件中，否則按無效投標處理。

§2 項目建設清單

序號	產品名 稱	子模塊名 稱	描述
1	集成平臺	消息流處理引擎	包含運行平臺開發；開發工具部署；管理平臺配置；監控平臺部署；數據存儲以及日志審計
		HL7標準引擎	協議標準定義；標準集成配置以及數據轉換
		主索引管理系統	包含匹配條件配置；索引信息查看；疑似記錄查看以及主索引日志
		運維管理監控平臺	包含服務器監控；總線監控；服務監控；通訊點與路由狀態監控；系統告警；通訊日志；異常日志；日志重發；日志歸檔；組件注冊；服務注冊以及事件注冊
		統一登錄平臺	包含用戶登錄；消息轉發；身份認證；密碼管理以及用戶管理
		集成平臺基礎件	包含數據總線和消息中間件
2	CDR數據中心	患者360視圖	包含門診時間軸;住院時間軸;門診量;住院量;歷次診斷;生命體征;出量入量;長囑信息;短囑信息;手術量;出入徑狀況;檢查信息;藥品信息;報告對比以及趨勢分析等內容
		主數據管理系統	包含術語注冊；基礎洗點；術語管理以及字典同步引擎
		ETL工具	提供圖形化用戶界面，可對數據抽取、轉換、傳輸和轉載，完成數據的標準化清洗
		數據集和共享文檔管理系統	提供可視化工具對數據標準進行管理，包括標準數據元管理、數據元值域管理、標準數據集管理、共享文檔模板管理
		對外統一數據服務	包含數據接口；數據視圖；權限認證以及視圖設 計
3	接口改造	接口改造	與第三方基礎業務系統改造

詳細建設內容

系統	子模塊	功能模塊
集成平臺	消息流處理引擎	運行平臺
		管理配置平臺
		開發平臺
		監控平臺
		數據存儲
		日志審計
	HL7標準引擎	協議標準定義
		數據轉換
		標準集成配置
	主索引管理系統	匹配條件配置
		索引信息查看
		疑似記錄查看
		主索引日志
	運維管理監控平臺	服務器監控
		總線監控
		服務監控
		通訊點與路由狀態監控
		系統告警
		通訊日志
		異常日志
		日志重發
		日志歸檔
		組件注冊
		事件注冊
	統一登錄平臺	用戶登錄
		消息轉發
		身份認證
		密碼管理
		用戶管理
	集成平臺基礎件	數據總線
		消息中間件
	數據治理	數據治理
	數據開放平臺	數據開放平臺
CDR數據中心	患者360視圖	門診時間軸
		住院時間軸
		門診量
		住院量
		歷次診斷
		生命體征
		出量入量
		長囑信息
		短囑信息
		手術量
		出入徑狀況
		檢查信息
		藥品信息
		報告對比
		趨勢分析
	主數據管理系統	術語注冊
		基礎洗點
		術語管理
		字典同步引擎
	ETL工具	提供圖形化用戶界面，可對數據抽取、轉換、傳輸和轉載，完成數據的標準化清洗
	數據集和共享文檔管理系統	標準數據元管理
		數據元值域管理
		標準數據集管理
		共享文檔模板管
		可視化標準工具管理
	對外統一數據服務	數據接口
		數據視圖
		權限認證
		視圖設 計
	業務總線	HIS信息交換組件
		電子病歷信息交換組件
		檢驗（LIS）信息交換組件
		放射信息交換組件
		心電信息交換組件
		超聲信息交換組件
		院感信息交換組件
		體檢信息交換組件
		微信公眾號服務組件
		掌上醫院業務交換組件
		績效、財務業務交換組件
		統一支付平臺信息交換組件
		診間結算信息交換組件
		床旁結算信息交換組件
		物資供應鏈業務交換組件
		手麻信息交換組件
		輸血信息交換組件
		合理用藥信息交換組件
		醫保服務組件
		知識庫交換組件
		閉環業務交換組件
		全民健康信息平臺交換組件
接口接入	第三方接入平臺	HIS系統改造
		電子病歷系統改造
		OA改造
		院感系統改造
		檢驗系統改造
		檢查類系統
		心電系統
		績效、財務系統改造
		物資供應鏈改造
		手術麻醉管理系統改造
		合理用藥系統改造
		輸血管理系統改造
		財務、預算管理系統改造
		體檢系統改造
		物資、固定資產等系統改造
		支付平臺改造
		多點結算改造

序號	產品名 稱	子模塊名 稱	描述
1	集成平臺	消息流處理引擎	包含運行平臺開發；開發工具部署；管理平臺配置；監控平臺部署；數據存儲以及日志審計
		HL7標準引擎	協議標準定義；標準集成配置以及數據轉換
		主索引管理系統	包含匹配條件配置；索引信息查看；疑似記錄查看以及主索引日志
		運維管理監控平臺	包含服務器監控；總線監控；服務監控；通訊點與路由狀態監控；系統告警；通訊日志；異常日志；日志重發；日志歸檔；組件注冊；服務注冊以及事件注冊
		統一登錄平臺	包含用戶登錄；消息轉發；身份認證；密碼管理以及用戶管理
		集成平臺基礎件	包含數據總線和消息中間件
2	CDR數據中心	患者360視圖	包含門診時間軸;住院時間軸;門診量;住院量;歷次診斷;生命體征;出量入量;長囑信息;短囑信息;手術量;出入徑狀況;檢查信息;藥品信息;報告對比以及趨勢分析等內容
		主數據管理系統	包含術語注冊；基礎洗點；術語管理以及字典同步引擎
		ETL工具	提供圖形化用戶界面，可對數據抽取、轉換、傳輸和轉載，完成數據的標準化清洗
		數據集和共享文檔管理系統	提供可視化工具對數據標準進行管理，包括標準數據元管理、數據元值域管理、標準數據集管理、共享文檔模板管理
		對外統一數據服務	包含數據接口；數據視圖；權限認證以及視圖設 計
3	接口改造	接口改造	與第三方基礎業務系統改造

§3、集成平臺§3.1數據總線

通過數據總線可實現平臺化的分層架構，應實現包括業務系統(如HIS、EMR、LIS、PACS、移動護理、移動查房、手術麻醉系統、重癥監護系統、預約管理系統、自助服務管理系統)與管理系統的分層等。將不同的業務系統依據訪問頻度、性能要求、實時性要求、數據粒度等的要求進行架構分層。

（1****醫院信息管理系統（HIS）系統交互要求：應能通過數據總線自動獲取HIS相關基本信息、醫囑信息等，為其他信息系統的信息交互提供所需的數據。

（2）數據總線與檢驗信息管理系統信息（LIS）交互要求：應能通過業務服務平臺獲取檢驗單據信息、患者住院信息、病歷信息，記錄完整的檢驗單據處理過程，標本送檢過程處理與單據費用自動處理，檢驗報告結構化存儲，實現多系統統一的報告調閱接口；

（3）數據總線與醫學影像傳輸與管理系統信息(PACS)交互要求：應能實現放射檢查、超聲檢查、內鏡檢查、病理檢查、心電檢查等業務通過業務服務平臺獲取檢查單據信息、患者住院信息、病歷信息，記錄完整的檢驗單據處理過程，檢查圖文報告結構化存儲，實現多系統統一的報告調閱接口；并需支持統一影像瀏覽及處理。

（4）數據總線與電子病歷系統(EMR)信息一體化交互要求：實現****中心的臨床信息系統，提供電子病歷分級評價標準所需的支持。

（5）數據總線與移動護理、移動查房交互要求：應能通過數據總線平臺獲取患者基本信息、檢驗報告、檢查報告、手術麻醉信息、重癥監護信息等。

（6）數據總線與健康體檢信息管理系統（PEIS）交互要求：應能通過數據總線自動獲取患者基本信息，并能實現檢驗信息管理系統（LIS）與醫學影像傳輸與管理系統信息(PACS)等系統的信息交互。

（7）數據總線與手術麻醉、重癥監護系統的交互要求：應能通過數據總線快速地獲取患者基本信息和醫囑信息，手術麻醉記錄和重癥監護記錄完后可以通過數據總線為臨床其他系統進行調閱。

（8）數據總線與預約管理系統的交互：通過數據總線可以快速的獲取患者預約掛號信息，預約管理系統可以通過數據總線與各個業務系統進行預約與排隊信息的管理，完成就診預約、檢查預約、取消預約等功能。

（9）建立多途徑的消息機制，實現各系統間關鍵醫療信息自動提醒（如急診異常報告）、預警功能。
§3.1 服務總線組件
§3.1.1消息模型管理
具備對平臺運行服務相應的具體報文內容的消息模型進行新增修訂發布等管理功能。
§3.1.2 接入系統服務管理
支持對接入平臺的相關系統提供的服務接口進行配置管理，包括服務地址，協議類型。調用方法等內容。
§3.1.3服務場景路由管理
應實現對平臺所需支持的業務消息事件進行登記修改等功能，通過簡單的界面拖拉組件操作進行業務場景的編排配置。
§3.1.4總線入口服務
平臺應提供統一調用總線的服務入口，以規范平臺接入方對平臺服務場景的請求調用跟返回消息的標準化。

§3.2消息流處理引擎

▲消息流處理引擎應集成不同的衛生系統，提供安全連接，提供可靠的消息傳遞和高性能，應基于圖形化的開發，****醫院具體情況，添加修改消息接收節點。此外平臺針對一些無法提供技術改造的廠商提供數據接入支持。（提供投標人或軟件原廠商消息流引擎系統軟件著作權證書）

§3.3 HL7標準引擎

醫療組織在管理醫療數據集成需要的大量標準。要求本項目集成引擎的標準醫療通訊協議資料能夠完整齊全，并能夠需支持相關醫療標準的不斷更新，為平臺提供標準支持。

要求集成引擎嵌入協議標準（TCP、FTP、HTTP、網絡服務等等）；

▲需支持HL7(從版本2.x到3)，同時需支持臨床文檔架構（CDA）和連續醫護文檔（CCD）；（提供投****醫院信息集成平臺醫療鏈接包產品著作權證書）

需支持DICOM圖像格式轉換機應用；

需支持醫用信息系統集成（IHE）配置文件。

▲信息集成適配系統：對于非HL7傳遞標準的系統，集成平臺應具備集成適配器轉換能力，能將非標系統通過適配器系統轉換成基于HL7標準接入到集成平臺中。（提供投****醫院信息集成適配系統產品著作權證書）

§3.4 消息中間件

消息中間件應采用消息隊列技術，通過消息隊列，應用程序可獨立地執行，而不需要知道彼此的位置、或在繼續執行前不需要等待接收程序接收消息。

平臺應能通過使用消息中間件實現系統之間數據的快速交換、查詢、調閱等功能。

平臺同時應能提供消息中間件的配置管理功能：包括部署授權管理、數據轉換路由、開發集成環境。

§3.5主索引管理系統

平臺的主索引管理系統應能提供兩種匹配模式：在線精確匹配與離線模糊匹配。兩種匹配模式相輔相成，共同組成主索引服務。

▲支持在病人登記場景發生時，系統能夠自動捕獲該場景的病人基本信息，調用主索引服務。主索引系統執行在線精確匹配，根據精確匹配結果快速匹配相似的病人記錄，在線精確匹配結果需控制在500毫秒內。如果在精確匹配沒有匹配結果的情況下，系統應將該病人信息自動轉為離線模糊匹配，根據模糊匹配條件生成疑似匹配結果，然后由人工對其進行確認。（提供投標人或軟件原廠商患者主索引系統產品著作權證書）

§3.6 集成平臺管理系統

通過管理系統與信息集成引擎的對接，可對平臺需支持的組件、服務、事件及數據交換規則進行定義和配置。

§3.6.1 用戶管理

需具備完善的用戶管理功能，包括用戶、組的維護，針對不同用戶進行權限管理。

§3.6.2 組件注冊

組件注冊功能能對接入平臺的組件進行登記，只有注冊過的組件發送的消息才會被平臺所接受。

§3.6.3 服務注冊

支持對已注冊的系統，進行服務登記，這里所指服務是指系統對外需提供的服務。

§3.6.4 事件注冊

應實現對平臺所需支持的消息事件進行登記。

§3.6.5 消息過濾

應實現針對不同系統所需要的消息進行過濾。

§3.7 集成平臺日志監控系統

日志監控系統用來跟蹤和記錄通信歷史信息，為后續性能分析、問題分析提供必要數據基礎。

§3.7.1 通信日志

支持用戶通過時間，通信系統，通信內容，消息類型等作為檢索條件查詢相應的通信日志。

§3.7.2 異常日志

應提供異常日志，當消息流發生異常時產生錯誤日志，記錄在異常日志表中，主要用來分析錯誤原因。

§3.7.3 日志重發

當消息傳輸時由于網絡異常中斷，產生的異常日志，可通過日志重發功能重新發送傳輸異常的消息。

§3.7.4 日志歸檔

采用歸檔的形式將日志信息轉儲到另外的日志歸檔表中，保證日志表數據條數控制在一定數量級內，方便快速查找。日志歸檔需支持每日自動歸檔和手動歸檔兩種方式。

§3.8 服務總線組件§3.8.1消息模型管理

具備對平臺運行服務相應的具體報文內容的消息模型進行新增修訂發布等管理功能。

§3.8.2 接入系統服務管理

支持對接入平臺的相關系統提供的服務接口進行配置管理，包括服務地址，協議類型。調用方法等內容。

§3.8.3服務場景路由管理

應實現對平臺所需支持的業務消息事件進行登記修改等功能，通過簡單的界面拖拉組件操作進行業務場景的編排配置。

§3.8.4總線入口服務

平臺應提供統一調用總線的服務入口，以規范平臺接入方對平臺服務場景的請求調用跟返回消息的標準化。

§3.9服務總線集成引擎§3.9.1 HL7標準引擎

醫療組織在管理醫療數據集成需要的大量標準。要求本項目集成引擎的標準醫療通訊協議資料能夠完整齊全，并能夠需支持相關醫療標準的不斷更新，為平臺提供標準支持。

要求集成引擎嵌入協議標準（TCP、FTP、HTTP、網絡服務等等）；

需支持DICOM圖像格式轉換機應用；

需支持醫用信息系統集成（IHE）配置文件。

§3.9.2 消息中間件

消息中間件應采用消息隊列技術，通過消息隊列，應用程序可獨立地執行，而不需要知道彼此的位置、或在繼續執行前不需要等待接收程序接收消息。

平臺應能通過使用消息中間件實現系統之間數據的快速交換、查詢、調閱等功能。

平臺同時應能提供消息中間件的配置管理功能：包括部署授權管理、數據轉換路由、開發集成環境。

§3.10 集成平臺運維管控系統

通過管理系統與信息集成引擎的對接，可對平臺需支持的組件、服務、事件及數據交換規則進行定義和配置。

§3.10.1 平臺用戶及角色權限管理

需具備完善的用戶管理功能，包括用戶、組的維護，針對不同用戶進行權限管理。

§3.10.2 平臺審計管理

具備平臺管控端登錄及連接事件的活動日志的記錄查看功能。

§3.10.3 平臺菜單功能管理

支持對通過簡單靈活配置的方式對平臺管控界面掛載的系統菜單顯示進行配置的功能。

§3.10.4 平臺接口在線調試功能

具備針對新接入系統或者接口服務的在線聯調測試的功能。

§3.10.5 平臺在線說明文檔

平臺提供針對平臺服務**目錄及功能說明的在線查看功能。

§3.11 集成平臺日志監控系統

日志監控系統用來跟蹤和記錄通信歷史信息，為后續性能分析、問題分析提供必要數據基礎。

§3.11.1 通信日志

支持用戶通過時間，通信系統，通信內容，消息類型等作為檢索條件查詢相應的通信日志。

§3.11.2 異常日志

應提供異常日志，當消息流發生異常時產生錯誤日志，記錄在異常日志表中，主要用來分析錯誤原因。

§3.11.3 日志重發

當消息傳輸時由于網絡異常中斷，產生的異常日志，可通過日志重發功能重新發送傳輸異常的消息。

§3.11.4 日志歸檔

采用歸檔的形式將日志信息轉儲到另外的日志歸檔表中，保證日志表數據條數控制在一定數量級內，方便快速查找。日志歸檔需支持每日自動歸檔和手動歸檔兩種方式。

§3.12 集成平臺運行監控系統

管理員應可以從監控大屏中實時監控平臺運行狀態、接口狀態、診斷信息、性能圖表、交互消息量等。監控平臺與管理平臺都可以通過網絡瀏覽器方便訪問同時可作出簡便設置并觀測消息路由情況。運行監控平臺的功能主要包括：平臺服務器監控、性能監控、服務監控、日志監控、用戶告警等。

§3.12.1 服務器監控

▲支持對運行集成平臺的物理服務器性能的監控，包含所有在用或備用服務器的CPU使用率、內存使用率、網絡流量、硬盤吞吐量等關鍵指標。（提供投標人或軟件原廠商管控平臺產品著作權證書）

§3.12.2 總線監控

支持通過設 計系統名 稱的故障服務服務數/系統所有注冊服務數直觀展示給管理人員，說明總線當前運行的情況。

§3.12.3 場景監控

場景監控是指對企業服務總線軟件的運行狀況的監控，包含所有在用或備用服務的可用性、當日接收調用次數、當日發送消息次數，當日錯誤發生次數等關鍵指標。

§3.12.4 通訊點與路由狀態監控

支持實時監控ESB總線各系統組件的運行狀態，如發現故障可以及時排除故障。

§3.12.5 數據庫監控

實現對當日消息量和數據庫消息表空間使用率的監控。其中消息量監控包含業務流消息，字典服務消息的正常數量、異常數量和等待數量的監測。

§3.12.6 監控大屏展示

提供平臺監控指標大屏展示功能，整合平臺關注的服務器、總線、數據庫等相關運行指標情況向平臺管理人員進行直觀展示。

§3.12.7 平臺運行日報

平臺具備定時生成每日平臺運行狀況的統計日報匯總，指標包括服務交換情況，異常情況，數據庫表空間情況等。

§3.13 平臺告警功能組件

§3.13.1 平臺告警規則配置

平臺告警規則配置功能可以對每個交互事件場景的告警條件進行配置，**異常數達到多少，最大值超過多少等條件滿足的情況下將進行告警提醒；

§3.13.2 告警訂閱推送配置

平臺針對告警信息通知推送進行配置，配置內容包括推送目標人員的相關信息（聯系方式，人員等級等）以及通知推送規則，推送方式等信息

§3.13.3 告警信息通知接口對接

在項目現場有短信平臺或者微信公眾號等消息通知推送渠道的情況下，平臺可以提供告警信息通知接口適配對接的功能，根據現場實際情況對接短信、微信公眾號等消息通知接口。.

§3.13.4 告警事件日志

具備平臺告警事件的日志留存及時候查看功能。以供平臺管理人員針對告警信息進行問題分析及處理。

§3.14 主索引管理系統

平臺的主索引管理系統應能提供兩種匹配模式：在線精確匹配與離線模糊匹配。兩種匹配模式相輔相成，共同組成主索引服務。

§3.15 單點登錄系統

通過統一門戶認證，用戶不再需要每次輸入用戶名 稱和用戶密碼，也不需要牢記多套不同供 應 商的系統用戶名 稱和用戶密碼，從而改善用戶使用應用系統的體驗。

§3.16 臨床業務集成專題包

通過服務總線可實現平臺化的分層架構，****醫院臨床業務流程具備內置以下接入集成業務專題。將不同的臨床業務依據訪問頻度、性能要求、實時性要求、數據粒度,涉及的臨床業務系統等的要求進行架構分層。

根據現場業務實際情況平臺集成專題包接入包括：

（1）患者標識域(患者信息、建卡建檔相關的服務)

（2）門診就診域(門診掛號診斷等就診相關服務)

（3）住院就診域(住院入、出、轉相關服務)

（4）檢查業務場景集成（檢查申請單業務相關服務）

（5）檢驗業務場景集成（檢驗申請單業務相關服務）

（6）手術業務場景集成(手術申請相關業務服務)

（7）用血業務場景集成(輸血申請單業務相關服務)

（8）醫囑用藥業務場景集成(醫囑狀態交互)

（9）基礎字典集成域

§4、****中心§4.1 數據采集總線

需提供多種類型的采集手段，以滿足數據采集現狀的要求。需支持主流關系型數據庫，如Oracle、SqlServer、Mysql等。根據數據需求的實時性及業務系統的可操作性（如是否能開放日志捕獲等），同時支持實時采集、定時采集兩種主要技術模式。

實時采集總線，應基于日志的結構化數據復制機制，通過捕獲數據庫日志，處理、轉化并實時入庫。自動識別數據庫結構變更，當出現表結構發生變動時，需要能夠自動捕獲、生成對應語句并自動執行，實現全自動實時靜默同步，無需人工干預。除支持單表數據實時入庫外，應支持轉化數據以準實時（非定時任務）方式入庫。

定時采集總線，應基于ETL機制，能夠支持多種數據格式（如表、視圖等），同時支持在線配置清洗轉化邏輯。通過定時增量任務配置，實現定時采集轉化。

基于ETL定時采集總線，具體需實現以下功能：

1、支持ETL作業生成

支持用戶通過編寫ETL程序，并將程序生成批量運行的作業，并允許對作業進行調度管理。

2、支持拖拽方式可視化創建ETL過程

提供易于操控的可視化作業生成界面，降低編寫程序的難度，使用拖拽的方式，迅速編寫好ETL數據轉換作業，并且能看到作業過程。

3、支持對不同數據源進行轉換操作

允許用戶通過下拉列表對不同數據源，轉換方式，目標輸出地進行選擇。

4、支持同時對數據源進行多次操作

支持用戶對同一數據源進行多次不同類型的數據轉換操作。

5、支持對數據源的多次操作進行自定義排序

支持用戶對數據操作類型進行排序。

6、支持關系型數據庫輸出

7、支持用戶輸出數據轉換結果到關系型數據庫，允許用戶配置，表名字，每次處理的記錄數量，以及對于存在唯一主鍵或者索引的記錄處理方式(更新同一主鍵的其他字段或者直接替換)。

8、支持拖拽方式配置ETL作業的時候動態生成數據抽樣

支持用在在進行拖拽方式配置數據ETL轉換作業時候，動態生成數據抽樣結果，可以點擊點擊轉換對數據轉換過程進行實時查看，也可以編輯數據對樣本數據進行修改。

9、同時支持C/S端及WEB端配置ETL邏輯。

10、支持用戶設置數據ETL作業自定義變量

允許用戶設置自定義變量，使用變量替換區配置多個調度任務，每個調度任務里的參數可以不同。

11、支持用戶自定義作業調度周期

允許用戶填寫作業實際的調度策略，可以按小時，天，或者周等等。

12、支持用戶自定義作業運行時間

允許用戶定義數據開始的時間，作業結束時間。

13、支持ETL作業調度與管理

支持數據ETL轉換作業調度與管理提供列表式管理界面，讓用戶創建的轉換作業進行全局查看，提供作業狀態、隊列數、啟始時間，等等進行統籌管理。

§4.2 數據質量保障

數據質量校驗包括數據采集、數據加載、數據分發等過程中數據校驗。在數據采集過程中通過對數據源與目標數據庫之間的數據進行對比分析，從而進一步來分析、發現與解決在數據抽取過程可能產生的異常錯誤信息，同時完成數據缺失的修復。

數據接入校驗需具備將分散的、異構數據源中的數據如關系數據、非關系數據、數據文件等抽取到臨時中間層后進行解析、轉換、校驗、過濾、清洗、反饋。

數據校驗規則要求：數據校驗需求可以滿足不同的系統使用者從不同的角度對數據進行分析。校驗規則主要包括數據完整性、準確性、一致性三方面的規則。

數據校驗任務要求：定時的執行數據校驗規則，滿足對不同規則的執行方式進行設置，配置任務的觸發時間和執行時間。

數據轉換要求：不同業務系統之間、業務系統與共享數據庫保存的數據格式和語義可能都不一致，他們之間交換的數據需要通過數據轉換為平臺提供統一的可識別、可處理的數據。此外，通過數據轉換，可以方便地對海量數據進行編目及目錄轉換。

完整性控制要求：MD5 或者 HASH 校驗通過對接收的傳輸數據執行散列運算來檢查數據的正確性。計算出的散列值和隨數據傳輸的散列值比較。如果兩個值相同，說明傳輸的數據完整無誤、沒有被篡改過（前提是散列值沒有被篡改），從而可以放心使用。

數據過濾要求：支持對指 定數據源數據的字段清洗，通過配置對指 定數據源進行字段級別的清洗過濾；支持編碼格式轉換、特殊字符的處理；支持可配置的數據過濾框架，業務可以根據需要注冊數據過濾程序。

校驗結果展示要求：對采集結果進行校驗后產生的結果數據，將結果數據推送到服務配置端以供相關人員進行查看和分析。

錯誤數據反饋要求：針對殘缺數據、錯誤數據和重復數據支持即時反饋的功能，促使數據提供單位盡快地修正錯誤，同時也可以做為將來驗證數據的依據。

§4.3 數據存儲

系統需采用關系型數據庫保存，并遵循第三范式設 計存儲，對于非結構化的、文檔中的內容數據，系統應采用文件存儲或非關系型的存儲系統存儲。

§4.4 資產監控運維§4.4.1 采集進度監控

數據從來源到目標的采集過程當中，需實時的對當前采集的進度進行監控。

§4.4.2 狀態監測

監控內容需包括：進程狀態、網絡狀態、連接情況、應用狀態、異常狀態等。對采集端的監測，包括是否正常運行、在線離線的監測以及異常的環境匯總。

§4.4.3 異常處理

提供數據接口所有任務的運行監控功能、異常日志分析工具、異常任務處理和恢復功能：

需提供針對任務點的異常恢復，當運行的任務執行失敗時，可以重新運行任務（流程啟動）、從故障點運行任務（任務啟動）。

需支持對不符合接口規范的異常數據進行標記的功能，并將異常數據輸出到指 定目錄、提供數據質量統計分析報告（數據源、時間、成功記錄、失敗記錄（各種失敗類型分類記錄）等。

需提供可視化的任務運行日志管理功能，包括運行的日志詳細信息（成功、異常）。

§4.4.4 日志管理

支持對所有系統運行日志、操作日志、業務日志、異常日志進行保存，并提供相應的可視化查詢和操作功能：

需支持對系統運行詳細**、狀態、運行日志的可視化監控和維護，包括軟件狀態、數據傳輸、數據稽查等；

需支持對系統操作日志的記錄，包括時間、人員、操作模塊、操作類型、操作前參數、操作后參數等；

需支持基于異常日志重發機制。

▲需支持對業務運行日志的采集和匯總，基于Web 框架，支持查詢日志，并將采集日志進行歸檔匯總。(提供投****醫院統計信息管理系統軟件著作權證書)

§4.5 患者360視圖

支持通過集成視圖方式進行數據展現,能實現病人診療信息的統一展現，橫向以時間軸的方式顯示病人的體征、醫囑等信息，縱向以診療事件順序來顯示相關診病信息，如檢驗、檢查報告、手術記錄等信息，還應包括檢驗報告的趨勢分析、歷史報告對比分析等功能。

§4.5.1 多維度數據展現

系統需通過多種維度的數據組織方式，進一步挖掘數據價值，為臨床科室人員提供有效數據支持。

就診視圖：支持以就診主線組織數據，展現每一次患者對應的就診數據，包含診斷記錄，文書，體格體征，醫囑，檢查檢驗報告等信息。

臨床視圖：支持以臨床業務類型為主線組織數據，展現患者特定診斷類型的歷史數據，如檢查報告（歷史指標比對），歷史開藥記錄等。

§4.5.2 系統集成§4.5.2.1 患者主索引集成

支持整合患者主索引（EMPI），能夠將多種注冊渠道的患者，通過特定的規則，統一展現在患者360視圖中，實現相關數據的匯聚展示。

§4.5.2.2 共享文檔集成

▲支持針對患者的每一次就診記錄，均有對應的共享文檔記錄。患者360視圖將二者進行關聯結合，滿足國家后續關于就診數據共享交換的長期需求。（提供投標人或軟件原廠商醫療信息共享文檔庫系統產品著作權證書）

§4.5.2.3 閉環集成

支持通過集成院內閉環系統（含藥品閉環、手術閉環、檢查閉環、檢驗閉環、會診閉環、危急值閉環等），能夠直觀的從就診記錄中查看業務中閉環相關數據。

§ 4.5.3 基于低代碼后端配置

應能夠實現快速邏輯配置，無需重啟服務，滿足醫院系統快速上線、快業務邏輯迭代的需求。

§4.6 共享文檔管理系統

1.文檔管理：應實現文檔生成模板、生成邏輯、展示界面進行在線配置，實現共享文檔的生成、批量生成和下載。

2.模型與抽取：應實現共享文檔主題庫的抽取模型在線配置，實現共享文檔基礎數據實時抽取、轉化。通過配置計劃、任務，實現基礎數據定時轉化。

3.文檔校驗：應能夠基于共享文檔數據集中數據元對應的校驗規則（如是否必填、數值型、布爾型），對已生成的共享文檔進行數據批量校驗，形成分析報表。

4.系統配置：應實現文檔類型、視圖類型、關聯關系，每篇文檔基礎數據集及規則、脫敏規則等配置。

5.數據統計：支持對已生成的文檔實現圖表分析。同時允許配置多個數據源，比對原始數據和目標數據的數量，用于分析目標文檔生成總量是否符合預期。

§4.6.1 標準數據管理

應包括標準數據元管理、數據元值域管理、標準數據集管理。其中針對數據元管理可以進行增加、修改和刪除等操作。

▲根據數據標準的修訂，及時更新系統中數據標準信息。其中數據標準管理需包括對數據元、值域、數據集等管理。（提供投標人或軟件原廠商數據倉庫系統產品著作權證書）

§4.6.2 文檔生成

▲需提供可視化操作功能，配置文檔生成邏輯，生成對應共享文檔。生成邏輯與生成模板均可在線配置，即改即生效，便于現場實施人員快速、靈活完成共享文檔生成。(提供投標人或軟件原廠商醫療信息交換與共享平臺軟件著作權證書)

§4.6.3 數據抽取

共享文檔的基礎數據，需支持定時任務完成數據的自動抽取、轉化與清洗，也支持手動按照視圖/文檔機制實時完成數據抽取。系統需支持從線下C/S客戶端構建轉化模型后上傳系統，也需支持直接在系統中創建轉化模型。

§4.6.4 數據校驗

應實現對文檔的組成字段、字段規則（是否必填、是否滿足某種條件等）進行校驗。校驗可以單篇文檔校驗，也可以建立校驗組，實現批量校驗。通過掃描數據質量，可大范圍挖掘目前共享文檔距離國家標準的差距，同時可以定位具體存在的字段的源頭。

§4.7 主數據管理系統§4.7.1 術語注冊

支持對術語字典的名 稱進行登記，只有注冊過的術語才會被納入主數據管理范圍。根據衛生部數據標準規劃，注冊內容應包含，術語字典名 稱，編碼，版本，標準來源，標準更新日期。

§4.7.2 基礎字典管理

通過主數據管理系統實現全院基礎數據集中管理，實現主數據整合、共享和監管功能。基礎字典實現基于國家、衛生局等標準字典的維護。

§4.7.3 院內字典管理

基于院內各系統中非標字典的維護和管理。

§4.7.4 字典映射

基礎字典與院內字典之間，存在映射關系。為了統一語義，實現標準化，提供基礎字典與院內字典的映射維護及管理。

§5、 現有系統接入

▲****醫院前期投資，優化現有就診流程，實現數據無縫連接，需要在現有信息化軟件系統的基礎上，通過醫院信息化系統與信息集成平臺的對接改造，實現數據共享、標準定義、統一用戶管理、用戶統一系統入口等功能。（提供投****醫院信息單點登錄系統著作權證書）

應基于以下原則建設：

1、簡單，方便醫院維護及查找故障；

2、易于修改，避免雙方大規模修改程序或業務流程；

3、行業通用的，或國際標準的；

4、投標人應提供對接標準，由第三方業務系統提供數據，自行寫入其業務系統數據庫，投標人不操作對方數據庫；

5、盡可能的減少工作人員操作的步驟，盡可能從后臺實現。

★投標人應書面承諾，****醫院集成平臺能與招標方現有的HIS系統、檢驗系統、電子病歷系統等實現數據無縫連接與互聯互通，所有業務數據均能夠相互調閱實現流程的一體化應用，若需要第三方協助以接口方式實現的，則所有接口開發費用必須包含在本次投標報價中，招標方無需另行支付。

更正日期：2022年9月28日

三、其他補充事宜

四、凡對本次公告內容提出詢問，請按以下方式聯系

1.采購人信息

名 稱：****

地 址：**縣綏安鎮石齋北路19號

聯系方式：0596-****092

2.采購代 理機構信息（如有）

名 稱：****

地 址：**市**區新浦東路22****廣場1幢2407室-2414室

聯系方式：185****0032

3.項目聯系方式

項目聯系人：余先生

電 話：0596-****092

****

發布日期：2022年9月28日