《医院信息集成平台建设技术方案》由会员分享，可在线阅读，更多相关《医院信息集成平台建设技术方案（23页珍藏版）》请在金锄头文库上搜索。
1、-信息集成平台建设方案1 建设需求一个完善的医院信息系统通常由上百个子系统组成， 牵涉众多的专业领域。这么庞大的系统需要非常专业化的软件开发分工，整合不同厂商有特色的专业系统是医院信息系统的发展趋势，医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经逐渐成为医院数字化发展亟待解决的主要问题。系统集成平台的构建主要面向两个核心问题： 一个是为各种医疗应用提供统一的医疗数据访问服务，从而消除各种医疗应用系统与医疗数据中心的直接耦合性；另一个是为各种临床
2、信息系统提供系统集成服务，系统集成服务基于系统集成模型，通过HL7和 DICOM等标准通讯协议为各种医疗应用系统提供集成服务，确保各个临床信息系统在工作流整合的基础上实现交互协作，从而以数字化的形式完成各项医-疗业务。2 建设目标系统间的整合、 集成和扩展一直都是制约医院数字化发展的主要障碍，由于不同厂商之间的产品不兼容，使得医院整体信息化步履维艰。通过建设一个规范的系统集成平台，在 IHE 、DICOM 、HL7 等国际标准的基础上，制定覆盖医疗所有业务流程的系统集成规范，开发基于规范的系统集成平台，为遗留的、当前的以及将来的系统提供了一个统一且标准的数据交换和工作流协同的平台。3 信息集成
3、方法信息集成方法有三，即应用集成、数据集成、界面集成，这三种集成方式各解决不同方面的问题。应用集成指应用程序之间实时或异步交换信息和相互调用功能，可以采用 HL7消息， Web Service ， CORBA ， EJB ，DCOM ， RPC 等标准，采用消息中间件， BPM 等中间件实现；数据集成是指应用系统的数据库系统之间的数据交换和共享，以及数据-之间的映射变换， 常采用 ETL（Extract-Transform-Load）工具实现；界面集成含义是应用程序界面之间相互关联引用合成，采用技术包括ActiveX插件、 Portlet、 IFrame等。协同应用从早期单纯的点对点接口方式，
4、发展到现如今的集成平台方式。各种方式中：?点对点接口方式的复杂性在于要和不同的系统建立1 ：N 的接口，假定有N 个系统相互之间需要建立接口，则接口数为N*(N-1)/2。? 集成平台方式中，在 N 个系统需要进行应用协同的情况下，只需要开发 N 个适配器接口即可，减少了集成平台的系统负荷。由于医院信息系统复杂性， 我们根据不同的需求和应用场景，设计分别采用上述三种不同集成方法和手段进行信息集成。4 应用集成和医技辅诊科室信息系统 （如 PACS/RIS 、LIS 、MUSE等）的信息集成，这种场景，信息交互的数据量不大，实时性要求不高，且各信息系统各专业厂商实现方式相差较大，-采用基于集成平
5、台的应用集成方式是最优选择。集成平台体系结构如下图所示， 集成平台对外提供支持多种方式的集成服务： 包括 WebService 服务、TCP 监听服务、文件监测服务、 FTP 服务、 SQL 监控服务等方式。医院信息系统在国际、国内广泛采用的有一套集成规范，即：医疗健康信息集成规范（IHE ）规范。 IHE 规范未定义新的集成标准，而是采用了“标准协调”过程推动基于工业标准的医疗IT 系统互操作性。在IHE中，消息传递采用的是 HL7 （2.x 版本 )标准，影像传递采用 DICOM 标准。本集成平台的集成严格参照该规范进行：信息集成平台在进行消息时采用 HL72.4 标准进行消息传递、在消息
6、内部传递-DICOMStudyUID，以满足后续DICOM图像应用时的需要。临床信息集成用于对各临床信息系统进行信息层面的集成事务处理。 事务的定义参照 IHE 规范执行， 消息的交互标准参照 HL7 2.4 标准执行。集成平台内部引擎本身由Ensemble集成平台基础之上进行二次开发而来， 依托 Ensemble本身对各种适配器的支持，集成平台对外能够提供多种接入服务方式： TCP 、文件夹监听、 FTP 文件监听、自定义 WebService 、SQL 监听等形式。以更多接入方式进行各种不同方式集成各业务系统。集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。集成引擎基于标准
7、的业务流程执行语言（Business Process Execution Language）进行扩展应用，以描述交互应用。4.1 信息集成模块与示例信息集成组件主要由以下几部分组成Business Service业 务 服 务 、 BusinessProcess业 务 处 理 、 BusinessOperation业务操作，这几部分共同作用下，将集成事务与消息传递进行完成。其中，BusinessService主要负责进-行消息的监听与接收；BusinessProcess负责全局的消息路由转发、事务流程处理、消息匹配映射等工作职责；Business Operation负责将转换完成、最原子化的一
8、个操作，发送 / 调用信息集成的目标端。同时在三者相互作用下，消息的反馈准确的返回到BusinessProcess ，由 Process来讲反馈消息控制返回到消息发送方。示意图如下（后续对该示例进行说明） ：业务服务监听与接收在当今医院中， 存在各种各种的医疗业务系统， 医疗业务系统的多样性，就将导致与其集成时，接入方式的多样性，如部分系统已实现 TCP 的发送传递；部分已实现文本输出等。集成平台作为医院信息系统的中转、适配角色，在接入方式的多样性成为必要条件。如前所述，在这方面，集成平台允许的接入方式有：TCP、FILE 、FTP 、SQL 、-SOAP(WebService)、HTTP 、
9、MAIL等多种方式与相应的适配器。在多种方式的接入过程中，将不同来源的消息通过统一的出口转交给业务处理部分，由其进行路由住转发、消息匹配映射、业务流程处理等相关的工作。在本示例中，EMRS通过WebService的服务监听（ ）方式将消息内容传递进集成平台，在通过验证后，将该消息转发给了业务处理模块中的路由模块。消息路由转发在一些应用场景中，如电子病历系统、重症监护系统、 HIS 系统三者进行信息传递时，部分信息是需要三者之间交互的，而部分信息仅仅需要两者之间交互，这在消息转发路由时，需要有一定的控制，起到闸门的作用。如：HIS 系统进行入院登记时，需要将病人的信息发送到电子病历系统与重症监护
10、系统；而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。因此，在集成平台中，引入消息路由转发的相关模块就显得比较重要。在本示例中， EMRCTLRouter这个消息路由者在接受到的消息时，可能会转发至-EMRPlaceOrder、 EMROrderCA、 BadMessageHandle三个相关的处理模块。而具体转发至何模块，由消息头定义中的相关信息具体定义。消息路由者起到解读与转发的作用。事务业务流程处理即时消息路由已经正确路由转发了消息到准确的端点， 但是在对应的端点内，还会有一些业务流程需要进行处理。如在 EMRS 下达一个新的 Order 的时候，需要的一定
11、的情况下产生不同的业务流程分支：如该病人为门诊病人或者住院病人，则有必要产生 HL7 消息中的住院病人登记信息与门诊病人登记信息： ADTA01 与 ADTA04 。在本示例中， BPEMRPlaceOrder的内部业务流程如下，每一个结点代表着一次逻辑处理过程：-消息匹配映射在一些情况下，消息的传递方并无必要产生HL7 标准格式消息的情况下，如EMRS与集成平台为内部互调时，双-方之间提供预定义的WebService的接口， 以快速的开发与进行集成。此时便需要在WebService中定义的消息格式与标准HL7 消息格式之间进行着匹配转换的工作。而该转换工作的处理调用是由事务业务流程处理模块来发起调用的。终端消息发送在进行正确的消息格式转换与业务逻辑处理， 此时的消息已经成为一个符合终端系统需要的消息格式。在事务业务流程处理中，会将此消息投递给相应的终端系统。在投递消息完成工， 事务业务流程处理模块会进入等待反馈的状况，等待终端系统反馈一个应答消息，以表示该消息在终端系统中被准确的处理。事务处理模块收到该应答消息，
