《医院数据集成平台与业务系统对接的标准流程》由会员分享，可在线阅读，更多相关《医院数据集成平台与业务系统对接的标准流程（7页珍藏版）》请在装配图网上搜索。
1、医院数据集成平台与业务系统对接的标准流程1 现状分析 随着公立医院改革的不断深入，医院现 有的信息基础架构和业务系统已经无法适应建设精益医院 的业务需求，在信息集成和数据分析利用方面更是捉襟见肘。 传统的以业务流程为主要驱动的软件开发模式已经难以满 足医院数据规划的新要求，医疗信息化建设需要找到一个新 的模式。医院信息集成平台已成为跨越临床信息建设障碍的 重要支撑，医疗信息化建设正在进行着从业务流程软件系统 为核心，逐步转向以数据规划为基础、以集成平台为核心的 架构模式。通过 ESB( Enterprise Service Bus )实现业务系统间实时数 据交换与共享，使各个应用系统在应用和数
2、据层面形成一体， 方便地进行业务协同，消除信息孤岛和协作盲点，同时增加 了全院整体系统的灵活性和扩展性。然而各业务系统由于采用不同的编程语言、不同的操作系统、 不同的软件平台，这些业务系统与数据集成平台的对接并非 易事。首先，负责对接的工程师不尽相同，彼此对于问题的 看法和处理问题的方式各异；其次，由于各业务系统自身的 特点，往往先入为主地采用自己比较熟悉的模式来接入集成 平台。这两个方面的因素造成了整个集成平台的对接工作繁 琐重复、效率低下，而且定位问题的时间加长、难度加大。因此，为了规范管理系统接入的各个环节，高效地掌控系统接入的完整流程，科学有序地监控并使用这些系统，有必要 制定一个合理
3、统一的系统接入方案。通过数据集成平台的实 施，做到服务(接口)可管理、可复用、可监控。2 方案设计数据交互平台作为数据交互的重要载体，主要涉及两个大的 方面：一是业务系统向数据集成平台发送数据，即平台接收 数据；二是数据集成平台向业务系统转发数据，即平台转发 数据。而在这两方面的工作中，日志记录都是极其重要的组 成部分。因此，在设计数据交互方案时必须加入日志记录功 能模块，确保数据交互的日志能够妥善保存，以备查验。同 时，为了提高整个系统的健壮性，还须考虑到应急通道的开 发，做到主通道瘫痪的情况下， 辅助应急通道能够正常工作， 满足数据交互的要求。2.1 业务系统发送数据至平台 各业务系统原理
4、千差万别， 采 用的架构不尽相同，但对外的数据交互方式与交互数据格式 应符合通行规范的标准。为统一规范，各业务系统都必须采 用平台认可的统一的发送方式。这里分为两种情况：实时发 送和定时轮询抽取。2.1.1 实时发送 由于本院平台的消息中间件是 IBM 的 WebSphere MQ (Message Queue) ，各业务系统要实现实时 发送数据，则需要在每个客户端安装 MQ 的客户端软件，这 样既浪费软硬件资源，增加实施工作量，也不利于后期的维 护。基于上述考虑，提出了新的框架，如图1所示。 图1业 务系统实时发送数据框架图 从上图中可以看到，整个流程主要由三个模块组成，即客户 端，中间件服
5、务器和平台。客户端模块主要完成数据的生成 与转换， 即产生数据并将其转换成数据交互标准要求的 XML 文档，接着调用中间件服务器提供的 WebService ，将 XML 文档转发到中间件服务器； 中间件服务器安装了 MQ 客户端 软件，其首先检查 WebService 调用的参数格式是否正确， 正确的话会返回给客户端一个反馈信息， 同时使用 MQ 方式 将 XML 文件发送到 MQ 消息队列中供平台接收。同时为了 均衡中间件服务器的负载压力，可以采用负载均衡来技术平 衡各个服务器的处理量。 平台模块采用 MQ 消息队列方式接 收 XML 文件。2.1.2 定时轮循发送 定时轮询发送， 即业务
6、系统设置轮询周 期，定时抽取数据库中的数据并封装成标准 XML 消息体发 送给平台。相应的架构如图 2 所示。 图 2 业务系统轮询发 送数据框架图 上图中中间件服务器定时查询数据库，获取数据后，将其转 换成数据交互标准要求的 XML 文档，接着按照 MQ 的方式 将消息体放到相应的消息队列中供平台接收。2.2 平台发送数据到业务系统 平台给各个业务系统发送数 据，采用 MQ 消息队列的模式，各业务系统根据配置从相应 的消息队列里逐个取出消息。 该流程相对比较简单， 见图 3图 3 业务系统轮询发送数据框架图 各业务系统从相应的消息队列中取出消息并解析，然后存入 数据表进行后续的数据处理。2.
7、3 日志记录 业务系统与集成平台对接的质量还体现在日 志记录方面。部分厂商之间的集成没有日志，无法跟踪和监 控，彼此之间的信息交互有没有成功难以知晓；增加医院管 理的难度，当集成出现问题时，往往很难协调。 因此，对于业务系统发送数据和接收数据，成功或者失败都 必须记录日志到日志表中。日志记录可以通过设置开关来控 制是否记录交互成功的日志，并根据实际情况在正式上线后 关闭开关，即不再记录交互成功的日志，但必须记录交互失 败的日志。消息的发送有两种模式，分别为：单次消息发送 和批量消息发送。而消息的接收只有单条消息的接收模式。2.3.1 单次发送或接收 单次发送消息或接收消息， 比较简单， 相应的
8、流程图如 4 所示。 图 4 单次发送 /接收消息流程图 2.3.2 批量发送 批量发送消息时， 情况比较复杂。 当某条消 息发送失败后，记录此条消息的失败日志，同时不影响该批 次的后续其它消息的继续发送，即单条消息的发送成败不应 影响整个发送队列的发送状况。因此，对于异常情况要充分考虑。具体的流程见图5图 5 批量发送消息流程图 上面两个方向上的数据交互，日志记录都是极其重要的一个 环节，其为系统的稳定运行和消息的可靠传递提供了保障。 通常，成功或失败的日志都是记录在数据库的日志表中，但 是必须要考虑到一些异常情况，比如数据库死锁，数据库容 量撑满，数据库崩溃等等，因此，必须要提供一条应急方
9、式 来保证日志记录的完整性，如将日志记录到本地日志文件夹 中，以保证日志记录的完整性（见图6）。图6日志记录流程图2.4 应急通道 相比较平台发送消息到业务系统而言， 业务系 统发送消息到平台涉及的技术环节更多，也更容易发生问题， 因此，必须要有一条应急通道以防止主通路发生异常而造成 整个数据链路瘫痪，以保证整个系统的安全与稳定。 业务系统应设计一个专门的应急 Web Service, 防止数据交 互平台出现故障导致业务中断。 Web Service 输出为对应消 息队列所发送的消息， 两者格式必须保持一致。 Web Service 的部署应独立于数据交互平台，同时采用负载均衡技术最大 限度确
10、保业务的正常运行转。应急发送模式下也要记录日志， 具体的要求可参考 2.3小节的日志记录要求（见图7）。图 7 应急 WebService 方式3 应用效果 基于以上方案设计，本文选择手麻系统与数据集成平台对接 来进行方案的效果验证，本次系统对接首先分析了手麻系统 的特点：手麻系统只向数据平台发送数据，不接收平台的数 据；手麻系统为 C/S 架构，相关数据的查询， XML 的封装 都是在服务器上完成的。 基于以上特点， 本文确定采用 2.1.1 小节所述的架构。 考虑到异常情况，手麻系统还开发了应 急 Web Service 通道， 以备在主通路瘫痪的情况下担负起继 续发送数据的任务。对于日志
11、记录，本次系统对接也是严格按照上文中关于日志 记录的要求进行设计的。 此外，还在程序中增加了多处开关， 这些开关可以在系统稳定运行后关闭发送成功的日志记录 来减轻数据库的负担和压力。目前整个系统工作正常，数据 信息完整无缺，每天的发送成功率均为 100% 。并且，日志 记录信息完整无遗漏，具体参看下表 1 的统计情况，表中部 分日期的发送量比较小，是由于周末病员较少的原因。表 1 手麻系统 2016 年 7 月 1 号至 2016 年 7 月 10 号的数 据发送统计4 总结与展望 本文从技术方案角度阐述了平台新接系统的标准流程，这其 中包括平台接收消息和平台发送消息两个大的方面。标准流 程是
12、简化接入工作的关键和重点，它在接入工作开启之初就 从全局上加以管控，明确接入工作的每一个环节。另外，这 对于把控工作进度，排查系统对接中出现的错误以及降低后 期的运维成本都有着极其重要的作用。目前，本院正陆续接 入 PETCT 系统、急诊系统、 眼科 PACS 、超声等诸多系统， 随着越来越多的系统接入，该方案将得到进一步优化调整， 这将极大地提高工作效率，使各式各样的接入变得整齐划一， 易于监控和管理，也利于工作的延续和传承。 目前很多医院数据集成平台与新系统的对接仅以能够使用 为目标，即只要能够和集成平台进行数据交互即可，而没有 关注宏观架构和微观细节的处理，因而造成系统对接的模式 和细节千差万别、五花八门，致使后期的维护工作繁重而费 时，每次问题的定位和修改，都不亚于重新进行一次对接； 而另一个方面上来看，系统维护人员也会因为工作岗位的调 整而经常的发生变化，每次工作交接都是一件耗时费力的过 程。相反，采用本文阐述的标准化系统对接规范，将极大地 简化交接流程，加快交接进度，显著提高交接的质量。
医院数据集成平台与业务系统对接的标准流程
