投标分项报价一览表.docx
《投标分项报价一览表.docx》由会员分享，可在线阅读，更多相关《投标分项报价一览表.docx（63页珍藏版）》请在冰豆网上搜索。
投标分项报价一览表
投标分项报价一览表
序号
名称
品牌
规格
型号
技术
参数
单位
数量
单价
总价
产地及
厂家
1
县级健康大数据平台软件系统
懿加乐
YJLYUNv2.0
项目的主要研发内容
1.1、通过系统全面实现对鄢陵县每个社区健康体检检查数据进行统一管理，将与公共卫生平台进行对接，实现两边系统数据的共享与互联互通，避免医生的重复工作与不同系统平台数据的不一致性。
项目的组成模块
2.1、医生团队管理，健康数据管理，体检计划管理，数据流管理，
2.2、整个平台由数据中心服务器端软件、客户端和数据对接服务器端软件构成。
2.3、服务器端软件能够接受多个客户端的数据传输请求。
项目的技术特点
3.1、项目的系统架构需主要基于社区医院现有的工作场景，在不影响医生工作的前提下，实现健康一体机和管理系统数据的互联互通。
3.2、当工作人员使用终端进行数据采集、修改的时候，该数据会经过对接系统的分析对比，实时同步到社区信息平台的系统中，工作人员可以及时从社区信息平台系统查看采集和更新的数据。
技术框架
4.1、服务承载着前端数据信息交互的接口支撑、管理用户的数据分析及维护以及大数据服务信息的基础架构支持的责任，结合当前急剧膨胀的数据需求和实际服务中遇到的并发及集中流量的问题，系统的整体架构如下所示：
就具体实现技术而言，系统在服务端主要通过如下方式进行服务的组织和提供
4.2、tomcat：
作为当前WEB技术中最为常用的轻量级容器服务，在系统的应用服务中起着不可替代的作用，为适应系统不断膨胀和业务不断增长的资源需求，在构建时，引入了负载均衡的概念，实现Session共享机制，完成了分布式的构架，实现了很强的可伸缩性；
4.3、SpringMvc+Spring+MyBatis：
平台系统需采用WEB服务框架当前最流行的SMM三剑客进行业务逻辑架构，通过三者的无缝整合，实现完整的全流程服务，轻量、可靠、高效，同时完成了业务服务的模块化分离，可以面向用户提供云端定制化配置化管理服务；
4.4、SQLServer、Redis、平台从成本和定制化考虑，选择了当前开源领域商用效果最好的SQLServer数据库作为基础数据服务平台，同时根据当前数据的结构化特点，在具体的服务中引入Redis等服务作为补充，方便业务逻辑高效实现的同时，也为大数据分析提供了相应的数据保证；
健康体检数据判读模块
5.1、系统安全：
5.1.1、用户输入正确的用户名密码即可登录系统，登录系统中，系统会识别登录人的身份、权限，呈现不同的功能界面。
5.1.2、拥有高级权限的用户可对系统用户进行权限设置，对于不用的用户可设置不同的权限，以保障对判读系统数据的安全、准确、有效。
5.2、数据判读：
5.2.1、登录判读系统后，判读系统会实时的获取各个地方体检上传的数据信息，判读分为初审、复审、终审三个阶段，每个阶段可以分配相应的人员参与其中，对其结果进行数据判读，对于采集中采集的心电图，判读人员也可以进行修改。
5.2.2、在初审页面点击获取，如果有新采集到的数据就会在初审页面获取到，初审的数据会首先进行一个系统判读，对采集到的数据进行初步的判读，判读中可对采集不准确的心电数据进行编辑修改，以保障判读结果的准确性，初审判读完成的数据才会在复审界面展示，在复审页面获取到的结果会带有初审的判读结果，可以对初审的判读结果进行编辑，也可以写下当前判读的意见和建议，复审结束后进入终审判读，终审判读同复审操作相同，判读终止可以配置，可以根据自己的需要设置复审为最终判读结果，也可以设置终审判读为最终的判读结果，判读人员判读完成后，采用长连接心跳机制，会实时的将判读结果自动分配到指定的PC终端。
5.2.3、判读也可以采用自动判读机制，对采集的数据进行自动判读，自动判读参数都是根据参数标准值进行自动判读。
自动判读的时候，只是在初审的时候进行了自动判读，对从服务端获取的每一条数据所检测的每一项都进行自动判读，判读完成后才能进行复审判读，判读过程不会出现越级现象，之后的操作和人工判断过程一样保持不变。
5.2.4、整个判读过程是对采集到的数据进行进一步分析解剖，判读系统关联每一台一体机，一体机采集的数据上传到服务端后都会展示在判读平台上，判读结束以后，判读结果也会实时的展示在一体机上，以供体检人员进行查看。
5.2.5、对于判读的结果都会以体检报告的形式展现，最终的判读报告一份会发送到服务端，一份发送到提供相应数据的PC客户端上，对判读的结果也可以进行打印，生成一份体检报告。
5.3、统计管理：
5.3.1、对体检中的采集数量、上传数量、初审判读数量、复审判读数量、终审判读数量进行统计管理。
可根据时间查询某一时间段的统计结果。
5.3.2、判读完成后可以在健康数据报告查看判读结果，可根据姓名，性别，身份证号，时间等条件进行查询。
查询的判读结果可以进行打印。
5.3.3、判读平台存在自己相应的隐藏编号，用于保障采集数据的安全性，达到采集数据安全，准确无误。
采集的时候会带着这个编号发送到相应的服务端，每当判读系统获取数据的时候，只有拿着这个编号才能获取到采集的数据。
数据安全管理
6.1、数据安全隔离
6.1.1、系统软件应基于阿里云数据运作，安全解决方案需通过对数据访问请求进行多层隔离，以提高数据访问安全性。
此场景适用于：
6.1.2、对鄢陵县卫生及监管组织内不同岗位人员赋予不同数据库或数据表的权限。
6.1.3禁止使用人员在公网环境查询、修改生产数据。
6.1.4、对于指定的高保密级别字段进行脱敏处理，且此部分数据的访问需特殊授权。
6.1.4.1、DMS数据访问请求隔离要求：
1）、网络访问隔离：
DMS内置IP白名单设置功能，非白名单IP无法登录系统（企业VPN除外）。
2）、库表权限隔离：
DMS的权限系统将数据库与数据表分离，允许管理员仅赋予用户某些表的相应权限，而非全库权限。
3）、字段敏感性隔离：
DMS对字段进行三级安全定义，如果数据表中包含安全级别为保密及以上的字段，即使拥有表的相应权限也不能查看更改保密字段，保密字段默认以*展示。
4）、操作权限隔离：
DMS权限体系中，查询、导出、订正三个权限需要分别申请，以便权限的细粒度管控。
6.2数据操作管控
6.2.1、为防止生产数据被“蚂蚁搬家”式的盗取，系统平台需提供每人每日查询数据上限设置功能；同时为避免低效查询对生产数据库性能的影响，DMS识别危险查询并对齐进行拦截，以保证生产数据库安全。
6.2.2、通过DMS的限制可有效保障：
·数据不被窃取，此场景下可设置：
o单日最大执行次数限制
o单日最大返回行数限制
o单日最大订正记录数限制
o单笔查询返回记录数限制
数据查询过程中生产库安全，此场景下可设置：
o单笔查询执行时间限制
o大表全表扫描执行限制
6.3、数据日志审计
6.3.1、当组织内人员调离岗位需要进行离职审计，或者需要审计配合场景下，需要对特定员工、特定数据库进行多维度审计，系统平台可以通过搜索操作日志，可实现“张三在过去一年内做过哪些数据操作”及“A库在过去一个月内被执行过哪些操作”等多维度审计。
6.4、数据信息传输安全要求
6.4.1、在对数据信息进行传输时，应该在风险评估的基础上采用合理的加密技术，选择和应用加密技术时，应符合以下规范：
6.4.2、符合国家有关加密技术的法律法规；
6.4.3、听取专家的建议，确定合适的保护级别，选择能够提供所需保护的合适的工具。
6.4.4、机密和绝密信息在存储和传输时必须加密，加密方式可以分为：
对称加密和不对称加密。
6.4.5、机密和绝密数据的传输过程中必须使用数字签名以确保信息的不可否认性，使用数字签名时应符合以下规范：
6.4.6、充分保护私钥的机密性，防止窃取者伪造密钥持有人的签名。
6.4.7、采取保护公钥完整性的安全措施，例如使用公钥证书；
6.4.8、确定签名算法的类型、属性以及所用密钥长度；
6.4.9、用于数字签名的密钥应不同于用来加密内容的密钥。
6.5、数据信息安全管理职责
数据信息涉及各类人员的职责如下：
6.5.1、拥有者：
拥有数据的所有权；拥有对数据的处置权利；对数据进行分类与分级；指定数据资产的管理者/维护人；
6.5.2、管理者：
被授权管理相关数据资产；负责数据的日常维护和管理；
6.5.3、访问者：
在授权的范围内访问所需数据；确保访问对象的机密性、完整性、可用性等；
6.6、数据信息完整性安全规范
6.6.1数据信息完整性应符合以下规范：
1）确保所采取的数据信息管理和技术措施以及覆盖范围的完整性。
2）应能够检测到网络设备操作系统、主机操作系统、数据库管理系统和应用系统的系统管理数据、鉴别信息和重要业务数据在传输过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施；
3）应能够检测到网络设备操作系统、主机操作系统、数据库管理系统和应用系统的系统管理数据、鉴别信息和重要业务数据在存储过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施；
4）具备完整的用户访问、处理、删除数据信息的操作记录能力，以备审计。
5）在数据信息时，经过不安全网络的（例如INTERNET网），需要对传输的数据信息提供完整性校验。
6）应具备完善的权限管理策略，支持权限最小化原则、合理授权。
6.7、数据信息备份与恢复
6.7.1·当系统发生如下信息数据丢失：
逻辑错误：
包括软件bug、病毒攻击、数据块被破坏等。
·物理损坏：
包括服务器、磁盘损坏等。
·自然灾害：
火灾、地震等自然灾害对数据中心的摧毁等。
为了应对数据丢失造成的损失，系统必须具备对数据进行灾备保护的功能，
功能说明：
灾备是指容灾+备份：
·备份的定义：
指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全
·容灾的定义：
指在相隔较远的两地（同城或者异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换。
当一处系统因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。
一般数据从生产到存储，主要经过应用、中间件、数据库、操作系统、存储或者磁盘驱动、服务器硬件、网络、存储交换机到存储。
其中数据库的灾备设计尤为重要。
数据库的灾备主要技术流派包括备份、容灾等。
·备份：
o逻辑备份：
利用数据库的重做日志、归档日志，将主本所在站点的日志传输到副本所在站点，通过重做SQL的方式实现数据复制。
逻辑复制只提供异步复制，主副本数据的最终一致性，无法保证实时一致性。
o物理备份：
通过Redo日志或者归档日志在副本站点的同步或者异步持久化写、RedoApply来实现复制功能，同时副本站点的数据可以提供只读功能。
物理备份又可进一步细分为冷备与热备。
·容灾：
数据容灾是在备份的基础上，建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。
根据应对故障场景不同，容灾可分为同城容灾、异地容灾。
进行灾备解决方案设计时，需关注灾备的两个关键技术指标：
·RTO：
RecoveryTimeObject，恢复时间目标。
指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。
RTO是反映业务恢复及时性的指标，体现了企业能容忍的IT系统最长恢复时间。
RTO值越小，代表容灾系统的恢复能力越强，但企业投资也越高。
RPO：
RecoveryPointObject，恢复点目标。
指灾难发生后，容灾系统进行数据恢复，恢复得来的数据所对应的时间点称为RPO。
RPO是反映数据丢失量的指标，体现了企业能容忍的最大数据丢失量的指标。
RPO值越小，代表企业数据丢失越少，企业损失越小。
6.7.2、数据灾备设计
数据库备份DBS使用了数据传输DTS的增量数据流技术，可以实现实时的数据备份。
在线数据发生变化，数据库备份会获得变更的数据，并将数据实时写入云端OSS，帮助用户实现秒级RPO的数据备份。
6.7.3、秒级RPO
DBS通过使用数据传输DTS的实时数据流技术，可以读取数据库日志并进行实时解析，然后存储到云端存储上，实现对数据库的增量备份。
通常，DBS可以将增量备份的延迟控制在秒级别以内，根据实际的网络环境不同，延迟的可能会有不同。
在进行数据恢复时，可以使用存储的增量备份实现精确到秒的数据库恢复。
最大限度保障数据安全。
6.7.4、多环境支持
支持多种网络环境的数据库备份。
通过专线接入、VPN网关等接入技术，可以实现用户本地IDC数据库备份、ECS自建数据库的备份、RDS数据库的异地备份、其他云环境的数据库备份。
无论哪个环境的数据库，DBS通过自身的安全机制和实时数据库流技术，都可以向用户提供安全、秒级RPO的数据库备份解决方案。
套
1
1492000
1492000
中国
懿加乐通信科技（北京）有限公司
合计
大写：
壹佰肆拾玖万贰仟圆整 小写：
¥1,492,000.00
服务承诺
平台软件售后服务方案及承诺
1、方案说明
1.1对于本投标项目（大健康平台软件系统）将从如何实施、部署、培训、售后内容做出售后服务方案。
1.2在完全满足技术参数要外，我们还会积极配合采购人对本平台软件进行实施、维护、新需求开发、技术支持。
矚慫润厲钐瘗睞枥庑赖賃軔朧。
2、实施部署
2.1进度安排
本项目按合同签订后的时间为起点作详细进度安排：
工程内容
软件部署（15天）
技术支持（后一个月）
1
项目启动
2
制定实施方案
3
系统展示
4
新需求调研、分析
5
新需求研发、测试
6
部署完成
7
试运行
8
客户培训
9
正式运行
10
日常辅助
2.2人员安排
针对本项目设置项目协调组、设计及开发组、实施组，其中协调组的职责主要是与采购人进行商务沟通、负责合同签订、协调等；项目设计及开发组负责需求梳理、系统设计、代码开发、测试等；项目实施组负责系统部署、现场调试等工作。
聞創沟燴鐺險爱氇谴净祸測樅。
主要人员要求如下：
项目协调组
项目职务
专业范围
历程承诺
人数
备注
总负责
计算机
10年
1
副总级
项目经理
计算机
5年
1
商务经理
财会或商务
2年
1
业务辅导
医学或药学
2年
1
项目设计及开发组
技术总监
计算机
10年
1
项目经理
计算机
5年
1
技术工程师
计算机
2年
3
实施组
项目经理
计算机
5年
1
技术工程师
计算机
2年
2
2.3系统部署
2.4项目验收
在合同签字后15天内，投标人完成本项目中的安装部署、运行及各项实施要求，并保证功能正常使用。
在内部测试无误后将交由采购方对系统进行验收。
残骛楼諍锩瀨濟溆塹籟婭骒東。
初步验收：
初步验收标准为完成项目所有实施工作（包括系统集成和应用开发工作），可以组织项目初步验收工作。
（2）功能调整：
初步验收完成后进入功能调整期，功能调整时间为系统初步验收后开始计算（初步验收期间系统不稳定则功能调整期顺延）。
酽锕极額閉镇桧猪訣锥顧荭钯。
功能调整期由中标人负责，招标人配合，对系统按各项技术、指标、系统功能、使用范围等进行提出功能调整需求，确保在不增加新的大需求功能前提下，投标人有义务无偿根据招标人需求的变更，进行系统的变更调整。
彈贸摄尔霁毙攬砖卤庑诒尔肤。
升级会员 