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

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

袁永福 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之類的條條框框。怎麼適合需求就怎麼作，靈活變幻開發策略，以最優的路徑作出符合客戶需求的軟件。