系统部署方案.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
系统部署方案.doc

目录 一、技术架构 11 1.1相互连接性 12 1.2标准的发展和采用 12 1.3术语规范化 13 1.4数据位置和HIAL处理 13 1.5监管 14 二、部署方式 14 2.1数据集中式管理 14 2.2采用B\S架构 14 三、项目实施计划 15 3.1项目实施流程 15 3.2项目实施主计划 15 3.3实施进度表 16 四、网络安全 16 4.1网络可靠性和冗余 16 4.2网络安全技术部署 17 4.2.1基于 VLAN的端口隔离 17 4.2.2 STP Root/BPDU Guard 17 4.2.3端口安全 18 4.2.4防IP伪装 18 4.2.5路由协议认证 19 系统部署方案 一、技术架构 iMed_HER电子健康档案信息系统是一个基于标准的健康数据平台。所有文档都符合 HL7 v3 CDA 标准,所有消息都符合 HL7 v3 标准。HL7 v3 是在 EHRS 上进行信息交换的标准。其中包括要经过 HIAL 的所有消息。因为所有消息转换、路由和使用服务都要经过 HIAL,所以 HIAL 的可扩展性对成功进行互联互通至关重要。EHRS 平台上硬件系统的处理能力与设计(网络、存储和安全在单独章节中描述),重点着眼于区域卫生信息平台的互联互通性以及健康信息的处理与分析。 1.1相互连接性 有许多系统要连接到 HIAL,其中包括 POS、公众健康信息数据存储库/门户、公共门户。可以按各种模型 SaaS、内部开发的系统、COTS(现成构件)- 或这些模型的混合来实施这些系统。HIAL 必须支持不同的软件架构的连接,而且不应牵涉任何外部系统的改造。这些系统之间的连接可以通过专用网络或公共网络进行,因此必须针对所有通信互连加强安全性以保证互连的安全。 1.2标准的发展和采用 标准的发展往往是一个进程,HL7 也不例外。HIAL 负责实现兼容的消息交换,例如消息映射和消息转换。这是为了保证基础结构的投资,以及实现与 RHIN 将来要扩展到的主体/系统的灵活兼容。此外,在支持现有的遵从 HL7 的 POS 系统(可能是在 HL7v2.x 上)上的信息交换方面也应该有一定的灵活性。示例场景包括:POS 应用程序可以了解 HL7v2.5,但不能从采用了 IHE 配置文件 XDS(跨院区文档共享)的社区 HIE 中查询和检索临床文档。HIAL 需要在无需对POS 应用程序进行任何变更的情况下实现这种使用情形。医院希望发布医患接触概况并与下属医生网络共享。HIAL 可以简单地将来自医院接口引擎的 HL7v2.x 消息源重定向,从而帮助实现这一点。HIAL 可以进一步根据数据格式提供 HL7.2x 到 HL7v3 的映射。这将减少花费在系统集成上的时间和成本。在以上两个示例中,都需要利用在旧系统上的现有的投资,同时认识到向前发展需要有更加灵活、可扩展的架构和标准。HIAL 可以执行作为基础结构层一部分的集成功能,从而允许医疗保健提供商可以采用与其策略更加一致的方式或步伐来实现互联互通性,而不必受限于供应商的计划或某个部门的老旧应用程序。 对于可能已经实施了较多系统的区域,RHIN 可以考虑将连接扩展到 HL7 以外。这样可以加快互联互通性的实现速度,从而加快居民电子健康档案系统的实现速度。 1.3术语规范化 HIAL 完成了整个 RHIN 中的术语规范化工具。存储在 RHIN 数据仓库中的数据必须是规范化的数据,以便实现互联互通性和分析的一致性。 1.4数据位置和HIAL处理 HIAL 的最佳模型应该不知道医疗数据的物理位置。也就是说,在每个 POS(分布式或混合模型/联合式)中,不牵涉考虑患者数据是否(集中)放在某个地方。而且,架构模型也不应自动适应数据源的变化,例如,不应要求开发团队在事情发生变化时重新构建整个模型。LRS(时序档案服务)也需要具备汇聚分布在整个 RHIN 中(包括 EHRS 与外部连接系统)的原数据能力。重点应放在规范化其上下文中的数据上,以方便后续的分类和存储。这样有助于根据 RHIN 规模来实施不同的 HIAL 范围。 1.5监管 策略监管是 RHIN 中的重要组成部分,其中服务提供商和服务实施可以是一个混合体。RHIN 架构必须包括一个可为跨供应商整合式监管提供开放策略框架的组件,并且策略的监管和执行最好在 HIAL 层实施。简而言之,HIAL 需要提供“基础设施层”互联互通性,并且能在iMed_HER电子健康档案信息系统和连接系统的持续发展中保持可互联互通性。 二、部署方式 2.1数据集中式管理 现在IT的发展趋势是数据集中,数据集中的核心是对服务器进行整合。特别是一些大型企业,建立企业数据中心,购买高性能的主机,对数据集中管理,已成为一种潮流。iMed_HER电子健康档案信息系统的网络服

文档评论(0)

wuyouwulu + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档