四川省眉山市医疗保障局眉山市医保信息系统应用软件运维服务项目单一来源成交公告1672

　1

　眉山市医疗保障局 眉山市医保信息系统应用软件运维服务项目

　单一来源采购文件

　 项目编号：5114012020000917

　 眉山市医疗保障局 四川国际招标有限责任公司 共同编制 二 O 二 O 年八月

　 2 录 目 录

　第一章报价邀请 ........................................... 3 第二章供应商须知 ......................................... 6 第三章资格证明文件 ...................................... 11 第四章货物需求一览表及技术规格 .......................... 13 第五章报价文件格式 ...................................... 39 第六章合同主要条款 ...................................... 50

　 3 第一章

　报价邀请

　四川国际招标有限责任公司受眉山市医疗保障局委托，对眉山市医疗保障局眉山市医保信息系统应用软件运维服务项目 采用单一来源方式采购,现诚邀贵公司参加本项目的报价。

　一、 采购 编号：5114012020000917

　二、采购名称：眉山市医疗保障局眉山市医保信息系统应用软件运维服务项目

　三、 采购 内容：

　本项目一个包，采购眉山市医保信息系统应用软件运维服务。（详见第 四章）。

　拟定供应商：广州华资软件技术有限公司

　四、资金来源：

　地方财政资金

　五、供应商资格要求：

　1.具有独立承担民事责任的能力； 2.具有良好的商业信誉和健全的财务会计制度； 3.具有履行合同所必须的设备和专业技术能力； 4.具有依法缴纳税收和社会保障资金的良好记录； 5.参加本次政府采购活动前三年内，在经营活动中没有重大违法记录； 6.法律、行政法规规定的其他条件； 7．按照规定购买了单一来源采购文件。

　六、严禁参加本次采购活动的供应商

　根据《关于在政府采购活动中查询及使用信用记录有关问题的通知》（财库〔2016〕125 号）的要求，采购人/采购代理机构将通过“信用中国”网站（www.creditchina.gov.cn）、“中国政府采购网”网站（www.ccgp.gov.cn）等渠道查询供应商在采购公告发布之日前的信用记录并保存信用记录结果网页截图，拒绝列入失信被执行人名单、重大税收违法案件当事人名单、政府采购严重违法失信行为记录名单中的供应商报名参加本项目的采购活动（以联合体形式参加本项目采购活动，联合体成员存在不良信用记录的，视同联合体存在不良信用记录）。

　七、报价保证金本项目不适用

　 4 八、报价有效期：报价后 0 90 天。

　九、报价文件正本一份，副本两份，及电子版一份

　十、成交服务费

　领取成交通知书时，成交人按规定的标准向采购代理机构一次性交清成交服务费。

　成交服务费标准：以成交金额作为计算基数，参照原国家发展计划委员会文件计价格［2002］1980 号文件及发改办价格[2003]857 号通知规定下浮 20%计取，由成交人承担。

　服务费收款单位：四川国际招标有限责任公司 开户行：中国民生银行股份有限公司成都分行营业部 银行账号：9902001200795084 十一、购买采购文件的时间、地点及售价：

　单一来源采购文件自 2020 年 9 月 1 日至 2020 年 9 月 2 日 ,每天上午 9:00- 12:00 ， 下 午 13:00-17:00 （ 北 京 时 间 ）

　节 假 日 除 外 在 我 司 指 定 网 站(http://sale.scbid.net)购买，具体购买流程详见该网站的“在线购买流程”。单一来源采购文件售后不退，协商资格不能转让。

　十二、递交报价文件截止时间( ( 以下简称报价截止时间) ) 地点：

　时间：

　2020 年 9 月 4 日 14:30(北京时间) 地点:

　四川国际招标有限责任公司 开标厅（四川省成都市高新区天府大道中段 800 号天府四街 66 号航兴国际广场 1 号楼 3 楼）

　十三、谈判时间及地点：

　时间：2020 年 9 月 4 日 14:30(北京时间) 地点:

　四川国际招标有限责任公司 开标厅（四川省成都市高新区天府大道中段 800 号天府四街 66 号航兴国际广场 1 号楼 3 楼）

　十四、供应商信用融资：

　1、根据《四川省财政厅关于推进四川省政府采购供应商信用融资工作的通知》（川财采[2018]123 号）文件要求，为助力解决政府采购中标、成交供应商资金不足、融资难、融资贵的困难，促进供应商依法诚信参加政府采购活动，有融资需求的供应商可根据四川政府采购网公示的银行及其“政采贷”产品，自行选择符合自身情况的“政采贷”银行及其产品，凭中标（成交）通知书向银行提出贷款意向申请（具体内容详见招标文件附件“川财采[2018]123 号”）。

　2、2、按照眉山市财政局《关于贯彻落实“政采贷”工作的通知》（眉财采〔2019〕3 号）文件要求，本项目支持“政采贷”信用融资贷款。“政采贷”产品信息查询渠道详见“四川政府采购网”—“相关模块”—“政采贷”。

　 5 十五、 联系人及联系电话

　采购人：眉山市医疗保障局 地

　址：四川省眉山市东坡区学士街 556 号 联系人：徐老师 电

　话：13778897437 采购代理机构：四川国际招标有限责任公司 地

　址：四川省成都市高新区天府大道中段 800 号天府四街 66 号航兴国际广场 1 号楼 17 楼

　邮

　编：610000 联 系 人：王女士 联系电话：028-87797107

　13111881606 传

　真：028-87793161

　 6 第二章

　供应商须知

　一、总

　则

　 1 1 ．资金来源

　1．1

　本采购项目资金来源见第一章

　《报价邀请》 2 2 ．合格的供应商、合格的货物与服务必须满足下列条件: :

　2．1

　符合第一章《报价邀请》中供应商资格要求并提供了相应资质证明文件的供应商。

　2.2供应商在过去和现在都不应与为采购人在本报价邀请下拟采购的货物从事设计，编制技术规格和其他文件提供咨询服务的公司及其附属机构有任何直接和间接的联系。

　2.3

　中华人民共和国政府拥有的企业只有在法律上和财务上独立，根据商业法规运营，并不是采购人的附属机构才可以参与报价。

　2.4 合格的货物与服务必须满足采购文件中技术、商务要求。

　3 3 ．报价费用

　3．1 供应商应承担所有与编写和提交报价文件有关的费用，不论报价的结果如何，采购人和采购代理机构在任何情况下均无义务和责任承担这些费用。

　二、采购文件

　4 4 ．采购文件构成

　4．1

　采购文件包括目录中的内容 4．2

　供应商应认真阅读采购文件中所有的事项、格式、条款和规范等要求。如果供应商没有按照采购文件要求提交全部资料或者报价文件没有对采购文件在各方面都作出实质性响应，是供应商的风险。没有实质上响应采购文件要求的报价文件将被拒绝。

　5 5 ．采购文件的澄清

　5．1

　任何要求对采购文件进行澄清的供应商，均应在递交报价文件截止时间2天以前按报价邀请书中的通讯地址以书面形式如电传、电报、传真等通知采购代理机构，采购代理机构对报价截止时间3天以前收到的任何澄清要求将以书面形式予以答复，同时将书面答复通知每个购买采购文件的

　 7 供应商，答复中包括所问问题，但不包括问题的来源。

　6 6 ．采购文件的修改

　6．1

　在报价截止时间3日前，无论出于何种原因，采购人和采购代理机构可主动地或在解答供应商提出的澄清问题时对采购文件进行修改。

　6．2

　采购文件的修改将以书面形式，包括传真和电传，通知所有购买采购文件的供应商，并对其具有约束力。供应商应立即以电报、电传、传真形式确认已收到修改文件。

　6．3

　为使供应商编写报价文件时有充分时间对采购文件的修改部分进行研究，采购人和采购代理机构可以自行决定，酌情延长报价截止时间。

　三、报价文件的编制

　7 7 ．报价的语言

　7．1

　供应商提交的报价文件以及供应商与采购人和采购代理机构就有关报价的所有来往函电均应使用中文。供应商可以提交用其他语言打印的资料，但有关的段落必须翻译成中文，在有差异和矛盾时以中文为准。

　8 8 ． 报价

　8．1

　供应商应在报价文件中的报价表上标明，本合同拟提供货物的单价为准。任何有选择的报价将不予接受，每种货物只允许有一个报价。

　8．2

　详细填写分项报价表。

　8．3

　供应商按照上述第8．2条要求分类报价，其目的是便于采购人和采购代理机构评审，但在任何情况下并不限制采购人以任何条款签订合同的权利。

　8．4 报价表里标明的价格在合同执行过程中是固定不变的，不得以任何理由予以变更。以可调整的价格提交的报价将作为非响应性报价而予以拒绝。

　9 9 ．报价货币

　9．1

　报价应以人民币报价。

　10 ．证明供应商合格和资格的文件

　10.1按照报价邀请中供应商资格要求，提供真实、有效的证明文件

　 8 11 ．证明货物的合格性和符合采购文件规定的文件

　11．1

　供应商应提交根据采购文件要求提供的所有货物及其服务的合格性以及符合采购文件规定的证明文件，并作为其报价文件的一部分。

　11．2

　证明货物和服务与采购文件的要求相一致的文件可以是文字资料、图纸和数据，供应商应提供：

　(1) 货物主要技术指标和运行性能的详细说明； (2)与采购文件技术规格的要求进行对照，指出自己提供货物和服务是否做出实质性的响应；并填报技术规格响应/偏离表 11．3

　供应商在阐述第11．2时应注意：采购文件技术规格中指出的工艺、材料和设备的标准以及参照的牌号或分类号除了特别指定的以外仅起说明作用，并没有限制性，供应商在报价中可以选用替代标准，牌号或分类号，但这些替代要实质上优于或相当于技术规格的要求，并且使采购人满意。

　11.4 供应商提供的采购标的成本、同类项目合同价格以及相关专利、专有技术等情况说明。

　12 ．报价保证金（本项目不适用）

　12．1

　供应商应以人民币提交一笔不少于“报价邀请”规定的人民币金额的报价保证金。

　报价保证金是为了保护采购人和采购代理机构免遭因供应商的行为而蒙受损失，采购人和采购代理机构在因供应商的行为受到损害时可根据第12．5条的规定不予退还供应商的报价保证金。

　12．2

　未按规定时间和数额交纳报价保证金的报价，应视为非响应性报价予以拒绝。

　12．3

　未成交人的报价保证金，将在成交通知书发出后五个工作日内全额退还（不退现金）。

　成交人的报价保证金在成交人与采购人签订采购合同并按规定交纳了履约保证金后5个工作日内无息退还（不退现金）。退还时请返还采购合同（原件）1份及经采购方盖章确认的履约保证金缴纳凭证复印件（如要求）后，到本采购代理机构财务部办理。

　12．5

　下列任何情况发生时，报价保证金将被不予退还：

　12.5.1 供应商在提交响应文件截止时间后撤回响应文件的； 12.5.2 成交人在规定期限内未签订合同、未提交履约保证金或未交纳成交服务费。

　12.5.3 在报价文件中提供虚假材料的。

　 9 13 ．报价有效期

　13．1 报价文件应从采购之日起，在“报价邀请”所规定的以日历天计算的报价有效期内有效。报价有效期比规定短的可以视为非响应报价而予以拒绝。

　13．2在特殊情况下，在原报价有效期期满之前，采购人和采购代理机构可征得供应商同意延长报价有效期。这种要求与答复均应为书面形式如电传、传真等。供应商可以拒绝采购人、采购代理机构的这种要求但不被不予退还报价保证金。同意延长的供应商既不能被要求也不允许修改其报价文件，但要相应延长其报价保证金的有效期。

　13.3响应有效期: 自采购之日起90个日历日。

　14 ．报价文件的式样和签署

　14.1

　报价供应商应针对所参加报价的每一个包分别准备一套报价文件（包括一份正本和“报价邀请”规定数目的副本），每套报价文件须清楚地标明“正本”或“副本”。一旦正本和副本不符，以正本为准。

　14.2

　报价文件的正本和所有的副本均需打印或用不退色墨水书写并由供应商法定代表人/单位负责人或经法定代表人/单位负责人正式授权并对供应商有约束力的授权代表签字。授权代表须将以书面形式出具的“法定代表人/单位负责人授权书”附在报价文件中。

　14.3

　除供应商对错处做必要修改外，报价文件不得行间插字、涂改和增删，如有修改错漏处，必须由供应商法定代表人/单位负责人或其授权代表签字。

　四、报价文件的递交

　15． ． 报价供应商在报价邀请规定的 递交报价文件截止时间(以下简称报价时间)以前递交到规定地点.

　 五、谈判、评审

　16．谈判小组和采购人代表审核报价文件，根据采购文件的要求与报价供应商代表进行技术、商务谈判，谈判中对采购文件和报价文件所取得一致的修改意见应做出谈判纪要，由谈判小组成员、采购人代表和报价供应商代表签字。

　17 ．参加本次报价的供应商应根据采购谈判的情况，提交最终报价。

　18 ．推荐成交供应商:在保证采购项目质量和双方商定合理价格的基础上谈判小组推荐成交供应商。

　19 ．谈判小组写出书面评审报告。

　20 ．采购代理机构应当在评审结束后两个工作日内将评审报告送采购人。采购人应当在收到评审报告后五个工作日内，按照评审报告中推荐意见确定成交供应商；

　 10 21.采购人确定成交供应商过程中，发现成交候选供应商有下列情形之一的，应当不予确定其为成交供应商：

　（1）发现成交候选供应商存在禁止参加本项目采购活动的违法行为的； （2）成交候选供应商因不可抗力，不能继续参加政府采购活动； （3）成交候选供应商无偿赠与或者低于成本价竞争； （4）成交候选供应商提供虚假材料。

　六、授予合同

　22 ．公告: 将成交结果在四川政府采购网上发布公告； 23 ．成交通知书:成交结果公示的同时，成交供应商按报价邀请中的规定交纳了成交服务费后，向成交供应商颁发“成交通知书”。领取成交通知书时,领取人须交法定代表人/单位负责人授权书或介绍信原件和领取人身份证复印件(并携领取人身份证原件备查). 2 24 4 ．成交供应商与采购人签订采购合同。

　24．1

　采购文件、报价文件、谈判中对采购文件和报价文件所取得一致的修改意见应做出谈判纪要成交通知书将是合同的一个组成部分。

　24．2

　按合同专用条款的规定，向采购人提交履约保证金，其格式为采购文件中提供的或采购人接受的其他格式。（如采购人要求提交履约保证金）

　25.验收 成交人与采购人应按照《四川省政府采购项目需求论证和履约验收管理办法》（川财采〔2015〕32号）的要求进行验收。

　 11 第三章

　资格证明文件

　 （1）具有独立承担民事责任的能力。（注：①供应商若为企业法人：提供“统一社会信用代码营业执照”；未换证的提供“营业执照、税务登记证、组织机构代码证或三证合一的营业执照”；②若为事业法人：提供“统一社会信用代码法人登记证书”；未换证的提交“事业法人登记证书、组织机构代码证”；③若为其他组织：提供“对应主管部门颁发的准许执业证明文件或营业执照”；④若为自然人：提供“身份证明材料”。以上均提供复印件）

　（2）具备健全的财务会计制度的证明材料。｛注：①可提供 2018 或 2019 年度经审计的财务报告复印件（包含审计报告和审计报告中所涉及的财务报表和报表附注），②也可提供 2018 或 2019 年度供应商内部的财务报表复印件（至少包含资产负债表），③也可提供距文件递交截止日一年内银行出具的资信证明（复印件），④供应商注册时间至文件递交截止日不足一年的，也可提供加盖工商备案主管部门印章的公司章程复印件。｝ （3）具备良好商业信誉的证明材料。（可提供承诺函）

　（4）具有依法缴纳税收和社会保障资金的良好记录（可提供承诺函）

　（5）具备履行合同所必需的设备和专业技术能力的证明材料（可提供承诺函）； （6）参加政府采购活动前 3 年内在经营活动中没有重大违法记录的承诺函； （7）具备法律、行政法规规定的其他条件的证明材料（可提供承诺函）； （8）法定代表人/单位负责人授权书原件（①附法定代表人/单位负责人身份证明材料复印件；②法定代表人/单位负责人参与谈判时不需要提供）； （9）被授权代表的身份证明材料复印件； （10）按照规定购买了单一来源采购文件（由代理机构提供供应商购买单一来源采购文件情况的相关证明材料，供应商不用提供证明材料）。

　注：1 1 、以上要求的资料复印件 （身份证明材料、采购文件购买情况证明材料除外）

　均须加盖供应商单位的公章（鲜章）。

　 12 2 2 、 根据国务院办公厅关于加快推进 “ 多证合一 ” 改革的指导意见（国办发【 2017 】1 41 号）等政策要求，若资格要求涉及的登记、备案等有关事项和各类证照已实行多证合一导致供应商无法提供该类证明材料的，供应商须提供 “ 多证合一 ” 的营业执照，并就被 “ 多证合一 ” 整合的相关登记、备案和各类证照的真实性作出承诺（承诺函格式详见第 五 章）。

　 13 第四章

　货物需求一览表及技术规格

　一、采购 项目简介

　1.本项目采购预算：120 万元，最后报价超过采购预算作无效响应处理。

　2.本项目一个包，采购眉山市医保信息系统应用软件运维服务。

　3.项目综述 （1）项目背景 眉山市医保信息化应用软件按照统一建设、统一标准、统一规范，是依据原人社部核心平台三版标准和省局相关要求，结合眉山本地实际情况，各业务应用子系统分步建设实施，在建设实施过程中，主要项目包括：职工医保信息系统（后面又集成了城乡医保信息）、本地医院药店划卡前台结算系统、医院 his 接口、省内异地就医院直接结算系统、跨省异地就医结算系统、省政务“最多跑一次”一体化服务平台、省医保手机 app 接口、本地医保 app 接口平台、人保财保险接口、人寿保险接口、省级数据同步接口，实现了信息共享一体化，对纵向机构、横向部门业务数据互联互通，实现了市级数据集中、统一业务经办平台、统一经办规程、统一数据标准，目前全市两区四县应用基本全覆盖，运行正常。

　（2）项目目标 为保证眉山市各区县的医疗保障局、两定点医疗机构、乡镇社区等工作业务的正常展开，需要对全市医保信息化应用软件进行强有力的保障，对全市业务办理中遇到的问题进行及时处理，对部、省级、市级及同级相关部门日益变化的医保业务发展和政策规范的适应性调整，并对现有全市医保信息化应用软件进行扩展、改造提供技术支撑。

　（3）项目采购方式 （一）本项目系统维护内容是基于核心平台三版，并且是由现承建商广州华资软件技术有限公司进行开发及本地化实施。

　（二）此项目主要运维内容是医疗保障信息系统、两定医疗机构、异地就医、保险公司数据接口以及新增的 DRGS 按病种付费等项目，医保业务关系社会民生稳定，不能中断，需要开发商非常熟悉眉山医保本地业务政策、系统结构和程序开发，以保持系统业务的稳定性、即时性、延续性和一致性； （三）医疗保险政策变化较多，政策时限要求也较高，也是全省全市人民关注度最高的社会事业、即时性非常，所以需使用与当前后台统一的数据标准，防止由于数据结构差异对当前系统稳定性和可靠性造成影响，因此要求开发商需要非常熟悉现有数据库结构和标准，保证数据运行安全； 本项目是根据原人社部核心平台三版标准为基准进行设计开发，广州华资是为数不多的一家具有核心平台三版开发资质的软件公司。而眉山“一卡通”项目

　 14 2014 年中标从设计到开发以及后面的几次变更新增都是有广州华资进行设计和开发，在现场派驻了四名 5 年以上医疗行业研发人员进行开发和运维，鉴于此，本项目将采用单一来源采购方式，拟定广州华资软件技术有限公司承建本项目。

　二、商务要求

　1.服务期：本合同约定服务期限为 2020 年 9 月 10 日起至 2021 年 9 月 9 日止，若因政策因素导致本地系统提前封存、迁移，本地运行服务期限不足 1 年的，甲乙双方按照实际运维月数核定服务期限。运维时间不足 1 个月的，结束日期在15 号以后的按 1 个月核定，15 号当日及以前的按半个月核定。

　2.采购项目实施的地点：眉山市医疗保障局，采购人指定地点 3.付款方式：

　1）在本合同服务期限内，甲、乙双方按照月数核定运维服务期，服务费用按季度支付，乙方向甲方提供运维报告经确认后 15 个工作日内，甲方支付合同价款，每季度应付价款=（合同年度运维费用-服务质量考核费用）/4。

　2）在本合同服务期限内，因政策调整、系统更换造成运维服务中止的，未支付合同价款按实际运维月数支付，应付价款=（合同年度运维费用-服务质量考核费用）/12×核定未支付运维月数。

　3）总费用的 10%用于服务质量考核，在合同到期后按双方确定的考核标准由甲方对乙方实施考核，根据考核结果按比例进行支付（考核细则详见附件）。支付时间为考核完成后 15 个工作日内。

　4）乙方提请甲方支付运维费用时，须向甲方出具完整且合法有效的完税发票。

　三、 技术、服务要求

　（一）运维服务功能需求 1 11 .1 系统功能性维护

　确保全市医保信息化应用软件正常运行，所有功能按照既定业务需求、性能要求运行，对全市医保信息化应用软件主要开展改正性维护和完善性维护，诊断和改正使用过程中发现的软件错误，满足用户方在使用过程中提出已有功能的需求完善。

　 15 2 1.2 系统运维服务

　成立系统运维服务组，在眉山市医保局指定的场地进行办公，开展但不限于以下的服务工作：每周 7*24 小时不间断的运维服务电话接听，为全市医保信息化应用软件用户提供服务请求响应、技术咨询支持服务，以及对全市应用软件运行状况进行实时监控、收集跟踪平台缺陷、升级发布、提供运维通报等服务。

　3 1.3 数据同步、清洗工作

　全市医保信息化应用软件主要业务数据的省级汇聚；与外部系统关联业务数据单向或双向同步；以及其它数据转换清洗处理、数据统计等工作；现有全市医保信息化应用软件的业务数据补迁、清洗转移等。

　4 1.4 报表维护开发

　全市医保信息化应用软件所有报表的维护；新报表的开发以及有关部门临时要求的各类业务数据统计。

　5 1.5 数据库运维保障

　协助对全市医保信息化应用软件数据库提供性能优化、故障排除、预防性巡检等服务，协助保障数据库稳定、高效率运行。

　6 1.6 接口监控维护

　保障全市医保信息化应用软件内部各种服务以及与第三方对接系统的业务功能正常，监控并保障全市医保信息化应用软件方的接口服务正常。主要包括医院HIS 接口、异地就医及时结算接口、省级数据同步接口、智能审核接口等。

　7 1.7 运行质量分析服务

　结合运行实际，定期提供运行质量分析服务，全面收集和分析全市医保信息化应

　 16 用软件各类运行数据。准确定位软件运行性能瓶颈，有效提交和发布各类运行性能诊断报告和质量优化提升方案。

　8 1.8 程序开发维护

　主要保障全市医保信息化应用软件正常运行，解决运行中遇到的 Bug 及分析现有程序运行情况并进行系统优化。

　9 1.9 特殊化定制服务

　根据眉山市医保局的安排，在现有配置的人力情况下，提供人力资源，配合医保局对相关软件的再培训、质量抽查、数据定制化提取等工作。

　0 1.10 响应政策变化

　在现有系统业务框架范围内，对各级业务部门提出的政策调整和需求变更进行适应性改造（重大新增需求调整除外）。

　（二）运维管理服务保障 1 2.1 运维保障服务

　全市医保信息化应用软件及其关联系统根据不同种类应用或功能各自的运行特点，采取有针对性的监控工具和手段，开展每周 7*24 小时不间断的全方位的运行状态实时监控服务，确保提前发现和先期消除各类瓶颈和隐患，确保及时响应和快速解决各类事件和故障，并根据运行特性调稳、调优软件平台运行支撑环境（操作系统、中间件等），保障全市医保信息化应用软件稳定、可靠、安全、高效地运行，以及软件应用的部署、迁移、配置管理等服务。

　2 2.2 需求分析服务

　负责眉山市医保局信息化过程中应用软件问题调研及需求反馈的分析，并完成需

　 17 求说明书编写、需求确认、需求争议讨论、需求变更等工作。配合编写测试计划、测试用例、测试报告的编写、问题缺陷的发现及跟踪、产品操作手册编写等。负责配置管理的工作，以确保在项目的整个项目生命周期过程中的各个阶段的工作产品以及相关文档的版本管理的有效性和完整性。

　3 2.3 程序维护开发

　主要保障全市医保信息化应用软件正常运行，解决运行中遇到的 Bug 及分析现有程序运行情况并进行系统优化。配合系统测试。

　4 2.4 运维团队

　安排至少 1 名项目经理，3 名开发维护人员驻场对本项目进行支持。

　岗位 人数 岗位职责 资格要求 项目经理 1 负责整个运维团队的管理工作 1. 熟悉项目管理规范流程； 2. 熟悉软件编程规范； 3. 熟悉运维管理流程规范； 4. 熟悉医保业务政策及业务系统操作； 5. 有较高的组织、协调、沟通、问题解决能力； 6. 累计工作年限不低于 5 年，医保行业工作不低于 3 年； 程序开发维护人员 3 负责软件平台功能开发维护工作 负责用户互动（包括业务咨询、操作指导等）

　1. 熟悉使用 java 语言程序编程开发； 2. 熟悉操作 oracle 数据库编程开发； 3. 熟悉软件编程规范； 4. 熟悉运维管理流程规范； 5. 熟悉现有医保系统框架开发；

　 18 6. 熟悉医保业务政策，医保业务工作年限不低于 2 年

　5 2.5 运维流程规范

　全市医保信息化应用软件运维服务承担全市各区县的医保局、两定点医疗机构、乡镇社区等维护工作及业务咨询工作。牵涉的运行环境复杂,包括服务器、多种版本操作系统及数据库、硬件环境，服务对象多，协调公司及资源多，需制定一套运维流程规范，并按规范流程进行运维。

　6 2.6 工作时间

　工作人员负责 24 小时对软件系统的监控及维护工作，工作日上午 9 点至下午 18点，下班时间及节假日采取值班的方式，遇到特殊情况，需按照医保局要求加班完成。

　7 2.7 沟通互动要求

　9:00 至 18:00 之间，全市各区县的医保局、两定点医疗机构、乡镇社区的提问要求即时响应并在 30 分钟内有效回复，对于收集到的软件缺陷要在 1 个小时内响应。

　18：00 至次日 9：00 全市各区县的医保局、两定点医疗机构、乡镇社区的提问要求即时响应并在 1 小时内有效回复，对于收集到的软件缺陷要在 2 个小时内响应。

　bug 跟踪：（对平台运行中遇到的问题进行分析汇总，问题建档跟踪，每个问题必须跟踪出结果），bug 问题一般需在 48 小时内完成修改并升级。

　 19 8 2.8 平台监控要求

　如是中间件被关闭或需要重启，应马上处理；如是平台运行问题应立即通知开发组，开发组指派人员解决；如是经办机构问题应及时通知相关经办机构管理员及告知信息部门；如出现对方接口问题，应及时通知到对方相关部门并告知信息部门。

　9 2.9 升级、安装部署

　严格按照医保局信息部门安排要求，准时按质完成部署。

　0 2.10 软件故障定义及响应要求

　本项目的软件 BUG 严重级别定义及描述如下，以下所有故障均不包括因平台运行环境如：硬件、网络、非维护公司人为原因导致的故障。（因平台运行环境导致的故障乙方有义务协助处理。）

　一级故障：不能完全满足系统要求，系统停止运行，或系统的重要部件无法运行，或系统崩溃、挂起等导致系统不能继续运行。

　修改优先级为最高，该级别问题需要立即修复。

　二级故障：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。修改优先级为高，该级别需要尽快修复。

　三级故障：系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。修改优先级为中，该级别需要尽快修改。

　响应时限要求：

　在工作日需立即响应；节假日在一小时内响应。

　处理时限要求：

　即时切换到备份系统，然后迅速修复系统。

　 20 一级故障：30 分钟内； 二级故障：60 分钟内； 三级故障：90 分钟内。

　1 2.11 运维工作报告规范

　应定期形成运维工作报告，工作报告应能真实、全面反映包括全市医保各系统运行情况、各类数据交换、各类接口服务、主要业务数据变动、运维服务工作等情况。

　（三）数据安全实施 1 3.1 权限管理

　应加强系统上线环节的风险管理，运维方需形成系统安全风险评估和安全管理方案。系统上线应遵循变更管理流程，按照规范流程要求正式运行环境并设置相应的系统与数据库权限，运维方需进入运行环境的应向该医保局提出权限申请。

　2 3.2 数据管理

　应明确数据管理的目标、职责、质量和安全保障措施，建立有关数据的采集、存储、备份、恢复、加工、访问、清除和销毁等控制流程。涉及保密的数据，依照国家及行业有关数据安全的规定执行。

　3 3.3 监控管理

　应建立运行监控管理机制，动态掌握网络及信息系统的运行状况，针对可能出现的重大故障和灾难，制定相关应急预案，定期组织进行应急演练，并对各种异常情况做出快速响应。

　 21 4 3.4 涉密管理

　运维方应对医保局的业务秘密和系统安全与风险信息负有保密责任，签订保密协议，防止其擅自对医保局任何文件、数据进行非法传播。

　5 3.5 安全培训

　应明确运维管理职责，定期制定运维服务岗位人力资源需求方案，制定运维人员专业能力评定标准，定期进行运维人员能力培养、考核和准入等工作，加强对运维管理人员的业务和安全管理等方面的培训，确保其行为符合专业技术服务规范。

　6 3.6 人员风险管理

　应评估运维关键岗位人员流失带来的风险，制定人员候补和岗位接替计划，在人员岗位发生变化后及时变更相关业务系统、操作系统、服务器、数据库等账户权限信息。

　（四）项目维护遵循的总体技术路线 1 4.1 遵循 L XML 标准

　XML（eXtensible Markup Language，可扩展置标语言）是由 W3C 于 1998 年 2月发布的一种标准，同 HTML 一样是 SGML（Standard Generalized Markup Language，标准通用置标语言）的一个简化子集。由于它将 SGML 的丰富功能与HTML 的易用性结合到了 Web 的应用中，自推出以来，迅速得到软件开发商的支持和程序开发人员的喜爱，显示出强大的生命力。

　XML 的优势之一是它允许各个组织、个人建立适合自己需要的置标集合，并且这些置标可以迅速地投入使用。这一特征使得 XML 可以在电子商务、政府文档、出版、CAD/CAM、保险机构、厂商和中介组织信息交换等领域中一展身手，针对不同的系统、厂商提供各具特色的独立解决方案。

　XML 的最大优点在于它的数据存储格式不受显示格式的制约。一般来说，一篇文

　 22 档包括三个要素: 数据、结构以及显示方式。对于 HTML 来说，显示方式内嵌在数据中，这样在创建文本时，要时时考虑输出格式，如果因为需求不同而需要对同样的内容进行不同风格的显示时，要从头创建一个全新的文档，重复工作量很大。此外 HTML 缺乏对数据结构的描述，对于应用程序理解文档内容、抽取语义信息都有诸多不便。

　XML 把文档的三要素独立开来，分别处理。首先把显示格式从数据内容中独立出来，保存在样式单文件（Style Sheet）中，这样如果需要改变文档的显示方式，只要修改样式单文件就行了。XML 的自我描述性质能够很好地表现许多复杂的数据关系，使得基于 XML 的应用程序可以在 XML 文件中准确高效地搜索相关的数据内容，忽略其他不相关部分。XML 还有其他许多优点，比如它有利于不同系统之间的信息交流，完全可以充当网际语言，并有希望成为数据和文档交换的标准机制。

　4.2 E J2EE 通用架构

　技术架构将采用 J2EE 的方式，J2EE 的优势在于, J2EE 为搭建具有可伸缩性、灵活性、易维护性的医疗保险信息系统提供了良好的机制。

　保留现存的 IT 资产: 由于必须适应新的业务办理需求，利用已有的信息系统方面的投资就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是所需求的。J2EE 架构可以充分利用用户原有的投资，如一些单位使用的 BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及 Netscape Application Server。这之所以成为可能是因为 J2EE 拥有广泛的业界支持和一些重要域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的 J2EE 领域的升级途径。由于基于 J2EE 平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。

　高效的开发: J2EE 允许把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务: 状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够

　 23 更快地完成程序开发。

　持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。

　分布式共享数据对象 CACHE 服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。

　支持异构环境: J2EE 能够开发部署在异构环境中的可移植程序。基于 J2EE 的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于 J2EE 的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE 标准也允许客户订购与 J2EE 兼容的第三方现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。

　可伸缩性: 必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于 J2EE 平台的应用程序可被部署到各种操作系统上。例如可被部署到高端 UNIX 与大型机系统，这种系统单机可支持 64 至 256 个处理器（这是 NT 服务器所望尘莫及的）。J2EE 领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

　稳定的可用性: 一个服务器端平台必须能全天候运转以满足客户、合作伙伴的需要。因为互联网是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE 部署到可靠的操作环境中，他们支持长期的可用性。一些 J2EE 部署在 WINDOWS 环境中，客户也可选择健壮性能更好的操作系统如 Sun Solaris、IBM OS/390。最健壮的操作系统可达到99.999%的可用性或每年只需 5 分钟停机时间，这是实时性很强系统理想的选择。

　（五）维护开发管理规范 1 5.1 编写需求文档

　对于重大新增需求，应在需求分析过程中根据分析步骤逐步编制形成《需求规格说明书》。编写需求规格说明书应规范完整。

　 24 医保局在这个阶段的主要工作内容是：

　1、审核并签字确认《需求调研计划》。

　2、根据《需求调研计划》内容要求，提供开发业务需求调研所需要的资源，积极配合开发商的业务需求调研工作。

　3、提供业务需求、业务流程、业务单据与报表。

　4、参加开发商的需求讲解讨论会，提出需求理解的差异性，并进行解释。指定人员进行需求管理，并解答开发商在需求分析过程中提出的需求方面的疑问。

　5、审核并确认本《用户需求说明书》并签字。

　开发公司主要工作内容是：

　1、制订《需求调研计划》 项目经理根据《软件项目计划》编写需求调研阶段的《需求调研计划》，在本计划中，项目经理与用户一起共同确定需求调研工作所需要的资源安排，需求调研方法以及调研日程。

　2、用户现场的需求调研活动 需求调研员按照需求调研计划，在用户现场进行需求调研工作。需求调研的内容包括三个部分：一是功能性需求，一是非功能性需求，另外是外部接口需求。功能性需求是指业务需求。

　功能性需求调研 医保局组织各单位的业务科室人员，除向开发商提供各种政策文件、业务办理流程文件、业务单据和业务报表外，开发商的需求调研人员还将采用面谈、开讨论会等形式，在用户现场对业务人员向进行需求调研，编写《需求调研记录》。

　对于用户单位提供的有关材料如业务表单，报表等，需求管理员要进行编号整理并记录。

　需求分析员阅读需求调研员提供的《需求调研记录》内容，采用基于业务建模方法的需求定义方法，找出隐含，重复和矛盾的需求，建立基本的业务模型，编写《用户需求说明书》。

　非功能性需求

　 25 非功能性需求与功能性需求相对应，指用户对系统操作表现、特点等方面的要求。

　系统表现、特点等方面的需求往往是传统需求定义方面的盲区，在基于用例（UC）的需求描述方法中，需在每个用例（UC）中单独描写中以涉众需求的形式单独描述，并把涉众需求以一定的形式量化。

　非功能性需求的验证，量化的非功能性需求有单独的系统测试用例进行验证和跟踪。

　非功能性需求对用户的影响，非功能性需求是系统性能的重要表现，对最终用户有较大的影响，也是系统设计的重要指标。

　外部接口需求 医保业务系统需要与其他系统进行数据交换，因此，外部接口的需要也是系统需求的一个重要部分。

　为了确保需求的易跟踪、易修改，需求分析人员应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并在《软件需求规格说明书》中明确说明。

　定义需求的优先级 优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。

　需求分析人员应确定每个需求的优先级并写入《软件需求规格说明书》，需求的优先级的评价标准如下：

　级别定义

　判断标准

　采取的措施

　高 满足以下任意一条时：

　1) 需求实现的紧急程度为特急或紧急 对于这些需求在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现。通常这类需求在当前版

　 26 2) 国家或行业法律法规、标准要求的，客户明确要求的，满足正常业务必须的。

　本必须实现。

　中 满足以下任意一条时：

　1) 客户隐含要求，对正常业务影响程度不大 2) 需求实现的紧急程度为中 3) 支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要求的。

　这些需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，如果有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。

　低 满足以下任意一条时：

　1) 功能或质量上的附加功能； 2) 实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能，属于锦上添花； 3) 需求实现的紧急程度为低；

　实现或不实现均可；可以在项目组有较足够的时间时考虑这些需求的实现 需求分析人员在需求分析过程中根据分析步骤逐步编制形成《软件需求规格说明书》。编写需求规格说明书应遵循以下规则：

　 相关的需求都得到了识别与描述，以确保需求的完整性；  各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；  正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；  定义必要的术语，适当结合图形、结构图等方式进行描述，以确

　 27 保需求无二义性；  使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；  确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；  考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。

　《软件需求规格说明书》的内容可以包括但不局限于：

　 需求描述约定  系统概述，如系统功能、业务描述、数据流程描述、用户的特点、运行环境要求、设计与实现上的限制等  功能需求描述  非功能性需求，如系统性能要求、安全备份与恢复要求、系统日志等。

　 外部接口说明，如软硬接口、通信接口等  其它需求描述，如界面要求、操作要求等  功能列表等 2 5.2 需求确认

　需求确认是指将评审通过的《软件需求规格说明书》提交给客户（或客户代表）进行确认，使项目组与客户对需求的认识达成一致，确认的方式由项目需求的承诺方在《评审报告》上直接签字或盖章确认。

　如果在需求确认过程中，项目组与客户对需求的认识未达成一致，客户提出了对《软件需求规格说明书》的修改意见，需求人员应详细收集这些修改意见，补充

　 28 记录到《评审记录表》中，并根据客户意见对《软件需求规格说明书》进行修改，将修改部分填写到文档的“文件更改摘要”中，并召开需求澄清会，将修改部分对原来参加需求评审会的人员做一次澄清，并在《评审报告》中附录说明。

　需求在经内部评审通过后，需求人员必须及时将《软件需求规格说明书》交给客户方做签字确认。

　3 5.3 需求变更

　需求在用户签字确认后发生变更时，应执行需求变更流程，需求分析人员重新对变更后的需求进行分析和定义，变更相应的《软件需求规格说明书》，并填写《需求变更控制报告》，一并做为评审材料，在通过文档规范性检查后，重新进行需求的评审和确认。在《需求变更控制报告》上签字，项目经理在开发组长签字后确认无误再签字，经办负责人签字确认后，由需求人员将《需求变更控制报告》的纸质文档提交配置管理员处并由配置管理员抄送一份给 QA 工程师，电子档提交到 SVN 上。

　4 5.4 设计开发管理

　系统设计编码过程包括系统设计、系统实现。系统设计是指设计软件系统的体系结构、数据库、模块等，在需求和代码之间建立桥梁，一般分概要设计和详细设计两个阶段；系统实现是指软件工程师按照系统设计去编码开发，并进行单元测试；在设计编码过程中需求组长组织需求人员同时进行《用户操作手册》的补充和编制，为测试、验证人员提供测试验证依据。

　对于本平台运维项目来说，是在一个完整的产品基础上进行局部地、逐步地系统完善性开发，因此，在小规模的完善过程中可以省略系统概要设计，直接由开发人员进行详细设计文档的编写。但是，项目开发组应维护一张完整的系统功能列表（即需求跟踪矩阵），对系统功能进行明确的标识，并能与《软件需求规格说明书》和《详细设计说明书》保持对应关系，以维护本项目从需求到设计、开发的跟踪，保持需求、设计、开发的一致性和完整性。

　 29

　主要工作内容：

　1、架构设计与系统设计 开发经理在组织开展系统设计工作前，根据《软件项目计划》，分解工作任务（分解粒度为半个工作日至两个工作日，每项任务有负责人和产出物），编制设计阶段的项目日程表。项目经理批准项目日程。

　开发经理组织系统设计人员进行系统设计。系统设计分为四个部分，即系统架构设计、数据库设计、功能模块设计和界面设计。

　2、设计文档的整理 文档工程师整理架构设计师、系统设计师、数据库设计师、界面设计师和模块设计师的设计记录草稿，形成《系统设计说明书》。

　3、设计的评审与同行评审 为保证系统具有先进性、开放性、实用性和独立性的要求，并具有良好的维护性等，项目经理指定评审负责人组织技术专家（架构设计专家、数据库设计专家、模块界面设计专家）以及相关人员构成评审小组对《用户需求说明书》进行评审和同行评审。评审通过后，项目经理负责验证评审问题解决。

　4、项目管理 开发经理根据设计结果填写《需求跟踪矩阵》，需求管理员进行需求管理。

　配置管理工程师将《系统设计说明书》作为配置项进行管理。

　项目经理编写里程碑《项目状态报告》。

　系统设计结束后，进入系统编码实现。

　5 5.5 设计评审

　为保证设计的正确性、完整性和与需求的一致性，应对《详细设计说明书》、《数据库设计说明书》以及其它相关文档进行评审。小规模的设计，可采用组内评审或书面轮查的方式进行，大规模的设计则采用技术评审会议的方式进行。提交《评审报告》、《评审记录表》。

　 30 6 5.6 编码开发

　系统设计完成后，进入编码开发阶段。运维方应在进入编码阶段之前，有明确的《编码规范》，说明系统源代码文件、数据表、存储过程等的命...