小规模非公有制医院门诊信息系统的应用研究

焦玮, 杨雪寒, 孟洁, 张倩

(河北医科大学第三医院, 河北 石家庄 050051)

0 引言

大型公立医院门诊信息系统大多都是以小型机作为系统平台，采用集中方式进行部署。由于小规模非公有制医院的信息化应用水平有限，采用此类方式建设和部署门诊信息系统将会导致系统建设费用高、系统可运维性不高以及系统可拓展性差等问题，为此本研究采用具有良好可扩展性的分布式系统架构以替代集中式的系统架构建设和部署门诊信息系统[1-3]。本文以河北医科大学附属医院门诊信息系统为例，阐述了以分布式体系架构对现有医院信息系统进行部署的应用实践。所研究的医院信息包括十个子系统，每个子系统之间都存在复杂的逻辑关联以解决门诊、取药、住院等繁杂的业务需求。目的是使用分布式体系架构完成对现有医院信息系统的重构，使其具有满足业务需求的高度可靠性和必要的运行效率。主要研究的是系统中系统消息路由、业务状态以及应用程序数据之间的交互，而不是描述系统的详细实现。通过具体的应用实践对该分布式体系架构的有效性进行必要验证。

1 研究背景和目标

河北医科大学附属医院的医院门诊信息系统具有10多个子系统，如图1所示。

图1 门诊信息系统架构

这些子系统之间存在很多数据交互。当患者在门诊挂号时，门诊子系统可以按挂号订单处理该患者。然后将挂号订单转发到相关子系统以进行进一步的工作。例如，针对患者挂号订单的放射检查指令将通过门诊信息系统的放射子系统转发至放射科信息系统(RIS)。当患者在放射科完成X射线检查后，RIS中将生成一个第三方系统的记录返回给门诊信息系统的放射子系统。许多患者挂号订单需要在子系统和外部第三方系统之间进行状态变更和数据交互，因此门诊信息系统需要灵活的体系结构来解决内部的不同子系统和第三方系统之间频繁的数据交互需求。

一般从三个维度对医院门诊信息系统的性能进行评价：高可用性、高可拓展性和高性能。本研究使用冗余服务器、负载均衡器和应用程序集群来实现这三个性能指标。在传统的集中式系统架构中，门诊信息系统由几个异构操作系统和数据库组成，如OS/390、HP-UX和Windows 2000服务器等操作系统，以及DB2、Sybase和Microsoft SQLServer等数据库[4-5]。在如此复杂的运行环境中显然无法保证系统高度可靠性、数据一致性和良好的系统可扩展性。为此本研究将基于统一的Windows 2003和Oracle RAC对门诊信息系统进行重构，以确保新的门诊信息系统的高度可用性以及不同数据库中数据的一致性。

2 系统架构

本研究选择SOA作为门诊信息系统运行的系统环境。使用基于Web的用户界面构建系统面向终端用户的系统操作交互页面。Web用户界面服务器(WebUI)是为用户浏览器生成系统交网页的服务器。本研究使用Microsoft StateServer[6]来存储来自WebUI的网页会话。身份验证Web服务器(Auth-WS)通过标准SOAP协议[7]为终端用户提供身份验证和授权，并且启用单点登录(SSO)[8]为门诊信息系统提高足够的安全保障。

HL7消息[9]服务器(HL7 Server)也是基于SOAP协议的Web服务。HL7 Server是通过SOAP协议上的HL7消息构建的。门诊信息系统的后端HIS数据库(HIS DB)通过运行Oracle RAC环境以实现高可用性。为了实现数据一致性，门诊信息系统设置了数据交换(DataExchang)服务器。该服务器仅接收从HL7 Server发送的消息。当DataExchang服务器接收消息时，它将执行数据同步作业，例如将患者实验室订单发送到HIS数据库或将新的挂号注册患者数据发送到存储服务器(DB Server)上。此数据交换处理可以确保其他系统中的所有数据都是最新的。门诊信息系统的基本运行逻辑，如图2所示。

图2 门诊信息系统的序列图

由图2可知，门诊信息系统所涉及的服务器包括WebUI、Auth-WS、StateServer、HL7Server、DataExchange和HIS DB。这些服务器为虚拟服务器，且构成了ServerFarms集群网络[10-11]。除HIS DB之外，所有虚拟服务器均具有映射的四层交换机定义的虚拟IP。该集群网络中部署了四台物理服务器，并被配置为以负载平衡模式或故障转移模式运行，以确保系统可用性。为了扩展系统并提高性能，为目标IP地址(如SOAP接口调用、HL7消息接口和DataExchang协议)提供了一个虚拟IP，该虚拟IP也在第4层交换机中定义。每个服务器组在医院内网和ServerFarms集群网络中都有对应的虚拟IP。由于Web服务器或HIS核心服务器以负载平衡模式运行，因此HIS可以将任何已配置的服务器动态添加到ServerFarms集群网络中以处理用户请求[12-13]。如果Web服务器的负担不大，还可以直接从四层交换机配置中删除一些Web服务器。因此，门诊信息系统的维护变得更加容易和有效。硬件架构，如图3所示。

图3 门诊信息系统硬件架构

3 应用结果

河北医科大学附属医院在开展本系统的应用实践。该医院的门诊总数约为180个，但同时开设的门诊科室总数约为150个。大约有40个挂号和收费柜台。同时，病历部门运行着约60个工作站，药房运行着20个工作站，实验室注册站点运行着10个工作站。其他科室和部门中也同时存在运行着少量工作站。因此，该医院全天总共约有500个工作站同时访问门诊信息系统。

经统计，医院一天大约需要为9 000名门诊病人提供服务。这意味着本研究所架构的门诊信息系统应持续、可靠地为500个工作站连接提供服务并处理其访问请求。为此本研究从以下几个方面来评估系统的性能。

3.1 四层交换机TCP连接数

本研究使用多路网络通信量绘图仪来监视四层交换机的运行状态。对四层交换机进行一个星期的性能监视，所得出的各个虚拟服务器的最大会话数，如表1所示。

表1 最大会话数和平均会话数

表1中 “30分钟最大会话数”表示单个虚拟服务器在采样时间中所处理的TCP会话总数。“30分钟平均会话数”表示连续五分钟的六次会话的平均值。

可以得出在一周中四层交换机总会话次数的峰值为1 253。

3.2 WebUI统计

WebUI直接处理用户浏览器请求，然后根据需要处理身份验证调用，HL7 Server 提供SOAP调用和数据交换调用的功能。对于WebUI页面的每个处理时间代表门诊信息系统的响应时间。

本研究通过分析Internet信息服务(IIS)的日志文件以获得Web服务器每天的总请求数和一天中每小时的平均响应时间的统计结果。门诊信息系统由10个子系统组成，所有子系统都部署在20台WebUI服务器中。每个WebUI服务器为10个子系统提供用户界面和交互服务。这10个子系统是门诊管理子系统、门诊子系统、检测子系统、病理子系统、传染病报告子系统、病历管理子系统、门诊调度管理子系统、放射科子系统、门诊计费子系统和药房管理子系统。每个子系统都有不同的用户请求和数据交换操作。下面就门诊管理子系统、诊所子系统、门诊计费子系统和总体统计结果进行具体阐述。

1)当日总请求数和平均响应时间的统计。以门诊管理子系统为例，该子系统处理患者挂号、挂号查询、挂号更新、查询患者数据、患者数据更新和其他一些用于挂号和维护患者数据的辅助功能。对门诊管理子系统的Web请求的统计数据，如表2所示。

表2 门诊管理子系统的请求IP总数

由表2可知，全天一共有172个客户端访问门诊管理子系统，该子系统全天约有2.4万个网页请求。

门诊子系统一天内有将近28万个页面请求。 在门诊HIS中，它占所有请求的69%。门诊子系统也是使用最多的子系统。每天大约有600个用户客户端访问诊所子系统。这意味着一天中将近70%的HIS用户使用门诊子系统。

对于一天中的平均响应时间，如表3所示。

表3 WebUI的响应时间

由表3可知，诊所子系统的平均响应时间为0.562 s，标准偏差为1.145 s，最大响应时间为154 s(154 s的响应时间也是所有子系统中最大的时间成本)。在长页面执行中应该存在一些编程或数据访问问题。页面响应时间长，可以帮助发现门诊信息系统中潜在的编程问题。所有子系统请求的平均响应时间为0.566 s，标准偏差为1.250 s。

2)全天中每小时的统计信息。为了评估请求和响应时间，本研究统计了当天的每小时总请求数和平均响应时间，如图4所示。

图4 门诊子系统的平均响应时间

在诊所子系统中，从07:00到20:00的平均响应时间不到1 s，如图5所示。

图5 诊所子系统的总访问请求数

早晨的高峰请求是10:00到11:00，大约有40 000个请求。从14:00到15:00是下午的高峰请求，大约有37 000个请求，如图6、图7所示。

图6 门诊管理子系统的平均响应时间

图7 门诊管理子系统的总访问请求数

显示了门诊管理子系统的总请求数和平均响应时间。门诊计费子系统的总请求数和平均响应时间，如图8、图9所示。

图8 门诊计费子系统的平均响应时间

图9 门诊计费子系统的总访问请求数

这两个子系统在07:00至20:00的平均响应时间约为1 s，而在07:00之前和20:00之后的平均响应时间有所不同。

4 结果讨论

本研究所重构的门诊信息系统中运行着20台WebUI服务器和20台HL7消息服务器。在应用实践中对四层交换机和WebUI的响应时间和会话数量进行统计和汇总，以验证系统的性能。其中WebUI响应时间包括服务器场中的后端操作，例如身份验证、基于SOAP协议的HL7消息接口调用和数据交换操作。

每小时响应时间和会话数统计结果表明，门诊信息系统的响应时间在07:00和20:00之间比较稳定，在负载较重的门诊子系统和计费子系统中也是如此。在上午10:00和下午15:00的高峰时段，整个门诊信息系统能够保持稳定运行，响应时间约为1 s。这意味着所架构的门诊信息系统具有较好负载响应性能。

响应时间在上午07:00之前和下午20:00之后出现变化的原因是，当子系统当前没有加载至内存中时， WebUI应用程序需要时间来缓存数据库中的一些常用数据。从上午00:00到上午07:00的门诊管理响应时间在0.6～1.23 s之间有很大差异，这是因为一些患者在午夜从医院急诊信息系统中进行门诊挂号操作，这导致响应时间较长。此外，门诊信息系统会在连续20分钟内没有访问请求的时候基于IIS对子系统进行内存回收，子系统的回收和启动会产生响应时间变长。

5 总结

本文通过分布式体系架构对基于小型机集中部署的门诊信息系统进行了重构。在分布式体系架构中，门诊信息系统可以实现数据高效交换和保持多个系统之间的数据一致性。该体系架构使用四层交换机作为服务器集群的负载平衡器，为门诊信息系统提供了高可用性和可拓展性。在该体系架构中，可以将已配置的服务器动态添加到ServerFarms中，为门诊信息系统提供良好的可拓展性能。本文通过应用实践获得了包含四层交换机和WebUI的会话数和响应实践的统计数据。 统计结果表明，基于SOA和分布式体系架构的门诊信息系统能够在负载较重的实际环境提供较好系统响应性能。