關於國內部分電子病曆編輯器的評價

一、模式

國內電子病曆系統的開發不外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具有更直觀的介面，實現所見即所得 (WYSIWYG)模式的書寫，而B/S不採用控制項很難做到。

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

當然具體採用哪種模式，還需要看自己的產品路線及技術沉澱，最好與HIS採用相同模式。由於B/S的電子病曆必需依賴資料庫，正常渠道很難看到，只有在使用者醫院才能匆匆看看，所以下面主要是講C/S模式下的電子病曆編輯控制項。

二、功能

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

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

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

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等富文字編輯器在做，總的來講都存在很難結構化處理、續打實現困難、書寫控制困難（如控制複製粘貼、運算式處理等）的問題。還有部分廠家的產品，由於個人能力有限無法看到，所以不好評估。

 

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