電子病歷編輯器，簡稱EMRE（EMR Editor）。EMRE是電子病歷系統的核心關鍵基礎技術。在HIT大市場中，EMRE已經是一個專業子市場。為什么會形成這個子市場，筆者在此討論一番。

論電子病歷文本編輯器

袁永福

28348092@qq.com

http://www.dcwriter.cn

2013-5-12

 

前言

受chisc.net網站的邀請，特撰此文，一家之言，如果有不妥，敬請指出。

 

作者簡介

袁永福，2001年東南大學畢業，從事IT十多年，2008年度微軟MVP，著書立說。現在南京從事電子病歷編輯器相關工作。博客網址http://www.rzrgm.cn/xdesigner。

電子病歷文本編輯器概述

電子病歷編輯器，簡稱EMRE（EMR Editor）。EMRE是電子病歷系統的核心關鍵基礎技術。在HIT大市場中，EMRE已經是一個專業子市場。為什么會形成這個子市場，筆者在此討論一番。

其實觀察整個醫療行業，所有的人都是圍繞著治病救人這個中心而忙碌著，無論是衛生系統的官員、醫院各級管理人員、醫務人員、各級醫療服務單位，還有我們這么多的HIT企業等等都是的。如果人不生病，全球立馬有幾千萬人失業。

在醫生治病救人的過程中會產生大量的信息，這些信息中最為重要的就是病歷，如果沒有這些病歷，診療過程就成為低水平的重復又重復，很多的涉及到生命的資料無從可查。因此病歷信息是整個醫療信息化中的核心信息。數據庫存儲的是病歷數據、網絡傳輸的是病歷數據、終端顯示的是病歷數據、打印機輸出的是病歷數據、后臺分析的是病歷數據、醫療司法活動的基礎證據也是病歷數據。

這里的病歷數據范圍比較廣，包括各種病歷文書、醫學影像、檢查檢驗結果等等。從HIT系統應用的角度上來說，各種類型的病歷數據處理手段不一樣，從而形成各個子市場。

比如醫學影像數據的處理比較專業，由此形成PACS子市場，里面已經有很多廠家，甚至還形成了醫學顯示器這種微市場。那里的人賣硬件賣軟件，生意興隆。

病歷文書數據也是病歷數據中的一個關鍵數據，也是應用最為頻繁的數據。畢竟一個人看病，可以不拍片子、不檢驗檢查，但醫生肯定會寫下一段文本病歷。PACS系統折騰一番生成的高清圖像也只是在醫生診療過程中作為參考，關鍵還是醫生寫下的病歷文本。

因此在目前的階段，所有的診療過程產生的最為關鍵的信息是病歷文書。

因此在醫學信息化中，病歷文書是作為最為重要的信息是需要得到最為特別的照顧。

在過去的傳統HIS階段，應用系統對病歷文書的照顧就是一個最簡單的TextBox，高級一點的用上MS WORD。不過這顯然是遠遠不夠的，那樣做不是與時俱進，而且HIT客戶已經越來越專業越挑剔了。

理論上來說，醫生拿著菜刀也能做手術，實際上那將是非常恐怖的事情。但實際上，很多醫生還是拿著菜刀寫病歷，而專業的EMRE就是醫生寫病歷時的上好工具。

EMRE子市場

現今開發和使用電子病歷系統不可避免的要使用到EMRE，這基本上是繞不過去的。對于EMRE，軟件開發公司主要有自行開發和對外采購的方式來獲得。

開發EMRE的技術那是老復雜了，難度是非常非常高，業界能開發編輯器的人才鳳毛麟角。因此一些HIT業務型軟件公司自主研發EMRE那是勇氣可嘉的，至于能否成功那只能是盡力而為了。

筆者的觀察中大多數軟件公司是搞不定自主研發EMRE的，經過一番折騰，弄得頭破血流的，最后還是轉而尋求外購EMRE。于是就形成了非常專業的EMRE子市場。

EMRE子市場不大，但由于掌握了技術高地，因此在HIT大市場中是還是比較關鍵的。大家討論電子病歷系統時必然會提到這個系統中使用的EMRE。大家所說的病歷控件基本上就是指電子病歷文本編輯器控件。

很多HIT企業在外購EMRE時都想同時購買源代碼，筆者覺得這是不現實的也是沒有多少實際意義的。

目前的EMRE企業基本上是不會出售源代碼的，這事關中國國情，大家都懂的。通過非正常途徑獲得的源代碼，那是有相當的法律風險，因為國內HIT圈子不算大，有一定的風險被EMRE廠家發現，引起糾紛，而且不管結局如何，醫院甲方都會有想法的。

也存在個人出售編輯器代碼，很有可能是網絡上已經流傳的代碼，特別是ZYTextDocumentLib的源代碼。筆者覺得這對于正規的HIT企業來說沒多大作用，因為改造這些代碼并進行二次開發的過程差不多等于走回自主研發EMRE的老路。

另外購買編輯器代碼并沒有多少實際意義。HIT企業購買代碼無非擔心EMRE企業倒閉轉行，使得編輯器無法更新換代。根據筆者觀察，現實中HIT企業的管理者會讓程序猿們時刻忙于項目，天天干活，特別是高級程序猿更是忙得團團轉；此時高級程序猿不會有大把的時間認真系統的消化吸收編輯器代碼的，而初級程序猿是沒有相關能力的。因此如果編輯器有BUG或者新功能需求，基本上還是要找EMRE企業。

這就是即使是東軟這樣的HIT巨頭也沒有自主研發EMRE控件的原因之一。

另外EMRE企業之所以成立，也必然有相應的技術力量，否則接下EMRE這種重活是害人害己。

另外EMRE企業相比于HIT企業更不在乎企業的規模。HIT業務型企業天天拉單子做項目，實施一個有點規模的醫院的HIS/EMR，沒有個一年半載是搞不定的，大批人員駐場開發那是常見，常年的駐點運維工程師也是常有的。因此HIT企業雖然人多有規模，當幾個項目同時運行時還是會人手不夠。

但EMRE企業不一樣，它是做通用產品的，它的客戶都是懂技術的，技術人員之間的溝通交流速度是很快的，而且所有HIT企業對于EMRE的需求的交集是不大的，無需大型團隊來應付。EMRE企業專注于特定技術鉆研，更在乎人員的精干而不是數量。因此小規模企業也能勝任EMRE業務。

實施HIT項目時，接口工作量不小。現在很多醫院的系統都是萬國系統，各種牌子的系統糾纏在一起，產生了大量的軟件和硬件接口需求，各個HIT企業、甲方內部小集團之間還存在互掐的現象；此外還有醫保銀行相關的接口，這些接口工作也耗掉了不少HIT企業的精力。

相比而言EMRE企業的接口工作量少的多。技術上EMRE企業是強勢的，HIT企業必須使用EMRE企業制定的開發接口。就這點而言，EMRE企業能省掉不少人力。

這些原因使得HIT企業可以追求做大或做強，但EMRE企業必然是追求做強而不是做大。

EMRE控件產品及技術路線介紹

目前業界存在一些EMRE控件產品及技術路線，在此介紹幾種常見的：

基于標準TextBox控件進行開發

基于TextBox控件來開發EMRE那是最為原始最為簡單的方式。比如在用戶界面上，放一個“主訴”文本標簽，后面跟著一個TextBox用于手動錄入主訴文本，現病史也類似。在存儲上，可能是主訴內容存一個文本型字段，現病史內容存一個文本型字段。

這種方式實現簡單，幾十年前就出現了，但現在早就OUT了，若還拿出來都不好意思見人了。

基于RichTextBox控件進行開發

很多開發工具提供一個RichTextBox控件，實際上就是Windows自帶的RichTextBox控件的簡單包裝。

使用RichTextBox控件能實現一些格式文本的編輯、錄入，文字格式的設置，能插入圖片，簡單的表格。

不過基于RichTextBox控件進行一些深入的開發就不行了。比如留痕、續打、知識庫等等，此時一些開發企業就騎虎難下了，終究是要放棄的。

基于MS WORD進行開發

         一些EMRE是基于MS WORD進行開發。其優點如下：

1.       MS WORD的文檔編輯器功能是任何其他文本編輯器所無法逾越的。文字、圖片、表格等等都是至尊級的，而且MS WORD應用廣泛，群眾基礎好。基于它開發，在文檔編輯用戶體驗上來說，用戶是很容易接受的。

2.       MS WORD的二次開發接口比較多，各種支持COM的開發工具都支持。而且MS WORD的開發學習資源比較豐富，網上能找到很多。

不過使用MS WORD進行開發也有不少缺點：

1.       MS WORD不是免費軟件，使用它必須購買一個完整的MS Office軟件包，這是一筆不小的版權費用。醫院可能拒絕使用盜版MS WORD，此時會比較大的增加項目成本。比如有微軟經銷商報價MS OFFICE2010為4000元/套。這樣就很不利于HIT企業市場銷售。

2.       客戶端電腦必須逐個安裝MS WORD，部署工作量比較大。而且不同版本的MS WORD的開發接口存在一定的兼容性問題，增加軟件開發、部署和調試的難度。比如不同的客戶已經安裝了WORD2003、WORD2007、WORD2010等等，此時麻煩不小。

3.       MS WORD開發是基于OLE自動化技術，使用了跨進程的操作，操作不當系統中會留下MS WORD的進程，容易資源泄露，因此一般避免在服務器端使用MS WORD。

4.       大量的電子病歷特定業務功能使用MS WORD是無法實現或者很難實現的。比如痕跡保留和三級權限控制；半結構化；續打、整潔打印和留痕打印；對于B/S系統，如何將MS WORD文件傳到服務器上也是個難題；難于實現知識庫。而且生成的WORD文件格式復雜難于解析，難于進行統計分析。

基于MS WORD開發電子病歷編輯器可以在某些情況下應急，但由于上述無法解決的缺陷，從長遠上來說是不可取的，終究是要放棄這種方式的。

基于開源DELPHI的TX控件進行開發

TX控件以前是一個免費開源的DELPHI控件，現在作者據此成立公司不再免費開源了。TX控件是用DELPHI開發的，有COM接口。因此很適合DELPHI或VB/PB的開發。

業界還有大量的已經運行中的信息化系統是由PB/VB/DELPHI開發的，而且還有一些新系統也是靠這些老技術開發的。因此業界還存在不少使用TX開發的EMRE控件。

使用TX控件開發編輯器控件，能輕松的實現常規的文檔編輯功能，比如圖文混排、表格、圖片等等。不過想要開發超出TX控件能力范圍而實現新的文檔編輯功能就非常難了。比如表格線上下拖拽調整表格行高度、續打等等。

另外TX控件是通用文檔編輯器控件，而電子病歷行業很多特種業務需求就很難實現。有些雞肋。

為實現電子病歷行業特定需求，需要在TX基礎上開發重大新功能，這需要深入理解TX的內部結構。只要是帶格式文檔編輯器控件都是非常復雜的，理解起來那是相當難的，而且現在的DELPHI熟練程序員越來越少，因此對于基于TX開發編輯器的廠商，許多電子病歷業務特定功能很難實現或者基本上是不可能實現。

HIT企業可以向TX供應商申請加功能，不過HIT行業只是TX供應商的市場的一部分，人家或許不在乎為這點市場而大改TX控件，因此進展緩慢。

另外DELPHI本身也是一項老技術，雖然還能用于開發一些新系統，不過相關人才會越來越少，系統維護將逐漸成為一個大問題。筆者覺得此時不未雨綢繆搞轉型，以后想轉就來不及了。

易訊電子病歷編輯器

易訊電子病歷編輯器是天方達軟件開發有限公司的產品，其軟件界面如下：

 

技術分析易迅電子病歷編輯器應該是Delphi開發的，可能是在TRichViewEdit的基礎上進行二次開發的。支持自由的文檔編輯，支持表格。控件程序文件大小為10MB。

易迅電子病歷編輯器在常規的文檔編輯器功能是差不多夠用了，但有些功能做得還不夠，在此挑出幾個：

1.       談不上支持半結構化技術。未發現支持XML技術。

2.       單元格無法單獨的設置寬度，當編輯復雜表格布局時比較費勁。

3.       開發幫助文檔太簡單了。

4.       文字排版無法兩端對齊，文字右邊緣層次不齊，影響美觀。

5.       圖片可以編輯后無法修改已經改過的內容，無法撤銷。

易訊編輯器的東家天方達公司還據此經營著一個電子病歷文檔的網絡社區。任何人注冊就可以上傳和下載電子病歷文檔范文，這是他們的一個不錯的特色。這里是病歷文檔范文，還談不上是病歷文檔模板。

病歷寶典

病歷寶典軟件是北京華信慧典科技有限公司研發的電子病歷編輯器。其用戶界面如下：

 

該軟件也應該是使用Delphi基于TRichViewEdit開發的。相比易迅病歷編輯器，其功能改善了不少，主要有：

1.       總體感覺用戶界面比易迅編輯器要現代多了。相比而言易迅編輯器的用戶界面還是比較粗糙的。

2.       能進行文字的兩邊對齊了。

3.       增強了醫學表達式。

筆者測試的是《慧典電子病歷系統學習版》，這個版本有一個很要命的缺點，那就是當該軟件顯示對話框，比如插入表格對話框時，在Win7環境下，切換到其他程序后在切換回來，對話框將隱藏在主窗體后面，此時應用程序根本無法操作，只能強制殺進程。

由于是未注冊版本，無法判斷是否真的支持半結構化文檔等重要功能。

初步感覺易迅編輯器和病歷寶典編輯器存在微妙的關系，這不僅僅是共同是基于TRichViewEdit開發的原因。因為筆者發現這兩個編輯器很多細節是高度一致的，猜測兩者應該共享很多代碼吧。

病歷寶典的編輯器是不單獨銷售的，是集成在慧典電子病歷系統中的，因此HIT企業不能指望它了。

基于開源OpenOffice進行開發

也有HIT企業在著名的開源OpenOffice的基礎開發電子病歷編輯器，OpenOffice保存的文件擴展名默認為odt（或ods,odp），這種文件實際上是ZIP格式，可以將odt擴展名改成ZIP，雙擊即可使用WinRAR打開。
使用OpenOffice進行開發的風險比Delphi開源控件為基礎的高得多。因為OpenOffice比其他任何開源控件要復雜得多，底層程序基本上無人可以修改。

OpenOffice最早可追朔至1980年代，多次易主，現在歸ORACLE所有。經過30多年的發展，已經包含1000多萬行C++/Java混合代碼，源代碼文件有1.6GB大小，其中的功能模塊不計其數，組件引用網格非常復雜，真是牽一發而動全身，為此歷史上遺留下來了一些無法剔除的垃圾模塊。下圖就是OpenOffice中各個功能模塊的引用關系圖：

 

如此復雜的內部結構，使得OpenOffice確實能拿過來就能用，但基本上無法修改。只能在表面上做一些盡力而為的事情了。

另外其他的編輯器是輕量級的控件，程序文件都不大，而且是從用戶界面上還是運行架構上都能緊密嵌入在應用程序中的。

但OpenOffice則是重型辦公軟件包而不是控件，功能齊全、文件數量多、體積龐大，精簡下來也有近百MB大小，用于B/S開發時需要謹慎。

而且從運行架構上，OpenOffice的文檔編輯用戶界面雖然能嵌入到應用程序中，但后臺還是跑著編輯器的獨立進程soffice.exe/soffice.bin，出現了復雜易錯的跨進程操作，應用程序有時候需要強制殺掉OpenOffice進程，這對操作系統運行環境比較傷。因此說基于OpenOffice開發的不是控件，而是軟件包的二次開發。這點很類似MS WORD。

OpenOffice體積龐大的另一個原因就是為了實現跨平臺的，它能運行在Windows/Linux/Mac OS/Solaris等多種操作系統，支持各種接口和規范。而國內電子病歷客戶端基本上都是MS Windows平臺，OpenOffice的這些跨平臺的功能對于EMR用戶來說就是畫蛇添足的了。

使用OpenOffce比MS WORD相比唯一的好處就是OpenOffice是自由軟件的，沒有版權現金成本，其開源的特性對于HIT企業來說其實是沒啥實際作用，就跟小學生學奧數一樣。OpenOffice文檔編輯功能也很強大，但還是無法達到MS WORD的那種至尊境界。

使用OpenOffice會涉及到它的版權問題，中國國情是不尊重版權的，比如有些IT企業（特別是政績企業）把OpenOffice或者開源操作系統簡單封裝一下，然后聲稱國產原創，跑到政府面前邀功套現套證書。

不過在此還是提一下OpenOffice的版權，以下內容摘自百度百科http://baike.baidu.com/view/406051.htm。

OpenOffice org采用GNU通用公共許可證（GPL）和Sun工業標準源碼許可證（Sun Industry Standards Source License，SISSL）8的“雙許可證”方式對源碼進行許可；采用獨立的公共文檔許可證9（Public Documentation License，PDL）對發布在OpenOffice org網站上、但不期望集成進軟件的絕大多數文檔進行許可。 “雙許可證”方式意味著要么應用GNU GPL許可證，要么應用SISSL許可證。當應用GPL許可證的時候，OpenOffice org源碼中的庫和組件功能將根據GNU LGPL進行許可。由于LGPL與GPL完全兼容，這樣就能夠鼓勵更多的人參與到OpenOffice org社區建設中來。 SISSL則是為商業應用設計的。由于GPL許可證對于自由復制、修改、發布等權利的嚴格保證，某些軟件商會因此而受限、不能參與到開放源碼社區中來。OpenOffice org的雙許可證方式解決了這個問題，他們可以選擇根據SISSL進行許可。SISSL是經過開放源碼促進會（Open Source Initiative，OSI）確認的開放源碼許可證10，它規定在被許可者承諾保證“標準”一致的條件下，可以分發軟件但不公開修改過的源代碼。這里的“標準”是指OpenOffice org的XML文件格式規范11，和OpenOffice org的應用程序接口規范12。

由于這個授權限制，使得基于OpenOffice開發自定義的適合電子病歷業務需求的XML文檔格式從授權上是違反的，從技術上是不可行的。

EMRPad

由于基于開源軟件而開發EMRE困難重重，于是國內有人開始自主研發編輯器了。其中最為著名的是陳聯忠開發的EMRPad了。

陳聯忠陳老師，技術達人，我等程序猿的楷模。中國最早做出了比較實用的電子病歷編輯器EMRPad，該軟件2006年被北京嘉和美康信息技術有限公司收購，從此不再獨行于江湖。

可以說，嘉和公司的壯大，陳老師的編輯器出力不少。當年該編輯器提出了很多目前業界關于編輯器的標準功能，主要有：

1.       半結構化文檔。將所謂的元素（也稱輸入域、關鍵字）和普通文本自由混排。實現全結構化文檔和自由文本的混合。這樣提供比較好的用戶體驗，而且也大大便利的程序對病歷數據的處理。

2.       XML存儲。將病歷文檔以純XML的方式進行存儲。而且文檔內容和排版樣式控制信息存在一個文件中。

3.       增強打印。包括續打、留痕打印和清潔打印。

4.       三級查房權限控制。

由于嘉和公司收購陳老師的編輯器，因此編輯器不會再單獨對外銷售了，不過奇怪的是，還是有傳聞有單獨銷售的，不知是真是假。

陳老師現在任嘉和公司CTO，應該是專注于電子病歷系統的大的框架性的研發，焦點可能已經不在編輯器上面了。不過這些對于廣大的需要編輯器的HIT企業來說沒啥關系了。

ZYTextDocumentLib系列編輯器

在國內HIT業界還流傳著ZYTextDocumentLib的病歷編輯器及其衍生版本，有一些HIT企業和個人使用這種編輯器。該編輯器用戶界面大致如下：

 

這種編輯器是使用C#1.1開發的，業界有源代碼流傳。其程序文件名為ZYTextDocumentLib.dll或變體。

這種編輯器是采用完全的XML存儲格式，其最大的特點就是XML根節點名稱為“emrtextdoc”。這種編輯器初步實現了半結構化的編輯和存儲，支持知識庫，還有痕跡保留功能，有些衍生版本支持簡單的表格。

不過該軟件運行還不穩定，容易出錯，功能也有不少欠缺。不建議使用。

DCWriter的編輯器

DCWriter編輯器是南京都昌信息科技有限公司的產品。其界面如下：

 

它是C#開發的，還提供COM接口，可用于VB/DELPHI之類的開發。該款編輯器功能還是非常全面的。比如續打，留痕打印，痕跡保留，三級權限控制，知識庫，級聯模板，醫學表達式，條碼等等。雖然功能多，但程序文件只有3MB大小，不依賴第三方組件，因此也適用于B/S開發。

該編輯器表格功能比較突出，相比其他編輯器而且已經比較接近于WORD的表格功能了，能實現標題行、單獨的設置單元格的寬度，能方便的進行復雜表格的排版。而且單元格內部可以加上網格線，很容易實現護理記錄的特殊文檔樣式。

另外對于.NET開發者，該編輯器提供DOM模式的文檔內容開發接口，使得開發者能詳細控制文檔內容的各種細節內容，甚至派生出自定義的文檔元素類型；而且DOM式的接口可用于非GUI程序的開發，能用于ASP.NET服務器端程序、命令行和Windows Service程序的開發。

此外文檔中還能嵌入.NET控件和WPF控件，實現了編輯器包含業務的軟件架構。因此對于.NET開發，在諸多EMRE控件中，DCWriter是首選。

在用戶界面上，該編輯器的知識庫采用彈出列表的方式顯示，并使用拼音碼檢索然后插入，彈出式列表的用戶界面相比對話框的方式能較少的干擾使用者的思路。

該編輯器支持半結構化文檔，病歷文件就是XML格式。程序可以直接快速處理病歷XML文件。

它對衛生部的電子病歷系統功能規范支持得很不錯。

另外該編輯器的文檔寫得很詳細，用戶手冊有300多頁13萬字，事無巨細的說明了該編輯器的所有細節內容。此外還有類似MSDN的那種開發SDK文檔。

DCWriter和ZYTextDocumentLib存在一些關系，DCWriter完全兼容ZYTextDocumentLib生成的電子病歷文檔。而且由于DCWriter采用開放的軟件接口架構，加上適配器即可直接加載其他編輯器生成的病歷文檔。

理想EMRE功能需求

根據作者的實踐，列出比較理想的PC版EMRE的功能需求

文檔編輯功能需求

1.       文字編輯：可自由輸入文字，可設置文字的字體名稱、大小、粗體、斜體、下劃線、刪除線樣式。可設置文字的顏色和背景色。支持文字套圈。

2.       圖片：可插入圖片，圖片和文字混排，能手動拖拽設置圖片的寬度和高度，能保持圖片的寬度高度比例。圖片的圖像數據可保持在文檔中，也可鏈接引用其他地方的圖像數據。能設置文字圍繞模式。支持替換文字。

3.       段落：可設置段落的行間距、段前間距、段后間距。可設置段落的首行縮進和整體縮進量。可設置多種段落列表頭顯示樣式。

4.       表格：支持單元格的橫向合并和縱向合并。支持表格單元格內部的圖文混排，支持表格套嵌表格。支持鼠標拖拽表格線來設置表格列的寬度和表格行的高度，支持鼠標拖拽來單獨是設置一個單元格的寬度（不影響其他單元格）。支持設置每頁都顯示的標題行。支持表格單元格邊框線的設置和背景顏色的設置。支持單元格斜線。

5.       圖形：能插入矢量圖形，包括橢圓形、正多邊形、五角星、菱形等等等。

6.       條形碼：支持一維條形碼。

7.       頁眉頁腳：支持設置頁眉頁腳，其內容和正文一樣編輯和排版。能插入頁碼元素。

8.       排版：支持文檔，能設置文檔節的邊框和背景。支持分頁符進行強制分頁。

9.       文檔編輯控件：支持分頁視圖模式和普通視圖模式。支持OLE拖拽插入數據，支持和其他程序的復制、粘貼，支持重做和撤銷操作。支持鼠標和鍵盤拖拽選擇文檔的部分內容。

10.   打印：支持文檔的打印，支持打印預覽。支持多個文檔在一個界面中預覽和打印。

11.   VBA：支持在文檔中嵌入VBA腳本代碼。

12.   文檔結構圖：支持顯示樹狀的文檔結構圖，使得用戶能快速定位內容。

13.   DOM模型：提供可開發和擴展的文檔內容DOM開發模型，支持自定義文檔元素類型。

14.   數據過濾：支持數據過濾，在向文檔插入數據時，應用程序能進行過濾和處理。

15.   開發環境：微軟WindowsXP及更高版本操作系統。能用于MS.NET/VB/PB/DELPHI開發，能用于B/S開發。

16.   運行環境：微軟WindowsXP及更高版本操作系統。對B/S客戶端為IE7及更高版本瀏覽器。

17.   文件：核心程序文件數量少，總大小不超過15MB；對于B/S應用總大小不超過10MB，不依賴第三方組件。

電子病歷業務功能需求

1.       UI用戶體驗：盡量少使用對話框，而使用彈出式的用戶界面。因為對話框比較容易打斷用戶的思路，而彈出式的用戶界面對此影響比較少。

2.       痕跡保留：支持痕跡保留，用戶對文檔中的內容的新增、修改和刪除都能產生痕跡信息并保留在文檔中，痕跡信息包括操作員的名稱、時間、操作類型和操作的文檔內容。痕跡信息能在用戶界面上展現出來。支持用戶配置痕跡可視化效果。

3.       權限控制：支持多級權限控制，每個用戶可以分配不同的權限等級。高權限等級的用戶能修改和刪除低權限等級的文檔內容；低權限等級的用戶無法修改和刪除高權限等級的文檔內容，只能看，不能改。

4.       內容保護：能設置指定文檔內容是只讀的，不能刪除和修改樣式。

5.       半結構化：支持半結構化文檔的錄入和存儲。文檔中關鍵區域被標記出來，而且對用戶的文本自由錄入的影響很小。

6.       輸入域：支持在文檔中插入輸入域，輸入域可以設置背景文本、固定寬度、數據錄入方式、數據校驗格式等信息。

7.       知識庫：支持加載知識庫，知識庫中以樹狀結構組織了多個知識庫節點，節點可以采用可選內容列表，也可以鏈接引用到模板中。知識庫的內容可以動態的來自其他程序模塊或數據庫。

8.       數據源綁定：文本輸入域能綁定數據源。應用程序能傳遞數據源來批量的修改文檔中輸入域中的內容。文檔中的內容也可以批量的回填到數據源中。

9.       級聯模板：設置某個輸入域的內容能自動的控制其他文檔片段的顯示和隱藏。使得文檔具有一定的智能判斷效果。

10.   醫學表達式：支持帶分子分母的醫學表達式。能直接在文檔中編輯醫學表達式中的數據。

11.   嵌入組件：支持在文檔中嵌入第三方組件，第三方組件參與文檔的排版和打印。

12.   網格線：支持整個文檔的網格線，支持單元格中設置網格線。實現類似護理記錄的錄入界面。

13.   繼續打印：支持斷點繼續打印。用戶和程序都能設置繼續打印的位置。

14.   整潔打印：支持不帶有痕跡信息的整潔打印。

15.   文件格式：必須支持單文檔的XML格式，文檔中所有的信息，包括文檔內容、排版樣式控制、痕跡保留信息等都所有細節信息都存儲在一個XML文檔中。

16.   表單視圖模式：支持表單視圖模式，用戶的編輯操作將限制在輸入域中。可編輯區域不得超出輸入域。

17.   視圖加密：支持加密模式顯示文檔中的部分內容，比如星號顯示患者姓名。

18.   事件：提供豐富的用戶界面事件進行二次開發。

功能規范

理想的EMRE能實現衛生部制定的《電子病歷系統功能規范》中的針對病歷文檔編輯器而制定的功能需求，這些需求列出如下：

電子病歷功能規范條款	點評
第九條第二點：對電子病歷數據的創建、修改、刪除等任何操作自動生成、保存審計日志（至少包括操作時間、操作者、操作內容等），并提供按審計項目追蹤查看其所有操作者、按操作者追蹤查看其所有操作等功能。
第十條第一款第一點：支持對各種類型的病歷資料的轉換、存儲管理，并采用公開的數據存儲格式，使用非特定的系統或軟件能夠解讀電子病歷資料。	存儲格式首推XML格式。
第十條第一款第五點：具有電子病歷數據備份和恢復功能；當電子病歷系統更新、升級時，應當確保原有數據的繼承與使用。	編輯器提供向上和向下兼容性，新版本的編輯器能加載舊版本保存的電子病歷文檔。舊版程序也能部分的加載新格式的文檔。
第十條第二款第一點：以適當的方式保存完整醫療記錄，能夠以原有樣式再現醫療記錄。
第十一條第一款第一點:對電子病歷設置保密等級的功能，對操作人員的權限實行分級管理，用戶根據權限訪問相應保密等級的電子病歷資料。授權用戶訪問電子病歷時，自動隱藏保密等級高于用戶權限的電子病歷資料。	支持加密顯示文檔內容。例如
第十三條: 為患者創建電子病歷，必須賦予患者唯一的標識號碼，建立包含患者基本屬性信息的主索引記錄，確保患者的各種電子病歷相關記錄正確地與患者唯一標識號碼相對應。
第十四條第一款第一點：為患者（含急診或其他情況下身份不確定的患者）創建電子病歷并賦予統一編碼的唯一標識號碼功能，通過該標識號碼可查閱患者的電子病歷相關信息。
第十四條第一款第二點：為每位患者電子病歷創建唯一的主索引，并記錄患者基本信息（應當至少包括患者姓名、性別、出生日期、常駐地地址等），并能夠對患者基本信息進行必要的修改、補充和完善。
第十四條第一款第三點：提供電子病歷主索引自動查重功能，按照患者基本信息記錄對系統可能存在的重復記錄給予提示并由人工確認。
第十五條：提供電子病歷自動查重功能，能夠將同一患者的多重電子病歷與該患者唯一標識號碼進行關聯，通過唯一標識號碼可查閱患者的電子病歷相關信息。
第十九條第二點：提供以自由文本方式錄入診斷（或主訴）、手術及操作名稱的功能。
第二十條第一款第二點：提供以自由文本方式錄入診斷、手術及操作名稱的功能。
第二十條第二款第二點：提供為臨床試驗病例、教學病例等特殊病歷資料進行標識的功能。
第二十三條第二點：提供住院病歷創建信息補記、修改等操作功能，對操作者應當進行身份識別、保存歷次操作印痕、標記準確的操作時間和操作者信息。	痕跡保留
第二十四條第一款第一點：支持各類型病歷資料錄入與編輯的功能。	支持文字、圖片、表格等等。
第二十四條第一款第二點：提供按照病歷類型、內容和要求，根據電子病歷系統中相關數據，自動生成住院病歷部分內容的功能。
第二十四條第一款第三點：提供自由文本錄入功能。	提供仿MS Word的用戶體驗，能自由錄入文本。
第二十四條第一款第四點：提供在住院病歷指定內容中復制、粘貼患者本人住院病歷相同信息的功能；禁止復制、粘貼非患者本人信息的功能。	在粘貼文檔內容時需要進行數據過濾。
第二十四條第一款第五點：提供模板輔助錄入功能，可以按照住院病歷類型、疾病病種選擇所需模板；模板內容應當符合該疾病現有診療指南、規范要求。
第二十四條第一款第六點：提供為醫療機構定制各類型住院病歷默認樣式的功能，默認樣式包括紙張尺寸、字體大小、版面設置等。	支持頁面設置，支持自定義紙張大小，支持信紙樣式的網格線。
第二十四條第一款第七點：提供暫時保存未完成住院病歷記錄，并授權用戶查看、修改、完成該病歷記錄，提供住院病歷記錄確認完成并記錄完成時間的功能。
第二十四條第一款第八點：提供住院病歷記錄雙簽名功能，當由實習醫師、試用期醫務人員書寫病歷時，應當經過本醫療機構注冊的醫務人員審閱、修改，并保留書寫者與審閱者的雙簽名。	提供痕跡保留、審閱標記等功能。
第二十四條第二款第一點：提供在住院病歷記錄中插入患者基本信息、醫囑信息、輔助檢查報告、生命體征信息等相關內容的功能。
第二十四條第二款第三點：提供結構化病歷記錄項目內容合理性檢查與提示功能，包括項目獨立檢查和項目之間、項目與患者個人特征間的相關性檢查。
第二十四條第二款第四點：提供包含展現樣式的病歷記錄錄入編輯和保存功能；提供所見即所得的病歷記錄錄入編輯功能。
規范第二十四條第三款第一點：提供在住院病歷記錄中嵌入圖片、表格、多媒體數據并進行編輯的功能。
第二十四條第三款第三點：.提供常用術語詞庫輔助錄入功能，術語詞庫包括癥狀名稱、疾病名稱、藥物名稱、手術名稱、護理常規名稱等.
第二十四條第三款第四點：提供結構化（可交互元素）模板輔助錄入功能，并在病歷記錄中保留結構化模板形成的結構。
第二十五條第一款第一點：提供病歷記錄的修改和刪除功能，并自動保存病歷記錄修改的痕跡；對已確認完成的病歷記錄進行修改時，系統自動記錄修改內容、修改人、修改時間。
第二十五條第一款第二點：對病歷記錄按照用戶修改權限管理的功能，允許上級醫務人員修改下級醫務人員創建的病歷記錄。
規范第二十五條第二款：提供病歷記錄禁止修改的設置功能。
第二十六條第二款第一點：提供創建結構化模板功能，結構化模板至少包含單選項、多選項、必填項、填空、不可修改文本等元素。
第二十六條第二款第二點：提供模板中定義自動宏替換元素功能，宏替換元素可用于在病歷記錄中經常出現的患者姓名、性別、主訴等內容。
第二十六條第二款第三點：提供結構化模板中，對結構化元素設定錄入方式、取值范圍、校驗規則等屬性功能。
第四十二條第一款：提供可瀏覽患者各類電子病歷內容的獨立軟件。
第四十三條第三款第二點：提供與病歷數據同時展現相關修改痕跡信息的功能，至少包括修改時間、修改人、修改內容等信息。
第四十四條第一款第一點：提供將電子病歷中的各類醫療記錄進行紙張打印的功能，打印格式符合衛生行政管理部門對紙質病歷的相關要求。
第四十四條第一款第二點：提供電子病歷記錄按照最終內容（不含修改痕跡）打印的功能。
第四十四條第一款第三點：提供電子病歷打印預覽、接續打印功能。
第四十四條第二款第一點：提供將一次就診的病歷資料全部或部分進行批量打印的功能。
第四十四條第三款第二點：提供將電子病歷中的各類醫療記錄以電子文件格式導出的功能。	應該必須支持XML格式。