項目概況
1、項目背景：目前深圳市區域衛生計生信息平臺仍存在數據質量問題，主因仍然是異構系統和數據異構性，加之參與項目建設的供應商多，協調和管理困難等原因，導致數據集成的質量和可靠性難以保證。為了解決區域健康平臺數據質量問題，深圳市衛計委決定在各公立醫院建立醫療衛生機構數據融合平臺，以實現深圳市區域衛生計生信息平臺的資源共享、綜合信息的查詢統計與業務監管、高效的利用轄區內的醫療衛生計生資源、加強醫療衛生計生監督、提高醫療衛生計生服務質量等。
2、項目地點：深圳市
3、項目內容: 深圳市市級醫療衛生機構數據融合平臺
4、完工期限要求: 合同簽訂生效之日起4個月內完成；
5、合同方式：總價合同，包括深圳市公立醫療衛生機構數據融合平臺的維護費、實施費、技術培訓費、安裝調試費等一切相關費用；
6、項目質量要求：按國家標準驗收合格；
7、項目設計費、造價咨詢費、監理費等費用均不計入投標總價。
8、質量等級：優良。
二、技術要求
為貫徹國家醫療信息化建設和醫療改革相關文件指示和要求，為繼續深化衛生體制改革，進一步建立和完善區域衛生計生信息化體系，滿足深圳市衛生計生信息化工作目標，解決區域健康平臺數據質量問題，深圳市衛計委決定在各公立醫院建立市級醫療衛生機構數據融合平臺，以實現深圳市區域衛生計生信息平臺的資源共享、綜合信息的查詢統計與業務監管、高效的利用轄區內的醫療衛生計生資源、加強醫療衛生計生監督、提高醫療衛生計生服務質量等，具體要求如下：
1、數據融合平臺技術支持及維護服務：為深圳市衛生和計劃生育委員會、全市各公立醫療衛生機構數據融合平臺提供技術支持及數據庫維護服務。投入人員要求：
1.1技術支持工程師12位以上；
1.2數據分析工程師8名以上。
2、服務方式與運營保障：提供醫院駐點客服、電話客服等多渠道多方式為市級個醫院提供服務，保障服務暢通性。服務方式要求與運營保障投入人員：
2.1醫院駐點客服，與醫院作息同步，投入2名客服人員；
2.2電話客戶服務，24小時保持暢通，投入1名客服人員；
3、深圳市區域衛生計生數據融合平臺數據建設技術要求
3.1總體要求
數據中心
1）模型支持衛生部發布的《電子病歷基本架構與數據標準》。
2）有后標準化能力，通過清洗、轉換或映射，使得非標準化數據與元數據模型標準化無縫對接。
3）交叉支持多種國際開放標準、國標、衛生部行業標準和多種標準代碼體系。
4）支持不依賴于異構系統（不同數據庫、不同操作系統、不同架構、不同數據結構）供應商的數據層面的一體化集成（Data Unifying）。
5）構建的元數據模型須完全獨立于任何數據庫和存儲介質，支持元數據模型導出/導入，比如導出為XML文件，具有將模型快速部署到其他醫院的能力。
6）具有完善、成熟的元數據建模和模型管理工具和數據集成ETL工具，并能依賴工具進行絕大部分數據一體化整合，對特別的異構系統不能完全依賴可視化圖形用戶界面進行數據集成時，支持輔助性人工編程。
7）平臺應該提供開放的編程接口，支持基于平臺的應用系統開發。
8）提供完整的庫結構說明文檔。
3.2數據一體化整合
1）具有完善、靈活、有效的病人身份整合算法，對不同異構系統中的患者身份進行一體化整合。
2）根據標準化數據模型，對異構系統的字典進行一體化整合。
3）基于標準化模型、一體化的患者身份和數據字典，將醫院散落于各種異構系統的歷史數據一體化整合為以患者為中心的、符合衛生部《電子病歷基本架構與數據標準》要求的電子病歷庫。
4）提供準實時數據集成系統，支持對異構系統產生的新數據的整合集成。
3.2.1支持區域醫療系統的數據采集
1）支持獨立于具體異構信息系統的區域衛生信息系統互聯，實現基于平臺的數據上傳。
2）為區域數據采集上傳系統和醫院異構信息系統松綁。區域數據采集范圍、結構、需求的變化不再需要調整HIS、LIS等異構系統的接口程序。
3.2.2整體技術路線和系統架構
1）提供對國際，國內同類系統建設（包括技術路線、建設成本、運維成本、風險控制等）的分析和比較。
2）提供對如下關鍵點進行分析：需求關鍵點、關鍵技術難點、非技術性難點。
在對需求關鍵點，技術難點的分析的基礎上，提供整體技術路線。
3）提出完整而詳細的系統架構，并通過系統架構方案體現技術路線的特點。
4）從系統整體架構角度提供系統的可擴展性的技術路線和實現方法。
5）從系統整體架構角度提供數據安全管理解決方案。
6）從系統整體架構角度提供如何支持應用軟件開發/投放/升級/運維管理。
7）醫院數據整合平臺支持主流數據庫，包含：DB2、Oracle、Sybase、SQLServer。
8）醫院數據整合平臺支持Windows、Linux、Unix等操作系統。
3.3 一體化數據集成的ETL數據抽取工具/平臺軟件
3.3.1支持不依賴于異構系統（不同數據庫、不同操作系統、不同架構、不同數據結構）供應商的數據一體化集成，這里所述的一體化是指數據模型層面進行一體化數據融合（Data Unification），而非簡單的聚集（Data Aggregation）的數據集成。
3.3.2工具軟件支持通過可視化、圖形用戶界面進行絕大部分數據一體化整合，對特別的異構系統不能完全依賴可視化圖形用戶界面進行數據集成時，支持輔助性人工編程。
3.3.3具有完善、靈活、有效的個人身份整合算法，支持對海量歷史數據，特別是標準化缺失的歷史異構數據的整合。
3.3.4數據整合工具提供的一體化整合，不能依賴于對已經在線運行的異構系統進行改造升級，例如標準化改造，須有一定的后標準化能力，通過清洗、轉換或映射，使得非標準化數據與元數據模型標準化無縫對接。
3.3.5通用ETL工具必須具有針對醫療衛生領域信息化的功能擴展，支持醫院常見的HIS、LIS、RIS、PACS、EMR、病案等醫療信息系統的數據清洗、轉換和集成。既支持對歷史數據的整合，也支持運行時實時數據同步/整合。實時數據同步功能需要具有運行狀態留痕或監控功能。
3.4元數據管理工具
3.4.1直接支持基于元數據，或基于領域概念（類似于Achitypes二階建模）建模、支持基于元數據的復雜醫療健康領域信息模型，避免完全依賴人工建模，造成數據模型異構、數據異構問題。
3.4.2支持元數據模型和數據庫物理模型的映射，支持應用系統直接通過元數據模型，而非數據庫的物理數據模型進行數據集成、計算、搜索、存取等操作。
3.4.3工具應自帶衛生部發布的《電子病歷基本架構與數據標準》中規定的行業標準數據元。
3.4.4交叉支持多種國際開放標準、國標、衛生部行業標準和多種標準代碼體系。
3.4.5具有完善、成熟的元數據建模和模型管理用戶界面。
3.4.6元數據模型工具須支持自動生成支持各種關系數據庫物理模型的功能。
3.4.7構建的元數據模型須完全獨立于任何數據庫和存儲介質，支持元數據模型導出/導入，比如導出為XML文件，具有將模型快速部署到其他數據醫院的能力。
3.4.8元數據管理工具須經過市場實例驗證，具有良好的成熟度、可靠性、可擴展性。
3.5數據安全管理軟件
提供基于ACL的多粒度數據安全管理機制。
3.6醫院現有的HIS、LIS、RIS、PACS、EMR、病案系統數據一體化整合
3.6.1身份整合
1）必須一體化整合歷史數據和新的、基于身份唯一標識的數據。
2）歷史數據身份整合不依賴于現有系統改造。
3）身份整合應該具有足夠的可擴展性和可進化性，整合后的數據不會由于技術進化而不得不進行返工或大規模改造。
4）支持建立病人注冊服務。
3.6.2醫院異構系統數據整合
1）在數據抽取過程中，不需要第三方寫數據接口。
2）在數據整合過程中，能夠對異構數據進行標準化代碼轉碼。
3）整合結果需支持區域數據上傳。
3.6.3數據質量控制
1）支持對抽取到醫院數據中心的數據與原始數據的條數對比。
2）程序設置分頁時須考慮臨界條件，避免丟失數據。
3）須對原始數據的無效數據做出篩選。
4）支持對可能產生字符串超長的字段合理截取。
5）支持對原始數據中的關鍵字段要做處理，防止因醫院數據中心或者上傳的前置機因非空約束倒是數據丟失的情況。
6）對抽到醫院數據中心的數據，要求隨機挑選幾條數據做對比，防止因程序不當而引起的數據錯誤。
7）須對抽到醫院數據中心的數據，每張表的關鍵字段進行非空或者指定類型的數據判斷。
8）對需要關聯的模型，需要進行關聯性查詢。
|
|
資源大�。�87.25 KB 
