医科大学附属第二医院信息系统重构项目招标文件

页ADDINCNKISM.UserStyle公开招标采购文件项目名称：信息系统重构

目录TOC\o"1-1"\h\z第一章招标公告 3供应商须知前附表 6第二章采购内容及需求 11（一）招标内容及整体要求 11（二）技术参数规格 38（三）商务要求 194第三章供应商须知 198第四章评标办法 210第五章采购合同 219第六章投标文件格式 225

第一章招标公告项目概况温州医科大学附属第二医院信息系统重构招标项目的潜在投标人应在政府采购云平台（）获取（下载）招标文件，并于2022年7月21日09：00（北京时间）前递交（上传）投标文件。一、项目基本情况项目编号：ZJ-2270273-07项目名称：温州医科大学附属第二医院信息系统重构预算金额（元）：30000000最高限价（元）：30000000采购需求：标项一：标项名称：信息系统重构数量：1预算金额（元）：30000000简要规格描述或项目基本概况介绍、用途：信息系统重构，具体详见采购文件。备注：无合同履约期限：按采购文件要求本项目（是）接受联合体投标。二、申请人的资格要求：1.满足《中华人民共和国政府采购法》第二十二条规定；未被“信用中国”()、中国政府采购网（）列入失信被执行人、重大税收违法案件当事人名单、政府采购严重违法失信行为记录名单。2.落实政府采购政策需满足的资格要求：/3.本项目的特定资格要求：无。三、获取招标文件时间：/至2022年7月21日，每天上午00：00至12：00，下午12：00至23：59（北京时间，线上获取法定节假日均可，线下获取文件法定节假日除外）地点（网址）：政府采购云平台（）方式：在线获取售价（元）：0四、提交投标文件截止时间、开标时间和地点提交投标文件截止时间：2022年*月*日09：00（北京时间）投标地点（网址）：线上（政府采购云平台（））开标时间：2022年7月21日09：00开标地点（网址）：线上（政府采购云平台（））五、公告期限自本公告发布之日起5个工作日。六、其他补充事宜1.《浙江省财政厅关于进一步发挥政府采购政策功能全力推动经济稳进提质的通知》（浙财采监（2022）3号）、《浙江省财政厅关于进一步促进政府采购公平竞争打造最优营商环境的通知》（浙财采监（2021）22号）已分别于2022年1月29日和2022年2月1日开始实施，此前有关规定与上述文件内容不一致的，按上述文件要求执行。2.根据《浙江省财政厅关于进一步促进政府采购公平竞争打造最优营商环境的通知》（浙财采监（2021）22号）文件关于“健全行政裁决机制”要求，鼓励供应商在线提起询问，路径为：政采云－项目采购－询问质疑投诉－询问列表：鼓励供应商在线提起质疑，路径为：政采云－项目采购－询问质疑投诉－质疑列表。质疑供应商对在线质疑答复不满意的，可在线提起投诉，路径为：浙江政府服务网－政府采购投诉处理－在线办理。3.供应商认为采购文件使自己的权益受到损害的，可以自获取采购文件之日或者采购公告期限届满之日（公告期限届满后获取采购文件的，以公告期限届满之日为准）起7个工作日内，对采购文件需求的以书面形式向采购人提出质疑，对其他内容的以书面形式向采购人和采购代理机构提出质疑。质疑供应商对采购人、采购代理机构的答复不满意或者采购人、采购代理机构未在规定的时间内作出答复的，可以在答复期满后十五个工作日内向同级政府采购监督管理部门投诉。质疑函范本、投诉书范本请到浙江政府采购网下载专区下载。4.其他事项：（1）采购项目需要落实的政府采购政策：《政府采购促进中小企业发展管理办法》（财库﹝2020﹞46号）、《关于促进残疾人就业政府采购政策的通知》（财库〔2017〕141号）、《关于政府采购支持监狱企业发展有关问题的通知》（财库[2014]68号）、《关于调整优化节能产品环境标志产品政府采购执行机制的通知》（财库[2019]9号）。（2）根据《浙江省财政厅关于规范政府采购供应商资格设定及资格审查的通知》（浙财采监[2013]24号）第6条规定接受金融、保险、通信等特定行业的全国性企业所设立的区域性分支机构，以及个体工商户、个人独资企业、合伙企业，且已经依法办理了工商、税务和社保登记手续，并且获得总机构授权或能够提供房产权证或其他有效财产证明材料，证明其具备实际承担责任的能力和法定的缔结合同能力。（3）单位负责人为同一人或者存在直接控股、管理关系的不同供应商，不得同时参加同一合同项下的投标。（4）为项目提供整体设计、规范编制或者项目管理、监理、检测等服务的供应商，不得参加该项目的投标。（5）本项目采购文件公告期限为本公告发布之日起5个工作日。七、对本次采购提出询问、质疑、投诉，请按以下方式联系

供应商须知前附表序号名称内容1采购人2采购代理机构3踏勘现场自行踏勘4资金来源已落实5环境标志产品节能产品（1）严格执行《财政部发展改革委生态环境部市场监管总局关于调整优化节能产品、环境标志产品政府采购执行机制的通知》（财库〔2019〕9号）。（2）采购人拟采购的产品属于品目清单范围的，采购人及其委托的采购代理机构将依据国家确定的认证机构出具的、处于有效期之内的节能产品、环境标志产品认证证书，对获得证书的产品实施政府优先采购或强制采购。供应商须按采购文件要求提供相关产品认证证书。▲（3）采购人拟采购的产品属于政府强制采购的节能产品品目清单范围的，供应商未按采购文件要求提供国家确定的认证机构出具的、处于有效期之内的节能产品认证证书，投标无效。属于政府优先采购产品类别的，须按照要求提供依据国家确定的认证机构出具的、处于有效期之内的节能产品或环境标志产品认证证书，否则不予认定。eq\o\ac(□)适用R不适用6投标产品主体eq\o\ac(□,√)不适用7投标保证金□适用eq\o\ac(□,√)不适用8投标文件有效期自投标截止时间起90天9投标截止时间按“招标公告”规定10投标地点按“招标公告”规定11开标时间和地点按“招标公告”规定12投标答疑供应商如认为采购文件表述不清晰的，请于2022年7月11日17：00之前将疑问发送至该电子邮件（邮箱）。答疑回复内容是采购文件的组成部分，并将以更正公告的形式在本采购公告发布的同一媒体发布，请供应商密切关注更正公告。13采购文件的澄清与修改采购人或者采购代理机构可以对已发出的采购文件进行必要的澄清或者修改。澄清或者修改的内容可能影响投标文件编制的，采购人或者采购代理机构应当在投标截止时间至少15日前，将以更正公告的形式在采购公告发布的同一媒体发布。采购文件的修改和澄清（答疑）答复的文件作为采购文件的补充和组成部分，对所有供应商均有约束力。若后续仍有更正内容，将继续以更正公告形式在本网站发布，请供应商密切关注更正公告。14投标文件形式本项目实行电子投标。供应商应准备2种形式的投标文件：电子加密投标文件、以介质存储的数据电文形式的备份投标文件。（1）“电子加密投标文件”是指通过“政采云电子交易客户端”完成投标文件编制后生成并加密的数据电文形式的投标文件（后缀格式为.jmbs）（2）“备份投标文件”是指与“电子加密投标文件”同时生成的数据电文形式的电子文件（备份投标文件，用于供应商电子加密投标文件解密异常时应急使用），其他方式编制的备份投标文件视为无效备份投标文件。备份投标文件（后缀格式为.bfbs）以U盘形式提供或发电子邮件至。15投标文件的上传和递交（1）电子加密投标文件：投标文件制作完成并生成加密文件，在投标截止时间前，供应商需将加密的投标文件上传至浙江政府采购网，到达开标时间后，供应商自行解密。供应商未能在投标截止时间前成功上传电子加密投标文件的投标无效。（2）备份投标文件：投标截止时间前，供应商应将备份投标文件递交至开标地点，以便电子加密投标文件解密异常时应急使用。备份投标文件递交要求：供应商须将备份投标文件以U盘形式单独放在密封袋中，密封后并在密封袋上注明投标项目名称、投标单位名称并加盖公章。未密封包装或者逾期送达的“备份投标文件”将不予接收。供应商若选择非开标当天递交，请确保在2022年7月20日17：00之前，将备份投标文件通过快递形式或直接送达采购代理机构处，以便标书解密异常时应急使用（地址：）16询标澄清在评标过程中，如评审小组对投标文件有疑问，由评审组长或代理机构代为将问题汇总后发起询标澄清函，供应商应在规定截止时间前回复相关内容并提交。17质疑根据《中华人民共和国政府采购法》第五十二条的规定，供应商认为采购文件、采购过程和中标、成交结果使自己的权益受到损害的，可以在知道或者应知其权益受到损害之日起七个工作日内，以书面形式向采购人、采购代理机构提出质疑。政府采购法第五十二条规定的供应商应知其权益受到损害之日，是指：（一）对可以质疑的采购文件提出质疑的，为收到采购文件之日或者采购文件公告期限届满之日；（二）对采购过程提出质疑的，为各采购程序环节结束之日；（三）对中标或者成交结果提出质疑的，为中标或者成交结果公告期限届满之日。根据《政府采购质疑和投诉办法》第十三条，采购人、采购代理机构不得拒收质疑供应商在法定质疑期内发出的质疑函，应当在收到质疑函后7个工作日内作出答复，并以书面形式通知质疑供应商和其他有关供应商。18投诉根据《中华人民共和国政府采购法》第五十五条的规定，质疑供应商对采购人、采购代理机构的答复不满意或者采购人、采购代理机构未在规定的时间内作出答复的，可以在答复期满后十五个工作日内向同级政府采购监督管理部门投诉。19样品eq\o\ac(□,√)不提供20演示本项目组织系统演示。本项目评标时安排每个投标人进行系统演示，系统演示要求详见采购文件第四章中评标细则及标准。每个投标人时间不超过25分钟，演示次序以投标文件解密成功时间先后次序为准，如遇不演示或现场未及时响应的投标人则自动至下一次序投标人。方式：现场系统演示。投标人应在提交投标文件截止时间前到采购文件规定线下会议室签到（温州市车站大道789号，智慧谷创意园i栋2楼，瓯办工场2013室）后按评标委员会指定的时间段和会议室进行现场系统演示，演示现场提供网络环境及投影仪，其余由投标人自备。投标人进入系统演示现场的演示代表不超过2人，系统演示人员进场前须核验演示代表身份证明原件及投标人出具的加盖投标人公章的书面授权演示代表证明（注明姓名，身份证号），核验合格后方可开始现场系统演示，否则系统演示不得分。未按要求及时到现场签到并经演示人员身份核验合格后进行系统演示的，本项现场系统演示不得分。（3）相关说明：因投标人自身原因导致无法演示或者演示效果不理想的，责任自负。21支持中小企业1.说明（1）中小企业中小企业是指在中华人民共和国境内依法设立，依据国务院批准的中小企业划分标准确定的中型企业、小型企业和微型企业，但与大企业的负责人为同一人，或者与大企业存在直接控股、管理关系的除外。符合中小企业划分标准的个体工商户，在政府采购活动中视同中小企业。在政府采购活动中，供应商提供的货物、工程或者服务符合下列情形的，享受本办法规定的中小企业扶持政策：（一）在货物采购项目中，货物由中小企业制造，即货物由中小企业生产且使用该中小企业商号或者注册商标；（二）在工程采购项目中，工程由中小企业承建，即工程施工单位为中小企业；（三）在服务采购项目中，服务由中小企业承接，即提供服务的人员为中小企业依照《中华人民共和国劳动合同法》订立劳动合同的从业人员。在货物采购项目中，供应商提供的货物既有中小企业制造货物，也有大型企业制造货物的，不享受本办法规定的中小企业扶持政策。以联合体形式参加政府采购活动，联合体各方均为中小企业的，联合体视同中小企业。其中，联合体各方均为小微企业的，联合体视同小微企业。响应文件中须同时出具《政府采购促进中小企业发展管理办法》【财库（2020）46号】规定的《中小企业声明函》，否则不得享受价格扣除。（2）残疾人福利性单位符合《关于促进残疾人就业政府采购政策的通知》（财库〔2017〕141号）规定的条件并提供提供《残疾人福利性单位声明函》的残疾人福利性单位视同小型、微型企业；（3）监狱企业根据《关于政府采购支持监狱企业发展有关问题的通知》（财库[2014]68号）的规定，供应商提供由省级以上监狱管理局、戒毒管理局（含新疆生产建设兵团）出具的属于监狱企业证明文件的，视同为小型和微型企业。2.价格扣除：本项目对符合规定的小微企业（含小型企业）报价给予10%的扣除。3.本项目采购标的所属行业为：软件和信息技术服务业22联合体和分包（1）对于联合协议约定小微企业的合同份额占到合同总金额30%以上的，其报价给予3%的扣除，用扣除后的价格参加评审。组成联合体的小微企业与联合体内其他企业之间存在直接控股、管理关系的，不享受价格扣除优惠政策。（2）对于分包意向协议约定小微企业的合同份额占到合同总金额30%以上的，其报价给予3%的扣除，用扣除后的价格参加评审。接受分包的小微企业与分包企业之间存在直接控股、管理关系的，不享受价格扣除优惠政策。（3）以联合体形式进行投标的，参加联合体的供应商均应当具备政府采购法第二十二条规定的条件，并应当在投标文件中提交联合协议，载明联合体各方承担的工作和义务。联合体各方应当共同与采购人签订采购合同，就采购合同约定的事项对采购人承担连带责任。（4）联合体中有同类资质的供应商按照联合体分工承担相同工作的，应当按照资质等级较低的供应商确定资质等级。（5）以联合体形式参加投标的，联合体各方不得再单独参加或者与其他供应商另外组成联合体参加本项目的投标。23其他（1）采购文件中凡标注“▲”的条款均为实质性要求，不响应的投标文件将作无效标处理。（2）供应商未上传电子加密投标文件，其投标无效。（3）供应商上传了电子加密投标文件，未提供备份投标文件，解密出现问题后，由此导致对该供应商投标无法评审的，其后果由该供应商自行承担。（4）各供应商自行在浙江政府采购网下载或查阅采购文件和相关更正公告等，不另行通知，如有遗漏采购人、采购代理机构概不负责。（5）两家或两家以上供应商提供的投标文件出自同一终端设备的，或在相同Internet主机分配地址（相同IP地址）报名或网上投标的，后果由供应商自行承担。

第二章采购内容及需求（一）招标内容及整体要求一、项目概述温州医科大学附属第二医院、育英儿童医院是浙江省属三甲综合性医院，以“特色鲜明的一流大学附属医院和国家级区域医疗中心”为发展目标，随着智慧医院建设的快速发展，医院依托信息中心\大数据中心的自主研发能力，在第三方软件厂商的协同支持下，已经建立了覆盖全院业务的信息系统体系，包含来自不同厂商的医技、护理、财务、行政管理等业务系统，成为了目前医院运营和管理的有力支撑。医院信息化建设取得快速发展的同时，也充分暴露出医院信息化发展过程中的各种瓶颈问题，全院业务系统的信息共享整合及互联互通的需求越来越大，数据管理的规范化、标准化要求越来越高。其中医院已建设信息集成平台，但在平台建设过程中，医院原有HIS内部交互采用紧耦合方式，集成平台未发挥其本身的消息通道、中间桥梁的价值。同时医院核心业务信息系统多采用C/S架构设计，PB+DB模式，可扩展性、可维护性较差；采用的开发语言及应用架构已经过于老化且跟不上最新的建设要求，维护较为困难。功能已不能满足当前需求，流程覆盖不完整，如：闭环医嘱、诊间预约、移动医护、费用自动审核等；流程协同不完善（在信息交互、共享、反馈等方面），如：临床药师和住院医生的协同、门诊药师和门诊医生的协同、病历质控和临床医生的协同等。为此，依据《中华人民共和国基本医疗卫生与健康促进法》、《中华人民共和国标准化法》、国务院《关于实施健康中国行动的意见》（国发〔2019〕13号）、国务院办公厅《关于促进“互联网+医疗健康”发展的意见》（国办发〔2018〕26号）、浙江省委《浙江省数字化改革总体方案》浙委改发〔2021〕2号等相关政策文件，为落实新医改相关工作任务，积极响应浙江省卫健委“数字化改革”的政策精神，加强并持续推进医院信息化建设进程，提高健康诊疗信息交互共享和医疗服务协同水平和信息惠民成效，采用目前主流的云原生微服务架构，对医院现有系统实现数字化转型，建立弹性可扩展的技术底座，不断创新医院的智慧化服务应用，全面提升医院的管理和服务能力，逐步实现“智慧医疗、智慧管理和智慧服务”。二、建设目标要求通过本项目建设，从医疗数据整合利用出发，梳理各业务系统的业务流程和数据流向，实现医院不同系统间“互联互通、信息共享、业务协同”，充分利用整合后的数据更好的服务于临床、科研、医院管理及患者服务。并达到以下要求：• 建立完善的医院信息系统基础架构与标准体系，完成数据标准化治理与建设，满足国内外行业标准和规范。• 优化现有信息系统架构，实现医联网、多院区、企业级的一体化智慧平台应用，支撑区域化医疗业务快速拓展。• 促进以患者为中心的医疗信息资源的整合与利用• 提高医疗服务质量及科研水平，为科教研智慧服务奠定基础• 促进医院高质量管理及电子病历高级别应用、提升临床辅助决策水平• 以评促建，完成符合医院信息化等级评审的信息化建设• 促进医疗机构间业务协同，推动区域化诊疗、互联网医疗的发展并实现达到以下目标：（1）落实浙江省医疗卫生服务领域“最多跑一次”服务为全面优化医疗机构就医环境，提升医疗卫生服务规范化、人性化、智慧化、便利化、特色化水平，逐步提升患者就医体验，浙江省卫健委从2018年开始连续3年递进式提出浙江省医疗卫生服务领域“最多跑一次”改革服务，作为新医改“三医联动”、“六医统筹”的重要举措。从信息化的层面看，本次项目要求是在数据标准化和对接的基础上，实现患者服务一站式完成，在某些场景下，通过借助自助机和移动互联网方式，患者可更快捷完成各项服务办理，一次都不用跑。（2）推进医院的数字化改革，提升现代医院管理水平积极推进浙江省委、省卫健委提出的“医疗卫生服务领域数字化改革提升患者就医体验暨实施进一步便利老年人就医举措工作方案（2021-2023年）”的行动目标，打造新一代智慧化医院业务管理系统，以中台突破传统系统能力瓶颈，引领医疗数字化升级。通过搭建中台核心微服务架构，联动应用温州市“健康云”平台资源，下沉核心资源共享，以微服务API提供统一的微服务调用管理，完成临床系统最小核心集的一体化集成与融合，同时基于HL7FHIR互操作标准串连各类业务系统及互联网应用，实现数字化系统间互通、并存与演化。实现医院数据的标准化管理。通过数据预治理满足管理决策、临床决策、科学研究、对外信息交流共享；实现统一的数据仓库的设计及技术文档、元数据管理等功能。提高医院管理质量和工作效率。规划医疗资源，实现诊疗流程再造，提高医院工作效率，提升医院的整体服务能力，通过数据算法反哺优化就诊，有效解决就诊“三长一短”现象。（3）巩固现有病历评级成果，落实电子病历六级建设依托数字化改革，结合云原生的微服务框架技术，对新一代智慧医院整体信息建设做顶层设计，对标电子病历六级水平，以我院当前通过的等级评审水平为基础，从以下五个方面重点加强信息化建设：1.全院各系统数据能够按统一的医疗数据管理机制进行信息集成，并提供跨部门集成展示工具；2.具有完备的数据采集智能化工具，支持病历、报告等的结构化、智能化书写；3.实现医疗数据全流程闭环管理，展现医疗数据全流程状态；4.基于集成的病人信息，利用知识库实现决策支持服务，并能够为医疗管理和临床科研工作提供数据挖掘功能。通过高水平全新建设，提高电子病历使用率，有效改进电子病历质量；5.重点地开展数据治理，加强数据合理应用，全面实现临床无纸化及区域互联互通共享。（4）对标互联互通五乙标准提质增速，加强医疗数据互通共享依据互联互通五乙标准，对医院平台进行重建，在建设之初就实现院内术语和字典的统一，并以此推向集团内其他院区，实现与上级平台基于共享文档形式的交互，提升整个集团医院信息系统互联互通水平，实现医疗信息和数据的互通共享。（5）瞄准智慧服务三级目标，线上线下一体化患者服务联通医院内外的智慧服务初步建立。电子病历的部分信息通过互联网在医院内外进行实时共享，部分诊疗信息可以在院外进行处理，并与院内电子病历信息系统实时交互。建立院内院外、线上线下一体化的医疗服务流程。达到智慧服务三级要求。三、建设标准依据本项目在建设过程中，需遵循相关国际国内的行业标准，包括功能规范、数据标准、建设与管理标准等：（1）政策法规《“健康中国2030”规划纲要》；《关于促进智慧城市健康发展的指导意见》（发改高技〔2014〕1770号）；《关于推进分级诊疗制度建设的指导意见》（国办发〔2015〕70号）；《医院信息化建设应用技术指引（2017年版）》（试行）（国卫办规划函〔2017〕1232号）；《国家发展改革委关于印发“十三五”国家政务信息化工程建设规划的通知》（发改高技〔2017〕1449号）；国家卫生健康委办公厅《关于进一步推进以电子病历为核心的医疗机构信息化建设工作的通知》（国卫办医发〔2018〕20号）；《关于印发公立医院开展网络支付业务指导意见的通知》（国卫办财务发〔2018〕23号）；国务院办公厅文件《关于促进“互联网+医疗健康”发展的意见》（国办发〔2018〕26号）的文件；《关于开展建立健全现代医院管理制度试点的通知》（国卫体改发〔2018〕50号文）;《关于印发电子病历系统应用水平分级评价管理办法（试行）及评价标准（试行）的通知》（国卫办医函〔2018〕1079号）；《医疗机构医用耗材管理办法（试行）》（国卫医发〔2019〕43号）；《国家卫生健康委办公厅关于印发医院智慧服务分级评估标准体系（试行）的通知》（国卫办医函〔2019〕236号）；《国家卫生健康委办公厅关于印发有关病种临床路径（2019年版）的通知》（国卫办医函〔2019〕933号）；互联网诊疗管理办法（试行）。《国家医疗健康信息医院信息互联互通标准化成熟度测评方案（2020年版）》；《关于印发医疗联合体管理办法（试行）的通知》（国卫医发〔2020〕13号文件）《关于做好公立医疗机构“互联网+医疗服务”项目技术规范及财务管理工作的通知》（国卫财务函〔2020〕202号）；《关于进一步完善预约诊疗制度加强智慧医院建设的通知》（国卫办医函〔2020〕405号）《国家卫生健康委办公厅关于印发医院智慧管理分级评估标准体系（试行）的通知》（国卫办医函〔2021〕86号）2021年6月4日国务院办公厅发布了《国务院办公厅关于推动公立医院高质量发展的意见》（国办发〔2021〕18号）《浙江省数字化改革总体方案》（浙委改发〔2021〕2号）《浙江省卫生健康委关于印发浙江省推进医疗卫生服务领域数字化改革提升患者就医体验暨实施进一步便利老年人就医举措工作方案（2021-2023年）的通知》（浙卫发函〔2021〕75号）《温州市卫生健康委员会关于印发温州市智慧健康云建设指导意见的通知》（温卫发函〔2021〕116号）（2）标准与规范《医院信息化建设应用技术指引（2017年版）》；《全国医院信息化建设标准与规范（试行）》（2018年5月）；《电子病历系统应用水平分级评价管理办法（试行）-2018版》；《电子病历系统应用水平分级评价标准（试行）-2018版》；《医院信息互联互通标准化成熟测评方案－2020版》；《医院信息互联互通标准化成熟测评指标体系－2020版》；《医院智慧服务分级评估标准体系（实行）》；《医院智慧管理分级评估标准体系（试行）》；《EMR、EHR公共卫生数据统一采集交换技术指导方案（试行）》；《基于EMR、EHR交换的公共卫生基本数据集》；《疾病分类与代码》GB/T14396-2016；《医疗环境电子数据交换标准HL7V3.0》；《医学信息交互集成IHE》；《卫生信息数据元目录）》（卫通[2011]13号）；《信息安全技术网络安全等级保护基本要求》（GB/T22239-2019）；《信息安全技术网络安全等级保护定级指南》（GB/T22240-2020）；《信息安全技术网络安全等级保护实施指南》（GB/T25058-2019）；《信息安全技术网络安全等级保护安全设计技术要求》（GB/T25070-2019）；《网络入侵检测系统测试方法》（GB/T26268-2010）；《信息安全技术网络安全等级保护测评要求》（GB/T28448-2019）；《信息安全技术网络安全等级保护测评过程指南》（GB/T28449-2018）；《信息安全技术网络型入侵防御产品技术要求和测试评价方法》（GB/T28451-2012）；《信息安全技术网络安全等级保护测试评估技术指南》（GB/T36627-2018）；《信息安全技术网络用户身份鉴别技术指南》（GB/T36633-2018）；《信息安全技术网络安全监测基本要求与实施指南》（GB/T36635-2018）；《信息安全技术网络安全威胁信息格式规范》（GB/T36643-2018）；《信息安全技术网络安全等级保护安全管理中心技术要求》（GB/T36958-2018）；《信息安全技术网络安全等级保护测评机构能力要求和评估规范》（GB/T36959-2018）；《互联网诊疗管理办法（试行）》；《远程医疗服务管理规范（试行）》；《远程医疗信息基本数据集》(WS539-2017)；《健康档案基本架构与数据标准》（试行）；《医院信息系统基本功能规范》（卫办发〔2002〕116号）；《医院信息互联互通标准化成熟度测评方案》；《卫生信息共享文档编制规范》(WS/T482-2016)；《中国公共卫生信息分类与基本数据集》；《电子病历基本架构与数据标准（试行）》（卫办发〔2009〕130号）；《信息安全技术网络安全等级保护基本要求》GB/T22239-2019；《建立术语数据库的一般原则与方法》（GB/T13725-2019）；《术语数据库开发文件编制指南》（GB/T15387.1-2014）；《术语数据库开发指南》（GB/T15387.2-2014）；《术语数据库技术评价指南》（GB/T15625-2014）；《信息安全技术大数据服务安全能力要求》（GB/T35274-2017）；《信息技术大数据术语》（GB/T35295-2017）；《信息技术大数据技术参考模型》（GB/T35589-2017）；《信息技术大数据分析系统功能要求》（GB/T37721-2019）；《信息技术大数据存储与处理系统功能要求》（GB/T37722-2019）；《信息安全技术大数据安全管理指南》（GB/T37973-2019）；《电气照明节能设计》（06DX008-1）；《电气设备节能设计》（06DX008-2）；《公共建筑节能设计规范》（DB45/T392-2007）；《国务院办公厅关于印发国家政务信息化项目建设管理办法的通知》（国办发〔2019〕57号）；《医疗机构消防安全管理》（WS308—2019）。（3）其他编制依据IHE集成规范；HL7（美国医疗服务信息网络通讯协议）3.0/2.4版；医疗卫生机构及医用仪器数据传输标准HL7；SNOMED《国际系统医学术语全集》3.5版；LOINC标准；SOA相关技术标准；医学数字成像和通信标准DICOM3.0；国际疾病分类标准ICD10以及手术分类标准ICD-9-CM-3；四、建设原则本项目要求充分利用现有先进、成熟技术和考虑长远发展需求，统一规划、统一布局、统一设计、规范标准、突出重点、分步实施，在实施策略上，根据实际需要及投资金额，统一领导、统筹规划、标准化及核心业务重点推进，注重信息的共享和安全体系建设，保证系统建设的完整性和投资的有效性。主要遵循以下原则和策略：标准化和规范化严格遵循国家智慧医院、区域医疗信息化等有关法律法规和技术规范的要求，从业务、技术、运行管理等方面对项目的整体建设和实施进行设计，充分体现标准化和规范化。完整性和实效性基于业务、服务、数据架构设计的方法即模型保证数据产生、存储及使用等过程的完整性和实效性。先进性和实用性信息技术尤其是软件发展迅速，新概念、新体系、新技术迭相推出，造成了先进技术和成熟的技术之间的矛盾。而大规模、全局性的应用系统，其功能和性能要求具有综合性。因此，在设计理念、技术体系、产品选用等方面要求先进性和成熟性的统一，以满足系统在很长的生命周期内有持续的可维护性和可扩展性。整体系统应充分体现先进的管理思想和理念，采用先进的、成熟的且可持续发展的技术方法，并与医院的实际需求相结合。在设计开发中要充分考虑系统的实用性，开发出的系统必须自然、易操作，满足行业的习惯，从业务上讲，遵照业务规范；在技术上遵照技术规范。系统设计时必须考虑系统的易维护和管理性，应能保证系统在运行过程中出现故障时能够快速、准确的定位和排除，同时使系统具备远程维护的能力。软件界面应简单、美观、容易理解，易于掌握；方案选择和功能设置应追求实用性，必须切合医疗集团的实际情况，采用当前主流的云原生、微服务技术，保障未来信息的自主可控及持续可扩展。前瞻性和整体性必须充分考虑网络安全行业信息化的发展趋势和方向，结合我院医疗集团信息化发展的实际情况，对集团化微服务云平台的整体架构进行前瞻性和整体性的设计，统筹规划、统一设计，保证整个系统的统一和数据的一致。集成性和扩展性整个平台系统应具有开放、灵活、符合主流标准的集成架构，能够与温州市健康医疗现有的、在建的、将建的各相关应用系统进行有效的集成整合，避免重复工作，力求减少浪费。系统要有良好的扩展性、可移植性和升级前景，系统结构模块化，功能模块可以平滑扩充，要为可能的增值服务留有空间。可管理性和可维护性基于微服务架构的新一代智慧医院整体解决方案由多个系统和子系统组成，是一个较为复杂的系统体系，因此要考虑系统应具有良好的可管理性和可维护性。安全性必须保证数据信息的安全性和保密性。保证系统在运营过程中管理的各种数据的信息安全；保证各系统之间信息交互过程的安全；保证系统业务管理体系的安全。数据管理、使用应具有可靠的权限控制。充分考虑统一安全CA系统、统一身份认证和权限分配的方便性，采用有效手段保障系统和数据的安全性。稳定性和可靠性系统应具备必要的多活、容灾、冗余和备份设计，必须采取有效的多活中心设计和备份措施，以便在遇到灾难性破坏时，实行数据多点应用和快速恢复。同时系统运行应稳定、可靠。成本可控性在开发过程中对部分通用性模块采用在成熟商业软件或开源软件基础上进行二次开发，降低定制开发的成本，另外采用系统租用的方式可进一步节约投资。五、项目整体要求注：▲号条款为必须满足项，如有负偏离将作为无效投标。★号条款为重要技术要求，需提供相应的软件功能截图。主要模块：主系统清单里业务模块编号为1（不包括信息集成引擎）、2、3、5（不包括放射治疗管理系统、心电管理系统、重症临床信息系统等接入改造系统）、10）。本项目的建设分二期，详见【七、主系统清单】。必须充分考虑医疗行业发展趋势，采用先进的体系结构和软硬件技术，满足目前以及将来相当一段时间对系统的需求。从而达到既满足医疗机构或组织应用整合现阶段工作对系统水平和能力的要求，推动计算机应用向更高级阶段发展，又能够在今后数年内保持其技术的先进性和实用性，从而保护投资的有效性。软件的研发严格执行国际软件工程的标准（CMM、ISO等），符合国际医疗软件的规范（HL7、SNOMED、ICD-9/10、IHE、XML等），符合卫生部《医院信息系统基本功能规范》要求，符合与信息集成平台建设与成熟度测评相关规定，符合医院信息互联互通标准化成熟度测评标准，符合医疗卫生行业及信息化政策法规。▲主要模块（详见上面定义）的原厂商必须为同一厂商，源代码均需向采购人无偿提供，并由采购人验证确认（供应商提供承诺书，并由采购人对源代码进行编译运行为准）；其他系统涉及API接口相关的源代码和配套接口文档也需向采购人无偿提供，并由采购人验证确认。▲核心数据库：要求核心主数据库为ORACLE11g以上，能支持今后逐步迁移到国产数据库（PgSQL、TiDB、华为高斯），做到主数据库级异地多活管理。▲系统平滑升级：支持在保障原有系统功能正常运行的情况下，可小范围按相对独立业务子系统或小院区范围启用新系统，按模块逐步切换升级。▲支持主流的Kubernetes+Docker云原生微服务容器架构。▲支持提供标准开放的接口服务及文档，支持云原生服务开放的生态应用平台。▲供应商必须承诺组织现场实施团队规模不少于30人（按工作日日均，以甲方考勤记录为准）。▲项目总负责人必须在医疗信息化项目管理领域工作五年以上，必须具备至少参加过一个通过电子病历系统功能应用水平分级评价5级（或以上）或者2020年新版国家医疗信息互联互通成熟度测评四级甲等（或以上）等级同类项目实施经验；需提供佐证材料（医院提供等级测评及项目实施证明。六、技术总体要求6.1技术架构及搭建要求6.1.1微服务的软件技术架构在平台功能服务架构上，需基于Kubernetes容器框架、DevOps理念构建以业务逻辑为核心的全生命周期生态体系架构，面向不同的使用用户提供可视化管理监控服务，需包括应用托管、环境管理、部署管理、分级发布、应用监控、微服务治理、服务监控等。需采用云原生的微服务架构体系，且兼容国内外先进、多源丰富服务技术栈，具体应包含：（1）技术部分：1.微服务框架及技术组件可采用ApacheDubbo、SpringBoot、SpringCloud、ServiceMesh、ServiceComb、Istio、Mesher。2.前端组件方面，需支持Node.JS、Reactjs、Vuejs、HTML5等多种开发语言，打包工具需支持NPM、Webpack、Jenkins等多种方式。3.应用服务方面，需支持SpringBoot/Tomcat基础框架，且支持软负载均衡方案、支持分布式文件存储服务、分布式任务调度、具备缓存服务Redis、分布式主键、工作流引擎等服务。4.编程语言方面，后端需支持Java、Go、Python、.NetCore、Erlang等多种开发语言，前端需支持Javascript、Node.JS、Reactjs、Vuejs、HTML5等开发语言，WEB页面需支持Chrome49+。5.架构服务方面，依赖管理需采用nexus，调用链路需采用Jaeger，服务发现需采用Nacos等技术体系，分布式事务需采用Seata（支持TCC、SAGA、XA、AT事务模式），配置中心需采用Nacos。6.数据服务方面，业务数据库需支持Oracle等数据库，大数据分析需采用Spark、Flink、Hive、MongoDB、Hbase、ElasticSearch、ClickHouse、Hudi等大数据计算引擎（2）容器部分：1.容器服务方面，需遵循设计容器编排（Kubernetes）、容器引擎（Docker/Podman）、镜像管理（Harbor）、容器网络（calico/flannel）、容器部署（Helm/Operator）等技术，并配合平台相关管理应用、数据及服务的部署。2.容器编排要求支持事实标准kubernetes，并且打包容器方案支持containerd

等CRI运行时（如podman等）来代替docker。3.容器运维服务方面，需提供日志监控功能，且支持ELK、Grafana、Prometheus等技术，运维持续集成需支持gitlab、Jenkins等打包工具。4.容器安全服务方面，平台权限管理需支持RBAC，传输加密需支持SSL、TLS等加密方式，数据审计需支持Auditing，容器漏洞扫描需支持CVE-SCAN等技术。5.基础设施方面，云虚拟化基础设施需支持Vmware、华为云、阿里云、腾讯云、百度云、金山云等，操作系统需支持RedhatLinux、CentOS7.6或以上版本，网络存储支持NFS等。6.1.2支持集群化、分布式部署应采用集群结构，提升系统扩展性。并随着系统业务的发展，该集群可动态增加扩展节点。同时，应用分布式结构将系统按照业务功能，拆分成独立的分系统，各分系统以“服务”形式展现，并可独立运行在容器中，通过主流的通信方式进行互相通信。6.1.3支持多级缓存应在整个系统架构的不同系统层级进行数据缓存建设，以提升访问效率，对于长时访问的数据、访问频率很高的场景，在缓存空间足够的情况下可支持不过期缓存。6.1.4平台化的系统交互支持实时与非实时的消息交互，采用主流的技术（如：Webservice、MQ、HTTP、WebSocket、Mqtt等）确保平台化的系统交互。6.1.5数据交换管理数据交换管理以整合各个医院信息系统或各医院数据中心的数据，为各医院之间的数据共享、业务协作以及对医院监管的各种交互服务提供数据共享与交换平台，实现各医院之间业务数据的实时交换共享和业务互联互通。其功能要求但不限于包含企业服务总线、服务编排与发布、消息订阅与发布、消息路由与转换、应用服务接入管理、服务权限管理、服务监控与调用分析管理等功能。6.2设计及管理要求6.2.1性能指标要求（1）应用系统性能需求1.应用系统性能需求：应用系统应满足用户的要求，稳定、可靠、实用。2.应用系统响应时间需求如下：1）系统稳定性高，年故障时间小于8小时，平均故障修复时间小于30分钟，故障修复最长时间小于2小时。2）使用频率极高的功能：非高峰时段，响应时间小于1秒；高峰时段，响应时间小于3秒。3）使用频率较高的功能：非高峰时段，响应时间小于3秒；高峰时段，响应时间小于5秒。4）使用频率一般的功能：非高峰时段，响应时间小于5秒；高峰时段，响应时间小于10秒。5）使用频率较低的功能：非高峰时段，响应时间小于10秒；高峰时段，响应时间小于15秒。6）使用频率极低的功能：响应时间小于30秒内。7）处理大量数据的功能：响应时间小于1小时。（2）服务平均响应时间1.患者注册服务调用，单个患者注册平均响应时间小于1秒；2.健康档案查询，按患者唯一标识查询，返回患者电子健康档案文档目录树时，平均响应时间小于2秒；3.患者基本信息查询，总记录50万以上，按患者唯一标识查询单个患者查询平均响应时间小于2秒；总记录100万以上，按患者唯一标识查询单个患者查询平均响应时间小于3秒；4.基于人口统计学信息的患者信息匹配（基于索引），总记录50万以上，返回患者唯一标识数据，返回记录数小于10条时，平均响应时间小于10秒；总记录100万以上，返回记录数小于10条时，平均响应时间小于15秒。（3）统计分析性能1.简单统计报表查询：响应时间≤10秒；2.千万级数据量下单项统计的响应时间≤5秒；3.复合汇总统计响应时间≤120秒；4.生成复杂统计报表的响应时间≤180秒。6.2.2安全性要求1.系统应该可实现7×24h连续安全运行，性能可靠，易于维护。2.可选择操作系统提供系统的稳定性；应用大型关系数据库或后关系数据库提高系统的处理速度和响应时间。3.对超级用户实行互相监督和访问、删改的痕迹保留和永久性备份保留的安全机制，以确保有关过程的安全性。4.研究开发过程严格按照ISO9001和CMMI的有关规定进行。6.2.3互联互通要求要求解决医院信息系统的系统异构集成、数据共享和数据交换传输标准等关键性技术问题。全院各个应用系统均与信息集成平台互联，并通过信息集成平台实现相互之间的数据交换和应用服务的调用。建立标准化交互体系，从生产系统、分析系统、接口交换等各层面都能够产生并使用标准化的数据和消息，将医院所有信息系统以灵活的方式进行互联互通，并对所有需要接入的系统提出标准化和改造要求，整合各个业务系统。要求建立一个异构系统（如：HIS、LIS、PACS、CIS等）之间、医院信息平台和区域信息平台之间实现互操作（信息共享、流程交互）的平台，符合卫计委电子病历互联互通标准，采用webservice协议、MQ等多种方式让各医疗信息系统之间以一种统一的数据标准、统一交互框架、统一的安全认证实现系统集成，实现业务系统之间信息的“互认”和“交互”，提高流程标准化、自动化和可靠性。互联互通服务功能要求：要求《医院信息平台基本交互规范》要求，建设包括但不限于：52个互联互通交互服务。包括：新增个人身份注册、个人信息更新、个人身份合并、个人基本信息查询、新增医护人员、医护人员信息更新、医护人员信息查询、新增医疗卫生机构（科室）注册医疗卫生机构（科室）信息更新、医疗卫生机构（科室）信息查询电子病历文档注册、电子病历文档检索、电子病历文档调阅、医嘱接收、医嘱查询申请单接收、申请单查询、医疗卫生人员注册服务调用、医疗卫生人员更新服务调用、医疗卫生机构注册服务调用、医疗卫生机构更新服务调用、调用区域个人身份注册服务、调用区域个人基本信息查询服务、病历文档上传服务调用、病历数据检索服务调用、病历数据查询服务调用、门诊就诊登记服务、门诊就诊查询、住院就诊登记服务、住院就诊查询、出院登记服务、出院信息查询等52个交互服务。实现院内各业务系统的数据交换和信息共享，要求支持现有平台接口模式，不改造现有系统或较少改造情况下，实现现有接口的平稳迁移。6.2.4数据集要求按照国家卫生健康委2020年发布的《医院信息互联互通标准化成熟度测评指标体系》第2.1章节数据集标准化建设情况中列出了58个数据集，投标方应主导按国家标准对应的业务系统进行改造，必测的数据集满足互联互通的相关要求同时，实现医院自定义数据集的扩充。根据相关标准，建立完整的数据集，对各临床业务系统数据集信息进行梳理，针对数据信息的不规范进行改造，如：值域不完整、值域信息不一致等。术语字典在平台主数据管理系统进行统一管理。要求58个基本数据集如下：序号基本数据集基本数据子集1电子病历基本数据集患者基本信息子集2基本健康信息子集3卫生事件摘要子集4医疗费用记录子集5电子病历基本数据集门急诊病历子集6急诊留观病历子集7电子病历基本数据集西药处方子集8中药处方子集（选测）9电子病历基本数据集检查记录子集10检验记录子集11电子病历基本数据集治疗记录子集12一般手术记录子集13麻醉术前访视记录子集14麻醉记录子集15麻醉术后访视记录子集16输血记录子集17电子病历基本数据集待产记录子集（选测）18阴道分娩记录子集（选测）19剖宫产手术记录子集（选测）20电子病历基本数据集一般护理记录子集21病危（重）护理记录子集22手术护理记录子集23生命体征测量记录子集24出入量记录子集25高值耗材使用记录子集26电子病历基本数据集入院评估记录子集27护理计划记录子集28出院评估与指导记录子集29电子病历基本数据集手术同意书子集30麻醉知情同意书子集31输血治疗同意书子集32特殊检查及特殊治疗同意书子集33病危（重）通知书子集34其他知情同意书子集35电子病历基本数据集住院病案首页子集36电子病历基本数据集中医住院病案首页子集（选测）37电子病历基本数据集入院记录子集3824h内入出院记录子集3924h内入院死亡记录子集40电子病历基本数据集首次病程记录子集41日常病程记录子集42上级医师查房记录子集43疑难病例讨论子集44交接班记录子集45转科记录子集46阶段小结子集47抢救记录子集48会诊记录子集49术前小结子集50术前讨论子集51术后首次病程记录子集52出院记录子集53死亡记录子集54死亡病例讨论记录子集55电子病历基本数据集住院医嘱子集56电子病历基本数据集出院小结子集57电子病历基本数据集转诊（院）记录子集58电子病历基本数据集医疗机构信息子集6.3基于微服务架构的平台建设技术要求6.3.1技术架构要求本次项目要求通过微服务平台封装对外提供服务，外部系统使用HTTP、HTTPS、RPC或者TCP等协议通过微服务网关来访问使用微服务。内部微服务应用通过RPC协议访问使用微服务；服务管理服务器采用微服务平台套件中的相关组件。通过服务治理组件提供服务全生命周期（创建，运行，管理和安全）管理的关键服务。管理服务器作为服务生命周期管理的核心组件，负责服务的创建和发布，其创建的服务将发布到服务网关组件，其与服务网关的通讯协议是HTTPS/RPC。6.3.2技术中台要求技术中台采用分布式服务架构进行建设，支撑每一个业务中心的独立部署，由分布式运行机制保障上层服务的正常运行基础。核心组件微服务框架，易于扩展和部署，对弹性伸缩、灰度发布等互联网场景有良好的支持。服务注册与发现服务注册是服务发现机制的核心，服务实例将自己的服务信息（包括网络IP、端口、服务名）注册到服务注册中心，服务注册中心将服务信息以及服务健康状态通过API暴露出来。服务消费方通过注册中心获取到服务实例信息，并通过IP、端口、服务名的组合去请求服务提供方提供的服务。除了完成以上核心功能外，服务注册与发现还需要实时监控服务实例的健康状态，一旦服务实例不可用，将通知各服务消费方移除无效服务实例。另外，一个服务可能存在多个服务实例，需要根据不同的负载均衡算法来保持服务调用的均衡。弹性伸缩在分布式集群里通过服务探针，可以监控应用和服务容器的状态，自动调整服务实例的数量。扩容，在监控到服务容器出现瓶颈，包括负载CPU、RT指标都出现紧张时，能够自动增加应用实例到集群中。缩容，在监控到服务容器负载减少出现资源浪费时，自动释放服务实例减少成本。调整弹性伸缩的规则支持用户灵活配置。限流降级分布式应用服务需要提供限流功能，时刻感知流量的变化，并做出相应调整。限流的策略可分为限制访问的绝对数量和控制流速（整流）。整流的算法有令牌桶算法，限制总数可通过设置规则来实现。降级是指某个服务被调低级别后，本服务的消费者在调用时即刻返回失败，这样服务实例将不会被调用。当然，也可以设置一个默认返回值。降级的规则支持用户灵活配置。灰度发布灰度发布的技术用于两个不同版本同时在线上并行的情形，既可用于业务试错，也可用于版本发布。一旦确认新版本达到目的，就可以平滑地从旧版本切换到新版本上。灰度发布需要解决两个方面的问题，才能顺利达成目的。（1）多版本部署多版本部署分为客户端部署和服务端部署两个方面。客户端如果是原生系统，可以用热更新技术实现，比如Android的CodePush。客户端如果是H5，则需要在服务器端部署一套CSS和页面。服务端部署要求应用服务、中台服务都要单独部署一套，通过版本来区分。如果需要对MQ的数据消费进行隔离，则需要重新定义Topic或Tag（2）流量切分流量切分包括入口流量切分和中台服务流量切分。入口流量的切分策略通常包括按服务器权重、IP地址段或用户标签等来切分流量。中台服务流量切分通过分布式服务发现机制，植入流量切分规则，控制流量的方向。分布式事务分布式事务技术（DTP）用于保证跨多个资源事务的一致性。DTP模型的典型应用场景是两阶段提交协议，多个资源管理器（RM）由一个事务管理器（TM）进行管理，事务管理器控制着全局事务和分支事务。DTP模型分别通过准备阶段和提交阶段来协作完成全局事务：准备阶段，由TM通知各RM准备事务，并接收RM的准备结果；提交阶段，由TM通知各RM提交分支事务，并接收RM的执行结果。RM执行结果都成功，那么TM返回成功，如果任意一个RM执行失败，原则上TM都会执行回滚。但在实践过程中，M失败的情况也有不同，TM可按照客户的需要判定是否回滚所有事务。目前，各大云厂商都提供了分布式全局事务，其中阿里云的GTS已经实现了分布式全局事务。在应用场景涉及的系统和步骤不是特别多的情况下，GTS可以方便快速地实现分布式事务。扩展点机制为配合上层快速的业务变化，中台需提供了很多配置化功能，支持灵活快速地对业务功能进行扩展。除此之外，扩展点机制提供在不修改现有代码的情况下，灵活扩展新功能。扩展点机制源于Java的SPI机制，当业务中台的某一个业务点遇到新业务逻辑比当前逻辑差别较大时，可以使用扩展点机制来实现。6.3.3分布式服务框架分布式服务技术架构要求要求通过一定的技术架构对系统进行封装形成易于消费的服务，从而实现业务能力粒度上的重用、组装、维护和管理，来灵活迅捷构筑实现特定业务目的的企业级应用技术特性，以统一的方式发布、调用服务，不用考虑分布式领域中的各种技术实现细节，支持服务容量线性扩展，服务可根据部署需求自动上下线，提供服务路由（接口级、方法级、参数级），服务归组，服务限流，安全控制追踪等服务治理能力。功能性要求服务注册中心集群应提供服务的发布订阅功能，作为各服务提供者和消费者的中间媒介，动态地向服务消费者应提供服务提供者的信息，以便供消费者调用。服务治理中心集群向服务的提供者和消费者提供服务的参数和规则信息。从技术手段上，分布式服务框架必须提供相应的支撑，具体体现为服务的路由规则、服务归组、权重规则、限流规则以及对体系整体管控分析非常重要的调用追踪能力。服务提供者和服务消费者通过代理层进行通信，代理层不仅要求提供远程调用功能，还应包含其他的服务治理功能，如限流，安全等。技术指标要求本项目提供的架构要求满足分布式服务框架的远程协议与序列化高性能要求：在单连接、100并发、100字节请求与回复信息体（三级组合对象）、硬件配置8核CPU、24G内存、千兆网卡，TPS不少于10万。分布式服务框架的中心集群负责服务注册订阅信息和服务治理规则的管理，该集群的规模取决于要管理的服务应用实例的个数。本次项目要求对于完整的服务治理中心集群：平均每个负责服务注册订阅的服务器，能管理的服务应用实例个数不低于1000;平均每个负责服务治理规则的服务器，能管理的服务应用实例个数不低于200。其他特性要求可扩展性。服务提供者实例的新部署在启动加载时自动完成服务提供信息的更新，直接实现服务容量的线性扩展。可用性。服务提供者、以及服务的注册中心和治理中心，都以软负载的分布式集群方式实现高可用，无单点缺陷。6.3.4分布式消息中间件分布式消息中间件要求能够支持海量消息堆积处理能力，缓解爆发式访问压力，并能够以异步方式实现业务能力的解耦，充分利用系统资源。消息中间件应位于处理用户请求的业务模块和其他共享业务模块之间，负责将业务的处理流通过异步消息的方式导引到与业务相关的共享业务模块中进行处理，保证业务逻辑的正确。技术架构要求分布式消息中间件从技术架构上应包括以下几部分：消息配置中心：主要提供代理（Broker）信息的推送功能发布者(Publisher)：通过连接到某个代理(Broker)，提供发送主题和消息的功能。订阅者(Subscriber)：通过代理（Broker）订阅并接收消息。代理(Broker)：代理负责发布和订阅的处理，根据发布订阅的请求把消息从发布者发送到订阅者。发布者通过从消息配置中心获得可用的Broker状态后，可以连接到某个Broker来创建主题并发送消息，订阅者连接到Broker订阅消息，当有消息到来时，Broker会将消息发送给订阅者。功能性要求功能点功能要求分布式事务支持对生产和消费的事务处理，满足最终一致性需求；消费者集群支持消费者线程数量的在线动态扩展；支持消费者机器数可以在线动态扩展；支持多个消费者集群可以平均消费消息；生产者顺序支持生产者同主题的发送顺序；消费结果回送支持生产者如果需要获取消费者的处理结果，可以选择在所有消费者均消费完毕后，将结果推送给上游。如：宽带开户场景。异常消息处理生产者系统异常/业务数据错误等原因，可能产生大量的错误消息，需要支持对待处理消息的处理。消息状态确认支持消费者向生产者提供消息消费状态的确认。负载均衡支持client连接系统时，不需要通过软硬件负载设备，也可以满足可靠性及负载均衡需求；消息压缩支持对大报文消息进行压缩，提高消息传输效率。流量控制支持流量控制。消息优先级支持消息级别的优先级管理。如：BOSS业务需要优先处理VIP号码、强制开机业务优先级较高。多消费者顺序支持业务逻辑处理的多消费者顺序。如：订单消息先到计费域、再把消息给服务开通消费。主题映射可以支持同一个主题，不同消费者的消费规则存在差异，可以通过主题映射将一个原始主题映射成多个不同的目标主题，再基于目标主题进行针对性处理。如：CRM订购实例，流量套餐发给计费和营销；非流量套餐发给计费。订购实例只有一个主题。多主题消费顺序可以支持消费者多主题消费的顺序。不限于使用消息中间件还是消费者自行处理。如：开户业务将消息分别发到两个主题上，一个是服务开通订阅，一个是计费订阅，那么需要保证服务开通先消费成功后，计费才可以再消费。消息过滤支持某些特定的消息（业务参数关联确定），不需要推送给任何消费者。限时消费支持对发送时间有限制的消息，需要系统自动根据时限要求将超时的消息删除。如：短信消费消息。定时消费支持生产时消息指定消息的发送时间，需要在到达预定时间后才发送给消费者。批量发送支持批量发送消息，一次性提交。批量消费支持消费者一次性请求一定数量的消息，处理后逐步提交消费结果。多语言客户端支持c++和javaapi。技术指标要求分布式消息中间件的技术指标：单台16核、64G内存、平均单台broker同步双写可处理的TPS不低于6000。其他功能特性配置功能：要求支持对消息中间件正常运行所需要的系统参数（如节点信息）、业务参数（如主题消息、客户端信息、发布订阅关系）进行可视化配置；支持参数配置热加载，配置立即生效，不需要重启。1.监控功能：支持对消息中间件运行状态的实时显示，可以实时查看当前时刻系统各个节点的实际运行状态（消息状态、内存、连接数等）。2.维护功能：支持对错误消息、超时消息等进行处理；支持消息收发测试。3.扩展性：Publisher、Broker、Storage、Subscriber等均可弹性扩展4.高可用性：Publisher支持Broker异常时候，消息存放本地；Publisher到Broker之间支持高可用；Broker支持高可用；Storage支持高可用；Subscriber支持高可用。5.易维护性：提供系统运行时状态的界面展现，可以实时查看当前时刻系统各个节点的实际运行状态（消息状态、内存、连接数等）；系统所有操作（配置、监控、查询等）均有相关界面支持；所有配置的修改，可以立即生效，不需要重新启动及影响生产；系统资源等情况，考虑支持主题在不同物理主机之间动态迁移，且不影响生产。6.安全性：可以对客户端的身份、地址等信息进行检测，以避免非授权用户的操作及各种越权操作。7.高可靠性：支持Broker的容错；支持消息持久化Storage的容错；支持配置中心的容错。6.3.5分布式数据库服务技术架构要求分布式数据库服务用于支撑海量交易类数据操作，提供标准SQL接口，对应用屏蔽数据分布，应用感知的是一个逻辑的虚拟数据库，数据分布对应用透明；数据库集群部署，能够自由增加数据库节点，实现弹性扩展，不需要停止业务系统进行割接操作；以高性能和自稳定性为主，高兼容性为辅的SQL关系型数据库访问能力。功能性要求功能点功能要求分布式数据管理支持节点路由规则管理；支持多种路由规则设定；分布式节点对应用完全透明，做到应用无需关心数据位置；路由自动更新，对应用无影响；线性扩展能力数据节点自动伸缩、水平动态扩展；数据节点数据自动迁移和再均衡；能够通过扩展分布式节点提升集群处理容量；支持节点变化时的数据自动重新分布；分布式事务支持完整的分布式事务管理能力；通过分布式事务保障跨节点数据操作的事务一致性；支持分布式事务的提交与回滚；标准SQL92能力支持DDL/DML基本语法解析；支持高级SQL语法解析功能；支持SQL92标准，支持整型、字符型、时间型等多种数据类型定义；支持序列、视图、单节点的多表关联查询、子查询等；支持跨节点的分组、排序、分页功能。提供查询优化功能，完善的查询计划功能；标准访问接口支持C、Java开发接口，提供标准CAPI;支持JDBC、ODBC等数据库通用标准接口；数据安全提供数据备份与恢复机制，提供REDO日志，支持内存数据写入磁盘持久化；当系统异常宕机可以从磁盘恢复数据，保障数据安全；节点备份提供一主多备的备份制，当主节点的数据变化实时复制至备份节点支持当主节点异常时，系统自动切换至备节点，保障系统操作连续服务不中断。数据同步支持从分布式内存数据库向磁盘数据库（Oracle、Sybase、MySQL等）的实时数据同步；支持从磁盘数据库实时向内存数据库同步功能；多种数据访问模式支持本地直连(DirectAccess)、Socket网络连接等多种数据访问模式；支持当应用与数据在同一台主机时采用直连模式可以提供更为高效的数据访问性能；索引算法支持Hash索引与T-Tree索引，根据数据访问特点采用不同的索引算法加快数据访问性能；锁管理支持数据库行级锁，实时锁超时检测、死锁判定与自动释放；运维支撑能力提供SQL执行工具；提供分布式系统运行状态监控工具；提供数据的导入/导出工具；提供数据迁移、核查工具；支持对SQL执行状态的查看与统计；支持对分布式节点的统一管理工具。多平台支持能力支持Unix、Linux、Windows等主流平台认证管理支持不同安全级别的数据库用户管理Infiniband支持支持infiniband网卡通信功能技术指标要求单个分布式数据库集群可以承载的最大简单查询TQPS能力能达到20000，延迟保持在2ms内；单个分布式数据库集群可以承载的最大复杂统计分析查询TQPS能力达到8000，延迟保持在6ms内；单个分布式数据库集群可以承载的最大复杂Join分析类查询的能力达到6000，延迟保持在8ms内。其他功能特性要求可扩展性：支持在线的数据库平滑扩容。高可用性：要求分布式数据服务的负载均衡集群、分布式数据库服务器集群、以及用户控制平台，都以软负载的多实例部署或集群方式实现高可用性。建议数据库磁盘做RAID10。易用性：用户使用分布式数据服务如同使用单一关系型数据实例，数据切分与路由自动完成，对应用透明；兼容MySQL交互协议；读写分离自动处理，读取请求可自动转在数据库的备库上进行，以降低主库压力。微架构云原生成熟度要求1.微服务云原生架构在技术层面分为六个不同维度进行成熟度测评，包括：服务化能力（Service）、弹性能力（Elasticity）、无服务器化程度（Serverless）、可观测行（Observability）、韧性能力（Resilience）、自动化水平（Automation）六个不同维度。每个维度分别考量不同的技术特点：2.服务化能力：用微服务或者小服务构建业务，分离大块业务中具备不同业务迭代周期的模块，并让业务以标准化API等方式进行集成和编排；服务间采用事件驱动的方式集成，减小相互依赖；通过可度量建设不断提升服务的SLA能力；服务各接口完成独立功能、保证单一职责，提供各接口说明文档、单接口测试用例、业务流程测试用例，支持技术异构，支持多语言治理体系有服务发现、服务配置管理、服务负载均衡、服务熔断/限流/降级3.弹性能力：自动根据业务峰值、资源负载扩充或者收缩系统的规模；4.无服务器化程度：在业务中尽量使用云服务而不是自己持有三方服务，特别是自己运维开源软件的情况；并让应用的设计尽量变成无状态的模式，把有状态部分保存到云服务中；尽量采用FaaS、容器/应用无服务器的云服务5.可观测性：IT设施需要被持续治理，任何IT设施中的软硬件发生错误后能够被快速修复，从而不会让这样的错误对业务带来影响，这就需要系统有全面的可观测性，从传统的日志方式、监控、APM到链路跟踪、服务QoS度量；6.韧性能力：除了包括服务化中常用的熔断、限流、降级、自动重试、反压等特性外，还包括高可用、容灾、异步化的特性；7.自动化水平：关注整个开发、测试和运维三个过程的敏捷，推荐使用容器技术自动化软件构建过程、使用OAM标准化软件交付过程、使用IaC（InfrastructureasCode）/GitOps等自动化CI/CD流水线和运维过程6.4温州市健康云平台服务扩展要求根据温州市卫健委相关文件精神，遵循“上云为常态，不上云为例外”的原则，落实“全市各县（市、区）卫健局及医疗卫生健康机构于发文之日起，原则上不应再单独投资新建机房设施或新建第三方云资源租赁服务，以使用全市统建的健康云为主”的相关要求，避免重复建设及系统迁移带来的成本和风险，整体项目建设应充分考虑全面接入温州市健康云的相关技术要求和未来业务拓展要求，不仅能够满足医院自身的业务需求，还能够支撑兼顾区域医联体/医共体、中小型医疗机构、民营医院的扩展业务需求。6.4.1面向区域业务全领域覆盖的云基础架构医院作为区域医疗龙头，利用医院相对完备的体系，开展区域协同业务支持、与区域其他医疗机构间的信息互联互通共享，构建全人全程健康管理系统。支撑面向突发公共卫生事件的预警和监测体系、应急指挥管理体系、医疗协同救治体系和数据治理科研体系建设。整体架构以温州市健康云平台提供的计算资源、存储资源、安全资源为IaaS平台保障日常业务的计算、运维、存储、安全等。采用面向医疗健康领域，基于微服务云原生架构定制化开发的智慧医疗云生态PaaS平台，实现对医疗健康业务的解构、设计、服务开发和基础组装，形成具备医疗领域功能特色的服务平台底座；在具体服务层面，针对大型医疗机构、区域医联体/医共体、中小型医疗机构及民营医院的不同业务属性和业务场景分别组装不同的SaaS服务，实现数据服务共享、前台业务个性化的灵活业务形态。6.4.2面向主体医疗机构的服务支持主体医疗机构由于日常业务繁重，流程结构复杂，整体架构应支持健康云（或称区域私有云）与医院主机房的分布式多活中心部署，为医院提供一套生产用的微架构云原生IaaS+PaaS平台。主体医疗机构作为区域医疗业务的龙头，覆盖区域医疗健康业务的绝大部分内容，是整体架构的核心部分，微服务云原生架构中的微服务拆解、微服务单元设计、服务交互设计都应该以主体医疗机构为蓝本，构建全面、稳定的基础服务平台。整体系统架构应确保本项目各系统可基于该平台稳定运行5年以上，并与医院中心机房的平台形成多活共存互备的一体化应用容灾系统。6.4.3面向区域医联体/医共体的服务支持医联体/医共体是区域医疗的核心组成，在整体技术架构上依托市级健康云和智慧医疗云生态体系，整合人工智能、大数据、物联网、5G等核心技术架构来共同支撑医共体信息化建设。智慧医疗云生态体系是医共体建设的关键基础架构之一，未来将作为信息交换和共享的核心，实现医共体内临床和管理相关领域跨系统的信息交互；基于大数据中心及决策支持系统能够在整合医共体各项临床和管理业务数据源的基础上，对数据进行标准化转换，提供各类基于数据的管理、决策、监管、科研和深层次的信息化应用，通过业务中台中的AI智能服务，与基层医疗机构转诊、辅助诊断、辅助治疗、智能影像识别等。而物联网、5G、区块链技术主要用于构建各类创新应用和服务模式，如互联网+护理服务、可穿戴设备健康监测、可信任的数据交互凭证等，从信息化的层面去支持深化“最多跑一次”在医疗卫生领域的应用。系统清单需要按子系统进行分别报价，其中每个业务模块的报价不得超过该业务模块的最高限价，每个子系统的报价不得低于所属业务模块的报价总价/该业务模块子系统数×20%。序号业务模块业务模块限价（万元）业务分类子系统数量建设类型建设分期1.微服务应用支撑5001.1.微服务基础底座1.1.1一体化微服务支撑平台1套新建一期1.1.2一体化运维管理平台1套新建一期1.1.3统一用户认证与单点登录系统1套新建一期1.1.4智能门户系统1套升级改造或新建一期1.2.院内信息集成1.2.1信息集成引擎1套新建一期1.2.2集成平台运行监控系统1套新建一期1.2.3集成平台服务管理系统1套新建一期1.2.4SDK管理平台1套新建一期1.2.5集成平台鉴权管理系统1套新建一期1.3.统一API接口平台1.3.1HQMS1套新建二期1.3.2医保及新农合1套新建二期1.3.3疾控中心(CDC)1套新建二期1.3.4血液中心1套新建二期1.3.5阳光采购平台（药品、器械、耗材）1套新建二期1.3.6省平台、一朵云接入1套新建二期1.3.7温州市数据中心检验检查等接入1套新建二期1.3.8产前建档、母婴健康平台接入1套新建二期1.3.9最多跑一次接入1套新建二期1.3.10温州市双向转诊、远程会诊、云门诊接入1套新建二期1.3.11急救中心、体检等接入1套新建二期1.3.12其他机构（第三方挂号平台、公安、银行、保险等）1套新建二期1.4微服务生态平台建设1.4.1微服务生态平台建设1套新建二期2.数据中台3002.1.数据建模2.1.1数据模型管理系统1套新建二期2.2.数据服务2.2.1数据服务开放平台1套新建二期2.2.2患者主索引管理系统1套新建二期2.2.3主数据管理系统1套新建二期2.3.数据运维2.3.1数据安全管理系统1套新建二期2.3.2可视化数据集成引擎1