力竟成

摘要：門診系統(tǒng)是醫(yī)院信息系統(tǒng)（HIS）的重要組成部分。在門診高峰時期，大并發(fā)量的情況下，出現(xiàn)客戶端網(wǎng)絡(luò)掉線或者樓層交換機損壞，都會極大地影響患者的就診服務(wù)，因此，門診應(yīng)急系統(tǒng)的架構(gòu)設(shè)計是應(yīng)急情況下的關(guān)鍵。該文采取基于客戶端本地緩存以及事后自動重新提交門診業(yè)務(wù)數(shù)據(jù)的原理，設(shè)計出模塊化，可插拔的門診應(yīng)急系統(tǒng)。

關(guān)鍵詞：門診應(yīng)急系統(tǒng)；本地緩存；異步提交；嵌入式數(shù)據(jù)庫

中圖分類號：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

門診通常接診病情較輕的患者，在門診高峰時期，短時間內(nèi)將有大量的患者排隊等待。一旦門診系統(tǒng)發(fā)生故障，造成客戶端無法連接服務(wù)器端(中心數(shù)據(jù)庫服務(wù)器或者應(yīng)用服務(wù)器)，在短時間內(nèi)又無法恢復運行，將對門診就診的正常運行造成混亂，影響醫(yī)院的形象和聲譽[1]。因此，如何設(shè)計好門診應(yīng)急系統(tǒng)，使得系統(tǒng)在部分故障的情況下，仍然能正常運行，最大可能保證業(yè)務(wù)的連續(xù)性，是門診系統(tǒng)可靠性的重要實現(xiàn)部分之一。目前，大部分醫(yī)院使用的門診系統(tǒng)都是從服務(wù)器端實時獲取數(shù)據(jù)。這種獲取數(shù)據(jù)方式的優(yōu)點是數(shù)據(jù)流和控制流邏輯簡單，數(shù)據(jù)準確，實時性強，其缺點是網(wǎng)絡(luò)健壯性差。因為一旦客戶端的網(wǎng)絡(luò)連接中斷，造成客戶端系統(tǒng)業(yè)務(wù)的中斷，故障恢復的時間越長，造成的損失越大。解決此問題的最佳手段就是在客戶端緩存一些關(guān)鍵數(shù)據(jù)，使得斷網(wǎng)的情況下，可以維持主要業(yè)務(wù)流程，比如，患者在掛號應(yīng)急系統(tǒng)下掛號，憑掛號發(fā)票在醫(yī)生工作站就診，順利完成掛號就診活動。在聯(lián)網(wǎng)之后，由后臺自動提交相關(guān)的業(yè)務(wù)數(shù)據(jù)到服務(wù)器端，維持數(shù)據(jù)的一致性。

1基本技術(shù)原理

緩存的第一目的是為了提高數(shù)據(jù)的讀取速度。在大多企業(yè)的現(xiàn)有業(yè)務(wù)系統(tǒng)架構(gòu)下，重要數(shù)據(jù)甚至幾乎所有的數(shù)據(jù)都存儲在數(shù)據(jù)庫中，因此連接客戶端和數(shù)據(jù)庫服務(wù)器或者應(yīng)用服務(wù)器的網(wǎng)絡(luò)，將變成非常重要。其吞吐量，穩(wěn)定性都是業(yè)務(wù)系統(tǒng)流暢運行的重要因素。所以客戶端進行本地緩存，可以減少客戶端與服務(wù)器端的數(shù)據(jù)交互，大大提高程序的性能。

緩存除了可以提高讀取速度外，根據(jù)業(yè)務(wù)規(guī)則，如果設(shè)計的合理，還可以在網(wǎng)絡(luò)中斷的小短時間為客戶端應(yīng)用提供關(guān)鍵業(yè)務(wù)數(shù)據(jù)，使得主要業(yè)務(wù)流程繼續(xù)下去。這一點，在醫(yī)院大門診量下，醫(yī)患關(guān)系緊張的今天，比前面這點更加重要。這一點也是門診應(yīng)急系統(tǒng)的技術(shù)基礎(chǔ)。

緩存有如此重要的優(yōu)點，但其自身也受到CAP原理的制約。具體來說，CAP原理中有三個要素：一致性(Consistency)，可用性(Availability)和分區(qū)容忍性(Partition tolerance)，這三個要素最多只能同時實現(xiàn)兩個，不可能三者都實現(xiàn)[2]。分區(qū)容忍性是分布式系統(tǒng)的基本要求，因此，任何系統(tǒng)架構(gòu)只能在一致性和可用性之間取舍。具體到緩存，就是拋棄關(guān)系數(shù)據(jù)庫般的強一致性，保留高可用性。

盡管緩存拋棄了強一致性，但卻可以保持弱一致性(Weak Consistency)，使系統(tǒng)達到最終一致性(Eventual Consistency)。所謂一致性，或強一致性，就是說更新后的數(shù)據(jù)能被后續(xù)的訪問都能看到。如果能容忍后續(xù)訪問部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時間后能訪問到更新后的數(shù)據(jù)，則是最終一致性。大部分緩存的設(shè)計都是通過失效時間來保持弱一致性，達到最終一致性的。

在斷網(wǎng)的情況下，客戶端提交的數(shù)據(jù)被緩存到本地緩存系統(tǒng)中，在聯(lián)網(wǎng)后，客戶端自動在后臺將這些數(shù)據(jù)異步提交到數(shù)據(jù)庫或者應(yīng)用服務(wù)器。它們通過統(tǒng)籌使用本地資源和到分布式數(shù)據(jù)資源的智能連接，提供適應(yīng)的、快速響應(yīng)的和豐富的交互式體驗[3]。對門診應(yīng)急系統(tǒng)來說，這一步非常關(guān)鍵。緩存可以使得在斷網(wǎng)的情況下，主要業(yè)務(wù)得以繼續(xù)，異步提交使得數(shù)據(jù)得以最終保存在數(shù)據(jù)庫。

2系統(tǒng)整體邏輯架構(gòu)

門診應(yīng)急系統(tǒng)包括幾個子系統(tǒng)，包括本地緩存，嵌入式數(shù)據(jù)庫，異步通信等子系統(tǒng)，其整體邏輯架構(gòu)用下圖表示。

圖1系統(tǒng)整體邏輯架構(gòu)圖

圖1虛線框內(nèi)的就是門診應(yīng)急的重要組成部分，虛線框之外就是現(xiàn)有的兩層或者三層門診系統(tǒng)?，F(xiàn)有門診系統(tǒng)一般是客戶端直接連接數(shù)據(jù)庫或者中間應(yīng)用服務(wù)器進行數(shù)據(jù)傳輸，如果網(wǎng)絡(luò)中斷的話，客戶端中斷與服務(wù)器的聯(lián)系，業(yè)務(wù)也隨之中斷。添加門診應(yīng)急子系統(tǒng)后，盡管網(wǎng)絡(luò)的中斷會造成客戶端和服務(wù)器端的連接中斷，但是，關(guān)鍵的業(yè)務(wù)仍然可以通過門診應(yīng)急子系統(tǒng)繼續(xù)下去。

應(yīng)急系統(tǒng)主要由三大部分組成：本地緩存，通信子系統(tǒng)以及嵌入式數(shù)據(jù)庫。

本地緩存用以緩存斷網(wǎng)時，客戶端業(yè)務(wù)系統(tǒng)繼續(xù)運行下去的關(guān)鍵數(shù)據(jù)。比如，對于掛號子系統(tǒng)，要緩存的關(guān)鍵業(yè)務(wù)數(shù)據(jù)就應(yīng)該包括科室，醫(yī)生，掛號費，診金，醫(yī)生出診時間等；對于醫(yī)生工作站，要緩存的數(shù)據(jù)包括藥品編碼，藥品名稱，藥品規(guī)格，使用方法，庫存余量，藥品價格，還有各種檢查治療項目等基本信息，這些都是支持醫(yī)生就診要使用的最基本數(shù)據(jù)信息；對于收費子系統(tǒng)，藥房配發(fā)藥子系統(tǒng)都有相應(yīng)的基本業(yè)務(wù)數(shù)據(jù)用于緩存。

通信子系統(tǒng)負責將數(shù)據(jù)庫服務(wù)器中的最基本的關(guān)鍵業(yè)務(wù)數(shù)據(jù)異步更新到本地緩存，同時也在斷網(wǎng)的情況下，將客戶端執(zhí)行的業(yè)務(wù)操作異步更新到數(shù)據(jù)庫或者中間層應(yīng)用服務(wù)器。采取后臺異步的方式，是為了不干擾客戶端的正常業(yè)務(wù)操作。

嵌入式數(shù)據(jù)庫，用于存儲斷網(wǎng)后執(zhí)行的業(yè)務(wù)操作數(shù)據(jù)，也用于存儲部分或全部本地緩存數(shù)據(jù)。存儲業(yè)務(wù)操作數(shù)據(jù)，是為了數(shù)據(jù)的持久化，防止業(yè)務(wù)操作的丟失；存儲部分本地緩存，可以存儲較少發(fā)生變化的業(yè)務(wù)數(shù)據(jù)，比如掛號類型，費別等基礎(chǔ)數(shù)據(jù)，這些數(shù)據(jù)庫可以從數(shù)據(jù)庫獲得后，存儲在本地的輕量級數(shù)據(jù)庫。

3業(yè)務(wù)邏輯設(shè)計

門診應(yīng)急系統(tǒng)可以是獨立的一個門診系統(tǒng)，也可以是和現(xiàn)有的門診系統(tǒng)兼容或者整合的一個系統(tǒng)。從業(yè)務(wù)上來說，應(yīng)該整合在一起，作為一個整體的門診系統(tǒng)。門診從業(yè)務(wù)流程上一般可分為掛號，候診，就診，收費，化驗或檢查，取藥最后離院，幾乎每一個子流程都可以成為一個子系統(tǒng)，如掛號子系統(tǒng)，分診子系統(tǒng)，醫(yī)生工作站，收費子系統(tǒng)，配發(fā)藥子系統(tǒng)等。因此，門診應(yīng)急系統(tǒng)也可以按上訴流程分成各個子系統(tǒng)和相應(yīng)的門診子系統(tǒng)進行整合。

本系統(tǒng)利用圖1所示的框架整合各個子系統(tǒng)，下面以掛號子系統(tǒng)為例說明其應(yīng)急系統(tǒng)的業(yè)務(wù)邏輯設(shè)計。

如圖2所示，子系統(tǒng)大概分成三大部分，分別為本地緩存管理CacheManage，通訊管理CommManage以及輕量級嵌入式數(shù)據(jù)庫SQLite，這三個部分互相協(xié)作，共同完成應(yīng)急掛號以及后續(xù)的掛號數(shù)據(jù)異步提交。

4系統(tǒng)設(shè)計實現(xiàn)

門診應(yīng)急系統(tǒng)使用C#做開發(fā)，在客戶端與現(xiàn)有的門診系統(tǒng)能夠較好地整合。本地緩存使用支持分布式緩存的開源Shared? Cache，嵌入式數(shù)據(jù)庫使用開源SQLite的.NET版本System.Data.SQLite，通訊管理啟用異步線程按正常的掛號方式與門診系統(tǒng)中間應(yīng)用層或者數(shù)據(jù)庫通訊。下面是這個門診應(yīng)急系統(tǒng)的一些關(guān)鍵代碼。

1) IDictionary charge = CACHE.SharedCache.RegexGet("pr_*.");獲取某種規(guī)則的處方類型，里面包含了不同處方類型的掛號費和診金

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

3) SQLiteConnection conn = new SQLiteConnection（connStr）;

SQLiteCommand cmd = new SQLiteCommand(sql,conn);

通過執(zhí)行sql語句，從SQLite數(shù)據(jù)庫獲取相應(yīng)數(shù)據(jù)

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

t.Start();調(diào)用CommManage.regist方法，啟動應(yīng)急掛號自動異步提交

5總結(jié)

該文利用開源組件SharedCache實現(xiàn)本地緩存，利用開源嵌入式數(shù)據(jù)庫SQLite以及多線程異步提交數(shù)據(jù)到后臺，設(shè)計了門診應(yīng)急系統(tǒng)的架構(gòu)，相比其他門診系統(tǒng)，在客戶端斷網(wǎng)的情況下，保持業(yè)務(wù)連續(xù)性。整個應(yīng)急系統(tǒng)的架構(gòu)具有良好的穩(wěn)定性，靈活性以及維護性。

參考文獻：

[1]任云華,溫恒彩.加強以病人為中心的門診服務(wù)管理[J].中國衛(wèi)生事業(yè)管理,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.