| |
分类导航 |
 |
|
|
|
|
|
|
资源大小：87.25 KB |
资源类型：文档 |
|
下载积分： 0 |
|
|
|
-->
|
|
资源介绍 |
|
项目概况
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）对需要关联的模型，需要进行关联性查询。
|
|
|
下载地址 |
|
|
| |
|
|
