系统部署方案

  • 格式:docx
  • 大小:72.92 KB
  • 文档页数:11

下载文档原格式

  / 11
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

系统部署方案

Document number:WTWYT-WYWY-BTGTT-YTTYU-2018GT

目录

系统部署方案

一、技术架构

iMed_HER电子健康档案信息系统是一个基于标准的健康数据平台。所有文档都符合HL7v3CDA标准,所有消息都符合HL7v3标准。HL7v3是在EHRS上进行信息交换的标准。其中包括要经过HIAL的所有消息。因为所有消息转换、路由和使用服务都要经过HIAL,所以HIAL的可扩展性对成功进行互联互通至关重要。EHRS平台上硬件系统的处理能力与设计(网络、存储和安全在单独章节中描述),重点着眼于区域卫生信息平台的互联互通性以及健康信息的处理与分析。

相互连接性

有许多系统要连接到HIAL,其中包括POS、公众健康信息数据存储库/门户、公共门户。可以按各种模型SaaS、内部开发的系统、COTS(现成构件)-或这些模型的混合来实施这些系统。HIAL必须支持不同的软件架构的连接,而且不应牵涉任何外部系统的改造。这些系统之间的连接可以通过专用网络或公共网络进行,因此必须针对所有通信互连加强安全性以保证互连的安全。

标准的发展和采用

标准的发展往往是一个进程,HL7也不例外。HIAL负责实现兼容的消息交换,例如消息映射和消息转换。这是为了保证基础结构的投资,以及实现与RHIN将来要扩展到的主体/系统的灵活兼容。此

外,在支持现有的遵从HL7的POS系统(可能是在上)上的信息交换方面也应该有一定的灵活性。示例场景包括:POS应用程序可以了解,但不能从采用了IHE配置文件XDS(跨院区文档共享)的社区HIE中查询和检索临床文档。HIAL需要在无需对POS应用程序进行任何变更的情况下实现这种使用情形。医院希望发布医患接触概况并与下属医生网络共享。HIAL可以简单地将来自医院接口引擎的消息源重定向,从而帮助实现这一点。HIAL可以进一步根据数据格式提供到HL7v3的映射。这将减少花费在系统集成上的时间和成本。在以上两个示例中,都需要利用在旧系统上的现有的投资,同时认识到向前发展需要有更加灵活、可扩展的架构和标准。HIAL可以执行作为基础结构层一部分的集成功能,从而允许医疗保健提供商可以采用与其策略更加一致的方式或步伐来实现互联互通性,而不必受限于供应商的计划或某个部门的老旧应用程序。对于可能已经实施了较多系统的区域,RHIN可以考虑将连接扩展到HL7以外。这样可以加快互联互通性的实现速度,从而加快居民电子健康档案系统的实现速度。

术语规范化

HIAL完成了整个RHIN中的术语规范化工具。存储在RHIN数据仓库中的数据必须是规范化的数据,以便实现互联互通性和分析的一致性。

数据位置和HIAL处理

HIAL的最佳模型应该不知道医疗数据的物理位置。也就是说,在每个POS(分布式或混合模型/联合式)中,不牵涉考虑患者数据是否(集中)放在某个地方。而且,架构模型也不应自动适应数据源的变化,例如,不应要求开发团队在事情发生变化时重新构建整个模型。LRS(时序档案服务)也需要具备汇聚分布在整个RHIN中(包括EHRS与外部连接系统)的原数据能力。重点应放在规范化其上下文中的数据上,以方便后续的分类和存储。这样有助于根据RHIN 规模来实施不同的HIAL范围。

监管

策略监管是RHIN中的重要组成部分,其中服务提供商和服务实施可以是一个混合体。RHIN架构必须包括一个可为跨供应商整合式监管提供开放策略框架的组件,并且策略的监管和执行最好在HIAL 层实施。简而言之,HIAL需要提供“基础设施层”互联互通性,并且能在iMed_HER电子健康档案信息系统和连接系统的持续发展中保持可互联互通性。

二、部署方式

数据集中式管理

现在IT的发展趋势是数据集中,数据集中的核心是对服务器进行整合。特别是一些大型企业,建立企业数据中心,购买高性能的主机,对数据集中管理,已成为一种潮流。iMed_HER电子健康档案信息系统的网络服务器部署推荐集中式。

采用B\S架构

iMed_HER电子健康档案信息系统采用B\S架构,B\S结构(Browser/Server,/模式),是WEB兴起后的一种网络结构模式,WEB浏览器是最主要的。这种模式统一了客户端,将系统功能实现的核心部分集中到服务器上,简化了系统的开发、维护和使用。客户机上只要安装一个浏览器(Browser),如或,服务器安装、、或等数据库。浏览器通过同数据库进行数据交互。B\S架构大大简化

了客户端的安装操作。

三、项目实施计划

项目实施流程

项目实施流程图如下:

项目实施主计划

项目实施主计划详细的描述了项目的进程,并明确了资源配置和项目各阶段应该完成的内容。

项目共有五个里程碑:项目组成立,系统安装,系统上线,用户培训,项目验收。

实施进度表

实施计划进度简表

备注:以上时间可根据具体实际情况再作调整!

四、网络安全

网络可靠性和冗余

➢本系统将从以下几个方面考虑高可用设计:

➢网络设备考虑交换引擎、接口、风扇、电源等冗余配置。

➢服务器接入层交换机成对部署,以支持服务器的多网卡双归属接入方式

➢在服务器接入交换机与汇聚交换机之间部署全交叉的物理链路,以实现链路的可靠性。

➢当服务器采用二层接入时,应将主汇聚交换机做为第一级服务器的默认网关以及STP的根节点,并将备份汇聚交换机设置为备用网关和备用STP 根。

➢将VRRP+MSTP或交换机虚拟化技术做为保证高可用型的实现技术。

网络安全技术部署

基于VLAN的端口隔离

交换机可以由硬件实现相同VLAN中的两个端口互相隔离。隔离后这两个端口在本设备内不能实现二、三层互通。当相同VLAN中的服务器之间完全没有互访要求时,可以设置各自连接的端口为隔离端口。这样可以更好的保证相同安全区域内的服务器之间的安全。

基于Root/BPDUGuard(Root/BridgeProtocolDataUnitGuard)方式的二层连接保护保证STP/RSTP(SpanningTreeProtocol/RapidSpanningTreeProtocol)稳定,防止攻击,保障可靠的二层连接。

基于BPDUGuard

对于接入层设备,接入端口一般直接与用户终端(如PC机)或文件服务器相连,此时接入端口被设置为边缘端口以实现这些端口的快速迁移;当这些端口接受到配置消息(BPDU报文)时系统会自动将这些端口设置为非边缘端口,重新计算生成树,引起网络拓扑的震荡。这些端口正常情况下应该不会收到生成树协议的配置消息的。如果有人伪造配置消息恶意攻击交换机,就会引起网络震荡。BPDU保护功能可以防止这种网络攻击。交换机上启动了BPDU保护功能以后,如果边缘端口收到了配置消息,系统就将这些端口shutdown,同时