招标代理公司（立即查看） 受业主单位（立即查看） 委托，于2020-07-01在采购与招标网发布 新民市人民医院及分院医共体信息系统建设采购公告。现邀请全国供应商参与投标，有意向的单位请及时联系项目联系人参与投标。 新（略）及（略）院医共体信息（略）建设的招（略）及（略）院医共体信息（略）建设（项目编号（略）-（略）-（略）获取招标文件')" rel="nofollow" style="color:red;" title="标书制作">招标文件，并于（略）-（略）-（略）（北京时间）前递交投标文件。一、项目基本情况项目编号（略）-（略）及（略）院医共体信息（略）建设预算金额：人民币（略）。包组编（略）及（略）院医共体信息（略）建设最高限价（略）采购需求：查看合同履行期限：项目完成时间：合同（略）采购政策内容：详见招标文件本包组不接受联合体投标。1.项目介绍通过（略）合信息资源，开发信息标准、建设（略）体性应用体系、集成业务（略）、基础设施（略）、跨部门、跨（略）络互联互通和业务协同，（略）信息（略）、新农合信息（略）、公共卫生管理信息（略）、区域卫生综合管理（略）等（略）的深层次应用与发展，提高卫生管理工作效率和决策水平，实现居民电子健康档案、电子病历、影像和检验结果的共享，提高对深化医药卫生体制改革各项任务实施情况动态监测、宏观调控和科学管理能力，支撑新医改的顺利推（略）部门提供及时、准确、全面的信息，为新民市居民提供高科技的数字卫生服务。2.项目内容及总体技术要求2.1项目内容项目内容包括（略）、医共体应用体系：主要包括患者主索引、集成平（略）及（略）接口、电子健康档案浏览器、（略）、（略）、慢性病管理（略）、健康展示（略）、全民健康促进（略）电子（略）一体化管理（略）影像（略）视频会诊（略）双向转诊（略）心电（略）检验模块。2、基础设（略）络及云服务模（略）（基础架构服务（略）络（略）机房设施。3、智能化（略）：面（略）的协同服务需求，采用云服务模式，（略），主要包括（略）、病房呼叫（略）、候诊叫号（略）、信息发布（略）、视频监控（略）、语音广播（略）及其它医用设施。4、专线服（略）络线路。（略））并提供5年线路服务。5、（略）集成及维护服务：包括相关硬件保养、安全等级保护相关（略）部署、调试及（略）维护服务。2.2总体技术要求2.2.1技术架构及技术采用1、投标人须按照招标要求提供完（略）、详细的（略）技术设计和实施方案（作为投标文件的组成部（略）），能够为（略）构建统一、可扩展的（略）体框架，包括但不限于（略）业务及功能架构、应用架构、数据架构及技术架构。2、要求采（略），支持面向SAAS的应用（略）开发、客户化部署、运行及管理，并提供包括但不限于业务集成、流程管理（BPM）、内容管理、门户（Portal）体系、商业智能（BI）等的基础构件。3、基于结构化文档技术，支持对医疗及公共卫生服务过程中各类文件的（略）并与Office无缝集成，可实现对电子病历、检验报告等专业文档体系的模板定制和管理，保证不同岗位、不同用户填写的完（略）性、准确性和一致性。4、采用统一的工作流组件，支持医共体内、外各类医疗服务、管理流程、操作流程的定制，支持各类临床、业务数据及表单集成、运行实例监控及安全管理；提供灵活定制、管理流程的工具，包括但不限于工作流定制工具工作流引擎、应用开发接口、业务表单定制工具及业务（略）工及用户授权管理等组件。5、实现面向（略）数据建模，在（略）合各类结构化、半结构化及非结构化医疗服务、管理信息和数据基础上，建立（略），实现包括但不限于主数据管理、服务总线（ESB）、业务数据体系、统一数据仓库及（略）析处理（OLAP）的（略）合服务，通过采用BI、报表服（略）的综合性查询、统计及报表功能。6、服务器及数据存储（略）采用“服务器集群化、存储（略）布化”新型架构，通过按服务类型配置相关的多节点IAAS环境，建立动态资源（略）配和资源管理体系，从根本上去除（略）单一故障点、提升（略）并发应用性能、提高硬件（服务器）使用效率（降低成本）及保证可持续扩展。2.2.2易用性及性能1、应用（略）基于统一门户架构（略）符合医疗人员、公共卫生服务管理人员及居民个人的应用习惯，具有统一风格；实现通过个性化页面及站点配置，提供丰富的个性化配置选项，支持用户按其使用习惯和操作模式对应用界面自行配置。2、对不同类型数据的录入提供多种可选的录入方式，支持全键盘操作录入数据（特别是大量数据和即时数据），最大限度提高数据处理效率。3、应用（略）应根据（略）的（略）体应用规模和业务处理要求，通过采用BSS（略）布处理、数据库（略）区、服务器集群和负载均衡支持等技术措施，充（略）保证应用（略）的（略）体性能优化；4、业务并发处理性能：应用（略）应能够7×（略）小时连续不间断稳定工作，页面响应时间不超过2秒，视频会话等（略）交互实现即时响应、流畅操作；复杂统计汇总、综合查询等操作响应不超过5秒。2.2.3安全性及可靠性1、投标人须结合项目应用体系、基础设施及智能化（略）的（略）体情况，制定信息（略）安全方案，须达到现行等级保护三级标准要求。2、建立统一的（用户）身份管理、认证、授权及审计体系，基于统一门户，实现单点（略）（即经一次（略）即可访问所有授权的（略）应用和服务），与ActiveDirectory及LDAP兼容，并支持采用（略）的认证方式。3、采用基于“（略）色”的授权机制，保证应用安全性和数据一致性；支持对用户操作或行为的审计，从技术层面保证数据修改和功能操作不可抵赖；4、应用（略）运行所涉及的所有资源、服务均须具备可靠性技术保障，保证（略）的长期稳定运行，通过先进、可行的技术配置保证应用（略）体故障切换时间不超过（略）秒。5、应用（略）具有抵（略）漏洞、恶意代码等等）影响和人为操作失误，完全保证相关程序、可执行代码（或脚本）的稳定性；保证数据的完（略）性、一致性、可回溯性及可恢复性。2.2.4管理及运行维护1、基本的（略）维护应包括但不限于工作参数修改、数据字典维护、用户权限控制、操作口令或密码设置和修改、数据安全性操作、数据备份和恢复、故障排除等。2、建立完（略）的基础数据维护体系，实现对（略）体（略）运行所涉及的公共基础数据配置、管理与维护。3、实现对应用（略）及应用（略）运行的全方位管理和运行维护，包括但不限于：应用（略）管理、应用权限管理（及（略）色配置）、运行过程管理等。4、通过提供完善的应用管理和运行维护工具，实现对所有（略）、智能化（略）的集中管理和运行维（略）络任何地点接入即可实现对（略）个（略）的（略）管理和维护。3.医供体应用体系3.1患者主索引1、支持按照配置好的值域规则对患者数据进行清洗。2、支持通过姓名、证件号、出生日期、联系电话等字段对疑似患者进行搜索查询。3、操作人员可根据信息人工判断两条或多条患者信息为同一名患者时进行数据合并，同时确认保留的患者信息。4、操作人员可根据信息人工判断两条或多条患者信息不为同一名患者时解除疑似关系。5、可显示该条患者信息的数据来源。6、可通过姓名、证件号、出生日期、联系电话等字段对已合并患者进行搜索查询。7、可将已合并的患者信息进行拆（略），还原为合并前的状态。8、可记录患者历史轨迹。9、可界面化配置匹配算法字段，及字段权重。（略）、可界面化设置相同患者（略）数、疑似患者（略）数。（略）、可根据输入的患者基本信息检索是否有相同病例或疑似病例3.2（略）3.2.1MDM主数据管理1、可对医疗服务人员、医疗卫生机构（科室）、医疗卫生术语和字典提供注册管理服务。2、主数据需记录修改历史和各版本信息。3、标准字典可通过下发通知各业务子（略）进行关联匹配，下发格式需为xml。3.2.2集成引擎（ESB）1、内嵌支持国际标准和中国医疗数据标准HL7（HealthLevelSeven）v2.x、v3.0、FHIR等版本和DICOM标准。2、具备Socket、WebService、JMSMQ、FTP协议连接能力，以及与其他协议相互的转换能力。3、支持MinimalLowerLayerProtocolMLLP传输协议，连接各类医疗设备。4、具备Database的连接能力,同时支持JDBC和ODBC连接方式，以及Socket协议和WebService的相互转换能力。5、具备（略）ML格式、管道消息的格式转换能力。可以实现不同协议的动态路由，且路由规则通过配置方式实现。6、能够通过请求的数据内容的关键值进行主题发布，编写Java程序通过JMSSubscriber来订阅不同主题的消息。7、内置消息中间件引擎，可确保消息不丢失。在服务超时方面具备配置能力和易用性。在服务的注册和查找方面具备配置能力和易用性。8、报警的功能支持，（略）的（略）合能力。监控（略）提供报警与监控指标数据，服务报警信息、监控指标可以支持JMS消息和EMAIL等任意手段，服务监控信息可以（略）。9（略）能够记录服务交互的输入、输出数据报文信息，支持记录开关配置功能。（略）、在认证授权功能方面的表现情况，ESB总线的安全性能力，可以对外来访问WebService（略）进行用户认证和访问权限的控制。（略）、具备IP访问控制能力，体现ESB总线的安全性能力。（略）、支持HTTPS，体现ESB总线的安全性能力。支持SOAPoverHTTPS，体现ESB总线的安全性能力。（略）、支持（略）位、（略）位（略）。可通过数据建模定制符合自己需求的消息类型。（略）、支持多种服务质量等级和通信模式：同步和异步两种通信模式，请求响应、队列、点到点以及发布订阅模式，各种交付保证，集群支持、HA和故障隔离，各种保障和交易策略等。（略）、支持对关键服务属性进行查询，如：服务名称服务代码统计时间调用次数调用异常次数调用异常率调用告警次数调用告警率服务异常次数服务告警次数。3.2.3（略）DS注册和资源库1、严格遵循IHEITI-（略）DS（略）DS-I等相关标准。建立电子病历文档库，遵循国家卫计委《电子病历共享文档规范》，至少包含标准要求的（略）类共享文档；并支持自定义扩展。2、支持非结构化数据的***、word等。3.2.4统一身份认证及授权1、通过统一（略）门户实现各业务（略）的单点（略）。2、实现用户、权限的统一管理，包括用户的统一注册、权限统一（略）配及下发。3、实现对用户所有（略）认证操作及授权访问行为的全面记录和监控，确保所有操作处于可控和可审计状态。3.3（略）及（略）接口1、严格遵循国家《城乡居民健康档案基本数据集》及《电子病历基本数据集》相关标准构建。2、包含共享基础信息库、原始业务信息库、交换信息库、操作数据存储以及数据仓库。3、建立医共体（略）CDR及（略）数据接口（略）数据采集；LIS数据采集；PACS；体（略）HIS、LIS、PACS（略）中收集居民健康档案数据。包括但不限于门诊诊疗记录、住院诊疗记录、住院病案记录、检验、检查等数据。接口如下（略）、病人接口说明2、病人诊断数据接口说明3、门诊诊疗数据接口说明4、门诊费用明细接口5、门诊用药记录接口6、转科接口7、住院诊疗数据接口8、住院费用明细接口9、住院用药记录接口（略）、住院长期医嘱接口（略）、住院临时医嘱接口（略）、住院病案首页接口（略）、住院病案首页出院诊断（略）、住院病案首页手术记录接口（略）、住院病案首页过敏源接口（略）、实验室检验报告接口（略）、实验室检验报告子项接口（略）、影像检查报告接口（略）、病历信息接口（略）、病历内容接口（略）、生命体征接口（略）、长期医嘱接口（略）、临时医嘱接口（略）、有效长期医嘱接口（略）、体检者档案接口（略）、体检数据接口（略）、检验项目接口（略）、检验项目子项接口（略）、科室检查接口（略）、科室会诊接口（略）、总检接口实时采集程序接口：实时采集HIS、LIS、PAC（略）、电子病例（略）接入集成的数据库（略）包括以下各表（略）