基于电子病历的医院信息平台建设技术解决方案.docx
《基于电子病历的医院信息平台建设技术解决方案.docx》由会员分享，可在线阅读，更多相关《基于电子病历的医院信息平台建设技术解决方案.docx（11页珍藏版）》请在冰豆网上搜索。
基于电子病历的医院信息平台建设技术解决方案
基于电子病历的医院信息平台建设技术解决方案.doc
篇一：
（XX-03-29）卫生部《基于电子病历的医院信息平台建设技术解决方案（版）》
卫生部办公厅关于印发《基于电子病历的医院信息平台建设技术解决方案（版）》的通知
卫办综发〔XX〕39号
各省、自治区、直辖市卫生厅局，新疆生产建设兵团卫生局，部属（管）医院：
为配合公立医院改革试点工作，推进以电子病历和医院管理为重点的医院信息化建设，促进医疗卫生领域业务应用系统互联互通和信息共享，我部在发布《电子病历基本架构与数据标准（试行）》（卫办发〔XX〕130号）基础上，组织编制了《基于电子病历的医院信息平台建设技术解决方案（版）》。
现印发给你们（标准文本可在卫生部网站下载），请参照试行，并及时将试行过程中发现的问题和有关建议反馈我部。
联系人：
卫生部统计信息中心童心、汤学军
联系电话：
（010）68792938、68792477
二〇一一年三月二十三日
业务部分_封面及目录.pdf
第一章概述.pdf
第二章分析与思路.pdf
第三章业务需求分析_用户分析.pdf
第三章业务需求分析_建模.pdf
第四章信息模型.pdf
技术部分_封面及目录.pdf
第五章平台设计.pdf
第六章应用与业务协同.pdf
第七章安全保障体系.pdf
第八章项目管理.pdf
第九章运维管理.pdf
致谢_医院信息平台.pdf
篇二：
电子病历的医院信息平台建设技术
电子病历的医院信息平台建设技术医院网络构架
设计原则
医院信息平台体系架构设计应遵循以下原则：
基于医院信息化现状，实现信息共享与业务协同。
即医院信息平台的建设不是一个推翻现有应用重建的过程，而是基于现有信息系统和现有的系统数据，通过医院信息平台来整合信息，并实现系统之间的业务协同。
基于企业信息架构分层设计思路。
按照企业信息架构理论和方法，以分层的方式设计医院信息平台，不同的层次解决不同（转载于:
小龙文档网:
基于电子病历的医院信息平台建设技术解决方案.doc）的问题。
覆盖医院信息系统建设全生命周期。
不仅包括从技术角度医院信息平台本身如何设计和建设，还包括医院信息平台项目管理、系统运维以及相关的信息安全保障体系。
全面支持电子病历相关业务规范与标准体系。
从数据层面遵循《电子病历基本架构与数据标准》，即医院信息平台上保存的电子病历数据符合该标准；在电子病历生成和使用上符合电子病历相关业务规范。
总体架构
医院信息平台总体架构
医院信息平台总体架构
如上图所示，医院信息平台的总体架构设计分为九个部分，包括：
医院信息平台门户层、医院信息平台应用层、医院信息平台服务层、医院信息平台信息资
源层、医院信息平台信息交换层、医院业务应用层、信息基础设施层以及信息标准体系、信息安全体系与系统运维管理。
其中图中上半部分包括的医院信息平台门户层、医院信息平台应用层、医院信息平台服务层、医院信息平台信息资源层、医院信息平台信息交换层是属于医院信息平台的软件部分，主要服务于医院信息系统应用整合的需求；医院业务应用层是目前医院内部的业务应用系统，是医院信息平台的基础；信息基础设施层以及标准规范和信息安全与系统运维管理服务于医院业务应用系统和医院信息平台，信息基础设施层主要服务于医院信息系统基础设施整合的需求。
医院信息平台信息交换层，主要用于实现全院级应用系统互联互通的需求；医院信息平台信息资源层，主要服务于建立全院级的病人主索引的需求、建立全院级电子病历的需求，并为医院信息二次利用、为患者提供公众服务、与外部互联奠定数据基础；医院信息平台应用层包含了建立在医院信息平台信息资源层、医院信息平台服务层、医院信息平台信息交换层的基础上的全院级应用。
医院网络的搭建
医院网络分层、功能分区设计
医院网络主要分为两层机构，包括数据中心层和终端接入层。
而数据中心层主要包括骨干网络区，内网中心服务器区，外网中心服务器区，数据灾备区，安全管理区，医疗专网出口区，互联网出口区等区域，而终端接入区则包含门诊终端接入区，住院终端接入区，医技设备接入区，无线终端接入区，行政终端接入区等区域。
网络分层概述
基于电子病历的医院信息平台业务模式具有扁平化特点，所有接入区终端点直接与数据中心的的业务系统进行交互。
进行网络架构设计时应充分考虑此特点，设计信息平台主要由两大部分组成，医院数据中心层和终端接入层。
终端接入层主要负责将门诊、住院、医技、行政终端等接入网络，实现业务数据的提交和电子病历资源以及医疗信息的调用，并且为网上办公提供网络基础；医院数据中心主要负责各业务系统的运行、管理，EMR信息的存储、调用，办公系统的业务支撑，医疗影像信息的存储，以及信息平台的外联。
整体网络架构设计-网络架构分层模型
进行整体网络架构设计时充分考虑此特点，将网络架构分为二层：
终端接入、数据中心。
同时根据各自其特点进行进一步细化。
网络分区概述
在阐述网络分区之前，先来明晰两个概念，本文中在介绍网络分区过程中所提到的内网外网的概念为逻辑上的划分，两种实际的物理架构中，逻辑上均包含内网和外网两部分。
划分主要根据业务系统的对内对外服务属性，医疗核心业务相关度等特性来进行，在实际实施过程中，需根据医院自身的实际情况，确定自身是否需要构建物理上内外网分离的网络。
网络基础设施平台根据其功能特点逻辑上划分13大模块：
内网中心服务器区、外网中心服务器区（DMZ区）、数据灾备区、骨干网络区、医疗专网出口区、互联网出口区、网络安全管理区、门诊终端接入区、住院终端接入区、医技终端接入区、无线终端接入区、行政终端接入区、其他终端接入区等。
数据中心的各
区域模块间通过独立的防火墙设备或者防火墙板卡进行安全隔离。
整体网络架构设计-网络架构分区模型
医院信息平台建议实际包含或功能上包含以下功能模块，方便针对不同的区域运用不同的控制策略：
内网中心服务器区
外网中心服务器区（DMZ）
数据灾备区
骨干网络区
医疗专网出口区
互联网出口区
网络安全管理区
门诊终端接入区
住院终端接入区
医技终端接入区
无线终端接入区
行政终端接入区
其他终端接入区
各区域的界限以及作用范围如下：
内网中心服务器区
医院信息平台上内网所有的应用服务器、数据库服务器、中间件服务器、数据存储设备等一切内网业务系统相关设备的集中连接区域，是整个医院业务的核心。
例如，内网中心服务器区域是HIS系统、LIS系统，PACS系统，EMR系统，等所在的区域。
外网中心服务器区（DMZ区）
医院信息平台上外网所有的应用服务器、数据库服务器、中间件服务器、数据存储设备等一切外网业务系统相关设备的集中连接区域。
例如，外网中心服务器区是医院外网OA服务器，外网WEB服务器，MAIL服务器等所在的区域。
器区是医院外网OA服务器，外网WEB服务器，MAIL服务器等所在的区域。
数据灾备区
该区域是HIS、电子病历、医学影像系统，等数据中心子系统的灾备区域，一般该区域为院内灾备区域，通过高速链路直接与核心交换机相连，实现业务系统与灾备区域数据实时的同步。
骨干网络区
主要负责医院信息平台上数据中心区域内各服务器区之间的互联，以及数据中心区与终端接入区之间的互联或汇聚互联，该区域的主要功能为实现局域网内数据的高速处理和转发。
远程链路汇聚主要采用高性能的路由器、VPN网关服务器。
HIS系统、LIS系统、EMR系统、PACS系统、网络安全管理系统等模块主要通过万兆平台及其以上的高性能三层交换机进行连接。
医疗专网出口区
该区域主要功能为为医疗信息平台提供医疗专网的接入服务，医疗专网包含的主要内容包括：
医疗行业上级单位，疾控直报网络，公共卫生突发预警系统，公安局，区域医疗卫生信息平台等。
医疗专网出口为医院信息平台提供了与其他医疗信息平台及上级主管机构信息交互的安全高效的通道，是连接医院信息孤岛，整合医疗信息网络的重要部分。
这部分出口主要通过专线连接，最好能够提供冗余的出口线路。
互联网出口区
该区域是为下载医学相关资料，获取互联网海量信息而提供的安全Internet出口，也是医院门户网站，对外服务系统对公众社会提供服务的出口区域，该区域由于与广域网链路相连，外部网络环境较为复杂，存在较大的风险隐患，所以是安全防护的重点区域。
该区域主要由高性能路由器、防毒墙、防火墙、流控设备、VPN设备、上网行为管理设备，网站保护系统等组成。
网络安全管理区
医院信息平台数据中心内保障整体信息平台安全、稳定运行的安全管理运维系统的连接区域。
如证书服务器、身份认证、漏洞扫描、入侵检测、网络管理等。
门诊终端接入区
该区域主要是将医院门诊部医疗相关的核心业务终端接入医院基础网络，主要包括门诊部门的医生工作站，护士工作站，计价终端系统等医疗相关终端系统接入网络，提供门诊部医疗终端与数据中心之间的互联互通性，使其能够快速，稳定与数据中心进行信息交互。
住院终端接入区
该区域主要是将医院住院部医疗相关的核心业务终端接入医院基础网络，主要包括住院部门的医生工作站，护士工作站，住院部计价终端系统等医疗相关终端系统接入网络，提供住院部医疗终端与数据中心之间的互联互通性，使其能够快速，稳定与数据中心进行信息交互。
医技终端接入区
该区域主要是将医院医技终端接入医院基础网络，主要包括医学影像系统，医疗化验系统，医疗监护系统等。
由于医疗检测相关信息的私密性以及重要性，并且部分医技子系统将产生大流量的数据文件，因此本区域需要保证医技终端与数据中心相关服务器之间的高速数据交互。
无线终端接入区
该区域主要是将无线查房系统，医疗手持终端，无线监护系统等依赖无线网络的系统通过高速可靠的无线接入点，连入医院的基础网络，保证其连接的稳定性以及与数据中心信息交互的高速可靠性，为无线医疗，无线查房，无线监护提供基础支撑环境。
行政终端接入区
将医院的非医疗事务类行政终端接入网络的区域，该区域包含丰富的办公应用，比如OA、邮件、局域网及时通信等。
该区域需要与医疗终端接入区域进行物理隔离或是逻辑隔离，以确保内网数据安全。
其他终端接入区
该区域主要是将，除上述终端以外的一些其他医生所用终端接入网络的区域，这部分终端同时有办公和访问互联网的需求。
如互联网医学资料查询需求等。
内外网融合与内外网分离的网络架构，都应该包含上述功能区域。
只是在定位上，内外网融合的网络架构，将所有功能区域都放到一张网络上，通过二层隔离，三层隔离，安全域划分，MPLSVPN技术等来逻辑隔离网络，保证网络安全。
而内外网分离的物理架构，则是将内网中心服务器区，安全网络管理区，数据灾备区，外联接口区，门诊终端接入区，住院终端接入区，医技终端接入区放在了内网，而将互联网出口区，外网中心服务器区，行政终端区和其他终端区放在了外网，内外网之间物理隔离。
两张网络拥有各自的核心层设备，无共用设备和线路，互不干扰。
内外融合的网络架构设计
篇三：
医院信息集成平台建设方案
信息集成平台建设方案
1建设需求
一个完善的医院信息系统通常由上百个子系统组成，牵涉众多的专业领域。
这么庞大的系统需要非常专业化的软件开发分工，整合不同厂商有特色的专业系统是医院信息系统的发展趋势，医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。
然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经逐渐成为医院数字化发展亟待解决的主要问题。
系统集成平台的构建主要面向两个核心问题：
一个是为各种医疗应用提供统一的医疗数据访问服务，从而消除各种医疗应用系统与医疗数据中心的直接耦合性；另一个是为各种临床信息系统提供系统集成服务，系统集成服务基于系统集成模型，通过HL7和DICOM等标准通讯协议为各种医疗应用系统提供集成服务，确保各个临床信息系统在工作流整合的基础上实现交互协作，从而以数字化的形式完成各项医疗业务。
2建设目标
系统间的整合、集成和扩展一直都是制约医院数字化发展的主要障碍，由于不同厂商之间的产品不兼容，使得医院整体信息化步履维艰。
通过建设一个规范的系统集成平台，在IHE、DICOM、HL7等国际标准的基础上，制定覆盖医疗所有业务流程的系统集成规范，开发基于规范的系统集成平台，为遗留的、当前的以及将来的系统提供了一个统一且标准的数据交换和工作流协同的平台。
3信息集成方法
信息集成方法有三，即应用集成、数据集成、界面集成，这三种集成方式各
解决不同方面的问题。
应用集成指应用程序之间实时或异步交换信息和相互调用功能，可以采用HL7消息，WebService，CORBA，EJB，DCOM，RPC等标准，采用消息中间件，BPM等中间件实现；数据集成是指应用系统的数据库系统之间的数据交换和共享，以及数据之间的映射变换，常采用ETL（Extract-Transform-Load）工具实现；界面集成含义是应用程序界面之间相互关联引用合成，采用技术包括ActiveX插件、Portlet、IFrame等。
协同应用从早期单纯的点对点接口方式，发展到现如今的集成平台方式。
各种方式中：
?
点对点接口方式的复杂性在于要和不同的系统建立1：
N的接口，假定有
N个系统相互之间需要建立接口，则接口数为N*（N-1）/2。
?
集成平台方式中，在N个系统需要进行应用协同的情况下，只需要开发
N个适配器接口即可，减少了集成平台的系统负荷。
由于医院信息系统复杂性，我们根据不同的需求和应用场景，设计分别采用上述三种不同集成方法和手段进行信息集成。
4应用集成
和医技辅诊科室信息系统（如PACS/RIS、LIS、MUSE等）的信息集成，这种场景，信息交互的数据量不大，实时性要求不高，且各信息系统各专业厂商实现方式相差较大，采用基于集成平台的应用集成方式是最优选择。
集成平台体系结构如下图所示，集成平台对外提供支持多种方式的集成服务：
包括WebService服务、TCP监听服务、文件监测服务、FTP服务、SQL监控服务等方式。
医院信息系统在国际、国内广泛采用的有一套集成规范，即：
医疗健康信息集成规范（IHE）规范。
IHE规范未定义新的集成标准，而是采用了“标准协调”过程推动基于工业标准的医疗IT系统互操作性。
在IHE中，消息传递采用的是HL7（版本）标准，影像传递采用DICOM标准。
本集成平台的集成严格参照该规范进行：
信息集成平台在进行消息时采用标准进行消息传递、在消息内部传递DICOMStudyUID，以满足后续DICOM图像应用时的需要。
临床信息集成用于对各临床信息系统进行信息层面的集成事务处理。
事务的定义参照IHE规范执行，消息的交互标准参照HL7标准执行。
集成平台内部引擎本身由Ensemble集成平台基础之上进行二次开发而来，依托Ensemble本身对各种适配器的支持，集成平台对外能够提供多种接入服务方式：
TCP、文件夹监听、FTP文件监听、自定义WebService、SQL监听等形式。
以更多接入方式进行各种不同方式集成各业务系统。
集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。
集成引擎基于标准的业务流程执行语言（BusinessProcessExecutionLanguage）进行扩展应用，以描述交互应用。
信息集成模块与示例
信息集成组件主要由以下几部分组成BusinessService业务服务、BusinessProcess业务处理、BusinessOperation业务操作，这几部分共同作用下，将集成事务与消息传递进行完成。
其中，BusinessService主要负责进行消息的监听与接收；BusinessProcess负责全局的消息路由转发、事务流程处理、消息匹配映射等工作职责；BusinessOperation负责将转换完成、最原子化的一个操作，发送/调用信息集成的目标端。
同时在三者相互作用下，消息的反馈准确的返回到BusinessProcess，由Process来讲反馈消息控制返回到消息发送方。
示意图如下（后续对该示例进行说明）：
业务服务监听与接收
在当今医院中，存在各种各种的医疗业务系统，医疗业务系统的多样性，就将导致与其集成时，接入方式的多样性，如部分系统已实现TCP的发送传递；部分已实现文本输出等。
集成平台作为医院信息系统的中转、适配角色，在接入方式的多样性成为必要条件。
如前所述，在这方面，集成平台允许的接入方式有：
TCP、FILE、FTP、SQL、SOAP（WebService）、HTTP、MAIL等多种方式与相应的适配器。
在多种方式的接入过程中，将不同来源的消息通过统一的出口转交给业务处理部分，由其进行路由住转发、消息匹配映射、业务流程处理等相关的工作。
在本示例中，EMRS通过WebService的服务监听（）方式将消息内容传递进集成平台，在通过验证后，
将该消息转发给了业务处理模块中的路
由模块。
消息路由转发
在一些应用场景中，如电子病历系统、重症监护系统、HIS系统三者进行信息传递时，部分信息是需要三者之间交互的，而部分信息仅仅需要两者之间交互，这在消息转发路由时，需要有一定的控制，起到闸门的作用。
如：
HIS系统进行入院登记时，需要将病人的信息发送到电子病历系统与重症监护系统；而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。
因此，在集成平台中，引入消息路由转发的相关模块就显得比较重要。
在本示例中，EMRCTLRouter这个消息路由者在接受到的消息时，可能会转发至EMRPlaceOrder、EMROrderCA、BadMessageHandle三个相关的处理模块。
而具体转发至何模块，由消息头定义中的相关信息具体定义。
消息路由者起到解析与转发的作用。
事务业务流程处理
即时消息路由已经正确路由转发了消息到准确的端点，但是在对应的端点内，还会有一些业务流程需要进行处理。
如在EMRS下达一个新的Order的时候，需要的一定的情况下产生不同的业务流程分支：
如该病人为门诊病人或者住院病人，则有必要产生HL7消息中的住院病人登记信息与门诊病人登记信息：
ADTA01与ADTA04。
在本示例中，BPEMRPlaceOrder的内部业务流程如下，每一个结点代表着一次逻辑处理过程：
升级会员 