一、模式

國內電子病歷系統的開發不外2種模式：C/S模式和B/S模式，其中C/S模式一般是以開放的文字編輯器為基礎進行開發，而B/S一般采用頁面填寫模式，也有采用OCX控件模式（這種模式其實也是一種C/S）。兩種模式各有優劣，從我個人角度講，更趨向于C/S（這里是指三層結構的C/S），理由如下：

1、B/S相對于C/S最大優勢在于客戶端免維護，其實C/S做好了，也可以實現自動升級和客戶端免維護，我以前在某地區做的醫保系統，采用三層結構，廣域網上1000多個C/S客戶端，一樣免維護。

2、C/S具有更好的界面操作性，尤其是能夠實現更復雜的界面操作動作，能在一定程度上較好實現自然語言輸入與結構化處理。B/S由于受編輯器功能限制，在文字間相互操作、數據元、各種提示、繪圖處理等方面都存在一定的欠缺。

3、C/S具有更直觀的界面，實現所見即所得模式的書寫，而B/S不采用控件很難做到。

4、C/S具有更好的效率，尤其是在處理和展示大量數據量時，C/S優勢更明顯。B/S模式受服務器和瀏覽器限制，展示大量數據時效率直線下降。我們曾經試過IE同時顯示1000條記錄時，速度慢得讓人無法忍受。

當然具體采用哪種模式，還需要看自己的產品路線及技術沉淀，最好與HIS采用相同模式。由于B/S的電子病歷必需依賴數據庫，正常渠道很難看到，只有在用戶醫院才能匆匆看看，所以下面主要是講C/S模式下的電子病歷編輯控件。

二、功能

C/S模式下，電子病歷系統的核心是電子病歷編輯器控件。有很多文章對電子病歷編輯器控件的功能要求進行了論述，這里只是簡單說明一下。

電子病歷編輯器的功能主要概況為以下幾個方面：

1、文字編寫：這是最基本的要求，細節不多講，按照臨床醫生習慣，最好是所見即所得書寫模式，另外病歷續打是文字編寫功能中必不可少的。

2、數據元管理：按照衛生部要求，電子病歷系統必須能夠實現病歷內容結構化，按照衛生部的數據標準進行管理。電子病歷結構化的目的包括：

　　a)質控要求：要求系統能夠識別和區分病歷內容，針對不同內容按照要求進行書寫限制、時效提醒、病歷自動評分等工作。

　　b)教學要求：書寫病歷除了記錄醫療過程外，還有一個很重要的功能，就是訓練低年資醫生的臨床思維模式。所以電子病歷編輯器要能夠引導書寫者以正確的思維方式完成書寫過程。

　　c)科研要求：臨床科研是為了從病歷中獲取既往醫療數據，其中病歷檢索是一個重要手段。病歷檢索可以采用文字檢索模式，或精確檢索模式，后者需要電子病歷在數據上的完全結構化。

　　目前國內的電子病歷編輯器都是基于文字編輯器開發的，在處理數據元及結構化上存在較大的缺陷。電子病歷數據結構化，不是簡簡簡單將病歷內容分成幾個塊來書寫就行了，必需在一定程度上，對書寫內容進行結構化，區分書寫內容，引導書寫者書寫，并還不能影響其用自然語言的描述。

3、安全管理：按照衛生部要求，電子病歷系統必須能夠實現電子簽名、數據留痕等功能。

三、技術路線

國內已商品化的電子病歷編輯器，從技術路線上講，已知的有以下幾個方向：

1、基于Delphi+RichView開發

RichView是一款基于Delphi的文字編輯控件，開發語言是pascal，收費（$499.00）后提供全部源代碼。利用該控件開發電子病歷的公司包括：病歷寶典、易訊、醫星等產品。

2、基于VC++AbiWord開發

AbiWord是一款開源的文字編輯器控件，開發語言是C++，可以跨平臺運行，含全部源代碼。利用該控件開發電子病歷的公司主要是EMRPad，國內很多HIS廠家產品都是OEM其產品，或在其控件基礎上實現的，如中聯等。

3、基于中標電子病歷控件開發

中標電子病歷控件是近幾年推向電子病歷市場應用的office組件。從文字編輯方面來講，其功能是最完整、最強大的，但該公司最大的缺陷在于自己不是醫療信息化方面的專業廠家，只是文字編輯器控件提供商，電子病歷廠家無法拿到源代碼，分發安裝的文件也很多，幾十兆上百個文件。

4、其他文字編輯器

有一些其他廠商，利用Word、RichEdit、TextControl、scintilla等富文本編輯器在做，總的來講都存在很難結構化處理、續打實現困難、書寫控制困難（如控制復制粘貼、表達式處理等）的問題。還有部分廠家的產品，由于個人能力有限無法看到，所以不好評估。

?

上述觀點僅代表個人意見，若有失公正，敬請指正。

總結

以上是生活随笔為你收集整理的关于国内部分电子病历编辑器的评价的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。