北京大学第一医院宁夏妇女儿童医院(宁夏回族自治区妇幼保健院)国家妇儿区域医疗中心—北京大学第一医院宁夏妇女儿童医院建设项目(智慧后勤综合服务平台、智能可视...

北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区 妇幼保健院） 国家妇儿区域医疗中心—北京大学第一 医院宁夏妇女儿童医院建设项目 （智慧后勤综合服务 平台、智能可视化管理平台）1（项目名称） 服务类政府采购公开招标文件 采购人：北京大学第一医院宁夏妇女儿童医院（宁夏回族自 治区妇幼保健院） 采购代理机构：中天世纪国际招标有限公司 2025 年3 月 目录 第一章投标邀请 第二章供应商须知前附表 第三章供应商须知 第四章项目说明和采购需求 第五章资格审查方法及标准 第六章评标方法和标准 第七章政府采购合同主要条款 第八章投标文件格式 第一章投标邀请(招标公告) 一、项目基本情况 1.政府采购计划编号：2025NCZ000605 2.项目名称： 北京大学第一医院宁夏妇女儿童医院 （宁夏回族自 治区妇幼保健院） 国家妇儿区域医疗中心—北京大学第一医院宁夏妇 女儿童医院建设项目 （智慧后勤综合服务平台、 智能可视化管理平台） 1 3.项目编号：D6400-20250324000004 4.采购方式：公开招标 5.预算金额（元） ：2250000.00 6.最高限价（如有） ：2250000.00 7.采购需求： 采购标段 标的名称 品目名称数量简要规格描述或项目基 本概况 预算金额(元) 备注 一标段： 智慧后勤综合服务平台、 智能可视化管理平台 行业应 用软件开发服务行业应用软件开发服务1 具体内容详见招标文件 2250000.00 数量合计：1 预算合计：2250000.00 8.合同履行期限：项目实施周期：自项目合同签订之日起，3 个 月内完成 9.本项目（是/否）接受联合体投标:否 二、申请人的资格要求： 1.满足《中华人民共和国政府采购法》第二十二条规定，应提供以下 材料： 1.1 提供在中华人民共和国境内注册的法人或其他组织的营业执照 （或事业单位法人证书，或社会团体法人登记证书） ，如投标供应商 为自然人的需提供自然人身份证明； 1.2 法人授权委托书、 法人及被授权人身份证复印件 （法定代表人直 接投标可不提供，但须提供法定代表人身份证复印件） ； 1.3 提供具有良好商业信誉和健全的财务会计制度的承诺函； 1.4 提供履行合同所必需的设备和专业技术能力的证明材料（承诺 函） ； 1.5 具有依法缴纳税收和社会保障资金的良好记录的承诺函； 1.6 提供参加采购活动前三年内在经营活动中没有重大违法记录的 书面声明（承诺函） ； 2.供应商在中国政府采购网（www.ccgp.gov.cn）未被列入政府采购 严重违法失信行为记录名单，在“ 信用中国” 网站 （www.creditchina.gov.cn） 未被列入失信被执行人、 重大税收违法 案件当事人名单（开标现场查询） ； 3.本项目（是/否）专门面向中小微企业：否 4.合格投标供应商的其他资格要求： 无 5.落实政府采购政策需满足的资格要求： （1)《政府采购促进中小企业发展管理办法》 （财库〔2020〕46 号） 、 《关于进一步加大政府采购支持中小企业力度的通知》 （财库 〔2022〕 19 号） 、 《关于落实政府采购促进中小企业发展有关措施的通知》 （宁 财（采）发﹝2022﹞275 号） ； （2)《财政部司法部关于政府采购支持监狱企业发展有关问题的通 知》 （财库〔2014〕68 号） ； （3) 《财政部民政部中国残疾人联合会关于促进残疾人就业政府采 购政策的通知》 （财库〔2017〕141 号） ； （4） 《国务院办公厅关于建立政府强制采购节能产品制度的通知》 （国 发办〔2007〕51 号）、 《关于印发节能产品政策采购品目清单的通 知》 （财库〔2019〕19 号） ； 《关于印发环境标注产品政府采购品目清 单的通知》 （财库〔2019〕18 号） ； 《关于调整优化节能产品、环境标 志产品政府采购执行机制的通知》 （财库〔2019〕9 号） ； （5） 《财政部 生态环境部 工业和信息化部关于印发 〈绿色数据中 心政府采购需求标准（试行） 〉的通知》 财库〔2023〕7 号、 《宁夏 回族自治区财政厅住房和城乡建设厅工业和信息化厅关于印发 〈政府 采购支持绿色建材促进建筑品质提升试点工作方案〉的通知》 （宁财 （采）发﹝2023﹞161 号） ；执行创新发展相关政策； 《自治区财政厅 人民银行银川中心支行关于印发 〈宁夏回族自治区政府采购合同信用 融资管理办法〉的通知》宁财规发﹝2021﹞10 号。 三、获取招标文件 时间：2025-03-25 至2025-04-03（提供期限自本公告发布之日 起不得少于5 个工作日） ，每天上午00：00 至12:00，下午12:00 至 24:00（北京时间，法定节假日除外） 地点：中国政府采购网、宁夏回族自治区政府采购网、宁夏回族 自治区公共资源交易网 方式：电子下载 售价：0 元 四、提交投标文件截止时间、开标时间和地点 2025-04-17 09:00（北京时间） （自招标文件开始发出之日起至 投标供应商提交投标文件截止之日止，不得少于20 日） 地点： 宁夏回族自治区公共资源交易服务中心 （宁夏回族自治区 银川市金凤区北京中路瑞银财富中心B 座） 五、公告期限 自本公告发布之日起5 个工作日。 六、其他补充事宜 1.参加投标供应商，请于“获取招标文件时间内”登录宁夏回族自治 区公共资源交易网（二期） ，通过CA 锁进行网上登记，登记成功后， 不要拔锁，按系统提示即可下载电子版招标文件。 2.在完成以上步骤后，系统会自动显示保证金缴纳帐号及相关信息， 请按系统提示缴纳投标保证金。 3.宁夏公共资源电子交易系统实行CA 锁认证安全登录管理， 请及时 将软硬件升级更新至最新版本。 办理CA 锁业务及CA 锁升级更新等 事宜请咨询西部安全认证中心有限责任公司， 联系电话： 4008600271 按1 键咨询， 办理地点： 银川市金凤区北京中路49 号瑞银财富中心 B 座23 层2305 号西部安全认证中心数字证书受理中心。 4.未在规定时间内按以上程序进行网上报名登记及下载招标文件的 投标供应商，投标一律不予接收。 5.本项目为电子招投标项目， 投标人须使用国泰新点投标文件制作软 件（宁夏版）专用工具查看招标文件、编制生成电子投标文件，在投 标截止时间前按招标文件的要求在交易系统中上传加密电子投标文 件，投标人开标当天持制作电子投标文件所使用的CA 锁至开标现场 进行解密， 未按要求到达现场进行解密的视为放弃投标资格， 投标文 件将予以退还。 如因投标人自身原因未按照招标文件相关要求操作导 致投标失败的，后果自行承担。 6.发布媒介：本次公告在中国政府采购网、宁夏政府采购网、宁夏公 共资源交易网同时发布。 7.招标代理费：参考原国家计委计价格【2002】1980 号文和国家发 改委发改办价格【2003】857 号文的计算方法收取，由中标人支付。 8.请各投标人在开标前随时关注中国政府采购网、 宁夏政府采购网、 宁夏公共资源交易网。 您所关注的项目有可能进行时间或内容上的调 整。 调整内容以公告形式公示， 采购人及招标代理机构不再以其他方 式通知。如因自身原因未及时关注招标公告或更正(澄清、补充等) 公告从而导致投标失败，其后果自行承担。 七、对本次招标提出询问，请按以下方式联系 1.采购人信息 名称： 北京大学第一医院宁夏妇女儿童医院 （宁夏回族自治区妇 幼保健院） 联系人：宁老师 地址：银川市金凤区湖畔路127 号 联系方式：0951-7895887 2.采购代理机构信息 名称：中天世纪国际招标有限公司 项目负责人：庞文娟、王铎 地址：银川市金凤区新昌西路金钻名座财富中心13 层 联系方式：0951-5606216 代理机构： 中天世纪国际招标有限公 司 2025-03-25 第二章供应商须知前附表 本表是项目的具体资料，是对投标供应商须知的具体补充和修 改，如有矛盾，应以本表为准。 序号 内容 1 项目名称：北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区 妇幼保健院）国家妇儿区域医疗中心—北京大学第一医院宁夏妇女 儿童医院建设项目 （智慧后勤综合服务平台、 智能可视化管理平台） 1 合同履行期限：项目实施周期：自项目合同签订之日起，3 个月内 完成 2 采购人：北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区妇 幼保健院） 联系人：宁老师 地 址：银川市金凤区湖畔路127 号 电 话：0951-7895887 3 采购代理机构：中天世纪国际招标有限公司 地址：银川市金凤区新昌西路金钻名座财富中心13 层 项目负责人：庞文娟 电话：0951-5606216 邮箱：ztsjzb2@126.com 4 合格投标供应商的资格要求： 1.满足《中华人民共和国政府采购法》第二十二条规定，应提供以 下材料： 1.1 提供在中华人民共和国境内注册的法人或其他组织的营业执 照（或事业单位法人证书，或社会团体法人登记证书） ，如投标供 应商为自然人的需提供自然人身份证明； 1.2 法人授权委托书、法人及被授权人身份证复印件（法定代表人 直接投标可不提供，但须提供法定代表人身份证复印件） ； 1.3 提供具有良好商业信誉和健全的财务会计制度的承诺函； 1.4 提供履行合同所必需的设备和专业技术能力的证明材料（承诺 函） ； 1.5 具有依法缴纳税收和社会保障资金的良好记录的承诺函； 1.6 提供参加采购活动前三年内在经营活动中没有重大违法记录 的书面声明（承诺函） ； 2.供应商在中国政府采购网（www.ccgp.gov.cn）未被列入政府采 购严重违法失信行为记录名单，在“ 信用中国” 网站 （www.creditchina.gov.cn）未被列入失信被执行人、重大税收违 法案件当事人名单（开标现场查询） ； 3.本项目（是/否）专门面向中小微企业：否 4.合格投标供应商的其他资格要求： 无 注：1.投标人应将上述资质要求扫描件放入电子投标文件中相应位 置，并加盖投标人电子公章，否则视为投标无效。 2.投标人须保证上述资料完整并清晰可辨，如出现模糊无法辨认的 情况，视其为不合格资料。 3.以上（1.3）-（1.6）项投标人可选择提供资格承诺函并加盖投 标人电子公章，也可选择按《中华人民共和国政府采购法》《中华 人民共和国政府采购法实施条例》及招标文件资格要求提供相应的 证明材料，若二者均不提供，视为投标无效。 5 专门面向中小微企业： （是/否）□是☑否 （专门面向中小企业采购， 供应商需出具 《中小企业声明函》 ， 未出具 或未按规定填写不完整的 （如产品制造商不全等） ， 视为未提供 《中小 企业声明函》 ，专门面向中小企业采购的项目或者采购包，中小企业 不再执行价格评审优惠扶持政策。 ） 6 根据工信部联企业〔2011〕300 号文件；本项目所属行业为： 1.非专门面向中小企业采购： （1）中小微企业参加宁夏政府采购招投 标活动， 参照 《政府采购促进中小企业发展管理办法》 (财库 （2020)46 号） 和 《关于落实政府采购促进中小企业发展有关措施的通知》 （宁财 规发【2022】275 号）文件执行，小型和微型企业应提供《中小企业 声明函》 ，对报价给予10%的扣除，用扣除后的价格参与评审。 （2）按 照 《财政部、 司法部关于政府采购支持监狱企业发展有关问题的通知》 （财库〔2014〕68 号） ，监狱企业视同为小型、微型企业，监狱企业 应提供证明文件，对报价给予10%的扣除，用扣除后的价格参与评审； （3） 企业分支机构参与投标， 需提供总公司出具的 《中小企业声明函》 、 《残疾人企业声明函》 ，分支机构提供的声明函不参与价格折扣。 7 是否允许联合体投标：否 8 联合体的其他资格要求：/ 9 项目预算金额：2250000.00 元；最高限价：2250000.00 元（如有） 10 报价方式：☑总价 □单价 □费率 □折扣 11 投标保证金：0 元 缴纳时间：投标截止时间前 投标保证金缴纳方式： 本项目不收取保证金 12 是否组织现场考察或者召开答疑会：□是☑否 组织现场考察或者召开答疑会相关要求： / 13 投标有效期：提交投标文件截止之日起不少于60 自然日（日历日） 14 投标文件（电子/纸质）提交截止时间：2025-04-17 09:00 投标文件提交地点：宁夏回族自治区公共资源交易网。注：加密电 子投标文件通过宁夏回族自治区公共资源交易网—宁夏公共资源 电子交易系统上传、递交。 15 开标时间：2025-04-17 09:00 开标地点：宁夏回族自治区公共资源交易服务中心（宁夏回族自治 区银川市金凤区北京中路瑞银财富中心B 座） 16 评标方法：适用综合评分法 17 推荐中标候选人的数量：3 名 18 招标人是否委托评标委员会直接确定中标供应商：☑是□否 定标原则:采购人按评审报告中推荐的中标候选人排序确定中标 人。 本项目评标委员会由7 人组成，其中评委专家5 人，评委专家从专 家库内随机抽取，采购方评委2 人。 19 是否提交履约保证金：☑是□否 履约保证金金额：合同总价的5%（不得超过政府采购合同金额的 5%） 提交履约保证金的时间：签订合同前15 个自然（日历）日 履约保证金有效期：自合同生效之日起至合同约定的中标或成交供 应商主要义务履行完毕止， 履约保证金提交方式：应当以支票、汇票、本票或者金融机构、担 保机构出具的保函等非现金形式提交 20 是否收取招标代理费：☑是□否 是否由中标供应商缴纳招标代理费：☑是□否 招标代理费：参考原国家计委计价格【2002】1980 号文和国家发改 委发改办价格【2003】857 号文的计算方法收取，由中标人支付。 （如收取，需明确招标代理费收取标准） 收取形式：转账 招标代理费缴纳账号：账户名称:中天世纪国际 招标有限公司银川分公司 账号：106075274575 开户行:中国银 行股份有限公司银川市海宝路支行 收取时间：2025-04-22 21 质疑供应商应在法定质疑期内通过“宁夏回族自治区政府采购网” “政府采购在线质疑投诉系统”一次性提出质疑。 22 根据《宁夏回族自治区政府采购合同信用融资管理办法》（宁财规 发〔2021〕10 号）要求，凡在宁夏回族自治区境内注册的中小微企 业，不分政府采购项目的资金性质（含财政性资金和单位自有资 金）、不分合同金额，在取得政府采购中标通知书及合同后，均可 办理融资业务。 具体融资事宜请登录 “宁夏回族自治区政府采购网” 政府采购合同线上融资系统查询办理。 23 政府采购合同签订及公告：①采购人应当自中标（成交）通知书 发出之日起30 日内，按照招标文件和中标人投标文件的规定，与 中标人签订政府采购合同；②采购人应当自政府采购合同签订之日 起2 个工作日内， 将政府采购合同在宁夏政府采购服务平台上公告， 但政府采购合同中涉及国家秘密、商业秘密的内容除外。 其他补充事项： 1 其他政府采购政策： （1)《政府采购促进中小企业发展管理办法》 （财库〔2020〕46 号） 、 《关于进一步加大政 府采购支持中小企业力度的通知》 （财库〔2022〕19 号） 、 《关于落实政府采购促进中小企 业发展有关措施的通知》 （宁财（采）发﹝2022﹞275 号） ； （2)《财政部司法部关于政府采购支持监狱企业发展有关问题的通知》 （财库〔2014〕68 号） ； （3)《财政部民政部中国残疾人联合会关于促进残疾人就业政府采购政策的通知》 （财 库〔2017〕141 号） ； （4） 《国务院办公厅关于建立政府强制采购节能产品制度的通知》 （国发办 〔2007〕 51 号）、 《关于印发节能产品政策采购品目清单的通知》 （财库〔2019〕19 号） ； 《关于印发环境标 注产品政府采购品目清单的通知》 （财库〔2019〕18 号） ； 《关于调整优化节能产品、环境 标志产品政府采购执行机制的通知》 （财库〔2019〕9 号） ； （5） 《财政部生态环境部工业和信息化部关于印发 〈绿色数据中心政府采购需求标准 （试 行） 〉的通知》财库〔2023〕7 号、 《宁夏回族自治区财政厅住房和城乡建设厅工业和信息 化厅关于印发〈政府采购支持绿色建材促进建筑品质提升试点工作方案〉的通知》 （宁财 （采）发﹝2023﹞161 号） ；执行创新发展相关政策； 《自治区财政厅人民银行银川中心 支行关于印发〈宁夏回族自治区政府采购合同信用融资管理办法〉的通知》宁财规发 ﹝2021﹞10 号。 2 服务地点：北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区妇幼保健院） 项目实施周期：自项目合同签订之日起，3 个月内完成。 项目质保期：软件质保期≥3 年，硬件质保期≥3 年（提供原厂质保服务） 付款方式： （1） 合同签订后15 个工作日内， 乙方应向甲方提供合同总金额5%的履约保函， 甲方收到履约保函后，60 个日历日内向乙方支付中标金额的30％，完成建设并通过甲方 验收合格后60 个日历日内，甲方向乙方支付中标金额金额的70％，质保期满后甲方向乙 方退回履约保函。 （2）如合同项目经费系财政拨付的专项资金，因乙方责任导致专项资金 尚未支付即被收回的，损失全部由乙方承担，甲方不承担任何责任，下剩款项有权不再支 付。 3 本项目采购所属行业为：软件和信息技术服务业。 4 （一）电子投标文件要求： 1.电子投标文件内容：商务标及技术标，并进行电子签名和签章。 2.电子投标文件的编制：以具体系统提示制作电子文件。 3.各投标供应商在开标前应及时关注宁夏公共资源交易中心网站信息， 及时查看时间或内 容上的调整，采购人（招标代理机构）不再以其他方式通知。 4.递交电子投标文件的时间： 投标人应当在招标文件规定的截止时间前， 将加密投标文件通过电子招投标交易系统进行 上传递交。 5.开标解密： 开标时按规定程序进行：投标人开标现场须随身携带生成投标文件所用的CA 锁，用于 现场投标文件的解密， 未按要求到达现场进行解密的视为放弃投标资格， 投标文件将予以 退还。 6.该交易管理平台系统实行CA 锁认证安全登录管理，报名前须办理CA 锁及电子签章 （含公章及法人章） 。CA 锁业务请咨询西部安全认证中心有限责任公司，联系电话： 4008600271 按1 号键。 7.投标文件制作完成后必须通过宁夏公共资源交易平台-【采购业务】-【上传投标文件】 菜单进行投标文件的上传。 (二)网上电子标操作指南 1.投标人进入宁夏回族自治区公共资源交易网(www.nxggzyjy.org)服务指南-下载专区-宁 夏公共资源交易系统（二期）政府采购项目-培训视屏-“宁夏公共资源交易系统（二期） 政府采购项目-供应商操作视屏.mp4”了解掌握电子标操作流程。 2.宁夏公共资源交易管理平台系统实行CA 锁认证安全登录管理，投标登记前须办理CA 锁及电子签章(含公章及法人章)。CA 锁业务请咨询西部安全认证中心有限责任公司，联 系电话4008600271 按1 号键。 （三）无效投标情形： 1.未在投标截止时间前完成上传及递交的，视为撤销其投标文件。 2.投标人未携带生成投标文件所用的CA 锁，视为撤销其投标文件。 3.因投标供应商CA 锁保管不当、硬件老化、电器性能不稳定、软硬件未及时更新等自身 问题导致现场不能正常解密的，视为撤销其投标文件。 5 第三章供应商须知 （一）总则 1.采购人、采购代理机构及投标供应商 1.1 采购人：是指依法进行政府采购的国家机关、事业单位、团体组 织。 1.2 采购代理机构：是指集中采购机构或从事采购代理业务的社会中 介机构。 1.3 投标供应商：是指响应招标、参加投标竞争的法人、非法人组织 或者自然人。 潜在投标供应商： 以招标文件规定的方式获取本项目招 标文件的法人、非法人组织或者自然人。 1.4 投标供应商须满足以下条件： 1.4.1 具备《中华人民共和国政府采购法》第二十一条、第二十二条 关于供应商条件的规定。 1.4.2 以招标文件规定的方式获得了本项目的招标文件。 1.4.3 符合本项目合格投标供应商的其他资格要求。 1.4.4 若本项目专门面向中小企业采购的，如投标供应商非中小企业 制造，其投标将被认定为投标无效。 1.5 如本项目允许联合体投标，对联合体规定如下： 1.5.1 两个及以上供应商可以组成一个投标联合体，以一个投标供应 商的身份投标。 1.5.2 联合体各方均应符合本须知1.4.1 的规定。 1.5.3 采购人根据采购项目对投标供应商的特殊要求，联合体中至少 应当有一方符合相关规定。 1.5.4 联合体各方应签订共同投标协议，明确约定联合体各方承担的 工作和相应的责任，并将共同投标协议作为投标文件的内容提交。 1.5.5 大中型企业、其他自然人、法人或者非法人组织与小型、微型 企业组成联合体共同参加投标， 共同投标协议中应写明小型、 微型企 业的协议合同金额占到共同投标协议投标总金额的比例。 1.5.6 以联合体形式参加政府采购活动的，联合体各方不得再单独参 加或者与其他供应商另外组成联合体参加本项目同一合同项下的投 标，否则相关投标将被认定为投标无效。 1.6 单位负责人为同一人或者存在直接控股、管理关系的不同供应商 参与本项目同一合同项下的投标的，其相关投标将被认定为投标无 效。 1.7 为本项目提供过整体设计、规范编制或者项目管理、监理、检测 等服务的供应商，不得再参加本项目上述服务以外的其他采购活动。 否则其投标将被认定为投标无效。 1.8 其他投标无效情形：无。 1.9 在政府采购活动中，采购人员及相关人员与供应商有下列利害关 系之一的，应当回避： 1.9.1 参加采购活动前3 年内与供应商存在劳动关系。 1.9.2 参加采购活动前3 年内担任供应商的董事、监事。 1.9.3 参加采购活动前3 年内是供应商的控股股东或者实际控制人。 1.9.4 与供应商的法定代表人或者负责人有夫妻、直系血亲、三代以 内旁系血亲或者近姻亲关系。 1.9.5 与供应商有其他可能影响政府采购活动公平、 公正进行的关系。 1.9.6 供应商认为采购人员及相关人员与其他供应商有利害关系的， 可以向采购人或者采购代理机构书面提出回避申请， 并说明理由。 采 购人或者采购代理机构应当及时询问被申请回避人员， 有利害关系的 被申请回避人员应当回避。 2.资金来源 2.1 本项目的采购人已获得足以支付本次招标后所签订的合同项下的 资金。 2.2 投标供应商报价超过招标文件规定的预算金额或者最高限价的， 其投标将被认定为投标无效。 3.投标费用 不论投标结果如何，投标供应商应承担所有与投标有关的费用。 （二）招标文件 4.招标文件构成 4.1 投标邀请 4.2 供应商须知前附表 4.3 供应商须知 4.4 项目说明和采购需求 4.5 资格审查方法及标准 4.6 评标方法和标准 4.7 政府采购合同主要条款 4.8 投标文件格式 5.招标文件的澄清与修改 5.1 采购人、采购代理机构可以对已发出的招标文件等进行必要的澄 清或者修改， 但不得改变采购标的和资格条件。 澄清或者修改应当在 原公告发布媒体上发布澄清公告。 澄清或者修改的内容为招标文件的 组成部分。 5.2 招标文件中有不一致的，有澄清的部分以最终的澄清更正内容为 准；未澄清的，以供应商须知前附表为准；供应商须知前附表不涉及 的内容，以编排在后的最后描述为准。 5.3 投标供应商应及时关注本项目原公告发布媒体上发布的澄清公告 或修改内容并自行下载，采购人、采购代理机构不再另行通知。 5.4 其他：无。 6.投标截止时间的顺延 6.1 为使投标供应商有足够的时间对招标文件的澄清或者修改部分进 行研究而准备投标或因其他原因， 采购人将依法决定是否顺延投标截 止时间。顺延变更公告应当在原公告发布媒体上发布。 6.2 投标供应商应及时关注本项目原公告发布媒体上发布的变更公 告，采购人、采购代理机构不再另行通知。 7.其他投标事项 7.1 投标供应商应认真阅读招标文件所有的事项、格式、条款和技术 规范等。 如投标供应商没有按照招标文件要求提交全部资料， 或者投 标文件没有对招标文件的实质性要求做出响应， 其投标将被认定为投 标无效。 （三）投标文件的编制 8.投标范围及文字、计量单位要求 8.1 投标供应商应当对招标文件中所列的所有内容进行投标，如仅响 应部分内容，其投标将被认定为投标无效。 8.2 无论招标文件中是否要求，投标供应商所投服务及伴随的货物和 工程均应符合国家强制性标准。 8.3 投标文件应使用规范汉字书写(专有名词须加注中文解释)，并采 用通用的图形符号，不得出现与常规书写格式不符的内容。 8.4 除招标文件中有特殊要求外，投标文件中所使用的计量单位，应 采用中华人民共和国法定计量单位。 9.投标文件的组成 投标供应商应完整地按照招标文件提供的投标文件格式及要求编写 投标文件， 对其投标文件的真实性与准确性负责， 投标供应商中标后， 其投标文件将作为合同的组成部分。 10.证明投标标的合格性和符合招标文件规定的技术文件 10.1 投标供应商应提交证明文件，证明其投标标的符合招标文件规 定。该证明文件是投标文件的技术文件。 10.2 上款所述的证明文件，可以是文字资料、图纸和数据，包括： 10.3 本条所指证明文件不包括对招标文件相关部分的文字、图标的 复制。 10.4 其他：无。 11.投标报价 11.1 投标供应商的报价应当包括满足本次招标全部采购需求所应提 供的服务，以及伴随的货物和工程。所有投标均应以人民币报价。 11.2 投标供应商应在价格明细表上标明分项服务、伴随的货物和工 程的价格（如适用）和总价，并由法定代表人或其授权代表签署。 11.3 投标供应商所报的价格明细在合同履行过程中是固定不变的， 不得以任何理由予以变更。 任何包含价格调整要求的投标， 其投标将 被认定为投标无效。 11.4 采购人不接受具有附加条件的报价或多个方案的报价。 12.投标保证金 12.1 保证金是投标文件的组成部分。本项目要求投标供应商提交投 标保证金的，应当在招标文件中明确保证金的数额及缴纳形式。 12.2 投标供应商未在规定时间内缴纳保证金或保证金数额不足以及 未按招标文件规定交纳保证金的，其投标将被认定为投标无效。 12.3 采购人或者采购代理机构应当自中标通知书发出之日起5 个工 作日内退还未中标人的投标保证金； 自采购合同签订之日起5 个工作 日内退还中标人的投标保证金。 13.投标有效期 13.1 投标应在供应商须知前附表中规定时间内保持有效。投标有效 期不满足要求的投标，其投标将被认定为投标无效。 13.2 因特殊原因，采购人或采购代理机构可在原投标有效期截止之 前， 要求投标供应商延长投标文件的有效期。 接受该要求的投标供应 商将不会被要求和允许修正其投标。 投标供应商也可以拒绝延长投标 有效期的要求，且不承担任何责任。 14.投标文件的制作 14.1 投标供应商应按供应商须知前附表中的规定，准备和递交投标 文件。电子投标文件需符合以下要求：详见供应商须知前附表 14.2 投标文件需由投标供应商的法定代表人或经其正式委托代理人 按招标文件规定在投标文件上签字并加盖公章。 委托代理人须持有书 面的“法定代表人授权委托书” ，并将其附在投标文件中。 未按招标文件要求签署和盖章的投标文件，其投标 将被认定为投标无效。 （四）投标文件的递交 15.投标文件的密封和标记 15.1 投标文件的制作应按照招标文件的要求进行制作并递交。投标 文件应当用不能被他人知悉或更换投标文件内容的方式密封。 15.2 纸质投标文件密封和递交要求： （采购人或者采购代理机构不得 因投标文件装订、纸张、文件排序等非实质性的格式、形式问题限制 和影响供应商投标） 15.3 电子投标文件密封和递交要求：详见供应商须知前附表 16.投标截止 16.1 投标供应商应在供应商须知前附表中规定的截止时间前，将投 标文件递交到招标公告中规定的地点。 16.2 采购人和采购代理机构将拒绝接收在投标截止时间后送达投标 文件。 17.投标文件的接收、修改与撤回 17.1 采购人和采购代理机构将按招标文件规定的时间和地点接收投 标文件。 17.2 递交投标文件以后，如果投标供应商要进行修改，须在投标截 止时间前提出申请， 投标供应商对投标文件的修改申请应按本须知规 定编制、签署、密封。采购人和采购代理机构将予以接收，并视为投 标文件的组成部分。 递交投标文件以后， 如果投标供应商要进行撤回的， 须在投标截止时 间前提出申请，采购人和采购代理机构将予以接受。 17.3 在投标截止时间之后，投标供应商不得对其投标文件做任何修 改。 17.4 除投标供应商不足3 家未开标外，采购人和采购代理机构对所 接收投标文件概不退回。 17.5 其他：无。 （五）开标及评标 18.开标 18.1 采购人和采购代理机构将按供应商须知前附表中规定的开标时 间和地点组织开标，并邀请所有投标供应商代表参加。 投标供应商不足3 家的，不予开标。 评标委员会成员不得参加开标活动。 18.2 开标时，采购人或者采购代理机构公布投标供应商名单，介绍 参加开标的人员， 宣布工作人员， 宣读投标供应商在开标一览表中所 填写的全部内容。 未宣读的投标价格、价格折扣等实质内容，评标时不予承认。 18.3 采购人或采购代理机构将对开标过程进行记录，由参加开标的 各投标供应商代表和相关工作人员签字确认，并存档备查。 投标供应商未派代表参加开标的，视同投标供应商认可开标结果。 18.4 投标供应商代表对开标过程和开标记录有疑义，以及认为开标 现场采购人、 采购代理机构相关工作人员有需要回避的情形的， 应当 场提出询问或者回避申请。 18.5 其他开标要求：无 19.资格审查及组建评标委员会 19.1 采购人或采购代理机构依据法律法规和招标文件中规定的内容， 对投标供应商及其投标货物的资格进行审查， 未通过资格审查的投标 供应商不进入评标。 合格投标供应商不足三家的，不得评标。 19.2 采购人或采购代理机构将按供应商须知前附表中规定的时间查 询投标供应商的信用记录。 19.2.1 投标供应商在中国政府采购网（www.ccgp.gov.cn）被列入政 府采购严重违法失信行为记录名单，或在“信用中国”网站 （www.creditchina.gov.cn） 被列入失信被执行人、 重大税收违法案 件当事人名单，以及存在《中华人民共和国政府采购法实施条例》第 十九条规定的行政处罚记录，投标将被认定为投标无效。 以联合体形式参加投标的，联合体任何成员存在以上不良信用记录 的，联合体投标将被认定为投标无效。 19.2.2 采购人或采购代理机构经办人将查询网页存档备查。投标供 应商不良信用记录以采购人或采购代理机构查询结果为准。 投标供应 商自行提供的与网站信息不一致的其他证明材料亦不作为资格审查 依据。 在本招标文件规定的查询时间之外， 网站信息发生的任何变更均不作 为资格审查依据。 19.3 按照《中华人民共和国政府采购法》 、 《中华人民共和国政府采 购法实施条例》 及本项目本级和上级财政部门的有关规定依法组建的 评标委员会，负责评标工作。 19.3.1 评标委员会由采购人代表和评审专家组成， 成员人数应当为5 人以上单数，其中评审专家不得少于成员总数的三分之二。 19.3.2 评标委员会成员名称在评标结果公告前应当保密。 20.投标文件符合性审查与澄清 20.1 符合性审查是指依据招标文件的规定，从商务和技术角度对投 标文件的有效性和完整性进行审查， 以确定是否对招标文件的实质性 要求做出响应。 20.2 投标文件的澄清 20.2.1 在评标期间，评标委员会要求投标供应商对其投标文件中含 义不明确、对同类问题表述不一致或者有明显文字和计算错误的内 容， 以及评标委员会认为投标供应商的报价明显低于其他通过符合性 审查投标供应商的报价， 有可能影响履约的情况作必要的澄清、 说明 或补正。 投标供应商的澄清、 说明或补正应在评标委员会规定的时间 内进行，并不得超出投标文件范围或者改变投标文件的实质性内容。 20.2.2 投标供应商的澄清、说明或补正将作为投标文件的一部分。 20.3 投标文件报价出现前后不一致的，按照下列规定修正： （1）投 标文件中开标一览表 （报价表） 内容与投标文件中相应内容不一致的， 以开标一览表（报价表）为准； （2）大写金额和小写金额不一致的，以大写金额为准； （3）单价金额小数点或者百分比有明显错位的，以开标一览表的总 价为准，并修改单价； （4）总价金额与按单价汇总金额不一致的，以单价金额计算结果为 准。 同时出现两种以上不一致的，按照前款规定的顺序修正。 21.符合性审查 21.1 如发现下列情况之一的，其投标将被认定为投标无效： 21.1.1 未按照招标文件规定要求签署、盖章的； 21.1.2 未满足招标文件中的实质性要求； 21.1.3 属于串通投标，或者依法被视为串通投标； 21.1.4 评标委员会认为投标供应商的报价明显低于其他通过符合性 审查投标供应商的报价， 有可能影响履约的， 且投标供应商未按照规 定证明其报价合理性的； 21.1.5 投标文件含有采购人不能接受的附加条件的； 21.1.6 属于招标文件规定的其他投标无效情形； 21.1.7 不符合政府采购法律法规和招标文件中规定的其他实质性要 求的。 22.其他投标无效情形： 23.比较与评价 23.1 经符合性审查合格的投标文件，评标委员会将根据招标文件确 定的评标方法和标准， 对其技术部分和商务部分作进一步的比较和评 价。 23.2 评标严格按照招标文件的要求和条件进行。根据实际情况，在 供应商须知前附表中规定采用下列一种评标方法： 23.2.1 最低评标价法，是指投标文件满足招标文件全部要求，且投 标报价最低的投标供应商为中标候选人的评标方法。 23.2.2 综合评分法，是指投标文件满足招标文件全部要求，且按照 评审因素的量化指标评审得分最高的投标人为中标候选人的评标方 法。 23.3 根据《政府采购促进中小企业发展管理办法》 （财库[2020]46 号） 、 《财政部司法部关于政府采购支持监狱企业发展有关问题的通 知》 （财库〔2014〕68 号）和《三部门联合发布关于促进残疾人就业 政府采购政策的通知》 （财库〔2017〕141 号）的规定，对满足价格 扣除条件且在投标文件中提交了 《中小企业声明函》 、 《残疾人福利性 单位声明函》 相关属于监狱企业的证明文件的投标供应商， 按照相关 价格扣除规定和供应商须知前附表要求执行。 23.4 落实其他政府采购政策条款，具体详见供应商须知前附表。 24.废标 24.1 出现下列情形之一，将导致项目废标： 24.1.1 符合专业条件的供应商或者对招标文件做实质性响应的供应 商不足三家； 24.1.2 出现影响采购公正的违法、违规行为的； 24.1.3 投标供应商的报价均超过了采购预算，采购人不能支付的； 24.1.4 因重大变故，采购任务取消的。 25.保密要求 25.1 评标将在严格保密的情况下进行。 25.2 有关人员应当遵守评标工作纪律，不得泄露评标文件、评标情 况和评标中获悉的国家秘密、商业秘密。 （六）确定中标 26.中标候选人的确定原则及标准 26.1 除评标委员会受采购人委托直接确定中标供应商的情形外，对 实质上响应招标文件的投标供应商按下列方法进行排序， 确定中标候 选人： 26.1.1 采用最低评标价法的，除了算术修正和落实政府采购政策需 进行的价格扣除外， 不对投标供应商的投标价格进行任何调整。 评标 结果按修正和扣除后的投标报价由低到高顺序排列。 得分与投标报价 均相同的处理方式：由采购人或采购人委托评标委员会随机抽取。 26.1.2 采用综合评分法的，评标结果按评审后得分由高到低顺序排 列。得分相同的，按修正和扣除后的投标报价由低到高顺序排列。得 分与投标报价均相同的处理方式： 由采购人或采购人委托评标委员会 随机抽取。 27.确定中标供应商及定标 27.1 评标委员会将根据评标标准，按供应商须知前附表中规定数量 推荐中标候选人。 27.2 按供应商须知前附表中规定，由评标委员会直接确定中标供应 商。 27.3 采购人应当自收到评审报告之日起5 个工作日内按照《投标供 应商须知前附表》中规定的中标原则确定中标人。 28.发出中标通知书 在投标有效期内， 中标供应商确定后， 采购人或者采购代理机构发布 中标公告。在公告中标结果的同时，向中标供应商发出中标通知书， 中标通知书是合同的组成部分。 29.告知招标结果 在公告中标结果的同时， 采用综合评分法评审的， 还将告知未中标供 应商本人的评审得分和排序。 （七）合同及履约验收 30.签订合同 30.1 采购人与中标供应商应当在中标通知书发出之日起三十日内， 签订政府采购合同。 30.2 招标文件、中标供应商的投标文件及其澄清文件等，均为签订 合同的依据。 所签订的合同不得对招标文件确定的事项和中标人投标 文件作实质性修改。 采购人不得向中标人提出任何不合理的要求作为 签订合同的条件。 30.3 如中标供应商拒绝与采购人签订合同的，中标供应商须按投标 函内容向采购人和采购代理机构支付赔偿； 采购人可以按照评标报告 推荐的中标候选人排序， 确定下一中标候选人为中标供应商， 也可以 重新开展采购活动。 30.4 当出现法律法规规定的中标无效或中标结果无效情形时，且合 格的供应商数量符合规定， 采购人可与排名下一位的中标候选人另行 签订合同，或依法重新开展采购活动。 31.履约保证金 如果需要履约保证金， 中标供应商应按照供应商须知前附表规定向采 购人提交履约保证金。 32.履约验收 按照宁财规发〔2022〕10 号《宁夏回族自治区政府采购履约验收管 理暂行办法》执行 33.招标代理费 本项目是否由中标供应商向采购代理机构支付招标代理费及招标代 理费标准，按照供应商须知前附表规定执行。 34.政府采购合同线上信用融资 中标的投标供应商为中小微企业的， 可以在取得中标通知书后， 通过 “政府采购合同线上信用融资系统” ，向相关金融机构、担保机构申 请政府采购融资服务。 （八）质疑和投诉 35.质疑 35.1 投标供应商认为采购文件、采购过程和中标结果使自己的权益 受到损害的，可以根据《中华人民共和国政府采购法》 、 《中华人民共 和国政府采购法实施条例》和《政府采购质疑和投诉办法》的有关规 定， 在知道或者应知其权益受到损害之日起7 个工作日内， 依法向采 购人或其委托的采购代理机构提出质疑。 35.2 提出质疑的供应商应当是参加所本项目采购活动的供应商。依 法获取可质疑采购文件的潜在供应商也可以依法提出质疑。 35.3 质疑供应商应在法定质疑期内通过“宁夏回族自治区政府采购 网” “政府采购在线质疑投诉系统”提出质疑。针对同一采购程序环 节的质疑次数应符合供应商须知前附表的规定。 超出法定质疑期提交 的质疑将被拒绝。 35.4 采购人、采购代理机构不得拒收质疑供应商在法定质疑期内发 出的质疑函， 应当在收到质疑函7 个工作日内作出答复， 并通知质疑 供应商和相关供应商。 36.投诉 36.1 质疑供应商对采购人、采购代理机构的答复不满意，或者采购 人、采购代理机构未在规定时间内作出答复的，可以在答复期满后 15 个工作日内向同级财政部门提起投诉。 36.2 投诉供应商应在法定投诉期内通过“宁夏回族自治区政府采购 网” “政府采购在线质疑投诉系统”提出投诉。 第四章项目说明和采购需求 一、商务部分 服务地点：北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区妇幼保健院） 1、商务部分 （1）投标人须提供可行的运行维护方案。 （2）提供全区范围内的定期集中培训和临时培训。 （3）投标人须承诺为本项目所涉及的软件、硬件提供自验收合格后三年免费质保服务（硬 件要求提供原厂质保服务） ，质保期内提供免费的送货、安装实施、技术支持、保修、软件 升级和维护等服务。 2、运维服务 （1）质保期内，投标人应提供电话、传真、电子邮件等多种方式的技术咨询服务。 （2）投标人应提供24 小时全天候服务（包括公休日）技术支持服务。投标人应提供远程技 术支持和现场技术支持两种方式，技术服务包括系统的功能完善、故障排除、软件升级、性 能调优、技术咨询等。 （3） 一旦发生系统故障问题， 投标人须在30 分钟内响应， 保证2 小时内进行技术响应并尝 试远程排除故障， 如无法远程排除故障的， 投标人工程师及其它相关技术人员必须在接到故 障通知后24 小时内赶到现场， 查找原因， 提出解决方案， 直至故障完全恢复正常服务为止。 （4）在免费质保期内，投标人根据采购人对系统的个性化需求，免费提供软件修改服务。 （5）软件质保期后每年运行维护费用，不得超过中标金额的10%。 3、驻场服务 （1）免费质保期内，投标人提供不少于1 名驻场工程师服务，驻场工程师需具有相关维护 经验， 有提供紧急故障处理能力， 在接到医院故障通知后2 小时内回复并提出解决方案， 现 场能解决的问题保证在24 小时内解决。 4、系统安全要求 根据建设方实际需求，系统支持适配国产服务器、数据库、中间件，可以在国产终端及国产 操作系统环境下运行。 5、项目实施周期 自项目合同签订之日起，3 个月内完成。 6、项目质保期 软件质保期≥3 年，硬件质保期≥3 年（提供原厂质保服务） 7、付款方式： （1）合同签订后15 个工作日内，乙方应向甲方提供合同总金额5%的履约保函，甲方收到 履约保函后，60 个日历日内向乙方支付中标金额的30％，完成建设并通过甲方验收合格后 60 个日历日内，甲方向乙方支付中标金额金额的70％，质保期满后甲方向乙方退回履约保 函。 （2）如合同项目经费系财政拨付的专项资金，因乙方责任导致专项资金尚未支付即被收回 的，损失全部由乙方承担，甲方不承担任何责任，下剩款项有权不再支付。 二、技术部分 1、标的清单(服务类） 序号： 1 ； 标的名称： 行业应用软件开发服务； 服务内容： 智慧后勤综合服务平台、 智能可视化管理平台建设； 项目实施周期：自项目合同签订之日起，3 个月内完成。 2、服务标准及要求;标的详细参数： 序号：1 ； 标的名称：行业应用软件开发服务； 详细参数： 一、项目概述 1.1、项目背景 北京大学第一医院宁夏妇女儿童医院是由宁夏回族自治区人民政府和北京大学第一医院合 作共建的国家妇儿区域医疗中心。 新建的妇产综合楼， 建筑面积67510 平方米， 包括裙楼地 上4 层，地下2 层，住院楼地上12 层，科研教学楼8 层，主要建设门急诊、医技、住院、 科研教学、后勤保障、地下车库、人防工程等；新建污水处理站300 平方米、液氧站60 平 方米及配套附属设施。 根据《国务院办公厅关于推动公立医院高质量发展的意见》 （国办发〔2021〕18 号） 、 《医院 智慧管理分级评估标准体系（试行） 》 （国卫办医函[2021]86 号）的要求，结合医院运营管理 现状， 本次拟通过智慧后勤综合服务平台和智能可视化管理平台建设项目， 将医院智慧后勤 管理、智慧安全管理等进行统一规划建设，按照保安全、提效率、增服务和智决策的设计思 路，打造安全、智能、高效、多系统融合的智慧医院运行支撑综合管理平台，构建医院运行 保障智慧管理体系，在保障医院安全运营基础上，提升医院服务品质、降低医院运营成本， 提高医院综合管理水平。 1.2、项目目标 本系统的设计理念是以人为本，在保障医院医护人员、病患、工作人员享有的安全、舒适和 健康的同时，为院内后端运行支撑工作人员、服务人员等提供高效、便捷、节能、智能、可 靠的综合监管平台。 为医院管理驾驶层人员的统揽全局、 指挥中心的调度把控、 业务部门领 导的精准管理以及基层工作人员的便捷操作等多项工作职责提供坚实的信息化支撑。 在功能的设计和实施中， 全面考虑医院不同业务功能、 不同使用人员对该系统平台的多方面 需求。 参照国家智能信息化相关标准规范， 合理考虑维护与应用操作的可行性、 合理性以及 可扩展性，充分利用数据中台、物联网、人工智能、等技术和设备，结合医院智慧后勤基础 设施， 适应医院后勤领域的信息应用和未来发展需求，初步形成功能完善的系统，建设融安 全、高效、节能、管理为一体的智慧数字化医院智慧管理平台，助力于以医疗技术为核心的 有效诊疗体系、 以病患便捷为前提的人文关怀服务体系、 以后勤供应联动为核心的高效运营 体系， 为医院业务发展赋能， 打造国内医院智慧管理系统建设和管理的标杆，带动医院后勤 服务水平的全面提升。 1.3、项目范围 1.3.1、功能范围 核心功能：包括设备管理、物资管理、能源管理、安消管理、一站式服务中心等。 辅助功能：报表生成、任务调度、数据分析等。 1.3.2、用户群体 后勤管理人员：负责日常管理和调度。 后勤工作人员：执行具体工作任务。 院领导：查看报表和决策支持。 外部供应商：物资供应和外包服务。 1.3.3、系统集成 智慧后勤综合服务平台、 智能可视化管理平台数据需接入到医院信息系统集成平台、 数据中 心等系统； 中标方负责完成与医院信息系统集成平台、数据中心等系统间的数据共享，并承 担相关费用。 医院信息系统（HIS） 、楼宇自控系统、公区照明监控管理系统、视频监控系统、门禁管理系 统、消防系统等系统数据需接入智慧后勤综合服务平台、 智能可视化管理平台， 实现统一管 理。医院负责协调相关第三方平台的开发方提供数据接口，供智慧后勤综合服务平台、智能 可视化管理平台进行调用。 1.3.4、技术实现 前端技术：界面交互与用户体验。 后端技术：数据处理与业务逻辑。 数据库：数据存储和管理。 二、项目总体要求 2.1、设计原则 2.1.1、前沿性 本项目建设应体现“适度超前与实用相结合”的理念，采用新技术、新工艺和新产品。具备 通过软件升级实现功能扩展的能力， 以确保系统在未来具备良好的扩展性， 保障用户投资的 长期价值。 2.1.2、实用性 项目建设应符合医院实际需求。 投标方案需基于广泛的市场调研和深入论证， 提出切实可行 的解决方案。设计过程中需考虑与现有系统的整合， 符合医院安全防范系统的整体规划， 避 免因设备不兼容导致的资源浪费和闲置。 2.1.3、可靠性 所选设备必须具备高可靠性， 能够长期稳定运行。 设备应为经过实际工程应用验证的成熟产 品和技术。 设计中应采用标准化、 规格化、 通用化的设备， 以便于后期的维护和更换。 同时， 需简化系统结构，减少部件和设备数量，优化布线路由，提高系统整体的可靠性。 2.1.4、开放性 本次项目建设所以使用的产品具有良好的开放性、兼容性、互操作性， 以满足各子系统的正 常使用和建成后的日常维修保养费用的控制。 2.1.5、规范性 本次项目建设严格遵循国家及行业相关标准规范，各系统应提供标准的软件、硬件、 操作系 统和数据库管理系统等诸多方面的接口与工具，使系统具备良好的规范性、兼容性。 2.1.6、适应性 系统设备的安装不应破坏医院现有人员的工作习惯，需与周边环境协调一致。 2.1.7、易管理性、易维护性 系统应采用全中文、 图形化软件平台实现整个系统管理与维护， 可自动检测系统中设备的运 行状态，以辅佐管理人员及时准确地判断和解决问题。系统提供简捷易用的操作界面，使操 作人员易于掌握。 2.2、系统功能需求 2.2.1、监管能力提升的需求 为了满足医院业务发展的需求， 全面覆盖后勤整体业务， 需建设一个完善的信息化管理系统。 该系统应具备实时监控、数据分析与报告生成等功能，以支持高效的管理和决策。 2.2.2、管理提质增效的需求 本项目需要建设一个统一、 易用且高效的后勤管理智能化系统。 该系统需实现业务流程的自 动化和智能化，提升管理效率，减少操作错误，并确保系统的健全性和可持续发展，以实现 后勤管理的提质增效目标。 2.2.3、推进节能减排的需求 在节能减排的驱动下，后勤管理系统需满足以下技术与管理的节能需求： 技术节能：通过优化控制空调、照明和用水等系统，提升能源使用效率，降低无效负荷， 减少建筑能耗。 管理节能：系统应具备能耗数据的自动采集与分析功能，能够对比分析用能情况， 识别运 行中的问题并进行改进，支持用能趋势预测，及时发现和处理用能异常。 整体协同：实现“监、管、控”全过程的整体协同，构建建筑能源信息的“可感知、可管 理、可追溯”的统一调度指挥机制。 2.2.4、满意度提升的需求 系统设计需致力于提升各类用户的满意度，具体要求如下： 患者满意度：通过高效的后勤运维，营造良好的就医环境，提升患者满意度。 医护人员满意度： 提供舒适的工作环境和全面的安全保障， 增强医护人员的安全感，提高 工作效率和环境满意度。 后勤人员满意度： 采用集中智能化监控管理系统， 减少后勤工作人员的工作负担， 提高工 作效率，优化工作体验。 2.2.5、系统安全性需求 智慧后勤综合服务平台和智能可视化管理平台设计保证较高安全级别要求， 具备极高的安全 性、可靠性和容错性。对接入系统的设备和用户，需要进行必要的接入认证，以保证接入的 安全性，采取适当的措施保证信息传输过程中的保密性和真实性。 运行支持系统建设中按照相关安全体系建设要求对软硬件进行综合设计， 在已有的身份认证 和访问控制、数据库备份与恢复等技术体系基础上加强应用系统、 数据库、 视音频传输等系 统安全性设计，保证数据库安全、应用软件运行、操作安全，保护网络建设者的合法利益， 所有应用项目和软硬件都应当具有比较好的安全方案。 2.2.6、系统开放性需求 系统设计所采用的技术和设备符合国际标准、国家标准、 公安部相关标准， 技术方案需标准 化程度高， 为扩展升级、 与其他系统的互联提供良好的基础。 能够提供良好的软、 硬件接口， 便于维护与修改，满足开放和标准化原则。 2.3、系统适用范围 2.3.1、业务场景适用范围 系统应用场景： 本次建设的智慧后勤综合服务平台和智能可视化管理平台的服务器将部署在医院门诊楼四 楼的信息中心机房， 系统控制中心位于新建的妇产综合楼一楼的安消防控制室。 此外，项目 所需的网络环境将依托于医院现有的网络基础设施。 医院后勤管理： 本系统适用于医院的后勤管理工作， 涵盖医院的设施维护、 物资管理、 能源管理、 设备管理、 餐饮服务、保洁管理、安保管理等多个业务领域。 工作流程管理： 系统支持医院后勤部门的工作流程管理， 包括任务分配、 执行跟踪、 问题反馈和工单处理等。 应急事件处理： 系统适用于医院后勤管理中的应急事件处理，如设备故障、物资短缺、 突发性公共卫生事件 等。 2.3.2、目标用户范围 后勤管理人员： 系统的主要用户是医院的后勤管理人员和工作人员， 包括后勤主管、物资管理人员、 设备维 护人员、安保人员、保洁人员和餐饮服务人员。 院领导及管理层： 系统适用于医院的管理层， 帮助他们通过系统查看后勤管理的整体运行情况， 生成决策支持 的数据报表。 外部服务供应商： 系统可能会为某些外包的服务供应商提供限定的访问权限， 以便管理其提供的服务， 如设备 维护外包、餐饮服务外包等。 2.3.3、功能适用范围 设施与设备管理： 系统适用于医院的设施和设备管理， 包括设备的日常维护、 使用记录、 故障报告和维修跟踪。 物资管理： 系统适用于医院的物资管理工作， 包括医疗设备配件耗材库管理、 办公物资、消耗品等的采 购、库存管理、领用和补充。 能源管理： 系统适用于医院的能源管理，包括水、电、气的消耗监控、能源使用报表和节能分析。 2.3.4、运行环境适用范围 硬件环境： 系统应能够运行在医院现有网络基础设施上，支持必要的服务器和客户端设备。 软件环境： 系统适用于Linux 系统，支持与医院现有的数据库和系统平台的集成。 网络环境： 系统适用于医院的局域网环境，并支持远程访问，供管理人员和外部供应商使用。 2.3.5、法规与合规适用范围 行业法规： 系统适用于符合医院后勤管理中的相关法规和政策要求， 如医疗安全、 物资管理规范、能源 使用规范等。 医院内部政策： 系统应遵循医院的内部管理政策，例如数据安全、信息保密、操作权限等。 2.3.6、系统边界 集成系统： 系统需要与医院的其他系统进行集成，如医院信息管理系统（HIS） 、财务管理系统、采购系 统等，通过接口实现数据交互。 外部系统集成： 系统将与部分外部供应商系统集成，支持供应商通过系统提交物资需求、服务工单等。 2.4、系统用户 2.4.1、用户角色分类 2.4.1.1、系统管理员 职责： 负责系统的整体管理和维护，包括用户权限设置、系统配置、数据备份、系统监控等。 管理系统的基础设置、数据库维护、接口管理以及与其他系统的集成工作。 权限： 拥有系统的最高权限，可以访问和配置所有模块，创建和管理用户账户，分配角色和权限。 负责系统的安全性和稳定性，能够查看系统日志和用户操作记录，进行异常处理。 使用场景： 配置系统初始设置，分配用户角色，监控系统运行状态，维护系统升级和数据安全。 典型用户： 医院信息技术（IT）部门的系统管理员或技术支持人员。 2.4.1.2、后勤管理人员 职责： 负责医院后勤管理的日常工作，包括物资管理、设备维护、能源管理、餐饮管理、保洁管理 等。 分配后勤任务、跟踪任务进度、管理资源调度和反馈后勤工作的完成情况。 权限： 可以创建、 分配和管理后勤任务， 查看相关模块的运行状态和数据 （如物资库存、 设备状态、 能耗情况等） 。 可以生成和查看各类工作报表，跟踪后勤任务的执行和完成情况。 使用场景： 通过系统管理物资库存、设备故障报修，监控能源使用。 典型用户： 医院后勤部门的管理人员，如后勤主管、物资管理人员、设备维护主管等。 2.4.1.3、后勤工作人员 职责： 负责执行后勤管理人员分配的具体任务，如设备维修、物资调度、安保巡逻等。 反馈任务执行情况，提交问题报告和任务完成确认。 权限： 拥有执行权限，可以查看分配给自己的任务，提交任务完成报告，反馈任务执行中的问题。 能够通过系统提交工单或请求物资，报告设备故障或任务进度。 使用场景： 接收并处理系统分配的工作任务，记录任务执行情况，报告执行任务中的问题或完成情况。 典型用户： 医院的保洁员、设备维修人员、物资调度员、安保人员等后勤工作人员。 2.4.1.4、院领导及管理层 职责： 监督和管理医院后勤运营的整体情况，评估后勤工作的效率和资源利用情况。 通过系统查看后勤工作的汇总报表和分析数据，进行战略决策和资源分配。 权限： 拥有查看权限，能够查看系统中的汇总数据和分析报告，包括物资消耗、能耗分析、设备维 护情况等。 可以生成并导出定制化报表，进行数据分析和决策支持，但无需参与具体任务分配和执行。 使用场景： 通过系统查看后勤管理工作的整体运行情况，生成能耗、物资库存、设备故障率等报表，做 出管理决策。 典型用户： 医院的高层管理人员，如院长、副院长、后勤管理部门负责人。 2.4.1.5、外部供应商 职责： 负责为医院提供外包服务或物资供应， 参与医院后勤管理工作的一部分，如设备维修、物资 采购等。 提交服务工单、物资采购单，提供服务完成情况的反馈。 权限： 具有有限的访问权限，能够通过系统提交工单、 查看相关任务的执行状态， 提交物资供应的 反馈信息。 仅能访问与自身相关的任务和数据，无法查看或操作医院内部的其他后勤信息。 使用场景： 通过系统提交设备维护申请、提供维修反馈，或处理医院物资订单，确认采购进度。 典型用户： 医院的外部合作伙伴，如设备供应商、物资供应商、设施维护外包公司等。 2.4.2、用户权限与系统功能的关联 角色与权限的划分： 不同用户角色拥有不同的系统权限和功能模块访问权限， 系统管理员可以为每个用户分配合 适的权限。 系统应提供灵活的权限管理功能， 允许管理员根据实际需求进行授权和调整， 确保系统的安 全性和可操作性。 权限控制的安全性： 系统应具备强大的权限控制机制，确保敏感数据和操作仅限于授权用户访问。 例如，院领导只能查看汇总报表，而后勤工作人员只能操作与自己相关的任务模块。 2.4.3、用户管理与维护 用户注册与管理： 系统管理员负责创建和管理用户账户，包括新增用户、分配角色、设置权限和注销用户等。 新用户注册流程应简单高效，管理员可以通过系统后台为新用户分配适合的角色和访问权 限。 用户角色变更： 在用户职责或岗位发生变化时， 系统管理员可以根据需求调整用户的角色与权限， 确保用户 仅能访问与其工作相关的功能模块。 用户审计与操作日志： 系统应记录每个用户的操作日志， 方便审计和问题追踪， 确保系统的使用安全和数据的可追 溯性。 系统管理员可以通过系统查看用户的登录记录、操作行为和权限变更情况。 2.5、系统集成要求 2.5.1、集成目标 数据共享与互通： 确保系统能够与医院其他系统共享数据， 实现信息的互通和流程的自动化。 功能协同：通过集成实现不同系统间的功能协同，提高整体运营效率。 2.5.2、集成方式 应用程序接口：使用标准化的应用程序接口进行数据交换和功能调用。 中间件：通过中间件实现不同系统间的消息传递和数据集成。 2.5.3、数据交换要求 数据格式：采用统一的数据格式进行交换，确保数据的一致性和兼容性。 数据同步：支持实时或定期的数据同步机制，确保不同系统中的数据保持一致。 2.5.4、兼容性要求 系统兼容性：确保系统能够兼容多种操作系统、数据库和网络环境。 版本兼容性：在系统升级时，确保与现有系统的兼容性。 2.5.5、安全性要求 身份验证：使用安全的身份验证机制保护接口的调用。 数据加密：确保传输中的数据采用加密技术保护。 2.5.6、测试与验证 接口测试：在集成前进行接口测试，验证接口的正确性和可靠性。 集成测试：进行全面的集成测试，确保系统与其他系统的无缝协作。 2.6、系统扩展性要求 2.6.1、模块化设计 可插拔模块：系统应采用模块化设计，便于添加或替换功能模块。 接口标准化：确保各模块间的接口标准化，支持无缝集成新功能。 2.6.2、数据库扩展性 水平扩展：支持通过增加数据库节点来扩展数据存储和处理能力。 分区与索引优化：设计数据库结构以支持分区和索引优化，提升查询性能。 2.6.3、性能扩展 负载均衡：系统应支持负载均衡，以分配流量并提升性能。 缓存机制：使用缓存技术减少数据库负载，提高系统响应速度。 2.6.4、用户与功能扩展 用户容量：设计系统以支持增加的用户数量，确保性能不下降。 功能扩展：支持添加新功能。 2.6.5、技术兼容性 技术栈升级：确保系统架构允许技术栈的更新和升级。 第三方集成：支持与第三方服务的集成。 2.6.6、安全扩展 权限管理：灵活的权限管理系统，适应用户和角色的增加。 安全升级：支持定期的安全升级和补丁应用。 三、技术要求 3.1、智慧后勤综合服务平台 3.1.1、智慧医院平台数字底座 3.1.1.1、基础业务中台系统 序号功能项功能描述 1 ★个人工作台1、支持登录用户按照个人需要定制需要展示的窗口模块，系统提供待办、 报警、各类数据分析、工作日历等多种窗格模块； 2、支持登录个人相关的报警、任务、审批、通知等消息接收与展示； 3、支持将工单、审批、巡检等还未处理完的工作任务进行归类汇总和展示； 4、支持点击待办工作，可直接完成此工作的处理； 5、支持将待办工作通过日历的形式进行展示，在日期上可显示每日待办工作的数量； 6、支持在不同任务类型标签上，区分不同的任务完成状态； 7、支持切换日历日期，查看历史或未来月份的任务分布情况； 8、支持模糊搜索，可通过关键字快速查找所需的子系统； 9、支持工作台个性化定制，支持窗体布局自定义，支持摆放位置拖拽，窗体大小调整，并 可保持布局；支持窗体内容自定义，支持待办事项，用户信息，安消防报警列表数据，后勤 巡检数据，后勤服务指标数据等；支持消息订阅和取消，支持工单消息，任务提醒消息，新 闻通知消息，调查问卷消息，报警消息等。 。 2 系统跳转管理支持用户登录校验通过后自动跳转至子系统页面，并将用户登录信息返回 到子系统； 3 工作流程管理1、支持自定义工作流的增删改查； 2、支持通过在线流程设计器自行添加或删除工作流节点，并可通过拖拽的方式实现流程顺 序的调整； 3、支持为节点设置不同的动作，并指定相关责任人； 4 工单管理1、支持向工作班组派发工单，工单发出后组内所有成员都可看到工单； 2、支持向指定个人派发工单，工单发出后只有指定人员可以看到工单； 3、支持将工单转发至组内其他工作人员处理； 4、支持处理工单时发起工作协助，邀请其他人员共同处理工单； 5、支持循环型工单，系统可根据循环周期、频度、管理班组和人员等信息，周期性的到期 生成和派发工单； 6、至少支持抢单和指派两种接单模式； 7、支持在抢单模式下，无人接单时，班组长手动指定派发工单； 8、支持通过微信、WEB、工单机确认接单； 9、支持设定工单完工时长，当超时未完成时，自动产生超时提醒； 10、支持通过微信、WEB 提交工单（微信功能需要提供专用公众号或者与医院企业微信对 接） ； 11、支持图片、语音多媒体信息附件的提交 12、支持在可视化图形上操作打开特定空间模型的工单列表； 13、支持打开任意工单查看详情，播放通话录音，录音具有倍速度播放和暂停功能； 14、支持在工单详情页面中操作，将通话录音转换为文字，并显示在窗口内。 5 消息推送管理1、支持消息推送统一接口，可实现微信、短信、WEB 多种消息推送； （微 信功能需要提供专用公众号或者与医院企业微信对接） ； 2、支持消息发送模板自定义配置，可通过正则表达式自动填写模板数据。 6 数据安全管理1、支持对关键数据的传输、存储过程进行加解密； 2、支持对关键数据进行自动定期备份，出现异常可恢复； 3、支持对数据资源配置不同角色的数据权限，只有拥有权限的用户，才能访问相关的数据 资源。 7 其他通用能力1、 人员台账管理： 支持对人员台账进行增删改查的， 对各类人员信息进行 登记， 包括姓名、 联系方式、 所属部门、 相关证书等， 同时为各子系统提供标准的数据接口； 2、空间台账管理：支持记录医院空间信息，包括位置、面积、所属科室、使用状态等信息， 同时为各子系统提供标准的数据接口； 3、组织台账管理：按照多层级模式，管理医院的组织架构，实现组织架构的增删改查，以 及为其他系统提供统一的数据接口； 4、资产台账管理：支持将各类设施、设备、资产进行统一管理，建立完整的设备台帐信息： 包括设备基本信息、所属位置等，同时为各子系统提供标准的数据接口 5、岗位台账管理：支持按照不同的工作需求和工作内容，进行定岗定责，实现岗位在医院 的标准化管理。针对每个岗位，要求明确名称、职责、要求等信息。并可通过增删改查进行 数据的调整； 6、日志管理：支持对用户的使用记录进行追溯，可按时间、操作类型、内容、IP 等信息进 行检索。 3.1.1.2、智能移动应用终端系统 序号功能项功能描述 1 ★工单管理1、支持工单接收与提醒：支持自动派单到服务班组；可通过服务类型、服务 区域与班组进行绑定，当用户下单后可自动分配任务到服务班组进行处置。 2、支持完工交单：服务班组人员可通过移动手持终端实时查询个人完工任务记录，了解个 人工作量情况。 完工交单时需进行一下操作，故障原因及维修方法，用户通过下拉选本次故 障原因和处置方案，同时支持用户手动添加；耗时使用，选择用的耗材，根据所选的耗材和 数量，显示价格；完工说明，使用文字对完工情况进行描述；附件照片，为了确保真实性， 完工时可上传完工附件照片，支持用户从相册或者实时拍照上传。 3、工单状态查询：系统支持按工单状态对工单进行查看，包括未派工、已派工、已挂单、 已完工状态下的所有工单记录 2 报警管理1、报警处置：支持手机端对警情进行处置，用户点击可查看报警详情，并警情 实际情况进行处置，处置方式支持确警、误报、演习处置方式； 2、报警转工单：支持报警警单自动转派后勤服务工单，并提交到对应的服务班组进行工单 的闭环处置管理。 3 审批管理支持各类型审批业务统一管理，可通过定义审批流节点方式，按照其策略把审 批消息推送给对应的人员做处理； 支持用户对审批工作进行处理，用户点击审批记录， 显示数据列表， 用户点击列表后即可对 记录进行查看和处置，完成业务审核。 4 设备运维支持多种巡检方式，根据设备日常的管理方式和周期不同，制定设备的巡检计 划和巡检项目， 并可把巡检项目与任务书关联起来从而快速生成适合本医院的巡检计划， 巡 检计划创建后可派发给责任班组或者责任人进行任务的执行； 持用户一键对设备进行报修，报修明细包括设备名称、报修人、联系方式、设备位置、发生 时间、故障描述、故障图片、故障类别、紧急程度、故障等级等内容； 5 后勤业务监管服务总览： 综合维修统计页面展示不同时段工单数量， 包括但不限于今日、 本周、本月及本年，还可自定义时间段查询。支持数据钻取，点击可查看工单详情。 维修事项统计： 维修事项统计页面显示不同时段综合维修工单服务事项统计， 显示内容包括： 不同事项工单总量、所占百分比及环比，按照服务事项总量倒序排序。 报修区域统计：以楼层为单位，实现维修区域的统计，可按今日、本周、本月及本年，还可 自定义时间段查询， 查询结果以柱状图和列表方式展示， 可对区域的数量进行同环比。支持 数据逐层钻取，点击数据可查看详情。 6 个人信息修改与维护1、 支持用用户制定修改个人信息， 用户在我的页面点击个人信息区 域进入个人资料页面，个人资料页面可完善或修改个人信息，包括姓名、部门、工号及联系 电话。 2、支持消息订阅，用户可对工单消息、审批消息、告警消息、任务提醒、系统消息等进行 开关设置，已关闭消息类型系统将无法接收； 3.1.2、资产及设备管理 3.1.2.1、智能资产台账管理系统 序号功能项功能描述 1 资产分类管理1、支持将资产按照固定资产国家标准GB/T 14885-2022 分类进行管理； 2、支持按字典进行资产的快速过滤与分类查看。 2 台账信息维护1、支持以列表形式展示资产台账，提供新增、删除、批量导入、导出等功 能。 2、支持资产名称，资产编码，所在区域等进行快速查询； 3、资产新增，资产信息包括资产名称、资产编码、品牌、型号、生产日期、SN 编码、NFC 编码、所在区域、计量单位、启用日期、使用期限、资产的状态等； 4、支持使用信息维护，包括使用部门、资产的图片等； 5、支持模型信息的维护管理。 3 运维信息管理1、支持对单位的运维信息进行查看与管理； 2、运维信息以时间轴先后方式显示，显示操作记录包括操作人、操作方式、修改内容，设 备巡检、保养、维修等记录 3.1.2.2、设备设施使用运维系统 序号功能项功能描述 1 日历展示1、 支持可视化设备运维日历， 系统可以日历的形式展示指定月份每日的工作任 务情况，并且可根据需求将指定月份的日历打印至A4 纸，方便查看管理； 2、支持在日历中展示每日任务类型、任务总数、完成状态，并用不同的颜色表示不同的任 务类型； 3、支持点击对应的日历中的对应日期打开所有的工作事项； 4、支持对每日工作进行跟踪，可按任务类型、按班组进行工作事项个跟踪；按类型类型跟 踪以列表方式显示任务名称、所属计划、周期类型、应巡日期、巡检部门、巡检人员、应巡 点数、实巡点数、完成状态等；按班组跟踪展示班组名称、任务总数、已完成、未完成、完 成率等数据； 5、在日历中，支持对列表点击查看任务执行的详情； 2 ★报修管理1、 维修派工：维修班组接收一站式服务中心分配的任务后， 可通过系统进行 派工处理，安排相对应的维修人员去现场处理。系统支持纸质工单打印。 2、维修接单：维修人员可通过系统接受一站式服务中心及班组长指派的维修任务，点击接 收表示认领维修任务，点击开始表示正式开始维修。 3、工单进度查询：报修人可通过系统进行维修工单的进度跟踪，实时掌握维修进展情况， 如是否已派工，接单维修人员是谁，何时开始维修，何时完工等。 4、维修完工：维修人员完成现场维修任务后，维修班组对该项维修工单进行完工处理，将 结果反馈给一站式服务中心及报修人。 5、维修抢单：维修人员可通过移动手持终端查询到当前班组内所有“未派工”的维修任务， 可根据自身实际忙闲情况对任务工单进行接单，抢单操作。 3 巡检/保养管理1、支持多种巡检方式，根据设备日常的管理方式和周期不同，制定设备 的巡检计划和巡检项目， 并可把巡检项目与任务书关联起来从而快速生成适合本医院的巡检 计划，巡检计划创建后可派发给责任班组或者责任人进行任务的执行； 2、支持多种任务分类方式，支持按自定义计划类别和设备分类方式显示待执行计划，通过 分类给用户提供快速筛选入口； 3、任务详情，以列表方式展示待执行任务，列表字段包括任务名称、周期频次、应巡点数、 已巡点数、应巡日期等，用户点开列表可查看任务详情并能对任务进行执行； 4、任务接收与执行，该任务中包含所有的巡检点的名称，并按顺序展示，用户点击对应的 巡检点查看巡检明细， 并按照巡检要求填写巡检结果进行上报。 巡检结果包括合格、 不合格、 报修等结果状态的上报及确认。 5、巡检结果合格和不合格处置；合格提交，巡检各项结果均正常。不合格提交，巡检明细 中有一项或者多项不符合要求， 系统可以自动把不符合项自动记录， 经用户同意后上报巡检 结果； 6、支持巡检异常报修，当巡检过程中发现有设备损坏，用户可选择提交报修单进行维修， 报修单内容可填写问题描述、图片、联系人、联系方式、录音等方式进行上报，系统接收到 报修记录会根据流程安排人员进行及时维修； 7、支持巡检有效性判断，为了确保巡检的真实性，巡检执行时支持设备二维码、蓝牙定位 点保障人员到现场执行，另外所有上报的图片均支持OSD 文字进行处理，在图片显示巡检 人员、部门、时间、GPS 定位坐标等记录； 8、 系统支持多种巡检方式根据用户管理需要进行限制， 如扫码开始巡检、按顺序执行巡检、 按巡检点执行巡检等方式； 9、系统支持多巡检模式，满足医院多样性管理的需求； 10、巡检点关联设备，可以把巡检点与设备管理，在巡检的过程中可以点击设备，查看设备 信息和运维记录，其中运维记录包括应巡检次数、实际巡检次数、应保养次数、实际保养次 数，下次巡检日期等。并可以以时间轴方式显示历史运维记录，点击运维记录可查看运维详 情 4 知识库管理1、内置针对常见的设备提供标巡检准作业书模板，包括冷热源、暖通排风、 变配电、污水处理、二次供水、电梯等系统，可供用户直接调取使用； 2、日常巡检知识库，用户可创建日期的巡检知识库，用户输入巡检内容、标准要求、巡检 依据即可创建自己的巡检知识库； 3、专业巡检知识库，支持数字填空（可配置着正常发范围，范围之外的自动判断为异常） ， 文本填空（即各类抄表，填写实际情况） 、单选（快速进行选择）以满足不同巡检要求； 4、支持对知识库的修改和编辑； 5、支持按知识库名称、类型等快速筛选查看知识库。 3.1.3、服务品质管理 3.1.3.1、智能一站式服务综合管理系统 序号功能项功能描述 1 ★一站式服务调度中心1、 任务提醒： 一站式服务中心接收到临床网络申请工单后， 系统 有任务提醒功能， 支持弹屏提醒、 声音提醒、 操作员可通过提醒界面直接进入工单进行调度， 将任务工单分配到对应服务班组，提高工单处理及时率。 2、 来电弹屏： 当临床用户通过院内分机来电报修时，系统可自动识别来电号码并弹屏提醒， 提醒内容可包括来电号码，来电科室，科室位置等。 3、工单优先级管理：调度员可根据工单的情况指定维修的优先级，最高级工单优先派单， 在未完工前永久停留在最上层。 4、紧急联系人：对于高优先级工单，可选择知会相关应急联系人，实现资源的协调和工单 的快速处理。 5、通话管理：可实现报修电话的全程录音，可在工单页面快速查找和回放；通过录音可实 时翻译成文字，支持对通过内容的快速复制，在工单详情中可查看工单录音文字内容。 6、计划工单：可对额定工作、定时、定期任务制定计划工单，定期定时发送工单到相关人 员。 7、自动派发工单：对于移动工单，科室人员指定位置和类型后，可实现无调度自动派单， 节省调度员工作量。 8、电话回访：针对完工工单、投诉事项进行回访跟踪，以确认工单完成效果、投诉处理结 果。 9、工单督办：针对延时、拖延、超时、紧急等工单事项，进行督办操作，相关人员接收督 办通知，以加快工作效率。 2 维修管理1、 报修登记： 当临床用户通过院内分机来电报修时， 系统可自动识别来电号码 并弹屏提醒，提醒内容可包括来电号码，来电科室，科室位置等。一站式服务坐席可通过来 电提醒界面直接进入工单登记界面，相关基础信息系统自动匹配，无需再次输入。 2、任务提醒：一站式服务中心将任务工单分派到班组后，班组管理系统自动弹屏新任务提 醒，操作员可由任务提醒界面直接进入相应工单，进行查看详情进行派工处理。 3、维修接单：维修人员可通过系统接受一站式服务中心及班组长指派的维修任务，点击接 收表示认领维修任务，点击开始表示正式开始维修。 4、工单转新单：维修人员可通过系统进行转新单操作，说明转单原因提交后由一站式服务 中心进行新工单的任务指派； 也可由班组自行进行工单转派， 备注转派信息；一站式可对转 派信息进行跟踪查看，系统对所有操作节点进行记录。 5、工单进度查询：报修人可通过系统进行维修工单的进度跟踪，实时掌握维修进展情况， 如是否已派工，接单维修人员是谁，何时开始维修，何时完工等。 6、维修挂单：维修人员接受班组派工后，进行现场服务，发现维修服务暂时无法完成，如 所需材料、配件短缺，需外送大修，需维保商维修等情况，可通过系统将工单暂停，录入暂 停说明等待维修条件成熟后恢复工单， 暂停信息将通过系统即时反馈报修人， 避免不必要的 催单。 7、维修完工：维修人员完成现场维修任务后，维修班组对该项维修工单进行完工处理，将 结果反馈给一站式服务中心及报修人。 8、维修工时费用登记：系统自动记录维修开始时间及完工时间，自动统计工时，费用，提 供相关数据报表以供决策。 9、接单任务：维修人员可通过移动手持终端查询到当前班组内所有“未派工”的维修任务， 可根据自身实际忙闲情况对任务工单进行接单， 抢单操作，避免班组与现场间的往返，提高 工作效率。 10、 维修任务：维修人员通过移动终端接单后进行现场作业， 可通过系统现场实时记录维修 情况，支持维修跟进信息录入，维修耗材、配件信息录入等，支持现场拍照上传，用于说明 维修完成情况，所有信息均可实时反馈至临床。 11、 维修抢单： 维修人员可通过移动手持终端查询到当前班组内所有 “未派工” 的维修任务， 可根据自身实际忙闲情况对任务工单进行接单，抢单操作。 12、 移动报障：维修人员发现不属于本班组或未进行故障报修登记的故障， 可通过手持终端 现场进行故障报修，提交报修工单到调度中心进行任务指派，系统支持拍照功能。 13、专用工单机：专用一体化单机，集成不小于10 寸多点触摸屏、打印机、高拍仪。实现 接单、派工、完工、工单查询统计、超时工单提醒等功能。可通过对纸质工单拍照做到线上 线下工单一体化。 14、快速报修：临床用户不仅可以通过利用传统的电话和PC 端报修，同时还可以用微信公 众号报修。支持选择高频报修内容或类别，进行快速的报修，提高临床用户的报修效率，同 时可与医院公众号对接，在医院公众号提供快速报修接口。 （微信功能需医院提供专用微信 公众号或与企业微信对接后实现） 3 工程仓库管理1、 维修单出库： 可根据维修单添加耗材， 所需耗材从耗材管理中直接添加， 耗材明细显示在维修单上，可实现快速检索和查询，统计分析。 2、库存统计：可通过系统实时查询耗材耗材使用情况，了解物料库存状态，支持多条件组 合查询，可通过物料名，物料批次进行综合查询。 3、耗材价格管理：实现耗材规格、价格统一登记与管理，维修时可直接使用。 4 报表管理1、维修统计查询：支持多维度、多口径分析统计报表，包括维修类别、报修趋 势、工单完成率、工时等等。同时可针对各维度工单内容，进行定制化统计查询、导出，对 超时工单、取消工单、挂单工单等进行数据分析。 2、维修用料查询：报修人可通过系统查询对应维修工单的维修用料情况，包括耗材、配件 使用明细，成本等。 3、定制报表：可根据用户所需自定义报表标题、列表，针对所需内容生成相关报表，满足 用户对数据统计的自定义操作。 4、例行报告管理：实现日报、周报、半月报、月报、季报、年报等标准制式的数据统计总 结报告一键生成。 5 大屏管理1、维修大屏：实现后勤运行数据、报修、维修、工单、工人排名，重点科室维 修监控数据实时动态展示。各项数据灵活展示。 2、工人大屏：支持后勤各班组工人工作量情况实时显示、动态展示。 3.1.4、应急处置管理 3.1.4.1、报警联动处置管理系统 序号功能项功能描述 1 警情类型管理支持报警类型的配置、至少支持消防报警、烟火报警、吸烟报警3 种报警 类型的配置和启停管理。 2 警情级别管理支持对所有的报警类型配置报警的级别。 3 警情联动配置管理支持根据警情类型配置警情的预案，包括警情的上墙、语音提醒、声 光提醒、警情弹窗等功能配置 4 报警中心1、支持在报警中心实时监测所有报警信息，当收到报警信息是立即弹出提醒； 2、支持展示所有报警信息； 3、支持报警的处置状态，如未处理、已处置等信息。 5 报警提示1、支持收到新报警时，通过弹窗的方式展示报警信息，内容包括报警类型、报 警级别、报警时间、报警对象、报警位置、报警内容等信息。 2、支持收到新报警时可通过警报声和语音的方式播放报警信息。 3、支持收到新报警时可联动报警器进行声光闪烁提醒。 6 警情处置1、支持报警时可进行确警、误报、演练操作。 2、支持确警、演练后可对报警进行派发工单操作，可制定工单处置人员和时间。 3、支持确警、演练后可对报警进行屏蔽操作，可设置报警屏蔽时间，屏蔽时间段内当前设 备不再重复报警。 7 报警工单1、 支持报警创建工单后， 工作人员可通过移动端进行接单、 指派、 完工、 取消、 挂单操作。 2、支持对报警信息处置，然后再工单上填写处置结果，并上传文字描述、语音、照片等信 息，进行完工操作。 3、支持在报警列表查看警情关联的工单完成进度，当工单完成后，警情状态自动修改为已 处置。 8 报警推送1、支持报警后可根据预案设置的通知人，自动推送短信报警信息至相关人员。 2、支持可通过短信查看报警的详细信息，包括报警类型、报警级别、报警时间、报警对象、 报警位置、报警内容等信息。 9 今日警情数量支持按照今日、本月、本年维度来统计报警数量信息，并按照报警分类进 行分类展示。 10 各类报警数量支持按照报警类型、报警的时间、报警的区域来统计报警数量信息 11 按科室统计支持按照报警区域、时间、类型等维度统计报警数量信息 3.1.5、后勤业务支撑管理 3.1.5.1、综合能耗智能监管系统 序号功能项功能描述 1 用能总览支持查看最近一个月的用能趋势曲线，查看的信息有：电力、水、天然气、综 合能耗等能源的用能情况， 同时能切换查看不同厂区的用能情况； 鼠标移动到曲线上可以查 看具体某一日的用能情况。 2 抄表维度1、 表计维度中展示当前所有表计及对应的信号， 可以通过点击信号前面的框来 选择查看或者取消查看某个信号对应的数据。 2、对象维度中展示所有用能单位的用能情况，可以通过点击用能单位前面的框来选择查看 或者取消查看某个用能单位对应的数据。 从能源分类中可以选择查看具体某种或者几种能源 对应的数据。 3 抄表曲线利用曲线的方式展示各表计的实时和历史抄表示数。 4 多维度监控支持多维度数据监控，可以查看表计维度、设备维度、对象维度等实时数据 和历史数据信息。 5 告警汇总分析1、 支持告警汇总分析对系统内所有告警记录进行统计分析， 分析维度包括： 按告警开始时间进行统计、按告警类型的分类进行统计、按照告警级别的分级进行统计。 2、系统支持上述统计数据按照告警开始时间范围进行查询。 6 告警汇总分析支持告警汇总分析对系统内所有告警记录进行统计分析，分析维度包括： 按告警开始时间进行统计、按告警类型的分类进行统计、 按照告警级别的分级进行统计。 系 统支持上述统计数据按照告警开始时间范围进行查询。 7 系统自监控告警将告警类型为系统自监控限告警的告警记录全部整理到此模块下，按照 告警开始时间、告警级别、告警状态进行快捷查询并支持列表中的对象、地点、告警内容、 处理人模糊查询功能，支持告警记录详情、备注功能。 9 设备故障告警将告警类型为设备故障告警的告警记录全部整理到此模块下，按照告警开 始时间、告警级别、告警状态进行快捷查询并支持列表中的对象、地点、告警内容、处理人 模糊查询功能，设备故障告警没有“告警值”和“限值” ，增加关闭、生成工单功能列表中 “任务状态”反应工单的状态，支持告警记录详情、备注功能。 10 能耗综合查询1、按照能源消耗及耗能工质种类分别统计用能单位维度、区域维度、组 织结构维度的能源消耗量。 除了用表格的形式展示外， 还使用趋势图直观的展示用能单位或 者区域的用能趋势；使用条形图展示用能单位或者区域的用能排名情况。 2、在列表中数据过多无法快速查看到想要查看的数据时，可以通过一些条件来过滤出想要 查看的数据。在综合能耗查询中，可以通过能耗分类、供给类型、统计周期及选择时间范围 来进行数据查询。还可以根据不同查询条件可以进行组合查询。 3、选择好需要展示的数据后，就可以看到表格数据对应趋势图/排名图，趋势图/排名图默 认显示数据为当前对应的数值。 11 能耗结构分析1、查询功能页面用于查询各维度下不同能源、统计周期的能耗、费用占 比。 2、在列表中数据过多无法快速查看到想要查看的数据时，可以通过一些条件来过滤出想要 查看的数据；在综合能耗查询中，可以通过能耗分类、供给类型、统计周期及选择时间范围 来进行数据查询，还可以根据不同查询条件可以进行组合查询。 3、用两个环形图分别来显示能耗占比和费用占比，能耗占比和费用占比分别用于显示每个 维度下不同用能单位在不同时段的能耗占比和费用占比情况， 鼠标在环形图上经过或悬停时 中间部分会显示该能源的详细信息。 12 时间段分析1、以曲线图的形式展示同种用能单位不同能耗或耗能工质情况在不同时间 段的能源消耗情况；同时可以选择开始时间，实现同种用能单位任意时间段曲线对比。 2、时间选择器中的日期和时间维度会根据选择的数据类型发生变化，当数据类型选择日， 查询时间的范围就会精确到日，可选的时间维度只显示大于日的，不能选择的设置为灰色； 能源类型只能单选，左侧的树可以多选。 13 报表方案1、进入页面后列表中默认展示所有的报表方案，也可以通过左上角查询条件 筛选出满足条件的报表方案。 2、可对已创建的报表方案进行启用、删除、编辑操作，可查看报表详情； 14 报表仓库1、在报表仓库中会展示所有已生成的报表； 2、通过左侧树结构和左上角查询条件筛选具体要查看的报表，点击报表具体所属的报表方 案，进入到报表方案详情页； 3、可下载报表，查看报表详情； 15 核算单位费价绑定支持通过对树结构模型绑定能源计费方式以及单价。 16 账单核算支持通过绑定的模型以及计费方式单价等信息，核算各个区域的账单信息。 17 定额用量根据用能单位维度/区域维度/组织架构维度， 对不同对象进行实际用量及与定 额值对比后的使用情况。 18 定额指标1、根据用能单位维度/区域维度/组织架构维度，对不同对象进行实际用量及 与定额值对比后的使用情况； 2、反馈对标结果，本期仅实现反馈达标/不达标/无法对比； 3、若无实际/定额指标值，则结果反馈无法对比。 19 能效对标1、根据对象维度与国家指标/地方指标/高效企业指标/企业历年数据指标等进 行对标； 2、反馈对标结果，本期仅实现反馈：优秀/达标/不达标； 3、仅有效指标可被选择与企业实际值进行对标。 20 指标管理1、展示国家指标/地方指标/高效企业指标/企业历年数据指标； 2、允许管理员新增基础指标信息及指标范围配置； 3、仅允许管理员修改及删除指标； 4、指标关联对应对象公式配置，最小数据周期为月。 21 定额管理管理员通过此功能，设定企业各对象维度定额值。 3.1.6、统一管理决策 3.1.6.1、后勤业务集成管理系统 序号功能项功能描述 1 系统功能1、 服务监督集成： 支持对后勤一站式服务各项不同维度的数据实时分析； 实时 分析数据有工单平均响应时间、工单平均完工时长、服务满意情况、近7 日回访率、本日超 时工单、本日总工单。 2、能耗监管集成：支持对能耗数据进行总览分析；支持对水能耗、电能耗数据进行统一维 度总览。 3、资产管理：支持对医院的资产数据进行集成，统一查看。 3.1.6.2、安全态势集成管理系统 序号功能项功能描述 1 系统功能1、 运行状态指标： 支持设备运行状态分析， 可分析设备离线、 在线、 故障时间。 2、各类报警数量：支持按照报警类型来统计报警数量信息。 3、警情数量趋势：支持按照同比、环比方式进行分类统计报警趋势。 3.1.7、第三方系统数据对接开发 与现有的楼控、安防、消防、能耗系统对接，实现数据统一接入平台统计分析。 软件接口如下： 3.1.8、风机盘管温控器智能控制改造 3.1.8.1、概述 本项目将妇产综合楼原有的697 个风机盘管温控器改造为智能风机盘管温控器， 智能风机盘 管温控器通过485 总线制联网， 实现对空调的自动化控制应用程序接口。 风机盘管智能控制 改造需与采购人目前现有楼宇自控系统（源创自动化监控软件V8.0）进行控制和数据对接 （控制和数据维度包括但不限于设备接入、基础控制、策略控制、组态系统、数据报表与统 计、协议与接口、跨系统联动等） 3.1.8.2、技术要求 3.1.8.2.1、风机盘管温控器要求 风机盘管温控器类型：所有风机盘管温控器必须支持Modbus RTU 协议，并通过485 总线 进行通信。 功能：风机盘管温控器应具备空调开关控制、温度设定、模式切换（制冷/制热/通风） 、风 速调节等功能。 显示界面：风机盘管温控器应配备清晰的显示界面，显示当前温度、空调状态及设定值。 操作：风机盘管温控器应支持本地手动操作，同时支持远程自动控制。 3.1.8.2.2、485 总线及网络控制器要求 总线制联网：所有风机盘管温控器通过485 总线联网，485 总线应符合RS-485 标准，支 持多点通信。 网络控制器：485 总线通过网络控制器转换为Modbus TCP 协议，网络控制器应支持 Modbus RTU 到Modbus TCP 的转换，确保数据在网络上传输的稳定性与可靠性。 数据传输速率：网络控制器应支持至少9600 bps 的数据传输速率，确保系统响应时间在可 接受范围内。 3.1.8.2.3、楼宇自控系统对接要求 协议支持：楼宇自控系统必须支持Modbus TCP 协议，能够通过网络控制器与风机盘管温 控器进行通信。 统一控制： 楼宇自控系统应具备对所有空调控制风机盘管温控器的统一管理功能， 实现定时 控制、远程控制、状态监视等功能。 智能控制：系统应支持基于环境传感器数据（如温度、湿度）的智能化控制，自动调节空调 运行模式。 3.1.8.2.4、智能可视化管理平台集成要求 应用程序接口：楼宇自控系统通过应用程序接口将空调的关键数据（如温度、运行状态、故 障报警等）传输至智能可视化管理平台。 远程监控： 智能可视化管理平台应具备远程监控功能，能够查看每个空调的当前状态、设定 值以及历史数据。 控制功能：智能可视化管理平台应具备远程控制功能，包括空调的开关控制、温度设定、模 式切换等操作。 报警管理： 当空调出现故障或异常状态时， 系统应能够通过应用程序接口将报警信息传输至 智能可视化管理平台，并触发相应的报警机制。 3.1.8.3、实施要求 3.1.8.3.1、设备安装 风机盘管温控器安装： 每个房间及公共区域的风机盘管温控器应安装在便于操作的位置， 安 装高度符合人体工程学标准（建议安装高度为1.2-1.5 米） 。 485 总线布线：所有风机盘管温控器通过485 总线连接，布线应符合国家和行业标准（如 《建筑电气工程施工质量验收规范》GB50303-2015）要求。尽量减少线缆长度，避免信号衰 减。 网络控制器安装： 网络控制器应安装在机房或弱电间， 确保与楼宇自控系统的网络连接稳定 可靠。控制器应便于维护和检查。 线缆接入：所有485 总线和网络线缆的接入应符合标准规范，确保接头牢固、连接可靠， 避免松动或接触不良。 3.1.8.3.2、系统调试 风机盘管温控器调试：在安装完毕后， 需要对每个风机盘管温控器进行功能调试，确保其能 够正常控制空调的开关、温度和模式切换。 通信测试：确保485 总线通信稳定，测试所有风机盘管温控器的通信情况，确保数据能够 通过网络控制器正确传输至楼宇自控系统。 集成测试： 进行楼宇自控系统与智能可视化管理平台的集成测试， 确保关键数据能够通过应 用程序接口正常传输，智能可视化管理平台能够有效监控和控制空调。 性能测试： 对系统进行性能测试， 确保在高并发情况下， 系统响应时间和控制精度符合项目 要求。 3.1.8.4、安全性要求 3.1.8.4.1、数据安全 加密传输： 通过网络控制器传输的数据应使用加密协议进行保护， 防止数据在传输过程中被 篡改或窃取。 权限管理： 系统应对不同用户的操作进行权限管理， 确保只有授权人员可以对空调进行控制 和配置。 3.1.8.4.2、系统稳定性 冗余设计： 网络控制器和楼宇自控系统应具备冗余设计， 确保系统在设备故障或网络断线的 情况下能够继续正常运行。 故障报警： 当风机盘管温控器或网络控制器出现故障时， 系统应能够及时发出报警， 并记录 故障信息，便于后续维护。 3.1.8.5、维护要求 3.1.8.5.1、设备维护 定期巡检：对风机盘管温控器、485 总线、网络控制器进行定期巡检，确保设备运行正常、 通信稳定。 设备更换： 若风机盘管温控器或网络控制器出现故障， 需及时更换， 并对系统进行重新调试。 系统升级： 根据楼宇自控系统和智能可视化管理平台的版本升级需求， 定期对应用程序接口 和控制逻辑进行升级和优化。 3.1.8.5.2、数据备份 日志记录： 系统应记录空调控制的操作日志和故障日志， 并定期进行数据备份， 确保历史数 据的完整性和可追溯性。 3.2、智能可视化管理平台 3.2.1、可视化数字孪生引擎系统 序号功能项功能描述 1 ★模型管理1、基础建模： （1）支持多种类型模型格式导入，包括：FBX、3DS、STL、OSGB、OBJ、DAE、DGN 、DWF、 IGES、RVT 等； （2）支持广域GIS 地图模型，三维园区模型以及室内三维模型的渲染与展示； 2、效果渲染：支持晴天、阴天、雨、雪等天气的渲染，并可在连接天气预报的情况下，实 现天气场景的自动切换。 支持白天和夜晚场景渲染， 可根据时间自动切换白天和黑夜的场景， 以及太阳和月亮在天空中的角度。 2 数模融合1、空间数据可视化：支持对院区、楼宇、楼层、分区、房间多级空间管理，可 实现对空间的功能类型、 所属科室、空间面积等多种属性进行管理，通过多种维度的统计分 析，实现对空间的精细化管理。 2、环境质量可视化：支持将空间内安装的各类型环境质量传感器获取相关环境品质数据， 并把环境的数据显示到模型中，实现环境质量的可视化管理。 3、能耗分析可视化：支持将各类能耗设备的信息同步至相应设备的数字孪生中，通过三维 透视的方式展现出来，同时给出不同维度数据分析示例、管理报表等。 4、人员定位可视化：支持在三地图模型上将定位的工作人员位置以图标的形式进行展示， 同时可点击查看该人员的具体信息。 5、支持通过可视化模型方式展示全院的建筑布局，展示全院空间数量、建筑面积等数据。 6、支持按使用部门、用途进行空间统计，并以柱状图展示统计结果。 7、支持在不同建筑模型之前进行切换，显示该建筑的空间数据 8、支持切换到楼层，使用不同的颜色表示不同的房间不同的功能用途，并能按不同用途筛 选空间并展示。 3 使用运维1、支持对各种模型查看视角的操作，包括旋转、翻转、拖拽、放大、缩小等。 2、支持室内地图和室外地图的任意切换。 3、支持视觉焦点动态切换，可自动将视觉焦点切换至选中的模型，后续的旋转、翻转等操 作将以此建筑为中心变化视觉。 4、支持对摄像头、水表、电表等各类设备作为信息点位进行进在地图上快速部署。 5、系统支持医用气体，视频监控，给排水，中央空调，能耗数据的统一展示，进入各监测 系统无新页面跳转。 3.2.2、可视化图形组态引擎系统 序号功能项功能描述 1 图形分类管理支持用户自定义模板分类，包括架构拓扑、电力能源、智慧医疗、智慧园 区。 2 组件库管理1、支持物联网，基础图形，表单，脑图，echarts 图表控件； 2、支持图形库自定义扩展：格式支持js、svg、jpg、iconfront 等。 3 多端适配1、支持组态设计页面内嵌集成到第三方平台； 2、支持导出HTML、Vue、React 等离线部署包； 3、支持网页端浏览器，支持移动端方式访问。 4 ★图纸绘制1、支持拖拽编辑、组态图的导入导出； 2、支持数据绑定，实时动态数据显示，数据下发，双向数据通信，条件、格式化显示； 3、支持逐帧动画和轨迹动画，条件告警动画等； 4、支持事件（鼠标移入、移出、按下、弹起、单击、双击） 、消息，组态联动； 5、支持组合、自定义状态、开关、报表、弹框、视频等； 5 数据通信1、支持mqtt 动态数据监听 2、支持websocket 动态数据监听 3、支持超文本传送协议自主请求动态更新数据 4、支持静态数据创建及导入 6 事件交互1、支持实时数据、报警数据事件的触发、监听和处理逻辑，根据事件的类型和 预设的处理逻辑，执行相应的事件处理逻辑 2、支持事件过滤功能，允许组件根据规则过滤数据。提高系统的性能和响应速度 3、支持系统消息、自定义消息、生命周期系统接口函数等 3.2.3、可视化数据驾驶舱管理系统 序号功能项功能描述 1 ★综合服务报修工单来源统计： 1、按今日、近7 天、近30 天、自定义日期进行数据统计； 2、统计结果以饼状图展示来源数量及所占百分比； 3、对工单详情查看，点击数字跳转到工单详情，显示工单总量、已完工、未完工、已取消、 完工率、平均响应、平均完工、返修率、综合评分、回访率等数据； 4、点击列表查看工单详情，实现工单的全生命周期跟踪 工单统计： 1、实现按今日、近7 天、近30 天、自定义日期进行数据统计； 2、实现对各状态工单的数量进行展示，展示其平均响应时长、平均完工时长、回访率； 3、实现对工单详情查看，点击数字跳转到工单详情，显示工单总量、已完工、未完工、已 取消、完工率、平均响应、平均完工、返修率、综合评分、回访率等数据； 4、实现点击列表查看工单详情，实现工单的全生命周期跟踪。 2 能耗统计分析1、支持按今日、近7 天、近30 天、自定义日期对用能情况进行总览分析； 2、用电数据总览，对累计用电量、累计费用、同比、环比数据进行查看。 3、支持以模型方式展示医院建筑名称和每栋建筑的用电量总量； 4、支持切换建筑模型，在模型上展示建该筑用电总量，每层楼的用电总量量，展示每层楼 用电量使用不同的深度颜色表示用电量大小； 5、 支持电表位置展示， 展示楼层电表位置分布，点击每个电表可展示当前电表的实时数据； 6、支持能耗数据统计，可按今日、本周、本月、本年、自定义日期方式统计用电量，展示 能耗总量、同比、环比、能耗费用数据，去年同期数据、能耗定额数据。 7、支持能耗模型展示，展示按电梯、照明插座、特殊用电、动力、空调用电的数据使用数 据。 3 BIM 可视化- 模型展示： 1、实现使用移动平板电脑实现对医院室内外三维可视化模型查看； 2、实现通过手指触摸移动、旋转模型； 3、实现通过手指触摸放大模型； 4、实现对设备模型进行查看，真实线上物理结构及设备所处的空间。 3.2.4、智慧电梯运行监测管理系统（对接，现有三菱品牌电梯） 序号功能项功能描述 1 运行数据融合1、支持系统电梯运行状态的实时展示。 2、支持用户可通过选择指定的电梯，查看其实时运行状态，包括电梯名称、位置、所在楼 层、上下行状态、运行速度、是否载人等详细信息。 2 报警统计支持以饼状图显示各类型的报警数量及百分比，选择饼状图时会具体显示报警 名称和报警的具体数量。 3 报警列表支持实时对电梯报警状态进行监测，显示报警时间、报警设备、报警类型、处 置状态等。 4 报警趋势支持以趋势图展示设备历史报警数量。 5 运行时长排行以柱状图统计所有电梯总运行时长的排行，单位为小时。 6 运行楼层排行以柱状图统计所有电梯运行楼层的数量排行，单位为层。 7 运行距离排行以柱状图统计所有电梯运行总距离的排行，单位为米。 8 ★运行实时监测1、 监测数据展示：支持以列表方式电梯运行的基础数据信息， 包括电梯 名称、开关门次数、电梯健康评分、电梯运行次数、电梯运行距离、电梯运行时间、电梯震 动状态等。 2、实时状态：支持多种实时运行数据监测，包括：运行状态、是否载人、当前速度、左右 偏移、前后偏移、当前楼层、梯门状态、运行震幅度、轿厢温度、轿厢湿度。 3、实时视频：支持对对电梯监控视频进行实时远程查看，发生异常可第一时间了解电梯内 部情况。 9 报警管理1、报警提醒：报警中心实时接收各电梯报警，支持报警声音播放提醒。 2、报警清单管理：报警数据显示电梯监测项名称、报警参数名称、报警原因、地理位置、 最新报警时间、处置状态等。 3、警情确认处置： （1）支持值班人员对报警记录做处理，报警处理可填写处置人员、处置人电话、处置结果、 处置结果说明、相关附件等； （2）支持报警批处理功能，一键修改全部报警状态. 4、警情概览：显示今日、本月、本年报警数量，支持用户自定义查询时间。 10 统计分析支持按今日、本月、本年、自定义时间方式进行统计，结果以表格和柱状图展 示电梯运行时间排行情况。 3.2.5、医用气体预警监测管理系统（对接，现有液氧站） 序号功能项功能描述 1 液氧储罐监测对液氧储罐的实时压力、实时液位、输出压力、进行监测采集，并可以把 数据实时传递到web 端、移动端进行实时显示，异常数据在页面有提醒显示。 2 站房空间环境监测支持对站房氧气浓度、温度进行检查采集，并可以把数据实时传递到 web 端、移动端进行实时显示，异常数据在页面有提醒显示。 3 仿真模型以图形化界面实时监控直观展示生产动态，对现场设备实现直接或间接控制， 满足可视化管理的需求。 4 报警接收实时接收前端设备各类状态数据，并能对状态是否异常进行判断，当数据超过 既定的阈值则判断为状态异常进行报警提醒。 5 报警提醒以声音、弹框等方式进行报警提示，提醒值班人员进行处置，并根据设置的安 全责任信息，把报警信息以短信、移动端消息方式进行推送。 6 报警处置对报警处置结果进行信息的录入，确保报警都得到处置和闭环。 7 报警统计以时间为维度实现报警状态统计、报警数量、设备报警、报警类型统计。 8 真空罐压力监测对真空罐压力数据进行实时监测，并可以把数据实时传递到web 端、移 动端进行实时显示，异常数据在页面有提醒显示。 3.2.6、供配电监测管理系统（对接，深证中电品牌系统） 序号功能项功能描述 1 配电室运行概况1、 显示当前配电室名称， 若项目具备多个配电机房， 可点击列表选择其 他机房，查看机房运行概况； 2、视频监控管理，点击可查看当前配电室内视频监控画面，视频墙形式显示，可显示多个 监控画面，选中单个可全屏查看监控画面，可对画面视角、焦距、方向进行控制，可查看历 史画面。 3、变压器设备运行状态查看，点击可打开变压器设备清单目录页，展示当前配电室内变压 器设备运行数据，包含额定功率、视在功率、负载率、用功功率、无功功率、功率因数、当 月最大需量、额定电流、ABC 相电流（运行参数可配电设备典表） ，展示变压器历史数据， 可通过日期进行筛选查看历史运行数据， 选择参数类型查看历史运行数据， 可切换数据展现 形式（图表、数据列表） 。 4、报警统计：统计今日当前配电室产生报警记录总数，未处理、处理中数量； 5、报警占比：查看当前配电室下设备产生报警类型占比； 6、巡检指标：查看今日、本周、本月应巡、已巡、巡检完成率。 7、支持可视化模型方式展示配电室，可对多个配电室进行切换，显示配电室物理空间设备 信息； 8、支持实时查看配电柜的运行数据，包括电流电压等数据。 2 变压器监测1、 显示当前配电室名称， 若项目具备多个配电室， 可点击列表选择其他配电 室，查看配电室下变压器设备运行数据； 2、变压器设备运行状态查看，点击变压器设备清单目录，展示当前选中变压器设备运行数 据，包含额定功率、视在功率、负载率、用功功率、无功功率、功率因数、额定电流、ABC 相电流（运行参数可配电设备典表） ，展示变压器历史数据，可通过日期进行筛选查看历史 运行数据，选择参数类型查看历史运行数据，可切换数据展现形式（图表、数据列表） 。 3 视频监控1、 显示当前配电室名称， 若项目具备多个配电室， 可点击列表选择其他配电室， 查看配电室视频监控画面； 2、视频墙形式显示，可显示多个监控画面，选中单个可全屏查看监控画面，可对画面视角、 焦距、方向进行控制，可查看历史画面。 4 配电系统图1、 显示当前配电室名称， 若项目具备多个配电室， 可点击列表选择其他配电 室，查看配电室配电系统图； 2、展示当前配电室配电系统图，配电系统scada 图可视化展示该系统的运行原理，设备上 下游关系及实施运行数据（运行参数可配电设备典表） ，可对系统图进行全屏、放大、缩小 等操作。 5 电力数据1、 显示当前配电室名称， 若项目具备多个配电室， 可点击列表选择其他配电室， 查看配电室电力数据； 2、原始电力数据显示选定配电室选定回路的电力数据，可切换展现形式数据列表或曲线图 表； 3、数据类型包括电流、相电压、线电压、频率、功率因数、有功功率、无功功率、视在功 率、电压、电流不平衡度等参数，可进行开始结束时间进行查询，并支持导出图表；方便用 户通过表格查询数据； 4、可切换极值电力数据显示统计时间范围内各运行参数日最大、最小、平均值。 6 电力运行日报1、 显示当前配电室名称，若项目具备多个配电室， 可点击列表选择其他配 电室，查看配电室电力数据； 2、电力运行报表数据显示选定配电室选定回路的电力运行日报数据，显示选择日期内逐时 数据； 3、数据类型包括全部、相电压或线电压、频率、功率因数、有功功率、无功功率、视在功 率、电压、电流不平衡度等参数，可进行日期进行查询，并支持导出图表；方便用户通过表 格查询数据。 7 分时段用电1、 显示当前配电室名称， 若项目具备多个配电室， 可点击列表选择其他配电 室，查看配电室分时段用电数据； 2、用能数据显示选定配电室选定回路的用能数据； 3、数据显示类型选定回路尖峰、平时、谷峰分段用电量及合计用电数据，可进行日期范围 进行查询，并支持导出图表；方便用户通过表格查询数据。 3.2.7、给排水监测管理系统（对接，现有源创智控品牌系统） 序号功能项功能描述 1 多维查询支持系统支持按今日、本月、本年、自定义时间方式查询各数据。 2 数据总览系统支持高液位、低液位、故障数量、离线设备数量的运行统计。 3 设备运行统计1、支持以分组方式展示水泵运行时长、平均运行率统计； 2、支持支持以折线图展示分时运行时长情况； 3、支持支持对单设备详情的运行数据的查看。 4 报警统计1、显示报警总数、未处理报警数、处置中报警等数量； 2、支持按并状态查看各类型包报警的占比。 5 组态可视化支持以组态视图的方式站各设备物联逻辑拓扑结构和设备点位信息，在组态 视图上支持查看设备实时实时数据查看。 3.2.8、冷热站监测管理系统（对接，现有源创智控品牌系统） 序号功能项功能描述 1 运行总览1、多维查询：系统支持按今日、本月、本年、自定义时间方式查询各数据。 2、数据总览：系统支持冷热源系统故障数量、离线数量、总耗电量、总耗水量、总供冷量、 总供热量、平均能耗比等数据的统一预览。 3、供冷趋势分析：支持以折线图显示供冷趋势和各时间段内的能效比。 4、供热趋势分析：支持以折线图显示供热趋势和各时间段内的能效比。 5、报警统计：显示报警总数、未处理报警数、处置中报警等数量；支持按并状态查看各类 型包报警的占比。 2 运行监测1、 组态可视化： 支持以组态视图的方式站各设备物联逻辑拓扑结构和设备点位 信息，在组态视图上支持查看设备实时实时数据查看。 2、水泵运行监测：对水泵开关机状态、电流、电压、手自动状态、运行频率等数据进行监 测。 3、展示空调末端设备数量，各状态数量；可按建筑按区域查询末端设备，显示设备运行状 态；以组态图显示设备运行状态； 3.2.9、公区照明监控管理系统（对接，现有欧普照明品牌系统） 序号功能项功能描述 1 运行总览1、支持显示当前系统回路总数，模块总数； 2、支持显示照明回路状态，包括开启状态、关闭状态、其他状态等，并以饼状图展示； 3、异常数据显示，显示当前系统模块离线数、模块故障数、回路控返不一致模块数量。 2 楼层照明信息显示1、 支持按楼层统计该楼层下的回路数量、 回路开关状态， 开关状态以 饼状图展示； 2、列表展示该楼层下的模块名称、模块下回路名称、回路服务空间的信息等； 3、支持查看该单回路的状态，并能进行回路状态控制； 3 照明回路台账1、支持用户自定义照明分组，支持分钟的新增、编辑、删除等操作； 2、支持通过设备名称、设备编码、所在建筑、所在楼层筛选查找设备 2、支持批量修改回路分组； 4 计划配置1、支持用户配置照明控制执行计划； 2、支持用户创建计划年份、时间区间、周期、运行模式；周期可选周一到周五，运行模式 可选工作日，周六日模式； 3、支持计划已月历方式显示，有运行计划的使用绿色显示，无运行计划的不显示任何颜色; 4、支持用户对计划进行编辑保持操作； 5 运行日历1、支持按年、月方式显示运行日历； 2、年运行日期可按年度切换，并显示12 个月的运行策略； 3、月运行日历默认显示本月运行策略，支持快速切换查看运行详情； 4、运行状态显示，在日历中可显示对应日期的运行模式，显示天气情况，日出日落时间等， 6 运行模式配置1、支持用户自定义多种照明模式以适应不同照明控制的需求； 2、新建场景运行模式包括模式名称、天气类型（晴天、阴天、暴雨天、沙尘暴） 、运行颜色 管理； 7 运行场景配置1、支持用户在模式下创建不同的照明场景； 2、可对不同的模块或者照明分组配置不同的照明场景； 3、可对不同的场景配置时间表，根据配置的时间表执行不同的时间策略； 3.2.10、视频监控集中监测管理系统（对接，现有浙江大华品牌系统） 序号功能项功能描述 1 视频预览支持查看视频设备实时画面，双击放大设备画面，调整查看视频路数，拖动设 备到预览区域预览画面。 2 录像回放支持对视频设备的历史录像进行回访、快进、倍速播放、拖动视频的时间轴、 下载视频。 3 动态追踪支持当发现人员信息是可截图保存人员记录，最终追踪完成保存追踪记录，支 持下载。 4 视频离线支持对摄像机状态监测，设备因异常状态离线时，显示设备离线的标识 3.2.11、门禁集中监测管理系统（对接，现有浙江大华品牌系统） 序号功能项功能描述 1 远程控制支持远程对门禁进行开门、关门、长开或长关的设置，支持一键开门或一键关 门。 2 权限下发支持对人员进行门禁开门权限的下发。 3 门禁报警支持对门禁设备进行报警配置，当监测到门禁状态属于报警时产出门禁报警。 4 门禁故障支持对门禁状态监测，门禁设备因异常状态导致门禁故障时。 5 出入记录支持对所有通过门禁设备验证后开门，开门的记录进行保存。 6 三维模型展示支持已经在三维模型中标定的门禁设备，支持在三维地图中显示门禁设备 的图标。 3.2.12、智慧消防监测预警系统（对接，现有海湾品牌系统） 序号功能项功能描述 1 设备台账1、 支持对消防水泵、 消防水池、 高位水箱、 末端试水、 消火栓的台账进行维护， 支持设备进行增、删、改、查； 2、消防风系统：支持对消防排烟风险、消防送风风机的台账进行维护，支持设备进行增、 删、改、查； 3、防火门系统：支持对消防防火门的台账进行维护，支持设备进行增、删、改、查； 4、消防报警系统：支持对烟感探测器、温感探测器、消防手报的台账进行维护，支持设备 进行增、删、改、查。 2 状态监测1、消防报警：支持监测消防主机中烟感、温感、手报的报警信息，发生报警时 立体推送报警模块； 2、消防故障：支持监测消防主机中烟感、温感、手报的故障信息，发生故障时自动生成故 障工单； 3、运行状态：支持监测消防水泵的启停、消防水池的液位、末端试水的压力、风机的启停、 防火门的开关和开门时间等运行状态信息。 3 可视化展示支持在三维模型中标定的消防设备位置， 根据消防系统内的设备有监测状态， 当监测到设备故障的异常状态出现时会显示设备故障信息。 3.2.13、地图制作 妇产综合楼6.7 万平米 支持基于建筑CAD 图制作全院室内外空间模型； 模型以框架展示为主，可通过立体图形展示出楼宇、楼层、房间的框架结构； 支持通过颜色区分不同的建筑区域，用于建筑空间示意。 3.3、系统硬件要求（数量明细见采购清单十） 3.3.1、智慧医院运行保障系统基础服务主机 1、软硬一体化专用设备，采用工业级嵌入式高性能硬件平台架构，配置ARM 架构处理器， 满足信息技术应用创新要求 2、主机配置不低于：处理器，主频2.2GHz（动态加速频率2.9GHz， 12 核，24 线程）*2；内存，64G；存储，8T*2RAID1 3、电源：550W 双电冗余 4、设备外形：4U 标准机架设备 5、支持2 个千兆光纤st 接口，满足主机运行的稳定监测。 6、基于国产安全系统内核定制操作系统，内嵌高可靠性防火墙和杀毒系统；内置业务数据 库、文件数据库、时序数据库； 为其他选配软件模块提供硬件运行环境。 7、预置医院基础业务中台管理系统，包括但不限于流程管理、计划管理、信息推送管理、 统一登录管理，权限管理、数据分析引擎、报表管理、日志管理、消息总线引擎，个人工作 台管理等。 8、专用设备内部配有机箱环境监测传感器，机箱前风机盘管温控器自带屏幕循环显示处理 器温度、系统温度、ip 地址等。 9、此设备安装于医院信息中心机房内。 3.3.2、安防系统对接网关 1、支持多个Modbus 协议，ModbusoverTCP 等标准通信协议和开关量等专用硬件接口。 2、支持与视频监控、门禁、报警等第三方系统进行接口对接，负责将第三方协议转换为平 台内部标准协议，实现两个系统间的物理隔离， 保障主系统运行稳定， 支持与第三方系统协 议进行定制开发适配 3、网络接口不低于：100M/1000M 以太网*2，光纤转换接口*2 4、串口不低于：RS485 接口*2 5、此设备安装于医院信息中心机房内。 3.3.3、消防系统对接网关 1、支持多个Modbus 协议，ModbusoverTCP 等标准通信协议和开关量等专用硬件接口。 2、支持与消控主机、电气火灾、可燃气体等第三方系统进行接口对接，负责将第三方协议 转换为平台内部标准协议，实现两个系统间的物理隔离， 保障主系统运行稳定， 支持与第三 方系统协议进行定制开发适配 3、网络接口不低于：100M/1000M 以太网*2，光纤转换接口*2 4、串口不低于：RS485 接口*2 5、此设备安装于医院信息中心机房内。 3.3.4、楼控系统对接网关 1、支持多个Modbus 协议，ModbusoverTCP 等标准通信协议和开关量等专用硬件接口。 ★2、支持OPC，楼宇自动控制网络数据通讯协议等多种楼控系统对接协议，支持与第三方 系统协议定制开发适配。 3、网络接口不低于：100M/1000M 以太网*2，光纤转换接口*2 4、串口不低于：RS485 接口*2 5、此设备安装于医院信息中心机房内。 3.3.5、网络安全数据互联主机 1、支持多个Modbus 协议，ModbusoverTCP 等标准通信协议和开关量等专用硬件接口。 ★2、支持网络安全类第三方系统进行接口对接，负责将第三方协议转换为平台内部标准协 议，实现两个系统间的物理隔离， 保障主系统运行稳定， 支持与第三方系统协议进行定制开 发适配。 3、网络接口不低于：100M/1000M 以太网*2，光纤转换接口*2 4、串口不低于：RS485 接口*2 5、此设备安装于医院信息中心机房内。 3.3.6、智能电话调度网关 1、设备接口：支持FXS 接口、FXO 接口、PC/WAN 接口、USB 接口、CON 接口等。 2、逃生功能：断电时正常使用电话通讯功能。 3、自动话务员功能：设备支持自动话务员功能/支持单层语音导航与多层语音导航，支持更 换内容与声音。 4、消息推送功能：可将振铃、通话、挂断的通话事件推送至平台。 5、外线功能：设备支持外线功能，打开此功能支持该分机用户将外线来电转接至第三方话 机。 6、 分机锁功能： 实现分机锁功能， 上锁分机仅能拨打内线， 拨打外线需要输入授权码 （PIN） 认证。 7、直通车功能：支持直通车功能，允许预设手机（如员工手机）呼入设备的外线后，无需 输入功能码即可通过设备进行外呼。 8、呼叫转移功能：支持呼叫转移功能，可将全部来电转另一话机、无法接听时转另一话机、 遇忙时转另一话机、无应答时转另一话机、全部来电转语音留言、遇忙/无应答时转语音留 言。 9、录音与留言功能：支持G.711 和G.729 录音、留言，且支持远程录音保存和本地录音保 存两种录音方式。 10、此设备安装于医院信息中心机房内。 3.3.7、智能工单处理服务站 1、设备配置不低于：处理器：1.2GHz/RAM：1GB/Flash：8GB/屏幕：≥10 寸电容触摸屏， 分辨率：1280*800，操作系统：国产操作系统 2、支持网络：设备支持WIFI 无线局域网、100M/1000M 以太网接口以及全网通的4G 及以 上网络 3、打印方式：设备支持内置热敏打印58mm，打印速度不低于50mm/秒 4、工单回收：设备支持使用高拍仪对工单进行拍摄扫描回收，分辨率≥500 万像素；可拍 摄不低于2560*1920 分辨率的照片/设备支持扫码二维码打开工单，进行工单完工操作。 5、语音提示：设备具有来单声音提示，语音播报正确，音量大小可调节 6、工单查询：设备支持查询本班组工单信息的功能，包括完工工单，挂单工单，派公工单/ 支持按年、月、日进行工单查询。 7、提示方式：设备支持新收到工单，工单处理超时，挂单工单的声音提醒，并可对工单提 醒的频率进行设置。 8、此设备安装于医院信息中心机房内。 3.3.8、风机盘管温控器 1、量程：不少于高、中、低、自动四档； 2、精度：±1℃； 3、信号类型：RS485； 4、电源电压：220VAC； 5、安装配件说明：预埋86 底盒，黑色，触摸按键； 6、防护等级：≥IP54； 3.3.9、风机盘管网络控制器 1、不少于1 个以太网口10/100Mbps 自适应(Modbus TCP 协议)，不少于2 个RS485，不少于 1 个232 通用口(Modbus RTU 协议、Modbus TCP 协议)； 2、不少于接入32 个设备，最大支持不少于512 点； 3、处理器不低于32 位ARM M4； 四、建设工期和质保期要求 4.1、建设工期 自项目合同签订之日起，3 个月内完成。 4.2、质保期要求 软件质保期≥3 年，硬件质保期≥3 年（提供原厂质保服务） 。 五、系统安全性要求 5.1、数据安全 5.1.1、数据存储安全 加密存储：所有敏感数据（如用户信息、设备信息、后勤管理数据等）应采用强加密算法进 行存储，确保即使数据泄露也无法被未经授权的人员读取。 数据库加密：数据库中的关键字段（如账户信息、认证信息）应进行加密处理，防止数据库 被直接访问时的数据泄露。 文件存储安全：系统上传的文件（如设备文档、维修记录）应存储在安全的文件服务器上， 并采用加密技术保护。 5.1.2、数据传输安全 传输加密： 所有数据在网络上传输时必须使用安全的传输协议进行加密， 防止数据在传输过 程中被截取或篡改。 VPN 或专用网络： 在必要时， 建议使用虚拟专用网络或专用网络来确保医院与外部系统之间 的数据传输安全。 5.1.2.1、数据访问控制 最小权限原则： 系统中的所有用户和服务应遵循最小权限原则， 确保每个用户只拥有其工作 所需的最低限度权限。 角色与权限管理：系统应具备完善的角色与权限管理功能，不同的用户角色（如后勤人员、 管理者、IT 管理员等）应拥有不同的权限，限制对敏感数据的访问。 多因素认证： 对于系统管理员和其他拥有高权限的用户， 系统应要求启用多因素认证以提高 登录的安全性。 5.1.2.2、数据备份与恢复 定期备份： 系统应具备自动备份功能， 定期对数据库和文件系统进行备份， 确保系统在发生 数据丢失或灾难时能够迅速恢复。 异地备份：备份数据应存储在异地，确保在发生自然灾害或物理破坏时不会丢失关键数据。 数据恢复机制：系统应具备完善的数据恢复机制，确保在数据丢失、损坏或被非法篡改后， 能够快速、安全地恢复到正常状态。 5.1.2.3、数据脱敏与匿名化 敏感数据脱敏： 在测试环境或非生产环境中使用真实数据时， 应对数据进行脱敏处理，确保 敏感信息（如用户名、联系方式等）不会在测试或开发阶段泄露。 数据匿名化：对于需要共享或展示的数据， 系统应支持数据匿名化处理，确保不会暴露患者 隐私或其他敏感信息。 5.1.2.4、数据审计与监控 操作日志记录：系统应记录所有关键操作的日志信息，包括数据的创建、读取、修改、删除 等操作。日志应包含操作时间、执行用户、操作内容等信息，确保操作可追溯。 异常行为监控： 系统应具备实时监控功能， 能够识别异常的访问行为或操作行为，并自动生 成警报，如异常的大量数据导出或频繁的登录失败。 日志保留策略：操作日志应按照医院的合规要求进行长期保存，并确保日志文件的安全性， 防止被篡改或删除。建议至少保存6 个月到1 年的日志记录。 5.1.2.5、数据生命周期管理 数据存储期限：系统应具备数据存储期限管理功能，确保不必要的数据（如历史操作记录、 过期的任务记录等）能够按期自动删除或归档，减少数据泄漏的风险。 数据销毁：当数据不再需要时（如合同到期、用户注销等） ，系统应支持安全销毁数据的功 能，确保数据不会被恢复或泄露。 5.1.2.6、数据加密密钥管理 密钥管理策略： 系统应使用安全的密钥管理机制， 确保数据加密和解密所需的密钥安全存储 和使用。密钥应定期更新，并在密钥泄露时能够迅速更换。 密钥保护： 密钥应存储在安全的密钥管理服务中，并对密钥的访问进行严格控制，防止未经 授权的使用。 5.1.2.7、第三方系统数据安全 第三方系统集成安全：对于与其他系统（如医院信息管理系统、能源管理系统等）的集成， 应确保数据在各系统间的传输安全，并通过应用程序接口安全策略限制非法访问。 第三方供应商合规性： 与第三方供应商合作时， 应确保其具备符合相关数据安全标准的资质， 并签订数据安全协议，明确各方的责任和义务。 5.1.2.8、数据合规性要求 法规遵从：系统应符合国家和行业的数据安全法律法规要求，如《网络安全法》 、 《个人信息 保护法》等。 隐私保护： 系统应符合医院对患者隐私数据的保护要求， 确保患者信息不会被未经授权的人 员访问或使用。 5.1.2.9、数据安全培训 用户安全意识培训： 对系统的所有用户进行定期的数据安全意识培训， 帮助他们识别潜在的 安全威胁（如钓鱼攻击、恶意软件等） ，并采取适当的防护措施。 安全操作培训： 对于系统管理员和技术人员，提供专业的数据安全操作培训，确保他们了解 如何安全地配置、维护和管理系统中的数据。 5.2、系统访问控制 5.2.1、用户身份认证 唯一用户标识：每个用户必须拥有唯一的用户标识符（如用户名、工号等） ，确保系统能够 准确区分和记录用户的操作行为。 强密码策略： 系统应要求用户设置强密码， 密码长度至少为8 位， 并包含大小写字母、数字和特殊字符的 组合。 密码应定期过期（如每90 天强制更新一次） ，并禁止重复使用过去的密码。 应设置密码输入错误次数限制，连续多次输入错误后应锁定账户（如5 次错误后锁定，需管 理员解锁） 。 多因素认证： 对于系统管理员、 关键岗位人员或其他高权限用户， 系统应支持多因素认证 （如 短信验证码、移动设备认证或硬件令牌） ，以提供额外的身份验证层。 单点登录： 系统可集成单点登录功能， 允许用户使用医院现有的身份验证系统登录， 减少用 户重复登录的操作，提升安全性。 5.2.2、角色与权限管理 基于角色的访问控制： 系统应实行基于角色的访问控制， 确保不同角色的用户拥有相应的权 限。角色可以根据用户的职务、部门、任务分配等进行灵活配置。 典型角色包括但不限于：普通用户、后勤人员、系统管理员、部门主管、医院领导等。 最小权限原则： 每个用户的权限应遵循最小权限原则，即只授予其工作所需的最低权限， 防 止用户访问与其工作无关的敏感数据或功能。 权限分级：系统中的权限应分级管理，关键操作（如系统配置修改、数据删除等）应要求更 高的权限，并进行审批。 动态权限管理： 系统应支持动态权限调整功能， 允许管理员根据岗位需求的变化实时调整用 户权限。 权限继承与撤销：系统应支持权限继承机制，确保当用户角色发生变化时， 其权限能够自动 继承或撤销；同时应支持管理员手动撤销权限。 5.2.3、用户会话管理 会话超时控制： 系统应设置会话超时机制， 在用户长时间未操作时自动注销，防止未授权人 员利用未关闭的会话进行操作。会话超时时间可根据用户角色进行设置（如普通用户30 分 钟，管理员10 分钟） 。 并发会话限制： 系统应限制每个用户的同时在线会话数量， 防止多个设备同时使用同一账户 进行操作，提升系统安全性。 自动注销：当系统检测到异常行为（如在不寻常的时间或地点登录）时，应立即强制注销用 户，并通知系统管理员。 5.2.4、访问日志与审计 访问日志记录：系统应记录所有用户的访问行为，包括但不限于登录、登出、数据查看、数 据修改、系统设置变更等操作。日志内容应包括时间、用户ID、操作类型、操作结果等信 息。 日志安全存储： 所有日志信息应安全存储， 防止被篡改或删除。建议使用加密技术对敏感日 志进行保护，并定期备份日志。 审计功能： 系统应具备完善的审计功能，允许管理员查看和分析日志， 识别潜在的安全威胁 或违规操作行为。审计日志应按规定时间保存（如6 个月或以上） 。 5.2.5、访问控制策略 IP 地址访问控制：系统应支持根据用户的IP 地址进行访问控制，允许或限制特定IP 地址或 IP 地址段的访问，例如只允许医院内部网络访问系统。 时间段访问控制： 系统应支持根据时间进行访问控制， 定义用户或角色在特定时间段内的访 问权限，防止在非工作时间的敏感操作。 设备访问控制： 系统应支持限制用户只能通过特定设备（如医院内网设备、 注册的移动设备 等）进行访问，防止通过未授权设备访问系统。 5.2.6、访问审批与授权流程 审批流程： 系统应具备访问权限申请与审批流程，当用户需要访问特定模块或数据时，必须 发起权限申请，经主管人员或系统管理员审批后才能获得临时或长期权限。 临时访问授权：对于临时任务（如紧急维修、外包服务） ，系统应支持临时授权机制，确保 在任务完成后自动撤销临时权限。 权限调整记录：所有权限变更操作（包括权限授予、权限撤销、角色调整）应记录在案，以 便日后审计。 5.2.7、数据访问控制 数据级别访问控制：对于系统中的敏感数据（如设备运行状态、维修记录等） ，系统应支持 基于用户角色进行数据级别的访问控制，确保只有授权人员能够查看或修改特定数据。 字段级别访问控制： 在某些情况下， 系统应允许管理员对某些用户只开放部分数据字段的访 问权限（如部分用户只能查看设备状态，不能查看具体的维修历史） 。 数据操作限制：系统应对敏感操作（如数据删除、批量导出等）进行严格限制，仅允许高权 限用户执行，并要求操作前进行二次确认。 5.3、用户权限管理 5.3.1、基于角色的权限管理 角色定义： 系统应支持基于角色的访问控制，允许管理员为不同功能岗位定义角色（如后勤 员工、部门主管、系统管理员、外包服务人员等） 。每个角色应预定义与其职责相符的权限 集。 角色权限分配： 每个角色应分配相应的权限， 包括对系统功能模块、 数据和操作的访问权限。 用户的权限应通过其所属角色来继承。 角色继承与层次化： 系统应支持角色的层次化设计， 允许子角色继承父角色的权限， 并对权 限进行细化或扩展。这样可以方便管理不同级别的用户。 5.3.2、最小权限原则 最小权限分配： 系统应遵循最小权限原则， 即每个用户只应被授予其工作所必需的最低权限。 避免用户拥有过多权限，从而减少潜在的安全风险。 权限组合： 系统应支持灵活的权限组合， 允许管理员根据具体需求对用户的权限进行精细化 裁剪，确保用户能够执行其岗位职责但无法访问无关功能或数据。 5.3.3、用户权限的分级管理 权限分级：系统应支持权限的分级管理，不同级别的用户应拥有不同的权限范围。例如，普 通用户只能访问与其直接相关的后勤任务， 而主管和管理员则可以访问全局信息、 进行系统 设置等高级操作。 审批流程：对于涉及高风险或敏感操作的权限，系统应支持权限申请与审批流程。例如，当 用户需要临时访问某些敏感数据时，必须经过主管或系统管理员的审批。 5.3.4、权限动态调整 权限调整机制： 系统应支持权限的动态调整， 允许管理员根据用户的岗位变化或临时需求实 时调整权限。系统应支持权限的即时生效或在下次登录时生效。 权限自动变更： 系统应支持根据特定规则自动调整权限。 例如，当员工离职或岗位发生变化 时，系统应自动撤销或调整其权限。 临时权限分配： 系统应支持临时权限的分配功能， 允许管理员为某些用户分配短期有效的权 限，并设定权限的自动过期时间。 5.3.5、权限审核与管理 权限变更记录：系统应记录所有权限变更操作，包括用户权限的授予、调整和撤销。记录内 容应包括操作时间、操作人、变更前后的权限详情等，以便后续审计。 定期权限审查： 系统应支持定期权限审查机制， 提醒管理员和主管定期检查和确认现有用户 的权限，确保用户的权限与其岗位相符，避免滥用或过期权限的存在。 5.3.6、细粒度权限控制 模块级权限： 系统应支持模块级的权限控制， 允许管理员为不同用户分配访问不同系统模块 的权限。例如，后勤人员可以访问设备管理模块，而管理员可以访问系统配置模块。 功能级权限：系统应支持操作级的权限控制，例如用户可以仅查看某个模块的数据， 但不能 进行修改或删除操作。 数据级权限：系统应支持数据级别的权限控制， 允许管理员根据用户的角色或岗位， 设置对 特定数据的查看、修改、删除等权限。例如，某些用户只能查看其负责的后勤设备的状态， 而不能查看其他区域的设备。 5.3.7、用户组权限管理 用户组管理： 系统应支持用户组的概念， 允许管理员将具有相似权限需求的用户组合成用户 组，然后为用户组分配权限。这样可以简化权限管理，特别是在大规模用户管理的场景中。 组权限继承：用户组内的权限应能够继承到组内所有用户，简化权限分配和管理。组权限的 修改应能够直接影响到组内所有成员。 5.3.8、多层次权限策略 多层次权限控制：系统应支持多层次的权限控制策略。例如， 管理员可以对用户的访问权限 进行进一步限制，设置基于时间、地点或设备的访问限制。 基于时间的权限控制： 系统应支持基于时间的权限控制， 允许管理员设置特定时间段内的权 限。例如，某些权限只能在工作时间内生效。 基于地理位置的权限控制： 系统应支持基于地理位置的权限控制， 确保用户只能在医院内网 或指定地点访问系统，限制在外部网络访问。 5.3.9、权限撤销与注销管理 自动权限撤销：系统应具备自动撤销权限的机制。例如，当用户离职、岗位变动或权限过期 时，系统应自动撤销其相应的权限，防止离职或不再负责该任务的用户继续访问系统。 手动权限撤销：管理员应能够随时手动撤销用户的权限，并确保权限撤销立即生效。 用户注销后的权限管理：当用户账户被注销或停用时，系统应确保所有 5.3.10、权限管理的可视化 权限管理界面： 系统应提供可视化的权限管理界面， 帮助管理员直观地查看和管理不同用户 和角色的权限。 权限冲突提示： 系统应具备权限冲突检测功能， 提醒管理员当用户或角色被分配了相互冲突 的权限时，能够及时调整和修正。 5.3.11、权限管理的自动化 权限自动分配： 系统应支持自动根据用户的岗位、部门或角色来分配默认权限， 减轻管理员 的工作负担。例如，系统根据用户的部门自动为其分配相应的后勤管理模块权限。 权限变更的自动通知：当用户权限发生变更时， 系统应自动通知相关用户和管理员， 确保权 限变更透明化。 5.4、信息加密与传输安全 5.4.1、数据加密要求 静态数据加密： 所有存储在数据库、文件系统、存储设备中的静态数据（即不在传输中的数据）应进行加密 处理。 加密数据应使用强加密算法进行保护， 确保即使存储介质被盗或泄露， 数据也无法被未经授 权的人员读取。 对于特别敏感的数据（如用户身份信息、认证信息等） ，应采用额外的加密措施（如双重加 密） 。 动态数据加密： 动态数据是指在运行时使用或传输中的数据。所有动态数据在传输和处理时必须进行加密， 防止攻击者通过中间人攻击或监听获取数据。 系统应在内存中对敏感数据（如用户认证信息、会话密钥等）进行加密处理，防止通过内存 泄露获取敏感信息。 字段级别加密： 对于存储在数据库中的敏感信息（如用户密码、认证凭证、财务信息等） ，应进行字段级别 加密，确保即使数据库被直接获取，也无法读取敏感字段的内容。 用户密码应使用加密哈希算法进行保护，并且必须带有随机盐值来防止彩虹表攻击。 5.4.2、数据传输加密 系统应采用超文本传输安全协议协议来确保数据在客户端与服务器之间传输时的安全性。 所 有通过互联网传输的数据都必须通过SSL/TLS 加密通道进行加密。 采用TLS1.2 或更高版本的协议，严禁使用过时的SSL 和TLS1.0/1.1 协议，以避免已知的安全 漏洞。 配置强加密的证书来确保通信的完整性和安全性。 内部通信加密： 系统的内部组件之间的通信必须通过加密通道进行， 使用加密协议来确保内部数据传输的安 全性，防止内部网络中出现未加密的敏感信息。 VPN 或专用网络： 对于医院外部的系统访问，建议使用虚拟专用网络（VPN）或其他专用加密的网络通道，以 确保远程连接的安全性。 外部供应商或第三方服务的接入应通过VPN 或其他加密手段，避免未经加密的外部访问。 5.4.3、加密密钥管理 密钥生成： 系统应采用安全随机生成的加密密钥，确保密钥的独特性和不可预测性。 密钥生成应遵循行业标准的加密算法，并使用硬件随机数生成器或其他强随机数生成器。 密钥存储： 密钥应存储在安全的密钥管理系统或硬件安全模块中， 确保密钥不会被未经授权的用户或进 程访问。 密钥不应硬编码在应用程序代码中，也不得以明文形式存储在配置文件或数据库中。 密钥轮换： 系统应支持定期密钥轮换机制，确保密钥不会因长期使用而被破解或泄露。 密钥的轮换应遵循“无感知”原则，即不会影响系统的正常运行和用户体验。 密钥访问控制： 只有授权的系统管理员或服务进程应能够访问加密密钥， 所有对密钥的访问操作应记录日志 并定期审计。 5.4.4、应用程序接口与第三方集成的加密 应用程序接口加密： 所有通过应用程序接口进行的数据交换必须经过加密， 确保数据在第三方系统或外部应用之 间的传输安全。 应用程序接口应使用安全认证机制，并通过加密的通信通道进行传输。 第三方集成加密： 与第三方系统集成时，必须确保所有数据传输均经过加密，防止中间人攻击或数据截取。 对于外部供应商或服务的访问， 系统应使用加密的应用程序接口密钥或身份令牌进行访问控 制，确保传输数据的安全性。 5.4.5、数据完整性与防篡改 哈希算法： 系统应采用安全的哈希算法对存储和传输的数据进行哈希处理，以确保数据的完整性。 对于文件传输或接口通信中的数据， 系统应计算哈希值并进行校验， 确保数据在传输过程中 未被篡改。 数字签名： 对于关键数据（如设备管理记录、后勤审批数据等） ，系统应支持数字签名功能，确保数据 在传输过程中的不可否认性和完整性。 使用非对称加密算法生成数字签名， 签署方可以是系统或特定用户， 接收方可以通过验证签 名来确保数据未被篡改。 5.4.6、数据泄露防护 数据泄露监控： 系统应支持数据泄露防护能， 实时监控可能导致敏感数据泄露的行为， 例如未经授权的数据 导出、数据拷贝、数据篡改等操作。 系统应设置敏感信息（如用户个人信息、设备数据等）的监控策略，防止敏感数据在传输或 存储过程中外泄。 加密数据导出： 当用户或管理员进行数据导出时， 系统应确保导出的数据经过加密处理， 防止导出的敏感数 据被未经授权的人员获取。 数据导出过程中应强制使用加密压缩包或其他安全格式。 5.4.7、安全协议与算法更新 协议和算法升级： 系统应具备灵活的加密协议和算法升级机制， 确保在发现安全漏洞或算法过时时， 能够快速 切换到安全的加密协议和算法。 系统应定期检查并淘汰已不再安全的加密算法，并替换为更安全的算法。 兼容性考虑： 系统在升级加密协议或算法时， 应考虑到与现有系统的兼容性， 确保在升级过程中不会影响 业务的正常运行。 对于旧版本的系统或设备，应逐步淘汰不安全的协议，并为其提供过渡解决方案。 5.5、系统日志与审计 5.5.1、日志记录范围 操作日志： 系统应记录所有关键用户操作， 如登录、 登出、 数据查看、 数据修改、 数据删除、 配置变更、 权限变更等操作。 记录的内容应包括：操作用户、操作时间、操作结果（成功或失败） 、操作类型、目标资源 （如修改的记录或文件）等详细信息。 系统日志： 系统应记录所有系统级事件，如启动、关闭、异常错误、服务状态变化、资源使用情况（如 内存、处理器）等。 记录应包括系统事件的时间戳、 事件类型、 详细错误信息 （如系统异常或崩溃时的堆栈信息） 等。 安全日志： 系统应记录所有与安全相关的事件，如登录失败、多次认证失败、权限拒绝、数据泄露防护 触发、异常的应用程序接口调用等。 针对敏感操作（如修改系统配置、用户权限变更、导出大批量数据等） ，应有专门的安全日 志进行记录。 审计日志： 系统应记录所有审计相关的操作， 如管理员对用户权限的修改、日志查看与导出、系统日志 配置变更等。 审计日志应详细记录谁进行了审计操作、审计时间、 审计内容等， 并确保这些日志无法被修 改或删除。 5.5.2、日志内容要求 标准化日志格式： 系统日志应采用统一的、结构化的格式，以便于后续分析、检索和处理。 日志记录应包含以下基本字段：时间戳、用户ID、操作类型、操作对象、操作结果、IP 地 址、设备信息等。 详细信息： 在记录系统操作时，日志应包含足够的详细信息，以便后续审计和故障排查。例如，数据库 的修改操作应记录修改的具体内容、修改前后的值等。 对于失败的操作（如登录失败、权限拒绝） ，日志应记录失败的原因（如密码错误、权限不 足等） 。 时间同步： 所有日志的时间戳应与系统时钟同步， 确保日志记录的时间一致性。 系统时钟应通过网络时 间协议与标准时间源同步，避免时间漂移。 5.5.3、日志存储与管理 日志存储安全： 日志应存储在安全的存储介质中， 防止未经授权的访问、 篡改或删除。 建议使用加密技术对 日志进行保护。 系统日志存储应具备访问控制机制，只有拥有特定权限的管理员才能访问日志文件。 日志存储期限： 系统应支持配置日志的存储期限， 确保日志能够根据医院的合规要求进行保留。 建议至少保 留6 个月至1 年的日志。 超过存储期限的日志应自动清理或归档处理，确保存储空间的高效利用。 日志备份： 系统应支持定期对日志文件进行备份，确保在日志文件损坏或丢失的情况下能够进行恢复。 5.5.4、日志的索引与检索 日志索引： 系统应能够对日志文件进行索引， 以便快速检索特定事件或操作。 索引字段应包括时间、 用 户ID、操作类型、IP 地址等。 日志检索工具： 系统应提供日志检索工具，允许管理员通过条件筛选（如时间范围、用户ID、操作类型等） 快速查找和分析日志。 支持日志的关键词搜索、模糊匹配、正则表达式等高级检索功能，以便快速定位问题。 5.5.5、实时监控与告警 实时日志监控： 系统应具备实时日志监控功能， 能够实时监控系统的日志信息， 及时发现并响应异常操作或 系统异常。 支持日志的实时流式处理，管理员可以通过控制台或可视化界面实时查看最新的日志记录。 异常日志告警： 系统应提供日志告警功能，当检测到异常操作或安全事件时（如多次登录失败、 未经授权的 访问、系统资源超限等） ，应立即触发告警。 告警应支持多种方式的通知，如系统内提醒、电子邮件、短信或第三方通知工具。 支持告警级别的定义，对不同类型的异常操作设置不同的告警级别（如低、中、高） ，并允 许管理员根据业务需求自定义告警规则。 5.5.6、日志审计功能 操作审计： 系统应提供审计功能， 允许合规或安全管理员对系统操作日志进行定期审查， 确保操作合规 性以及及时发现潜在的安全威胁。 系统应支持审计的定期自动化运行，并生成审计报告，供管理层或安全团队参考。 审计日志不可修改： 系统的审计日志应具备不可篡改性， 确保管理员或其他用户无法修改或删除审计日志。 建议 采用日志加密与数字签名技术来保障审计日志的完整性。 审计日志导出： 系统应支持审计日志的导出功能，允许管理员将日志导出为标准格式用于外部审计或分析。 5.5.7、日志合规性要求 合规性标准： 日志记录应符合相关法律法规和行业标准的合规要求，如 《网络安全法》 《个人信息保护法》 等法律法规要求的日志记录和审计要求。 系统应遵守国际安全标准中规定的日志记录和审计要求， 确保日志的安全性、 完整性和合规 性。 隐私保护： 在记录日志时， 应遵循数据隐私保护要求， 确保不记录敏感个人信息（如患者隐私信息等） ， 或者对敏感信息进行脱敏处理。 对于涉及个人隐私的数据， 应确保日志的访问受到严格的权限控制， 并在合规要求的时间范 围内定期清理。 5.5.8、日志分析与报告 日志分析工具： 系统应提供日志分析工具， 帮助管理员从大量日志数据中提取有价值的信息， 识别潜在的安 全威胁、系统瓶颈或操作异常。 支持日志的图表化展示， 如操作类型的分布、异常操作的趋势等， 帮助管理员快速理解系统 状态。 日志报告生成： 系统应支持自动生成日志报告，报告应包括重要的操作概览、 异常操作统计、安全事件的详 情等。 日志报告应支持定期生成（如每日、每周、每月） ，并可以导出为标准格式供管理层或审计 团队使用。 5.6、备份与恢复机制 5.6.1、备份策略 全量备份： 系统应支持全量备份（完全备份） ，即对系统的所有数据、系统配置、日志和应用程序进行 完整的备份。全量备份应定期执行（如每周一次） ，以确保系统在发生重大故障时可以完全 恢复到备份时的状态。 增量备份： 系统应支持增量备份， 即只备份自上次备份以来发生变化的数据。 增量备份可以有效节省存 储空间和备份时间，并应每日或根据业务需求频繁执行。 差异备份： 系统应支持差异备份， 即只备份自上次全量备份以来发生变化的数据。 差异备份可以在全量 备份与增量备份之间提供灵活性，适合每周或每天执行。 热备份与冷备份： 系统应支持热备份（在线备份） ，即在系统正常运行时进行备份，确保备份过程中服务不中 断。 智慧后勤综合服务平台和智能可视化管理平台对业务连续性要求高， 因此热备份是必要 的。 系统还应支持冷备份（离线备份） ，在系统停机或特定维护窗口期间进行，主要用于系统停 机维护或特殊情况下的数据备份。 5.6.2、备份数据的范围 数据库备份： 系统应定期备份数据库中的所有数据，包括后勤设备信息、任务记录、用户数据、日志数据 等。 对于大型数据库，系统应支持分片备份或并行备份，以加快备份速度并减少系统负载。 文件备份： 系统中存储的文件（如配置文件、日志文件、应用程序文件等）应定期备份，并确保这些文 件在恢复时能够正确还原到原始位置。 配置与系统状态备份： 系统应支持对关键的系统配置（如网络配置、权限配置、服务配置等）进行备份，确保在恢 复系统时能够快速恢复到正常工作状态。 系统状态（如当前任务、会话状态等）也应进行备份，以便在恢复后能够尽量减少中断对业 务的影响。 5.6.3、备份的存储与安全 本地与异地备份： 系统应支持本地备份和异地备份。 本地备份用于快速恢复，异地备份用于灾难恢复。 异地备 份应存储在与主系统物理位置不同的安全地点，防止灾难（如火灾、洪水）导致本地和备份 数据同时丢失。 备份存储加密： 所有备份数据应使用强加密算法进行加密，防止备份数据在传输或存储过程中被窃取或泄 露。 加密密钥应使用安全的密钥管理服务进行管理， 确保只有授权人员和系统进程能够访问备份 密钥。 备份访问控制： 系统应对备份的访问进行严格的权限控制， 防止未经授权的人员访问、 修改或删除备份数据。 备份访问应记录日志，并定期审计。 备份存储冗余： 备份存储应具备冗余和容错能力， 确保即使某个存储节点或介质出现故障， 备份数据仍然是 安全的。建议采用RAID、分布式存储或云存储等具备冗余特性的技术进行备份存储。 5.6.4、备份的时间与频率 备份时间窗口： 系统应支持配置备份的时间窗口， 确保备份任务在业务低峰期执行， 减少对系统性能的影响。 对于关键系统，应支持在非业务时间段（如夜间或周末）进行全量备份和冷备份。 备份频率： 系统应根据数据的重要性和更改频率配置不同的备份频率。建议： 数据库的增量备份每天进行一次。 系统的全量备份每周进行一次。 配置文件和日志文件的备份频率根据具体业务需求确定（如每日或每周） 。 5.6.5、恢复机制 数据恢复流程： 系统应提供简洁、清晰的恢复流程，确保在灾难或数据丢失时能够快速恢复数据。恢复流程 应包括选择备份、执行恢复、验证数据完整性等步骤。 恢复流程应支持部分恢复和全量恢复。 部分恢复允许只恢复特定的数据集或模块， 而全量恢 复则恢复整个系统到某个时间点。 自动恢复： 系统应支持自动恢复机制，在特定故障检测到时，能够自动触发备份恢复，减少人工干预。 自动恢复应具备智能化判断功能，确保不会在错误的情况下触发恢复，导致数据覆盖。 恢复时间目标： 系统应定义恢复时间目标， 即从故障发生到系统恢复正常运行的时间。 应确保备份恢复机制 能够满足业务连续性要求，恢复时间目标应尽量控制在最短时间内（如几小时内） 。 恢复点目标： 系统应定义恢复点目标， 即在恢复后数据能够回滚到的时间点。根据业务需求， 恢复点目标 应尽量缩小，在关键系统中可设置为几分钟或几小时，确保数据丢失量最小。 5.6.6、备份与恢复的监控与日志 备份日志记录： 系统应记录所有备份操作的详细日志，包括备份时间、备份类型（全量/增量） 、备份数据大 小、备份的成功或失败状态等信息。 备份日志应支持导出和审计，管理员可以根据日志排查备份失败的原因并采取相应措施。 恢复日志记录： 每次恢复操作应记录详细日志，包括恢复时间、恢复的数据范围、恢复的成功或失败状态， 以及恢复操作的执行人。 恢复日志应保存足够长的时间，并支持审计，以确保数据恢复操作符合业务和合规要求。 监控与告警： 系统应实时监控备份和恢复的状态， 尤其是备份失败、 恢复失败、 超出时间限制等异常情况。 备份失败或恢复失败时，系统应及时发送告警通知管理员，告警方式可包括邮件、短信、系 统通知或第三方工具。 5.6.7、备份与恢复的测试 定期恢复测试： 系统应定期进行备份与恢复的演练和测试，确保备份数据在实际灾难发生时能够成功恢复。 建议每季度进行一次备份恢复测试。 恢复测试应覆盖全量恢复和部分恢复场景， 确保所有类型的备份数据在恢复过程中都能无误 还原。 恢复测试报告： 每次恢复测试应生成详细报告，包括测试时间、测试恢复的数据范围、恢复成功与否、恢复 用时等信息。报告应供管理层和审计人员参考，以验证备份恢复机制的有效性。 5.6.8、灾难恢复与业务连续性 灾难恢复计划： 系统应制定详细的灾难恢复计划， 包括灾难发生时的应急处理流程、 备份恢复流程和应急响 应人员的职责。 灾难恢复计划应涵盖各种可能的系统故障、硬件故障、数据损坏、网络中断等场景，并针对 每个场景制定相应的恢复措施。 异地灾备与业务连续性： 系统应支持异地灾备，确保在主站点发生灾难（如火灾、地震等）时，能够从异地备份站点 快速恢复系统运行，保障业务连续性。 系统应评估业务连续性的要求，确保关键业务模块可以在灾备环境下无缝运行或快速恢复。 5.7、安全合规要求 平台建设符合国家、 地方对信息系统安全保密标准的要求， 具备严格、 细致的访问权限控制； 保证数据的机密性、完整性、可用性，系统须提供良好的密级管理，实现在数据存储和数据 传递过程中的安全防护， 数据具有多种备份方式，保障数据的安全。平台整体要符合国家等 级保护2.0 三级的要求，有具体安全保障设备设施和措施。在等保测评期间中标供应商须按 照采购人网络安全要求， 配合进行等级保护定级备案测评和整改的工作， 整个定级备案测评 和整改工作发生的费用由中标供应商承担。 技术方案须按照国家政策推行信息技术应用创新、 密码应用技术， 建设内容应支持信息技术 应用创新， 非信息技术应用创新产品能按要求按时完成适配， 密码算法要符合国密技术要求。 5.7.1、法律法规遵从 网络安全法： 系统开发和运营应严格遵守《中华人民共和国网络安全法》 ，确保网络安全、数据安全、个 人信息保护等方面符合国家法律规定。 系统应具备保障网络安全的技术措施和管理措施，防止数据泄露、 篡改、丢失以及网络攻击 等行为的发生。 个人信息保护法： 系统应遵守《中华人民共和国个人信息保护法》的规定，确保对用户个人信息的合法收集、 存储、使用、传输和共享。 系统应确保用户有权知晓其个人信息的处理情况，并支持用户对个人信息的查询、更正、 删 除等操作。 系统的设计应遵循最小化收集原则， 仅收集业务所需的最少信息， 并确保数据处理行为符合 用户授权范围。 电子病历管理制度： 系统中涉及到患者信息的模块 （如后勤设备可能关联的医疗设备数据） 应遵从国家卫生健康 委员会发布的《电子病历管理制度》相关规定，确保数据的安全性和隐私性。 系统中保存的医疗数据应具备足够的访问控制和加密保护， 确保医护人员和授权人员才能访 问相关信息。 医疗器械网络安全注册技术审查指导原则： 如果系统涉及到与医疗设备或器械的互联互通， 系统应遵守国家药品监督管理局发布的 《医 疗器械网络安全注册技术审查指导原则》 ，确保设备互联中的数据传输安全，并采取必要的 加密措施。 5.7.2、等级保护2.0 要求 系统等级评估： 系统应根据《网络安全等级保护制度》 （等保2.0）进行安全等级评估，并根据系统的重要性 和敏感性确定安全等级。 对于智慧后勤综合服务平台和智能可视化管理平台， 系统通常会涉 及到二级保护。 等保2.0 的基本要求包括：物理安全、网络安全、主机安全、应用安全、数据安全和安全管 理等六大方面，系统应在这些方面落实技术和管理措施。 物理安全： （依托医院现有物理环境） 系统应部署在符合等保2.0 要求的物理环境中，确保服务器和关键设备的物理安全。机房应 具备防火、防水、防盗、防电磁干扰等措施。 系统应支持对物理访问的监控和记录，确保只有授权人员才能接触服务器和存储设备。 网络安全： （依托医院现有网络环境） 系统应具备防火墙、入侵检测和防御系统（IDS/IPS） 、网络隔离等网络安全措施，防止外部 攻击和网络入侵。 系统应使用虚拟专用网络 （VPN） 或专网传输来保证远程访问的安全性， 并确保内外网隔离。 支持对网络流量的监控与分析，及时发现和阻止恶意流量。 主机安全： 系统应对所有服务器进行安全加固，定期安装安全补丁和漏洞修复，确保操作系统、 应用程 序和中间件的安全性。 系统应支持主机的访问控制、权限管理和日志记录，防止未经授权的访问和操作。 系统应具备主机的病毒防护和恶意软件检测功能，及时发现并清理可能的安全威胁。 应用安全： 系统应采用安全编码规范，防止常见的安全漏洞。 系统应具备严格的身份认证机制，重要操作应进行多因素认证，确保用户身份的合法性。 系统应支持会话管理与超时处理，防止会话被劫持或滥用。 数据安全： 系统应对所有静态数据和传输中的数据进行加密， 确保数据在存储和传输过程中不被窃取或 篡改。 系统应具备数据备份机制，结合等保要求， 备份数据应异地存储， 并确保在灾难发生时能够 迅速恢复。 系统应具备数据脱敏功能，防止在数据处理、测试或展示中出现敏感信息泄露。 安全管理： 系统应具备完善的安全管理制度，明确责任分工，确保安全事件能够快速响应和处理。 系统应定期进行安全培训和应急演练，确保有关人员具备应对网络安全事件的能力。 系统应具备安全事件的应急响应机制， 能够在安全事件发生时及时采取措施， 防止事态扩大， 并在事后进行安全事件审计和分析。 5.7.3、数据保护与隐私要求 敏感数据的保护： 系统应对敏感数据（如用户身份信息、认证信息、医疗数据等）进行分类管理，确保敏感数 据具备更高的保护级别。 系统应支持数据最小化原则， 即仅处理业务所需的最少数据， 并确保敏感数据不会暴露给无 关人员。 数据脱敏： 系统应对展示或传输中的敏感数据进行脱敏处理， 确保在展示给非授权用户时， 数据的敏感 部分被掩盖或隐藏（如身份证号中间几位被隐藏） 。 数据脱敏应覆盖数据库查询结果、 日志记录、调试信息等， 确保敏感信息不在非必要场景中 泄露。 数据传输安全： 系统应对所有跨网络传输的数据进行加密保护， 确保数据在网络传输过程中不会被窃听或篡 改。 系统应采用安全的传输协议来保护数据传输的安全性， 防止 “中间人攻击” 等常见网络攻击。 5.7.4 安全审计与日志管理 日志记录与审计： 系统应符合等保2.0 的日志审计要求， 记录所有重要操作的日志， 包括用户登录、 权限变更、 数据访问、数据导出、系统配置变更等。 日志记录应具备不可篡改性，并确保重要日志的完整性和可追溯性。 系统应支持日志的定期审计和分析，及时发现潜在的安全风险和异常行为。 审计报告： 系统应定期生成安全合规报告，报告内容应包括安全事件、系统日志、用户操作记录等，并 满足网络安全等级保护的审计要求。 审计报告应符合《网络安全法》 《等保2.0》以及医院内部安全审计的要求，并供管理层和监 管机构审查。 5.7.4、安全事件应急响应 应急响应预案： 系统应建立详细的安全事件应急响应预案， 明确应急响应的流程和分工， 确保在发生安全事 件时能够及时有效地进行处理。 应急预案应涵盖多种安全事件场景，如数据泄露、恶意攻击、网络入侵、系统漏洞利用等， 并明确每种场景下的处理步骤。 应急演练： 系统应定期进行安全事件的应急演练， 确保系统管理员和相关人员具备应急响应能力。 建议 每年至少进行一次全面的应急演练。 安全事件报告： 系统应具备安全事件的实时监控和报告机制， 确保在发生安全事件时能够及时通知相关负责 人，并按照等保要求向监管机构报告（如重大数据泄露事件） 。 系统应生成详细的安全事件报告，描述事件的发生时间、影响范围、处理措施和恢复情况， 并保留报告记录以备审计。 5.7.5、第三方审计与认证 等保测评： 系统应通过第三方的网络安全等级保护测评，并定期进行复测，以确保系统持续符合等保 2.0 的相关要求。 通过测评的系统应获得相应的等保认证，认证结果应报告给医院管理层和相关监管部门。 六、性能要求 6.1、系统响应速度 6.1.1、页面加载时间 首次加载时间： 系统的登录页面和主要功能模块的页面应在3 秒内完成首次加载， 确保用户可以快速进入系 统。 对于包含大量数据或复杂功能的页面， 首次加载时间不得超过5 秒。 若页面加载需要较长时 间，应使用加载动画或进度条提示用户系统正在处理。 后续页面加载时间： 对于已经访问过的页面，后续加载应在1-2 秒内完成。系统应通过缓存机制加速常用页面的 加载速度。 6.1.2、数据查询响应时间 简单查询： 对于简单的数据查询（如查询单条记录或少量数据） ，系统的响应时间应控制在1 秒以内， 确保用户可以快速获取结果。 复杂查询： 对于复杂查询（如多条件筛选、大量数据的检索） ，系统的响应时间应控制在3 秒以内。对 于数据量非常大的查询请求，响应时间不应超过5 秒。 系统应提供分页显示功能，对于大数据量的查询结果，支持分批加载， 避免一次性返回大量 数据导致响应时间过长。 6.1.3、数据提交与保存 数据提交与保存响应时间： 普通的数据提交与保存操作（如保存表单、提交任务等） ，系统的响应时间应控制在1 秒以 内，确保用户的操作能够立即得到反馈。 对于较大数据量的提交操作（如批量数据导入、文件上传等） ，响应时间不应超过5 秒。如 果操作需要较长时间，系统应提供进度条或提示信息，告知用户处理的进展。 6.1.4、文件上传与下载 文件上传速度： 系统应根据网络带宽和文件大小，确保文件上传的响应速度。对于小文件（<=10MB） ，上 传时间应在3 秒以内完成。 大文件（>10MB）的上传时间应根据文件大小和网络状况合理控制，对于超过100MB 的 文件，上传时间应在30 秒内完成，并提供进度条或上传提示。 文件下载速度： 系统应确保在稳定的网络环境下， 文件下载响应时间不超过2 秒， 并根据文件大小提供下载 进度提示。 对于大文件下载，系统应支持断点续传功能，确保下载中断后可以继续进行。 6.1.5、并发访问响应能力 并发用户访问响应时间： 系统应能够在100 个并发用户进行访问的场景中保持良好的响应速度， 确保所有用户的响应 时间不超过3 秒。 在500 个并发用户访问的高峰场景下，核心操作（如登录、数据查询、数据提交等）的响应 时间不应超过5 秒。 6.1.6、报表生成与导出 报表生成时间： 系统应能够在3 秒内生成简单报表（如单个表格或少量数据的报表） 。 对于包含大量数据的复杂报表，生成时间应控制在10 秒以内。过长的报表生成过程应提供 进度条或提示用户等待。 报表导出时间： 报表导出（如导出为Excel、PDF 格式等）的响应时间应控制在5 秒以内。对于大型报表导 出，系统应根据文件大小合理控制导出时间，但不应超过10 秒。 6.1.7、异常处理响应时间 错误提示与恢复操作： 当系统发生错误或异常时， 系统应在1 秒内给出错误提示或反馈， 避免用户在长时间等待后 才发现操作失败。 系统应支持快速恢复操作， 如自动重试或提示用户手动重试， 并确保恢复操作的响应时间不 超过3 秒。 6.1.8、系统登录与注销 登录响应时间： 用户登录系统时，系统的响应时间应控制在2 秒以内，确保用户能够快速进入系统。 登录过程中应支持用户身份验证和权限加载， 确保登录后用户能够立即访问其有权限的功能 模块。 注销响应时间： 用户注销系统时， 系统的响应时间应控制在1 秒以内， 确保用户能够快速退出并返回登录页 面。 6.1.9、实时数据刷新 实时数据刷新间隔： 对于需要实时更新的数据（如设备状态、任务进度等） ，系统应支持每2-5 秒刷新一次，确 保数据的及时性和准确性。 6.1.10、应用程序接口响应时间 应用程序接口调用响应时间： 系统提供的应用程序接口的响应时间应控制在1 秒以内， 确保外部系统或应用程序能够快速 获取数据或提交请求。 对于复杂的应用程序接口请求（如涉及多表查询或复杂运算） ，响应时间不应超过3 秒。 6.1.11、负载均衡与性能优化 负载均衡要求： 系统应具备负载均衡机制，确保在高并发或大流量访问时，能够均衡分配资源， 避免单个服 务器或节点过载，从而影响系统的整体响应速度。 性能优化要求： 系统应支持缓存机制、数据库索引优化、异步处理等性能优化手段，确保在高负载或复杂操 作下，依然能够保证响应速度符合要求。 6.2、并发用户数 6.2.1、并发用户数定义 并发用户数： 并发用户数是指在同一时间内， 系统能够同时处理的活跃用户数量。 活跃用户是指同时在线 且执行操作（如登录、数据查询、提交任务等）的用户，而非仅仅保持在线状态的用户。 并发峰值用户数： 并发峰值用户数是指系统能够承受的最大并发用户数量。 在系统设计时， 应考虑业务高峰期 的并发负载，确保系统在峰值状态下仍然能够正常、高效地运行。 6.2.2、目标并发用户数 普通时段并发用户数： 系统应在普通时段（非高峰期）支持200-500 个并发用户，同时保证系统的响应速度不超过 规定的时间（如数据查询在1-2 秒内返回结果，表单提交在1 秒内完成） 。 高峰时段并发用户数： 在业务高峰期（如交接班、设备维护集中时段等） ，系统应支持至少1000 个并发用户，并确 保系统在高并发情况下依然保持稳定运行，关键功能（如登录、数据查询、提交等）的响应 时间不超过3-5 秒。 系统应具备自动扩展能力， 在并发用户接近峰值时能自动增加资源， 确保高峰时段的用户体 验不受影响。 6.2.3、各模块承受的并发量 登录模块： 登录模块应能够在每分钟处理至少200 次登录请求， 在高峰时段登录请求的响应时间不应超 过3 秒。同时，系统应支持并发用户的登录认证与权限加载，确保用户能够快速进入系统。 数据查询模块： 数据查询模块应能够在每秒处理至少100 个并发查询请求，并确保响应时间符合系统要求 （如简单查询响应时间不超过1-2 秒，复杂查询不超过3-5 秒） 。 任务处理模块： 系统任务（如设备任务分配、任务状态更新等）应支持至少100 个并发任务同时处理，并确 保任务数据的提交和反馈不出现明显延迟。每个任务的处理时间应控制在1-3 秒内。 文件上传/下载模块： 文件上传/下载模块应支持至少50 个并发文件操作， 确保上传和下载的响应时间不超过规定 时间（如小文件上传在3 秒内完成，大文件上传在10 秒内完成，并支持断点续传） 。 6.2.4、并发用户数与系统性能 处理器与内存使用率： 在并发用户数达到峰值时，系统的处理器使用率应保持在合理范围内，通常不应超过80%， 以避免由于资源耗尽导致系统性能下降。 系统的内存使用率应保持在70%以下， 确保系统在处理大量并发请求时依然有足够的内存资 源应对突发情况。 数据库并发处理能力： 系统的数据库应支持高并发下的读写操作， 特别是在高峰时段， 数据库读写的响应时间应控 制在3 秒以内。数据库应具备优化机制（如索引优化、查询缓存等） ，以提升并发处理能力。 数据库应支持读写分离或分布式数据库架构， 确保在高并发情况下系统性能不受数据库瓶颈 的影响。 6.2.5、并发用户数下的负载均衡 负载均衡机制： 系统应具备负载均衡机制， 通过将用户请求分配到多个服务器或节点上， 以确保各服务器的 负载均衡， 防止单个服务器超载。 负载均衡应确保在高并发时段， 系统各模块的响应时间不 会明显增加。 负载均衡应支持动态扩展，能够根据并发用户数量的变化，自动增加或减少服务器， 确保系 统资源的高效利用。 6.2.6、并发用户数与系统扩展性 水平扩展能力： 系统应具备良好的水平扩展能力，即能够通过增加服务器节点来提升系统的并发处理能力。 系统架构应支持容器化、 微服务架构或分布式架构， 确保在业务增长时能够通过扩展轻松应 对不断增加的并发用户数。 垂直扩展能力： 系统应具备一定的垂直扩展能力， 即通过提升单台服务器的硬件配置（如增加处理器、内存 等资源） ，能够提高单一节点的并发处理能力。 6.2.7、并发用户数与异常处理 过载保护机制： 系统应具备过载保护机制， 在并发用户数超过系统最大承受能力时， 系统能够自动采取限制 措施（如限流、排队、拒绝部分非关键请求等） ，避免系统崩溃或服务不可用。 过载保护应具备告警机制， 当系统接近或超过并发用户上限时， 系统应及时通知运维人员采 取进一步措施（如增加服务器、优化资源配置等） 。 降级机制： 在极端情况下（如并发用户数远超预期） ，系统应具备降级策略，即暂时关闭部分非关键功 能，确保核心功能模块（如登录、数据查询、任务处理等）能够正常运行。降级措施应自动 触发，并在并发压力缓解后自动恢复系统所有功能。 6.2.8、并发用户数的测试与验证 压力测试： 系统上线前应进行并发压力测试， 模拟不同场景下的并发用户访问情况， 确保系统能够在规 定的并发用户数下保持稳定运行。压力测试应覆盖登录、数据查询、任务处理、文件上传/ 下载等核心功能。 压力测试的结果应提供详细报告， 报告应包括系统在不同并发用户数下的响应时间、 系统资 源使用情况（如处理器、内存、网络带宽等） 、数据库性能表现等。 长期稳定性测试： 系统应进行长期并发稳定性测试， 模拟系统在长时间高并发运行下的表现， 确保系统不会因 资源泄漏、内存不足等问题导致性能衰退或崩溃。测试时间建议不少于72 小时。 6.2.9、并发用户数扩展规划 未来扩展预留： 系统应支持未来扩展的需求， 确保在业务增长时能够通过增加服务器或优化架构支持更高的 并发用户数。系统设计时应预留足够的扩展空间，建议至少支持2000 个并发用户的未来扩 展能力。 弹性扩展机制： 系统应支持弹性扩展，即在并发用户数临时增加时， 系统能够自动或手动增加资源（如申请 更多的云服务器、自动扩展微服务节点等） ，确保系统在短时间内能够应对突发的高并发需 求。 6.3、数据处理能力 6.3.1、数据处理容量 日均数据处理量： 系统应具备处理大量数据的能力， 能够每日处理至少100 万条数据记录， 并保持稳定的性能 表现，不会因数据量持续增加而影响系统的响应速度。 系统应能够根据业务需求支持数据处理量的渐进式增长， 确保每天的新增数据处理能力至少 有20%的冗余。 数据存储容量： 系统应支持大规模的数据存储， 至少能够存储5 年以上的业务数据， 且应具备灵活的扩展能 力，支持未来的数据增长。 数据存储应支持自动清理或归档机制， 确保历史数据不会对当前系统性能造成负面影响， 定 期将不常用的数据归档至异地存储或冷存储。 单次批量数据处理能力： 系统应支持每次处理至少100 万条数据记录的能力，特别是在业务高峰期或批量数据导入 时，系统应能够在3 分钟内完成数据处理，不影响其他功能模块的正常运作。 6.3.2、实时数据处理能力 实时数据处理性能： 系统应能够支持实时数据处理，例如来自设备传感器的监控数据、任务状态的实时更新等， 确保实时数据处理延迟不超过2 秒。 系统应具备弹性处理能力，确保在突发性数据量增加时， 仍能保持实时数据处理的性能， 延 迟不超过5 秒。 高频数据更新响应： 对于高频率的数据更新（如设备状态更新、任务进度更新等） ，系统应确保能够每秒处理至 少1000 次更新请求，并在高负载情况下保持不超过1 秒的处理延迟。 6.3.3、数据查询与检索性能 简单查询： 对于简单查询（如按唯一键查询单条记录） ，系统应确保在1 秒内返回结果，即使在高并发 情况下，响应时间也不应超过2 秒。 复杂查询： 对于涉及多条件、多表关联的复杂查询， 系统应确保在3 秒内返回结果。对于数据量非常庞 大的查询， 响应时间不应超过5 秒， 并支持分页或分批返回数据， 避免一次性加载过多数据 导致系统性能下降。 全文检索： 系统应支持全文检索功能，特别是针对大量文本数据（如任务描述、设备日志等） ，应能够 在5 秒内完成全文检索并返回结果。 系统应具备全文检索的优化机制， 如索引优化、 缓存机 制等。 6.3.4、数据导入与导出能力 批量数据导入： 系统应支持从外部数据源批量导入数据的功能，能够在10 分钟内导入至少100 万条数据记 录，并确保在导入过程中不影响其他模块的运行。 数据导入应支持断点续传机制，确保在网络中断或系统故障时，能够继续进行导入操作， 而 不会导致数据丢失。 批量数据导出： 系统应支持批量导出数据的功能，能够在5 分钟内导出至少50 万条数据记录，导出格式应 支持常见的格式。 在导出大数据量时， 系统应提供进度提示， 并支持后台导出， 避免长时间的导出操作影响前 端用户的正常使用。 6.3.5、报表生成与处理能力 报表生成性能： 系统应能够快速生成各类业务报表，简单报表（如单表报表）应在2 秒内完成生成，复杂报 表（如多表关联、统计分析报表）应在10 秒内完成生成。 系统应支持定时生成报表功能， 能够根据设定的时间点或频率自动生成并推送报表， 确保用 户能够及时获取业务数据。 报表处理能力： 系统应支持对报表数据进行在线处理和分析，能够对报表中的数据进行筛选、排序、汇总、 分组等操作，并在3 秒内完成操作的响应。 对于涉及大量数据的动态报表， 系统应支持后台异步处理， 确保用户在前台操作时不会因数 据过多而导致系统卡顿或响应延迟。 6.3.6、数据压缩与传输优化 数据压缩： 系统应支持对大数据量进行压缩处理， 尤其是在传输大批量数据或存储大数据量时， 数据压 缩应提高效率，压缩率达到30%-50%，并且数据压缩和解压缩的时间总计不应超过3 秒。 压缩算法应确保对性能的影响最小， 并兼顾传输速度与数据完整性， 避免因压缩导致的数据 丢失或错误。 传输优化： 系统应支持大数据量的高效传输， 特别是在网络带宽有限的情况下， 系统应通过优化传输协 议和传输方式，确保大数据量传输的效率提升，传输延迟不超过5 秒。 6.3.7、数据一致性保证 事务处理性能： 系统必须支持事务处理， 确保在数据处理过程中数据的一致性和完整性。 在大量并发的数据 操作下（如同时更新多条记录） ，系统应确保事务执行的可靠性，事务提交和回滚的处理时 间不超过2 秒。 系统应支持分布式事务处理， 确保跨多个数据库或系统的数据一致性， 特别是在涉及后台批 量处理和异步任务时，系统应具备超时控制和重试机制，避免数据不一致的情况。 数据同步能力： 系统应支持多数据源之间的数据同步， 确保不同子系统之间的数据能够实时同步， 数据同步 的延迟不超过5 秒。 系统应具备监控和校验机制， 确保数据同步的准确性， 避免因同步失败或延迟导致的数据不 一致问题。 6.3.8、数据处理的扩展性 水平扩展： 系统应具备良好的水平扩展性， 能够通过增加服务器节点来提升数据处理能力， 特别是在数 据量和并发用户数增加时，系统应能够通过水平扩展来提升整体性能。 系统架构应支持分布式数据处理， 能够通过分布式计算框架来处理大规模数据， 确保在数据 量激增时能够通过扩展节点来提升处理能力。 垂直扩展： 系统应支持垂直扩展，能够通过增加单台服务器的硬件资源（如处理器、内存等）来提升数 据处理性能。 在数据处理达到瓶颈时， 系统应具备垂直扩展的能力， 以应对突发的性能需求。 6.3.9、数据处理的容错与恢复能力 容错处理： 系统应具备容错机制，在数据处理出现异常或失败时，系统应能够自动恢复数据处理流程， 并重试未成功的操作。 容错处理的响应时间应控制在2 秒内， 确保系统能够在短时间内恢复 正常。 系统应具备错误日志记录功能， 详细记录数据处理过程中出现的错误， 并提供错误的诊断信 息，便于后续分析与处理。 数据恢复能力： 系统应具备数据备份与恢复机制， 在发生数据处理失败或异常时， 能够快速恢复数据，确保 数据完整性不受影响。 数据恢复的响应时间应控制在5 分钟以内， 确保重要数据能够及时恢 复。 系统应支持自动备份功能，能够定期对重要数据进行备份，并支持增量备份，确保数据备份 的效率与安全性。 6.4、系统可用性要求 6.4.1、系统可用性定义 系统可用性： 系统可用性是指系统在规定时间内可正常运行并提供服务的能力。 服务不可用时间： 服务不可用时间指的是系统因故障、 维护或升级而无法正常提供服务的时间。 可用性要求应 尽量减少这种不可用时间，并确保其对业务的影响最小。 6.4.2、系统可用性目标 全年可用性目标： 系统的全年可用性应保证在99.9%以上，即全年系统不可用时间不应超过8.76 小时。 核心功能可用性： 对于系统的核心功能（如设备监控、任务管理、数据查看等） ，可用性要求应更高，至少达 到99.95%，即全年不可用时间不超过4.38 小时。 6.4.3、系统维护与升级的可用性要求 计划内维护： 系统应支持定期维护和升级， 但计划内的维护时间应尽量安排在业务低峰期， 并提前通知用 户。计划内维护时间每年不应超过24 小时，且每次维护时间不应超过2 小时。 在维护过程中，系统应尽量保持部分关键功能的可用性（如设备监控、任务处理等） ，并通 过冗余机制或双活部署，确保系统核心服务的不中断性。 在线升级机制： 系统应支持在线升级， 即在不影响系统正常运行的情况下进行版本升级或功能更新。 对于重 要的系统更新，系统应支持热部署，以避免因升级而导致的服务中断。 6.4.4、故障恢复与应急响应 故障恢复时间目标： 当系统发生故障时，系统的恢复时间目标应不超过30 分钟，即从故障发生到系统恢复正常 运行的时间应控制在30 分钟以内。对于关键业务功能（如任务管理、设备监控等） ，故障恢 复时间目标应控制在15 分钟以内。 故障恢复点目标： 系统的恢复点目标应控制在5 分钟以内， 即在系统故障恢复后， 丢失的数据不应超过5 分钟 之内生成的数据。系统应通过定期备份和灾难恢复机制，确保数据丢失的范围最小化。 应急响应机制： 系统应具备完善的应急响应机制， 在发生重大故障或事故时， 能够迅速启动应急预案， 包括： 系统自动告警、故障定位与排查、快速切换到备用系统或冗余节点等。 应急响应流程应确保故障发生后， 技术团队在5 分钟内收到告警并开始处理， 确保尽快恢复 系统正常运行。 6.4.5、冗余与高可用架构 冗余架构设计： 系统应具备冗余架构，通过多节点部署、主备切换、容灾备份等方式，确保服务在单点故障 发生时不受影响。关键服务（如数据库、任务调度、网络通信等）应采用双活部署或多活部 署，确保系统的高可用性。 负载均衡机制： 系统应支持负载均衡机制， 通过将用户请求分配到多个节点或服务器上， 确保在出现单个节 点故障时， 其他节点能够自动接管， 避免系统中断。 负载均衡机制应具备自动故障转移功能， 确保故障节点恢复后能够正常接入负载池。 灾难恢复机制： 系统应具备完善的灾难恢复机制，包括异地备份、数据同步、快速恢复等手段。在因灾难导 致的系统宕机情况下，系统应能够在60 分钟内切换到备用数据中心或恢复备份数据，确保 业务的连续性。 灾难恢复演练应定期进行，确保系统能够在紧急情况下快速响应和恢复。 6.4.6、数据备份与恢复 数据备份频率： 系统应支持定时自动备份，关键数据（如设备状态、任务记录、用户操作日志等）应至少每 5 分钟备份一次，其他非关键数据（如报表数据、历史任务记录等）可每24 小时备份一次。 系统应支持异地备份，确保在本地服务器发生故障时，能够从异地备份中快速恢复数据。 数据恢复能力： 系统应具备快速数据恢复能力，在数据丢失或损坏时，能够在30 分钟内恢复关键数据，确 保业务的连续性。 数据恢复应支持选择性恢复， 用户可以根据需求恢复特定时间段或模块的 数据。 6.4.7、系统监控与告警 实时监控： 系统应具备实时监控机制，能够监控系统的运行状态、资源利用率（如处理器、内存、网络 带宽等） 、数据库性能、应用程序性能等。监控数据应能够实时展示在可视化控制台上，供 运维人员查看。 系统应支持设置监控阈值，当系统的资源使用接近或超出阈值时，能够及时触发告警。 自动告警机制： 系统应具备自动告警机制，在出现异常（如服务中断、资源耗尽、性能下降等）时，能够自 动通过邮件、短信、电话等方式通知运维人员，确保能够及时处理问题。 告警机制应具备多级告警功能， 严重故障应优先通知， 确保技术支持团队能够在5 分钟内响 应并处理。 6.4.8、系统升级与扩展的可用性保障 无缝扩展： 系统应支持水平扩展， 即通过增加服务器节点或计算资源来提升系统的性能和可用性， 确保 在业务量增长时， 系统依然能够保持高可用性。 扩展应支持热添加， 不影响系统的正常运行。 在线升级： 系统应支持在线升级和热更新，确保在功能扩展或版本更新时，不影响系统的可用性。特别 是关键业务系统，升级过程中应保持不间断服务，或将影响降到最低。 6.4.9、用户体验与可用性保障 用户无感知维护： 系统的维护应尽量做到用户无感知， 即在进行系统维护或小范围故障处理时， 用户不应感受 到系统的中断或异常。系统应通过分布式部署、 冗余机制等手段， 在后台进行维护和修复的 同时，前台服务不受影响。 用户操作反馈： 系统应确保用户操作的实时性和响应速度， 当系统因临时性故障或维护导致响应变慢时， 系 统应给出友好的提示（如加载进度、维护通知等） ，避免用户误以为操作失败。 6.4.10、可用性测试与验证 定期可用性测试： 系统应进行定期的可用性测试，包括压力测试、故障恢复测试、灾难恢复演练等，以确保系 统在不同情况下都能维持高可用性。 测试应包括以下内容： 系统响应时间和性能表现 系统在高并发和高负载下的稳定性 系统在单点故障和服务中断时的自动恢复能力 灾难恢复机制的有效性 可用性报告： 系统应定期生成可用性报告，包括系统运行时间、故障时长、故障原因、恢复时间、监控数 据等。 6.5、系统容错与灾备能力 6.5.1、系统容错能力 6.5.1.1、容错机制定义 容错机制： 容错机制是指系统在出现硬件或软件故障时， 能够自动处理或绕过故障， 继续提供服务而不 影响系统整体的可用性和正常运行。容错机制应确保系统的关键业务模块（如任务管理、 设 备监控、数据处理等）能够在故障发生时正常运行。 6.5.1.2、单点故障防护 单点故障保护： 系统应避免单点故障， 即任何单一组件或模块的故障不应导致整个系统的中断。 关键模块应 具备冗余设计，确保即使某一模块出现问题，其他模块或冗余节点能够自动接管。 系统应具备自动故障切换机制， 确保在单点故障发生时， 系统能够自动切换到备用系统或冗 余节点，避免业务中断。 6.5.1.3、自动检测与故障处理 故障自动检测： 系统应具备自动故障检测机制，能够实时监测各个模块的运行状态，一旦发现异常（如服务 不可用、性能下降、资源耗尽等） ，系统应自动触发相应的处理措施。 自动检测应具备多种检测手段，包括健康检查、心跳检测、性能监视等。 自动故障恢复： 系统应具备自动故障恢复能力，即在发生故障时，系统能够自动执行恢复操作， 如重新启动 服务、切换到备用节点、重新分配资源等，确保业务不中断或将中断时间降至最低。 自动恢复的响应时间应控制在1 分钟以内，确保高效处理故障。 6.5.1.4、数据层容错 数据库容错： 系统数据库应具备高可用性架构，如主从复制、读写分离、分布式数据库等，确保数据库在 出现故障时能够自动切换到备用节点或从库，保证数据读取和写入正常进行。 数据库应支持事务处理和日志恢复， 在数据库写入操作失败或发生故障时， 能够通过事务日 志进行自动恢复，确保数据的一致性和完整性。 6.5.1.5、应用层容错 应用程序容错： 应用程序应具备错误处理机制，如异常捕获、错误重试、降级处理等，确保当某一功能模块 出现错误时，不影响整体系统的稳定性。 在某些功能不可用时，系统应具备功能降级机制，暂时关闭或简化部分非核心功能， 确保核 心业务功能（如任务管理、设备监控等）继续正常运行。 6.5.2、灾难恢复能力 6.5.2.1、灾难恢复机制定义 灾难恢复： 灾难恢复是指在发生重大故障或灾难（如硬件损坏、自然灾害、网络中断等）时，系统能够 在尽可能短的时间内恢复运行的能力。 灾备机制应确保业务的连续性， 避免因灾难导致长时 间的系统中断或数据丢失。 6.5.2.2、灾难恢复目标设定 恢复时间目标： 系统的恢复时间目标应控制在60 分钟以内，即在发生灾难后，系统应能够在1 小时内恢复 基本的业务功能。对于关键业务系统，恢复时间目标应控制在30 分钟以内。 恢复点目标： 系统的恢复点目标应控制在5 分钟以内， 即灾难发生时， 系统应能够恢复到最近5 分钟内的 状态， 数据丢失量不应超过5 分钟内生成的数据。 对于关键业务数据， 恢复点目标应尽可能 接近实时。 6.5.2.3、灾备中心与异地备份 异地灾备中心： 系统应建立异地灾备中心，确保在主数据中心发生灾难时（如网络中断、火灾、水灾等） ， 能够快速切换到异地灾备中心， 保障业务的连续性。 异地灾备中心的地理位置应与主数据中 心保持足够距离，以避免受同一灾难影响。 异地数据同步： 系统应支持异地数据同步， 确保主数据中心的数据能够实时或定期复制到异地灾备中心。 数 据同步应保证一致性，避免因灾难导致的数据不一致或丢失。 数据同步频率应根据业务需求设定，关键数据（如任务状态、设备监控数据）应实现实时同 步，非关键数据（如历史日志、报表数据）可定期同步。 6.5.2.4、数据备份与恢复 数据备份策略： 系统应具备详细的数据备份策略， 包括全量备份和增量备份两种机制。 全量备份应每周或每 月进行一次，增量备份应至少每5 分钟进行一次，确保数据备份的及时性和完整性。 系统应支持多版本备份，确保在数据损坏或丢失时能够恢复到不同时间点的备份版本。 数据恢复能力： 系统应提供快速的数据恢复能力，在发生数据损坏、误操作或灾难时，能够在30 分钟内恢 复最近备份的数据。 恢复过程应支持选择性恢复， 用户可以根据业务需求选择恢复特定模块或时间段的数据， 确 保业务能够快速恢复。 6.5.2.5、灾难恢复演练 定期灾难恢复演练： 系统应定期进行灾难恢复演练， 至少每年进行一次， 确保系统在灾难发生时具备快速恢复的 能力。演练应模拟不同类型的灾难场景（如网络中断、硬件故障、自然灾害等） ，测试系统 的恢复能力。 演练评估与改进： 每次灾难恢复演练后，应生成详细的报告， 评估系统的数据备份和恢复过程中的问题，并根 据演练结果进行系统优化和改进。 6.5.3、数据一致性与完整性 6.5.3.1、数据一致性保证 强一致性： 系统应确保关键业务数据的强一致性， 特别是涉及设备监控、 任务状态等实时数据时，系统 应通过事务机制、分布式锁等手段确保数据在各个节点和数据库间的一致性。 最终一致性： 对于非关键性数据 （如日志、 报表等） ， 系统可采用最终一致性模型， 确保在一定时间内 （如 5 秒内）数据达到一致状态，避免因一致性要求过高导致的性能下降。 6.5.3.2、数据校验与完整性检查 定期数据校验： 系统应定期进行数据校验， 确保数据存储过程中的完整性和一致性。 校验应包括数据库的索 引优化、数据完整性校验、文件校验等，避免因硬件故障或系统错误导致的数据损坏。 数据一致性检查： 系统应具备数据一致性检查机制， 在数据同步、 备份或恢复后， 系统应自动检查数据的一致 性，确保数据在不同节点或数据库中的一致性。 6.5.4、系统监控与告警 6.5.4.1、容错与灾备的实时监控 系统健康监控： 系统应具备实时的健康监控机制， 能够监控各个节点、 服务器、 数据库、 网络等的运行状态， 确保在出现故障或性能下降时能够及时发现。 监控内容应包括处理器、内存、磁盘使用率、网络延迟、数据库性能等，确保系统资源的合 理分配和使用。 6.5.4.2、自动告警与处理 故障告警： 系统应具备自动告警功能， 当系统检测到容错机制失效或灾备机制异常时， 能够自动发送告 警通知（通过邮件、短信、电话等） ，确保运维人员能够及时响应。 告警系统应具备分级机制， 根据故障的严重性自动分配优先级， 确保严重故障能够得到优先 处理。 6.6、网络带宽与灾备能力 6.6.1、网络带宽需求 6.6.1.1、带宽需求评估 用户并发与带宽需求： 系统应根据同时在线用户数量、数据传输量以及业务高峰期的并发数来评估所需的网络带 宽。每个用户的网络带宽需求应根据系统的功能模块（如监控数据流、任务状态更新、数据 查询等）进行详细估算。 在高并发情况下，系统应保证每个用户的最低带宽，确保业务操作的顺畅执行。例如，当并 发用户数量达到1000 人时，系统应确保至少1Gbps 的总网络带宽。 6.6.1.2、数据传输需求 实时数据传输： 系统应支持实时数据传输，例如设备状态更新、 任务进度汇报等。 这些数据传输应具备低延 迟，网络带宽应确保在高并发情况下，实时数据传输的延迟不超过1 秒。 大文件传输需求： 对于大文件传输（如设备日志、视频监控数据、报表导出等） ，系统应具备足够的带宽支持， 以确保大文件能够在5 分钟内完成传输。 系统应确保有足够的冗余带宽， 在进行大文件传输 时不会影响其他业务操作的正常运行。 6.6.1.3、内部网络带宽需求 局域网带宽： 系统应确保医院内部网络（局域网，LAN）具备足够的带宽来支持各个子系统之间的数据交 互。例如，设备监控、任务调度、数据查询等功能应能够在局域网内快速响应，局域网带宽 应至少达到1Gbps，在高负载情况下应支持10Gbps 带宽。 服务器间带宽： 系统各个服务器节点之间的数据传输应具备高速带宽， 尤其对于分布式系统架构， 服务器之 间的带宽应至少达到10Gbps，以支持大规模数据同步和高频率的节点间通信。 6.6.2、网络性能与优化 6.6.2.1、网络延迟要求 端到端延迟： 系统需要保证端到端（用户到服务器）的网络延迟在200ms 以内，确保用户操作的即时性 和系统的快速响应。 如果系统涉及到远程数据传输或跨地理区域的用户， 网络延迟应通过内 容分发网络或边缘计算进行优化。 内部延迟： 系统内部的网络延迟（如设备到服务器、服务器到数据库等）应控制在50ms 以内，确保内 部通信的高效性，尤其是对于实时数据监控和任务调度等场景，要求更低的延迟。 6.6.2.2、网络吞吐量 吞吐量优化： 系统应具备足够的网络吞吐量， 能够在高并发用户访问和数据传输峰值时， 保证网络的稳定 性。网络吞吐量应能够支持每秒处理至少1000 次请求，并在高负载下保持稳定。 带宽利用率： 系统应通过压缩数据、优化数据传输协议来提升带宽利用率， 确保在带宽有限的情况下， 能 够最大化传输效率，减少不必要的网络开销。 6.6.2.3、数据压缩与传输优化 数据压缩： 在进行大规模数据传输时，系统应支持数据压缩机制，以减少带宽占用。压缩率应达到 30%-50%，特别是在传输静态数据或日志文件时，能够显著降低带宽负担。 传输协议优化： 系统应采用高效的传输协议，以提高数据传输的性能和稳定性。 6.6.3、网络冗余与灾备能力 6.6.3.1、多线路冗余 多线路接入： 系统应支持多线路接入， 确保在某条线路出现问题时，能够自动切换到其他可用线路，避免 因网络中断导致的业务中断。多线路接入应具备自动故障切换机制，切换时间不应超过1 分钟。 负载均衡： 系统应具备负载均衡机制， 将网络流量分配到不同的线路或服务器节点上， 确保在高并发情 况下， 各个节点的负载均衡分配合理。 负载均衡能够提升系统的响应速度， 并在某个节点出 现故障时自动切换到其他节点。 6.6.3.2、网络故障恢复能力 网络故障自动检测与恢复： 系统应具备网络故障自动检测机制，能够实时监测网络的连接状态、带宽使用情况， 以及网 络的稳定性。当检测到网络故障时，系统应自动切换到备用线路或备份网络，确保业务不受 影响。 故障恢复时间应控制在1 分钟以内，确保业务连续性。 6.6.3.3、网络灾备中心 异地网络灾备中心： 系统应具备异地灾备中心， 确保在发生重大网络故障或自然灾害时， 能够切换到异地的网络 资源来继续提供服务。 灾备中心应具备独立的网络连接， 避免与主数据中心共用同一网络资 源。 异地灾备中心的网络应与主数据中心保持冗余连接， 确保在灾难发生时， 能够无缝切换到灾 备中心的网络。 6.6.3.4、网络带宽扩展能力 弹性带宽扩展： 系统应具备弹性带宽扩展能力，能够根据业务需求动态扩展网络带宽。 例如，在业务高峰期 或突发情况（如自然灾害应急响应）下，系统应能够自动或手动增加网络带宽，确保服务质 量不受影响。 带宽扩展应支持按需扩展，即在业务量增加时自动扩展，业务量恢复正常后自动降低带宽， 确保资源的合理利用和成本控制。 6.6.4、网络安全与保障 6.6.4.1、网络安全防护 分布式拒绝服务保护： 系统应具备分布式拒绝服务攻击防护能力，能够在遭受大规模流量攻击时，通过流量清洗、 限流等技术手段，确保核心业务不受影响。分布式拒绝服务防护应能够应对至少5Gbps 的 攻击流量，并能够根据攻击规模灵活调整防护策略。 入侵检测与防护： 系统应具备入侵检测与防护系统， 能够实时监控网络流量，分析潜在的攻击行为 （如数据库 注入、跨站脚本攻击等） ，并在攻击发生时自动阻断可疑流量，确保系统的安全性。 6.6.4.2、数据加密传输 加密通信： 系统中的所有数据传输应采用加密通信， 如通过TLS/SSL 协议， 确保敏感数据 （如用户信息、 任务状态、设备数据等）在传输过程中不会被截获或篡改。 特别是在公网传输的数据， 应确保使用最新的加密协议， 避免使用已知存在漏洞的旧版本协 议（如SSLv3 等） 。 6.6.4.3、网络隔离与分区 网络分区： 系统应对不同的功能模块和数据进行网络隔离与分区， 例如将内部管理系统、 设备监控系统、 外部访问系统放置在不同的网络分区中， 确保即使某个分区遭受攻击或故障， 不会影响其他 分区的正常运行。 虚拟局域网： 系统可使用虚拟局域网技术对网络进行逻辑分区， 确保不同部门、 系统模块或设备间的网络 隔离，提升整体系统的安全性和可管理性。 6.6.5、网络监控与管理 6.6.5.1、实时网络监控 带宽使用监控： 系统应具备实时的网络带宽监控功能， 能够监控各个节点、 线路和功能模块的带宽使用情况， 确保网络资源分配合理，及时发现潜在的网络瓶颈。 网络延迟与丢包监控： 系统应实时监控网络的延迟和丢包率，确保在网络出现异常时，能够及时告警并进行处理。 特别是在涉及实时监控和任务调度的模块，网络延迟应保持在可接受范围内（如200ms 以 内） 。 6.6.5.2、网络故障告警 自动告警机制： 系统应具备自动告警机制，当网络带宽使用过高、网络延迟过大或出现丢包、网络中断等问 题时，系统应自动通过邮件、短信、电话等方式通知运维人员，确保能够及时响应。 告警应具备分级处理机制，确保严重的网络故障能够优先处理，保障核心业务的连续性。 6.6.5.3、带宽管理与优化 带宽使用策略： 系统应具备动态的带宽使用策略， 能够根据业务需求动态调整带宽分配。例如， 核心业务模 块（如设备监控、任务调度）应优先获得较大的带宽分配，非核心业务模块（如报表生成、 日志传输）应在网络空闲时进行处理。 带宽限制与优先级： 系统应支持带宽限制和优先级设置， 确保在网络资源有限时， 高优先级的业务模块能够获得 优先处理，低优先级的业务模块则可以延迟处理或限速，避免网络拥塞影响整体系统性能。 七、实施与部署要求 7.1、系统实施计划 7.1.1、实施目标与范围 7.1.1.1、系统实施目标 明确目标： 系统实施的总体目标是确保智慧后勤综合服务平台和智能可视化管理平台顺利部署， 并在规 定的时间内实现系统的上线运行。具体目标包括系统的安装、配置、测试、培训和上线等步 骤，确保系统能够顺利交付并满足技术规格书中的所有功能和性能要求。 阶段性目标： 系统实施应分阶段进行，每个阶段的目标应明确。包括但不限于： 系统环境搭建 软件安装和配置 数据迁移和初始化 功能测试与性能测试 用户培训和验收 系统上线与运行监控 7.1.1.2、实施范围 系统范围： 系统实施计划应明确系统的实施范围， 包括具体的功能模块、 子系统和关键设备的部署范围。 比如，任务管理模块、设备监控模块、数据分析模块等各个子系统的具体实施内容。 物理范围： 实施计划应明确部署的物理范围，包括具体的医院部门、楼层、设备、服务器等。应确保系 统覆盖到所有需要管理的后勤设施和设备，并对不同的物理位置进行相应的部署规划。 7.1.2、项目时间安排 7.1.2.1、总体时间表 项目全周期时间表： 系统实施计划应包括整个项目周期的详细时间表， 明确每个阶段的开始和结束时间。 项目周 期应包括需求分析、系统设计、开发、部署、测试、培训、验收等各个阶段。 关键里程碑： 在时间表中应明确关键的里程碑节点，如系统环境准备完成、系统安装完成、测试完成、用 户培训完成等。每个里程碑应有明确的时间节点，以确保项目进度按计划推进。 7.1.2.2、阶段性时间安排 阶段划分： 系统实施应分为多个阶段，每个阶段应包括详细的任务和时间安排。常见的阶段包括： 项目启动阶段：需求确认、项目组建立 环境搭建阶段：硬件设备、网络和服务器的准备 系统部署阶段：软件安装、模块配置、数据迁移 测试阶段：功能测试、性能测试、用户验收测试 培训阶段：系统使用培训、管理培训 上线阶段：系统正式运行、故障监控 验收阶段：系统最终验收与移交 7.1.3、责任分配与团队结构 7.1.3.1、项目团队组成 项目团队角色： 系统实施计划应明确项目团队的组成，包括项目经理、技术负责人、实施工程师、测试工程 师、培训负责人、运维人员等。明确每个角色的职责，以确保项目的顺利开展。 关键责任人： 每个阶段的关键任务应指定明确的责任人， 确保任务的执行和跟踪。例如， 系统部署由实施 工程师负责，技术问题由技术负责人处理，测试阶段由测试工程师主导等。 7.1.3.2、外部资源协调 供应商与合作伙伴： 如果系统实施涉及外部供应商或合作伙伴（如设备供应商、软件供应商等） ，实施计划中应 明确这些外部资源的参与方式、任务分配和责任范围。 医院内部团队协调： 实施计划还应涵盖与医院内部团队（如IT 部门、后勤部门、设备管理部门等）的协调工作， 确保内部资源的合理分配和各部门的协同工作。 7.1.4、资源需求与支持 7.1.4.1、软硬件资源需求 硬件设备需求： 系统实施计划应明确所需的硬件资源，包括服务器、存储设备、网络设备、工作站等。应根 据系统的性能需求，合理配置硬件资源，确保系统能够稳定运行。 软件资源需求： 实施计划应列出所有需要安装和配置的软件资源，包括操作系统、数据库、中间件、应用程 序等。每个软件的安装版本和配置要求应事先明确，以避免实施过程中出现兼容性问题。 7.1.4.2、人力资源需求 项目人员安排： 系统实施计划应明确每个阶段所需的人员数量和技能要求， 确保项目实施过程中有足够的技 术人员、测试人员和运维人员参与。 7.1.4.3、其他资源支持 外部技术支持： 如果需要外部技术支持（如硬件供应商的安装调试、软件厂商的技术支持等） ，实施计划中 应明确外部支持的具体时间安排和支持内容。 7.1.5、系统实施步骤 7.1.5.1、环境准备 硬件和网络环境准备： 系统实施前，应确保所有硬件设备、网络设备、服务器、存储等基础设施已准备好，并经过 内部测试。网络环境应满足系统部署和数据传输的要求。 系统安装准备： 系统安装前应准备好所有所需的软件安装包、 许可证和配置文档， 并确保所有系统依赖的服 务（如数据库、网络连接等）已准备就绪。 7.1.5.2、系统安装与配置 安装步骤： 系统实施计划应详细列出每个系统模块的安装步骤， 包括数据库安装、 应用程序部署、配置 文件的调整等。每个步骤应有明确的操作说明，确保实施人员能够按照规范进行操作。 配置与调优： 系统安装完成后， 应进行必要的配置和性能调优， 确保系统能够根据医院的实际需求高效运 行。这包括数据库优化、网络配置优化、应用程序性能调优等。 7.1.5.3、数据迁移与初始化 数据迁移： 如果系统需要从旧系统或其他系统中迁移数据， 实施计划应明确数据迁移的过程， 包括数据 清洗、数据导入、数据验证等步骤。 数据初始化： 系统初始化时应导入必要的基础数据，如设备信息、任务信息、用户角色等，确保系统能够 在正式上线前具备基本的运行数据。 7.1.5.4、试与验收 功能测试： 系统上线前应进行全面的功能测试，确保所有功能模块正常运行。功能测试包括单元测试、 集成测试、用户验收测试等。 性能测试： 系统应经过严格的性能测试， 确保在高并发、复杂操作下系统能够稳定运行。性能测试应包 括响应时间、并发处理能力、网络带宽使用等关键指标。 7.1.5.5、用户培训与文档交付 用户培训： 在系统上线前，实施计划应安排针对不同用户（管理员、操作员、技术人员等）的培训，确 保他们能够熟练使用系统的各项功能。 技术文档交付： 系统实施完成后，应交付完整的技术文档，包括安装手册、操作手册、维护手册、常见问题 解答等，确保运维人员和用户能够根据文档进行系统维护和操作。 7.1.6、风险管理与应急预案 7.1.6.1、风险识别与评估 潜在风险识别： 系统实施计划应识别实施过程中的潜在风险，如硬件故障、网络不稳定、数据迁移失败、人 员短缺等。应对每个风险进行优先级评估，明确哪些风险对项目的影响最大。 风险评估： 针对每个潜在风险， 实施计划应进行详细的风险评估，包括发生概率、 影响程度以及应对措 施。 7.1.6.2、应急预案 应急方案制定： 对于关键风险， 系统实施计划应制定相应的应急预案，如硬件故障时的备件供应、数据丢失 时的数据备份恢复方案、人员短缺时的外部资源调度等。 应急响应机制： 实施计划应明确应急响应的流程和责任分配，确保在风险发生时能够及时响应并采取措施， 避免对项目产生重大影响。 7.2、部署架构设计 7.2.1、部署架构总体设计 7.2.1.1、部署架构概述 系统架构概述： 系统的部署架构应采用模块化设计，明确各个模块（如任务管理模块、设备监控模块、数据 分析模块等）在物理服务器、虚拟机或容器中的部署方式。应提供架构图，展示各个模块的 相互关系、数据流动和依赖性。 部署模型： 部署架构设计应明确采用的部署模型，如单一数据中心、主备数据中心、分布式部署，或是 基于云计算、混合云等不同的部署模式。 如果系统涉及多个地理位置的部署（如主中心和异地灾备中心） ，应明确数据同步和流量调 度的机制。 7.2.1.2、系统分层架构 分层设计： 部署架构设计应遵循分层架构的原则， 将系统划分为不同的逻辑层和物理层， 包括但不限于： 表示层（前端系统、用户接口） 业务逻辑层（应用服务、业务处理） 数据访问层（数据库、缓存等） 基础设施层（服务器、存储、网络设备等） 各层之间的通信方式、数据格式和调用机制应明确说明，并确保良好的隔离性和松耦合。 7.2.2、服务器与资源规划 7.2.2.1、服务器规划 服务器类型与规格： 部署架构设计应明确系统中使用的服务器类型，如物理服务器、虚拟机、云主机或容器。每 种服务器应根据其功能和角色（如应用服务器、数据库服务器、文件服务器等）进行规划。 对于每台服务器，应明确其硬件配置，如处理器核心数、内存大小、存储容量和网络带宽， 确保能够满足系统的性能需求。 7.2.2.2、资源分配与隔离 资源分配策略： 部署架构应明确各个业务模块所需的资源分配， 确保不同模块间不会因资源争夺而影响系统 性能。 资源隔离： 对于关键业务模块（如任务调度、 设备监控等） ，应采用单独的服务器或容器实例进行部署， 确保在高负载时不会影响其他模块的正常运行。 对于不同的租户或用户群体， 资源隔离策略 应更加严格。 7.2.3、数据库与存储设计 7.2.3.1、数据库部署 数据库类型与架构： 部署架构设计应明确系统中使用的数据库类型， 并详细描述数据库的部署架构。 例如，是否 采用主从复制、读写分离，或者是分布式数据库架构。 数据库应具备高可用性， 可通过主备切换或集群模式来保障业务的连续性， 确保在主库故障 时，备库能够快速接管。 7.2.3.2、存储规划 存储类型与分配： 存储设计应明确系统使用的存储类型（如本地磁盘、NAS、SAN 等） ，并根据数据的访问频 率、大小和重要性进行合理分配。例如，热数据存储在高性能的SSD 上，冷数据可以存储在 机械硬盘或云存储上。 数据备份与恢复机制： 系统应具备自动备份机制， 数据库和文件存储的数据应进行定期的全量备份和增量备份。 应 明确备份的频率和数据保留策略， 并设计相应的数据恢复机制， 确保在数据丢失或损坏时能 够快速恢复。 7.2.4、网络架构与配置 7.2.4.1、网络拓扑 网络架构设计： 部署架构设计应提供系统的网络拓扑图，明确各个服务器、网络设备（如交换机、路由器、 防火墙等）之间的连接方式。网络架构应能够支持系统的高并发访问和大规模数据传输。 内部与外部网络配置： 系统应区分内部网络和外部网络的流量。 例如， 应用服务器与数据库之间的通信应通过内部 网络进行，而用户访问系统的流量应通过外部网络。应确保内部网络的高带宽和低延迟。 7.2.4.2、网络安全与隔离 网络隔离： 系统应通过虚拟局域网、 子网或防火墙策略实现网络隔离， 确保敏感数据和关键业务模块不 会暴露在不信任的网络中。 例如， 数据库服务器应放置在内网， 并通过防火墙限制外部访问。 网络安全设计： 网络架构设计应包括安全防护措施， 如入侵检测系统、 防火墙策略、 分布式拒绝服务防护等。 所有外部访问的接口应通过SSL/TLS 加密，确保数据传输的安全性。 7.2.5、系统高可用性与容错设计 7.2.5.1、高可用性架构 负载均衡与冗余设计： 部署架构设计应明确系统中的负载均衡机制， 确保多个应用服务器或服务实例之间可以平衡 负载，避免单点故障。可以采用硬件负载均衡设备或软件负载均衡器。 冗余与备份： 对于关键的业务模块，应采用冗余部署，确保在某一节点出现故障时， 其他节点能够继续提 供服务。 7.2.5.2、容错与故障恢复 自动故障切换： 系统应具备自动故障切换机制， 当某一服务器或服务实例出现故障时， 系统应自动切换到备 用节点或实例， 以确保业务不中断。 故障切换的时间应尽可能短， 通常应控制在30 秒以内。 健康检查与自动恢复： 系统应定期对各个模块进行健康检查， 一旦发现某个服务或服务器不健康， 系统应自动尝试 重启、恢复或切换到其他节点。健康检查的结果应通过监控系统进行实时展示和报警。 7.2.6、系统扩展性与弹性设计 7.2.6.1、水平扩展与垂直扩展 水平扩展： 系统架构应支持水平扩展， 即通过增加更多的服务器或节点来提升系统的处理能力。 水平扩 展应尽可能做到无缝扩展， 即在不影响现有服务的情况下， 能够通过增加节点扩展系统的处 理能力。 垂直扩展： 对于单一服务器实例， 系统应支持垂直扩展， 即通过增加服务器的硬件资源 （如增加处理器、 内存等）来提升性能。系统应具备良好的资源利用率，确保在高负载情况下能够有效扩展。 7.2.6.2、弹性伸缩机制 自动伸缩： 部署架构应支持自动弹性伸缩， 即在业务高峰期能够自动扩展服务器或服务实例的数量， 而 在业务低谷期则可以缩减资源，减少成本。 负载监控与自动触发： 系统应具备负载监控功能，能够实时监控处理器、内存、网络带宽等指标。当某个指标超过 预设阈值时，系统应自动触发扩展操作，确保系统的高可用性和性能。 7.2.7、部署规范与自动化 7.2.7.1、部署规范 标准化部署流程： 部署架构设计应明确标准化的部署流程，包括软件安装、配置文件管理、服务启动等操作。 所有部署步骤应有详细的操作文档，并确保相关人员能够按照规范执行部署任务。 环境一致性： 为了避免生产环境与测试、开发环境的不一致， 系统应采用环境一致性管理工具。这些工具 能够确保在不同环境中部署的系统具备相同的配置和运行环境。 7.2.7.2、自动化部署与持续集成 自动化部署工具： 系统应支持自动化部署， 通过工具实现一键部署，减少人为操作带来的错误。自动化部署工 具应支持批量部署、滚动升级、回滚等功能。 持续集成/持续部署： 部署架构应支持持续集成/持续部署流程，使得代码的开发、测试、部署能够自动化完成， 减少手动干预。持续集成/持续部署流程应包括自动构建、自动测试、自动部署等步骤，确 保软件能够快速迭代和部署。 7.3、数据迁移与转换方案 7.3.1、数据迁移与转换目标 7.3.1.1、数据迁移目标 明确迁移目标： 数据迁移的主要目标是将现有系统中的所有相关数据 （如设备信息、 任务记录、 用户数据等） 迁移到新系统中， 并确保数据的完整性和一致性。 所有迁移的数据应与新系统的架构和业务 逻辑相匹配，确保在新系统中能够正常使用。 业务连续性保障： 在数据迁移过程中， 必须确保医院的业务不受影响。 迁移应尽量在业务低峰期或计划的维护 窗口内进行，确保系统能够平稳过渡。 7.3.1.2、数据转换目标 数据格式转换： 如果现有系统中的数据格式与新系统不兼容， 数据迁移过程中应进行数据格式转换。 目标是 确保旧系统中的数据能够与新系统的数据结构、字段类型、编码方式等保持一致。 数据标准化： 数据迁移过程中应对数据进行标准化处理，如统一日期格式、编码格式、单位转换等，确保 新系统中的数据遵循统一的标准，避免因数据不一致导致的业务逻辑错误。 7.3.2、数据迁移与转换范围 7.3.2.1、数据迁移的类型与范围 数据类型： 数据迁移范围应明确包括系统中涉及的所有数据类型，如： 设备数据：设备信息、状态、历史记录 任务数据：任务调度、执行情况、工单记录 用户数据：用户信息、权限配置、操作日志 历史数据：历史报表、日志、统计信息 配置数据：系统参数、规则配置、工作流定义等 数据量与规模： 应描述需要迁移数据的总量和规模，包括数据表的数量、记录总数、存储空间大小等，确保 在迁移过程中能够合理分配资源，避免因数据量过大导致的迁移延误或失败。 7.3.2.2、数据转换的范围 数据字段映射： 在数据迁移过程中，旧系统与新系统的数据结构可能不同，设计应明确数据字段映射关系， 包括字段名称、数据类型、字段长度、约束条件等。应提供详细的字段映射表，确保数据能 够正确转换到新系统。 数据清洗： 数据转换过程中，可能需要对现有系统中的数据进行清洗，如删除冗余数据、修复不完整数 据、处理重复记录等。应制定数据清洗规则，确保清洗后的数据在新系统中符合业务需求。 7.3.3、数据迁移与转换步骤 7.3.3.1、数据迁移前的准备工作 数据备份： 在数据迁移前， 应对现有系统中的所有数据进行完整的备份， 确保在迁移过程中如果发生问 题，能够快速恢复到原始状态。备份数据应存储在安全的存储介质上， 并经过验证确保备份 的完整性和可恢复性。 环境准备： 确保新系统的部署环境（服务器、数据库、存储等）已经准备好，并经过测试以确保可以承 载迁移后的数据。还应确保网络连接稳定，避免迁移过程中出现中断。 7.3.3.2、数据迁移与转换流程 数据提取： 从现有系统中提取数据时， 应明确数据提取的工具和方法， 确保提取过程中数据的完整性和 一致性。提取的数据应经过初步验证，以确保数据没有损坏或丢失。 数据转换： 在数据转换过程中， 应根据预先定义的字段映射关系和转换规则， 将旧系统中的数据进行转 换。转换过程中应严格遵循数据类型和格式规范，确保数据能够正确导入新系统。 数据导入： 数据转换完成后，使用导入工具或脚本将数据导入新系统中。导入过程应记录详细的日志， 确保每条数据的导入情况可追溯。如果导入过程中出现错误，应能够快速定位并修复问题。 7.3.3.3、数据验证与校验 数据一致性校验： 数据迁移完成后， 必须对新系统中的数据进行一致性校验， 确保迁移后的数据与旧系统中的 数据完全一致。应对关键数据（如设备信息、任务数据、用户数据等）进行逐一比对，确保 没有数据丢失、重复或错误。 数据完整性验证： 除了一致性校验外， 还应对数据的完整性进行验证， 确保所有必填字段都有有效数据，所有 数据记录都符合新系统的业务规则和数据约束条件。 7.3.3.4、数据清洗与优化 数据清洗规则执行： 在数据迁移过程中， 应根据预定义的规则执行数据清洗操作， 如删除无效数据、 合并重复记 录、修正错误数据等。数据清洗应在迁移前完成校验，确保清洗后的数据符合新系统的业务 需求。 数据性能优化： 数据导入后， 应对新系统中的数据进行性能优化， 如为关键字段建立索引、 优化查询字段等， 确保新系统能够高效处理业务操作。 7.3.4、数据迁移风险管理 7.3.4.1、数据迁移风险识别 潜在风险： 数据迁移过程中的潜在风险可能包括：数据丢失、数据格式不兼容、网络中断、系统性能下 降等。应对这些风险进行识别，并根据影响程度进行分级处理。 数据冲突与不一致性： 在数据迁移过程中， 可能会出现数据冲突或不一致性，如不同系统间的数据版本不一致、 记 录重复等。应明确如何处理这些冲突，确保最终数据的准确性。 7.3.4.2、风险应对措施 应急预案： 为应对数据迁移过程中可能出现的紧急情况（如数据丢失、迁移失败等） ，应制定应急预案。 应急预案中应明确如何快速恢复旧系统的数据，以及如何修复迁移过程中出现的错误。 回滚机制： 如果数据迁移过程中出现重大问题，应具备回滚机制，能够将系统恢复到迁移前的状态。 回 滚过程应快速、可靠，避免影响业务连续性。 7.3.5、数据迁移的工具与技术 7.3.5.1、数据迁移工具 数据迁移工具选择： 系统应选择适合的数据迁移工具，确保能够高效、安全地进行数据提取、转换和导入。 自定义脚本： 对于复杂的数据转换需求， 可能需要编写自定义脚本来处理特定的转换逻辑。 脚本应经过充 分测试，确保能够正确执行数据迁移和转换过程。 7.3.5.2、数据加密与安全传输 数据加密： 在数据迁移过程中，特别是涉及敏感数据（如用户信息、设备日志等）时，应确保数据在传 输和存储过程中经过加密处理，如使用SSL/TLS 协议传输数据，或对数据进行AES 加密后再 传输。 安全传输： 数据迁移过程中，应确保数据的传输通道是安全的，防止数据在传输过程中被截获或篡改。 应使用VPN 或专用网络进行数据传输，确保数据的安全性。 7.3.6、数据迁移后的验证与确认 7.3.6.1、用户验收测试 验收测试： 数据迁移完成后， 应进行用户验收测试， 确保业务部门能够在新系统中正常访问和使用迁移 后的数据。用户验收测试应覆盖所有关键业务流程，确保数据的完整性和准确性。 用户反馈与调整： 用户在验收测试过程中可能会发现数据问题（如数据缺失、不一致等） ，应根据用户反馈进 行数据调整和优化，确保最终的数据符合用户需求。 7.3.6.2、数据迁移确认 迁移确认文档： 数据迁移完成后，应形成迁移确认文档，记录迁移的详细过程、数据校验结果、问题处理情 况以及最终确认的迁移数据量和内容。 迁移确认文档应由项目负责人和相关业务部门共同签 字确认。 迁移后数据维护： 数据迁移完成后，应制定数据维护方案，确保数据在新系统中得到持续维护和管理。 应定期 进行数据备份、清理无效数据，并对数据库性能进行持续优化。 7.4、测试计划 7.4.1、测试目标与范围 7.4.1.1、测试目标 明确测试目标： 测试的主要目标是验证系统是否满足技术规格书中的所有要求， 包括功能性、 性能、 稳定性、 安全性、兼容性等。 测试应确保系统在真实环境中可以正常运行， 并且能够支持医院业务的 连续性和可靠性。 业务连续性保障： 测试还应确保系统在高负载、 峰值流量等场景下能够稳定运行， 确保智慧后勤综合服务平台 和智能可视化管理平台不会因故障或性能问题影响业务连续性。 7.4.1.2、测试范围 系统功能： 测试范围应覆盖系统的所有功能模块，如任务管理、设备监控、数据分析、用户管理等。每 个功能模块都应进行单独测试和集成测试，确保各模块之间的协同工作没有问题。 非功能性要求： 除功能测试外，测试范围还应包括非功能性要求，如性能测试（响应时间、并发用户数） 、 安全性测试、兼容性测试、易用性测试、可维护性测试等。 7.4.2、测试类型与方法 7.4.2.1、功能测试 单元测试： 针对系统各个子模块进行单元测试，确保每个模块的基本功能能够按照设计要求正常运行。 测试应包括所有可能的输入和输出情况，确保模块在各种场景下都能正常工作。 集成测试： 通过集成测试验证各个模块之间的互操作性， 确保模块之间的数据传输和业务逻辑能够正确 执行。集成测试应覆盖所有主要的业务流程，确保系统在整体上能够正常运行。 回归测试： 在系统升级或修改后， 进行回归测试， 验证新功能或修复的Bug 不会对系统的已有功能造成 影响，确保系统整体功能的稳定性。 7.4.2.2、性能测试 负载测试： 通过负载测试验证系统在高并发用户访问、 数据处理量增加的情况下是否能够稳定运行。 测 试应模拟实际使用场景，评估系统在不同负载条件下的响应时间、吞吐量和资源利用率。 压力测试： 通过压力测试评估系统在极限负载下的行为。 测试应逐步增加系统的负载直到系统崩溃， 以 评估系统的最大承载能力和故障恢复能力。 容量测试： 通过容量测试验证系统在不同规模的数据集下的性能表现， 确保系统能够处理预期的数据量 和用户数量。 7.4.2.3、安全性测试 漏洞扫描： 通过漏洞扫描工具检测系统中的安全漏洞，并确保这些安全问题能够得到及时修复。 访问控制测试： 验证系统的用户权限管理是否严格，确保不同角色的用户只能访问他们授权的功能和数据， 防止越权行为。 数据加密与传输安全测试： 测试系统中敏感数据（如用户信息、设备日志等）的加密和传输安全性，确保数据在存储和 传输过程中不会被泄露或篡改。 7.4.2.4、兼容性测试 跨平台兼容性： 通过兼容性测试验证系统是否能够在不同的操作系统、不同设备和不同浏览器上正常运行。 软件版本兼容性： 验证系统是否与不同版本的软件或中间件（如数据库、服务器软件等）兼容，确保系统不会 因为软件版本的差异而出现功能异常。 7.4.2.5、用户验收测试 用户参与测试： 用户验收测试是测试计划中的重要环节， 确保系统的功能和性能能够满足用户的实际业务需 求。用户应参与测试过程，并对系统的功能、界面、易用性等进行评估。 业务流程测试： 根据实际业务流程， 设计一系列的用户场景， 确保系统能够支持医院智慧后勤管理工作的关 键业务操作，如设备调度、任务管理、报表生成等。 7.4.3、测试环境与数据准备 7.4.3.1、测试环境配置 硬件与网络环境： 测试计划应明确测试环境的硬件配置和网络拓扑，确保测试环境尽可能接近实际的生产环 境。测试环境的服务器、存储、网络设备应与生产环境具有相同或相似的配置，确保测试结 果具有参考价值。 软件与中间件环境： 测试环境中的操作系统、数据库、中间件、应用软件等应与生产环境保持一致。应确保所有 依赖的软件包、库文件等都已正确安装和配置。 7.4.3.2、测试数据准备 真实数据与模拟数据： 测试计划应明确使用的测试数据类型， 既可以使用真实业务数据， 也可以使用模拟数据。 测 试数据应覆盖所有可能的业务场景，包括正常情况和异常情况。 数据初始化： 在测试开始前， 测试环境中的数据应进行初始化，确保测试数据符合预期的业务状态。如果 测试涉及多次运行，测试数据应在每次测试后进行重置。 7.4.4、测试执行与记录 7.4.4.1、测试执行步骤 测试脚本与自动化工具： 测试应按照预先编写的测试脚本进行， 确保测试过程的标准化和可重复性。 对于复杂的功能 测试和性能测试，建议使用自动化测试工具来执行测试。 手工测试： 对于不能自动化的测试（如用户体验测试、界面测试等） ，应由测试人员手工执行，并记录 每一步的操作和结果。 7.4.4.2、测试记录与报告 测试记录表： 每次测试的执行情况应记录在测试记录表中，包括测试的日期、执行人员、测试结果、故障 描述和修复进度等。所有的测试记录应保存归档，便于后续的分析和审核。 测试报告： 测试完成后，应形成测试报告，总结测试执行情况、测试结果、发现的Bug 与问题、系统的 性能表现等， 并提出改进建议。 测试报告应提供给项目开发团队和相关的业务部门进行审核。 7.4.5、问题跟踪与修复 7.4.5.1、故障分类与优先级 问题分类： 测试过程中发现的问题应按照其性质进行分类，如功能性问题、性能问题、安全问题、界面 问题等。每个问题应有详细的描述，并记录其影响范围和重现步骤。 优先级划分： 根据问题的严重程度，问题应分为紧急（如系统崩溃、数据丢失） 、高优先级（如关键功能 失效） 、中优先级（如次要功能异常） 、低优先级（如界面细节问题） 。优先处理紧急和高优 先级的问题，确保系统的核心功能能够正常运行。 7.4.5.2、问题修复与回归测试 问题修复流程： 开发人员应根据测试报告中的问题列表逐项修复问题， 修复完成后重新提交给测试人员进行 验证。每次修复后，测试人员应执行回归测试，确保修复不会引入新的问题。 问题关闭： 当问题被修复并通过回归测试后， 测试人员应在问题跟踪系统中关闭该问题， 并记录修复的 时间和修复内容，确保问题能够被追踪和记录。 7.4.6、测试验收与总结 7.4.6.1、验收标准 通过标准： 测试完成后， 应根据预先设定的通过标准进行系统的最终验收。 通过标准应包括关键功能的 100%通过率、性能指标达到要求、安全性无重大漏洞等。如果系统未达到通过标准，应进 行进一步的优化和测试，直至满足要求。 用户验收确认： 用户验收测试后， 业务部门应对测试结果进行确认并签字， 确保系统在业务使用中的可行性 和稳定性。 7.4.6.2、测试总结与改进 测试总结报告： 测试完成后，应形成测试总结报告，总结整个测试过程中的经验、问题和改进建议。总结报 告应包括测试范围、测试类型、问题修复情况、系统表现等内容，并为后续系统的维护和升 级提供参考。 持续改进： 根据测试过程中发现的问题， 项目组应对开发和测试流程进行优化， 确保在后续的开发和测 试中能够减少类似问题的发生，提升系统的整体质量。 7.5、用户培训计划 7.5.1、培训目标与原则 7.5.1.1、培训目标 提高系统使用能力： 培训的主要目标是确保用户能够熟练掌握系统操作， 并能够应用系统的各项功能完成日常工 作。用户培训应涵盖系统的基本操作、数据查询、报表生成、设备管理、任务调度等核心功 能。 提高问题解决能力： 培训应帮助用户掌握基本的问题排查和解决能力， 使他们能够应对常见的操作问题和系统故 障，减少对技术支持的依赖。 支持业务流程优化： 培训应确保用户了解系统功能的优化使用方式， 帮助他们更好地结合实际业务需求， 利用系 统提升工作效率和业务流程的自动化程度。 7.5.1.2、培训原则 针对性与实用性： 培训内容应根据不同用户群体的需求进行定制， 确保培训的针对性。对于操作人员、 管理人 员、技术支持人员等不同角色，应设计不同的培训课程， 确保每个群体能够掌握与其职责相 关的知识和技能。 循序渐进： 培训计划应遵循循序渐进的原则， 从基础操作到高级功能，逐步加深培训内容， 确保学员能 够逐步消化和吸收知识。 理论与实践相结合： 培训应在讲解系统理论知识的同时， 提供充足的操作演练机会， 确保学员能够通过实际操作 加深对系统的理解。 7.5.2、培训内容 7.5.2.1、基础操作培训 系统登录与界面介绍： 培训应包括系统的登录流程、 用户界面介绍、菜单结构说明等基础操作，确保用户能够快速 熟悉系统的使用环境。 基本功能操作： 针对系统的核心功能模块（如任务管理、设备监控、数据查询等） ，培训应详细讲解每个功 能的使用方法，包括如何创建、编辑、删除和查询数据。 7.5.2.2、进阶操作培训 报表与统计分析： 培训应讲解如何使用系统的报表生成和统计分析功能， 帮助用户熟练掌握数据的查询、 筛选、 导出和分析，以及如何根据分析结果做出业务决策。 自定义配置： 对于有权限的用户， 培训应涵盖系统自定义配置的内容， 例如如何调整用户权限、配置系统 参数、设置报警规则等，确保用户能够根据业务需求配置系统。 7.5.2.3、管理与维护培训 系统管理培训： 针对系统管理员，应培训如何进行用户管理、权限分配、系统日志查看、系统备份与恢复等 操作，确保系统的安全性与稳定性。 故障排查与维护： 提供常见问题的故障排查培训，如网络连接问题、系统响应慢、数据异常等。管理员应掌握 如何快速定位和解决问题，或在必要时联系技术支持。 7.5.2.4、安全操作培训 数据安全与隐私保护： 培训应强调系统的安全操作规范， 确保用户在使用系统时能够遵循数据安全与隐私保护的要 求。内容包括密码管理、数据加密、敏感信息处理等。 安全事件处理： 用户应了解如何应对安全事件（如数据泄露、账户异常等） ，包括如何及时上报问题、封禁 可疑账户、查看系统日志等操作。 7.5.3、培训方式与工具 7.5.3.1、培训方式 现场培训： 培训人员应在医院现场进行面对面的培训，解答用户的疑问，并进行实时的操作演示。 远程培训： 对于分布式的用户或后续的更新培训， 可以采用远程培训进行， 确保培训的灵活性和覆盖面。 自助学习： 提供系统的用户手册、操作视频、 常见问题解答等自助学习资源， 确保用户在培训后能够通 过这些资源自主学习和巩固知识。 7.5.3.2、培训工具 演示系统： 培训应提供一个与实际系统相同或相似的演示系统， 供学员进行实际操作练习， 确保学员能 够在无风险的环境下熟悉系统的操作流程。 多媒体教学资料： 培训过程中应使用多媒体教学资料，如PPT 演示文稿、操作视频、在线教程等，帮助学员更 直观地理解操作步骤和系统功能。 在线测试与练习： 培训计划可以包括在线测试或操作练习， 通过在线测试评估学员的学习效果， 并根据测试结 果提供针对性的指导和反馈。 7.5.4、培训对象与分层培训 7.5.4.1、培训对象分类 操作人员： 负责日常操作的人员应接受系统的基础操作和进阶操作培训， 确保他们能够高效执行任务调 度、设备管理、数据查询等日常工作。 管理人员： 管理人员需要掌握系统的高级功能，如报表生成、统计分析、权限管理等，帮助他们进行数 据驱动的决策和业务优化。 技术支持人员： 技术支持人员应接受系统的管理与维护培训，掌握系统的安装、配置、维护、故障排查等技 术知识，确保他们能够为操作人员和管理人员提供技术支持。 7.5.4.2、分层培训策略 基础培训： 面向所有用户， 提供基础功能的操作培训， 确保每个用户都能掌握系统的核心功能并胜任日 常工作。 进阶培训： 面向特定用户群（如管理员、技术支持人员） ，提供进阶培训，帮助他们掌握复杂功能、系 统配置和问题解决的能力。 专项培训： 根据用户的具体需求，提供专项培训（如报表与数据分析、任务调度自动化等）以满足不同 角色的业务需求。 7.5.5、培训评估与反馈 7.5.5.1、培训评估 培训效果评估： 培训结束后， 应通过在线测试或操作考核等方式对学员的学习效果进行评估， 考察学员对系 统功能的掌握程度。评估内容应包括系统基本操作、数据查询与分析、常见问题处理等。 用户满意度调查： 培训结束后，进行用户满意度调查，收集学员对培训内容、培训讲师、培训方式的反馈。调 查结果将用于后续培训的优化和改进。 7.5.5.2、培训反馈与改进 反馈机制： 建立完善的培训反馈机制， 学员在培训过程中或培训结束后， 可以随时反馈他们的意见和建 议。反馈机制应包括在线反馈、课程评价表等渠道。 培训计划改进： 根据学员的反馈和评估结果，对培训计划、培训方式、培训内容进行不断优化。通过总结培 训中的经验和问题，提升后续培训的效果和针对性。 7.6、项目实施阶段与时间表 7.6.1、项目实施目标与原则 7.6.1.1、实施目标 确保按时交付： 项目实施的目标是确保在规定的时间范围内，按照预期的质量和功能要求，成功交付系统。 阶段性成果交付： 实现每个项目阶段的明确交付成果， 确保项目的进度能够被持续评估和调整， 避免项目延期 或超出预算。 7.6.1.2、实施原则 循序渐进： 项目实施应按照分阶段进行， 每个阶段应有明确的任务、 目标和交付物，确保项目能够按计 划顺利进行。 灵活调整： 项目的时间表应具备一定的灵活性， 允许根据实际进展情况进行适当调整， 确保在不影响总 体进度的情况下应对突发情况或需求变更。 7.6.2、项目实施阶段划分 7.6.2.1、启动阶段 项目启动与需求确认： 明确项目目标、范围、需求，确定项目团队成员、职责分工，并制定详细的项目实施计划和 沟通机制。 7.6.2.2、设计阶段 系统架构设计： 在此阶段， 进行系统的总体架构设计， 明确系统的技术框架、 功能模块、 数据库设计等内容。 接口与数据设计： 设计与其他系统的接口方案，制定数据格式、数据流转的详细设计。 7.6.2.3、开发阶段 模块化开发： 按照系统设计的功能模块，逐步进行开发工作。 开发过程中应遵循阶段性目标， 确保模块功 能的逐步实现。 接口开发与集成： 开发与其他系统的接口，确保数据能够顺利交互，并进行系统的初步集成测试。 7.6.2.4、测试阶段 单元测试： 在每个功能模块开发完成后，立即进行单元测试，确保模块功能的正确性。 集成测试： 各功能模块开发完成后，进行集成测试，验证各模块之间的数据流转和业务逻辑是否正确。 用户验收测试： 在系统整体测试通过后，进行用户验收测试，确保系统功能和性能符合用户需求。 7.6.2.5、部署阶段 系统部署与配置： 将系统部署到生产环境，进行必要的配置、调试，确保系统能够正常运行。 数据迁移与导入： 将旧系统的数据迁移到新系统中，并进行数据校验，确保数据的完整性和准确性。 7.6.2.6、培训与切换阶段 用户培训： 对系统的最终用户进行全面的培训，确保他们能够熟练操作系统。培训方式包括现场培训、 远程培训等。 系统切换与上线： 在充分的测试和培训后，进行系统切换，将新系统投入正式使用，关闭旧系统或转为备用。 7.6.2.7、维护与支持阶段 项目验收与支持： 系统正式上线后， 技术团队应提供一段时间的技术支持， 解决用户在使用过程中遇到的问题， 并对系统进行必要的调整和优化。 7.6.3、项目时间表 7.6.3.1、总体时间表 时间表形式： 项目时间表可以采用甘特图或项目计划表的形式， 明确每个阶段的开始和结束时间、 任务分 配、关键节点等信息。 阶段划分： 时间表应按照项目实施阶段进行划分，包括启动、设计、开发、测试、部署、培训与切换、 维护与支持等。 里程碑设置： 在时间表中设置关键里程碑，如需求确认完成、系统设计完成、开发完成、测试完成、正式 上线等。每个里程碑应代表一个阶段性目标的达成。 7.6.3.2、时间节点与任务分配 关键时间节点： 对每个阶段设定明确的开始与结束时间， 并标明关键任务的时间节点。 时间节点应与项目的 总体时间表匹配，确保各阶段任务按时完成。 任务分配与责任人： 明确每个任务的责任人、 参与人员以及完成时间，确保任务分工明确， 避免职责不清或任务 重复。 7.6.4、项目进度监控与调整 7.6.4.1、进度跟踪机制 定期进度汇报： 每周或每两周召开项目进度会议， 项目团队应汇报每个阶段的进展情况， 并对存在的问题进 行讨论和解决，确保项目始终按计划推进。 项目进度报告： 项目经理应定期向管理层提交项目进度报告，包括完成的任务、未完成的任务、 存在的风险 与问题、以及下一阶段的计划。 7.6.4.2、风险管理与应对 风险识别与评估： 在每个阶段的实施过程中，应不断识别项目的潜在风险（如人员不足、技术难题、需求变化 等） ，并对风险进行评估，制定相应的风险应对策略。 应急预案： 对于可能导致项目延期或影响项目质量的风险， 应有相应的应急预案， 确保在风险发生时能 够及时应对，减少对项目的影响。 7.6.4.3、项目调整机制 时间表调整： 如果项目进度出现偏差， 项目经理应根据实际情况对时间表进行调整， 确保关键里程碑不会 受到影响。调整后的时间表应经过项目管理层和相关利益方的确认。 资源协调与优化： 如果项目进度滞后， 可以通过增加人力、加快资源调配等方式优化资源分配，确保项目能够 顺利推进。 7.6.5、项目验收与总结 7.6.5.1、项目验收标准 项目验收准备： 项目接近尾声时，应准备项目验收文档，详细记录项目的完成情况，包括功能实现、系统质 量、用户反馈等。 验收标准： 项目验收应以预先制定的验收标准为依据，确保项目的最终交付物符合合同要求和用户需 求。验收标准包括系统功能、性能指标、数据迁移质量、用户满意度等。 7.6.5.2、项目总结与改进 项目总结报告： 项目完成后，项目经理应组织项目团队进行总结，并制作项目总结报告，分析项目的成功经 验、遇到的问题、解决的方案以及改进的建议。 持续改进： 根据项目的总结结果， 提出今后项目管理中的改进措施， 帮助团队在未来的项目实施中规避 类似问题，并进一步提升项目管理水平。 八、运维与支持要求 8.1、系统运维方案 8.1.1、运维目标与原则 8.1.1.1、运维目标 系统稳定性保障： 确保系统在上线后能够长期稳定运行， 满足日常业务需求， 减少系统宕机或中断的情况发生。 快速问题响应： 确保在系统运行过程中出现问题时， 能够快速定位问题并进行修复， 减少对用户及业务的影 响。 性能与安全优化： 通过持续的监控和优化， 确保系统性能能够满足业务增长需求， 并保障系统在不同负载下的 高效运行。同时，确保系统的安全性，防范数据泄露、攻击等安全风险。 8.1.1.2、运维原则 预防性维护优先： 系统运维应以预防性维护为主，尽量在问题发生前发现并解决潜在风险，避免问题的发生。 自动化与规范化： 运维工作应尽可能实现自动化，减少人工干预，提升效率和准确性。同时，所有操作必须规 范化，确保运维流程有据可依，并记录所有变更和操作细节。 8.1.2、运维组织与职责分工 8.1.2.1、运维团队组成 运维团队架构： 运维团队应具备明确的职责分工，包括系统管理员、网络管理员、安全管理员、数据库管理 员等，确保每个运维岗位都有专门的人员负责。 第三方支持： 如果系统涉及第三方供应商（如硬件设备、软件服务等） ，则应明确这些第三方在运维中的 角色、联系方式以及支持范围。 8.1.2.2、运维职责分工 系统管理员： 负责系统的日常运行维护，包括系统配置、故障排查、用户管理等。 网络管理员： 负责网络的正常运行、网络设备的监控与维护，确保系统在网络层面的稳定与安全。 安全管理员： 负责系统的安全管理，包括防火墙设置、漏洞修复、账号权限管理等，确保系统不受外部攻 击。 数据库管理员： 负责数据库的正常运行与优化，确保数据的安全性、 完整性与可用性， 并执行定期备份和恢 复测试。 8.1.3、系统监控与预警机制 8.1.3.1、实时监控 系统健康监控： 实时监控系统的各项健康指标， 包括处理器、 内存、 磁盘使用率、 网络流量、 数据库性能等， 确保系统在最佳状态下运行。 业务指标监控： 除了硬件和系统层面的监控，还应监控关键业务指标，如系统响应时间、请求处理成功率、 任务队列长度等，确保系统能够满足业务需求。 8.1.3.2、预警与报警机制 阈值设定： 为每个监控指标设定合理的阈值， 当相关指标超过阈值时，系统应自动触发预警，通知相关 人员进行处理。 多层次报警： 报警机制应具备多层次的处理流程。 低级别的报警可以由系统自动修复或记录日志， 而严重 的报警应立刻通知运维团队，甚至触发应急响应机制。 8.1.3.3、报警通知与处理 通知机制： 预警和报警应通过多种渠道通知相关人员，如电子邮件、短信、即时消息工具等，确保问题 能够及时被处理。 报警处理流程： 制定详细的报警处理流程， 确保每个报警都有明确的响应和处理步骤。 所有报警的处理过程 应记录在案，以便后续分析和改进。 8.1.4、日常运维管理 8.1.4.1、日常巡检 系统巡检： 制定系统日常巡检计划， 定期对系统进行检查， 确保硬件、 软件、 网络等各个部分正常运行。 巡检内容： 日常巡检应包括服务器状态、存储设备使用情况、数据库性能、网络连通性、安全日志等。 巡检结果应形成报告，定期反馈给相关管理层。 8.1.4.2、日志管理 日志采集与存储： 系统应自动采集并保存各类日志，包括系统日志、安全日志、应用日志等。日志文件应定期 归档并存储，以备问题排查和审计。 日志分析： 运维团队应定期对日志进行分析，发现潜在的系统问题或安全威胁，并及时采取措施处理。 8.1.4.3、数据备份与恢复 定期备份： 制定详细的数据备份计划，确保业务数据、系统配置、数据库等关键数据定期进行备份。备 份应保存在多个位置，并确保备份文件的安全性。 备份验证与恢复测试： 定期对备份数据进行完整性验证， 确保在需要时能够通过备份数据进行恢复。此外， 应定期 进行数据恢复测试，确保在发生数据丢失时，能够快速有效地恢复系统。 8.1.5、系统安全管理 8.1.5.1、用户权限管理 账号与权限管理： 通过严格的用户权限管理， 确保每个用户只能访问与其工作相关的系统模块。 定期审查用户 权限，及时删除无效账号和不必要的权限。 双因素认证： 针对重要的管理角色和敏感操作， 建议启用双因素认证， 提升系统的安全性，防止未授权访 问。 8.1.5.2、漏洞修复与补丁管理 漏洞扫描： 定期对系统进行安全漏洞扫描， 及时发现和修复潜在的安全漏洞， 防止攻击者利用漏洞入侵 系统。 补丁管理： 系统应定期更新安全补丁，尤其是操作系统、数据库、应用软件的补丁。补丁安装前应在测 试环境中进行测试，确保不会影响系统的正常运行。 8.1.5.3、安全审计与应急响应 安全审计： 定期进行安全审计， 检查系统的安全策略是否得到有效实施， 审查安全日志，排查潜在的安 全风险。 应急响应机制： 制定完善的安全应急响应机制，确保在发生安全事件（如数据泄露、系统入侵等）时，能够 及时采取措施， 减少损失并修复问题。 应急响应流程应包括事件通知、 问题处理、 恢复业务、 事后总结与改进等。 8.1.6、问题管理与技术支持 8.1.6.1、问题报告与处理流程 问题报告机制： 用户或系统管理员发现问题时，应通过统一的途径（如工单系统、电话支持、邮件等）报告 问题。问题报告应包括详细的描述、截图、日志等信息，以便技术团队快速定位问题。 问题处理流程： 制定明确的问题处理流程，包括问题的分类、优先级划分、责任人分配、处理时间限制等。 问题的处理过程应全程记录，并在问题解决后形成总结报告，供后续参考。 8.1.6.2、技术支持等级 多级技术支持： 运维方案应根据问题的复杂度和紧急程度，提供多级技术支持（如一级支持、二级支持、第 三方支持等） 。低级问题可以由基础运维人员处理，复杂问题由高级技术团队或第三方供应 商处理。 响应时间与服务级别协议： 制定明确的服务级别协议，包括问题响应时间、处理时限、故障修复时间等。SLA 应根据问 题的严重程度设定不同的响应时间和处理周期， 如紧急问题需在1 小时内响应， 重大故障需 在24 小时内修复。 8.1.7、系统升级与优化 8.1.7.1、系统升级计划 定期升级： 系统应根据业务需求和技术发展定期进行升级。升级计划应包括硬件升级、软件版本更新、 数据库优化等，确保系统能够持续满足业务需求。 升级流程： 系统升级应先经过测试环境验证， 确保升级不会对现有功能和数据产生负面影响。 升级计划 应详细描述升级步骤、备份要求、回滚策略等。 8.1.7.2、性能优化 性能监控与分析： 定期对系统的性能进行分析，识别系统瓶颈（如处理器占用过高、数据库查询过慢等） ，并 提出优化方案。 优化措施： 性能优化措施包括但不限于：数据库索引优化、缓存机制的应用、负载均衡策略的调整、系 统代码的优化等，确保系统在高负载情况下依然能够高效运行。 8.1.8、运维文档与知识库 8.1.8.1、运维文档管理 运维手册： 制定详细的运维手册，包括系统架构说明、日常操作手册、故障排查指南、数据备份与恢复 流程等，确保每个运维人员都能按照规范操作。 变更管理： 所有的系统变更（包括配置修改、系统升级、数据迁移等）都应记录在案，并更新到运维文 档中，确保变更过程透明可追溯。 8.1.8.2、知识库建设 问题与解决方案汇总： 建立运维知识库，记录日常运维过程中遇到的问题和解决方案，供运维团队参考，以便在未 来遇到类似问题时能够快速解决。 持续更新与维护： 知识库应根据系统的变化和运维经验的积累持续更新， 确保其始终具备最新的内容， 帮助运 维团队提高工作效率。 8.2、技术支持服务要求 8.2.1、技术支持服务的目标与原则 8.2.1.1、技术支持服务目标 系统稳定性保障： 确保系统在运行过程中出现问题时， 能够通过技术支持服务得到及时响应和修复， 保障系统 的稳定运行。 业务连续性支持： 在系统发生故障或出现技术问题时， 技术支持服务应确保业务能够尽快恢复， 避免或减少业 务中断的时间。 用户满意度提升： 提供高质量的技术支持， 快速响应和解决用户的技术问题， 提高用户满意度和系统使用体验。 8.2.1.2、技术支持服务原则 响应迅速： 技术支持应根据问题的严重性和优先级，提供快速响应，避免问题长时间得不到处理。 透明与高效： 技术支持流程应透明化，用户能够实时了解问题处理的进展。同时，技术支持应高效，确保 问题在最短时间内得到解决。 持续改进： 技术支持服务应建立反馈机制，不断总结和优化支持流程，提升服务质量。 8.2.2、技术支持服务范围 8.2.2.1、系统范围 应用系统支持： 提供对所有应用系统模块的技术支持，包括功能问题、性能问题、配置错误等。 数据库支持： 提供对系统数据库的技术支持，包括数据库查询优化、数据恢复、性能调优等。 网络与安全支持： 提供对系统网络和安全相关的支持，包括网络连接问题、访问控制、漏洞修复、防火墙配置 等。 硬件支持： 提供对系统运行的硬件环境（如服务器、存储设备、网络设备等）的技术支持，确保硬件故 障能够及时得到处理。 第三方组件支持： 对集成的第三方软件或组件（如应用程序接口、插件、中间件等）提供相应的支持，确保其 能够与系统正常集成和运行。 8.2.2.2、服务内容 故障排查与修复： 提供对系统故障的排查和修复服务，确保系统能够尽快恢复正常运行。 性能优化： 提供对系统性能的优化建议和实施方案，帮助用户解决系统性能瓶颈问题。 配置与操作支持： 提供对系统配置、操作的指导服务，确保用户能够正确配置系统功能， 避免因配置错误导致 问题。 升级与补丁支持： 提供对系统升级、补丁安装等技术支持，确保系统能够顺利更新而不影响业务操作。 8.2.3、技术支持服务级别 8.2.3.1、服务优先级划分 紧急级别： 系统无法正常运行，或出现严重数据丢失、系统宕机等情况，导致业务中断。该级别问题应 优先处理并立即响应。 高优先级： 系统的核心功能部分无法正常使用，但系统仍在运行，业务受影响。 问题应在较短时间内得 到处理。 中优先级： 系统的部分功能存在问题， 但不影响核心业务的正常运行。 该类问题应在合理的时间内进行 修复。 低优先级： 系统存在轻微问题或需要小范围的功能改进，不影响业务操作。应在日常维护中进行处理。 8.2.3.2、响应时间与处理时间 响应时间： 根据问题的优先级，设定技术支持的响应时间。例如： 紧急级别：1 小时内响应。 高优先级：4 小时内响应。 中优先级：1 个工作日内响应。 低优先级：2 个工作日内响应。 处理时间： 设定每个优先级问题的处理时限。例如： 紧急级别：在4 小时内修复或提供临时解决方案。 高优先级：在1 个工作日内修复。 中优先级：在3 个工作日内修复。 低优先级：在5 个工作日内修复或改进。 8.2.3.3、服务可用性要求 全年服务可用性： 技术支持服务应确保全年无间断，具体要求可为7×24 小时支持或5×8 小时（工作日）支 持，根据项目需求设定。 系统可用性保障： 确保系统全年可用性达到99.9%或更高，若系统不可用时间超过约定范围，技术支持团队应 提供具体的补偿措施。 8.2.4 技术支持渠道与沟通机制 8.2.4.1 支持渠道 电话支持： 提供全天候的电话支持服务， 用户可以通过电话直接联系技术支持团队， 报告问题或咨询技 术问题。 电子邮件支持： 用户可以通过电子邮件提交问题，技术支持团队应在规定时间内回复并给出处理方案。 在线工单系统： 提供在线工单系统， 用户可以通过该系统提交问题、 查询问题状态，技术支持团队通过工单 系统进行问题处理和反馈。 即时通讯支持： 在紧急情况下，可通过即时通讯工具进行快速沟通，确保问题能够快速得到响应。 8.2.3.4、沟通机制 定期沟通： 定期与用户进行沟通，包括月度/季度的技术支持会议，回顾已解决的问题、未解决的问题 以及系统的整体运行情况，提出改进建议。 问题处理进度反馈： 在问题处理过程中， 技术支持团队应定期向用户反馈处理进度， 确保用户了解问题的处理状 态。 问题升级机制： 若问题在规定时间内未解决， 用户可以按照明确的升级机制， 将问题升级到更高层的技术支 持或管理层，确保问题能够得到快速处理。 8.2.4、技术支持人员资质与培训 8.2.4.1、技术支持人员资质 专业技术能力： 技术支持团队应具备与系统相关的技术背景，包括操作系统、数据库、网络、安全、应用开 发等领域的专业知识。 认证与培训： 技术支持人员应持有相关技术认证（如操作系统认证、数据库认证等） ，并定期参加培训， 确保能够跟上技术发展和系统更新。 应急处理能力： 技术支持人员应具备较强的应急处理能力， 在系统发生紧急事件时， 能够快速定位并修复问 题。 8.2.4.2、持续培训与知识更新 定期培训： 提供定期培训计划， 确保技术支持团队能够持续学习最新的技术知识和系统功能更新， 提升 技术支持的能力。 知识库建设： 技术支持团队应参与知识库的建设和维护， 将常见问题和解决方案记录在知识库中， 方便快 速查找和复用。 8.2.5、服务报告与审计 8.2.5.1、服务报告 定期服务报告： 技术支持团队应定期提供服务报告，内容包括问题的数量与类型、响应时间、处理时间、未 解决的问题、系统运行状况等。 问题分析与改进建议： 服务报告还应提供对常见问题的分析，提出改进建议，帮助用户优化系统配置和使用。 8.2.5.2、服务审计 服务质量评估： 定期对技术支持服务进行审计评估，检查服务是否达到约定的SLA 标准，包括响应时间、处 理时间、用户满意度等。 用户反馈机制： 建立用户反馈机制， 收集用户对技术支持服务的意见和建议， 并根据反馈不断改进服务质量。 8.2.6、应急支持与保障措施 8.2.6.1、应急支持机制 重大故障应急支持： 在系统发生重大故障时， 技术支持团队应立即启动应急支持机制， 调动各级技术专家进行问 题排查与修复，确保系统能够尽快恢复。 应急预案： 针对可能的系统故障或安全事件，技术支持团队应制定详细的应急预案，包括应急联系人、 处理步骤、责任分工等。 8.2.6.2、备用系统与数据恢复 备用系统： 在关键业务场景下， 提供备用系统支持，确保在主系统发生故障时能够切换到备用系统， 减 少业务中断时间。 数据恢复支持： 在数据丢失或损坏的情况下， 技术支持团队应提供数据恢复服务， 确保系统数据能够及时恢 复，减少业务影响。 8.3、故障恢复与恢复时间要求 8.3.1、故障恢复的目标与原则 8.3.1.1、故障恢复目标 业务连续性保障： 在系统发生故障时， 确保业务恢复的时间和数据恢复的程度能够在可接受的范围内， 尽量降 低业务中断的影响。 数据完整性与一致性保障： 确保在恢复过程中，系统数据能够恢复到故障前的一致性状态，避免数据丢失或损坏。 8.3.1.2、故障恢复原则 快速响应与高效恢复： 故障恢复应遵循快速响应的原则， 利用自动化工具和预定义流程， 尽快恢复系统功能和业务 操作。 预防为主，恢复为辅： 故障恢复机制应优先以预防为主， 尽量减少故障的发生， 并通过合理的备份和冗余机制， 确 保在故障发生时能够快速恢复。 8.3.2、恢复时间目标和恢复点目标 8.3.2.1、恢复时间目标 恢复时间目标： RTO 是指从系统故障到恢复所有功能所允许的最长时间。 恢复时间目标的要求应根据系统的 重要性和业务影响划分： 核心业务系统：恢复时间目标应控制在1 小时以内，确保业务连续性。 次要业务系统：恢复时间目标可适当延长至4 小时。 辅助性系统：恢复时间目标可为24 小时或更长时间，视业务需求而定。 不同故障场景下的恢复时间目标： 对于不同类型的故障（如硬件故障、网络故障、数据损坏等） ，分别设定合理的RTO，确保 各类故障能够在可控时限内恢复。 8.3.2.2、恢复点目标 恢复点目标： 恢复点目标是指在发生故障时，允许系统丢失的最大数据量， 即从故障发生时回溯， 系统需 要恢复到的最近一个数据备份点。根据业务需求划分： 核心业务数据：恢复点目标应为0-15 分钟，确保数据丢失最小化。 次要业务数据：恢复点目标可为1 小时。 辅助性数据：恢复点目标可为24 小时或更长，视业务需求而定。 不同数据类型下的RPO： 关键业务数据（如财务数据、交易数据等）应具备更严格的恢复点目标要求。对于非关键数 据（如日志、临时文件等） ，恢复点目标可适当放宽。 8.3.3、故障恢复流程与应急预案 8.3.3.1、故障分类与应对策略 硬件故障： 如服务器、 存储设备、 网络设备等硬件故障， 技术支持团队应有明确的硬件更换和恢复流程， 包括设备冗余、备用硬件的快速启用等。 软件故障： 如系统崩溃、数据库损坏等软件故障，应有明确的重启、修复和数据恢复流程，确保软件在 最短时间内恢复。 网络故障： 如网络中断或延迟，应有清晰的网络诊断和恢复方案，包括网络切换、负载调整等措施。 安全事件： 如系统遭受攻击或数据泄露，应有应急处理方案，包括隔离受影响的系统、修复漏洞、恢复 数据，同时确保系统安全性得到加强。 8.3.3.2、故障恢复流程 故障识别： 当故障发生时，系统应通过监控和报警机制及时发现问题，并自动通知相关人员。 问题诊断： 技术支持团队应对故障进行初步诊断， 确定问题的根本原因， 并根据故障类型启动相应的恢 复流程。 故障隔离与恢复： 在确认故障后， 团队应隔离故障源头， 防止问题扩大， 并按照预定的恢复方案进行系统恢复。 数据恢复与验证： 恢复系统后，应进行数据恢复操作，将系统状态恢复到故障前的可用状态， 并验证数据的完 整性和一致性。 8.3.3.3、应急预案 应急预案设计： 为不同类型的故障设计详细的应急预案，包括设备故障、网络故障、数据库损坏、灾难性事 件等。应急预案应涵盖每个团队成员的职责分工、恢复步骤、所需资源等。 预案演练： 定期进行应急预案演练， 模拟系统故障场景，确保技术支持团队能够熟练执行预案， 快速恢 复系统功能。 应急联系人： 制定应急联系人列表，明确在紧急情况下的联系人员、联系方式以及应急响应的层级。 8.3.4、数据备份与恢复机制 8.3.4.1、数据备份策略 备份频率： 制定合理的备份频率， 以满足不同业务系统的数据恢复需求。 核心业务系统建议进行实时备 份或每小时备份，次要业务系统可采用每日备份。 备份存储位置： 备份数据应存储在不同物理地点， 确保在发生灾难性事件时， 数据不会因为单一地点的损坏 而丢失。建议采用异地备份或云备份方案。 多层次备份： 采用全量备份和增量备份相结合的策略， 确保数据备份的效率和完整性。 全量备份的频率可 为每周一次，增量备份可为每日或每小时进行。 8.3.4.2、数据恢复流程 备份验证： 定期验证备份数据的完整性， 确保备份数据在恢复时可用， 并且不会出现数据损坏或不一致 的情况。 数据恢复步骤： 制定详细的数据恢复步骤，包括从备份中提取数据、 恢复到系统中的具体操作步骤， 以及恢 复后的数据一致性检查。 恢复测试： 定期进行数据恢复测试，确保备份恢复机制在实际故障情况下能够快速有效地恢复数据。 8.3.5、系统冗余与容灾机制 8.3.5.1、系统冗余设计 硬件冗余： 关键设备（如服务器、存储、网络设备）应具备冗余设计，保证在单个设备故障时，系统能 够自动切换到备用设备，减少业务中断时间。 软件冗余： 关键应用程序、数据库服务等应具备高可用性设计，如主从结构、负载均衡、自动故障转移 等，确保软件故障不会导致整个系统的瘫痪。 网络冗余： 系统应具备双线或多线网络冗余， 确保在单一路由或网络链路故障时， 能够自动切换至备用 网络。 8.3.5.2、容灾方案 本地容灾： 提供本地数据中心内的容灾方案， 通过冗余设备和数据备份， 确保本地服务器和数据存储的 高可用性。 异地容灾： 对于关键业务系统， 应具备异地容灾能力， 通过异地备份和数据同步， 确保在本地数据中心 发生灾难时，可以快速切换到异地系统，保证业务不中断。 容灾演练： 定期进行容灾演练， 测试系统在灾难情况下切换到异地系统的能力， 确保容灾方案在实际场 景中能够有效执行。 8.3.6、故障恢复的监控与优化 8.3.6.1、故障监控 实时监控： 部署故障监控系统， 实时监测系统的健康状况和关键指标 （如处理器、 内存、 存储、 网络等） ， 并在出现异常时及时报警，通知相关人员进行处理。 自动故障检测： 系统应具备自动故障检测能力，如应用程序崩溃、网络延迟、数据库异常等情况，系统应自 动识别并记录，同时触发报警机制。 8.3.6.2、恢复流程优化 故障恢复分析： 每次故障恢复后，技术支持团队应进行详细的恢复流程分析， 评估恢复时间、恢复质量以及 恢复过程中遇到的困难，提供改进建议。 持续优化： 根据恢复分析结果，不断优化故障恢复流程，包括缩短恢复时间、减少数据丢失、提高恢复 自动化程度等。 8.3.7、故障报告与事后总结 8.3.7.1、故障报告 故障报告内容： 每次故障恢复后，应撰写详细的故障报告，内容包括故障发生时间、故障类型、影响范围、 恢复时间、恢复步骤、数据丢失情况等。 报告审查机制： 故障报告应由相关管理层进行审查， 确保所有问题得到彻底分析， 且所有改进措施得到落实。 8.3.7.2、事后总结与改进 事后复盘： 在故障恢复后的适当时间， 组织技术团队进行事后复盘， 分析故障原因、 恢复过程中的问题， 提出改进建议。 改进跟踪： 对于复盘提出的改进建议，应设定明确的责任人和时间表，确保改进措施得到落实， 并通过 定期监控和评估跟踪改进效果。 8.4、系统升级与维护计划 8.4.1、系统升级的目标与原则 8.4.1.1、系统升级目标 功能增强： 通过系统升级，引入新的功能特性和业务需求，持续优化系统性能和用户体验。 安全性提升： 及时进行安全补丁的更新与漏洞修复，保证系统免受新出现的安全威胁。 性能优化： 通过升级优化系统的性能，提升处理速度、响应时间和资源利用率。 8.4.1.2、系统升级原则 最小化业务影响： 系统升级应尽量避免或最小化对生产环境和业务的影响，选择合理的时间窗口进行升级操 作。 稳定性优先： 在进行系统升级前， 应确保新版本已经过充分的测试， 避免因升级引发新的问题或系统不兼 容问题。 回滚机制： 系统升级过程中应具备完善的回滚机制， 确保在升级失败或出现严重问题时， 可以快速恢复 到升级前的状态。 8.4.2、系统升级类型与计划 8.4.2.1、系统升级类型 功能性升级： 对系统功能进行扩展或改进， 引入新的业务模块或功能特性。 如用户界面改进、 新增报表功 能等。 安全性升级： 对系统进行安全补丁的更新和漏洞修复，确保系统免受已知的安全威胁和攻击。 性能优化升级： 对系统的核心性能进行优化升级， 如数据库查询优化、 系统响应速度提升、 资源调度优化等。 平台升级： 升级应用程序所依赖的基础平台，如操作系统、数据库版本、中间件等，以保持系统与底层 平台的兼容性和性能提升。 8.4.2.2、升级计划制定 年度升级计划： 制定年度系统升级计划， 明确每次升级的时间节点、 升级内容和预期目标， 确保系统的升级 工作与业务发展同步。 紧急升级计划： 针对突发的安全漏洞或系统缺陷， 制定紧急升级计划，确保在最短时间内完成升级， 避免系 统遭受攻击或出现重大故障。 定期维护与升级： 系统应进行定期的维护与升级， 建议每季度或每半年进行一次小版本的升级和维护， 确保系 统始终保持在最佳状态。 8.4.3、系统升级流程与步骤 8.4.3.1、升级前准备 升级方案设计： 在每次升级前，应制定详细的升级方案，包括升级的内容、影响范围、可能的风险、回滚方 案等。 升级测试： 在实际升级之前， 应先在测试环境中进行全面的功能测试和性能测试， 验证升级是否存在兼 容性问题、功能缺陷或性能下降等情况。 备份和回滚方案： 升级前应对系统的核心数据、 配置文件、应用程序进行完整备份， 确保在升级失败或出现问 题时能够快速回滚至原状态。 8.4.3.2、升级实施 升级时间窗口： 选择合适的时间窗口进行升级，建议在业务低峰期（如周末、夜间）进行系统升级，以减少 对用户和业务的影响。 监控和验证： 升级过程中应进行实时监控， 确保系统状态正常， 并在升级完成后进行功能验证和性能测试， 确保系统功能正常运行。 用户通知： 在系统升级前， 应提前通知用户和相关业务部门，告知升级的时间、影响范围和预期停机时 间，确保用户提前做好准备。 8.4.3.3、升级后工作 系统验证： 升级完成后，技术团队应对系统进行完整的功能验证，确保所有功能正常，数据完整，性能 无显著下降。 问题跟踪与修复： 若升级后出现问题，应及时跟踪并处理，确保问题在最短时间内得到解决。 用户反馈收集： 升级完成后，收集用户的反馈，评估升级对用户体验和业务的影响，进一步优化升级过程。 8.4.4、系统维护计划 8.4.4.1、维护内容 日常维护： 包括监控系统运行状态、检查日志文件、定期清理无用文件、优化数据库等，确保系统在正 常运行过程中不会出现性能下降或资源不足的问题。 安全维护： 定期进行安全漏洞扫描、安装安全补丁、更新防病毒软件、检查访问控制等，确保系统的安 全性不受外部威胁影响。 性能维护： 定期监控系统的性能指标，包括处理器、内存、磁盘利用率等，及时发现和解决性能瓶颈， 确保系统长期稳定高效运行。 8.4.4.2、维护周期 日常维护：建议每天进行系统运行状态的检查和资源监控。 每周维护：每周进行日志分析、数据库优化、系统健康检查等。 每月维护：每月进行全面的系统性能评估、漏洞扫描、安全检查等。 季度维护：每季度进行一次更大规模的系统优化，包括数据库重组、日志归档、软硬件更新 等。 8.4.4.3、维护工具与自动化 维护工具： 使用自动化运维工具进行系统的日常维护，提升维护效率并减少人工操作的错误。 监控平台： 部署专业的监控平台，对系统的各项指标进行实时监控，并在出现异常时自动报警。 自动化维护任务： 设置自动化的维护任务（如日志清理、磁盘资源管理、定时备份等） ，确保系统维护工作能 够定期执行。 8.4.5、风险控制与回滚机制 8.4.5.1、升级风险评估 风险识别： 在每次升级前， 进行风险识别，列出所有可能影响系统稳定性和业务连续性的风险， 例如兼 容性问题、数据丢失、性能下降等。 风险分级： 对识别出的风险进行分级， 确定风险的严重性和发生概率， 根据风险的等级制定相应的应对 措施。 8.4.5.2、回滚机制 回滚条件： 明确系统回滚的条件， 即在什么情况下需要终止升级并回滚到升级前的版本。 例如系统功能 无法正常运行、数据丢失无法恢复、系统性能大幅下降等。 回滚方案： 制定详细的回滚方案，包括从备份中恢复数据、恢复配置文件、重新部署旧版本应用等，确 保回滚过程能够快速执行。 回滚验证： 回滚完成后，应进行系统的全面验证， 确保在回滚过程中不会出现新的问题，且系统能够恢 复到升级前的状态。 8.4.6、升级与维护的沟通与通知机制 8.4.6.1、升级前通知 提前通知： 在系统升级或维护操作前，至少提前1-2 周通知相关用户和业务部门，说明升级的时间、影 响范围和预期停机时间，确保用户能够提前做好准备。 通知渠道： 通过多种渠道通知用户，如邮件、短信、公告栏、即时通讯工具等，确保所有相关人员能够 及时收到通知。 8.4.6.2、升级后的通知与反馈 升级完成通知： 系统升级或维护完成后，应及时通知相关人员，告知系统已经完成升级并恢复正常运行。 用户反馈机制： 在系统升级完成后，提供用户反馈渠道（如在线工单系统、邮件、电话支持等） ，便于用户 报告升级后遇到的问题或提交建议。 8.4.7、系统升级与维护的报告与审计 8.4.7.1、升级与维护报告 报告内容： 每次系统升级与维护后，撰写详细的报告，内容包括升级/维护的时间、涉及的系统模块、 升级/维护的具体内容、遇到的问题、解决方案、系统验证结果等。 报告分发： 升级与维护报告应分发给相关管理层、 技术团队和业务部门， 确保所有相关方了解升级的结 果和系统状态。 8.4.7.2、升级与维护审计 升级过程审计： 定期对系统的升级和维护过程进行审计，评估升级计划是否合理、 执行是否规范，以及是否 存在未解决的风险或问题。 持续改进： 根据审计结果，提出改进建议，优化升级与维护流程，提升系统的稳定性和安全性。 8.5、系统监控与预警 8.5.1、系统监控的目标与原则 8.5.1.1、系统监控目标 实时掌控系统状态： 通过全面的监控体系，实时掌握系统各个部分的运行状态，确保对系统性能、可用性和安全 性有完整的了解。 快速检测并响应问题： 在系统出现异常时， 监控系统能够快速检测并发出预警， 运维团队能够及时处理，减少故障 对业务的影响。 性能瓶颈识别与优化： 监控系统应帮助运维团队识别系统中的性能瓶颈， 提供数据依据以优化系统资源使用和响应 时间。 8.5.1.2、系统监控原则 全面监控： 系统监控应涵盖所有关键层面，包括硬件资源、网络、应用程序、数据库、存储等，确保监 控的全面性。 实时性与精准性： 监控数据应具备实时性，能够快速反映系统的当前状态，确保预警的准确性和及时性。 自动化与智能化： 监控系统应具备自动化能力， 能够智能分析监控数据， 自动生成预警并根据问题的严重性触 发相应的响应措施。 8.5.2、系统监控范围与监控指标 8.5.2.1、监控范围 硬件监控： 包括服务器的处理器、内存、磁盘、网络带宽等资源使用情况，确保硬件资源无瓶颈或过载 情况。 操作系统监控： 对操作系统的负载、进程、内存使用、磁盘读写、文件系统等进行监控，确保操作系统的正 常运行。 网络监控： 监控网络链路的状态、延时、丢包率、带宽占用情况等，确保网络连接的稳定性和性能。 应用程序监控： 监控应用程序的运行状态、响应时间、吞吐量、并发请求数、错误率等，确保应用程序正常 运行且性能符合预期。 数据库监控： 监控数据库的连接数、查询执行时间、读写性能、并发性、锁等待、缓存命中率等，确保数 据库的性能和响应速度。 存储监控： 监控存储系统的可用空间、读写速度、读写利用率、存储阵列健康状态等，避免存储资源不 足或性能瓶颈。 安全监控： 监控系统的安全威胁，如异常登录尝试、权限变更、恶意代码注入、数据泄露等，确保系统 安全性。 8.5.2.2、监控指标 处理器使用率： 实时监控服务器和虚拟机的处理器使用率，预警处理器过载或闲置的情况。 内存使用率： 监控内存的使用情况，预警内存接近全满或内存泄漏的情况。 磁盘使用率： 监控磁盘的使用空间、I/O 读写速度、磁盘健康状态，预防磁盘满或者I/O 性能瓶颈。 网络延迟与丢包率： 监控网络连接的延迟时间和丢包率，确保网络通信的稳定性。 应用响应时间： 监控关键应用的响应时间，评估应用是否达到性能要求，特别是在高并发情况下的表现。 数据库查询时间： 监控数据库关键查询的执行时间，预警查询过慢或产生大量锁等待的情况。 错误日志与告警日志： 监控系统日志、应用日志、数据库日志等，实时捕捉异常或错误信息，及时预警。 8.5.3、预警机制与响应策略 8.5.3.1、预警级别划分 信息级： 表示系统状态正常但可能有需要关注的情况，通常不需要立即采取行动。 警告级： 表示系统存在潜在问题，可能影响系统性能或稳定性，需要运维团队密切监控并准备应对。 严重级： 表示系统已经出现严重问题或即将发生故障， 可能导致业务中断， 运维团队必须立即采取行 动。 灾难级： 表示系统发生了灾难性故障，业务已经中断或即将中断，需要启动应急预案。 8.5.3.2、预警触发条件 资源使用率超过阈值： 当处理器、内存、磁盘、网络带宽等资源的使用率超过预设阈值（如80%、90%等）时，触 发预警。 响应时间超出设定范围： 当应用、数据库等关键系统的响应时间超出设定的范围（如请求响应时间超过2 秒） ，触发 预警。 错误率或失败率增加： 当应用请求的失败率、 数据库查询的错误率或系统日志中的错误数量超过阈值时， 触发预警。 异常行为检测： 当系统检测到异常的行为模式（如大量的登录失败、 异常的数据传输量等） ，触发安全预警。 8.5.3.3、预警通知机制 通知渠道： 通过多种渠道发送预警通知，包括电子邮件、短信、即时通讯工具、电话呼叫等，确保相关 人员能够及时收到预警信息。 通知分级： 根据预警的严重性级别， 通知不同的人员或团队。对于信息级和警告级，可以通知值班运维 人员；对于严重级或灾难级，需要通知运维主管、业务负责人，甚至高层管理者。 通知频率： 对于长时间未处理的预警，系统应定期重复发送通知，确保问题得到及时关注。 8.5.3.4、响应流程 初步分析： 运维人员在收到预警后，第一步进行初步的故障分析，确认问题的严重性和影响范围。 故障定位与处理： 运维团队根据预警信息快速定位问题的根源，并采取相应的措施进行处理， 如释放资源、 重 启服务、调整参数等。 升级处理： 若问题无法在短时间内解决， 或预警升级为更高严重级别， 运维团队应及时将问题上报至技 术主管或高级技术专家，启动更高级别的处理流程。 故障记录与反馈： 处理完成后，运维团队应做好故障记录和处理反馈，以便后续的分析和改进。 8.5.4、监控工具与平台 8.5.4.1、监控工具选型 开源监控工具： 可选择开源监控工具，根据实际需求进行定制和扩展。 8.5.4.2、监控数据存储与分析 监控数据存储： 监控系统应具备对历史监控数据的存储能力， 确保能够对过去的运行情况进行回溯分析。 建 议将监控数据存储在数据库或分布式存储系统中，保证数据的可扩展性和持久性。 数据分析与可视化： 采用数据分析工具与可视化平台展示系统的监控数据， 帮助运维团队通过图表、 报表等方式 直观了解系统的运行状态，发现潜在问题。 8.5.4.3、自动化运维与自愈机制 自动化响应： 监控系统应支持与自动化运维工具集成，在检测到问题时自动执行修复脚本（如重启服务、 释放资源等） ，实现故障的自动处理。 自愈机制： 在关键系统中，配置自愈机制，当系统检测到某些可预期的问题时，自动进行恢复操作（如 自动切换到备用服务器、重启应用程序、扩展资源等） 。 8.5.5、监控与预警的优化与改进 8.5.5.1、监控策略优化 动态调整监控阈值： 根据系统的运行情况和历史数据， 动态调整监控阈值， 避免因固定阈值设置不合理导致的误 报或漏报情况。 定期评估监控指标： 定期评估监控指标的有效性， 确保监控项能够准确反映系统的运行状态， 减少不必要的监控， 提升监控效率。 8.5.5.2、预警响应优化 预警分级优化： 根据历史预警记录， 分析预警的触发频率和实际影响，调整预警的分级标准，确保严重问题 能够优先得到处理。 响应时间优化： 分析预警的响应时间和处理效率， 优化故障响应流程，提升运维团队的处理速度，减少问题 对业务的影响。 8.5.5.3、预警日志与报告 预警日志记录： 记录所有预警的详细日志，包括预警时间、触发条件、处理过程、响应时间等，便于后续分 析和改进。 预警报告： 定期生成预警报告，分析各类预警的发生频率、问题根源、处理时间等数据，帮助运维团队 识别系统中的薄弱环节，制定优化方案。 8.6、保障连续运营的措施 8.6.1、业务连续性保障目标与原则 8.6.1.1、连续性保障目标 业务不中断： 在发生故障或灾难时，确保系统能够以最短的时间恢复，尽量减少对业务的影响。 数据不丢失： 确保在任何情况下，业务数据的完整性和一致性，避免因系统故障导致数据丢失或损坏。 快速恢复与可用性提升： 提供快速恢复机制，确保系统能够在紧急情况下迅速恢复运行，提升系统的可用性。 8.6.1.2、连续性保障原则 高可用性设计： 系统架构设计应遵循高可用原则， 通过冗余设计、负载均衡等手段， 确保一个或多个组件出 现故障时，其他组件能继续提供服务。 数据同步与备份： 采用实时或定期的数据同步与备份机制，确保在发生故障时，能够迅速恢复到最近的状态， 避免数据丢失。 自动化与标准化响应： 制定标准化的应急响应流程， 并尽可能通过自动化手段执行， 减少人为操作带来的延误和错 误。 定期演练与优化： 定期进行灾难恢复演练，通过不断优化和调整，确保应急预案和恢复策略的有效性。 8.6.2、高可用性与冗余设计 8.6.2.1、系统架构冗余设计 硬件冗余： 关键硬件设备（如服务器、存储、网络设备等）应具备冗余设计，确保某个硬件设备发生故 障时，其他设备能够迅速接替任务，避免单点故障。 网络冗余： 网络架构应具备多链路冗余设计， 采用多条网络路径进行通讯， 防止网络中断或链路故障导 致业务中断。 应用层冗余： 关键应用和服务应采用多实例部署， 结合负载均衡和自动故障转移机制， 确保当某一实例出 现问题时，其他实例能继续提供服务。 8.6.2.2、数据冗余与备份机制 实时数据同步： 通过数据复制或实时同步机制， 确保生产环境的数据能够实时复制到备份环境中， 保证数据 在主系统出现故障时可以快速切换到备用系统。 定期备份： 制定明确的数据备份计划， 定期对核心业务数据进行完整备份， 并确保备份数据存储在异地 或云端，防止单一数据中心灾难导致数据无法恢复。 备份完整性检测： 定期进行备份数据的完整性检测， 确保备份数据在恢复时能够正常使用， 不会因数据损坏或 不完整导致恢复失败。 8.6.2.3、自动故障转移与切换机制 自动故障检测： 通过实时监控和健康检查机制，自动检测系统中各组件的健康状态，识别故障或异常情况。 自动故障切换： 当检测到某一组件出现故障时， 系统应具备自动切换机制， 能够将流量或任务自动转移到备 用组件或节点，确保业务不中断。 多数据中心切换： 系统应支持在多个数据中心之间进行业务切换， 保证在一个数据中心出现大规模故障时， 业 务能够迅速切换到另一个数据中心继续运行。 8.6.3、灾难恢复计划 8.6.3.1、灾难恢复目标 恢复时间目标： 定义系统从故障发生到恢复正常运行的目标时间， 确保在该时间内能够恢复业务功能， 最小 化业务中断时间。 恢复点目标： 定义系统故障发生后可以接受的最大数据丢失时间， 确保在灾难恢复时， 数据的丢失量不超 过业务可接受的范围。 8.6.3.2、灾难恢复策略 异地灾备： 设置异地灾备中心，确保当主数据中心发生灾难（如火灾、地震等）时，异地灾备中心能够 接管业务，保障业务的连续性。 云灾备： 采用云灾备方案，将关键系统和数据备份至云端，确保即使本地数据中心完全不可用时， 仍 然可以通过云端恢复业务。 冷备、热备与容灾： 根据业务的连续性要求，选择合适的灾备模式： 冷备：灾难发生后手动启动备用系统，恢复时间较长，适合对恢复时间要求不高的场景。 热备：实时数据同步，备用系统始终处于可用状态，能够快速切换，适合对业务连续性要求 较高的场景。 容灾：主备系统同时运行，确保当主系统出现故障时，备份系统可以无缝接管业务。 8.6.3.3、灾难恢复演练 定期演练： 每年至少进行一次全面的灾难恢复演练， 模拟各种可能的故障场景， 验证灾备方案的可行性 和恢复速度。 演练评估与优化： 在演练后进行详细的评估，记录每个恢复步骤的执行情况、所用时间和遇到的问题， 提出改 进建议，不断优化灾难恢复计划。 8.6.4、应急响应与故障处理流程 8.6.4.1、应急响应计划 应急响应小组： 建立专门的应急响应小组， 明确各成员的职责和分工， 确保在发生故障时能够迅速组织和响 应。 故障分级处理： 根据故障的严重程度，将故障分为不同的级别（如严重、重要、一般） ，并制定相应的处理 流程和响应时间。 应急预案启动条件： 明确应急预案的启动条件，当系统出现重大故障、数据丢失、业务中断等情况时，立即启动 应急预案，进行应急处理。 8.6.4.2、故障处理流程 故障检测与报告： 通过监控系统实时检测故障或异常情况，运维人员或自动化系统应在故障发生后立即报告， 并启动故障处理流程。 故障定位与修复： 运维团队应迅速定位故障原因，分析故障的影响范围，并及时采取修复措施，确保故障得到 快速解决。 故障通知与升级： 在故障处理过程中， 根据故障的严重性，及时通知相关业务部门和管理层， 并在必要时将故 障升级为高级别处理，调动更多资源进行修复。 故障恢复与验证： 故障处理完成后，进行全面的系统验证，确保业务功能恢复正常， 并确认没有数据丢失或其 他潜在问题。 8.6.4.3、故障记录与分析 故障记录： 对每次故障进行详细记录，包括故障发生时间、影响范围、处理过程、恢复时间等，形成故 障报告。 故障分析与改进： 定期对故障记录进行分析， 查找故障的根本原因， 提出系统改进建议， 减少同类故障的发生。 8.6.5、自动化恢复与自愈机制 8.6.5.1、自动化故障检测与切换 自动化故障检测： 通过监控系统和智能化分析工具，实时检测系统的健康状态，及时识别潜在的故障风险。 自动化业务切换： 在检测到系统故障时， 自动化系统应能够根据预先设定的策略， 自动将业务切换到备用系统 或数据中心，减少人工干预，提高恢复速度。 8.6.5.2、自愈机制 自动修复机制： 系统应具备自愈能力， 能够在故障发生时自动尝试修复常见问题 （如重启服务、 释放资源等） ， 避免小问题演变为大故障。 智能化故障分析： 通过机器学习等智能技术， 分析系统的运行数据和故障模式， 预测可能发生的故障并提前采 取预防措施。 8.6.6、业务连续性评估与优化 8.6.6.1、业务连续性评估 定期评估： 定期对系统的业务连续性保障措施进行评估，分析系统的恢复能力、应急响应速度， 确保能 够满足业务需求。 关键指标评估： 评估业务连续性的关键指标， 如恢复时间目标和恢复点目标， 确保这些指标与业务需求保持 一致。 8.6.6.2、持续优化 优化冗余设计： 根据业务需求的变化， 动态调整系统的冗余设计， 确保系统资源的合理利用和故障切换的有 效性。 改进灾备与恢复流程： 根据灾难恢复演练的结果以及故障处理记录， 定期优化灾备和恢复流程， 提升系统的恢复能 力。 九、验收标准 在本项目的验收阶段， 中标供应商应全力配合建设方或建设方委托的系统评测方， 完成全面 的系统验收工作。供应商需提供必要的技术支持、详细的文档资料以及相关资源，确保验收 过程顺利进行。 双方应依据既定的验收标准和测试计划， 逐项验证系统的功能完整性、正确 性、 稳定性、 性能、 安全性及用户体验等各项指标， 确保系统完全满足项目需求和质量要求。 在整个验收过程中， 供应商需积极回应评测方的测试需求，及时解决发现的问题，并协助进 行缺陷修复和回归测试。最终，经过全面的评估与确认，双方将签署验收确认书，正式完成 系统验收，标志着项目的顺利交付与实施。 9.1、功能验收标准 9.1.1、功能验收基本原则 9.1.1.1、完整性 功能的全面性： 系统应实现所有需求文档或技术规格书中明确的功能， 且每个功能模块均能正常运行， 没有 缺失或遗漏。 功能点覆盖率： 确保系统实现了每一项既定的功能点，功能点的覆盖率应达到100%。 9.1.1.2、正确性 功能操作的正确性： 系统的所有功能应按预期工作，用户操作各个功能时能获得正确的输出结果，且逻辑无误。 业务流程的正确性： 系统应严格按照定义的业务流程工作，确保用户操作流程的正确性与一致性。 9.1.1.3、稳定性 功能稳定性： 系统应在各种环境和场景下保持功能的稳定性， 避免因操作频繁或并发量大导致功能失效或 崩溃。 9.1.1.4、响应时间与性能 功能响应速度： 每项功能的响应时间应符合性能要求， 确保用户在合理时间范围内完成操作， 避免出现长时 间的响应延迟。 性能要求： 功能在高负载或并发情况下， 仍应保持较高的性能表现， 避免因为过多用户同时使用导致业 务操作变慢或失败。 9.1.2、功能验收范围 9.1.2.1、核心业务功能验收 核心业务流程： 验收系统的核心业务流程，确保其按业务需求正常运行。 输入与输出的准确性： 核心功能的输入和输出数据应经过严格测试，确保数据的有效性、准确性和一致性。 9.1.2.2、辅助功能验收 辅助功能模块： 对各辅助功能模块（如报表功能、用户管理、权限控制等）进行验收，确保这些功能能够顺 利支持核心业务的运作。 边缘功能验证： 对一些边缘功能（如帮助页面、系统通知等）进行验证，确保用户体验完整，系统使用无障 碍。 9.1.2.3、安全功能验收 用户登录与身份验证： 验收系统的用户认证和授权功能， 确保登录、注册、 权限管理等安全功能能够有效防止未授 权访问和数据泄露。 数据加密与传输安全： 验证数据加密功能是否按要求实现，敏感信息的存储与传输是否符合安全标准。 9.1.2.4、兼容性验收 多平台兼容性： 验收系统在不同操作系统、浏览器、设备（如电脑、手机、平板等）上的兼容性，确保系统 在不同平台上都能正常运行。 9.1.3、功能验收测试方式 9.1.3.1、单元测试 模块级功能测试： 验收每个功能模块的单元测试结果， 确保各模块能够独立正常运行， 且其输入输出符合预期。 错误处理与边界条件测试： 针对每个功能模块的边界条件、异常输入、 极限操作等情况进行测试， 确保系统能够适应各 种极端操作，并能正确处理异常情况。 9.1.3.2、集成测试 模块集成验收： 验收系统中各功能模块的集成情况， 确保各模块之间的接口和数据交换能够无缝衔接， 模块 间依赖的功能能够顺利完成。 业务流程测试： 通过模拟实际业务操作流程， 验证整个系统的功能是否按预期顺畅进行， 从输入到输出全过 程无误。 9.1.3.3、用户验收测试 用户场景测试： 邀请实际用户或业务代表参与验收测试， 验证系统在真实场景下的功能表现是否符合业务需 求。 用户体验与反馈： 收集用户在实际操作中的体验和反馈， 确保系统的功能符合用户的操作习惯和期望， 并根据 反馈进行必要的调整。 9.1.4、功能验收通过标准 9.1.4.1、验收通过条件 全部功能完成并正常运行： 所有需求文档中定义的功能必须全部完成并能够正常运行，且无重大错误或功能缺失。 无严重BUG 或阻塞性问题： 系统在验收过程中不得出现严重影响业务流程的BUG，且所有阻塞性问题必须在验收前修 复。 通过所有测试案例： 系统中的所有功能都应通过事先制定的测试案例，确保功能的正确性和完整性。 9.1.4.2、验收失败条件 核心功能缺失或功能不全： 如果系统的核心功能未实现或功能不全，导致无法完成业务流程，则验收失败。 严重BUG 或频繁崩溃： 如果系统存在严重的BUG 或频繁崩溃，影响用户的正常操作，则验收失败。 未通过关键测试案例： 如果系统未通过某些关键的测试案例，导致重要业务无法顺利完成，则验收失败。 9.1.5、功能验收报告 9.1.5.1、验收测试结果记录 测试案例执行情况： 记录每个测试案例的执行结果， 包括通过与失败的情况， 并针对失败的案例给出详细的描述 和原因分析。 BUG 记录与修复情况： 记录验收过程中发现的所有BUG 及其修复情况，确保在验收结束前，所有严重BUG 都已修 复或有明确的修复时间表。 9.1.5.2、验收评估报告 验收评估总结： 对整个验收过程进行评估总结， 确认系统是否达到了既定的功能需求， 是否可以进入下一阶 段（如上线或交付） 。 用户反馈报告： 如果进行了用户验收测试， 应记录用户的反馈意见和建议， 并对系统功能的符合性进行综合 评估，提出改进建议。 9.1.5.3、验收签字确认 各方确认签字： 验收完成后， 所有相关方 （包括开发方、 测试方、 用户方） 应对功能验收结果进行签字确认， 确认系统功能已经通过验收。 9.2、性能验收标准 9.2.1、性能验收目标与原则 9.2.1.1、性能验收目标 系统响应速度： 验证系统在不同负载下的响应时间， 确保用户能够在合理时间内完成操作， 系统不会因为负 载增加而导致显著延迟。 系统处理能力： 验证系统的最大并发处理能力， 确保系统能够应对高并发场景， 支持一定数量的同时用户访 问而不影响性能。 资源使用效率： 验证系统在正常和高负载情况下对资源（如处理器、内存、磁盘、网络）的使用率，确保资 源使用合理，避免过度消耗。 系统扩展性： 验证系统的扩展能力， 确保系统能够根据业务需求的增长， 通过水平或垂直扩展来提升性能， 避免性能瓶颈。 9.2.1.2、性能验收原则 实用性与合理性： 性能验收应基于实际业务需求，验证系统能够在真实场景下满足性能要求。 负载测试与压力测试结合： 性能测试应包括正常负载下的测试和超负荷状态下的压力测试， 确保系统能在不同负载条件 下保持稳定性。 准确性与可重复性： 测试结果应准确可靠，且测试场景能够重复，确保每次测试的结果具有一致性。 9.2.2、性能验收范围 9.2.2.1、响应时间验收 页面加载时间： 测试系统各类页面的加载时间， 确保页面加载时间符合预期标准， 通常情况下应在2 秒内完 成，重要操作页面（如支付、登录、查询等）应在1 秒内完成。 事务处理时间： 验证核心业务事务（如订单提交、付款、数据查询等）的处理时间，确保在高并发情况下， 核心业务操作能在合理范围（如2 秒内）内完成。 应用程序接口响应时间： 测试系统各类应用程序接口的响应时间，确保每个应用程序接口调用在规定时间内返回数 据，一般要求应用程序接口响应时间不超过500 毫秒。 9.2.2.2、并发处理能力验收 并发用户数： 测试系统在并发用户数达到一定量（如500、1000、5000）的情况下，能否保持正常运行， 并确保响应时间不显著增加。 最大并发连接数： 测试系统的最大并发连接数，确保系统能够在高并发场景下处理所有请求而不出现连接超 时、服务不可用等问题。 9.2.2.3、吞吐量验收 每秒处理事务数： 测试系统在单位时间内能够处理的事务数量， 尤其是核心业务的每秒处理事务数 （如订单处 理、数据存储等） ，确保系统能够在高峰期处理大量的用户请求。 每秒请求数： 验证系统在每秒能够处理的请求数量， 确保系统在高并发访问时， 能够处理足够多的请求而 不丢失请求或延时过长。 9.2.2.4、资源使用率验收 处理器使用率： 测试系统在不同负载下的处理器使用情况， 确保在高负载情况下， 处理器使用率不超过80%， 避免出现处理器过载导致的性能瓶颈。 内存使用率： 验证系统在不同负载下的内存使用情况， 确保内存使用合理， 避免内存泄漏或内存过度占用。 磁盘读写使用率： 测试系统在高并发读写条件下的磁盘读写使用率， 确保系统能够在高负载下保持稳定的磁盘 读写性能，避免因读写瓶颈导致响应延迟。 网络带宽使用率： 验证系统在高负载下的网络使用情况， 确保网络带宽的利用率保持在合理范围， 避免因带宽 不足导致网络请求延迟或丢失。 9.2.3、性能测试方式与工具 9.2.3.1、性能测试方式 基准测试： 对系统进行基准测试，测量系统在标准条件下的性能表现，确定系统的基本性能指标，为后 续的负载和压力测试提供参考。 负载测试： 在系统正常运行状态下， 逐步增加负载至接近最大设计负载， 测试系统在不同负载下的响应 时间、吞吐量和资源使用率，确保系统性能符合预期。 压力测试： 对系统施加超出正常负载的压力， 测试系统在极限负载下的表现， 观察系统是否能够在高压 下保持稳定，及其在崩溃后是否能够正常恢复。 容量测试： 测试系统在不同硬件配置或架构扩展下的性能表现， 确定系统的扩展能力， 确保系统在硬件 资源增加时能够线性提升性能。 稳定性测试： 对系统进行长时间的稳定性测试， 验证系统在持续负载下是否能够保持稳定运行， 避免长时 间运行导致的性能下降或资源泄漏。 9.2.4、性能验收通过标准 9.2.4.1、性能通过条件 响应时间符合要求： 所有关键操作和页面的响应时间必须符合预先设定的要求 （如页面加载时间不超过2 秒， 核 心操作响应时间不超过1 秒） 。 并发处理能力符合要求： 系统在验收过程中应能够处理指定的并发用户数， 并且在高并发情况下， 响应时间和吞吐量 不会显著下降。 吞吐量符合业务需求： 系统的吞吐量（如每秒处理的事务数或请求数） 应满足业务峰值需求， 确保在业务高峰期间 能够处理所有请求。 资源使用率合理： 在不同负载条件下， 系统的处理器、 内存、 磁盘读写和网络带宽的使用率应保持在合理范围， 避免性能瓶颈和资源过度使用。 稳定性通过验证： 系统在高负载和长时间运行情况下应保持稳定， 避免因负载过大或资源泄漏导致系统崩溃或 性能急剧下降。 9.2.4.2、性能失败条件 响应延迟过长： 如果系统的响应时间超出规定的上限（如页面加载时间超过2 秒，核心事务处理时间超过1 秒） ，则性能验收失败。 并发处理能力不达标： 如果系统在并发情况下无法处理指定的用户数， 或者出现连接超时、服务不可用等问题， 则 性能验收失败。 资源使用率过高： 如果系统在正常负载下的资源使用率（如处理器、内存、I/O 等）超过80%，且没有优化空 间，则性能验收失败。 系统崩溃或不稳定： 如果系统在压力测试中频繁崩溃， 或者长时间运行后性能明显下降，无法保持稳定性，则性 能验收失败。 9.2.5、性能验收报告 9.2.5.1、性能测试结果记录 测试案例执行情况： 记录每个性能测试案例的执行结果，包括响应时间、并发处理能力、吞吐量、资源使用率等 指标的详细数据。 性能瓶颈与优化记录： 记录性能测试中发现的性能瓶颈（如处理器过载、内存泄漏、读写瓶颈等） ，并给出相应的 优化建议和解决方案。 9.2.5.2、性能评估报告 总体性能评估： 对系统的整体性能表现进行评估， 确认系统在不同负载条件下的性能是否满足业务需求和技 术规格要求。 性能优化建议： 如果系统在某些方面未能达到性能要求， 应在报告中提供详细的优化建议， 包括调整硬件配 置、优化代码、调整架构等。 9.2.5.3、验收签字确认 各方确认签字： 性能验收完成后，所有相关方（包括开发方、测试方、用户方）应对性能验收结果进行签字 确认，确认系统性能已经通过验收。 9.3、安全性验收标准 9.3.1、安全性验收目标与原则 9.3.1.1、安全性验收目标 系统防护： 确保系统能够有效抵御常见的安全威胁，包括但不限于数据库注入、跨站脚本攻击、 跨站请 求伪造、拒绝服务攻击等。 数据保护： 确保用户数据和系统敏感信息的安全，防止数据泄露、篡改和未授权访问。 访问控制： 验证系统的身份验证和权限管理机制，确保只有经过授权的用户才能访问特定功能和数据。 9.3.1.2、安全性验收原则 最小权限原则： 系统应遵循最小权限原则， 确保每个用户仅有其职责范围内的访问权限， 避免权限过大导致 的安全隐患。 加密传输与存储： 系统中所有敏感数据的传输和存储应使用加密技术， 确保数据在传输和存储过程中不会被窃 取或篡改。 漏洞防护与修复： 系统应具备良好的漏洞防护机制，能够及时发现并修复安全漏洞，确保系统处于安全状态。 9.3.2、安全性验收范围 9.3.2.1、身份验证验收 强密码策略： 验证系统是否强制用户使用强密码， 包括密码长度、 复杂性 （大小写字母、 数字、 特殊字符） 、 定期更改密码等。 两因素认证： 如果系统要求更高的安全性， 验证是否实现了两因素认证， 确保用户在登录时需要通过额外 的身份验证（如手机短信、电子邮件验证码、认证软件等） 。 账户锁定与重设密码： 验证系统在用户多次失败登录后是否会自动锁定账户， 并确保密码重设流程安全， 避免被恶 意利用。 9.3.2.2、权限管理验收 角色与权限分配： 验证系统是否具备完备的角色与权限管理机制，确保权限的分配和管理可以按用户角色进 行，且每个角色的权限范围符合业务规则。 权限边界检查： 测试用户在其权限范围外的功能访问，确保用户无法访问未授权的功能或数据。 超级管理员权限控制： 验证是否对超级管理员权限有严格的控制和监控，避免超级管理员权限被滥用。 9.3.2.3、数据保护验收 数据加密： 验证系统是否对敏感数据（如用户密码、支付信息、个人身份信息等）进行加密存储，确保 这些数据即使在数据库泄漏的情况下也不会被轻易破解。 加密传输： 验证系统是否使用超文本传输安全协议或其他加密协议传输敏感信息， 确保在传输过程中不 会被窃取或篡改。 敏感信息脱敏展示： 验证系统对敏感信息的展示是否进行了脱敏处理（如部分遮盖银行卡号、身份证号等） ，确 保敏感信息不会在界面上被完全暴露。 9.3.2.4、漏洞防护验收 常见漏洞防护： 验证系统是否具备防护常见安全漏洞的机制，包括： SQL 注入：验证是否对用户输入进行了严格的过滤和转义，防止SQL 注入攻击。 跨站脚本：确保系统对输入输出数据进行了适当的编码，防止用户注入恶意脚本。 跨站请求伪造： 验证是否对关键操作 （如用户数据修改、 支付等） 进行了跨站请求伪造防护。 文件上传漏洞： 验证系统是否对文件上传功能进行了严格的文件类型检查和安全处理， 防止 恶意文件的上传和执行。 拒绝服务攻击防护： 验证系统是否具备防护拒绝服务攻击防护攻击的机制， 例如通过限流、 IP 地址封禁等技术手 段，避免系统因流量过大而不可用。 9.3.2.5、审计与监控验收 操作日志记录： 验证系统是否记录了所有关键操作日志（如登录、登出、权限更改、数据修改等） ，确保在 发生安全事件时能够追溯操作记录。 异常行为监控： 验证系统是否具备监控异常行为的功能（如频繁的登录失败、权限越界访问等） ，并能及时 报警或采取防护措施。 日志保护与存储： 验证系统的日志是否经过妥善保护， 确保日志不会被篡改或删除， 且日志存储符合合规要求。 9.3.2.6、安全合规验收 法律法规遵从： 验证系统是否符合相关法律法规的要求 行业安全标准遵从： 如果系统属于特定行业（如金融、电商、医疗等） ，需要验证系统是否符合该行业的安全标 准，确保业务敏感数据的安全。 9.3.3、安全性测试方式与工具 9.3.3.1、安全性测试方式 渗透测试： 通过模拟攻击者的角色， 对系统进行渗透测试， 发现可能的安全漏洞， 并验证系统的安全防 护措施是否有效。 漏洞扫描： 使用漏洞扫描工具对系统进行扫描， 发现并记录系统中存在的已知安全漏洞， 确保系统没有 暴露在常见的安全漏洞之下。 代码审计： 对系统的源代码进行审计， 分析代码中可能存在的安全漏洞， 特别是对用户输入的处理和对 敏感信息的保护，需中标单位提供第三方代码审计报告。 安全配置审查： 对系统的安全配置进行审查，确保服务器、数据库、网络设备等的配置符合安全最佳实践， 不存在弱口令、默认配置等安全隐患。 9.3.4、安全性验收通过标准 9.3.4.1、安全性通过条件 无重大安全漏洞： 系统中不存在严重的安全漏洞，如高危的数据库注入、跨站脚本攻击等漏洞，一旦发现这些 漏洞，必须在验收前修复。 数据加密与隐私保护符合要求： 系统中的数据加密措施和用户隐私保护措施应符合预定要求， 确保敏感数据在传输和存储过 程中不会被泄露。 身份验证与权限管理严格： 系统的身份验证和权限管理机制应严格执行， 确保只有经过授权的用户才能访问特定功能和 数据，且权限控制符合最小权限原则。 审计与监控机制健全： 系统的操作日志记录和异常行为监控机制应健全， 确保能够追踪用户操作并及时发现和应对 异常行为。 9.3.4.2、安全性失败条件 存在严重安全漏洞： 如果系统存在严重的安全漏洞， 特别是影响数据安全和系统稳定性的漏洞， 则安全性验收失 败。 加密与隐私保护不足： 如果系统对敏感数据的加密和隐私保护措施不足， 导致数据泄露风险过高， 则安全性验收失 败。 权限管理不严格： 如果系统的权限管理机制存在漏洞， 导致用户可以访问未授权的功能或数据， 则安全性验收 失败。 缺乏日志审计或监控机制： 如果系统缺乏完善的日志审计或异常行为监控机制，无法有效追踪用户操作或发现安全事 件，则安全性验收失败。 9.3.5、安全性验收报告 9.3.5.1、安全测试结果记录 漏洞记录与修复情况： 记录在安全测试中发现的所有漏洞及其修复情况， 确保在验收结束前， 所有重大漏洞都已修 复或有明确的修复计划。 测试案例执行情况： 记录所有安全性测试案例的执行结果，确保所有的测试案例（如渗透测试、漏洞扫描等）都 已通过。 9.3.5.2、安全评估报告 整体安全评估： 对系统的整体安全性进行评估， 确认系统是否达到了预期的安全防护目标， 并符合安全标准 和合规要求。 安全优化建议： 如果系统存在一些潜在的安全隐患或改进空间， 应在报告中提出优化建议， 帮助系统进一步 提升安全性。 9.3.5.3、验收签字确认 各方确认签字： 安全性验收完成后，所有相关方（包括开发方、测试方、用户方）应对安全性验收结果进行 签字确认，确认系统安全性已经通过验收。 9.4、系统集成验收标准 9.4.1、系统集成验收目标与原则 9.4.1.1、系统集成验收目标 数据流通与交换： 验证系统能够与其他系统进行正确的数据交换，确保数据传输的完整性与一致性。 接口的正确性与稳定性： 确保系统各个接口（应用程序接口、网页服务、文件传输等）能够按预期调用，并返回正确 数据，无错误或超时情况。 系统协调工作： 验证系统与外部系统协同工作时，能够正确执行业务流程，实现预期功能。 9.4.1.2、系统集成验收原则 一致性与兼容性： 系统集成应确保数据格式、通信协议、 字符编码等方面的一致性， 避免因不兼容性导致数据 丢失或功能异常。 高可用性与稳定性： 系统在集成过程中应保持高可用性和稳定性， 在高并发或复杂业务场景下， 确保系统集成的 可靠性。 可追溯性与日志记录： 系统集成的过程应有详细的日志记录， 确保在集成出现问题时， 能够快速定位问题并进行修 复。 9.4.2、系统集成验收范围 9.4.2.1、数据集成验收 数据格式一致性： 验证不同系统之间的数据格式是否一致， 确保在数据交换过程中， 数据的转换和处理符合预 期要求。 数据传输完整性： 验证系统在数据传输过程中是否保证了数据的完整性，确保传输的数据不会丢失或篡改。 数据同步： 验收系统与其他系统之间的数据同步机制， 确保数据在各系统中保持一致， 避免由于数据不 同步导致的业务逻辑错误。 9.4.2.2、接口集成验收 接口调用正确性： 验证系统能够正确调用其他系统的接口 （应用程序接口） ， 并确保接口返回的数据正确无误。 接口安全性： 验证接口调用过程中是否使用了安全机制， 确保接口的调用是安全的， 防止未经授权的访问。 接口超时与重试机制： 验证系统在调用接口时是否有超时处理和重试机制， 确保接口调用失败时系统仍能保持业务 的连续性。 9.4.2.3、系统间通信验收 通信协议： 验证系统与其他系统之间的数据通信协议是否一致， 确保不同系统之间的通信顺畅， 避免因 协议不一致导致的通信失败。 字符编码和语言兼容性： 验证系统在集成时是否考虑了字符编码和多语言环境下的兼容性， 确保不同语言和字符集之 间的数据交换正确无误。 9.4.2.4、应用集成验收 业务流程整合： 验证系统能够与其他应用系统整合， 实现跨系统的业务流程自动化， 确保业务流程的无缝衔 接。 跨系统事务处理： 验收跨系统的事务处理机制，确保业务流程在跨系统的情况下能够保持事务一致性和完整 性，特别是对于分布式事务的处理。 9.4.2.5、性能与负载验收 接口响应时间： 验证系统在调用其他系统接口时的响应时间是否符合要求， 确保在高并发情况下， 接口的响 应时间不会对系统整体性能造成影响。 系统集成的负载能力： 验收系统集成在高负载情况下的性能表现， 确保系统在大量数据交换和接口调用的情况下依 然能够保持稳定运行。 9.4.2.6、异常处理与容错机制验收 异常处理机制： 验证系统在集成过程中出现错误或异常时， 是否有完善的异常处理机制， 确保系统能够正确 处理错误并生成相应的日志。 容错与恢复机制： 验证系统是否具备容错能力， 在集成过程中出现部分系统或服务不可用的情况下， 系统是否 能够正确恢复并继续运行，或采取必要的降级策略。 9.4.3、系统集成测试方式与工具 9.4.3.1、系统集成测试方式 集成测试： 对系统与其他子系统或外部系统的集成进行功能性测试， 确保数据交换、 功能调用和业务流 程的正确性。 接口测试(应用程序接口测试)： 使用自动化测试工具进行接口测试，验证接口的功能、性能、安全性和异常处理，确保接口 能够按预期工作。 消息队列与异步处理测试： 如果系统使用消息队列进行异步处理， 测试消息的发送、 接收和处理是否符合预期， 确保消 息不会丢失或重复处理。 跨系统事务测试： 对跨系统的事务处理进行测试， 确保分布式事务能够在多个系统之间保持一致性， 避免数据 不一致或事务失败。 9.4.4、系统集成验收通过标准 9.4.4.1、系统集成通过条件 无数据丢失或篡改： 系统在数据交换过程中应确保数据的完整性和一致性， 任何数据丢失、 篡改或错误传输都被 视为集成失败。 接口调用成功率高： 系统的接口调用成功率应达到99%以上， 且接口响应时间符合预期要求， 确保系统在高并发 情况下能够稳定运行。 异常处理机制健全： 系统应具备完善的异常处理机制， 确保在集成过程中出现错误时能够快速恢复并生成相应的 日志记录。 跨系统事务一致性： 系统应确保跨系统事务的一致性，特别是分布式事务在多个系统之间的协调处理应保持一 致，避免数据不一致或事务失败。 9.4.4.2、系统集成失败条件 数据传输错误： 如果系统在数据传输过程中出现数据丢失、 篡改或错误， 导致业务逻辑无法正常执行，则集 成验收失败。 接口调用失败或超时频繁： 如果系统在接口调用过程中频繁发生失败或超时， 影响系统集成的稳定性， 则集成验收失败。 事务处理不一致： 如果跨系统的事务在多个系统之间无法保持一致性， 导致数据的不一致或业务流程中断， 则 集成验收失败。 缺乏容错与恢复能力： 如果系统在集成过程中出现部分服务不可用时无法正确恢复， 且没有容错机制， 则集成验收 失败。 9.4.5、系统集成验收报告 9.4.5.1、集成测试结果记录 测试案例执行情况： 记录每个集成测试案例的执行结果，包括数据传输、 接口调用、 跨系统事务处理等方面的详 细测试数据。 问题记录与修复情况： 记录集成测试中发现的问题及其修复情况， 确保在验收结束前， 所有集成问题都已修复或有 明确的修复计划。 9.4.5.2、集成评估报告 系统集成评估： 对系统集成的整体表现进行评估， 确认系统在数据交换、 接口调用、 业务流程整合等方面的 表现是否达标。 性能与兼容性评估： 如果系统在集成过程中涉及多种平台或环境， 应对系统的性能和兼容性进行评估， 确保系统 集成在不同环境下都能正常运行。 9.4.5.3、验收签字确认 各方确认签字： 系统集成验收完成后，所有相关方（包括开发方、测试方、用户方）应对集成验收结果进行 签字确认，确认系统集成已经通过验收。 9.5、系统使用体验验收标准 9.5.1、系统使用体验验收目标与原则 9.5.1.1、系统使用体验验收目标 易用性： 确保系统界面清晰易懂，系统使用能够方便、快速地找到并使用所需的功能。 美观性： 确保系统界面设计美观，布局合理，符合当前的设计趋势，提升系统使用的视觉愉悦感。 交互设计： 确保系统的交互流程流畅，系统使用操作顺畅，避免不必要的复杂步骤或点击。 响应速度： 确保系统在系统使用操作时响应及时，避免长时间等待或卡顿，提供流畅的使用体验。 9.5.1.2、系统使用体验验收原则 系统使用为中心： 系统设计应以系统使用为中心，确保系统使用能够轻松理解和使用，减少学习成本， 并最大 限度地满足系统使用需求。 一致性： 系统的界面设计、交互行为、 导航逻辑等应保持一致，避免不同页面或功能模块之间的设计 风格或操作方式不统一。 可访问性： 确保系统对所有系统使用（包括残障用户）都能友好使用，支持多种设备和辅助技术访问， 符合相关的可访问性标准。 9.5.2、系统使用体验验收范围 9.5.2.1、界面设计验收 视觉设计一致性： 验证系统的视觉设计是否保持一致性，包括颜色、字体、图标和按钮风格等。各界面元素应 符合设计规范，不应出现风格突兀或不一致的情况。 布局合理性： 验证系统的界面布局是否合理， 确保重要功能和信息在显著位置， 系统使用能够快速找到常 用功能，减少不必要的点击或滚动。 文字和图像清晰度： 验证界面的文字和图像是否清晰、易于阅读，确保字体大小、行间距、对比度等符合可读性 要求，图像质量良好且无失真。 9.5.2.2、交互设计验收 交互流程简洁流畅： 验证系统使用执行常见任务（如登录、搜索、数据输入、提交等）的交互流程是否简洁、流 畅，避免复杂的操作步骤和过多的点击。 按钮和控件的反馈： 验证按钮和控件（如表单、下拉菜单、开关等）在系统使用操作时是否有明确的反馈（如颜 色变化、加载指示等） ，确保系统使用清楚操作结果。 错误处理和提示： 验证系统在系统使用操作错误时， 是否提供了清晰、 易懂的错误提示， 并且提示内容应帮助 系统使用纠正错误，而不是让系统使用感到困惑。 9.5.2.3、响应时间与性能验收 页面加载时间： 验证系统的页面加载时间是否在合理范围内， 避免长时间的加载等待。 通常页面加载时间应 控制在3 秒以内，以提供流畅的系统使用体验。 操作响应速度： 验证系统在系统使用操作（如点击按钮、提交表单、切换界面等）时的响应速度，确保系统 能够快速响应系统使用请求，避免卡顿或延迟。 动画与过渡效果： 验证系统中的动画和过渡效果是否流畅且不影响性能，确保动画不会导致页面卡顿或延迟。 9.5.2.4、多设备兼容性验收 响应式设计： 验证系统是否支持响应式设计，确保在不同设备（如桌面电脑、平板、手机）上都能正确显 示，界面布局应根据屏幕大小自适应调整。 跨浏览器兼容性： 验证系统是否在不同浏览器上显示和操作正常， 确保不会因为浏览器差异导致功能异常或显 示问题。 移动设备上的体验： 验证系统在移动设备上的体验是否良好，确保页面加载速度、 触屏操作、手势交互等都符合 移动端系统使用的使用习惯。 9.5.2.5、系统使用反馈与满意度验收 系统使用调研与反馈收集： 通过系统使用访谈、问卷调查、可用性测试等方式，收集系统使用对于系统体验的反馈，重 点了解系统使用在使用过程中的痛点和需求。 系统使用满意度评级： 通过系统使用评分（如1-5 分或1-10 分）收集系统使用对系统的整体满意度，确保满意度 达到预期标准（如平均满意度须在75%以上） 。 9.5.3、用户体验验收通过标准 9.5.3.1、用户体验通过条件 系统使用满意度达标： 系统使用满意度的平均评分应达到或超过预期标准（如75%或80%） ，确保大多数系统使用 对系统体验感到满意。 易用性问题少： 系统在可用性测试中应表现良好， 关键任务的完成率应达到90%以上， 且系统使用在操作时 的错误率较低。 响应时间符合标准： 系统页面加载时间和操作响应时间应符合性能标准，避免超过3 秒的延迟或卡顿现象。 无重大兼容性问题： 系统在不同设备、浏览器和网络环境下应表现一致， 确保界面和功能的兼容性， 无重大显示 或操作问题。 9.5.3.2、系统使用体验失败条件 系统使用满意度低： 如果系统使用满意度评分低于预期（如低于75%） ，则系统使用体验验收失败，需重新优化 系统设计和交互体验。 易用性问题严重： 如果系统在可用性测试中， 关键任务的完成率低于80%， 或系统使用频繁出现操作错误和困 惑，则验收失败。 响应时间过长： 如果系统在页面加载时间和操作响应时间上表现不稳定， 系统使用需长时间等待， 导致系统 使用体验不佳，则验收失败。 兼容性问题明显： 如果系统在不同设备或浏览器上出现严重的兼容性问题， 导致系统使用无法正常使用某些功 能，则验收失败。 9.5.4、系统使用体验验收报告 9.5.4.1、系统使用体验测试结果记录 测试案例与结果： 记录所有系统使用体验测试案例的执行结果，包括系统使用的操作流程、完成率、错误率、 反馈意见等，确保对所有关键任务的系统使用体验进行了全面测试。 问题记录与优化建议： 记录系统使用测试中发现的所有问题， 并提出优化建议， 确保在验收完成后，能够根据系统 使用反馈进一步提升系统的系统使用体验。 9.5.4.2、系统使用满意度评估报告 满意度数据分析： 分析系统使用调研和测试中的满意度数据， 得出系统使用对系统体验的整体评价， 并与预期 目标进行对比。 关键改进点总结： 总结系统使用体验中的关键改进点，列出需优化的界面设计、交互流程、性能表现等，帮助 团队在后续开发中进行改进。 9.5.4.3、验收签字确认 各方确认签字： 系统使用体验验收完成后，所有相关方（包括开发方、测试方、系统使用方）应对系统使用 体验验收结果进行签字确认，确认系统系统使用体验已通过验收或提出进一步优化需求。 9.6、验收测试计划和流程 9.6.1、验收测试计划 9.6.1.1、测试目标 明确验收测试的总体目标，包括确保系统功能完整、 性能稳定、 系统使用体验良好以及系统 兼容性强，满足项目需求和业务目标。 验证系统在真实环境下的运行情况，确保其在实际使用中的可靠性和可用性。 9.6.1.2、测试范围 功能测试：涵盖系统的所有主要功能模块，确保功能实现符合需求文档中的描述。 非功能测试：包括性能测试、安全测试、兼容性测试、可用性测试等，确保系统在各个非功 能性需求方面的表现符合标准。 接口测试：对系统与外部系统或子系统之间的接口进行测试，确保系统集成正常。 系统使用体验测试： 对界面设计、 交互流程和系统使用满意度进行评估，确保系统使用体验 达到预期。 9.6.1.3、测试方法 手动测试： 通过人工操作验证系统功能和系统使用体验， 确保复杂的交互流程和细节得到准 确测试。 自动化测试：使用自动化工具对常规的、重复性的测试场景进行自动化测试，减少人为操作 错误并提高测试效率。 黑盒测试：测试人员不需要了解系统内部实现，只需通过输入和输出来验证系统功能。 白盒测试：针对系统内部逻辑和代码的测试，确保所有代码路径和逻辑分支都被覆盖。 9.6.1.4、测试环境 确定验收测试所需的硬件、软件、网络和数据环境。包括搭建测试服务器、数据库、测试工 具、虚拟机、移动设备等。 保证测试环境与生产环境一致或尽量接近，确保测试结果的准确性和可靠性。 9.6.1.5、测试角色与职责 项目经理：负责整体测试计划的制定和测试进度的管理。 测试人员：负责执行具体的测试任务，包括功能测试、性能测试、兼容性测试等。 开发人员： 负责修复测试过程中发现的缺陷和问题， 并在修复后与测试团队进行协作，确保 问题得到验证和关闭。 系统使用代表：参与系统使用体验测试，提供反馈并确认系统的可用性和满足业务需求。 质量保证团队： 负责监控整个验收测试过程，确保测试过程符合质量标准， 并最终给出验收 测试结果的评估报告。 9.6.1.6、测试资源与工具 列出测试过程中可能使用的资源和工具，例如自动化测试工具、性能监控工具、 缺陷跟踪工 具等。 确保所有测试所需的工具和资源在测试开始前准备到位。 9.6.1.7、测试时间计划 制定详细的测试时间表，列出每个测试阶段的开始和结束时间。 设定各类测试的执行顺序和并行测试的安排，确保所有测试任务能够按时完成。 留出适当的时间用于问题的修复和多轮回归测试。 9.6.2、验收测试流程 9.6.2.1、测试准备 测试用例设计： 根据需求文档和技术规格书编写详细的测试用例， 包括功能性测试用例、 非功能性测试用例 以及系统使用体验测试用例。 确保测试用例覆盖所有主要功能模块和关键场景，并明确测试的输入、 输出、预期结果和通 过标准。 测试数据准备： 准备测试所需的输入数据， 确保测试数据能够全面覆盖不同类型的输入场景， 包括正常数据、 异常数据、边界值数据等。 测试环境配置： 搭建和配置测试环境，确保所有硬件、软件、网络和其他依赖资源都已设置完成，并与生产 环境保持一致或高度相似。 测试人员培训： 对参与测试的人员进行培训，确保他们熟悉测试计划、测试用例、测试工具和测试流程。 9.6.2.2、测试执行 功能测试执行： 按照测试用例逐步执行功能测试， 确保系统各模块功能符合需求， 记录每个测试步骤的执行 情况。 非功能测试执行： 执行性能测试、 压力测试、安全测试等非功能性测试，确保系统在不同负载和极限条件下表 现稳定。 系统使用体验测试执行： 邀请系统使用代表参与系统使用体验测试， 评估系统的易用性、美观性、交互流程和系统使 用满意度。 接口测试执行： 验证系统与外部系统或子系统之间的接口是否正常工作，确保数据交换和功能调用符合要 求。 自动化测试执行： 执行已设定的自动化测试用例，确保系统在不同环境下的功能和性能稳定。 9.6.2.3、问题跟踪与修复 缺陷报告： 在测试过程中发现的任何问题或缺陷， 应立即记录在缺陷跟踪系统中， 并注明缺陷的详细描 述、优先级、重现步骤和相关截图。 问题修复： 开发团队根据缺陷报告进行修复，确保问题在规定时间内得到解决。 回归测试： 问题修复后， 测试团队应进行回归测试， 确保修复后的功能和系统的其他部分没有受到影响。 9.6.2.4、测试评估与报告 测试结果评估： 对所有测试用例的执行结果进行评估， 统计通过、失败的测试用例数量，分析各类测试的通 过率和问题率。 缺陷分析： 对发现的缺陷进行分类和优先级分析， 评估系统中是否还存在严重的缺陷， 确定是否需要进 一步修复和测试。 系统使用反馈评估： 汇总系统使用体验测试中的反馈和评分， 评估系统的易用性和系统使用满意度， 确保系统使 用对系统的整体体验感到满意。 性能评估： 对系统的性能测试结果进行评估， 确保系统在压力测试中的表现符合性能要求， 无明显的性 能瓶颈或瓶颈点已被识别并有优化方案。 9.6.2.5、验收测试结束 测试总结会议： 组织所有相关方召开测试总结会议， 讨论测试结果、 系统中存在的问题以及最终的验收决定。 验收签字： 如果测试结果符合项目的验收标准， 所有相关方 （如项目经理、 测试人员、 系统使用代表等） 应签署验收确认单，确认系统验收通过。 测试文档归档： 将所有测试文档、 缺陷报告、 测试结果、 系统使用反馈等进行归档， 供后续项目参考和改进。 9.7、验收文档要求 9.7.1、验收文档类型 9.7.1.1、验收测试计划文档 内容： 测试目标与范围 测试方法与策略 测试环境与工具 测试时间表 测试人员及职责分配 测试用例设计概要 目的： 提供关于验收测试的整体计划和安排，确保各方了解测试的目标、时间和责任划分。 9.7.1.2、测试用例文档 内容： 测试用例编号 测试用例描述 测试步骤 输入数据 预期结果 实际结果 通过/失败状态 测试执行人员和测试时间 目的： 详细记录每个测试场景的执行情况，确保每个功能点和需求均有相应的测试用例覆盖。 9.7.1.3、测试执行报告 内容： 测试用例执行情况（通过/失败数量及比例） 测试过程中发现的问题 问题的严重性和优先级 缺陷的修复状态 回归测试结果 测试总体评估 目的： 汇总验收测试的执行情况，提供测试结果的详细报告，帮助各方了解系统当前的质量状态。 9.7.1.4、缺陷跟踪报告 内容： 缺陷编号 缺陷描述 重现步骤 发现日期 严重性/优先级 责任人 修复状态（已修复/待修复/无法修复） 修复确认时间与确认人 目的： 记录在测试过程中发现的所有缺陷和问题， 跟踪缺陷的修复进度， 确保所有缺陷得到处理或 解释。 9.7.1.5、性能测试报告 内容： 系统的性能测试结果（响应时间、处理能力、并发系统使用数等） 测试环境与条件 性能瓶颈分析 性能优化建议 资源利用率（处理器、内存、硬盘读写等） 目的： 提供系统性能的详细测试结果，确保系统在性能方面达到了预期的目标。 9.7.1.6、系统使用体验测试报告 内容： 系统使用体验测试的具体场景 系统使用反馈总结 系统使用满意度评分 系统使用提出的改进建议 系统易用性分析 改进措施 目的： 记录系统使用在体验过程中提供的反馈， 评估系统的系统使用界面和交互设计， 并提出改进 建议。 9.7.1.7、测试总结报告 内容： 测试概述 测试计划执行情况 主要发现的缺陷及其处理情况 系统功能完成度 系统性能与稳定性总结 系统使用体验和满意度总结 测试结论（是否满足验收标准） 目的： 对整个验收测试过程进行总结， 给出系统是否通过验收的总体结论， 确保测试过程的完整性 和透明性。 9.7.1.8、验收确认单 内容： 验收测试结果总结 系统使用代表确认是否满足业务需求 开发团队确认缺陷已处理完毕 测试团队确认系统已经通过所有必要的测试 各方签字确认 目的： 作为正式的验收确认文档，所有相关方通过签字确认测试结果，标志着验收正式完成。 9.7.2、验收文档提交要求 9.7.2.1、提交时间 每个验收文档应在测试阶段的相应时间点按时提交，例如： 测试计划在测试开始前提交 测试报告在每轮测试结束后提交 测试总结报告在验收测试完成后提交 验收确认单在所有测试完成且系统通过验收后提交 9.7.2.2、提交格式 所有文档应按照项目规定的格式进行编写，并以电子文档的形式提交。 文档格式应统一，包括文件封面、目录、页眉页脚、字体大小、标题层级等，确保文档的规 范性和可读性。 9.7.2.3、提交工具 文档可以通过项目管理系统或邮件系统提交，确保所有文档的可追溯性和版本控制。 电子文档应保存在项目的文档管理系统中，便于后续查阅和归档。 9.7.3、验收文档审查与审批 9.7.3.1、文档审查 所有验收文档应经过项目相关方的审查，包括项目经理、 开发团队、 测试团队和系统使用代 表，确保文档内容的准确性和完整性。 文档审查应涵盖以下方面： 文档是否覆盖验收范围内的所有测试内容 测试结果是否清晰、准确 缺陷跟踪是否完整，修复措施是否合理 9.7.3.2、文档审批 验收确认单和测试总结报告等关键文档应由项目经理、 系统使用代表、 开发和测试团队等相 关方签字确认，作为系统正式通过验收的依据。 9.7.3.3、文档归档 所有验收文档在审查和审批完成后， 均应归档保存， 确保未来的审计和项目回顾过程中可以 查阅完整的验收记录。 文档归档应按照项目的文档管理规范进行，包括版本控制、存储路径和权限设置。 十、采购内容清单 序号软件及设备名称数量单位 一智慧后勤综合服务平台 1 智慧医院平台数字底座基础业务中台系统1 套 智能移动应用终端系统1 套 2 资产及设备管理智能资产台账管理系统1 套 设备设施使用运维系统1 套 3 服务品质管理智能一站式服务综合管理系统1 套 4 应急处置管理报警联动处置管理系统1 套 5 后勤业务支撑管理综合能耗智能监管系统1 套 6 统一管理决策后勤业务集成管理系统1 套 安全态势集成管理系统1 套 7 第三方系统数据对接开发安防系统对接网关1 台 消防系统对接网关1 台 楼控系统对接网关1 台 第三方系统数据对接开发4 套 网络安全数据互联主机1 台 智慧医院运行保障系统基础服务主机1 台 二智能可视化管理平台 1 可视化数字孪生引擎系统1 套 2 可视化图形组态引擎系统1 套 3 可视化数据驾驶舱管理系统1 套 4 智慧电梯运行监测管理系统（对接）1 套 5 医用气体预警监测管理系统（对接）1 套 6 供配电监测管理系统（对接）1 套 7 给排水监测管理系统（对接）1 套 8 冷热站监测管理系统（对接）1 套 9 公区照明监控管理系统（对接）1 套 10 视频监控集中监测管理系统（对接）1 套 11 门禁集中监测管理系统（对接）1 套 12 智慧消防监测预警系统（对接）1 套 13 地图制作6.7 万平米 三智慧后勤综合服务平台配套硬件 1 服务品质管理单元 1.1 智能电话调度网关工业级设备， 用于一站式调度中心， 可支持≥4 路坐席， 可实现来电 自动弹单，通话录音，自动回拨等功能。1 台 1.2 智能工单处理服务站班组处理工单时使用，≥10 寸多点触控电容屏，集成工单打印， 工单扫描，支持收单、派单、超时提醒等功能。1 台 2 风机盘管智能控制改造 2.1 网络控制器1、≥1 个以太网口10/100Mbps 自适应(Modbus TCP 协议)，≥2 个RS485， ≥1 个232 通用口(Modbus RTU 协议、Modbus TCP 协议)； 2、只少支持32 个设备，最大支持512 点； 3、处理器32 位ARM M4； 4、24VDC 供电，功耗最大1W；32 个 2.2 能耗计量系统终端数据采集器控制箱箱体尺寸≥高500mm×宽400mm×深150mm， 箱体含(安装板、人工、辅材(线槽、导轨、线缆、接地排等)) 18 个 2.3 开关电源支持90-264VAC 宽电压输入、支持47-63Hz 宽频率输入，支持21-26VDC 可调 电压输出、额定功率≥120W 输出；18 个 2.4 风机盘管温控器1、量程：至少具有高、中、低、自动四档； 2、精度：±1℃； 3、信号类型：RS485； 4、电源电压：220VAC； 5、安装配件说明：预埋86 底盒，黑色，触摸按键； 6、防护等级：不低于IP54；694 个 2.5 485 通讯线RVVSP 2*1.0 15,000 米 2.6 风机盘管系统接口开放平台通信协议服务器软件，支持第三方编程1 套 因电子交易系统原因无法显示表格， 本项目具体参数以附件形式上传， 请各投标供应商自行 下载，以附件为准。 第五章资格审查方法及标准 根据《政府采购法》 、 《政府采购法实施条例》 、 《政府采购货物和服务 招标投标管理办法》等相关法律法规确定以下资格审查方法及标准。 一、资格审查方法 公开招标采购项目开标结束后， 采购人或采购代理机构依据法律、 法 规及招标文件的规定， 对投标供应商的资格进行审查， 以确定投标供 应商资格是否合格。 二、资格审查标准 （一） 资格审查表 序号 资格要求 须提供的资料 1 提供在中华人民共和国境内 注册的法人或其他组织的营 业执照（或事业单位法人证 书，或社会团体法人登记证 书），如投标供应商为自然人 的需提供自然人身份证明； 提供在中华人民共和国境内注册的法人或其他组 织的营业执照（或事业单位法人证书，或社会团 体法人登记证书），如投标供应商为自然人的需 提供自然人身份证明；注：1.投标人应将上述资 质要求扫描件放入电子投标文件中相应位置，并 加盖投标人电子公章，否则视为投标无效。2.投 标人须保证上述资料完整并清晰可辨，如出现模 糊无法辨认的情况，视其为不合格资料。 2 法人授权委托书、法人及被授 权人身份证复印件（法定代表 人直接投标可不提供，但须提 供法定代表人身份证复印件） ； 法人授权委托书、法人及被授权人身份证复印件 （法定代表人直接投标可不提供，但须提供法定 代表人身份证复印件）；注：1.投标人应将上述 资质要求扫描件放入电子投标文件中相应位置， 并加盖投标人电子公章，否则视为投标无效。2. 投标人须保证上述资料完整并清晰可辨，如出现 模糊无法辨认的情况，视其为不合格资料。 3 提供具有良好商业信誉和健 全的财务会计制度的承诺函； 提供具有良好商业信誉和健全的财务会计制度的 承诺函；注：1.投标人应将上述资质要求扫描件 放入电子投标文件中相应位置，并加盖投标人电 子公章，否则视为投标无效。2.投标人须保证上 述资料完整并清晰可辨，如出现模糊无法辨认的 情况，视其为不合格资料。3.投标人可选择提供 资格承诺函并加盖投标人电子公章，也可选择按 《中华人民共和国政府采购法》《中华人民共和 国政府采购法实施条例》及招标文件资格要求提 供相应的证明材料，若二者均不提供，视为投标 无效。 4 提供履行合同所必需的设备 和专业技术能力的证明材料 （承诺函）； 提供履行合同所必需的设备和专业技术能力的证 明材料（承诺函）；注：1.投标人应将上述资质 要求扫描件放入电子投标文件中相应位置，并加 盖投标人电子公章，否则视为投标无效。2.投标 人须保证上述资料完整并清晰可辨，如出现模糊 无法辨认的情况，视其为不合格资料。3.投标人 可选择提供资格承诺函并加盖投标人电子公章， 也可选择按《中华人民共和国政府采购法》《中 华人民共和国政府采购法实施条例》及招标文件 资格要求提供相应的证明材料，若二者均不提供， 视为投标无效。 5 具有依法缴纳税收和社会保 障资金的良好记录的承诺函； 具有依法缴纳税收和社会保障资金的良好记录的 承诺函；注：1.投标人应将上述资质要求扫描件 放入电子投标文件中相应位置，并加盖投标人电 子公章，否则视为投标无效。2.投标人须保证上 述资料完整并清晰可辨，如出现模糊无法辨认的 情况，视其为不合格资料。3.投标人可选择提供 资格承诺函并加盖投标人电子公章，也可选择按 《中华人民共和国政府采购法》《中华人民共和 国政府采购法实施条例》及招标文件资格要求提 供相应的证明材料，若二者均不提供，视为投标 无效。 6 提供参加采购活动前三年内 在经营活动中没有重大违法 记录的书面声明（承诺函）； 提供参加采购活动前三年内在经营活动中没有重 大违法记录的书面声明（承诺函）；注：1.投标 人应将上述资质要求扫描件放入电子投标文件中 相应位置，并加盖投标人电子公章，否则视为投 标无效。2.投标人须保证上述资料完整并清晰可 辨，如出现模糊无法辨认的情况，视其为不合格 资料。3.投标人可选择提供资格承诺函并加盖投 标人电子公章，也可选择按《中华人民共和国政 府采购法》《中华人民共和国政府采购法实施条 例》及招标文件资格要求提供相应的证明材料， 若二者均不提供，视为投标无效。 7 中国政府采购网及信用中国 查询截图 供应商在中国政府采购网（www.ccgp.gov.cn）未 被列入政府采购严重违法失信行为记录名单，在 “信用中国”网站（www.creditchina.gov.cn） 未被列入失信被执行人、重大税收违法案件当事 人名单（开标现场查询）； （二） 确定资格审查合格投标供应商 1. 按照本章“资格审查方法及标准” ，对各投标资格证明文件进 行审查。 依据对各投标供应商资格证明文件的审查结果， 确定资格审 查合格的投标供应商。 2. 资格审查合格投标供应商不足3 家的，不进行评标。 第六章评审方法和标准 评标委员会将按照本项目招标文件进行评标工作，采购人或者 采购代理机构负责评标的组织工作。工作程序如下： 一、评标准备工作，由采购人或者采购代理机构负责 1.核对评审专家身份和采购人代表授权函； 2.宣布评标纪律，集中保管通讯工具； 3.公布投标供应商名单，告知评审专家应当回避的情形； 4.组织评标委员会推选评标组长，采购人代表不得担任组长； 5.根据评标委员会的要求介绍政府采购相关政策法律、招标文 件。 二、符合性审查工作 评标委员会开展符合性审查： 符合性审查是指依据招标文件的规 定， 从商务和技术角度对投标文件的有效性和完整性进行审查， 以确 定是否对招标文件的实质性要求做出响应。 对符合资格的投标供应商 的投标文件进行符合性审查， 以确定其是否满足招标文件的实质性要 求。符合性审查出现下列情形之一的投标按照无效投标处理： （此部分内容需固化到交易系统专家评审环节，对某家投标供 应商作无效投标处理时选择以下相应选项，对已标记为无效投标的 供应商由交易系统同步至政府采购管理系统） 序号 内容 1 投标总报价超过项目（分包）预算金额或最高限价的； 2 未按照招标文件规定要求签署、盖章； 3 出现两个或两个以上投标方案的（招标文件中要求提供备选方案的除外）； 4 投标有效期不足的； 5 响应文件中附有采购人不能接受条件； 6 不满足招标文件商务实质性要求； 7 出现招标文件规定的其他无效投标条款； 8 出现不同供应商投标文件机器制作码一致的情况； 三、详细评审 评标委员会要求投标供应商对投标文件有关事项作出澄清或者 说明（如有） ； 评标委员会各成员依照招标文件规定的评标程序、方法和标准 进行独立评审； 如本项目评标方法为最低评标价法，评标委员会在审查投标文 件满足招标文件全部实质性要求后，按投标报价从低到高顺序确定 中标候选人。除了算术修正和落实政府采购政策需进行的价格扣除 外，不得对投标供应商的投标价格进行任何调整。 如本项目评标方法为综合评分法， 评标委员会对满足招标文件全 部实质性要求的投标文件，按照招标文件规定的评审因素的量化指 标进行评审打分，以评审得分从高到低顺序确定中标候选供应商。 评标委员会每位成员独立对每个有效投标供应商的投标文件进 行评价、打分；然后汇总每个投标供应商的得分，计算得分平均值， 以平均值由高到低进行排序，按排序顺序推荐中标候选供应商。分 值计算保留小数点后两位，第三位四舍五入。 四、采购人或者采购代理机构核对评标结果 五、确定中标候选供应商名单，或者根据采购人委托直接确定中标 供应商 六、评审标准中应考虑下列因素 1.政府采购政策要求 中小企业： 属于专门面向中小企业采购的标段或项目，不再执行价格评审优惠 扶持政策。 不属于专门面向中小企业采购的标段或项目， 根据 《政府 采购促进中小企业发展管理办法》(财库〔2020〕46 号) 、关于进一 步加大政府采购支持中小企业力度的通知》 (财库 〔2022〕 19 号)、 《宁 夏回族自治区财政厅发展和改革委员会工业和信息化厅住房和 城乡建设厅交通运输厅水利厅公共资源交易管理局中国人民银 行银川中心支行关于落实政府采购促进中小企业发展有关措施的通 知》 （宁财(采)发〔2022〕275 号）的规定，对满足价格扣除条件且 在投标文件中提交了《中小企业声明函》的投标人，其投标报价扣 除10% 后参与评审。 残疾人福利性企业： 不属于专门面向中小企业采购的项目，根据《财政部民政部中国残 疾人联合会发布关于促进残疾人就业政府采购政策的通知》(财库 〔2017〕141 号) 的规定，对提供《残疾人福利性单位声明函》的 残疾人福利性单位或残疾人辅助性就业机构，对其投标总价扣除 10% 后参与评审。 残疾人福利性单位或残疾人辅助性就业机构与大中型企业和其他自 然人、法人或者其他组织组成联合体共同参加非专门面向中小企业 的政府采购活动, 残疾人福利性单位或残疾人辅助性就业机构协议 合同金额占到联合体协议合同总金额30% 以上的,给予联合体4% 的价格扣除。 残疾人福利性单位或残疾人辅助性就业机构按照上述 规定的政策获取政府采购合同后,不得分包或转包给大型、中型企 业。 监狱企业： 根据《财政部司法部关于政府采购支持监狱企业发展有关问题的通 知》(财库〔2014〕68 号)的规定，由省级以上监狱管理局、戒毒管 理局(含新疆生产建设兵团) 出具的属于监狱企业的证明文件的投标 人，其投标报价扣除10% 后参与评审。 联合体中小微企业协议合同金额占到联合体协议合同总金额30%以 上的： 可给予联合体4% 的价格扣除。联合体各方均为小型、微型企业和 监狱企业的，联合体视同为小型、微型企业和监狱企业。 对于同时属于小微企业、监狱企业、残疾人福利性单位的，不重复 进行投标报价扣除(按较高比例扣除)。 其他政府采购政策要求： 采购人采购产品属于节能产品、环境标志产品的，依据品目清单和 国家确定的认证机构出具的，处于有效期之内的节能产品，环境 标志产品认证证书，对获得证书的产品实施政府优先采购或强制采 购。品目清单以财政部生态环境部发布《财库〔2019〕18 号》 、财 政部发展改革委发布《财库〔2019〕19 号》为准。节能、环保产品 的界定以《国家节能产品认证证书》 、 《中国环境标志产品认证证书》 和政府部门公布的品目清单网页截屏为准。 如采购人所采购产品为政府强制采购的节能产品，投标人所投产品 的品牌及型号必须提供证明文件，否则其投标将作为无效投标被拒 绝。 2.同品牌处理办法 如采用最低评标办法，则： 提供相同品牌产品的不同投标人参加同一合同项下投标的，以其中 通过资格审查、符合性审查且报价最低的参加评标；报价相同的， 由采购人或者采购人委托评标委员会按照招标文件规定的方式确定 一个参加评标的投标人， 招标文件未规定的采取随机抽取方式确定， 其他投标无效； 如采用综合评标法，则： 提供相同品牌产品且通过资格审查、符合性审查的不同投标人参加 同一合同项下投标的，按一家投标人计算，评审后得分最高的同品 牌投标人获得中标人推荐资格；评审得分相同的，由采购人或者采 购人委托评标委员会按照招标文件规定的方式确定一个投标人获得 中标人推荐资格，招标文件未规定的采取随机抽取方式确定，其他 同品牌投标人不作为中标候选人。 3.中标候选供应商并列时的处理方式 如采用最低评标办法，则： 评标结果按投标报价由低到高顺序排列。得分与投标报价均相同的 处理方式：由采购人或采购人委托评标委员会随机抽取； 采用综合评标法，则： 评标结果按评审后得分由高到低顺序排列。 得分相同的， 按投标报价 由低到高顺序排列。 得分与投标报价均相同的处理方式： 由采购人或 采购人委托评标委员会随机抽取。 七、评审因素和标准 服务类公开招标（综合评分法） 序号 评审项目 分值权重 评分标准 1 投标报价 15.0 所有算术修正后的投标报价由低到高 进行排序，除投标报价明显低于其他通 过符合性审查投标人的报价又不能证 明其报价合理性的被拒绝外。 实际得分＝（评标基准价／投标报价） ×15 评标基准价为有效报价的最低价。评标 委员会认为投标人的报价明显低于其 他通过符合性审查投标人的报价，有可 能不能诚信履约的，评标委员会有权要 求其在评标现场合理的时间内提供书 面说明，必要时提交相关证明材料；投 标人如不能证明其报价合理性的，评标 委员会应当将其作为无效投标处理。 2 技术标响应情况 15.0 招标文件中带“★”条款为重要技术 指标、 参数要求， 其它为一般技术指标、 参数要求。 以15 分为基础，投标文件中重要技术 指标、参数低于招标文件规定的相应技 术指标、参数，每有一项减1 分; 一般 技术指标、参数低于招标文件规定的相 应技术指标、 参数， 每有一项减0.5 分， 两项减完为止。 注：①招标文件中“★”的技术指标须 提供相关证明材料的清晰扫描件予以 佐证，附于投标文件中并加盖投标人电 子公章，无证明材料的视为负偏离。投 标人不得瞒报、虚报技术指标，投标过 程中及中标后一经发现存在虚假响应 行为即视为无效投标。②投标人提供的 相关证明材料中未体现的技术指标、参 数视为负偏离。投标参数与实际参数不 符时视为无效标书。 3 功能演示1 3.0 演示要求： ①使用软件系统或demo 进行运行和演 示，使用静态页面、PPT、视频或截图 的一律不得分； ②演示总时长不得超过20 分钟； ③投标人须到场进行演示操作，须自备 演示电脑、屏幕连接线，评标区域无网 络，不能携带手机等通讯设备，须自行 解决网络问题；演示人员须携带身份证 原件。 ④投标人未按照规定时间到场演示，视 为自动放弃本次演示，本项不得分。 ⑤本次采购的智慧后勤综合服务平台、 智能可视化管理平台具有统一的整体 架构，两套平台具有统一入口，能实现 数据互通和功能耦合，便于医院管理和 使用，要求投标人在同一个演示业务平 台对功能进行演示，系统页面风格、操 作习惯须统一，在不同系统切换或者页 面跳转方式演示视为无效演示，本项不 得分。 演示内容： 1、智慧后勤综合服务平台功能演示 （1）个人工作台管理（3 分） 工作台个性化定制： ①窗体布局自定义，支持摆放位置拖 拽，窗体大小调整，并可保持布局； ②窗体内容自定义，至少包含：待办事 项，用户信息，安消防报警列表数据， 后勤巡检数据，后勤服务指标数据； ③消息订阅：支持消息订阅和取消，至 少包含工单消息，任务提醒消息，新闻 通知消息，调查问卷消息，报警消息。 每满足一小项演示要求得1 分，满分3 分，未提供演示或演示不全的均不得 分。 4 功能演示2 4.0 （2）设备设施运行监测（4 分） ①监测功能菜单展示：提供医用气体， 视频监控，给排水，中央空调，能耗数 据的统一展示，进入各监测系统无新页 面跳转。 ②空调运行监测展示：展示空调末端设 备数量，各状态数量；可按建筑按区域 查询末端设备，显示设备运行状态；以 组态图显示设备运行状态； 每满足一小项演示要求得2 分，满分4 分，未提供演示或演示不全的均不得 分。 5 功能演示3 6.0 2、智能可视化管理平台 （1）空间可视化展示（6 分） ①以可视化模型方式展示全院的建筑 布局，展示全院空间数量、建筑面积等 数据。 ②可按使用部门、用途进行空间统计， 并以柱状图展示统计结果。 ③可在不同建筑模型之前进行切换，显 示该建筑的空间数据 ④可切换到楼层，使用不同的颜色表示 不同的房间不同的功能用途，并能按不 同用途筛选空间并展示。 每满足一小项演示要求得1.5 分，满分 6 分，未提供演示或演示不全的均不得 分。 6 功能演示4 4.0 （2）配电系统可视化管理（4 分） ①以可视化模型方式展示配电室，可对 多个配电室进行切换，显示配电室物理 空间设备信息； ②对可实时查看配电柜的运行数据，包 括电流电压等数据。 每满足一小项演示要求得2 分，满分4 分，未提供演示或演示不全的均不得 分。 7 功能演示5 3.0 （3）后勤服务工单可视化管理演示（3 分） ①在可视化图形上操作打开特定空间 模型的工单列表； ②打开任意工单查看详情，播放通话录 音，录音具有倍速度播放和暂停功能； ③在工单详情页面中操作，将通话录音 转换为文字，并显示在窗口内。 每满足一小项演示要求得1 分，满分3 分，未提供演示或演示不全的均不得 分。 8 功能演示6 5.0 （4）能源能耗可视化演示（5 分） 展示能源消耗的可视化效果展示。 ①以模型方式展示医院建筑名称和每 栋建筑的用电量总量； ②可切换建筑模型，在模型上展示建该 筑用电总量，每层楼的用电总量量，展 示每层楼用电量使用不同的深度颜色 表示用电量大小； ③电表位置展示，展示楼层电表位置分 布，点击每个电表可展示当前电表的实 时数据； ④能耗数据统计，可按今日、本周、本 月、 本年、 自定义日期方式统计用电量， 展示能耗总量、同比、环比、能耗费用 数据，去年同期数据、能耗定额数据。 ⑤能耗模型展示，展示按电梯、照明插 座、特殊用电、动力、空调用电的数据 使用数据。 每满足一小项演示要求得1 分，满分5 分，未提供演示或演示不全的均不得 分。 9 对接方案 5.0 投标人须对风机盘管智能控制改造与 现有楼宇自控系统进行控制和数据对 接（控制和数据维度包括但不限于设备 接入、 基础控制、 策略控制、 组态系统、 数据报表与统计、协议与接口、跨系统 联动等）提供对接方案。 投标人对控制和数据对接进行详细设 计和阐述，并提供相应控制与数据对接 承诺函（控制和数据对接过程中所发生 的费用全部由投标人承担）。 投标人对控制与数据对接的要求了解 全面透彻，对接方案内容完整详实，表 述合理，技术可行性强，思路清晰的得 5 分； 投标人对控制与数据对接的要求了解 清晰，对接方案内容完整，表述清楚， 技术有可行性，思路合理的得3 分； 投标人对控制与数据对接要求并未全 面深入的了解，制定的对接方案有欠 缺，基本可以满足招标要求但内容尚不 完善的得1 分； 未提供对接方案，或制定的对接方案内 容严重缺失并无法满足招标需求，无法 与现有平台进行数据对接，或未提供对 接承诺函的均不得分。 10 整体技术方案 6.0 投标人针对本项目制定整体技术方案， 包含但不限于：①系统架构设计、②关 键技术分析、③建设方案等内容。 针对以上小项内容，技术方案内容完整 详尽、思路清晰，具有针对性及可行性 的，完全满足采购需求的得2 分；技术 方案满足招标文件要求，但内容过于简 单片面的得1 分，未提供不得分。 11 实施方案 10.0 投标人针对本项目制定项目实施方案， 包含但不限于：①项目实施计划、②实 施进度、③项目质量管理、④重点难点 理解分析及应对措施能力、⑤人员组织 架构等内容。 针对以上小项内容，实施方案内容完整 详尽、思路清晰，具有针对性及可行性 的，完全满足采购需求的得2 分；实施 方案满足招标文件要求，但内容过于简 单片面的得1 分，未提供不得分。 12 售后服务 8.0 根据本项目采购需求提供售后服务方 案，包括但不限于：①售后服务内容、 售后服务承诺、②培训内容、③应急预 案、④服务响应及时程度等内容。针对 以上小项内容，售后方案内容完整详 尽、 思路清晰， 具有针对性及可行性的， 完全满足采购需求的得2 分；售后方案 满足招标文件要求，但内容过于简单片 面的得1 分，未提供不得分。 13 企业实力1 3.0 1、投标人具备质量管理体系ISO9001 认证证书、 信息安全管理体系ISO27001 认证证书、信息技术服务管理体系 ISO20000 认证证书，每有一项得1 分， 满分3 分，未提供不得分。注：投标文 件中附有效期内的证书扫描件并加盖 投标人电子公章，否则不得分。 14 企业实力2 1.0 2、投标人具备信息技术服务运行维护 标准符合性证书（ITSS），二级及以上 的得1 分， 其他或未提供均不得分。 注： 投标文件中附有效期内的证书扫描件 并加盖投标人电子公章，否则不得分。 15 企业实力3 1.0 3、投标人具备信息系统安全集成服务 资质证书 （CCRC） 二级及以上的得1 分， 其他或未提供均不得分。注：投标文件 中附有效期内的证书扫描件并加盖投 标人电子公章，否则不得分。 16 类似业绩 3.0 投标人提供近三年（2022 年1 月至今） 类似项目业绩的，每提供一个得1 分， 满分3 分。 注：投标文件中附中标（成交）通知书 或合同清晰扫描件（时间以合同签订时 间或中标通知书发布时间为准）并加盖 投标人电子公章，否则不得分。 17 项目团队1 4.0 1、投标人拟派至本项目的项目经理（1 名）具有信息系统项目管理师证书的得 4 分，未提供不得分。注：投标文件中 附有效期内人员证书扫描件并加盖投 标人电子公章及投标人为其缴纳的 2024 年9 月至今任意连续3 个月的社保 缴纳记录清晰扫描件并加盖投标人电 子公章，否则不得分。 18 项目团队2 4.0 2、 项目服务团队人员中 （含项目经理） ， 分别具有①软件设计师、②系统集成项 目管理工程师、③数据库系统工程师、 ④信息安全保障人员认证证书(CISAW) 的， 每提供一种证书得1 分， 满分4 分， 未提供不得分。（本小项中同一人具有 多个证书不重复加分。）注：投标文件 中附有效期内人员证书扫描件并加盖 投标人电子公章及投标人为其缴纳的 2024 年9 月至今任意连续3 个月的社保 缴纳记录清晰扫描件并加盖投标人电 子公章，否则不得分。 （一）澄清有关问题 评标委员会对投标文件中含义不明确、 同类问题表述不一致或者 有明显文字和计算错误的内容， 以书面形式 （应当由评标委员会专家 签字）要求投标供应商做出必要的澄清、说明或者纠正。投标供应商 的澄清、说明或者补正应当采用书面形式，由其授权的代表签字，并 不得超出投标文件的范围或者改变投标文件的实质性内容。 评标委员会认为投标供应商的报价明显低于其他通过符合性审 查投标供应商的报价， 有可能影响产品质量或者不能诚信履约的， 应 当要求其在评标现场合理的时间内提供书面说明， 必要时提交相关证 明材料； 投标供应商不能证明其报价合理性的， 评标委员会应当将其 作为无效投标处理。 （二）投标报价修正（如有） 投标文件报价出现前后不一致的，按招标文件规定修正； （三）比较与评价 评标委员会按招标文件中规定的评标方法和标准， 对资格性检查 和符合性检查合格的投标文件进行商务和技术评估，综合比较与评 价。具体评审因素详见《评审因素和标准》 。 （四）推荐中标候选人名单 中标候选人数量详见《投标供应商须知前附表》 。评标委员会按 评审后得分由高到低顺序排列。 得分相同的， 按投标报价由低到高顺 序排列；得分且投标报价相同的，按技术指标优劣顺序排列。 (五)编写评标报告 评标报告是评标委员会根据全体评标成员签字的原始评标记录 和评标结果编写的报告。 第七章政府采购合同主要条款 本合同□是/□否中小企业预留合同 合同编号： 项目编号： 国家妇儿区域医疗中心-北京大学第一医院 XXXXXXX 采购合同 甲方：北京大学第一医院宁夏妇女儿童医院 （宁夏回族自治区妇幼保健院） 乙方：xx 公司 签订日期：2025 年月 签订地点：中国·银川 目 录 第一章总则1 第二章定义及释义1 第三章合同价格及付款方式2 第四章工程实施与服务3 第五章知识产权3 第六章保修及售后服务4 第七章保密条款5 第八章双方义务6 第九章违约责任8 第十章不可抗力8 第十一章争议的解决8 第十二章合同变更和解除9 第十三章其他9 甲 方： 北京大学第一医院宁夏妇女儿童医院 （宁夏回族自治区妇幼保健院） （以下称为 “甲 方” ） 地 址：宁夏回族自治区银川市金凤区湖畔路127 号 邮 编：750011 联系人： 电 话： 乙 方： 地 址： 邮 编： 联系人： 电 话： 第一章总则 1.1 总则 本着平等互利、相互支持、优势互补、共同发展的理念，经友好协商，根据甲方公开招标的 结果（详见附件1：中标通知书） ，乙方为成交供应商。现依照项目招标文件、投标文件及 有关法律、法规、规章制度的内容，甲乙双方就国家妇儿区域医疗中心-北京大学第一医院 宁夏妇女儿童医院建设项目信息化建设项目 （智慧后勤综合服务平台、 智能可视化管理平台） 合作达成共识。双方按照本合同约定的条款享受权利、履行义务并承担相应的责任。 第二章定义及释义 2.1 定义 除本协议另有特别约定和声明以外，下列用语应具有如下含义： 2.1.1 “本项目” ：指国家妇儿区域医疗中心-北京大学第一医院宁夏妇女儿童医院建设项目 信息化建设项目（智慧后勤综合服务平台、智能可视化管理平台）建设项目。 2.1.2 “系统” ：指系统/平台建设，是相关软件、安装材料、施工等总称。 2.1.3 “现场” ：对设备进行安装和运行的场所。 2.1.4 “合同” ：本合同正文及其附件；附件是合同不可分割的一部分，具有同等法律效力。 如果附件和本合同正文有任何不一致之处，以合同正文为准。 2.1.5 “设备到货验收” ：除应用软件外的其它配套设备、材料等发到现场后，由甲方和乙方 一起安排人员根据合同要求，对到货内容进行验证，确定货物发运正确，货物检查完毕后， 甲方与乙方共同签署设备到货证明。 2.1.6 “响应” ：乙方就甲方提出问题予以答复的行为。 2.1.7 “响应时间” ：指乙方就甲方提出的问题予以答复的时间。 2.1.8 “工作日” ：星期一至星期五，所有中国法定节假日除外。 2.2 释义 2.2.1 “一方”或“双方”应为本协议的“一方”或“双方” ，且均包括各自权利、义务继承 者和获准的受让人。 2.2.2 本协议项下所述“不少于” 、 “不晚于” 、 “之内”均包括本数。 2.2.3 表示时间跨度的“日” 、 “天”均指公历日。 第三章合同价格及付款方式 3.1 合同范围 依照本合同及其附件约定的条件，由乙方负责国家妇儿区域医疗中心-北京大学第一医院宁 夏妇女儿童医院建设项目信息化建设项目（智慧后勤综合服务平台、智能可视化管理平台） 的实施，乙方负责完成该项目设计开发、硬件设备的采购、软件的开发、系统集成、实施、 培训、移交、维护及相关其他服务工作，并保证本项目提供的应用软件、硬件设备满足本合 同及附件提出的要求。 3.1.1 采购明细 本合同所采购开发软件及技术服务的名称、 技术规格和数量， 详见合同附件及乙方投标文件 “投标分项报价表” 。 3.1.2 合同文件内容 以下文件是合同不可分割的部分： 3.1.2.1 本项目招标文件中的技术说明。 3.1.2.2 乙方提交的投标文件。 3.1.2.3 本合同的所有附件。 3.2 合同金额 根据招标文件的要求和乙方投标文件内容， 本合同最终执行总金额为： 大写人民币 元整 （小写：¥ 元）(详见附件2：项目金额)。此价格包含项目实施期间的所有费用以及相关税 费， 乙方不再向甲方及甲方相关单位另行收费。 分项价格在乙方投标文件的投标报价表中有 明确规定。 3.3 付款方式 3.3.1 履约保函。合同签订后15 个工作日内，乙方应向甲方提供合同总金额5%的履约保函， 乙方若违反政府采购相关规定给甲方造成损失的，甲方可安合同约定要求乙方承担赔偿责 任。 3.3.2 甲方收到履约保函后， 60 个日历日内向乙方支付中标金额的30％， 即大写人民币 元 整（小写：¥ 元） 。 3.3.3 完成建设并通过甲方验收合格后60 个日历日内， 甲方向乙方支付中标金额的70％， 即 大写人民币 元整（小写：¥ 元） 。 3.3.4 质保期满后甲方向乙方退回履约保函。 3.3.5 乙方应在甲方每次付款前开具相应支付金额的增值税发票，对于乙方交付软件及硬件 产品需向甲方开具增值税发票，甲方在收到乙方发票后10 个工作日内需支付相应款项。甲 方未收到发票有权不予付款且不承担任何责任。 3.3.6 乙方银行信息： 户 名: 开户行: 账 号: 3.4 如合同项目经费系财政拨付的专项资金，因乙方责任导致专项资金尚未支付即被收回 的，损失全部由乙方承担，甲方不承担任何责任，下剩款项有权不再支付。 第四章实施与服务 4.1 乙方必须于合同生效之日起【90】日内按照如下清单完成所列的项目任务并交付验收， 同时承担过程中发生的一切费用及手续。 序号名称交付时间 1 xx 任务合同签订之日起【90】天 4.2 乙方应确保项目的完整履行并按期交付，如因乙方原因出现任何缺漏配置、延迟履行、 功能不全、 部分完成或其他违约情形， 导致项目无法按期通过验收，乙方必须立即按甲方要 求的时限无偿自行补齐， 整改优化至满足交付要求， 同时甲方有权利选择随时解除合同， 甲 方选择解除合同的，下剩款项不再支付，乙方应当退还甲方全部已付款并承担违约责任。 4.3 甲乙双方指派代表，组成本软件系统开发管理小组，管理小组的成员应满足项目推进的 需求。 乙方应保证项目成员的工作经验丰富及长期稳定， 如乙方更换项目成员， 应事先征得 甲方的书面同意。对于工作态度消极、 工作能力无法满足业务需求的乙方项目人员， 甲方有 权要求乙方进行即时更换。甲方也可以指定第三方作为自己的代理人参加管理小组。 4.4 在本项目建设范围内， 如有监理单位的， 乙方要服从甲方所聘请的监理单位的合理管理， 按照监理单位要求，及时推进醒目进度并提供相关项目文档。 4.5 非甲方书面同意，本合同项下全部工作内容乙方不得以分包、转让、合作开发等任何形 式交于第三方单位、人员进行。 第五章知识产权 5.1 乙方承诺，为完成本合同约定事项，乙方为系统软件的著作权人（或乙方已从系统软件 权利人处取得许可使用权） ，并有权许可甲方使用应用软件，且该授权长期合法有效并能够 满足本项目需要。乙方保证提供的服务不侵犯任何第三者的著作权、商标权、专利权或所有 权及商业秘密。 如乙方违反知识产权规定而导致甲方被第三人追究法律责任， 乙方应当负责 解决， 并确保该等纠纷不得影响甲方对合同采购内容的正常使用， 包括但不限于提供甲方继 续使用本合同项下的软件而需取得的第三方授权， 修改本合同项下软件使其至少在功能上可 以替代原技术、 提供功能上相等的使甲方可以达到原合同目的的其他软件， 并承担因此而产 生的所有费用。否则，乙方向甲方支付合同总价30%的违约金，并赔偿甲方因此而造成的全 部损失，包括但不限于诉讼费用、调查费用、合理的律师费用、和解金额或生效法律文书中 规定的赔偿金额。 5.2 乙方已开发完成之系统的知识产权归乙方所有，甲方具有该系统的使用权，本合同项下 所产生的工作成果的知识产权归甲乙双方共同所有， 工作成果包括但不限于技术资料、 源代 码、开发文档和编译后的安装程序等， 乙方应在系统或软件交付甲方使用前，向甲方提供完 整的上述工作成果，并保证甲方有权自行修改、更新和维护源代码。 5.3 自上线之日起系统运行所产生的医疗、护理、文档、患者基本信息等所有数据信息所有 权归甲方所有，乙方无条件配合导出，乙方未经甲方书面允许，不得擅自对数据进行修改、 删除、展示、导出、分析等处理，不得通过任何手段复制、移动、使用各类数据。 第六章项目验收 6.1 根据双方约定的项目计划， 进行相应系统软、硬件验收。 在完成合同规定全部的系统 软、硬件的安装调试、培训工作并在系统上线后，乙方需自系统正常上线之日起【】日内向 甲方书面提起验收申请，验收应甲乙双方及监理单位（如有）共同参与，如因乙方原因造成 无法及时进行验收，甲方不承担任何责任，乙方承担逾期违约责任。 6.2、验收标准：所有软、硬件系统功能满足合同约定、甲方使用需求及中标文件要求，并 且向甲方提交具体项目文档、工作成果等相关验收文件。 6.3、软、硬件及服务验收与中标参数一致，在中国境内可依常规安全合法使用，验收时如 发现所交付的软、硬件及服务有不符合本合同规定之情形者，甲方应做出详尽的现场记录， 或由甲乙双方签署备忘录， 此现场记录或备忘录可用作软件功能完善的有效证据。 由此产生 的有关费用由乙方承担。 6.4、甲方组成验收小组按合同附件清单进行验收，必要时邀请相关的专业人员或机构参与 验收。 验收通过各方签署项目验收单， 作为甲方后续付款的依据。 乙方工作成果不符合本合 同要求的，乙方应限期无偿整改，超期部分承担承担逾期违约责任。 第七章保修及售后服务 7.1 乙方保证其向甲方提供的软件为正版， 保证其在保修期内向甲方免费提供包括培训在内 的完善的技术服务， 并且保证其应用软件的性能、 质量及运行与合同及其附件中的所有要求 相符。 7.2 自系统验收合格之日起，乙方提供软件服务【】年、硬件设备【】年的质保服务（包括 但不限于系统的维护、升级、维保服务） ，不再另行要求甲方支付费用。质保服务期满，甲 方可视实际业务需要，选择自动终止服务或向乙方购买售后服务。 如甲方提出要约的，乙方 承诺继续提供售后技术服务， 标准不低于本合同质保期服务标准， 服务费用不高于本合同总 金额的10%，并接受医院的服务考核。如果乙方无法继续提供符合要求的售后服务，应向甲 方支付本合同总价30%的违约金。 7.3 售后服务期内，乙方应根据甲方的管理要求提供相应的技术咨询和技术支持。 7.4 质保期内，乙方所提供的产品或服务，如果发生版本变更或升级（包括但不限于系统大 版本号升级以及子版本号升级） ，乙方应当免费为甲方提供升级服务，乙方所提供的产品或 服务知识库版本变更或升级（包括但不限于系统大版本号升级以及子版本号升级） ，乙方应 当免费为甲方提供升级服务。 7.5 乙方保证所开发的软件与甲方现有提供的硬件和目标系统完全兼容；甲方如计划调整 硬件，应提前通知乙方。 7.6 售后服务期内，凡是因为甲方自身硬件、或因运行非乙方提供的软件造成上述软件产品 的破坏，乙方应当提供相应的技术指导。 7.7 重大故障：系统崩溃或系统不能运行。该种故障的售后服务实行7×24 小时服务，在 接到用户报障后，1 小时内做出响应，4 小时内到达现场提供技术服务。单纯因“乙方成果” 原因造成的故障，24 小时内恢复正常使用，48 小时内予以解决故障并恢复正常运行；因其 它原因造成的故障，乙方应提供与乙方相关的技术指导。 7.8 严重故障：系统运行不正常，某些功能无法使用，影响了多数用户。该种故障的售后服 务实行7×24 小时服务，在接到用户报障请求后，1 小时内做出响应，4 小时内到达现场提 供技术服务。单纯因“ 乙方成果”原因造成的故障，24 小时内恢复正常使用，72 小时内 予以解决故障并恢复正常运行；因其它原因造成的故障，乙方应提供与乙方相关的技术指 导。 7.9 一般故障：系统运行不正常，某些功能无法使用，影响了个别用户。对于一般故障，实 行7×8 小时服务，24 小时内恢复正常使用，96 小时内予以解决故障并恢复正常运行。 7.10 在售后服务期内，乙方免费接受甲方的电话、邮件、微信和书面函件方式的技术咨询， 该种售后服务实行5×8 小时响应服务，并在响应后24 小时内给予甲方答复。 7.11 在维保期内，如果乙方所提供的系统的性能和质量与合同规定不符，乙方负责尽快排 除缺陷并承担造成的直接损失，乙方承担责任上限累计不超过本合同总价。 7.12 在系统软件生命周期内，对于由于乙方原因产生的软件缺陷及/或不合理情况，乙方免 费提供应用软件免费升级、备份软件版本升级、补丁程序或技术支持，保证软件正常运行， 且不影响医院其他软件运行环境。 。 7.13 质保期内，乙方需免费提供【】名驻场工程师服务，驻场工程师应当具有系统维护的相 关经验，紧急故障处理服务能力， 项目实施及售后维护驻场人员须严格遵守医院《信息系统 第三方驻场人员管理制度》 。 7.14 质保期内，乙方提供定期巡检服务，检查的具体内容包括：系统的云像是否正常；系统 是否有功能改进的需要；网络环境是否正常；硬件系统日志检查；各项应用系统日志检查； 系统病毒检测；乙方专业角度考虑应当进行的及甲方提出其他需求等。 7.15 质保期内硬件维护服务要求： 对使用频率较高， 易出故障的设备，按照20%的比例提供 核心配件，如【】 。对终端硬件进行例行维护保养，包括设备清洁、屏幕校准、设备检查维 护等，提供平均无故障工作时间。 第八章保密条款 8.1 保密资料内容： 甲乙双方中任何一方披露给对方的明确标注或指明是保密资料的相关业 务和技术方面的书面或其它形式的资料和信息均认为是保密材料， 不得转发、 公布他人或其 他机构（简称：保密资料） ，包括商业秘密和技术资料，商业秘密包括但不限于商务配置、 商务报价，技术秘密与经营秘密。技术资料包含但不限于技术方案、工程设计、制造方法、 工艺流程、技术指标、计算机软件、数据库、研究开发记录、技术报告、检测报告、图纸、 操作手册、 技术文档、相关函电以及未公开的专利等知识产权信息。但不包括下述资料和信 息： （一）已经公布于众的资料,但不包括双方或其代表违反本协议规定未经授权所披露的； （二）在任何一方披露前已为接受方知悉的非保密性资料； （三）任何一方提供的非保密资料，接受方在披露这些资料前不知此资料提供者（第三方） 已经与本协议下的非保密资料提供方订立过有约束力的保密协议， 且接受方有理由认为资料 披露者未被禁止向接受方提供该资料； （四）中华人民共和国法律要求必须公开的资料。 8.2 双方责任： （一）甲乙双方互为保密资料的提供方和接受方，负有保密义务，承担保密责任； （二）甲乙双方中任何一方未经对方书面同意不得向第三方公开和披露任何保密资料； （三）双方均须把保密资料的接触范围严格限制在与项目相关部门和项目有关的人员范围 内； （四）除经过双方书面同意而必要进行披露外，任何一方不得将资料复印提供给他人； （五）双方应承担各自员工保密监管责任，员工对保密资料的披露等同单位披露 （六）未经乙方许可，甲方不得向第三方软件公司展示本软件。 8.3 违约责任： 一方违反本章约定，应当承担违约责任；给对方造成损失的，应当赔偿。违约方应当承担对 方因争取执行其在本协议项下的权利而发生的一切合理费用和开支 （包括但不限于法院费用 和律师费用） 。 8.4 政府相关单位进行必要合法的查询、审计等可免责、不受此限。 8.5 本合同及附件的保密条款持续有效，不因本合同变更终止而终止，如果双方没有对保密 期限加以规定， 则直至保密信息在本行业中成为公知信息后， 本合同约定的保密义务才予以 解除。 第九章双方义务 9.1 甲方义务 9.1.1 向乙方提供项目总体需求，配合乙方进行详细的需求调研工作，并在符合甲方需求的 情况下及时进行确认。 9.1.2 根据合同约定按时向乙方支付合同款项。 9.1.3 提供本项目运行的场地、配套设施等环境。 9.1.4 向乙方提供实施本项目所必需的应由甲方提供的信息、数据及资料；及时对乙方实施 本项目时的提问等进行答复、确认。由于甲方未尽到前述职责而致使乙方无法开展工作的， 合同期限相应顺延。 9.1.5 甲方需负责提供或协调与XX 平台信息化升级对接相关的其他系统厂家积极配合乙方 提供与本系统集成所需的所有接口要求。非乙方原因造成的系统对接问题导致项目延期的， 乙方不承担责任。 9.1.6 负责按时做好验收工作。 9.1.7 对乙方工作进行监督、提出改进意见及要求，合理的意见乙方应当接受并及时改进。 9.2 乙方义务 9.2.1 乙方保证其有完成本项目的资质与能力，并承诺亲自完成本项目的全部工作。 9.2.2 负责拟定和实施与乙方成果相关的、甲方目前在用以及即将投入使用的应用系统的整 体联调方案。 9.2.3 负责与乙方成果相关的软硬件集成工作，包括安装、调试、调优等，包含但不限于乙 方提供的硬件设备。 9.2.4 保证工作成果功能的完整性，保证项目的安全性、稳定性和易操作性，并保证项目能 在甲方用户使用范围内全面正常运行。 9.2.5 负责配合甲方对本项目及本项目的验收工作，负责验收前项目运行的技术支持，并负 责向甲方提出验收结果报告。 9.2.6 负责对项目运行、维护所需的甲方人员进行培训，保证甲方人员通过培训，可以自己 完成对项目的操作。 9.2.7 在项目交付时，分别以纸质文件和电子文档方式向甲方提供完整的系统手册等技术资 料及甲方个性化需求源代码， 确保提供的技术资料符合行业标准， 具体内容包括但不限于内 容清单、格式要求、版本管理细节、系统架构、模块功能、接口描述、代码注释等，以满足 甲方后续自行或委托第三方开发需要（无需另行付费） ，并应根据项目的变化立即更新相关 资料。 。 9.2.8 保证所开发的成果具有可扩展性，在甲方提出进一步的开发需求时，能及时提供进一 步的技术支持使系统的功能得到增强和完善； 产品在实施及使用过程中， 由乙方通过合理的 技术和机制保障甲方全国范围内相关单位使用的系统版本完全一致。 9.2.9 乙方对所有乙方人员履行本合同行为承担全部责任。 9.2.10 乙方须使用最好的技术资源， 全力配合甲方项目的集成及接口开发工作， 在甲方项目 的总体计划、安排和要求下完成相关的工作，积极解决遇到的接口、性能等技术问题。 9.2.11 乙方需积极配合完成XX 平台集成所需的所有接口工作，如因乙方原因造成的系统对 接问题导致项目延期的，乙方负全部责任。 9.2.12 乙方需免费配合甲方完成XX 绩效考核相关工作，如因乙方逾期造成甲方无法通过相 关单位的评级、考核的，乙方应当支付甲方违约金 万元。 9.2.13 乙方需按要求完成与xx 平台、xx 设备等的连接以及与xx 平台、互联网医院一体化 监管平台、 “xx”APP、宁夏远程诊疗服务平台、电子健康码、助产机构电子病历/LIS/PACS、 妇幼云HIS 等其他政府要求实现互联互通的系统对接工作， 如因乙方原因造成的系统对接问 题导致项目延期的，乙方负全部责任。 第十章违约责任 10.1 本合同生效后，双方均应全面履行合同义务。 10.2 乙方未能按照本合同约定按期交付约定成果、质保服务迟延的，每逾期一天，按照合 同总价款的千分之五向甲方支付违约金。 如乙方累计逾期达7 日、 项目报验整改一次后仍无 法通过验收、将项目交予第三方、违反保密义务及合同其他约定的，乙方应承担合同价款 20%的违约金并赔偿甲方由此遭受的损失，同时甲方有权随时单方通知解除本合同。 10.3 甲方暂不解除并合同的， 乙方应当继续履行合同并承担违约责任； 甲方通知解除合同的， 合同项下未付款不再支付，已付款应当予以退还。 10.4 乙方违约情况下， 应当赔偿甲方的损失范围包括但不限于： 甲方另行委托第三方完成本 合同乙方工作对应的费用、 因项目逾期造成其他额外费用、 双方争议情形下甲方产生的诉讼 费用、律师费用、调查费用等。 第十一章不可抗力 11.1 双方因天灾、战争、洪水、火灾、爆炸、地震、暴乱、民变、政变、瘟疫等人类不可 抗拒的情况而耽误或无法对本合同进行履行， 将不被视为是过失并无需承担任何责任。 遭受 不可抗力的一方在不可抗力发生后应及时通知对方， 并提供权威机构的相关证明。 未尽通知 义务， 不可免责。 如发生不可抗力的情况， 另一方应予以协助， 采取必要措施防止损失扩大。 11.2 前款情形下，合同双方可延长项目时间。延长时间为因受其影响期间的进程直至该影 响结束为止。如该影响持续超过六十日，双方均有权书面通知对方终止本合同， 并按合同实 际履行情况清算费用。 第十二章争议的解决 12.1 凡因本合同的签订、履行、解释等所发生的或与本合同有关的一切争议，双方应通过 友好协商解决。 12.2 若协商不能解决的，争议之任何一方均有权向甲方所在地人民法院提起诉讼。 第十三章合同变更和解除 13.1 合同变更：甲乙双方在符合法律规定的前提下，经友好协商，双方同意后可以对本合 同进行修改或补充，达成新的合同内容。 13.2 变更的范围：标的数量和质量、合同价款、履行的期限、地点、方式、合同主体。 13.3 合同协商解除：甲乙双方在法律规定的条件下，经友好协商，双方同意后可以在原来 约定的合同有效期内提前终止本合同。 13.5 合同变更或解除后，甲乙双方不需要再按原合同履行，但由于合同变更或解除致使一 方遭受损失的，除依法可以免除责任以外，对造成损失负有责任的一方应赔偿对方的损失。 13.6 合同的变更或解除，只有甲乙双方授权代表在书面文件上签字、单位盖章后方可生效。 第十四章其他 14.1 双方承认已阅读过此合同，理解并同意其条款和条件。而且，双方同意将本合同文本 作为双方合同的完整的和唯一的表述，以取代此前双方有关此项目内容的所有口头、书面、 及其他通信方式中的表述。 14.2 本合同及具体项目合同的成立、效力和解释以及根据本协议及具体项目合同所进行的 合作受中华人民共和国法律管辖。 14.3 双方确定，在本合同有效期内，甲方指定高宇为甲方项目负责人、联系人，乙方指定 何文宇为乙方项目负责人、联系人。本合同自双方签字并盖章后成立并生效。 14.4 所有附件及本项目的招投标文件、成交通知书等均是本合同不可分割的组成部分，与 本合同具有同等法律效力。 14.5 本合同生效后，未经双方协商一致，任何一方不得擅自对本合同进行变更或修改。经 双方协商一致，对本合同进行变更或修改的，应签署书面文件，且须经双方签字并盖章。 14.6 合同未尽事宜，双方可以协商签订补充协议，补充协议与本合同具有同等法律效力。 对本合同的任何补充，均应签署书面文件， 且须经双方签字并盖章。补充协议中的条款若与 本合同中的相应条款发生冲突， 则以补充协议中的条款为准。 其他未尽事宜按招投标文件就 高就优执行。 14.7 本合同一式捌份，甲方执陆份，乙方执贰份，具有同等法律效力。 附件：1.中标通知书；2.项目金额；3.项目技术指标及参数；4.保密协议；5.安全生产承诺书 甲方：北京大学第一医院宁夏妇女儿童 医院（宁夏回族自治区妇幼保健院） （公章）乙方：xx 公司 （公章） 法定代表人或其授权委托人 签 字： 分管领导： 科室负责人： 经办人： 法定代表人或其授权委托人 签 字： 联 系 人： 联系人电话： 签字日期: 年 月 日 签字日期： 年 月 日 地址：银川市金凤区湖畔路127 号 电话：0951-7819573 地址： （以下无正文，仅供双方签章） 附件1.中标通知书 2.项目金额； 3.项目技术指标及参数； 附件4：保密协议 甲方：北京大学第一医院宁夏妇女儿童医院（宁夏回族自治区妇幼保健院） （以下简称“甲 方” ） ； 乙方：xx 公司（以下简称“乙方” ） 鉴于乙方受甲方委托承担xx 项目，将涉及医院的相关业务系统的系统结构、系统源代码、 系统账号及口令、数据库内容、业务核心数据，项目建设需了解的业务流程、各业务系统相 关数据和信息， 并获取相关文档资料， 现就文档资料、数据和信息使用所涉及的保密信息达 成以下协议： 一、保密信息 1.本协议所称“保密信息”是指由本协议甲方以任何形式（包括但不限于：书面，口头，或 以样品、范本、计算机程序或其他形式）向本协议乙方披露的任何信息和资料，以及乙方在 工作中接触到的一切属于甲方的信息和资料。 2.上述“保密信息”包括但不限于：相关业务系统的系统结构、系统原代码、系统帐号及口 令、数据库内容、业务核心数据及业务流程、各业务系统相关数据和信息内容，以及其他专 有信息等（以下统称“保密信息” ） 。 3.“保密信息”不包括下列信息： （1）在生效日之前或之后成为公众所知（非因乙方的过错） ； （2）乙方没有使用保密信息而独立开发的信息； （3）乙方从第三方合法获取的信息。 二.权利保证 甲方保证其向乙方披露的专有信息不侵犯任何第三方的知识产权及其它合法权益。 三.保密义务 1.乙方从甲方获得所有保密信息，乙方仅对保密信息具有使用权，而没有所有权、知识产权 及解释权。 2.甲方所披露的保密信息只能被乙方用于本项目的实施工作， 不得将甲方所披露的保密信息 用于其它任何目的。 3.乙方有义务妥善保管保密信息。乙方承诺采取包括但不限于身份验证、访问控制、数据加 密等具体措施以保证保密信息不被泄露， 此种措施应与或超过甲方对自己的保密信息的妥善 保管措施。 4.乙方仅能向有知悉必要的乙方人员（包括但不限于雇员或顾问）披露保密信息。一经发现 对保密信息的任何未经授权的披露或乙方及其人员违反本协议时， 乙方应立即通知甲方， 并 采取措施防止进一步未经授权而使用保密信息。 5.未经甲方的事先书面批准，乙方不得直接或间接以任何形式或任何方式把保密信息和/或 其中的任何部分，披露、 透露给任何第三方或者公开，乙方保证不向任何第三方披露本协议 的存在或本协议的任何内容。 6.在甲方书面要求时，乙方应返还保密信息的所有原件、复印件、复制品、及所有其他载有 保密信息的载体，或依甲方的要求，销毁了上述保密资料，并提供相关有效证明。未经甲方 书面许可，乙方不得处分任何书面的或其他有形保密信息。 7.乙方应当告知并以适当方式要求其参与本项工作之雇员遵守本协议规定， 乙方人员向第三 方披露保密信息，或依据该保密信息向第三方做出任何建议，都被视为乙方违反本协议。 8.乙方参加本项目的所有人员必须与乙方签有正式的保密协议， 并且该人员在知晓保密信息 前应已充分了解本协议的内容。 9.乙方不得以任何方式，包括但不限于复制、仿造、转述、口述、总结等方式来传播或使用 保密信息。 四、违约责任 乙方违反本协议任何规定， 均视为违约， 应当对其违约行为给甲方造成的损失承担赔偿责任。 五、保密期限 自甲方第一次向乙方披露任何保密信息之日后起直至该保密信息合法公开时止， 乙方不得向 任何第三方披露该保密信息。 如果所涉及的保密信息依照国家主管机关或相关法律、 法规另 有规定的，适用其相关规定。任何一方违反本保密协议，乙方应赔偿甲方因此遭受的损失。 六、争议解决 本协议适用中华人民共和国法律。 凡因执行本协议所发生的或与本协议有关的一切争议， 双 方应通过友好协商解决。如果协商不能解决时，双方均可向甲方所在地人民法院诉讼解决。 七、其他 1.如果有关权威机构认定本协议的条文无法履行或者无效， 如果这种认定不能使本协议整体 无法履行或者无效， 在此情况下， 只能修改该条文， 且将这种改动解释为在适用法律或适用 法庭判决的范围内实现该无法履行或无效条款预定的目标。 2.本协议作为双方签订合同附件的组成部分一同签订。 3.对于本协议条款的修改，只有经双方授权的代表书面签署方可生效并对双方具有约束力。 （以下无正文，仅供双方签章） 甲方：北京大学第一医院宁夏妇女儿童 医院（宁夏回族自治区妇幼保健院） （公章）乙方：xx 公司 （公章） 法定代表人或其授权委托人 签 字： 分管领导： 科室负责人： 经办人： 法定代表人或其授权委托人 签 字： 联 系 人： 联系人电话： 签字日期: 年 月 日 签字日期： 年 月 日 地址：银川市金凤区湖畔路127 号 电话：0951-7819573 地址： 附件5：安全生产责任承诺书 第八章投标文件格式 服务类政府采购 投标文件 项目名称： 政府采购计划编号： 项目编号： 标段（包号） ： 投标供应商： （电子签章） 年 月 日 一、投标函 致： （采购人/采购代理机构名称） 我（单位/本人，以下统称我方）自愿参加（项目名称、采购计 划编号）的投标,并做出如下承诺： 一、 我方授权(姓名和职务)代表我方 （投标供应商的名称） 全权 处理本项目投标的有关事宜。 二、 我方愿意按照采购文件规定的各项要求， 向采购人提供所需 的服务和相关配套的货物（工程） ，我方投标价为人民币（大 写） ： ； （小写） ： 我方愿意按照采购文件规定的各项要求， 向采购人提供所需的 货物和相关服务。 三、我方已详细审查全部采购文件，包括所有补充通知（如有） ， 完全理解并同意放弃对这方面有不明、误解的权利。 四、我方已提供投标人（供应商）须知规定的全部投标文件，包 括纸质版文件____份，电子版（NXTF）文件____份，电子版（nNXTF） 文件____份。 五、我方承诺：自投标截止时间至本项目发布中标公告为止，撤 销投标的、 或者中标后不依法与采购人签订合同、 或者中标后不按照 本采购文件规定缴纳招标代理费的， 我方将向采购人、 采购代理机构 支付相应的违约赔偿金（不低于投标保证金的金额） 。 六、 我方愿意按照采购文件的要求， 提供与项目有关的所有文件 资料， 并保证我方所有文件资料的合法性、 真实性、 完整性和准确性。 七、 一旦我方被确定为中标供应商， 我方将严格履行合同规定的 责任和义务， 保证于合同签字生效后按照约定时间完成项目， 并交付 采购人验收。 投标人： （盖公章） 地址： 电话： 传真： 电子邮件： 邮编： 法定代表人或委托代理人(签字或签章)： 日期： 二、开标一览表 项目名称 项目编号 标段（包号） 投标价格 人民币小写(元): （项目报价方式为总价招标 的填写此栏） 人民币大写: （项目报价方式为总价招标的同 时填写此栏） 单价： （元） （项目报价方式为单价招标的填 写此栏） 费率： 按照****（招标文件中规定的） 标准的 %（项 目报价方式为费率招标的填写此栏） 折扣：按照****（招标文件中规定的）标准的 折（项 目报价方式为折扣招标的填写此栏） 合同履行期限 投标有效期 备 注 1.投标价格为供应商考虑各种因素（含折扣、优惠等） 的最终报价。 2.投标人提出的赠送不作为评标依据。 投标人： （盖公章） 法定代表人或委托代理人(签字或签章)： 日期： 三、投标价格明细表 （此表格需固化在投标文件编制软件中由投标人逐项填写， 并在填写 后将中标供应商此表内容同步至政府采购管理系统） 序 号 名称 服务内容 单价 （元）/ 费率 （%） /折扣 （折） 数量 总价（元） 中小 企业 （中型 /小型/微 型） 1 2 3 4 5 6 7 8 … 合计 投标人： （盖公章） 法定代表人或委托代理人(签字或签章)： 日期： 四、评审因素和内容响应详情 智慧后勤综合服务平台配套硬件投标明细表： 序号 产品名称 数量 品牌、规格型号 制造商 1 第三方系统数据对接开发： 安 防系统对接网关 1 台 2 第三方系统数据对接开发： 消 防系统对接网关 1 台 3 第三方系统数据对接开发： 楼 控系统对接网关 1 台 4 第三方系统数据对接开发： 网 络安全数据互联主机 1 台 5 第三方系统数据对接开发： 智 慧医院运行保障系统基础服 务主机 1 台 6 智能电话调度网关 1 台 7 智能工单处理服务站 1 台 8 网络控制器 32 个 9 能耗计量系统终端数据采集 器控制箱 18 个 10 开关电源 18 个 11 风机盘管温控器 694 个 12 485 通讯线 15000 米 13 风机盘管系统接口 1 套 注：投标人须按上表据实填写所投硬件的品牌、规格型号以及制造商。 （一）商务要求响应表 序 号 商务条款 招标文件规定 投标文件响应 偏离 情况 备注 商务条款要求 商务条款响应 1 2 3 4 5 6 7 8 9 … … … … … 注： 如响应内容较多可在表格中填写基本响应内容， 在本表后附件中 上传详细响应内容或相关资料 （包括但不限于佐证材料或投标供应商 自行认为需要提供的相关资料）扫描件。 投标供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 附件： （二）技术要求响应表 序 号 标的名 称 招标文件规定 投标文件响应情况 偏离 情况 备注 （页码） 技术、参数指标要求 技术、参数指标响 应 1 2 3 4 5 … … … … … … 注： 如响应内容较多可在表格中填写基本响应内容， 在本表后附件中 上传详细响应内容或相关资料 （包括但不限于佐证材料或投标供应商 自行认为需要提供的相关资料）扫描件。 投标供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 附件： （三）类似业绩 注：招标文件评审因素中未要求提供类似业绩的可不提供。 （四）售后服务 注： 投标供应商应根据招标文件采购内容及评审因素中售后服务条款 提供。 （五）服务方案 注：投标供应商应根据招标文件采购内容及评审因素中相关要求提 供。 （六）人员配备 注：投标供应商应根据招标文件采购内容及评审因素中相关要求提 供。 （七）其他评审因素内容 注： 投标供应商应根据招标文件采购内容及评审因素中其他内容条款 提供。 五、资格证明文件 （一） 提供在中华人民共和国境内注册的法人或者其他组织的营业执 照（或事业单位法人证书，或社会团体法人登记证书），如供应商为 自然人的需提供自然人身份证明证明材料 提供在中华人民共和国 境内注册的法人或者其 他组织的营业执照 （或事 业单位法人证书， 或社会 团体法人登记证书） ， 如 供应商为自然人的需提 供自然人身份证明 如供应商是企业（包括合伙企业），应提供在 工商部门注册的有效 “企业法人营业执照” 或“ 营业执照”；如是事业单位，应提供有效的“事 业单位法人证书” ； 非企业专业服务机构的，应 提供执业许可证等证明文件； 是个体工商户， 应 提供有效的“个体工商户营业执照”；自然人 ，应提供有效的自然人身份证明。 （二）法人/负责人身份证明及授权委托书 授权委托书 法人/负责人授权委托书、法人及被授权人身份 证复印件 （法定代表人直接响应可不提供， 但须 提供法定代表人身份证复印件） 法人/负责人/自然人身份证明 致： （采购人/采购代理机构名称） （姓名 ）现任（供应商名称）、（担任）职务，为法定代表 人（企业或单位负责人），特此证明。 法定代表人身份证号： 法定代表人联系电话： 法定代表人签字或签章： 供应商： （电子签章） 日期： 年 月 日 注：自然人可以只附身份证，不填写本表。 附：法定代表人/企业或单位负责人法人身份证（正反面） 法定代表人授权委托书 致： （采购人/采购代理机构名称） 本授权书声明： （供应商名称）的（法人代表姓名、职务） 授权（被授权人的姓名、职务）为我方就（采购项目名称）、（ 标段）项目响应活动的合法代理人，以我方名义全权处理与该项目 有关的一切事务。 本授权书于 年 月 日签字生效,特此声明。 供应商（电子签章）： 法定代表人（签字或签章）： 身份证号： 联系电话： 委托代理人（签字或签章）： 身份证号： 联系电话： 注：自然人响应的或法定代表人响应的无需提供授权委托书。 附：被授权人身份证（正反面） （三）提供具有良好的商业信誉和健全的财务会计制度承诺函 提供具有良好的商业信誉 和健全的财务会计制度 提供书面承诺或声明，或提供相应证明材料。 致： （采购人/采购代理机构名称） 我单位在参与（项目名称）（项目编号： ）（标段） 项目的政府采购活动中承诺如下： 我单位具有《中华人民共和国政府采购法》 《中华人民共和国政 府采购法实施条例》 及采购文件资格要求规定的良好的商业信誉和健 全的财务会计制度。 若我单位以上承诺不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 说明：供应商可自行选择是否提供本承诺函，若不提供本承诺函，应 按《中华人民共和国政府采购法》 《中华人民共和国政府采购法实施 条例》及采购文件资格要求提供相应的证明材料。 （供应商承诺良好的商业信誉和健全的财务会计制度； 若为联合体响 应，联合体各方均需提供承诺书） （四）提供履行合同所必需的设备和专业技术能力的承诺函 提供履行合同所必需的 设备和专业技术能力 提供书面承诺或声明，或提供相应证明材料。 致：（采购人/采购代理机构名称） 我单位在参与（项目名称）（项目编号： ）（标段） 项目的政府采购活动中承诺如下： 我单位具有《中华人民共和国政府采购法》 《中华人民共和国政 府采购法实施条例》 及采购文件资格要求规定的履行合同所必需的设 备和专业技术能力。 若我单位以上承诺不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： （五）具有依法缴纳税收和社会保障资金的良好记录的承诺函 具有依法缴纳税收和社会保障 资金的良好记录 提供书面承诺或声明，或提供相应证明材 料。 致： （采购人/采购代理机构名称） 我单位在参与（项目名称）（项目编号： ）（标段） 项目的政府采购活动中承诺如下： 我单位具有《中华人民共和国政府采购法》 《中华人民共和国政 府采购法实施条例》 及采购文件资格要求规定的依法缴纳社会保障资 金和税收的良好记录。 若我单位以上承诺不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 说明：供应商可自行选择是否提供本承诺函，若不提供本承诺函，应 按《中华人民共和国政府采购法》 《中华人民共和国政府采购法实施 条例》及采购文件资格要求提供相应的证明材料。 （供应商承诺依法缴纳社会保障资金和税收； 若为联合体响应， 联合 体各方均需提供承诺书） （六） 提供参加采购活动前三年内在经营活动中没有重大违法记录承 诺函 提供参加采购活动前三 年内在经营活动中没有 重大违法记录 提供书面承诺或声明，或提供相应证明材料。 致： （采购人/采购代理机构名称） 我单位在参与（项目名称）（项目编号： ）（标段） 项目的政府采购活动中承诺如下： 我单位符合《中华人民共和国政府采购法》 《中华人民共和国政 府采购法实施条例》 及采购文件资格要求规定的 “参加政府采购活动 前三年内，在经营活动中没有重大违法记录”的要求。 若我单位以上承诺不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 说明：供应商可自行选择是否提供本承诺函，若不提供本承诺函，应 按《中华人民共和国政府采购法》 《中华人民共和国政府采购法实施 条例》及采购文件资格要求提供相应的证明材料。 （申请人承诺参加 政府采购活动前三年内， 在经营活动中没有重大违法记录； 若为联合 体响应，联合体各方均需提供承诺书） （七）落实政府采购政策要求的资格证明文件 中小企业声明函（服务） 本公司（联合体）郑重声明，根据《政府采购促进中小 企业发展管理办法》 （财库﹝2020﹞46 号） 的规定， 本公司 （联 合体）参加（单位名称）的（项目名称）采购活动，工程的施 工单位全部为符合政策要求的中小企业（或者：服务全部由 符合政策要求的中小企业承接） 。相关企业（含联合体中的 中小企业、 签订分包意向协议的中小企业） 的具体情况如下： 1.（标的名称） ， 属于 （采购文件中明确的所属行业） ； 承建（承 接）企业为（企业名称） ， 从业人员 人，营业收入为 万 元，资产总额为 万元1 ，属于（中型企业、小型企业、微型 企业） ； 2.（标的名称） ， 属于 （采购文件中明确的所属行业） ； 承建 （承 接）企业为（企业名称） ， 从业人员 人，营业收入为 万 元，资产总额为 万元，属于（中型企业、小型企业、微型 企业） ； …… 以上企业，不属于大企业的分支机构，不存在控股股东 为大企业的情形，也不存在与大企业的负责人为同一人的情 形。 本企业对上述声明内容的真实性负责。如有虚假，将依 法承担相应责任。 企业名称（盖章） ： 日期： 1 从业人员、营业收入、资产总额填报上一年度数据，无上一年度数据的新成立企业可不填报。 中小企业划型标准规定 一、根据《中华人民共和国中小企业促进法》和《国务院关于进 一步促进中小企业发展的若干意见》(国发〔2009〕36 号)，制定本 规定。 二、中小企业划分为中型、小型、微型三种类型，具体标准根据 企业从业人员、营业收入、资产总额等指标，结合行业特点制定。 三、本规定适用的行业包括：农、林、牧、渔业，工业（包括采 矿业，制造业，电力、热力、燃气及水生产和供应业），建筑业，批 发业，零售业，交通运输业（不含铁路运输业），仓储业，邮政业， 住宿业，餐饮业，信息传输业（包括电信、互联网和相关服务），软 件和信息技术服务业，房地产开发经营，物业管理，租赁和商务服务 业，其他未列明行业（包括科学研究和技术服务业，水利、环境和公 共设施管理业，居民服务、修理和其他服务业，社会工作，文化、体 育和娱乐业等）。 四、各行业划型标准为： （一）农、林、牧、渔业。营业收入20000 万元以下的为中小微 型企业。其中，营业收入500 万元及以上的为中型企业，营业收入 50 万元及以上的为小型企业，营业收入50 万元以下的为微型企业。 （二）工业。从业人员1000 人以下或营业收入40000 万元以下 的为中小微型企业。 其中， 从业人员300 人及以上， 且营业收入2000 万元及以上的为中型企业；从业人员20 人及以上，且营业收入300 万元及以上的为小型企业；从业人员20 人以下或营业收入300 万元 以下的为微型企业。 （三） 建筑业。 营业收入80000 万元以下或资产总额80000 万元 以下的为中小微型企业。其中，营业收入6000 万元及以上，且资产 总额5000 万元及以上的为中型企业；营业收入300 万元及以上，且 资产总额300 万元及以上的为小型企业； 营业收入300 万元以下或资 产总额300 万元以下的为微型企业。 （四） 批发业。 从业人员200 人以下或营业收入40000 万元以下 的为中小微型企业。其中，从业人员20 人及以上，且营业收入5000 万元及以上的为中型企业；从业人员5 人及以上，且营业收入1000 万元及以上的为小型企业；从业人员5 人以下或营业收入1000 万元 以下的为微型企业。 （五） 零售业。 从业人员300 人以下或营业收入20000 万元以下 的为中小微型企业。其中，从业人员50 人及以上，且营业收入500 万元及以上的为中型企业；从业人员10 人及以上，且营业收入100 万元及以上的为小型企业；从业人员10 人以下或营业收入100 万元 以下的为微型企业。 （六）交通运输业。从业人员1000 人以下或营业收入30000 万 元以下的为中小微型企业。其中，从业人员300 人及以上，且营业收 入3000 万元及以上的为中型企业； 从业人员20 人及以上， 且营业收 入200 万元及以上的为小型企业； 从业人员20 人以下或营业收入200 万元以下的为微型企业。 （七） 仓储业。 从业人员200 人以下或营业收入30000 万元以下 的为中小微型企业。 其中， 从业人员100 人及以上， 且营业收入1000 万元及以上的为中型企业；从业人员20 人及以上，且营业收入100 万元及以上的为小型企业；从业人员20 人以下或营业收入100 万元 以下的为微型企业。 （八）邮政业。从业人员1000 人以下或营业收入30000 万元以 下的为中小微型企业。其中，从业人员300 人及以上，且营业收入 2000 万元及以上的为中型企业；从业人员20 人及以上，且营业收入 100 万元及以上的为小型企业；从业人员20 人以下或营业收入100 万元以下的为微型企业。 （九） 住宿业。 从业人员300 人以下或营业收入10000 万元以下 的为中小微型企业。 其中， 从业人员100 人及以上， 且营业收入2000 万元及以上的为中型企业；从业人员10 人及以上，且营业收入100 万元及以上的为小型企业；从业人员10 人以下或营业收入100 万元 以下的为微型企业。 （十） 餐饮业。 从业人员300 人以下或营业收入10000 万元以下 的为中小微型企业。 其中， 从业人员100 人及以上， 且营业收入2000 万元及以上的为中型企业；从业人员10 人及以上，且营业收入100 万元及以上的为小型企业；从业人员10 人以下或营业收入100 万元 以下的为微型企业。 （十一）信息传输业。从业人员2000 人以下或营业收入100000 万元以下的为中小微型企业。其中，从业人员100 人及以上，且营业 收入1000 万元及以上的为中型企业； 从业人员10 人及以上， 且营业 收入100 万元及以上的为小型企业；从业人员10 人以下或营业收入 100 万元以下的为微型企业。 （十二） 软件和信息技术服务业。 从业人员300 人以下或营业收 入10000 万元以下的为中小微型企业。 其中， 从业人员100 人及以上， 且营业收入1000 万元及以上的为中型企业；从业人员10 人及以上， 且营业收入50 万元及以上的为小型企业； 从业人员10 人以下或营业 收入50 万元以下的为微型企业。 （十三）房地产开发经营。营业收入200000 万元以下或资产总 额10000 万元以下的为中小微型企业。其中，营业收入1000 万元及 以上，且资产总额5000 万元及以上的为中型企业；营业收入100 万 元及以上， 且资产总额2000 万元及以上的为小型企业； 营业收入100 万元以下或资产总额2000 万元以下的为微型企业。 （十四） 物业管理。 从业人员1000 人以下或营业收入5000 万元 以下的为中小微型企业。其中，从业人员300 人及以上，且营业收入 1000 万元及以上的为中型企业；从业人员100 人及以上，且营业收 入500 万元及以上的为小型企业；从业人员100 人以下或营业收入 500 万元以下的为微型企业。 （十五）租赁和商务服务业。从业人员300 人以下或资产总额 120000 万元以下的为中小微型企业。其中，从业人员100 人及以上， 且资产总额8000 万元及以上的为中型企业；从业人员10 人及以上， 且资产总额100 万元及以上的为小型企业；从业人员10 人以下或资 产总额100 万元以下的为微型企业。 （十六） 其他未列明行业。 从业人员300 人以下的为中小微型企 业。其中，从业人员100 人及以上的为中型企业；从业人员10 人及 以上的为小型企业；从业人员10 人以下的为微型企业。 五、企业类型的划分以统计部门的统计数据为参考。 六、 本规定适用于在中华人民共和国境内依法设立的各类所有制 和各种组织形式的企业。 个体工商户和本规定以外的行业， 参照本规 定进行划型。 七、 本规定的中型企业标准上限即为大型企业标准的下限， 国家 统计部门据此制定大中小微型企业的统计分类。 国务院有关部门据此 进行相关数据分析，不得制定与本规定不一致的企业划型标准。 八、 本规定由工业和信息化部、 国家统计局会同有关部门根据 《国 民经济行业分类》修订情况和企业发展变化情况适时修订。 九、 本规定由工业和信息化部、 国家统计局会同有关部门负责解 释。 十、本规定自发布之日起执行，原国家经贸委、原国家计委、财 政部和国家统计局2003 年颁布的《中小企业标准暂行规定》同时废 止。 2、残疾人福利性单位声明函 本单位郑重声明，根据《财政部民政部中国残疾人联合会关 于促进残疾人就业政府采购政策的通知》（财库〔2017〕141 号） 的规定， 本单位为符合条件的残疾人福利性单位， 且本单位参加贵单 位的 项目采购活动由本单位提供服务。 本单位对上述声明的真实性负责。 如有虚假， 将依法承担相应责 任。 供应商名称： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注1：应填写服务提供单位。 注2：非残疾人福利性单位无须填写。 3、监狱企业声明函 本单位郑重声明，根据《财政部司法部关于政府采购支持监狱 企业发展有关问题的通知》（财库〔2014〕68 号）的规定，本单位 为符合条件的监狱企业， 且本单位参加贵单位的 项目采购 活动由本单位提供服务。 本单位对上述声明的真实性负责。 如有虚假， 将依法承担相应责 任。 供应商名称： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注1：应填写服务提供单位。 注2：非监狱企业无须填写。 （八）本项目的其他资格要求 六、符合性审查响应详情 （一）联合体投标声明函 致： （采购人/采购代理机构名称） 我方郑重声明， 我单位与 组建联合体参与本项 目投标， 联合体各方未再单独参加或者与其他供应商另外组成联合体 参加本项目同一合同项下的投标， 如有虚假， 我方愿承担相关法律责 任。 投标供应商名称： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注：不接受联合体投标项目及非联合体投标供应商无须填写。 （二）投标供应商关联性企业说明 1、与投标供应商存在关联企业明细表 序号 单位名称 关联关系 1 2 … 投标供应商名称： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注： 投标供应商存在 “单位负责人为同一人或者存在直接控股、 管理关系的不同供应商” 时， 应据实填写1 明细表。 2、声明函 致： （采购人/采购代理机构名称） 我方郑重声明， 我单位不存在与本单位负责人为同一人或者存在 直接控股、管理关系的其他相关单位，如有虚假，我方愿承担相关法 律责任。 投标供应商名称： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注：与投标供应商无关联企业情形的须提供2 声明函。 （三）投标供应商未对本项目提供过有关服务的声明函 致： （采购人/采购代理机构名称） 我单位在参与（项目名称） （项目编号： ） （标段）项 目的政府采购活动中声明如下： 我单位没有为本项目提供过整体设计、规范编制或者项目管理、 监理、检测等服务。 若我单位以上承诺不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 投标供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： （四）投标供应商对本项目报价的声明函 致： （采购人/采购代理机构名称） 我单位在参与（项目名称） （项目编号： ） （标段）项 目的政府采购活动中声明如下： 我单位报价为 ，未超过本项目预算价（最高限价） 。 我公司所报的价格明细在合同履行过程中是固定不变的， 不以任 何理由予以变更。 我公司投标文件中无任何包含价格调整的要求。 若我单位以上声明不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 投标供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： （五）投标供应商对本项目投标文件附加条件的声明函 致： （采购人/采购代理机构名称） 我单位在参与（项目名称） （项目编号： ） （标段）项 目的政府采购活动中声明如下： 我单位投标文件中附加条件如下： 1、 2、 3、 ... 若我单位以上声明不实， 自愿承担提供虚假材料谋取中标、 成交 的法律责任。 投标供应商： （电子签章） 法定代表人或委托代理人(签字或签章)： 日期： 注1：投标文件中无附加条件的无须填写。 注2：投标供应商应谨慎在投标文件中提出附加条件，如提出的附加条件采购人无法接受， 其投标将被认定为无效投标。 （六）招标文件中其他符合性审查内容 注：本模块包括招标文件中其他（未提供即认定为无效投标）的条款。