一種電子病歷系統軟件框架思想

一種電子病歷系統軟件框架思想

袁永福 2016-5-9

 

電子病歷系統到底采用B/S還是C/S架構是一個長期爭論的話題。而在業界兩種架構的應用范圍誰也不占有顯著優勢。

在此筆者提出一種BS和CS混合的架構，以下是其原理圖：

 

在該結構中主要部分有

WEB服務器

這是系統的核心。大多數的業務流程運行在WEB服務器中。采用ASP.NET開發，直連數據庫。

 

WEB服務器包含系統功能 API集合，以遠程調用的方式向PC客戶端軟件提供功能支持。

還包含ASPX頁面，向移動設備提供功能支持。

 

PC機客戶端

PC機客戶端為一個輕量級的客戶端軟件，為一個.NET開發的WinForm軟件。該軟件提供良好的互換性操作體驗，提供各種病歷數據的查看、錄入和打印功能。大多數情況下本軟件只進行簡單的數據轉發功能，基本上不執行具體的業務流程操作。

 

移動設備

移動設備采用瀏覽器形式訪問WEB服務器。

 

數據庫服務器

為一個專門的數據庫服務器，只向WEB服務器開放連接。

 

 

以下是B/S,C/S以及這種混合模式的對比評分表：

 

 

編號	對比項目	滿分	BS	BS 得分	CS	CS 得分	BS和CS混合模式	混合模式 得分	說明
1	離線運行能力	3	無，若系統突然斷網、服務器崩潰，數據全部丟失。	0	有，若系統突然斷網，數據可以緩存到本地，聯網后再保存。	3	有	2	用戶辛苦敲入大段文本，突然斷網了，心情不會好的。
2	頁面狀態數據	1	全靠ASP.NET SESSION，編程比較復雜。	0.5	控制簡單，幾個全局變量即可完成。	1	控制簡單	1
3	頁面間數據傳輸	1	全靠ASP.NET SESSION，編程復雜而且效率低。	0.5	簡單，全局變量，公開的屬性或字段就能實現該功能。	1	簡單	1
4	瀏覽器兼容性問題	3	有，增加開發和維護難度和工作量。	0	無	3	無	3	嚴格限制客戶端瀏覽器版本是一種不友好的行為，有時候會和其他軟件發生沖突。應當盡量避免。
5	本地數據緩存	1.5	無，如果系統配置了知識庫列表，葯品信息列表，ICD數據列表，則需要頻繁的重復下載。	0	有。無需頻繁的重復下載。減少網絡IO負荷和對服務器的依賴。	1.5	有	1.5
6	軟件升級	5	簡單，只要更新服務器軟件即可。	5	必須要更新客戶端軟件，次數多，成本高，影響系統運行。	2	大部分情況下更新服務器即可。少數情況下才需要更新客戶端軟件。	3	目前的各種自動更新技術應該是夠用的，而且電子病歷是院內系統，有一定的控制力度。另外應該是以用戶使用方便為第一，開發和維護人員自己方便為第二。
7	系統配置更改	2	簡單	2	復雜	0	簡單	1.5	比如數據庫服務器換IP了。防火牆修改了。
8	運行速度	4	慢。網絡傳輸速度和客戶端瀏覽器呈現速度比較慢，一般操作都需要幾秒鍾的時間。	2	快，主要受限於網絡傳輸速度。	4	快，主要受限於網絡傳輸速度。	4	對於BS軟件，可能服務器端運行耗時只有幾百毫秒，但在網絡傳輸和瀏覽器展現頁面需要耗掉幾千毫秒。
9	網絡帶寬利用效率	1	低，一般為明文原始格式傳輸	0	高，可以加密壓縮傳輸。	1	高。	1
10	用戶互操作體驗	6	一般。	2	良好	6	良好	6	用戶年復一年的操作這些界面，稍微減少些鼠標鍵盤操作就能產生顯著的效益。另外一些病歷模板工具等軟件模塊基本上只能用CS模式。
11	安全性	1	高。服務器軟件控制好就行了。	1	低。	0.5	高。基本上等於服務器的安全性。	0.5	由於是院內系統，行政管理能幫助進行安全管理。
12	部署	5	簡單。但是如果不得不出現IE嵌控件的形式，則很復雜。	4	復雜，需要配置客戶端運行環境，配置數據庫連接信息。	0	比較復雜。但無需配置數據庫連接信息。	3	可能要用上醫保接口，容易出現IE嵌控件的情況。
13	U盤,K寶等外接設備	2	復雜，需要仔細配置客戶端運行環境，容易出錯。	0	簡單	2	簡單	2	比如用上電子簽章功能，醫生人手一個K寶。
14	打印	2	難於做到精細打印。比如不彈出對話框的打印，指定打印機、紙盒，續打，雙面打印等。	0.5	簡單強大	2	簡單強大	2
15	開發技術	4	復雜。需要C#/HTML/JS的混合編程。對開發人員要求高。調試操作復雜。	1	簡單，統一的WinForm編程模式。	4	較為簡單，ASP.NET和WinForm編程，編程語言統一。	2	開發人才難找，需要降低對開發人員的要求。
16	產品化	1	復雜。	0.5	簡單，可以方便的制作安裝文件和各種配置工具。	1	比較復雜。	0.5	既然以后要向其他醫院推廣，需要考慮到軟件的產品化。
17	數據庫負載	4	良好	4	差，需要創建大量數據庫連接。	0	良好，不直連數據庫。	4
18	災難恢復	5	差，服務器宕機，所有客戶端都不能用。	0	有一定的應付能力。	3	有比較弱的應付能力。	1	電子病歷應該是7X24小時運行的系統。
19	對移動設備的支持	4	良好	4	無	0	良好，仍然提供WEB頁面功能。	3
20	並發控制	1	好	1	一般	0.5	好	1
21	系統伸縮性	1	好	1	差	0	好	1	醫院職工數比較穩定。
22	系統可擴展性	5	好	5	差	1	較好	3.5	醫療需求變更比較大，會比較頻繁的調整的系統功能，對系統可擴展性要求比較高。
23	客戶端硬件要求	4	要求低	4	有一定的要求	1	要求比較低	2
24	服務器端硬件要求	1	要求高	0	要求低	1	要求比較高	0.5
25	操作系統底層功能調用	2	無，HTML/JS權限很低。	0	有	2	有	2	某些情況下需要調用操作系統底層功能。比如不同病人的病歷文本不能相互復制就需要直接訪問系統剪切板。
26	國際化（多語言版本）	0.5	復雜	0	簡單	0.5	簡單	0.5	比如開發繁體中文版，英文版等等。
	滿分	70	BS得分	38	CS得分	41	混合模式得分	52.5

 

 

 

關於這種架構思想的來源，筆者長期做UI層開發，那么就從UI層開始說起。

現在所有的醫療軟件都是圖形化用戶界面，對於C/S程序，寫C#代碼調用DrawString(),DrawLine(),DrawImage()之類的GUI API來繪制用戶界面；而對於B/S程序是服務器端寫代碼輸出HTML代碼，然后發給瀏覽器讓其解釋這個HTML代碼來“繪制”用戶界面。

因此可以抽象出來看，程序猿都是花大量的代碼來繪制圖形化用戶界面，只不過一部分代碼輸出圖形繪制指令，一部分代碼輸出HTML代碼。但最終目的都是一樣的。

另外程序猿還需要寫大量的代碼來讓圖形化用戶界面和用戶互動，都需要響應KeyDown/MouseClick等事件，這點大家的寫的代碼都很類似。最終目標也一樣。

按照這種思想，B/S和C/S的理解可以如下：

C/S程序	數據庫服務器→應用軟件→界面呈現信息（DrawString等指令）→GUI For Windows
B/S程序	數據庫服務器→應用軟件→界面呈現信息（HTML代碼）→GUI For Browser

兩者邏輯上的高度相似性可以很容易聯想到物理學中引力和電磁力邏輯上的高度相似性。物理學中正在謀求統一場理論，那么我們也可以謀求B/S和C/S的統一。

雖然B/S和C/S呈現用戶界面的代碼雖然語言不同、代碼執行的地方不同，但邏輯是相同的，因此邏輯上完全可以統一起來。以此類推，對於業務邏輯執行也是這樣的，這就是B/S和C/S統一的理論基礎，具體表現形式可以是OOP、AOP之類的。

按照B/S,C/S的統一設想，電子病歷系統軟件可以划分為以下幾個部分：

1. 數據庫服務器。SQL SERVER/ORACLE/NOSQL之類的。
2. 業務邏輯執行層。執行醫療業務邏輯的代碼，這個層面純粹執行業務功能，沒有用戶界面。而且考慮到B/S應用應該是多線程安全的。
3. B/S服務器應用層。運行在WEB服務器上的，直接調用業務邏輯執行層來實現業務功能。
4. 遠程調用包裝層。對業務邏輯層執行層的功能進行包裝，能方便的進行遠程調用，這個遠程調用就是基於XML的WebService或者基於二進制的JAVA/.NET Remoting。
5. C/S客戶端軟件。客戶端軟件通過網絡調用遠程調用包裝層來執行業務邏輯。

對於這種架構模型，如果業務邏輯執行層和B/S服務器應用層編譯在一起就是傳統的B/S系統；業務邏輯執行層和C/S客戶端軟件編譯在一起就是傳統的C/S系統。如果5個部分都分開，那么就是同時支持B/S和C/S的，這樣軟件具有強大的擴展性和生命力。

回歸到筆者的老本行，電子病歷編輯器。編輯器控件提供WinForm版本和ASP.NET版本的。WinForm版本支持所有的功能；不過受限於當前技術水平，ASP.NET版本只能只讀的閱讀病歷文檔內容，而無法編輯修改。因此建議在開發常規電子病歷系統時采用C/S模式，對於互聯網應用，比如公衛平台之類的，也是建議新的B/S和C/S統一模式。對於移動應用可以采用傳統B/S模式。

最后想總結一下，孫子兵法又說了：兵勢如水。小平同志的白貓黑貓也是這個理。筆者覺得開發軟件也應該“兵勢如水”，不必拘泥於B/S,C/S之類的條條框框。怎么適合需求就怎么做，靈活變幻開發策略，以最優的路徑做出符合客戶需求的軟件。