漳浦县中医院综合诊治能力提升项目-集成平台建设项目标前更正公告
发送至邮箱
漳浦县中医院综合诊治能力提升项目-集成平台建设项目标前更正公告
一、项目基本情况
原公告的采购项目编号：[*]FJCY[GK]*
原公告的采购项目名 称： (略) 综合诊治能力提升项目- (略) 建设项目
首次公告日期：2022年9月9日
二、更正信息
合同包1
更正事项：采购文件的技术和服务要求
更正原因：修改技术和服务要求
更正内容：
(略) 在院区信息化建设过程中上线了各种技术架构、各种应用领域的专业信息化软件， (略) 医疗业务的发展提供了强有力的信息化支撑。
但由于在国内信息化建设初期发展阶段，各类信息系统缺乏统一的标准及技术互联互通标准化架构， (略) 也逐渐暴露出了架构复杂、系统相对独立、数据标准不统一，系统运行风险高 (略) 数据进行有效的统一管理与利用。
医院现需要通过引进一套集实用性、易用性、安全性、可靠性、开放性、可扩展性、标准化 (略) (略) ， (略) 构建具有国际先进管理理念，符合国内医疗未来发展方向的综合管理体系， (略) 现有各临床系统的历史业务结果数据以及实时性业务交互数 (略) 中，同时实现各业务 (略) (略) 的互联互通，消灭各系统间原先存在的接口， (略) 各业务系统从原来的到所需业务系统中获得数据到现 (略) (略) 上获得数据。并在此基础上， (略) 所有数据进行重新的解构和处理，实现基于医疗大数据的挖掘和分析目标。 (略) 和标准协议基础上， (略) 现有系统环境统 (略) 上， (略) 、统一体系 (略) 。
★为保证项目工程的顺利实施，投标人必须进行客户现场勘察， (略) 现有信息系统现状，各种可预见问题投标人均应考虑到，对于系统对接等各类原因造成费用增加时，各投标人应综合考虑在投标报价内，今后在服务时存在此原因造价不再调整中标价格。现场勘察完毕，采购人将出具已勘察过的潜在投标人的勘察证明，并在勘察证明原件上盖章确认该投标人已勘察过现场，经确认的勘察证明应附在投标人的投标文件中，否则按无效投标处理。
§2项目建设清单
序号 | 产品名 称 | 子模块名 称 | 描述 |
1 | (略) | 消息流处理引擎 | (略) 开发；开发工具部署； (略) 配置； (略) 部署；数据存储以及日志审计 |
HL7标准引擎 | 协议标准定义；标准集成配置以及数据转换 | ||
主索引管理系统 | 包含匹配条件配置；索引信息查看；疑似记录查看以及主索引日志 | ||
(略) | 包含服务器监控；总线监控；服务监控； (略) 由状态监控；系统告警；通讯日志；异常日志；日志重发；日志归档；组件注册；服务注册以及事件注册 | ||
(略) | 包含用户登录；消息转发；身份认证；密码管理以及用户管理 | ||
(略) 基础件 | 包含数据总线和消息中间件 | ||
2 | CDR数据中心 | 患者360视图 | 包含门诊时间轴;住院时间轴;门诊量;住院量;历次诊断;生命体征;出量入量;长嘱信息;短嘱信息;手术量;出入径状况;检查信息;药品信息;报告对比以及趋势分析等内容 |
主数据管理系统 | 包含术语注册；基础洗点；术语管理以及字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | ||
数据集和共享文档管理系统 | 提供可视化工具对数据标准进行管理，包括标准数据元管理、数据元值域管理、标准数据集管理、共享文档模板管理 | ||
对外统一数据服务 | 包含数据接口；数据视图；权限认证以及视图设 计 | ||
3 | 接口改造 | 接口改造 | 与第三方基础业务系统改造 |
系统 | 子模块 | 功能模块 |
(略) | 消息流处理引擎 | (略) |
(略) | ||
(略) | ||
(略) | ||
数据存储 | ||
日志审计 | ||
HL7标准引擎 | 协议标准定义 | |
数据转换 | ||
标准集成配置 | ||
主索引管理系统 | 匹配条件配置 | |
索引信息查看 | ||
疑似记录查看 | ||
主索引日志 | ||
(略) | 服务器监控 | |
总线监控 | ||
服务监控 | ||
(略) 由状态监控 | ||
系统告警 | ||
通讯日志 | ||
异常日志 | ||
日志重发 | ||
日志归档 | ||
组件注册 | ||
事件注册 | ||
(略) | 用户登录 | |
消息转发 | ||
身份认证 | ||
密码管理 | ||
用户管理 | ||
(略) 基础件 | 数据总线 | |
消息中间件 | ||
数据治理 | 数据治理 | |
(略) | (略) | |
CDR数据中心 | 患者360视图 | 门诊时间轴 |
住院时间轴 | ||
门诊量 | ||
住院量 | ||
历次诊断 | ||
生命体征 | ||
出量入量 | ||
长嘱信息 | ||
短嘱信息 | ||
手术量 | ||
出入径状况 | ||
检查信息 | ||
药品信息 | ||
报告对比 | ||
趋势分析 | ||
主数据管理系统 | 术语注册 | |
基础洗点 | ||
术语管理 | ||
字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | |
数据集和共享文档管理系统 | 标准数据元管理 | |
数据元值域管理 | ||
标准数据集管理 | ||
共享文档模板管 | ||
可视化标准工具管理 | ||
对外统一数据服务 | 数据接口 | |
数据视图 | ||
权限认证 | ||
视图设 计 | ||
业务总线 | HIS信息交换组件 | |
电子病历信息交换组件 | ||
检验（LIS）信息交换组件 | ||
放射信息交换组件 | ||
心电信息交换组件 | ||
超声信息交换组件 | ||
院感信息交换组件 | ||
体检信息交换组件 | ||
微信公众号服务组件 | ||
(略) 业务交换组件 | ||
绩效、财务业务交换组件 | ||
(略) 信息交换组件 | ||
诊间结算信息交换组件 | ||
床旁结算信息交换组件 | ||
物资供应链业务交换组件 | ||
手麻信息交换组件 | ||
输血信息交换组件 | ||
合理用药信息交换组件 | ||
医保服务组件 | ||
知识库交换组件 | ||
闭环业务交换组件 | ||
(略) 交换组件 | ||
接口接入 | (略) | HIS系统改造 |
电子病历系统改造 | ||
OA改造 | ||
院感系统改造 | ||
检验系统改造 | ||
检查类系统 | ||
心电系统 | ||
绩效、财务系统改造 | ||
物资供应链改造 | ||
手术麻醉管理系统改造 | ||
合理用药系统改造 | ||
输血管理系统改造 | ||
财务、预算管理系统改造 | ||
体检系统改造 | ||
物资、固定资产等系统改造 | ||
(略) 改造 | ||
多点结算改造 |
序号 | 产品名 称 | 子模块名 称 | 描述 |
1 | (略) | 消息流处理引擎 | (略) 开发；开发工具部署； (略) 配置； (略) 部署；数据存储以及日志审计 |
HL7标准引擎 | 协议标准定义；标准集成配置以及数据转换 | ||
主索引管理系统 | 包含匹配条件配置；索引信息查看；疑似记录查看以及主索引日志 | ||
(略) | 包含服务器监控；总线监控；服务监控； (略) 由状态监控；系统告警；通讯日志；异常日志；日志重发；日志归档；组件注册；服务注册以及事件注册 | ||
(略) | 包含用户登录；消息转发；身份认证；密码管理以及用户管理 | ||
(略) 基础件 | 包含数据总线和消息中间件 | ||
2 | CDR数据中心 | 患者360视图 | 包含门诊时间轴;住院时间轴;门诊量;住院量;历次诊断;生命体征;出量入量;长嘱信息;短嘱信息;手术量;出入径状况;检查信息;药品信息;报告对比以及趋势分析等内容 |
主数据管理系统 | 包含术语注册；基础洗点；术语管理以及字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | ||
数据集和共享文档管理系统 | 提供可视化工具对数据标准进行管理，包括标准数据元管理、数据元值域管理、标准数据集管理、共享文档模板管理 | ||
对外统一数据服务 | 包含数据接口；数据视图；权限认证以及视图设 计 | ||
3 | 接口改造 | 接口改造 | 与第三方基础业务系统改造 |
通 (略) 化的分层架构，应实现包括业务系统(如HIS、EMR、LIS、PACS、移动护理、移动查房、手术麻醉系统、重症监护系统、预约管理系统、自助服务管理系统)与管理系统的分层等。将不同的业务系统依据访问频度、性能要求、实时性要求、数据粒度等的要求进行架构分层。
（1）数 (略) 信息管理系统（HIS）系统交互要求：应能通过数据总线自动获取HIS相关基本信息、医嘱信息等，为其他信息系统的信息交互提供所需的数据。
（2）数据总线与检验信息管理系统信息（LIS）交互要求： (略) 获取检验单据信息、 (略) 信息、病历信息，记录完整的检验单据处理过程，标本送检过程处理与单据费用自动处理，检验报告结构化存储，实现多系统统一的报告调阅接口；
（3）数据总线与医学影像传输与管理系统信息(PACS)交互要求：应能实现放射检查、超声检查、内镜检查、病理检查、心电检查等 (略) 获取检查单据信息、 (略) 信息、病历信息，记录完整的检验单据处理过程，检查图文报告结构化存储，实现多系统统一的报告调阅接口；并需支持统一影像浏览及处理。
（4）数据总线与电子病历系统(EMR)信息一体化交互要求：实现完善以电子病历为中心的临床信息系统，提供电子病历分级评价标准所需的支持。
（5）数据总线与移动护理、移动查房交互要求： (略) 获取患者基本信息、检验报告、检查报告、手术麻醉信息、重症监护信息等。
（6）数据总线与健康体检信息管理系统（PEIS）交互要求：应能通过数据总线自动获取患者基本信息，并能实现检验信息管理系统（LIS）与医学影像传输与管理系统信息(PACS)等系统的信息交互。
（7）数据总线与手术麻醉、重症监护系统的交互要求：应能通过数据总线快速地获取患者基本信息和医嘱信息，手术麻醉记录和重症监护记录完后可以通过数据总线为临床其他系统进行调阅。
（8）数据总线与预约管理系统的交互：通过数据总线可以快速的获取患者预约挂号信息，预约管理系统可以通过数据总线与各个业务系统进行预约与排队信息的管理，完成就诊预约、检查预约、取消预约等功能。
（9）建立多途径的消息机制，实现各系统间关键医疗信息自动提醒（如急诊异常报告）、预警功能。
§3.1 服务总线组件
§3.1.1消息模型管理
(略) 运行服务相应的具体报文内容的消息模型进行新增修订发布等管理功能。
§3.1.2 接入系统服务管理
(略) 的相关系统提供的服务接口进行配置管理，包括服务地址，协议类型。调用方法等内容。
§3.1.3 (略) 由管理
(略) 所需支持的业务消息事件进行登记修改等功能，通过简单的界面拖拉组件操作进行业务场景的编排配置。
§3.1.4总线入口服务
平台应提供统一调用总线的服务入口， (略) (略) 服务场景的请求调用跟返回消息的标准化。
▲消息流处理引擎应集成不同的卫生系统，提供安全连接，提供可靠的消息传递和高性能，应基于图形化的开发， (略) 具体情况，添加修改消息接收节点。 (略) 针对一些无法提供技术改造的厂商提供数据接入支持。（提供投标人或软件原厂商消息流引擎系统软件著作权证书）
医疗组织在管理医疗数据集成需要的大量标准。要求本项目集成引擎的标准医疗通讯协议资料能够完整齐全，并能够需支持相关医疗标准的不断更新，为平台提供标准支持。
要求集成引擎嵌入协议标准（TCP、FTP、HTTP、网络服务等等）；
▲需支持HL7(从版本2.x到3)，同时需支持临床文档架构（CDA）和连续医护文档（CCD）；（提供投标人或软 (略) (略) 医疗链接包产品著作权证书）
需支持DICOM图像格式转换机应用；
需支持医用信息系统集成（IHE）配置文件。
▲信息集成适配系统：对于非HL7传递标准的系统， (略) 应具备集成适配器转换能力，能将非标系统通过适配器系统转换成基于HL (略) 中。（提供投标人或软 (略) 信息集成适配系统产品著作权证书）
消息中间件应采用消息队列技术，通过消息队列，应用程序可独立地执行，而不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收消息。
平台应能通过使用消息中间件实现系统之间数据的快速交换、查询、调阅等功能。
平台同时应能提供消息中间件的配置管理功能：包括部署授权管理、 (略) 由、开发集成环境。
平台的主索引管理系统应能提供两种匹配模式：在线精确匹配与离线模糊匹配。两种匹配模式相辅相成，共同组成主索引服务。
▲支持在病人登记场景发生时，系统能够自动捕获该场景的病人基本信息，调用主索引服务。主索引系统执行在线精确匹配，根据精确匹配结果快速匹配相似的病人记录，在线精确匹配结果需控制在500毫秒内。如果在精确匹配没有匹配结果的情况下，系统应将该病人信息自动转为离线模糊匹配，根据模糊匹配条件生成疑似匹配结果，然后由人工对其进行确认。（提供投标人或软件原厂商患者主索引系统产品著作权证书）
通过管理系统与信息集成引擎的对接， (略) 需支持的组件、服务、事件及数据交换规则进行定义和配置。
需具备完善的用户管理功能，包括用户、组的维护，针对不同用户进行权限管理。
组件 (略) 的组件进行登记，只有注册过的组件 (略) 所接受。
支持对已注册的系统，进行服务登记，这里所指服务是指系统对外需提供的服务。
(略) 所需支持的消息事件进行登记。
应实现针对不同系统所需要的消息进行过滤。
日志监控系统用来跟踪和记录通信历史信息，为后续性能分析、问题分析提供必要数据基础。
支持用户通过时间，通信系统，通信内容，消息类型等作为检索条件查询相应的通信日志。
应提供异常日志，当消息流发生异常时产生错误日志，记录在异常日志表中，主要用来分析错误原因。
当消息传 (略) 络异常中断，产生的异常日志，可通过日志重发功能重新发送传输异常的消息。
采用归档的形式将日志信息转储到另外的日志归档表中，保证日志表数据条数控制在一定数量级内，方便快速查找。日志归档需支持每日自动归档和手动归档两种方式。
(略) 运行服务相应的具体报文内容的消息模型进行新增修订发布等管理功能。
(略) 的相关系统提供的服务接口进行配置管理，包括服务地址，协议类型。调用方法等内容。
(略) 所需支持的业务消息事件进行登记修改等功能，通过简单的界面拖拉组件操作进行业务场景的编排配置。
平台应提供统一调用总线的服务入口， (略) (略) 服务场景的请求调用跟返回消息的标准化。
医疗组织在管理医疗数据集成需要的大量标准。要求本项目集成引擎的标准医疗通讯协议资料能够完整齐全，并能够需支持相关医疗标准的不断更新，为平台提供标准支持。
要求集成引擎嵌入协议标准（TCP、FTP、HTTP、网络服务等等）；
需支持DICOM图像格式转换机应用；
需支持医用信息系统集成（IHE）配置文件。
消息中间件应采用消息队列技术，通过消息队列，应用程序可独立地执行，而不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收消息。
平台应能通过使用消息中间件实现系统之间数据的快速交换、查询、调阅等功能。
平台同时应能提供消息中间件的配置管理功能：包括部署授权管理、 (略) 由、开发集成环境。
通过管理系统与信息集成引擎的对接， (略) 需支持的组件、服务、事件及数据交换规则进行定义和配置。
需具备完善的用户管理功能，包括用户、组的维护，针对不同用户进行权限管理。
(略) 管控端登录及连接事件的活动日志的记录查看功能。
支持对通过简单 (略) 管控界面挂载的系统菜单显示进行配置的功能。
具备针对新接入系统或者接口服务的在线联调测试的功能。
(略) 服务资源目录及功能说明的在线查看功能。
日志监控系统用来跟踪和记录通信历史信息，为后续性能分析、问题分析提供必要数据基础。
支持用户通过时间，通信系统，通信内容，消息类型等作为检索条件查询相应的通信日志。
应提供异常日志，当消息流发生异常时产生错误日志，记录在异常日志表中，主要用来分析错误原因。
当消息传 (略) 络异常中断，产生的异常日志，可通过日志重发功能重新发送传输异常的消息。
采用归档的形式将日志信息转储到另外的日志归档表中，保证日志表数据条数控制在一定数量级内，方便快速查找。日志归档需支持每日自动归档和手动归档两种方式。
管理员应可以从监 (略) 运行状态、接口状态、诊断信息、性能图表、交互消息量等。 (略) 都 (略) 络浏览器方便访问同时可作出简便设置并 (略) 由情况。 (略) 的功能主要包括：平台服务器监控、性能监控、服务监控、日志监控、用户告警等。
▲ (略) 的物理服务器性能的监控，包含所有在用或备用服务器的CPU使用率、内存使用率、网络流量、硬盘吞吐量等关键指标。（提供投标人 (略) 产品著作权证书）
支持通过设 计系统名 称的故障服务服务数/系统所有注册服务数直观展示给管理人员，说明总线当前运行的情况。
场景监控是指对企业服务总线软件的运行状况的监控，包含所有在用或备用服务的可用性、当日接收调用次数、当日发送消息次数，当日错误发生次数等关键指标。
支持实时监控ESB总线各系统组件的运行状态，如发现故障可以及时排除故障。
实现对当日消息量和数据库消息表空间使用率的监控。其中消息量监控包含业务流消息，字典服务消息的正常数量、异常数量和等待数量的监测。
(略) 监控指标大屏展示功能， (略) 关注的服务器、总线、数据库等相 (略) 管理人员进行直观展示。
平台 (略) 运行状况的统计日报汇总，指标包括服务交换情况，异常情况，数据库表空间情况等。
平台告警规则配置功能可以对每个交互事件场景的告警条件进行配置，比如异常数达到多少，最大值超过多少等条件满足的情况下将进行告警提醒；
平台针对告警信息通知推送进行配置，配置内容包括推送目标人员的相关信息（联系方式，人员等级等）以及通知推送规则，推送方式等信息
(略) 或者微信公众号等消息通知推送渠道的情况下，平台可以提供告警信息通知接口适配对接的功能，根据现场实际情况对接短信、微信公众号等消息通知接口。.
(略) 告警事件的日志留存及时候查看功能。 (略) 管理人员针对告警信息进行问题分析及处理。
平台的主索引管理系统应能提供两种匹配模式：在线精确匹配与离线模糊匹配。两种匹配模式相辅相成，共同组成主索引服务。
通过统一门户认证，用户不再需要每次输入用户名 称和用户密码，也不需要牢记多套不同供 应 商的系统用户名 称和用户密码，从而改善用户使用应用系统的体验。
通 (略) 化的分层架构，平台 (略) 临床业务流程具备内置以下接入集成业务专题。将不同的临床业务依据访问频度、性能要求、实时性要求、数据粒度,涉及的临床业务系统等的要求进行架构分层。
根据 (略) 集成专题包接入包括：
（1）患者标识域(患者信息、建卡建档相关的服务)
（2）门诊就诊域(门诊挂号诊断等就诊相关服务)
（3）住院就诊域(住院入、出、转相关服务)
（4）检查业务场景集成（检查申请单业务相关服务）
（5）检验业务场景集成（检验申请单业务相关服务）
（6）手术业务场景集成(手术申请相关业务服务)
（7）用血业务场景集成(输血申请单业务相关服务)
（8）医嘱用药业务场景集成(医嘱状态交互)
（9）基础字典集成域
§4、临床数据中心需提供多种类型的采集手段，以满足数据采集现状的要求。需支持主流关系型数据库，如Oracle、SqlServer、Mysql等。根据数据需求的实时性及业务系统的可操作性（如是否能开放日志捕获等），同时支持实时采集、定时采集两种主要技术模式。
实时采集总线，应基于日志的结构化数据复制机制，通过捕获数据库日志，处理、转化并实时入库。自动识别数据库结构变更，当出现表结构发生变动时，需要能够自动捕获、生成对应语句并自动执行，实现全自动实时静默同步，无需人工干预。除支持单表数据实时入库外，应支持转化数据以准实时（非定时任务）方式入库。
定时采集总线，应基于ETL机制，能够支持多种数据格式（如表、视图等），同时支持在线配置清洗转化逻辑。通过定时增量任务配置，实现定时采集转化。
基于ETL定时采集总线，具体需实现以下功能：
1、支持ETL作业生成
支持用户通过编写ETL程序，并将程序生成批量运行的作业，并允许对作业进行调度管理。
2、支持拖拽方式可视化创建ETL过程
提供易于操控的可视化作业生成界面，降低编写程序的难度，使用拖拽的方式，迅速编写好ETL数据转换作业，并且能看到作业过程。
3、支持对不同数据源进行转换操作
允许用户通过下拉列表对不同数据源，转换方式，目标输出地进行选择。
4、支持同时对数据源进行多次操作
支持用户对同一数据源进行多次不同类型的数据转换操作。
5、支持对数据源的多次操作进行自定义排序
支持用户对数据操作类型进行排序。
6、支持关系型数据库输出
7、支持用户输出数据转换结果到关系型数据库，允许用户配置，表名字，每次处理的记录数量，以及对于存在唯一主键或者索引的记录处理方式(更新同一主键的其他字段或者直接替换)。
8、支持拖拽方式配置ETL作业的时候动态生成数据抽样
支持用在在进行拖拽方式配置数据ETL转换作业时候，动态生成数据抽样结果，可以点击点击转换对数据转换过程进行实时查看，也可以编辑数据对样本数据进行修改。
9、同时支持C/S端及WEB端配置ETL逻辑。
10、支持用户设置数据ETL作业自定义变量
允许用户设置自定义变量，使用变量替换区配置多个调度任务，每个调度任务里的参数可以不同。
11、支持用户自定义作业调度周期
允许用户填写作业实际的调度策略，可以按小时，天，或者周等等。
12、支持用户自定义作业运行时间
允许用户定义数据开始的时间，作业结束时间。
13、支持ETL作业调度与管理
支持数据ETL转换作业调度与管理提供列表式管理界面，让用户创建的转换作业进行全局查看，提供作业状态、队列数、启始时间，等等进行统筹管理。
数据质量校验包括数据采集、数据加载、数据分发等过程中数据校验。在数据采集过程中通过对数据源与目标数据库之间的数据进行对比分析，从而进一步来分析、发现与解决在数据抽取过程可能产生的异常错误信息，同时完成数据缺失的修复。
数据接入校验需具备将分散的、异构数据源中的数据如关系数据、非关系数据、数据文件等抽取到临时中间层后进行解析、转换、校验、过滤、清洗、反馈。
数据校验规则要求：数据校验需求可以满足不同的系统使用者从不同的角度对数据进行分析。校验规则主要包括数据完整性、准确性、一致性三方面的规则。
数据校验任务要求：定时的执行数据校验规则，满足对不同规则的执行方式进行设置，配置任务的触发时间和执行时间。
数据转换要求：不同业务系统之间、业务系统与共享数据库保存的数据格式和语义可能都不一致，他们之间交换的数据需 (略) 提供统一的可识别、可处理的数据。此外，通过数据转换，可以方便地对海量数据进行编目及目录转换。
完整性控制要求：MD5 或者HASH 校验通过对接收的传输数据执行散列运算来检查数据的正确性。计算出的散列值和随数据传输的散列值比较。如果两个值相同，说明传输的数据完整无误、没有被篡改过（前提是散列值没有被篡改），从而可以放心使用。
数据过滤要求：支持对指 定数据源数据的字段清洗，通过配置对指 定数据源进行字段级别的清洗过滤；支持编码格式转换、特殊字符的处理；支持可配置的数据过滤框架，业务可以根据需要注册数据过滤程序。
校验结果展示要求：对采集结果进行校验后产生的结果数据，将结果数据推送到服务配置端以供相关人员进行查看和分析。
错误数据反馈要求：针对残缺数据、错误数据和重复数据支持即时反馈的功能，促使数据提供单位尽快地修正错误，同时也可以做为将来验证数据的依据。
系统需采用关系型数据库保存，并遵循第三范式设 计存储，对于非结构化的、文档中的内容数据，系统应采用文件存储或非关系型的存储系统存储。
数据从来源到目标的采集过程当中，需实时的对当前采集的进度进行监控。
监控内容需包括：进程状态、网络状态、连接情况、应用状态、异常状态等。对采集端的监测，包括是否正常运行、在线离线的监测以及异常的环境汇总。
提供数据接口所有任务的运行监控功能、异常日志分析工具、异常任务处理和恢复功能：
需提供针对任务点的异常恢复，当运行的任务执行失败时，可以重新运行任务（流程启动）、从故障点运行任务（任务启动）。
需支持对不符合接口规范的异常数据进行标记的功能，并将异常数据输出到指 定目录、提供数据质量统计分析报告（数据源、时间、成功记录、失败记录（各种失败类型分类记录）等。
需提供可视化的任务运行日志管理功能，包括运行的日志详细信息（成功、异常）。
支持对所有系统运行日志、操作日志、业务日志、异常日志进行保存，并提供相应的可视化查询和操作功能：
需支持对系统运行详细资源、状态、运行日志的可视化监控和维护，包括软件状态、数据传输、数据稽查等；
需支持对系统操作日志的记录，包括时间、人员、操作模块、操作类型、操作前参数、操作后参数等；
需支持基于异常日志重发机制。
▲需支持对业务运行日志的采集和汇总，基于Web 框架，支持查询日志，并将采集日志进行归档汇总。(提供投标人或软 (略) 统计信息管理系统软件著作权证书)
支持通过集成视图方式进行数据展现,能实现病人诊疗信息的统一展现，横向以时间轴的方式显示病人的体征、医嘱等信息，纵向以诊疗事件顺序来显示相关诊病信息，如检验、检查报告、手术记录等信息，还应包括检验报告的趋势分析、历史报告对比分析等功能。
系统需通过多种维度的数据组织方式，进一步挖掘数据价值，为临床科室人员提供有效数据支持。
就诊视图：支持以就诊主线组织数据，展现每一次患者对应的就诊数据，包含诊断记录，文书，体格体征，医嘱，检查检验报告等信息。
临床视图：支持以临床业务类型为主线组织数据，展现患者特定诊断类型的历史数据，如检查报告（历史指标比对），历史开药记录等。
支持整合患者主索引（EMPI），能够将多种注册渠道的患者，通过特定的规则，统一展现在患者360视图中，实现相关数据的汇聚展示。
▲支持针对患者的每一次就诊记录，均有对应的共享文档记录。患者360视图将二者进行关联结合，满足国家后续关于就诊数据共享交换的长期需求。（提供投标人或软件原厂商医疗信息共享文档库系统产品著作权证书）
支 (略) 内闭环系统（含药品闭环、手术闭环、检查闭环、检验闭环、会诊闭环、危急值闭环等），能够直观的从就诊记录中查看业务中闭环相关数据。
应能够实现快速逻辑配置，无需重启服务， (略) 系统快速上线、快业务逻辑迭代的需求。
1.文档管理：应实现文档生成模板、生成逻辑、展示界面进行在线配置，实现共享文档的生成、批量生成和下载。
2.模型与抽取：应实现共享文档主题库的抽取模型在线配置，实现共享文档基础数据实时抽取、转化。通过配置计划、任务，实现基础数据定时转化。
3.文档校验：应能够基于共享文档数据集中数据元对应的校验规则（如是否必填、数值型、布尔型），对已生成的共享文档进行数据批量校验，形成分析报表。
4.系统配置：应实现文档类型、视图类型、关联关系，每篇文档基础数据集及规则、脱敏规则等配置。
5.数据统计：支持对已生成的文档实现图表分析。同时允许配置多个数据源，比对原始数据和目标数据的数量，用于分析目标文档生成总量是否符合预期。
应包括标准数据元管理、数据元值域管理、标准数据集管理。其中针对数据元管理可以进行增加、修改和删除等操作。
▲根据数据标准的修订，及时更新系统中数据标准信息。其中数据标准管理需包括对数据元、值域、数据集等管理。（提供投标人或软件原厂商数据仓库系统产品著作权证书）
▲需提供可视化操作功能，配置文档生成逻辑，生成对应共享文档。生成逻辑与生成模板均可在线配置，即改即生效，便于现场实施人员快速、灵活完成共享文档生成。(提供投标人或软件原厂商医 (略) 软件著作权证书)
共享文档的基础数据，需支持定时任务完成数据的自动抽取、转化与清洗，也支持手动按照视图/文档机制实时完成数据抽取。系统需支持从线下C/S客户端构建转化模型后上传系统，也需支持直接在系统中创建转化模型。
应实现对文档的组成字段、字段规则（是否必填、是否满足某种条件等）进行校验。校验可以单篇文档校验，也可以建立校验组，实现批量校验。通过扫描数据质量，可大范围挖掘目前共享文档距离国家标准的差距，同时可以定位具体存在的字段的源头。
支持对术语字典的名 称进行登记，只有注册过的术语才会被纳入主数据管理范围。根据卫生部数据标准规划，注册内容应包含，术语字典名 称，编码，版本，标准来源，标准更新日期。
通过主数据管理 (略) 基础数据集中管理，实现主数据整合、共享和监管功能。基础字典实现基于国家、卫生局等标准字典的维护。
(略) 内各系统中非标字典的维护和管理。
(略) 内字典之间，存在映射关系。为了统一语义，实现标准化，提供 (略) 内字典的映射维护及管理。
§5、现有系统接入▲ (略) 前期投资，优化现有就诊流程，实现数据无缝连接，需要在现有信息化软件系统的基础上， (略) 信息 (略) 的对接改造，实现数据共享、标准定义、统一用户管理、用户统一系统入口等功能。（提供投标人或软 (略) 信息单点登录系统著作权证书）
应基于以下原则建设：
1、简单， (略) 维护及查找故障；
2、易于修改，避免双方大规模修改程序或业务流程；
3、行业通用的，或国际标准的；
4、投标人应提供对接标准，由第三方业务系统提供数据，自行写入其业务系统数据库，投标人不操作对方数据库；
5、尽可能的减少工作人员操作的步骤，尽可能从后台实现。
★投标人应书面承诺，投标人 (略) (略) 能与招标方现有的HIS系统、检验系统、电子病历系统等实现数据无缝连接与互联互通，所有业务数据均能够相互调阅实现流程的一体化应用，若需要第三方协助以接口方式实现的，则所有接口开发费用必须包含在本次投标报价中，招标方无需另行支付。
更正日期：2022年9月28日
三、其他补充事宜
四、凡对本次公告内容提出询问，请按以下方式联系
1.采购人信息
名 称： (略)
地 址：漳浦县绥安 (略) 19号
联系方式：0596-*
2.采购代 理机构信息（如有）
名 称：福建 (略)
地 址： (略) 龙文 (略) 22号明发商业广场1幢2407室-2414室
联系方式：*
3.项目联系方式
项目联系人：余先生
电 话：0596-*
福建 (略)
发布日期：2022年9月28日
一、项目基本情况
原公告的采购项目编号：[*]FJCY[GK]*
原公告的采购项目名 称： (略) 综合诊治能力提升项目- (略) 建设项目
首次公告日期：2022年9月9日
二、更正信息
合同包1
更正事项：采购文件的技术和服务要求
更正原因：修改技术和服务要求
更正内容：
(略) 在院区信息化建设过程中上线了各种技术架构、各种应用领域的专业信息化软件， (略) 医疗业务的发展提供了强有力的信息化支撑。
但由于在国内信息化建设初期发展阶段，各类信息系统缺乏统一的标准及技术互联互通标准化架构， (略) 也逐渐暴露出了架构复杂、系统相对独立、数据标准不统一，系统运行风险高 (略) 数据进行有效的统一管理与利用。
医院现需要通过引进一套集实用性、易用性、安全性、可靠性、开放性、可扩展性、标准化 (略) (略) ， (略) 构建具有国际先进管理理念，符合国内医疗未来发展方向的综合管理体系， (略) 现有各临床系统的历史业务结果数据以及实时性业务交互数 (略) 中，同时实现各业务 (略) (略) 的互联互通，消灭各系统间原先存在的接口， (略) 各业务系统从原来的到所需业务系统中获得数据到现 (略) (略) 上获得数据。并在此基础上， (略) 所有数据进行重新的解构和处理，实现基于医疗大数据的挖掘和分析目标。 (略) 和标准协议基础上， (略) 现有系统环境统 (略) 上， (略) 、统一体系 (略) 。
★为保证项目工程的顺利实施，投标人必须进行客户现场勘察， (略) 现有信息系统现状，各种可预见问题投标人均应考虑到，对于系统对接等各类原因造成费用增加时，各投标人应综合考虑在投标报价内，今后在服务时存在此原因造价不再调整中标价格。现场勘察完毕，采购人将出具已勘察过的潜在投标人的勘察证明，并在勘察证明原件上盖章确认该投标人已勘察过现场，经确认的勘察证明应附在投标人的投标文件中，否则按无效投标处理。
§2项目建设清单
序号 | 产品名 称 | 子模块名 称 | 描述 |
1 | (略) | 消息流处理引擎 | (略) 开发；开发工具部署； (略) 配置； (略) 部署；数据存储以及日志审计 |
HL7标准引擎 | 协议标准定义；标准集成配置以及数据转换 | ||
主索引管理系统 | 包含匹配条件配置；索引信息查看；疑似记录查看以及主索引日志 | ||
(略) | 包含服务器监控；总线监控；服务监控； (略) 由状态监控；系统告警；通讯日志；异常日志；日志重发；日志归档；组件注册；服务注册以及事件注册 | ||
(略) | 包含用户登录；消息转发；身份认证；密码管理以及用户管理 | ||
(略) 基础件 | 包含数据总线和消息中间件 | ||
2 | CDR数据中心 | 患者360视图 | 包含门诊时间轴;住院时间轴;门诊量;住院量;历次诊断;生命体征;出量入量;长嘱信息;短嘱信息;手术量;出入径状况;检查信息;药品信息;报告对比以及趋势分析等内容 |
主数据管理系统 | 包含术语注册；基础洗点；术语管理以及字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | ||
数据集和共享文档管理系统 | 提供可视化工具对数据标准进行管理，包括标准数据元管理、数据元值域管理、标准数据集管理、共享文档模板管理 | ||
对外统一数据服务 | 包含数据接口；数据视图；权限认证以及视图设 计 | ||
3 | 接口改造 | 接口改造 | 与第三方基础业务系统改造 |
系统 | 子模块 | 功能模块 |
(略) | 消息流处理引擎 | (略) |
(略) | ||
(略) | ||
(略) | ||
数据存储 | ||
日志审计 | ||
HL7标准引擎 | 协议标准定义 | |
数据转换 | ||
标准集成配置 | ||
主索引管理系统 | 匹配条件配置 | |
索引信息查看 | ||
疑似记录查看 | ||
主索引日志 | ||
(略) | 服务器监控 | |
总线监控 | ||
服务监控 | ||
(略) 由状态监控 | ||
系统告警 | ||
通讯日志 | ||
异常日志 | ||
日志重发 | ||
日志归档 | ||
组件注册 | ||
事件注册 | ||
(略) | 用户登录 | |
消息转发 | ||
身份认证 | ||
密码管理 | ||
用户管理 | ||
(略) 基础件 | 数据总线 | |
消息中间件 | ||
数据治理 | 数据治理 | |
(略) | (略) | |
CDR数据中心 | 患者360视图 | 门诊时间轴 |
住院时间轴 | ||
门诊量 | ||
住院量 | ||
历次诊断 | ||
生命体征 | ||
出量入量 | ||
长嘱信息 | ||
短嘱信息 | ||
手术量 | ||
出入径状况 | ||
检查信息 | ||
药品信息 | ||
报告对比 | ||
趋势分析 | ||
主数据管理系统 | 术语注册 | |
基础洗点 | ||
术语管理 | ||
字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | |
数据集和共享文档管理系统 | 标准数据元管理 | |
数据元值域管理 | ||
标准数据集管理 | ||
共享文档模板管 | ||
可视化标准工具管理 | ||
对外统一数据服务 | 数据接口 | |
数据视图 | ||
权限认证 | ||
视图设 计 | ||
业务总线 | HIS信息交换组件 | |
电子病历信息交换组件 | ||
检验（LIS）信息交换组件 | ||
放射信息交换组件 | ||
心电信息交换组件 | ||
超声信息交换组件 | ||
院感信息交换组件 | ||
体检信息交换组件 | ||
微信公众号服务组件 | ||
(略) 业务交换组件 | ||
绩效、财务业务交换组件 | ||
(略) 信息交换组件 | ||
诊间结算信息交换组件 | ||
床旁结算信息交换组件 | ||
物资供应链业务交换组件 | ||
手麻信息交换组件 | ||
输血信息交换组件 | ||
合理用药信息交换组件 | ||
医保服务组件 | ||
知识库交换组件 | ||
闭环业务交换组件 | ||
(略) 交换组件 | ||
接口接入 | (略) | HIS系统改造 |
电子病历系统改造 | ||
OA改造 | ||
院感系统改造 | ||
检验系统改造 | ||
检查类系统 | ||
心电系统 | ||
绩效、财务系统改造 | ||
物资供应链改造 | ||
手术麻醉管理系统改造 | ||
合理用药系统改造 | ||
输血管理系统改造 | ||
财务、预算管理系统改造 | ||
体检系统改造 | ||
物资、固定资产等系统改造 | ||
(略) 改造 | ||
多点结算改造 |
序号 | 产品名 称 | 子模块名 称 | 描述 |
1 | (略) | 消息流处理引擎 | (略) 开发；开发工具部署； (略) 配置； (略) 部署；数据存储以及日志审计 |
HL7标准引擎 | 协议标准定义；标准集成配置以及数据转换 | ||
主索引管理系统 | 包含匹配条件配置；索引信息查看；疑似记录查看以及主索引日志 | ||
(略) | 包含服务器监控；总线监控；服务监控； (略) 由状态监控；系统告警；通讯日志；异常日志；日志重发；日志归档；组件注册；服务注册以及事件注册 | ||
(略) | 包含用户登录；消息转发；身份认证；密码管理以及用户管理 | ||
(略) 基础件 | 包含数据总线和消息中间件 | ||
2 | CDR数据中心 | 患者360视图 | 包含门诊时间轴;住院时间轴;门诊量;住院量;历次诊断;生命体征;出量入量;长嘱信息;短嘱信息;手术量;出入径状况;检查信息;药品信息;报告对比以及趋势分析等内容 |
主数据管理系统 | 包含术语注册；基础洗点；术语管理以及字典同步引擎 | ||
ETL工具 | 提供图形化用户界面，可对数据抽取、转换、传输和转载，完成数据的标准化清洗 | ||
数据集和共享文档管理系统 | 提供可视化工具对数据标准进行管理，包括标准数据元管理、数据元值域管理、标准数据集管理、共享文档模板管理 | ||
对外统一数据服务 | 包含数据接口；数据视图；权限认证以及视图设 计 | ||
3 | 接口改造 | 接口改造 | 与第三方基础业务系统改造 |
通 (略) 化的分层架构，应实现包括业务系统(如HIS、EMR、LIS、PACS、移动护理、移动查房、手术麻醉系统、重症监护系统、预约管理系统、自助服务管理系统)与管理系统的分层等。将不同的业务系统依据访问频度、性能要求、实时性要求、数据粒度等的要求进行架构分层。
（1）数 (略) 信息管理系统（HIS）系统交互要求：应能通过数据总线自动获取HIS相关基本信息、医嘱信息等，为其他信息系统的信息交互提供所需的数据。
（2）数据总线与检验信息管理系统信息（LIS）交互要求： (略) 获取检验单据信息、 (略) 信息、病历信息，记录完整的检验单据处理过程，标本送检过程处理与单据费用自动处理，检验报告结构化存储，实现多系统统一的报告调阅接口；
（3）数据总线与医学影像传输与管理系统信息(PACS)交互要求：应能实现放射检查、超声检查、内镜检查、病理检查、心电检查等 (略) 获取检查单据信息、 (略) 信息、病历信息，记录完整的检验单据处理过程，检查图文报告结构化存储，实现多系统统一的报告调阅接口；并需支持统一影像浏览及处理。
（4）数据总线与电子病历系统(EMR)信息一体化交互要求：实现完善以电子病历为中心的临床信息系统，提供电子病历分级评价标准所需的支持。
（5）数据总线与移动护理、移动查房交互要求： (略) 获取患者基本信息、检验报告、检查报告、手术麻醉信息、重症监护信息等。
（6）数据总线与健康体检信息管理系统（PEIS）交互要求：应能通过数据总线自动获取患者基本信息，并能实现检验信息管理系统（LIS）与医学影像传输与管理系统信息(PACS)等系统的信息交互。
（7）数据总线与手术麻醉、重症监护系统的交互要求：应能通过数据总线快速地获取患者基本信息和医嘱信息，手术麻醉记录和重症监护记录完后可以通过数据总线为临床其他系统进行调阅。
（8）数据总线与预约管理系统的交互：通过数据总线可以快速的获取患者预约挂号信息，预约管理系统可以通过数据总线与各个业务系统进行预约与排队信息的管理，完成就诊预约、检查预约、取消预约等功能。
（9）建立多途径的消息机制，实现各系统间关键医疗信息自动提醒（如急诊异常报告）、预警功能。
§3.1 服务总线组件
§3.1.1消息模型管理
(略) 运行服务相应的具体报文内容的消息模型进行新增修订发布等管理功能。
§3.1.2 接入系统服务管理
(略) 的相关系统提供的服务接口进行配置管理，包括服务地址，协议类型。调用方法等内容。
§3.1.3 (略) 由管理
(略) 所需支持的业务消息事件进行登记修改等功能，通过简单的界面拖拉组件操作进行业务场景的编排配置。
§3.1.4总线入口服务
平台应提供统一调用总线的服务入口， (略) (略) 服务场景的请求调用跟返回消息的标准化。
▲消息流处理引擎应集成不同的卫生系统，提供安全连接，提供可靠的消息传递和高性能，应基于图形化的开发， (略) 具体情况，添加修改消息接收节点。 (略) 针对一些无法提供技术改造的厂商提供数据接入支持。（提供投标人或软件原厂商消息流引擎系统软件著作权证书）
医疗组织在管理医疗数据集成需要的大量标准。要求本项目集成引擎的标准医疗通讯协议资料能够完整齐全，并能够需支持相关医疗标准的不断更新，为平台提供标准支持。
要求集成引擎嵌入协议标准（TCP、FTP、HTTP、网络服务等等）；
▲需支持HL7(从版本2.x到3)，同时需支持临床文档架构（CDA）和连续医护文档（CCD）；（提供投标人或软 (略) (略) 医疗链接包产品著作权证书）
需支持DICOM图像格式转换机应用；
需支持医用信息系统集成（IHE）配置文件。
▲信息集成适配系统：对于非HL7传递标准的系统， (略) 应具备集成适配器转换能力，能将非标系统通过适配器系统转换成基于HL (略) 中。（提供投标人或软 (略) 信息集成适配系统产品著作权证书）
消息中间件应采用消息队列技术，通过消息队列，应用程序可独立地执行，而不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收消息。
平台应能通过使用消息中间件实现系统之间数据的快速交换、查询、调阅等功能。
平台同时应能提供消息中间件的配置管理功能：包括部署授权管理、 (略) 由、开发集成环境。
平台的主索引管理系统应能提供两种匹配模式：在线精确匹配与离线模糊匹配。两种匹配模式相辅相成，共同组成主索引服务。
▲支持在病人登记场景发生时，系统能够自动捕获该场景的病人基本信息，调用主索引服务。主索引系统执行在线精确匹配，根据精确匹配结果快速匹配相似的病人记录，在线精确匹配结果需控制在500毫秒内。如果在精确匹配没有匹配结果的情况下，系统应将该病人信息自动转为离线模糊匹配，根据模糊匹配条件生成疑似匹配结果，然后由人工对其进行确认。（提供投标人或软件原厂商患者主索引系统产品著作权证书）
通过管理系统与信息集成引擎的对接， (略) 需支持的组件、服务、事件及数据交换规则进行定义和配置。
需具备完善的用户管理功能，包括用户、组的维护，针对不同用户进行权限管理。
组件 (略) 的组件进行登记，只有注册过的组件 (略) 所接受。
支持对已注册的系统，进行服务登记，这里所指服务是指系统对外需提供的服务。
(略) 所需支持的消息事件进行登记。
应实现针对不同系统所需要的消息进行过滤。
日志监控系统用来跟踪和记录通信历史信息，为后续性能分析、问题分析提供必要数据基础。
支持用户通过时间，通信系统，通信内容，消息类型等作为检索条件查询相应的通信日志。
应提供异常日志，当消息流发生异常时产生错误日志，记录在异常日志表中，主要用来分析错误原因。
当消息传 (略) 络异常中断，产生的异常日志，可通过日志重发功能重新发送传输异常的消息。
采用归档的形式将日志信息转储到另外的日志归档表中，保证日志表数据条数控制在一定数量级内，方便快速查找。日志归档需支持每日自动归档和手动归档两种方式。
(略) 运行服务相应的具体报文内容的消息模型进行新增修订发布等管理功能。
(略) 的相关系统提供的服务接口进行配置管理，包括服务地址，协议类型。调用方法等内容。
(略) 所需支持的业务消息事件进行登记修改等功能，通过简单的界面拖拉组件操作进行业务场景的编排配置。
平台应提供统一调用总线的服务入口， (略) (略) 服务场景的请求调用跟返回消息的标准化。
医疗组织在管理医疗数据集成需要的大量标准。要求本项目集成引擎的标准医疗通讯协议资料能够完整齐全，并能够需支持相关医疗标准的不断更新，为平台提供标准支持。
要求集成引擎嵌入协议标准（TCP、FTP、HTTP、网络服务等等）；
需支持DICOM图像格式转换机应用；
需支持医用信息系统集成（IHE）配置文件。
消息中间件应采用消息队列技术，通过消息队列，应用程序可独立地执行，而不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收消息。
平台应能通过使用消息中间件实现系统之间数据的快速交换、查询、调阅等功能。
平台同时应能提供消息中间件的配置管理功能：包括部署授权管理、 (略) 由、开发集成环境。
通过管理系统与信息集成引擎的对接， (略) 需支持的组件、服务、事件及数据交换规则进行定义和配置。
需具备完善的用户管理功能，包括用户、组的维护，针对不同用户进行权限管理。
(略) 管控端登录及连接事件的活动日志的记录查看功能。
支持对通过简单 (略) 管控界面挂载的系统菜单显示进行配置的功能。
具备针对新接入系统或者接口服务的在线联调测试的功能。
(略) 服务资源目录及功能说明的在线查看功能。
日志监控系统用来跟踪和记录通信历史信息，为后续性能分析、问题分析提供必要数据基础。
支持用户通过时间，通信系统，通信内容，消息类型等作为检索条件查询相应的通信日志。
应提供异常日志，当消息流发生异常时产生错误日志，记录在异常日志表中，主要用来分析错误原因。
当消息传 (略) 络异常中断，产生的异常日志，可通过日志重发功能重新发送传输异常的消息。
采用归档的形式将日志信息转储到另外的日志归档表中，保证日志表数据条数控制在一定数量级内，方便快速查找。日志归档需支持每日自动归档和手动归档两种方式。
管理员应可以从监 (略) 运行状态、接口状态、诊断信息、性能图表、交互消息量等。 (略) 都 (略) 络浏览器方便访问同时可作出简便设置并 (略) 由情况。 (略) 的功能主要包括：平台服务器监控、性能监控、服务监控、日志监控、用户告警等。
▲ (略) 的物理服务器性能的监控，包含所有在用或备用服务器的CPU使用率、内存使用率、网络流量、硬盘吞吐量等关键指标。（提供投标人 (略) 产品著作权证书）
支持通过设 计系统名 称的故障服务服务数/系统所有注册服务数直观展示给管理人员，说明总线当前运行的情况。
场景监控是指对企业服务总线软件的运行状况的监控，包含所有在用或备用服务的可用性、当日接收调用次数、当日发送消息次数，当日错误发生次数等关键指标。
支持实时监控ESB总线各系统组件的运行状态，如发现故障可以及时排除故障。
实现对当日消息量和数据库消息表空间使用率的监控。其中消息量监控包含业务流消息，字典服务消息的正常数量、异常数量和等待数量的监测。
(略) 监控指标大屏展示功能， (略) 关注的服务器、总线、数据库等相 (略) 管理人员进行直观展示。
平台 (略) 运行状况的统计日报汇总，指标包括服务交换情况，异常情况，数据库表空间情况等。
平台告警规则配置功能可以对每个交互事件场景的告警条件进行配置，比如异常数达到多少，最大值超过多少等条件满足的情况下将进行告警提醒；
平台针对告警信息通知推送进行配置，配置内容包括推送目标人员的相关信息（联系方式，人员等级等）以及通知推送规则，推送方式等信息
(略) 或者微信公众号等消息通知推送渠道的情况下，平台可以提供告警信息通知接口适配对接的功能，根据现场实际情况对接短信、微信公众号等消息通知接口。.
(略) 告警事件的日志留存及时候查看功能。 (略) 管理人员针对告警信息进行问题分析及处理。
平台的主索引管理系统应能提供两种匹配模式：在线精确匹配与离线模糊匹配。两种匹配模式相辅相成，共同组成主索引服务。
通过统一门户认证，用户不再需要每次输入用户名 称和用户密码，也不需要牢记多套不同供 应 商的系统用户名 称和用户密码，从而改善用户使用应用系统的体验。
通 (略) 化的分层架构，平台 (略) 临床业务流程具备内置以下接入集成业务专题。将不同的临床业务依据访问频度、性能要求、实时性要求、数据粒度,涉及的临床业务系统等的要求进行架构分层。
根据 (略) 集成专题包接入包括：
（1）患者标识域(患者信息、建卡建档相关的服务)
（2）门诊就诊域(门诊挂号诊断等就诊相关服务)
（3）住院就诊域(住院入、出、转相关服务)
（4）检查业务场景集成（检查申请单业务相关服务）
（5）检验业务场景集成（检验申请单业务相关服务）
（6）手术业务场景集成(手术申请相关业务服务)
（7）用血业务场景集成(输血申请单业务相关服务)
（8）医嘱用药业务场景集成(医嘱状态交互)
（9）基础字典集成域
§4、临床数据中心需提供多种类型的采集手段，以满足数据采集现状的要求。需支持主流关系型数据库，如Oracle、SqlServer、Mysql等。根据数据需求的实时性及业务系统的可操作性（如是否能开放日志捕获等），同时支持实时采集、定时采集两种主要技术模式。
实时采集总线，应基于日志的结构化数据复制机制，通过捕获数据库日志，处理、转化并实时入库。自动识别数据库结构变更，当出现表结构发生变动时，需要能够自动捕获、生成对应语句并自动执行，实现全自动实时静默同步，无需人工干预。除支持单表数据实时入库外，应支持转化数据以准实时（非定时任务）方式入库。
定时采集总线，应基于ETL机制，能够支持多种数据格式（如表、视图等），同时支持在线配置清洗转化逻辑。通过定时增量任务配置，实现定时采集转化。
基于ETL定时采集总线，具体需实现以下功能：
1、支持ETL作业生成
支持用户通过编写ETL程序，并将程序生成批量运行的作业，并允许对作业进行调度管理。
2、支持拖拽方式可视化创建ETL过程
提供易于操控的可视化作业生成界面，降低编写程序的难度，使用拖拽的方式，迅速编写好ETL数据转换作业，并且能看到作业过程。
3、支持对不同数据源进行转换操作
允许用户通过下拉列表对不同数据源，转换方式，目标输出地进行选择。
4、支持同时对数据源进行多次操作
支持用户对同一数据源进行多次不同类型的数据转换操作。
5、支持对数据源的多次操作进行自定义排序
支持用户对数据操作类型进行排序。
6、支持关系型数据库输出
7、支持用户输出数据转换结果到关系型数据库，允许用户配置，表名字，每次处理的记录数量，以及对于存在唯一主键或者索引的记录处理方式(更新同一主键的其他字段或者直接替换)。
8、支持拖拽方式配置ETL作业的时候动态生成数据抽样
支持用在在进行拖拽方式配置数据ETL转换作业时候，动态生成数据抽样结果，可以点击点击转换对数据转换过程进行实时查看，也可以编辑数据对样本数据进行修改。
9、同时支持C/S端及WEB端配置ETL逻辑。
10、支持用户设置数据ETL作业自定义变量
允许用户设置自定义变量，使用变量替换区配置多个调度任务，每个调度任务里的参数可以不同。
11、支持用户自定义作业调度周期
允许用户填写作业实际的调度策略，可以按小时，天，或者周等等。
12、支持用户自定义作业运行时间
允许用户定义数据开始的时间，作业结束时间。
13、支持ETL作业调度与管理
支持数据ETL转换作业调度与管理提供列表式管理界面，让用户创建的转换作业进行全局查看，提供作业状态、队列数、启始时间，等等进行统筹管理。
数据质量校验包括数据采集、数据加载、数据分发等过程中数据校验。在数据采集过程中通过对数据源与目标数据库之间的数据进行对比分析，从而进一步来分析、发现与解决在数据抽取过程可能产生的异常错误信息，同时完成数据缺失的修复。
数据接入校验需具备将分散的、异构数据源中的数据如关系数据、非关系数据、数据文件等抽取到临时中间层后进行解析、转换、校验、过滤、清洗、反馈。
数据校验规则要求：数据校验需求可以满足不同的系统使用者从不同的角度对数据进行分析。校验规则主要包括数据完整性、准确性、一致性三方面的规则。
数据校验任务要求：定时的执行数据校验规则，满足对不同规则的执行方式进行设置，配置任务的触发时间和执行时间。
数据转换要求：不同业务系统之间、业务系统与共享数据库保存的数据格式和语义可能都不一致，他们之间交换的数据需 (略) 提供统一的可识别、可处理的数据。此外，通过数据转换，可以方便地对海量数据进行编目及目录转换。
完整性控制要求：MD5 或者HASH 校验通过对接收的传输数据执行散列运算来检查数据的正确性。计算出的散列值和随数据传输的散列值比较。如果两个值相同，说明传输的数据完整无误、没有被篡改过（前提是散列值没有被篡改），从而可以放心使用。
数据过滤要求：支持对指 定数据源数据的字段清洗，通过配置对指 定数据源进行字段级别的清洗过滤；支持编码格式转换、特殊字符的处理；支持可配置的数据过滤框架，业务可以根据需要注册数据过滤程序。
校验结果展示要求：对采集结果进行校验后产生的结果数据，将结果数据推送到服务配置端以供相关人员进行查看和分析。
错误数据反馈要求：针对残缺数据、错误数据和重复数据支持即时反馈的功能，促使数据提供单位尽快地修正错误，同时也可以做为将来验证数据的依据。
系统需采用关系型数据库保存，并遵循第三范式设 计存储，对于非结构化的、文档中的内容数据，系统应采用文件存储或非关系型的存储系统存储。
数据从来源到目标的采集过程当中，需实时的对当前采集的进度进行监控。
监控内容需包括：进程状态、网络状态、连接情况、应用状态、异常状态等。对采集端的监测，包括是否正常运行、在线离线的监测以及异常的环境汇总。
提供数据接口所有任务的运行监控功能、异常日志分析工具、异常任务处理和恢复功能：
需提供针对任务点的异常恢复，当运行的任务执行失败时，可以重新运行任务（流程启动）、从故障点运行任务（任务启动）。
需支持对不符合接口规范的异常数据进行标记的功能，并将异常数据输出到指 定目录、提供数据质量统计分析报告（数据源、时间、成功记录、失败记录（各种失败类型分类记录）等。
需提供可视化的任务运行日志管理功能，包括运行的日志详细信息（成功、异常）。
支持对所有系统运行日志、操作日志、业务日志、异常日志进行保存，并提供相应的可视化查询和操作功能：
需支持对系统运行详细资源、状态、运行日志的可视化监控和维护，包括软件状态、数据传输、数据稽查等；
需支持对系统操作日志的记录，包括时间、人员、操作模块、操作类型、操作前参数、操作后参数等；
需支持基于异常日志重发机制。
▲需支持对业务运行日志的采集和汇总，基于Web 框架，支持查询日志，并将采集日志进行归档汇总。(提供投标人或软 (略) 统计信息管理系统软件著作权证书)
支持通过集成视图方式进行数据展现,能实现病人诊疗信息的统一展现，横向以时间轴的方式显示病人的体征、医嘱等信息，纵向以诊疗事件顺序来显示相关诊病信息，如检验、检查报告、手术记录等信息，还应包括检验报告的趋势分析、历史报告对比分析等功能。
系统需通过多种维度的数据组织方式，进一步挖掘数据价值，为临床科室人员提供有效数据支持。
就诊视图：支持以就诊主线组织数据，展现每一次患者对应的就诊数据，包含诊断记录，文书，体格体征，医嘱，检查检验报告等信息。
临床视图：支持以临床业务类型为主线组织数据，展现患者特定诊断类型的历史数据，如检查报告（历史指标比对），历史开药记录等。
支持整合患者主索引（EMPI），能够将多种注册渠道的患者，通过特定的规则，统一展现在患者360视图中，实现相关数据的汇聚展示。
▲支持针对患者的每一次就诊记录，均有对应的共享文档记录。患者360视图将二者进行关联结合，满足国家后续关于就诊数据共享交换的长期需求。（提供投标人或软件原厂商医疗信息共享文档库系统产品著作权证书）
支 (略) 内闭环系统（含药品闭环、手术闭环、检查闭环、检验闭环、会诊闭环、危急值闭环等），能够直观的从就诊记录中查看业务中闭环相关数据。
应能够实现快速逻辑配置，无需重启服务， (略) 系统快速上线、快业务逻辑迭代的需求。
1.文档管理：应实现文档生成模板、生成逻辑、展示界面进行在线配置，实现共享文档的生成、批量生成和下载。
2.模型与抽取：应实现共享文档主题库的抽取模型在线配置，实现共享文档基础数据实时抽取、转化。通过配置计划、任务，实现基础数据定时转化。
3.文档校验：应能够基于共享文档数据集中数据元对应的校验规则（如是否必填、数值型、布尔型），对已生成的共享文档进行数据批量校验，形成分析报表。
4.系统配置：应实现文档类型、视图类型、关联关系，每篇文档基础数据集及规则、脱敏规则等配置。
5.数据统计：支持对已生成的文档实现图表分析。同时允许配置多个数据源，比对原始数据和目标数据的数量，用于分析目标文档生成总量是否符合预期。
应包括标准数据元管理、数据元值域管理、标准数据集管理。其中针对数据元管理可以进行增加、修改和删除等操作。
▲根据数据标准的修订，及时更新系统中数据标准信息。其中数据标准管理需包括对数据元、值域、数据集等管理。（提供投标人或软件原厂商数据仓库系统产品著作权证书）
▲需提供可视化操作功能，配置文档生成逻辑，生成对应共享文档。生成逻辑与生成模板均可在线配置，即改即生效，便于现场实施人员快速、灵活完成共享文档生成。(提供投标人或软件原厂商医 (略) 软件著作权证书)
共享文档的基础数据，需支持定时任务完成数据的自动抽取、转化与清洗，也支持手动按照视图/文档机制实时完成数据抽取。系统需支持从线下C/S客户端构建转化模型后上传系统，也需支持直接在系统中创建转化模型。
应实现对文档的组成字段、字段规则（是否必填、是否满足某种条件等）进行校验。校验可以单篇文档校验，也可以建立校验组，实现批量校验。通过扫描数据质量，可大范围挖掘目前共享文档距离国家标准的差距，同时可以定位具体存在的字段的源头。
支持对术语字典的名 称进行登记，只有注册过的术语才会被纳入主数据管理范围。根据卫生部数据标准规划，注册内容应包含，术语字典名 称，编码，版本，标准来源，标准更新日期。
通过主数据管理 (略) 基础数据集中管理，实现主数据整合、共享和监管功能。基础字典实现基于国家、卫生局等标准字典的维护。
(略) 内各系统中非标字典的维护和管理。
(略) 内字典之间，存在映射关系。为了统一语义，实现标准化，提供 (略) 内字典的映射维护及管理。
§5、现有系统接入▲ (略) 前期投资，优化现有就诊流程，实现数据无缝连接，需要在现有信息化软件系统的基础上， (略) 信息 (略) 的对接改造，实现数据共享、标准定义、统一用户管理、用户统一系统入口等功能。（提供投标人或软 (略) 信息单点登录系统著作权证书）
应基于以下原则建设：
1、简单， (略) 维护及查找故障；
2、易于修改，避免双方大规模修改程序或业务流程；
3、行业通用的，或国际标准的；
4、投标人应提供对接标准，由第三方业务系统提供数据，自行写入其业务系统数据库，投标人不操作对方数据库；
5、尽可能的减少工作人员操作的步骤，尽可能从后台实现。
★投标人应书面承诺，投标人 (略) (略) 能与招标方现有的HIS系统、检验系统、电子病历系统等实现数据无缝连接与互联互通，所有业务数据均能够相互调阅实现流程的一体化应用，若需要第三方协助以接口方式实现的，则所有接口开发费用必须包含在本次投标报价中，招标方无需另行支付。
更正日期：2022年9月28日
三、其他补充事宜
四、凡对本次公告内容提出询问，请按以下方式联系
1.采购人信息
名 称： (略)
地 址：漳浦县绥安 (略) 19号
联系方式：0596-*
2.采购代 理机构信息（如有）
名 称：福建 (略)
地 址： (略) 龙文 (略) 22号明发商业广场1幢2407室-2414室
联系方式：*
3.项目联系方式
项目联系人：余先生
电 话：0596-*
福建 (略)
发布日期：2022年9月28日
招投标大数据
最近搜索
无
热门搜索
无
