门诊应急系统的架构设计与实现

力竟成

摘要：门诊系统是医院信息系统（HIS）的重要组成部分。在门诊高峰时期，大并发量的情况下，出现客户端网络掉线或者楼层交换机损坏，都会极大地影响患者的就诊服务，因此，门诊应急系统的架构设计是应急情况下的关键。该文采取基于客户端本地缓存以及事后自动重新提交门诊业务数据的原理，设计出模块化，可插拔的门诊应急系统。

关键词：门诊应急系统；本地缓存；异步提交；嵌入式数据库

中图分类号：TP319文献标识码：A文章编号：1009-3044(2012)24-5823-03

Architecture Design and Implementation of Outpatient Emergency System

LI Jing-cheng

(The Second Affiliated Hospital of Guangzhou Medical College, GuangZhou 510260，China)

Abstract: The outpatient system is an important part of the Hospital Information System. In the clinic during peak hour, amount concur rency case, appear the client network dropped or floor switches damage, will greatly affect the persons medical service, therefore, outpa tient emergency system architecture design is emergency cases of the key. This paper based on the local cache and the subsequent automatic re-submit the data of outpatient services, designed a modular, pluggable outpatient emergency system

Key words: Outpatient Emergency System; local cache; asynchronous submit; embedded database

门诊通常接诊病情较轻的患者，在门诊高峰时期，短时间内将有大量的患者排队等待。一旦门诊系统发生故障，造成客户端无法连接服务器端(中心数据库服务器或者应用服务器)，在短时间内又无法恢复运行，将对门诊就诊的正常运行造成混乱，影响医院的形象和声誉[1]。因此，如何设计好门诊应急系统，使得系统在部分故障的情况下，仍然能正常运行，最大可能保证业务的连续性，是门诊系统可靠性的重要实现部分之一。目前，大部分医院使用的门诊系统都是从服务器端实时获取数据。这种获取数据方式的优点是数据流和控制流逻辑简单，数据准确，实时性强，其缺点是网络健壮性差。因为一旦客户端的网络连接中断，造成客户端系统业务的中断，故障恢复的时间越长，造成的损失越大。解决此问题的最佳手段就是在客户端缓存一些关键数据，使得断网的情况下，可以维持主要业务流程，比如，患者在挂号应急系统下挂号，凭挂号发票在医生工作站就诊，顺利完成挂号就诊活动。在联网之后，由后台自动提交相关的业务数据到服务器端，维持数据的一致性。

1基本技术原理

缓存的第一目的是为了提高数据的读取速度。在大多企业的现有业务系统架构下，重要数据甚至几乎所有的数据都存储在数据库中，因此连接客户端和数据库服务器或者应用服务器的网络，将变成非常重要。其吞吐量，稳定性都是业务系统流畅运行的重要因素。所以客户端进行本地缓存，可以减少客户端与服务器端的数据交互，大大提高程序的性能。

缓存除了可以提高读取速度外，根据业务规则，如果设计的合理，还可以在网络中断的小短时间为客户端应用提供关键业务数据，使得主要业务流程继续下去。这一点，在医院大门诊量下，医患关系紧张的今天，比前面这点更加重要。这一点也是门诊应急系统的技术基础。

缓存有如此重要的优点，但其自身也受到CAP原理的制约。具体来说，CAP原理中有三个要素：一致性(Consistency)，可用性(Availability)和分区容忍性(Partition tolerance)，这三个要素最多只能同时实现两个，不可能三者都实现[2]。分区容忍性是分布式系统的基本要求，因此，任何系统架构只能在一致性和可用性之间取舍。具体到缓存，就是抛弃关系数据库般的强一致性，保留高可用性。

尽管缓存抛弃了强一致性，但却可以保持弱一致性(Weak Consistency)，使系统达到最终一致性(Eventual Consistency)。所谓一致性，或强一致性，就是说更新后的数据能被后续的访问都能看到。如果能容忍后续访问部分或者全部访问不到，则是弱一致性。如果经过一段时间后能访问到更新后的数据，则是最终一致性。大部分缓存的设计都是通过失效时间来保持弱一致性，达到最终一致性的。

在断网的情况下，客户端提交的数据被缓存到本地缓存系统中，在联网后，客户端自动在后台将这些数据异步提交到数据库或者应用服务器。它们通过统筹使用本地资源和到分布式数据资源的智能连接，提供适应的、快速响应的和丰富的交互式体验[3]。对门诊应急系统来说，这一步非常关键。缓存可以使得在断网的情况下，主要业务得以继续，异步提交使得数据得以最终保存在数据库。

2系统整体逻辑架构

门诊应急系统包括几个子系统，包括本地缓存，嵌入式数据库，异步通信等子系统，其整体逻辑架构用下图表示。

图1系统整体逻辑架构图

图1虚线框内的就是门诊应急的重要组成部分，虚线框之外就是现有的两层或者三层门诊系统。现有门诊系统一般是客户端直接连接数据库或者中间应用服务器进行数据传输，如果网络中断的话，客户端中断与服务器的联系，业务也随之中断。添加门诊应急子系统后，尽管网络的中断会造成客户端和服务器端的连接中断，但是，关键的业务仍然可以通过门诊应急子系统继续下去。

应急系统主要由三大部分组成：本地缓存，通信子系统以及嵌入式数据库。

本地缓存用以缓存断网时，客户端业务系统继续运行下去的关键数据。比如，对于挂号子系统，要缓存的关键业务数据就应该包括科室，医生，挂号费，诊金，医生出诊时间等；对于医生工作站，要缓存的数据包括药品编码，药品名称，药品规格，使用方法，库存余量，药品价格，还有各种检查治疗项目等基本信息，这些都是支持医生就诊要使用的最基本数据信息；对于收费子系统，药房配发药子系统都有相应的基本业务数据用于缓存。

通信子系统负责将数据库服务器中的最基本的关键业务数据异步更新到本地缓存，同时也在断网的情况下，将客户端执行的业务操作异步更新到数据库或者中间层应用服务器。采取后台异步的方式，是为了不干扰客户端的正常业务操作。

嵌入式数据库，用于存储断网后执行的业务操作数据，也用于存储部分或全部本地缓存数据。存储业务操作数据，是为了数据的持久化，防止业务操作的丢失；存储部分本地缓存，可以存储较少发生变化的业务数据，比如挂号类型，费别等基础数据，这些数据库可以从数据库获得后，存储在本地的轻量级数据库。

3业务逻辑设计

门诊应急系统可以是独立的一个门诊系统，也可以是和现有的门诊系统兼容或者整合的一个系统。从业务上来说，应该整合在一起，作为一个整体的门诊系统。门诊从业务流程上一般可分为挂号，候诊，就诊，收费，化验或检查，取药最后离院，几乎每一个子流程都可以成为一个子系统，如挂号子系统，分诊子系统，医生工作站，收费子系统，配发药子系统等。因此，门诊应急系统也可以按上诉流程分成各个子系统和相应的门诊子系统进行整合。

本系统利用图1所示的框架整合各个子系统，下面以挂号子系统为例说明其应急系统的业务逻辑设计。

如图2所示，子系统大概分成三大部分，分别为本地缓存管理CacheManage，通讯管理CommManage以及轻量级嵌入式数据库SQLite，这三个部分互相协作，共同完成应急挂号以及后续的挂号数据异步提交。

4系统设计实现

门诊应急系统使用C#做开发，在客户端与现有的门诊系统能够较好地整合。本地缓存使用支持分布式缓存的开源Shared? Cache，嵌入式数据库使用开源SQLite的.NET版本System.Data.SQLite，通讯管理启用异步线程按正常的挂号方式与门诊系统中间应用层或者数据库通讯。下面是这个门诊应急系统的一些关键代码。

1) IDictionary charge = CACHE.SharedCache.RegexGet("pr_*.");获取某种规则的处方类型，里面包含了不同处方类型的挂号费和诊金

2) CACHE.SharedCache.Add(key,value);向CACHE里面添加缓存信息

3) SQLiteConnection conn = new SQLiteConnection（connStr）;

SQLiteCommand cmd = new SQLiteCommand(sql,conn);

通过执行sql语句，从SQLite数据库获取相应数据

4) Thread t = new Thread(new ThreadStart(CommManage.regist));

t.Start();调用CommManage.regist方法，启动应急挂号自动异步提交

5总结

该文利用开源组件SharedCache实现本地缓存，利用开源嵌入式数据库SQLite以及多线程异步提交数据到后台，设计了门诊应急系统的架构，相比其他门诊系统，在客户端断网的情况下，保持业务连续性。整个应急系统的架构具有良好的稳定性，灵活性以及维护性。

参考文献：

[1]任云华,温恒彩.加强以病人为中心的门诊服务管理[J].中国卫生事业管理,2005,200(2):27-28.

[2] Eric Brewer.Lessons From Giant-Scale Services[C].IEEE Internet Computing July/Aug.2001:46-55.

[3] David Hill, Brenton Webster.Smart Client Architecture and Design Guide[M]. MicroSoft Press,2004:5.