医院数据集成平台与业务系统对接的标准流程.doc

医院数据集成平台与业务系统对接的标准流程

1 　 现状分析 随着公立医院改革的不断深入，医院现有的信息基础架构和业务系统已经无法适应建设精益医院的业务需求，在信息集成和数据分析利用方面更是捉襟见肘。传统的以业务流程为主要驱动的软件开发模式已经难以满足医院数据规划的新要求，医疗信息化建设需要找到一个新的模式。医院信息集成平台已成为跨越临床信息建设障碍的重要支撑，医疗信息化建设正在进行着从业务流程软件系统为核心，逐步转向以数据规划为基础、以集成平台为核心的架构模式。
通过ESB（Enterprise Service Bus）实现业务系统间实时数据交换与共享，使各个应用系统在应用和数据层面形成一体，方便地进行业务协同，消除信息孤岛和协作盲点，同时增加了全院整体系统的灵活性和扩展性。
然而各业务系统由于采用不同的编程语言、不同的操作系统、不同的软件平台，这些业务系统与数据集成平台的对接并非易事。首先，负责对接的工程师不尽相同，彼此对于问题的看法和处理问题的方式各异；其次，由于各业务系统自身的特点，往往先入为主地采用自己比较熟悉的模式来接入集成平台。这两个方面的因素造成了整个集成平台的对接工作繁琐重复、效率低下，而且定位问题的时间加长、难度加大。
因此，为了规范管理系统接入的各个环节，高效地掌控系统接入的完整流程，科学有序地监控并使用这些系统，有必要制定一个合理统一的系统接入方案。通过数据集成平台的实施，做到服务（接口）可管理、可复用、可监控。
2 　方案设计
数据交互平台作为数据交互的重要载体，主要涉及两个大的方面：一是业务系统向数据集成平台发送数据，即平台接收数据；二是数据集成平台向业务系统转发数据，即平台转发数据。而在这两方面的工作中，日志记录都是极其重要的组成部分。因此，在设计数据交互方案时必须加入日志记录功能模块，确保数据交互的日志能够妥善保存，以备查验。同时，为了提高整个系统的健壮性，还须考虑到应急通道的开发，做到主通道瘫痪的情况下，辅助应急通道能够正常工作，满足数据交互的要求。
2.1 业务系统发送数据至平台 各业务系统原理千差万别，采用的架构不尽相同，但对外的数据交互方式与交互数据格式应符合通行规范的标准。为统一规范，各业务系统都必须采用平台认可的统一的发送方式。这里分为两种情况：实时发送和定时轮询抽取。
2.1.1 实时发送 由于本院平台的消息中间件是IBM的WebSphere MQ (Message Queue)，各业务系统要实现实时发送数据，则需要在每个客户端安装MQ的客户端软件，这样既浪费软硬件资源，增加实施工作量，也不利于后期的维护。基于上述考虑，提出了新的框架，如图１所示。 图1 业务系统实时发送数据框架图
从上图中可以看到，整个流程主要由三个模块组成，即客户端，中间件服务器和平台。客户端模块主要完成数据的生成与转换，即产生数据并将其转换成数据交互标准要求的XML文档，接着调用中间件服务器提供的WebService，将XML文档转发到中间件服务器；中间件服务器安装了MQ客户端软件，其首先检查WebService调用的参数格式是否正确，正确的话会返回给客户端一个反馈信息，同时使用MQ方式将XML文件发送到MQ消息队列中供平台接收。同时为了均衡中间件服务器的负载压力，可以采用负载均衡来技术平衡各个服务器的处理量。平台模块采用MQ消息队列方式接收XML文件。
2.1.2 定时轮循发送 定时轮询发送，即业务系统设置轮询周期，定时抽取数据库中的数据并封装成标准XML消息体发送给平台。相应的架构如图2所示。 图2 业务系统轮询发送数据框架图
上图中中间件服务器定时查询数据库，获取数据后，将其转换成数据交互标准要求的XML文档，接着按照MQ的方式将消息体放到相应的消息队列中供平台接收。
2.2 平台发送数据到业务系统 平台给各个业务系统发送数据，采用MQ消息队列的模式，各业务系统根据配置从相应的消息队列里逐个取出消息。该流程相对比较简单，见图3。

图3 业务系统轮询发送数据框架图
各业务系统从相应的消息队列中取出消息并解析，然后存入数据表进行后续的数据处理。
2.3 日志记录 业务系统与集成平台对接的质量还体现在日志记录方面。部分厂商之间的集成没有日志，无法跟踪和监控，彼此之间的信息交互有没有成功难以知晓；增加医院管理的难度，当集成出现问题时，往往很难协调。
因此，对于业务系统发送数据和接收数据，成功或者失败都必须记录日志到日志表中。日志记录可以通过设置开关来控制是否记录交互成功的日志，并根据实际情况在正式上线后关闭开关，即不再记录交互成功的日志，但必须记录交互失败的日志。消息的发送有两种模式，分别为：单次消息发送和批量消息发送。而消息的接收只有单条消息的接收模式。
2.3.1 单次发送或接收 单次发送消息或接收消息，比较简单，相应的流程图如4所示。 图4 单次发送/接收消息流程图
2.3.2 批量发送 批量发送消息时，情况比较复杂。当某条消息发送失败后，记录此条消息的失败日志，同时不影响该批次的后续其它消息的继续发送，即单条消息的发送成败不应影响整个发送队列的发送状况。因此，对于异常情况要充分考虑。具体的流程见图５。

图5 批量发送消息流程图
上面两个方向上的数据交互，日志记录都是极其重要的一个环节，其为系统的稳定运行和消息的可靠传递提供了保障。通常，成功或失败的日志都是记录在数据库的日志表中，但是必须要考虑到一些异常情况，比如数据库死锁，数据库容量撑满，数据库崩溃等等，因此，必须要提供一条应急方式来保证日志记录的完整性，如将日志记录到本地日志文件夹中，以保证日志记录的完整性（见图６）。 图6 日志记录流程图
2.4 应急通道 相比较平台发送消息到业务系统而言，业务系统发送消息到平台涉及的技术环节更多，也更容易发生问题，因此，必须要有一条应急通道以防止主通路发生异常而造成整个数据链路瘫痪，以保证整个系统的安全与稳定。
业务系统应设计一个专门的应急Web Service, 防止数据交互平台出现故障导致业务中断。Web Service输出为对应消息队列所发送的消息，两者格式必须保持一致。Web Service的部署应独立于数据交互平台，同时采用负载均衡技术最大限度确保业务的正常运行转。应急发送模式下也要记录日志，具体的要求可参考2.3小节的日志记录要求（见图７）。

图7 应急WebService方式
3 应用效果

基于以上方案设计，本文选择手麻系统与数据集成平台对接来进行方案的效果验证，本次系统对接首先分析了手麻系统的特点：手麻系统只向数据平台发送数据，不接收平台的数据；手麻系统为C/S架构，相关数据的查询，XML的封装都是在服务器上完成的。基于以上特点，本文确定采用2.1.1小节所述的架构。 考虑到异常情况，手麻系统还开发了应急Web Service通道，以备在主通路瘫痪的情况下担负起继续发送数据的任务。
对于日志记录，本次系统对接也是严格按照上文中关于日志记录的要求进行设计的。此外，还在程序中增加了多处开关，这些开关可以在系统稳定运行后关闭发送成功的日志记录来减轻数据库的负担和压力。目前整个系统工作正常，数据信息完整无缺，每天的发送成功率均为100%。并且，日志记录信息完整无遗漏，具体参看下表1的统计情况，表中部分日期的发送量比较小，是由于周末病员较少的原因。
表1 手麻系统2016年7月1号至2016年7月10号的数据发送统计
4 总结与展望
本文从技术方案角度阐述了平台新接系统的标准流程，这其中包括平台接收消息和平台发送消息两个大的方面。标准流程是简化接入工作的关键和重点，它在接入工作开启之初就从全局上加以管控，明确接入工作的每一个环节。另外，这对于把控工作进度，排查系统对接中出现的错误以及降低后期的运维成本都有着极其重要的作用。目前，本院正陆续接入PETCT系统、急诊系统、眼科PACS、超声等诸多系统，随着越来越多的系统接入，该方案将得到进一步优化调整，这将极大地提高工作效率，使各式各样的接入变得整齐划一，易于监控和管理，也利于工作的延续和传承。
目前很多医院数据集成平台与新系统的对接仅以能够使用为目标，即只要能够和集成平台进行数据交互即可，而没有关注宏观架构和微观细节的处理，因而造成系统对接的模式和细节千差万别、五花八门，致使后期的维护工作繁重而费时，每次问题的定位和修改，都不亚于重新进行一次对接；而另一个方面上来看，系统维护人员也会因为工作岗位的调整而经常的发生变化，每次工作交接都是一件耗时费力的过程。相反，采用本文阐述的标准化系统对接规范，将极大地简化交接流程，加快交接进度，显著提高交接的质量。