浙江大学医学院附属义乌医院信息化工程开业前项目合格供应商征求公告

浙江大学医学院附属义乌医院信息化工程开业前项目

合格供应商征求公告

浙江省成套工程有限公司公司受浙江大学医学院附属义乌医院委托，就浙江大学医学

院附属义乌医院信息化工程开业前项目进行公开招标，现将本项目相关技术规范及服务要

求（详见附件）公布如下，欢迎各供应商根据本项目的特点和要求，编制并提供客观、真

实、有效的响应文件。

1、项目介绍

按照浙大附属义乌医院信息化工程开业前项目建设规划，以总承包商身份协调各子系

统建设单位、集成整合各专业信息系统、完成以系统集成平台为核心的，完整覆盖医院运

转所涉及的医疗、管理、患者服务等各业务环节的医院信息系统建设，为医院在2014年开

业奠定坚实的信息化基础。内容包括：

（1）医院信息化工程开业前项目建设总体规划和总包项目管理；

（2）医院各个信息化系统建设总集成；

（3）各子系统选型及建设实施。包括项目建设的总体设计、项目管理、开发实施、安

装调试、系统总集成、运行维护、培训和项目验收等。

2、资格要求

（1）在中华人民共和国境内注册，注册资金不少于人民币2000万元（含2000万元）,

具有独立法人资格，符合《中华人民共和国政府采购法》第二十二条规定的投标人资格条

件要求。

（2）具有较强的项目研发，系统集成、管理和组织实施能力。

（3）已取得国家工信部（原信息产业部）颁发的计算机信息系统集成资质。

（4）经有关机构认证通过的符合IS09000标准的质量保证体系，且在有效期内。

（5）2009年1月1日以来至少有一个独立承担的医疗信息化项目业绩（单个合同中应

用软件部分金额1000万（含）以上）。业绩证明材料包括：政府采购网的项目信息截屏、网址、

中标通知书及合同。

（6）自2010年1月1日（以法院的判决日期为准）至投标截止日前无行贿犯罪记录。

（7）本项目不接受联合体参加投标。

3、其他事项

各潜在供应商及有关单位请于2013年8月31日上午9时前（节假日除外）按照附件

要求将响应文件编制成册，密封并加盖公司公章后送至浙江省成套工程有限公司。

联系人：严桂0571-85100319传真

联系地址：浙江省成套工程有限公司，杭州市古墩路701号紫金广场A座1511室。

对逾期送达的供应商资料恕不接受，采购人将对收到的供应商资料组织相关专家进行

论证，选取符合要求的供应商入围。采购人不接受未按要求提供资料的供应商及论证后不

符合要求的供应商参与投标。

浙江大学医学院附属义乌医院

浙江省成套工程有限公司

2013年月日

附件:

浙江大学医学院附属义乌医院信息化工程开业前项目

合格供应商征求文件

采购人：浙江大学医学院附属义乌医院

招标代理机构：浙江省成套工程有限公司

时间：2013年8月

-3-

（-）响应文件的编制要求：

（1）法人授权委托书，法定代表人及授权委托人的身份证；

（2）通过年检有效的企业法人营业执照（副本）、税务登记证、社保登记证（副本）；非本地投

标人在浙江的分公司（如有，需提供本地工商注册登记资料）作为常驻服务和技术支持机

构。

（3）2012年度资产负债表、损益表；

（4）所有资质文件；

包括供应商已取得国家工信部（原信息产业部）颁发的计算机信息系统集成资质证书和软

件认证资质证书；

拟选用产品或开发项目的相关软件具有国家版权局颁发的计算机软件产品登记证书和计算

机软件著作权登记证书；IS09000质量保证体系认证证书，银行资信；政府部门（企业）或

第三方权威鉴定机构出具的信用等级证书或证明（如果有）；

拟选用产品如果不是供应商自己生产的自主产品，供应商应提供产品实际生产厂家的证明

文件，即提供该产品生产厂商针对本次项目的授权书及质量、服务承诺函等证明文件（注：

自主产品定义：软件产品必须提供国家版权局颁发的计算机软件著作权证书和计算机软件

产品登记证书，供应商与软件产品著作权拥有者可以是在同一个集团公司内部不同公司拥

有）。

（5）公司介绍及相关的主要业绩证明，2009年以来承担类似项目情况，参考合同或用户验

收报告等工程实例证明（以签订时间为准，原件备查，在专家论证期间，有权要求供应商

出具响应文件中的主要业绩证明原件：如合同或用户验收报告等，予以确认其的真实性和

有效性；

（6）政府采购领域中投标人在投标和项目履约期间是否存在不良行为记录（如果有）；

（7）针对项目的完整技术解决方案：

针对浙江大学医学院附属义乌医院信息系统建设需求的总体设计、建设、集成方案、

软件开发方案和产品选型依据及软件设备清单配置表、硬件设备清单配置表（内容包含品

牌、型号、数量等，格式自拟）。应明确构架设计（包括软件和硬件的系统架构）、系统平

台选择、各分系统选择及依据，软件部署等；对各系统软件要求提供基本属性说明（包括

开发语言（采用软件开发平台及开发语言）、软件架构（B/S、C/S、三层）、软件部署方式（C/S

结构要求自动分发）等）；系统采用的先进技术说明（是否模块化、SOA、。。等技术）；说

明拟采用的开发工具、开发方法等；是否符合医院信息系统建设对当前和未来发展的要求;

以及对功能设计和实施计划的建议。

（8）应对项目技术规范和服务要求中所提出各项要求进行逐条逐项的答复、说明和解释。

-4-

（9）针对本项目建设的详细实施计划，包括软件开发、安装调试、系统集成、试运行、测

试、调优、系统管理培训、系统运行维护培训等内容。本项目详细工作实施组织方案，包

括（但不限于）以下内容：组织机构、工作时间进度表、工作程序和步骤、管理和协调方

法、关键步骤的思路和要点。

（10）项目验收之前、验收之后的维护方案；针对本项目的系统运行维护方案，包括售后

服务机构及人员情况等。以书面形式完整准确地表述拟选用产品的原厂商的标准售后服务

承诺（范围、标准及期限等）、可能增加的服务承诺等。并明示服务承诺可能涉及的前提条

件，否则将被认为是无条件的。承诺货物升级、故障排除、性能调优、技术咨询等售后技

术支持服务情况。质保期内均提供免费上门维护、免费升级服务；

（11）投标人为完成本项目组建的工作小组名单，每个专业人员的情况和投入医院人员数

应该明确表示，明确各阶段投入人数，工作小组名单中的人员，须为公司的固定职员；每

个参加项目人员的履历表应随标书一并提交，主要内容包括学历、经验与业绩（包括从事

相关系统建设的经验，对每一个项目有一个简要的描述，该人员参与的时间以及在项目中

的责任）、职称或资质情况等；

（12）培训计划；

（13）验收方案；

（14）技术偏离说明表；

（15）投标人认为需要的其他技术文件或说明。

注：响应文件编制要求中提及的营业执照、税务登记证等企业资质证书、资质证书、项目

业绩及证明材料、计算机软件著作权证书和计算机软件产品登记证书、外购产品的厂商证

明文件等均需提供原件备查。

-5-

（二）项目技术规范和服务要求

一、项目概述

浙江大学医学院附属义乌医院位于浙江省义乌市，南邻金华市，北邻诸暨市，距省会杭州100公里。

医院规划占地12.62公顷，建筑面积16.6万平方米，计划投资10亿元。医院将建设成为拥有门诊楼、

医技楼、住院楼、感染楼、行政办公楼、国际健保楼、科教楼和专家公寓、值班宿舍、实习生宿舍及后

勤保障楼等楼群，集医疗、教学、科研、防保、康复、急救“六位一体”，功能多元化、服务现代化的

三级甲等综合性医院。

浙江大学医学院附属义乌医院位于义乌市春风大道与商城大道交叉口地块。义乌市是国际著名的商

品集散地，交通便利、气候宜人。本地人口70万，常住人口已经超过200多万，其中常驻包括国外客

商约2万人，国外流动客商达到60余万人次。另外义乌市周边地区金华市、诸暨市、东阳市.和其他市

部分居民，也可以享受到优质医疗服务，届时义乌医院的医疗覆盖人口将达到400万左右。

浙江大学医学院附属义乌医院按照医院的建设目标和战略定位，以义乌国际化商贸城市的人口经济

资源和区域特色为基础，依托浙江大学的人才和学科优势资源，吸收和借鉴国际先进的医院管理模式，

采用行业领先的医疗安全管理体系，建设一所高起点、高水平、国际化特色鲜明的现代化医院，为义乌

乃至浙中地区提供优质、安全、高效、价廉的医疗服务。

浙江大学医学院附属义乌医院是经浙江省卫生厅批准、义乌市政府全额投资、由浙江大学和义乌市

政府合作、浙江大学负责管理，按照三甲综合性医院标准设计建设的大学附属医院。

浙江大学医学院附属义乌医院是浙江大学首家异地建设的附属医院，力争通过10年努力把医院建设

成为学科齐全、品质一流、与国际接轨的、达到国家三级甲等综合性医院医疗水平的浙中区域重要医疗

中心；再用10年时间建设成为浙江大学医学学科重要的医疗技术研究和辅助医学教育基地。

浙江大学己成立附属义乌医院筹建组，并已开始组织运作。筹建组将按照医院的建设目标和战略定

位，以义乌国际化商贸城市的人口经济资源和区域特色为基础，依托浙江大学的人才和学科优势资源，

吸收和借鉴国际先进的医院管理模式，采用行业领先的医疗安全管理体系，建设一所高起点、高水平、

国际化特色鲜明的现代化医院，为义乌乃至浙中地区提供优质、安全、高效、价廉的医疗服务。

二、项目建设的目标和内容

2.1总体建设目标

浙江大学医学院附属义乌医院规划占地189.3亩，一期工程包括门诊楼、住院楼、行政办公楼、后

勤楼，设计建筑11万平方米，设800张床位，于2009年10月开工建设，2011年底已经结顶。目前，

幕墙、装修、设备安装等各项工程正在顺利有序进行中，预计2013年年底竣工。二期工程包括感染楼

-6-

和值班宿舍楼，建筑面枳L31万平方米，感染楼规划120张床位，建有感染、肠道、发热门诊，于2013

年5月开工建设，要求与一期工程同时完工。

按照浙江大学与义乌市的合作协议，浙江大学于2009年组建浙江大学医学院附属义乌医院，现已

招聘员工500余人，包括医生、护士、医技、行政管理等各个方面。开业后经过一到二年的发展，医院

最终达到1500余员工的规模。

浙江大学医学院附属义乌医院数字化医院的总体建设目标是“三个全面、一个基点”，即建设一

个实现“全方位、全过程、全员”信息化为目标、以医疗质量提高为基点的数字化医院。

医院的智能化建设为医院的信息化建设也提供了坚实的基础，其中全院覆盖的无线网络为移动医

疗和护理奠定通讯保证。

浙江大学附属义乌医院是一所全新的医院，医院的信息化建设没有历史的包袱，不存在陈旧系统

的升级改造和需求变更，具有立足在当今IT技术的前沿设计信息化系统的先天优越条件。浙江大学医

学院附属义乌医院招聘的新员工，年轻化比例较高，占到医院80%,其中博士、硕士学历组成医生队伍

的主体部分，这些在计算机网络下成长的新一代，对信息化具有自然的亲和力，具有熟练的计算机应

用能力，使医院减轻培训的压力，他们同时迫切要求医院信息化对医疗提供强有力的支持。

浙江大学医学院附属义乌医院是按照三甲综合性医院标准设计新建设的医院，因此在考虑医院整

体的信息化建设有区别其他医院信息化项目，需采取全面规划、分期建设的方法来推动本项目的开

展。针对义乌市的国际化特点，医院的信息化建设特别规划了双语文字，为义乌的国际贸易试点城市

提供医疗保健支撑服务。同时，信息化对医院准备在最短的时间内通过JCI的国际医院评审提供必需的

保证。

2.2数字化医院整体架构

-7-

数字化医院系统框架

临床/科研支持管理决策支持

核心平台

协

商

作

业

信息服务平台医

伙

院

远

伴—、

程

客

衽

区

医

户

临床数据中心CDR医

疗

关

废

、

救

系

区

护

管

域

信息集成平台车

国理

协

基础业务系统基础业务系统基础业务系统

同

（医疗管理）（行政管理）（行政管理）

「彦百理|「悟苔理|降百I心m九4{vpjfl家

庭

&肛院言理|日匕百理||药品管理|『匕甲皆||情L二也||「正一百匹I|仁空.仃匡|

|商庆】“kUS信息百理|1二F•力CHFSt息首忠|

信息安全与支撑系统

数字化医院建设是个庞大复杂的系统工程，完善的医院信息系统通常由上百个子系统组成，牵涉

众多的专业领域。这么庞大的系统需要非常专业化的软件开发分工，整合不同厂商各有特色的专业系

统是医院信息系统的发展趋势，医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度

共享。这些系统通常是来源于不同的厂家，基于不同的技术，为此集成整合这些异构系统需要一个灵

活科学的系统框架。

2.2.1系统框架总体要求

完整的数字化医院模型

采用国际领先的技术架构及平台，在逻辑设计及物理部属上采取多层结构，提高整个系统的可扩

展性及性能，适应医院信息化不断发展。

国际领先的电子病历系统

电子病历系统绝非简单的病历电子化，也不是仅仅实现结构化的病历编辑，而是通过所有临床信

息的融合，为临床、科研、管理、患者等各类人群提供综合性的支持服务，从而提高医疗质量、优化

工作流程、降低医疗成本和提高工作效率。

规范的信息集成平台

系统间的整合、集成和扩展一直都是制约医院数字化发展的主要障碍，由于不同厂商之间的产品

不兼容，使得医院整体信息化步履维艰。通过建设一个规范的系统集成平台，在1HE、DICOM,HL7等国

-8-

际标准的基础上，制定覆盖医疗所有业务流程的系统集成规范，开发基于规范的系统集成平台，为遗

留的、当前的，以及将来的系统提供了一个统一且标准的数据交换和工作流协同的平台。

标准、全面、开放的临床信息服务

虽然很多医院已经投入大量资金构建信息系统。但由于临床信息的分散存储、不规范和不完整，

使得信息无法很好地为科研、管理和临床决策服务。需开放可满足来自于科研、管理、患者的各种信

息需求的信息服务，同时，也可服务于远程医疗/区域协同以及医院客户关系管理（CRM）等各类应用。

完善的信息安全防护体系

信息安全在数字化医院中尤其重要，通过采用电子身份认证、电子签名、权限管理等多种技术手

段，使信息系统身份验证机制和医院整体的安全机制结合起来，形成医护人员的身份验证体系，从而

实现数据访问权限控制，保证医疗数据的安全。

先进的临床管理模式

以临床为核心、内嵌收费政策的临床管理系统，既能从专业的角度满足医生、护士的临床业务特

点，同时兼顾收费，在临床过程中完成II常计费。突破了目前国内以计费为核心的设计思想。提供以

患者为中心的临床信息系统展示界面，将患者的临床信息集中展示；建立医嘱的全流程管理，严格管

理医嘱的开立、审核、执行、计费、报告，记录所有医嘱过程，全面展示医嘱的全生命周期；为医

生、护士建立全面的临床工作流，将医嘱的执行拆分到不同的时段，使医生、护士的医嘱执行、计划

有序，工作内容一目了然；将患者历次就诊信息、健康记录信息进行二次加工处理，以临床视角方式

展示给医院医护人员（医生、护士等），可以方便进行历史记录对比分析、变化曲线分析；系统集成了

国外临床系统先进的诊疗特点；从发展的角度看，目前国内医院的收入比例会逐渐的由药品转向以医

疗服务为主，因此谁先取得临床服务质量的提高谁就会在未来的市场竞争中取得优势。为护士提供全

生命周期的护理评估、护理计划、护理执行方案，护理评估指导护理执行，同时护理执行结果又能对

护理评估形成反馈，及时调整护理计划。

以患者为中心的理念

建立全面的患者档案管理，而不是单纯的医嘱管理，将患者的就诊史、疾病史、过敏史、诊断过

程与医疗文书相关联，为医生提供全面的诊疗方案，降低医疗出错率；患者远程访问医院就诊信息，

使患者在家中就可以第一时间了解自己的健康记录；通过增加多种渠道的展示方式，将医院的出诊信

息、医生信息、患者的健康信息提供给患者。

降低医院成本、提高医院收入

对医院资源分类管理，对人、财、物进行精确管理、合理利用，为各种资源建立阀值、资源利用

率和资源使用定义；系统内置的医保策略工具，可及时分析医保数据，借助分析工具可以挖据医院的

-9-

潜在客户；通过合理分配医疗资源、提高系统运行效率，可以缩短原来的平均住院日，提高床位的周

转率，增加床位的使用效率。新业务模块的开发不需要重新进行结构调整，超前的设计理念使系统具

备了几乎所有的医院业务模型。

2.2.2技术特点

丰富的界面操作方式

界面采用以患者为中心的设计思想和以业务流程为中心的设计思想并重，在患者管理上将患者所

有的信息进行有效的集成，在流程处理上引入工作流的设计思想，流程处理方便快捷：提供多种录入

帮助方式，可以快速、准确定位数据；提供可扩展的查询条件选项，可深入过滤数据。

优越的系统性能

采用集群技术，分散计算压力，提高各个运算层面的计算效率；提供数据统计缓存方案，提高数

据统计重复访问效率；采用成熟的技术架构，封装数据操作，屏蔽因为程序员水平不齐所造成的系统

性能降低。

先进的集群技术

系统可以根据医院住院床位增加、门诊量增加，随需增加硬件投资，而不是替换原有硬件，最大

限度的保护医院硬件投资；客户端采用浏览器方式，不需要安装任何软件即可运行程序；应用服务器

和数据库服务器采用最先进的集群技术，最大限度的平衡负载。数据和访问的增加，不会引起运行速

度降低。

随时随地的信息访问

系统利用最新的互联网富客户端技术，提供远程访问能力，医生可以在家里浏览医嘱、病历等信

息，可以不受时间、空间的限制：患者可以在出院后远程访问医院提供的诊疗信息，及时浏览自己的

报告结果。同时保留和桌面系统一样的用户操作体验，提高了系统反应速度及性能。

优化的业务流程

系统可根据医院业务的流程调整、政策的变化，通过流程配置调整业务流向，而不用修改代码；

平台集成了高可伸缩性的业务流程管理引擎，能够自定义客户的业务流程，工作流程，集成流程等；

系统提供管理工具监视流程活动，业务流程的所有状态都有历史记录，并能及时看到流程进行状态。

快速的应用扩展

平台配备了灵活的及功能强大的集成引擎，用来定义处理集成数据及相互的约束规则。同时拥有

强大的管理配置工具，能够迅速完成各系统集成及开发：能够快速集成医院内部的各种数据，应用软

件，系统及设备；能够与其它合作伙伴连接，使其成为医疗信息交互中心集线器；提供一系列业务功

能及组件，能够使医院按照其需求配置与装配系统，不需要进行客户化代码开发；使用智能配置来满

-10-

足医疗机构的特殊需求，参数化的服务组件能够符合客户的管理行为及要求。

持续的升级能力

产品化发展模式，将全球持续发展的优秀的功能，引入到医院，提高医院的市场竞争力，产品将

统一进行版本管理，对医院提供长期的升级服务。

2.2.3软件层次架构

在过去传统应用系统开发过程中，CLIENT/SERVER体系结构得到了广泛的应用。其特点是，应用程

序逻辑通常分布在客户和服务器两端，客户端发出数据资源访问请求，服务器端将结果返回客户端。

但CLIENT/SERVER结构存在着很多体系结构上的问题，比如：当客户端数目激增时，服务器端的性能会

因为负载过重而大大衰减；一旦应用的需求发生变化，客户端和服务器端的应用程序都需要进行修

改，给应用维护和升级带来了极大的不便；大量的数据传输增加了网络的负载等等。

三层体系结构，是在客户端与数据库之间加入了•个“中间层”，也叫组件层。这里所说的三层

体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三

层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。

三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情

况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与

数据库进行交互。

随着分布式对象技术的逐渐成熟，多层分布式应用体系结构得到了越来越多的应用。应用系统只

有向多层分布式转变，才能最终解决CLIENT/SERVER结构存在的问题。在多层架构下，应用可以分布在

不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。将应用系统集成于分布式系统

之上，能极大地提高系统的可扩展性。为此，软件层次架构要采用三层或多层架构。

2.2.4IT硬件基础架构

为了更加稳定、高效、安全地支撑医院信息系统运行，医院需要搭建良好的1T硬件基础架构平

台，IT硬件基础架构平台示意图如下图所示，该示意图只是基本架构，实施厂家可以根据自身软件需

求进行深化设计。

建设要求

1、满足所有应用系统的资源需求

满足医院应用系统建设的资源需求，包括计算资源、网络资源、存储资源以及相应的安全、备份

优化解决方案。

2、保障医院所有应用系统安全运行

医院应用系统要受到良好的高可用保护，确保在任何情况下都能够安全、高效、可用。

3、降低系统管理复杂度

通过虚拟化技术，将IT基础设施环境下的大部分组件和部件虚拟化，统一整合和调度IT基础设施

资源，实现灵活的热插拔和统一管理，降低系统管理复杂度。

4、基础架构的灵活扩展

构建具有灵活扩展性的基础架构平台，保证未来三、五年以后，现在搭建的IT基础设施平台仍然

可以继续工作，使今天的投资始终不会浪费。

5、绿色环保

节能降耗，最大限度节省电力消耗。

6、数据保护

实现虚拟化计算环境下高级别的数据备份及恢复机制，并提供虚拟化计算环境下专业的防毒功

能。

技术要求

-12-

1、采用业界领先的服务器和桌面虚拟化技术架构，在保证经济适用性的前提下，适度超前，确保

较长时期内技术和架构的先进性，并保留较大的可扩展性，满足医院未来三年对系统性能和容量的需

求。

2、采用国际知名存储品牌统一数据存储和存储虚拟化引擎设备，统一管理数据中心内部的存储资

源，提供统一管理界面，支持Active/Active的使用模式，实现数据中心本地存储双活架构，提高业务

系统的可用性。

3、采用国际知名品牌RISC架构的企业级高性能服务器支持医院核心HIS应用系统，同时，对核心

HIS应用系统提供CDP持续数据保护，保障核心HIS应用系统安全、高效、可用。

4、提供虚拟化计算环境下专业的备份恢复解决方案，提供重复数据的删除功能，支持主流的数据

库Oralce、DB2、SQLSERVER等在线备份功能。

5、提供虚拟化计算环境下专业防病毒功能，确保应用系统信息和数据安全可靠。

2.3建设内容

项目通过引进新•代数字化医院信息系统，建立以电子病历为核心，基于信息集成平台，覆盖医

院所有业务和管理的完整体化医院信息系统，以及相关的软硬件配套设施建设。

2.3.1软件部分

编号分类产品与服务内容分项明细技术参数

1.患者信息存储详见下文要求

2.临床数据存储详见下文要求

3.临床业务数据梳理和建模详见下文要求

4.CDR集成引擎详见下文要求

5.临床数据中心(CDR)数据访问接口详见下文要求

6.患者主索引管理MPI详见下文要求

7.核心平台字典主数据梳理详见下文要求

8.临床数据集成视图详见下文要求

9.医学影像综合浏览详见下文要求

10.信息集成交换引擎详见下文要求

基于HL7标准的集成接口适配

11.信息集成平台详见下文要求

器

12.基于FTP的集成接口适配器详见下文要求

-13-

13.基于数据库的集成接口适配器详见下文要求

14.信息映射设计器详见下文要求

15.信息集成监控详见下文要求

16.数据同步引擎和服务详见下文要求

17.门急诊挂号系统详见下文要求

18.门急诊划价收费系统详见下文要求

19.住院收费管理系统详见下文要求

20.门(急)诊中西药房系统详见下文要求

21.住院药房系统详见下文要求

22.中西药库管理系统详见下文要求

23.入院管理详见下文要求

24.出院管理详见下文要求

医疗管理信息系统

25.基础业务住院转科管理详见下文要求

(H1S)

26.集中预约管理系统详见下文要求

27.床位管理系统详见下文要求

28.医保接口系统详见下文要求

29.物价收费管理系统详见下文要求

30.自助服务系统详见下文要求

31.病案统计管理系统详见下文要求

32.留观系统详见下文要求

33.门诊应急系统详见下文要求

34.其他基础业务系统详见下文要求

35.电子病历详见下文要求

36.护理电子病历详见下文要求

电子病历(门诊、住

37.门急诊电子病历详见下文要求

医院临床信息系统院)

38.电子病历质控详见下文要求

(CIS)

39.历史病历浏览详见下文要求

40.移动医生系统详见下文要求

移动医疗

41.移动护理系统详见下文要求

-14-

42.门急诊输液详见下文要求

43.重症监护重症监护系统详见下文要求

44.合理用药合理用药系统详见下文要求

45.手术麻醉管理手术麻醉信息系统详见下文要求

46.检验科管理系统详见下文要求

47.LIS系统实验室系统详见下文要求

48.血库系统（临床用血）详见下文要求

49.RTS（放射科信息管理系统）详见下文要求

50.PACS（影像存储与文档）详见下文要求

51.RIS/PACS系统超声管理系统详见下文要求

52.内镜管理系统详见下文要求

53.病理管理系统详见下文要求

54.电生理管理电生理管理系统详见下文要求

55.中心供应室管理中心供应室管理系统详见下文要求

56.院感监控院感监控系统详见下文要求

57.网站建设及管理软医院门户网站详见下文要求

58.件协同办公系统详见下文要求

59.HRP-人力资源管理系统详见下文要求

60.HRP-财务管理系统详见下文要求

61.行政管理信息系统HRP-后勤管理系统详见下文要求

62.（HMIS）综合运营管理平台HRP-设备管理系统详见下文要求

63.HRP-物资耗材库房管理系统详见下文要求

64.HRP-固定资产管理系统详见下文要求

65.HRP-人员权限管理详见下文要求

66.医保管理医保办管理系统详见下文要求

67.计算机操作系统详见下文要求

68.时间戳、操作系统数据库软件系统详见下文要求

计算机系统软件

69.、数据库系统等网络杀毒软件详见下文要求

70.电子签名认证系统详见下文要求

-15-

71.时间戳系统详见下文要求

72.短信支持系统详见下文要求

73.Office办公软件详见下文要求

74.数据字典详见下文要求

2.3.2硬件部分

根据软件规划和硬件基础架构的要求，投标人提供完整的硬件平台设计方案(包括配置清单和产品

选型)，如下内容做参考。

类别序号产品名称技术参数

服务器端

1.数据库服务器(1)详见下文要求

2.数据库服务器(2)详见下文要求

3.物理服务器详见下文要求

4.虚拟化服务器详见下文要求

5.服务器虚拟化软件详见下文要求

6.桌面虚拟化软件详见下文要求

7.HIS核心存储详见下文要求

8.HIS/PACS核心备份存储详见下文要求

9.存储虚拟化设备虚拟化安全产品

10.连续数据保护装置虚拟化安全产品

11.备份系统详见下文要求

12.虚拟化安全产品详见下文要求

13.运维软件详见下文要求

14.光纤交换机详见下文要求

用户终端

15.台式计算机详见下文要求

16.显示器详见下文要求

17.医用灰阶显示器(5M)详见下文要求

18.医用灰阶显示器(3M)彩色详见下文要求

-16-

19.医用灰阶显示器（3M）黑白详见下文要求

20.针式打印机详见下文要求

21.激光打印机（黑白）详见下文要求

22.激光打印机（彩色）详见下文要求

23.高速打印机详见下文要求

24.标签打印机详见下文要求

25.读卡器详见下文要求

26.移动手推车（医生）详见下文要求

27.移动手推车（护士）详见下文要求

28.PDA详见下文要求

29.PAD详见下文要求

注：用户终端数量暂不定。

2.4软件技术指标

2.4.1核心平台

（-）临床数据中心（CDR）

临床数据中心（ClinicalDataRepository,CDR）是电子病历系统的核心组成部分，通过对各类

临床数据进行标准化、结构化地表达、组织和存储，以及在此基础上开放各种标准的、符合法律规范

和安全要求的数据访问服务，为医院的各类信息化应用提供一个统一的、完整的数据视图，最终实现

辅助改善医疗服务质量、减少医疗差错、提高临床科研水平和降低医疗成本等主要目标。

在建立临床数据中心的过程中，标准化是一个非常重要的问题。标准化的数据类型、标准化的信

息组织结构、标准化的医疗术语集、标准化的数据访问服务能够满足各种应用系统的临床数据需求，

最大程度地支持不同系统之间的语义互操作，从而构建统一的医疗信息环境。

临床数据中心的建设必须符合如下要求：

>患者信息存储

1.为患者建立个人信息数据库，兼容符合国家卫生部有关患者基本信息数据集，授予唯一标识主

索引并确保与患者的基本信息主记录相对应。

2.病人信息可以包括：

1）自然信息：姓名、姓名拼音、曾用名、曾用名拼音、性别、血型、年龄、出生日期、出生

地等。

2）社会信息：身份、民族、籍贯、职业、工作地、婚姻、住址、联系方式、医保信息等。

-17-

3）健康信息：过敏史、遗传病史、传染病史、疾病史、手术史、输血史、用药史、免疫史、

月经史、生育史、家族史、职业病史、残疾情况等。

4）生活信息：抽烟史、酗酒史等。

3.对上述患者信息进行结构化表达、组织和存储，对外提供多种数据访问服务，如webservice、

1IL7等。

4.医院内部各系统能够共享患者主索引及基本信息。

＞临床数据存储

1.临床数据和患者信息数据采用分别建模。

2.临床数据存储患者诊疗活动过程中产生的文字和非文字资料。

3.诊疗活动中产生信息：

1）病人出入转记录：转入科室、医生、转入日期、转出科室、转出时间、出院时间、出院方

式、历次就诊记录等。

2）病情变化记录：起止时间、诊断、病情等。

3）病人体征信息：体温（口表、腋表、肛表）、心率、脉搏、呼吸、血压、瞳孔变化（左右

大小、左右光反应）、神志、血氧、血糖、中心静脉压、记录忖间等。

4）用药信息与执行记录：药品名称、规格、剂量、使用频次、给药途径、录入时间、使用的

起止时间、备注、开药医生、校对护士、执行护理、执行时间、执行频率、执行结果等信

息。

5）膳食记录：膳食名称、起止时间、备注等。

6）诊疗文书：首次病程记录、日常病程记录、首次查房记录、日常查房记录、会诊记录、交

（接）记录、阶段小结、转出（入）记录、术前讨论、术前小结、手术记录、术后病程记

录、抢救记录、出院记录等。

7）常规检查信息：放射、超声、内镜、病理、心电等信息。申请记录、检查记录、检查报告

记录。

8）医学影像资料：根据医院关于多媒体资料的存储策略，可支持集中存储或分布式存储（即

沿用原有影像中心）。集中存储时，存储放射、CT、磁共振、超声等医学影像信息，心电

图，录音，录像等。分布式存储时，即支持集成整合FullPACS中已建成的影像中心，实

现CDR中的检查相关记录和该影像中心中存储的影像文件关联访问。

9）实验室测试信息（检验记录）：种类、项目、检体、结果、日期。

10）费用与计价记录信息：计价项目、计价时间、记录者、执行科室等。

11）用血信息与记录：血型、采血日期、采血单位、献血者、包装、数量、审批人等。

12）手术记录信息：手术排班记录、麻醉记录、术后护理记录、切口信息。

13）护理记录信息：一般护理记录、特殊护理记录信息、危重护理记录信息。

14）诊断信息：诊断描述、诊断日期、诊断医生等。

-18-

4.对上述诊疗信息进行结构化表达、组织和存储，对外提供多种数据访问服务，如webservice、

HL7等。

5.医院内部各系统能够共享患者诊疗信息。

＞临床业务数据梳理和建模

1.为实现采集并存储医院现有临床辅助业务信息系统的最终临床数据到数据中心，对所有相关信

息系统的数据集进行梳理。

2.调研各业务信息系统的业务流程，数据流程，输出各系统的运行流程图、数据结构图。

3.梳理各系统间存在交集的信息集，输出各系统信息最小集，及各系统信息集和临床数据中心的

对照关系。

4.根据医院信息系统建设现状，调整和设计临床数据中心存储模型，并输出临床数据中心数据结

构手册。

＞CDR集成引擎

1.根据医院现有信息系统建设情况，结合上述数据梳理和数据建模，建设一套CDR集成引擎，实

现上述临床辅助业务信息系统数据到临床数据中心的集成。

2.集成引擎的实现方式包括提供数据库ETL工具，基于HL7、DICOM和WebService等接口技术实

现HIS、PACS,US等第三方业务系统数据到CDR的集成。

＞数据访问接口

1.公共信息

1）用户身份有效性验证

2）查询用户信息

3）查询指定用户的所有角色

4）查询指定用户的所有权限点

5）查询指定用户的指定权限点

6）查询当前计算机信息

7）查询检查科室

8）查询所有检查类型