論電子病歷文本編輯器
袁永福
28348092@qq.com
2013-5-12
前言
受chisc.net網(wǎng)站邀請，特撰此文，一家之言，供技術(shù)交流，如果有不妥，敬請指正。
作者簡介
袁永福，2001年東南大學畢業(yè)，從事IT十多年，2008年度微軟MVP，著書立說�，F(xiàn)在南京從事電子病歷編輯器相關(guān)工作。博客網(wǎng)址http://www.cnblogs.com/xdesigner。
電子病歷文本編輯器概述
電子病歷編輯器，簡稱EMRE（EMR Editor）。EMRE是電子病歷系統(tǒng)的核心關(guān)鍵基礎技術(shù)。在HIT大市場中，EMRE已經(jīng)是一個專業(yè)子市場。為什么會形成這個子市場，筆者在此討論一番。
其實觀察整個醫(yī)療行業(yè)，所有的人都是圍繞著治病救人這個中心而忙碌著，無論是衛(wèi)生系統(tǒng)的官員、醫(yī)院各級管理人員、醫(yī)務人員、各級醫(yī)療服務單位，還有我們這么多的HIT企業(yè)等等都是的。如果人不生病，全球立馬有幾千萬人失業(yè)。
在醫(yī)生治病救人的過程中會產(chǎn)生大量的信息，這些信息中最為重要的就是病歷，如果沒有這些病歷，診療過程就成為低水平的重復又重復，很多的涉及到生命的資料無從可查。因此病歷信息是整個醫(yī)療信息化中的核心信息。數(shù)據(jù)庫存儲的是病歷數(shù)據(jù)、網(wǎng)絡傳輸?shù)氖遣v數(shù)據(jù)、終端顯示的是病歷數(shù)據(jù)、打印機輸出的是病歷數(shù)據(jù)、后臺分析的是病歷數(shù)據(jù)、醫(yī)療司法活動的基礎證據(jù)也是病歷數(shù)據(jù)。
這里的病歷數(shù)據(jù)范圍比較廣，包括各種病歷文書、醫(yī)學影像、檢查檢驗結(jié)果等等。從HIT系統(tǒng)應用的角度上來說，各種類型的病歷數(shù)據(jù)處理手段不一樣，從而形成各個子市場。
比如醫(yī)學影像數(shù)據(jù)的處理比較專業(yè)，由此形成PACS子市場，里面已經(jīng)有很多廠家，甚至還形成了醫(yī)學顯示器這種微市場。那里的人賣硬件賣軟件，生意興隆。
病歷文書數(shù)據(jù)也是病歷數(shù)據(jù)中的一個關(guān)鍵數(shù)據(jù)，也是應用最為頻繁的數(shù)據(jù)。畢竟一個人看病，可以不拍片子、不檢驗檢查，但醫(yī)生肯定會寫下一段文本病歷。PACS系統(tǒng)折騰一番生成的高清圖像也只是在醫(yī)生診療過程中作為參考，關(guān)鍵還是醫(yī)生寫下的病歷文本。
因此在目前的階段，所有的診療過程產(chǎn)生的最為關(guān)鍵的信息是病歷文書。
因此在醫(yī)學信息化中，病歷文書是作為最為重要的信息是需要得到最為特別的照顧。
在過去的傳統(tǒng)HIS階段，應用系統(tǒng)對病歷文書的照顧就是一個最簡單的TextBox，高級一點的用上MS WORD。不過這顯然是遠遠不夠的，那樣做不是與時俱進，而且HIT客戶已經(jīng)越來越專業(yè)越挑剔了。
理論上來說，醫(yī)生拿著菜刀也能做手術(shù)，實際上那將是非�？植赖氖虑椤５珜嶋H上，很多醫(yī)生還是拿著菜刀寫病歷，而專業(yè)的EMRE就是醫(yī)生寫病歷時的上好工具。
EMRE子市場
現(xiàn)今開發(fā)和使用電子病歷系統(tǒng)不可避免的要使用到EMRE，這基本上是繞不過去的。對于EMRE，軟件開發(fā)公司主要有自行開發(fā)和對外采購的方式來獲得。
開發(fā)EMRE的技術(shù)那是老復雜了，難度是非常非常高，業(yè)界能開發(fā)編輯器的人才鳳毛麟角。因此一些HIT業(yè)務型軟件公司自主研發(fā)EMRE那是勇氣可嘉的，至于能否成功那只能是盡力而為了。
筆者的觀察中大多數(shù)軟件公司是搞不定自主研發(fā)EMRE的，經(jīng)過一番折騰，弄得頭破血流的，最后還是轉(zhuǎn)而尋求外購EMRE。于是就形成了非常專業(yè)的EMRE子市場。
EMRE子市場不大，但由于掌握了技術(shù)高地，因此在HIT大市場中是還是比較關(guān)鍵的。大家討論電子病歷系統(tǒng)時必然會提到這個系統(tǒng)中使用的EMRE。大家所說的病歷控件基本上就是指電子病歷文本編輯器控件。
很多HIT企業(yè)在外購EMRE時都想同時購買源代碼，筆者覺得這是不現(xiàn)實的也是沒有多少實際意義的。
目前的EMRE企業(yè)基本上是不會出售源代碼的，這事關(guān)中國國情，大家都懂的。通過非正常途徑獲得的源代碼，那是有相當?shù)姆娠L險，因為國內(nèi)HIT圈子不算大，有一定的風險被EMRE廠家發(fā)現(xiàn)，引起糾紛，而且不管結(jié)局如何，醫(yī)院甲方都會有想法的。
也存在個人出售編輯器代碼，很有可能是網(wǎng)絡上已經(jīng)流傳的代碼，特別是ZYTextDocumentLib的源代碼。筆者覺得這對于正規(guī)的HIT企業(yè)來說沒多大作用，因為改造這些代碼并進行二次開發(fā)的過程差不多等于走回自主研發(fā)EMRE的老路。
另外購買編輯器代碼并沒有多少實際意義。HIT企業(yè)購買代碼無非擔心EMRE企業(yè)倒閉轉(zhuǎn)行，使得編輯器無法更新?lián)Q代。根據(jù)筆者觀察，現(xiàn)實中HIT企業(yè)的管理者會讓程序猿們時刻忙于項目，天天干活，特別是高級程序猿更是忙得團團轉(zhuǎn)；此時高級程序猿不會有大把的時間認真系統(tǒng)的消化吸收編輯器代碼的，而初級程序猿是沒有相關(guān)能力的。因此如果編輯器有BUG或者新功能需求，基本上還是要找EMRE企業(yè)。
這就是即使是東軟這樣的HIT巨頭也沒有自主研發(fā)EMRE控件的原因之一。
另外EMRE企業(yè)之所以成立，也必然有相應的技術(shù)力量，否則接下EMRE這種重活是害人害己。
另外EMRE企業(yè)相比于HIT企業(yè)更不在乎企業(yè)的規(guī)模。HIT業(yè)務型企業(yè)天天拉單子做項目，實施一個有點規(guī)模的醫(yī)院的HIS/EMR，沒有個一年半載是搞不定的，大批人員駐場開發(fā)那是常見，常年的駐點運維工程師也是常有的。因此HIT企業(yè)雖然人多有規(guī)模，當幾個項目同時運行時還是會人手不夠。
但EMRE企業(yè)不一樣，它是做通用產(chǎn)品的，它的客戶都是懂技術(shù)的，技術(shù)人員之間的溝通交流速度是很快的，而且所有HIT企業(yè)對于EMRE的需求的交集是不大的，無需大型團隊來應付。EMRE企業(yè)專注于特定技術(shù)鉆研，更在乎人員的精干而不是數(shù)量。因此小規(guī)模企業(yè)也能勝任EMRE業(yè)務。
實施HIT項目時，接口工作量不小�，F(xiàn)在很多醫(yī)院的系統(tǒng)都是萬國系統(tǒng)，各種牌子的系統(tǒng)糾纏在一起，產(chǎn)生了大量的軟件和硬件接口需求，各個HIT企業(yè)、甲方內(nèi)部小集團之間還存在互掐的現(xiàn)象；此外還有醫(yī)保銀行相關(guān)的接口，這些接口工作也耗掉了不少HIT企業(yè)的精力。
相比而言EMRE企業(yè)的接口工作量少的多。技術(shù)上EMRE企業(yè)是強勢的，HIT企業(yè)必須使用EMRE企業(yè)制定的開發(fā)接口。就這點而言，EMRE企業(yè)能省掉不少人力。
這些原因使得HIT企業(yè)可以追求做大或做強，但EMRE企業(yè)必然是追求做強而不是做大。
EMRE控件產(chǎn)品及技術(shù)路線介紹
目前業(yè)界存在一些EMRE控件產(chǎn)品及技術(shù)路線，在此介紹幾種常見的：
基于標準TextBox控件進行開發(fā)
基于TextBox控件來開發(fā)EMRE那是最為原始最為簡單的方式。比如在用戶界面上，放一個“主訴”文本標簽，后面跟著一個TextBox用于手動錄入主訴文本，現(xiàn)病史也類似。在存儲上，可能是主訴內(nèi)容存一個文本型字段，現(xiàn)病史內(nèi)容存一個文本型字段。
這種方式實現(xiàn)簡單，幾十年前就出現(xiàn)了，但現(xiàn)在早就OUT了，若還拿出來都不好意思見人了。
基于RichTextBox控件進行開發(fā)
很多開發(fā)工具提供一個RichTextBox控件，實際上就是Windows自帶的RichTextBox控件的簡單包裝。
使用RichTextBox控件能實現(xiàn)一些格式文本的編輯、錄入，文字格式的設置，能插入圖片，簡單的表格。
不過基于RichTextBox控件進行一些深入的開發(fā)就不行了。比如留痕、續(xù)打、知識庫等等，此時一些開發(fā)企業(yè)就騎虎難下了，終究是要放棄的。
基于MS WORD進行開發(fā)
一些EMRE是基于MS WORD進行開發(fā)。其優(yōu)點如下：
1. MS WORD的文檔編輯器功能是任何其他文本編輯器所無法逾越的。文字、圖片、表格等等都是至尊級的，而且MS WORD應用廣泛，群眾基礎好�；谒_發(fā)，在文檔編輯用戶體驗上來說，用戶是很容易接受的。
2. MS WORD的二次開發(fā)接口比較多，各種支持COM的開發(fā)工具都支持。而且MS WORD的開發(fā)學習資源比較豐富，網(wǎng)上能找到很多。
不過使用MS WORD進行開發(fā)也有不少缺點：
1. MS WORD不是免費軟件，使用它必須購買一個完整的MS Office軟件包，這是一筆不小的版權(quán)費用。醫(yī)院可能拒絕使用盜版MS WORD，此時會比較大的增加項目成本。比如有微軟經(jīng)銷商報價MS OFFICE2010為4000元/套。這樣就很不利于HIT企業(yè)市場銷售。
2. 客戶端電腦必須逐個安裝MS WORD，部署工作量比較大。而且不同版本的MS WORD的開發(fā)接口存在一定的兼容性問題，增加軟件開發(fā)、部署和調(diào)試的難度。比如不同的客戶已經(jīng)安裝了WORD2003、WORD2007、WORD2010等等，此時麻煩不小。
3. MS WORD開發(fā)是基于OLE自動化技術(shù)，使用了跨進程的操作，操作不當系統(tǒng)中會留下MS WORD的進程，容易資源泄露，因此一般避免在服務器端使用MS WORD。
4. 大量的電子病歷特定業(yè)務功能使用MS WORD是無法實現(xiàn)或者很難實現(xiàn)的。比如痕跡保留和三級權(quán)限控制；半結(jié)構(gòu)化；續(xù)打、整潔打印和留痕打��；對于B/S系統(tǒng)，如何將MS WORD文件傳到服務器上也是個難題；難于實現(xiàn)知識庫。而且生成的WORD文件格式復雜難于解析，難于進行統(tǒng)計分析。
基于MS WORD開發(fā)電子病歷編輯器可以在某些情況下應急，但由于上述無法解決的缺陷，從長遠上來說是不可取的，終究是要放棄這種方式的。
基于開源DELPHI的TX控件進行開發(fā)
TX控件以前是一個免費開源的DELPHI控件，現(xiàn)在作者據(jù)此成立公司不再免費開源了。TX控件是用DELPHI開發(fā)的，有COM接口。因此很適合DELPHI或VB/PB的開發(fā)。
業(yè)界還有大量的已經(jīng)運行中的信息化系統(tǒng)是由PB/VB/DELPHI開發(fā)的，而且還有一些新系統(tǒng)也是靠這些老技術(shù)開發(fā)的。因此業(yè)界還存在不少使用TX開發(fā)的EMRE控件。
使用TX控件開發(fā)編輯器控件，能輕松的實現(xiàn)常規(guī)的文檔編輯功能，比如圖文混排、表格、圖片等等。不過想要開發(fā)超出TX控件能力范圍而實現(xiàn)新的文檔編輯功能就非常難了。比如表格線上下拖拽調(diào)整表格行高度、續(xù)打等等。
另外TX控件是通用文檔編輯器控件，而電子病歷行業(yè)很多特種業(yè)務需求就很難實現(xiàn)。有些雞肋。
為實現(xiàn)電子病歷行業(yè)特定需求，需要在TX基礎上開發(fā)重大新功能，這需要深入理解TX的內(nèi)部結(jié)構(gòu)。只要是帶格式文檔編輯器控件都是非常復雜的，理解起來那是相當難的，而且現(xiàn)在的DELPHI熟練程序員越來越少，因此對于基于TX開發(fā)編輯器的廠商，許多電子病歷業(yè)務特定功能很難實現(xiàn)或者基本上是不可能實現(xiàn)。
HIT企業(yè)可以向TX供應商申請加功能，不過HIT行業(yè)只是TX供應商的市場的一部分，人家或許不在乎為這點市場而大改TX控件，因此進展緩慢。
另外DELPHI本身也是一項老技術(shù)，雖然還能用于開發(fā)一些新系統(tǒng)，不過相關(guān)人才會越來越少，系統(tǒng)維護將逐漸成為一個大問題。筆者覺得此時不未雨綢繆搞轉(zhuǎn)型，以后想轉(zhuǎn)就來不及了。
易訊電子病歷編輯器
易訊電子病歷編輯器是天方達軟件開發(fā)有限公司的產(chǎn)品，其軟件界面如下：
技術(shù)分析易迅電子病歷編輯器應該是Delphi開發(fā)的，可能是在TRichViewEdit的基礎上進行二次開發(fā)的。支持自由的文檔編輯，支持表格。控件程序文件大小為10MB。
易迅電子病歷編輯器在常規(guī)的文檔編輯器功能是差不多夠用了，但有些功能做得還不夠，在此挑出幾個：
1. 談不上支持半結(jié)構(gòu)化技術(shù)。未發(fā)現(xiàn)支持XML技術(shù)。
2. 單元格無法單獨的設置寬度，當編輯復雜表格布局時比較費勁。
3. 開發(fā)幫助文檔太簡單了。
4. 文字排版無法兩端對齊，文字右邊緣層次不齊，影響美觀。
5. 圖片可以編輯后無法修改已經(jīng)改過的內(nèi)容，無法撤銷。
易訊編輯器的東家天方達公司還據(jù)此經(jīng)營著一個電子病歷文檔的網(wǎng)絡社區(qū)。任何人注冊就可以上傳和下載電子病歷文檔范文，這是他們的一個不錯的特色。這里是病歷文檔范文，還談不上是病歷文檔模板。
病歷寶典
病歷寶典軟件是北京華信慧典科技有限公司研發(fā)的電子病歷編輯器。其用戶界面如下：
該軟件也應該是使用Delphi基于TRichViewEdit開發(fā)的。相比易迅病歷編輯器，其功能改善了不少，主要有：
1. 總體感覺用戶界面比易迅編輯器要現(xiàn)代多了。相比而言易迅編輯器的用戶界面還是比較粗糙的。
2. 能進行文字的兩邊對齊了。
3. 增強了醫(yī)學表達式。
筆者測試的是《慧典電子病歷系統(tǒng)學習版》，這個版本有一個很要命的缺點，那就是當該軟件顯示對話框，比如插入表格對話框時，在Win7環(huán)境下，切換到其他程序后在切換回來，對話框?qū)㈦[藏在主窗體后面，此時應用程序根本無法操作，只能強制殺進程。
由于是未注冊版本，無法判斷是否真的支持半結(jié)構(gòu)化文檔等重要功能。
初步感覺易迅編輯器和病歷寶典編輯器存在微妙的關(guān)系，這不僅僅是共同是基于TRichViewEdit開發(fā)的原因。因為筆者發(fā)現(xiàn)這兩個編輯器很多細節(jié)是高度一致的，猜測兩者應該共享很多代碼吧。
病歷寶典的編輯器是不單獨銷售的，是集成在慧典電子病歷系統(tǒng)中的，因此HIT企業(yè)不能指望它了。
基于開源OpenOffice進行開發(fā)
也有HIT企業(yè)在著名的開源OpenOffice的基礎開發(fā)電子病歷編輯器。這個風險比Delphi開源控件為基礎的高得多。因為OpenOffice比其他任何開源控件要復雜得多，底層程序基本上無人可以修改。
OpenOffice最早可追朔至1980年代，多次易主，現(xiàn)在歸ORACLE所有。經(jīng)過30多年的發(fā)展，已經(jīng)包含1000多萬行C++/Java混合代碼，源代碼文件有1.6GB大小，其中的功能模塊不計其數(shù)，組件引用網(wǎng)格非常復雜，真是牽一發(fā)而動全身，為此歷史上遺留下來了一些無法剔除的垃圾模塊。下圖就是OpenOffice中各個功能模塊的引用關(guān)系圖：
如此復雜的內(nèi)部結(jié)構(gòu)，使得OpenOffice確實能拿過來就能用，但基本上無法修改。只能在表面上做一些盡力而為的事情了。
另外其他的編輯器是輕量級的控件，程序文件都不大，而且是從用戶界面上還是運行架構(gòu)上都能緊密嵌入在應用程序中的。
但OpenOffice則是重型辦公軟件包而不是控件，功能齊全、文件數(shù)量多、體積龐大，精簡下來也有近百MB大小，用于B/S開發(fā)時需要謹慎。
而且從運行架構(gòu)上，OpenOffice的文檔編輯用戶界面雖然能嵌入到應用程序中，但后臺還是跑著編輯器的獨立進程soffice.exe/soffice.bin，出現(xiàn)了復雜易錯的跨進程操作。因此說基于OpenOffice開發(fā)的不是控件，而是軟件包的二次開發(fā)。這點很類似MS WORD。
OpenOffice體積龐大的另一個原因就是為了實現(xiàn)跨平臺的，它能運行在Windows/Linux/Mac OS/Solaris等多種操作系統(tǒng)，支持各種接口和規(guī)范。而國內(nèi)電子病歷客戶端基本上都是MS Windows平臺，OpenOffice的這些跨平臺的功能對于EMR用戶來說就是畫蛇添足的了。
使用OpenOffce比MS WORD相比唯一的好處就是OpenOffice是自由軟件的，沒有版權(quán)現(xiàn)金成本，其開源的特性對于HIT企業(yè)來說其實是沒啥實際作用，就跟小學生學奧數(shù)一樣。OpenOffice文檔編輯功能也很強大，但還是無法達到MS WORD的那種至尊境界。
使用OpenOffice會涉及到它的版權(quán)問題，中國國情是不尊重版權(quán)的，比如有些IT企業(yè)（特別是政績企業(yè)）把OpenOffice或者開源操作系統(tǒng)簡單封裝一下，然后聲稱國產(chǎn)原創(chuàng)，跑到政府面前邀功套現(xiàn)套證書。
|
OpenOffice org采用GNU通用公共許可證（GPL）和Sun工業(yè)標準源碼許可證（Sun Industry Standards Source License，SISSL）8的“雙許可證”方式對源碼進行許可；采用獨立的公共文檔許可證9（Public Documentation License，PDL）對發(fā)布在OpenOffice org網(wǎng)站上、但不期望集成進軟件的絕大多數(shù)文檔進行許可。
“雙許可證”方式意味著要么應用GNU GPL許可證，要么應用SISSL許可證。當應用GPL許可證的時候，OpenOffice org源碼中的庫和組件功能將根據(jù)GNU LGPL進行許可。由于LGPL與GPL完全兼容，這樣就能夠鼓勵更多的人參與到OpenOffice org社區(qū)建設中來。
SISSL則是為商業(yè)應用設計的。由于GPL許可證對于自由復制、修改、發(fā)布等權(quán)利的嚴格保證，某些軟件商會因此而受限、不能參與到開放源碼社區(qū)中來。OpenOffice org的雙許可證方式解決了這個問題，他們可以選擇根據(jù)SISSL進行許可。SISSL是經(jīng)過開放源碼促進會（Open Source Initiative，OSI）確認的開放源碼許可證10，它規(guī)定在被許可者承諾保證“標準”一致的條件下，可以分發(fā)軟件但不公開修改過的源代碼。這里的“標準”是指OpenOffice org的XML文件格式規(guī)范11，和OpenOffice org的應用程序接口規(guī)范12。
|
由于這個授權(quán)限制，使得基于OpenOffice開發(fā)自定義的適合電子病歷業(yè)務需求的XML文檔格式從授權(quán)上是違反的，從技術(shù)上是不可行的。
EMRPad
由于基于開源軟件而開發(fā)EMRE困難重重，于是國內(nèi)有人開始自主研發(fā)編輯器了。其中最為著名的是陳聯(lián)忠開發(fā)的EMRPad了。
陳聯(lián)忠陳老師，技術(shù)達人，我等程序猿的楷模。中國最早做出了比較實用的電子病歷編輯器EMRPad，該軟件2006年被北京嘉和美康信息技術(shù)有限公司收購，從此不再獨行于江湖。
可以說，嘉和公司的壯大，陳老師的編輯器出力不少。當年該編輯器提出了很多目前業(yè)界關(guān)于編輯器的標準功能，主要有：
1. 半結(jié)構(gòu)化文檔。將所謂的元素（也稱輸入域、關(guān)鍵字）和普通文本自由混排。實現(xiàn)全結(jié)構(gòu)化文檔和自由文本的混合。這樣提供比較好的用戶體驗，而且也大大便利的程序?qū)Σv數(shù)據(jù)的處理。
2. XML存儲。將病歷文檔以純XML的方式進行存儲。而且文檔內(nèi)容和排版樣式控制信息存在一個文件中。
3. 增強打印。包括續(xù)打、留痕打印和清潔打印。
4. 三級查房權(quán)限控制。
由于嘉和公司收購陳老師的編輯器，因此編輯器不會再單獨對外銷售了，不過奇怪的是，還是有傳聞有單獨銷售的，不知是真是假。
陳老師現(xiàn)在任嘉和公司CTO，應該是專注于電子病歷系統(tǒng)的大的框架性的研發(fā)，焦點可能已經(jīng)不在編輯器上面了。不過這些對于廣大的需要編輯器的HIT企業(yè)來說沒啥關(guān)系了。
ZYTextDocumentLib系列編輯器
在國內(nèi)HIT業(yè)界還流傳著ZYTextDocumentLib的病歷編輯器及其衍生版本，有一些HIT企業(yè)和個人使用這種編輯器。該編輯器用戶界面大致如下：
這種編輯器是使用C#1.1開發(fā)的，業(yè)界有源代碼流傳。其程序文件名為ZYTextDocumentLib.dll或變體。
這種編輯器是采用完全的XML存儲格式，其最大的特點就是XML根節(jié)點名稱為“emrtextdoc”。這種編輯器初步實現(xiàn)了半結(jié)構(gòu)化的編輯和存儲，支持知識庫，還有痕跡保留功能，有些衍生版本支持簡單的表格。
不過該軟件運行還不穩(wěn)定，容易出錯，功能也有不少欠缺。不建議使用。
DCWriter的編輯器
DCWriter編輯器是南京都昌信息科技有限公司的產(chǎn)品。其界面如下：
它是C#開發(fā)的，還提供COM接口，可用于VB/DELPHI之類的開發(fā)。該款編輯器功能還是非常全面的。比如續(xù)打，留痕打印，痕跡保留，三級權(quán)限控制，知識庫，級聯(lián)模板，醫(yī)學表達式，條碼等等。雖然功能多，但程序文件只有3MB大小，不依賴第三方組件，因此也適用于B/S開發(fā)。
該編輯器表格功能比較突出，相比其他編輯器而且已經(jīng)比較接近于WORD的表格功能了，能實現(xiàn)標題行、單獨的設置單元格的寬度，能方便的進行復雜表格的排版。而且單元格內(nèi)部可以加上網(wǎng)格線，很容易實現(xiàn)護理記錄的特殊文檔樣式。
另外對于.NET開發(fā)者，該編輯器提供DOM模式的文檔內(nèi)容開發(fā)接口，使得開發(fā)者能詳細控制文檔內(nèi)容的各種細節(jié)內(nèi)容，甚至派生出自定義的文檔元素類型；而且DOM式的接口可用于非GUI程序的開發(fā)，能用于ASP.NET服務器端程序、命令行和Windows Service程序的開發(fā)。
此外文檔中還能嵌入.NET控件和WPF控件，實現(xiàn)了編輯器包含業(yè)務的軟件架構(gòu)。因此對于.NET開發(fā)，在諸多EMRE控件中，DCWriter是首選。
在用戶界面上，該編輯器的知識庫采用彈出列表的方式顯示，并使用拼音碼檢索然后插入，彈出式列表的用戶界面相比對話框的方式能較少的干擾使用者的思路。
該編輯器支持半結(jié)構(gòu)化文檔，病歷文件就是XML格式。程序可以直接快速處理病歷XML文件。
它對衛(wèi)生部的電子病歷系統(tǒng)功能規(guī)范支持得很不錯。
另外該編輯器的文檔寫得很詳細，用戶手冊有300多頁13萬字，事無巨細的說明了該編輯器的所有細節(jié)內(nèi)容。此外還有類似MSDN的那種開發(fā)SDK文檔。
DCWriter和ZYTextDocumentLib存在一些關(guān)系，DCWriter完全兼容ZYTextDocumentLib生成的電子病歷文檔。而且由于DCWriter采用開放的軟件接口架構(gòu)，加上適配器即可直接加載其他編輯器生成的病歷文檔。
理想EMRE功能需求
根據(jù)作者的實踐，列出比較理想的PC版EMRE的功能需求
文檔編輯功能需求
1. 文字編輯：可自由輸入文字，可設置文字的字體名稱、大小、粗體、斜體、下劃線、刪除線樣式。可設置文字的顏色和背景色。支持文字套圈。
2. 圖片：可插入圖片，圖片和文字混排，能手動拖拽設置圖片的寬度和高度，能保持圖片的寬度高度比例。圖片的圖像數(shù)據(jù)可保持在文檔中，也可鏈接引用其他地方的圖像數(shù)據(jù)。能設置文字圍繞模式。支持替換文字。
3. 段落：可設置段落的行間距、段前間距、段后間距�？稍O置段落的首行縮進和整體縮進量�？稍O置多種段落列表頭顯示樣式。
4. 表格：支持單元格的橫向合并和縱向合并。支持表格單元格內(nèi)部的圖文混排，支持表格套嵌表格。支持鼠標拖拽表格線來設置表格列的寬度和表格行的高度，支持鼠標拖拽來單獨是設置一個單元格的寬度（不影響其他單元格）。支持設置每頁都顯示的標題行。支持表格單元格邊框線的設置和背景顏色的設置。支持單元格斜線。
5. 圖形：能插入矢量圖形，包括橢圓形、正多邊形、五角星、菱形等等等。
6. 條形碼：支持一維條形碼。
7. 頁眉頁腳：支持設置頁眉頁腳，其內(nèi)容和正文一樣編輯和排版。能插入頁碼元素。
8. 排版：支持文檔，能設置文檔節(jié)的邊框和背景。支持分頁符進行強制分頁。
9. 文檔編輯控件：支持分頁視圖模式和普通視圖模式。支持OLE拖拽插入數(shù)據(jù)，支持和其他程序的復制、粘貼，支持重做和撤銷操作。支持鼠標和鍵盤拖拽選擇文檔的部分內(nèi)容。
10. 打�。褐С治臋n的打印，支持打印預覽。支持多個文檔在一個界面中預覽和打印。
11. VBA：支持在文檔中嵌入VBA腳本代碼。
12. 文檔結(jié)構(gòu)圖：支持顯示樹狀的文檔結(jié)構(gòu)圖，使得用戶能快速定位內(nèi)容。
13. DOM模型：提供可開發(fā)和擴展的文檔內(nèi)容DOM開發(fā)模型，支持自定義文檔元素類型。
14. 數(shù)據(jù)過濾：支持數(shù)據(jù)過濾，在向文檔插入數(shù)據(jù)時，應用程序能進行過濾和處理。
15. 開發(fā)環(huán)境：微軟WindowsXP及更高版本操作系統(tǒng)。能用于MS.NET/VB/PB/DELPHI開發(fā)，能用于B/S開發(fā)。
16. 運行環(huán)境：微軟WindowsXP及更高版本操作系統(tǒng)。對B/S客戶端為IE7及更高版本瀏覽器。
17. 文件：核心程序文件數(shù)量少，總大小不超過15MB；對于B/S應用總大小不超過10MB，不依賴第三方組件。
電子病歷業(yè)務功能需求
1. UI用戶體驗：盡量少使用對話框，而使用彈出式的用戶界面。因為對話框比較容易打斷用戶的思路，而彈出式的用戶界面對此影響比較少。
2. 痕跡保留：支持痕跡保留，用戶對文檔中的內(nèi)容的新增、修改和刪除都能產(chǎn)生痕跡信息并保留在文檔中，痕跡信息包括操作員的名稱、時間、操作類型和操作的文檔內(nèi)容。痕跡信息能在用戶界面上展現(xiàn)出來。支持用戶配置痕跡可視化效果。
3. 權(quán)限控制：支持多級權(quán)限控制，每個用戶可以分配不同的權(quán)限等級。高權(quán)限等級的用戶能修改和刪除低權(quán)限等級的文檔內(nèi)容；低權(quán)限等級的用戶無法修改和刪除高權(quán)限等級的文檔內(nèi)容，只能看，不能改。
4. 內(nèi)容保護：能設置指定文檔內(nèi)容是只讀的，不能刪除和修改樣式。
5. 半結(jié)構(gòu)化：支持半結(jié)構(gòu)化文檔的錄入和存儲。文檔中關(guān)鍵區(qū)域被標記出來，而且對用戶的文本自由錄入的影響很小。
6. 輸入域：支持在文檔中插入輸入域，輸入域可以設置背景文本、固定寬度、數(shù)據(jù)錄入方式、數(shù)據(jù)校驗格式等信息。
7. 知識庫：支持加載知識庫，知識庫中以樹狀結(jié)構(gòu)組織了多個知識庫節(jié)點，節(jié)點可以采用可選內(nèi)容列表，也可以鏈接引用到模板中。知識庫的內(nèi)容可以動態(tài)的來自其他程序模塊或數(shù)據(jù)庫。
8. 數(shù)據(jù)源綁定：文本輸入域能綁定數(shù)據(jù)源。應用程序能傳遞數(shù)據(jù)源來批量的修改文檔中輸入域中的內(nèi)容。文檔中的內(nèi)容也可以批量的回填到數(shù)據(jù)源中。
9. 級聯(lián)模板：設置某個輸入域的內(nèi)容能自動的控制其他文檔片段的顯示和隱藏。使得文檔具有一定的智能判斷效果。
10. 醫(yī)學表達式：支持帶分子分母的醫(yī)學表達式。能直接在文檔中編輯醫(yī)學表達式中的數(shù)據(jù)。
11. 嵌入組件：支持在文檔中嵌入第三方組件，第三方組件參與文檔的排版和打印。
12. 網(wǎng)格線：支持整個文檔的網(wǎng)格線，支持單元格中設置網(wǎng)格線。實現(xiàn)類似護理記錄的錄入界面。
13. 繼續(xù)打印：支持斷點繼續(xù)打印。用戶和程序都能設置繼續(xù)打印的位置。
14. 整潔打�。褐С植粠в泻圹E信息的整潔打印。
15. 文件格式：必須支持單文檔的XML格式，文檔中所有的信息，包括文檔內(nèi)容、排版樣式控制、痕跡保留信息等都所有細節(jié)信息都存儲在一個XML文檔中。
16. 表單視圖模式：支持表單視圖模式，用戶的編輯操作將限制在輸入域中�？删庉媴^(qū)域不得超出輸入域。
17. 視圖加密：支持加密模式顯示文檔中的部分內(nèi)容，比如星號顯示患者姓名。
18. 事件：提供豐富的用戶界面事件進行二次開發(fā)。
功能規(guī)范
理想的EMRE能實現(xiàn)衛(wèi)生部制定的《電子病歷系統(tǒng)功能規(guī)范》中的針對病歷文檔編輯器而制定的功能需求，這些需求列出如下：
|
電子病歷功能規(guī)范條款
|
點評
|
|
第九條第二點：對電子病歷數(shù)據(jù)的創(chuàng)建、修改、刪除等任何操作自動生成、保存審計日志（至少包括操作時間、操作者、操作內(nèi)容等），并提供按審計項目追蹤查看其所有操作者、按操作者追蹤查看其所有操作等功能。
|
|
|
第十條第一款第一點：支持對各種類型的病歷資料的轉(zhuǎn)換、存儲管理，并采用公開的數(shù)據(jù)存儲格式，使用非特定的系統(tǒng)或軟件能夠解讀電子病歷資料。
|
存儲格式首推XML格式。
|
|
第十條第一款第五點：具有電子病歷數(shù)據(jù)備份和恢復功能；當電子病歷系統(tǒng)更新、升級時，應當確保原有數(shù)據(jù)的繼承與使用。
|
編輯器提供向上和向下兼容性，新版本的編輯器能加載舊版本保存的電子病歷文檔。舊版程序也能部分的加載新格式的文檔。
|
|
第十條第二款第一點：以適當?shù)姆绞奖４嫱暾t(yī)療記錄，能夠以原有樣式再現(xiàn)醫(yī)療記錄。
|
|
|
第十一條第一款第一點:對電子病歷設置保密等級的功能，對操作人員的權(quán)限實行分級管理，用戶根據(jù)權(quán)限訪問相應保密等級的電子病歷資料。授權(quán)用戶訪問電子病歷時，自動隱藏保密等級高于用戶權(quán)限的電子病歷資料。
|
支持加密顯示文檔內(nèi)容。例如
|
|
第十三條: 為患者創(chuàng)建電子病歷，必須賦予患者唯一的標識號碼，建立包含患者基本屬性信息的主索引記錄，確�；颊叩母鞣N電子病歷相關(guān)記錄正確地與患者唯一標識號碼相對應。
|
|
|
第十四條第一款第一點：為患者（含急診或其他情況下身份不確定的患者）創(chuàng)建電子病歷并賦予統(tǒng)一編碼的唯一標識號碼功能，通過該標識號碼可查閱患者的電子病歷相關(guān)信息。
|
|
|
第十四條第一款第二點：為每位患者電子病歷創(chuàng)建唯一的主索引，并記錄患者基本信息（應當至少包括患者姓名、性別、出生日期、常駐地地址等），并能夠?qū)颊呋拘畔⑦M行必要的修改、補充和完善。
|
|
|
第十四條第一款第三點：提供電子病歷主索引自動查重功能，按照患者基本信息記錄對系統(tǒng)可能存在的重復記錄給予提示并由人工確認。
|
|
|
第十五條：提供電子病歷自動查重功能，能夠?qū)⑼换颊叩亩嘀仉娮硬v與該患者唯一標識號碼進行關(guān)聯(lián)，通過唯一標識號碼可查閱患者的電子病歷相關(guān)信息。
|
|
|
第十九條第二點：提供以自由文本方式錄入診斷（或主訴）、手術(shù)及操作名稱的功能。
|
|
|
第二十條第一款第二點：提供以自由文本方式錄入診斷、手術(shù)及操作名稱的功能。
|
|
|
第二十條第二款第二點：提供為臨床試驗病例、教學病例等特殊病歷資料進行標識的功能。
|
|
|
第二十三條第二點：提供住院病歷創(chuàng)建信息補記、修改等操作功能，對操作者應當進行身份識別、保存歷次操作印痕、標記準確的操作時間和操作者信息。
|
痕跡保留
|
|
第二十四條第一款第一點：支持各類型病歷資料錄入與編輯的功能。
|
支持文字、圖片、表格等等。
|
|
第二十四條第一款第二點：提供按照病歷類型、內(nèi)容和要求，根據(jù)電子病歷系統(tǒng)中相關(guān)數(shù)據(jù)，自動生成住院病歷部分內(nèi)容的功能。
|
|
|
第二十四條第一款第三點：提供自由文本錄入功能。
|
提供仿MS Word的用戶體驗，能自由錄入文本。
|
|
第二十四條第一款第四點：提供在住院病歷指定內(nèi)容中復制、粘貼患者本人住院病歷相同信息的功能；禁止復制、粘貼非患者本人信息的功能。
|
在粘貼文檔內(nèi)容時需要進行數(shù)據(jù)過濾。
|
|
第二十四條第一款第五點：提供模板輔助錄入功能，可以按照住院病歷類型、疾病病種選擇所需模板；模板內(nèi)容應當符合該疾病現(xiàn)有診療指南、規(guī)范要求。
|
|
|
第二十四條第一款第六點：提供為醫(yī)療機構(gòu)定制各類型住院病歷默認樣式的功能，默認樣式包括紙張尺寸、字體大小、版面設置等。
|
支持頁面設置，支持自定義紙張大小，支持信紙樣式的網(wǎng)格線。
|
|
第二十四條第一款第七點：提供暫時保存未完成住院病歷記錄，并授權(quán)用戶查看、修改、完成該病歷記錄，提供住院病歷記錄確認完成并記錄完成時間的功能。
|
|
|
第二十四條第一款第八點：提供住院病歷記錄雙簽名功能，當由實習醫(yī)師、試用期醫(yī)務人員書寫病歷時，應當經(jīng)過本醫(yī)療機構(gòu)注冊的醫(yī)務人員審閱、修改，并保留書寫者與審閱者的雙簽名。
|
提供痕跡保留、審閱標記等功能。
|
|
第二十四條第二款第一點：提供在住院病歷記錄中插入患者基本信息、醫(yī)囑信息、輔助檢查報告、生命體征信息等相關(guān)內(nèi)容的功能。
|
|
|
第二十四條第二款第三點：提供結(jié)構(gòu)化病歷記錄項目內(nèi)容合理性檢查與提示功能，包括項目獨立檢查和項目之間、項目與患者個人特征間的相關(guān)性檢查。
|
|
|
第二十四條第二款第四點：提供包含展現(xiàn)樣式的病歷記錄錄入編輯和保存功能；提供所見即所得的病歷記錄錄入編輯功能。
|
|
|
規(guī)范第二十四條第三款第一點：提供在住院病歷記錄中嵌入圖片、表格、多媒體數(shù)據(jù)并進行編輯的功能。
|
|
|
第二十四條第三款第三點：.提供常用術(shù)語詞庫輔助錄入功能，術(shù)語詞庫包括癥狀名稱、疾病名稱、藥物名稱、手術(shù)名稱、護理常規(guī)名稱等.
|
|
|
第二十四條第三款第四點：提供結(jié)構(gòu)化（可交互元素）模板輔助錄入功能，并在病歷記錄中保留結(jié)構(gòu)化模板形成的結(jié)構(gòu)。
|
|
|
第二十五條第一款第一點：提供病歷記錄的修改和刪除功能，并自動保存病歷記錄修改的痕跡；對已確認完成的病歷記錄進行修改時，系統(tǒng)自動記錄修改內(nèi)容、修改人、修改時間。
|
|
|
第二十五條第一款第二點：對病歷記錄按照用戶修改權(quán)限管理的功能，允許上級醫(yī)務人員修改下級醫(yī)務人員創(chuàng)建的病歷記錄。
|
|
|
規(guī)范第二十五條第二款：提供病歷記錄禁止修改的設置功能。
|
|
|
第二十六條第二款第一點：提供創(chuàng)建結(jié)構(gòu)化模板功能，結(jié)構(gòu)化模板至少包含單選項、多選項、必填項、填空、不可修改文本等元素。
|
|
|
第二十六條第二款第二點：提供模板中定義自動宏替換元素功能，宏替換元素可用于在病歷記錄中經(jīng)常出現(xiàn)的患者姓名、性別、主訴等內(nèi)容。
|
|
|
第二十六條第二款第三點：提供結(jié)構(gòu)化模板中，對結(jié)構(gòu)化元素設定錄入方式、取值范圍、校驗規(guī)則等屬性功能。
|
|
|
第四十二條第一款：提供可瀏覽患者各類電子病歷內(nèi)容的獨立軟件。
|
|
|
第四十三條第三款第二點：提供與病歷數(shù)據(jù)同時展現(xiàn)相關(guān)修改痕跡信息的功能，至少包括修改時間、修改人、修改內(nèi)容等信息。
|
|
|
第四十四條第一款第一點：提供將電子病歷中的各類醫(yī)療記錄進行紙張打印的功能，打印格式符合衛(wèi)生行政管理部門對紙質(zhì)病歷的相關(guān)要求。
|
|
|
第四十四條第一款第二點：提供電子病歷記錄按照最終內(nèi)容（不含修改痕跡）打印的功能。
|
|
|
第四十四條第一款第三點：提供電子病歷打印預覽、接續(xù)打印功能。
|
|
|
第四十四條第二款第一點：提供將一次就診的病歷資料全部或部分進行批量打印的功能。
|
|
|
第四十四條第三款第二點：提供將電子病歷中的各類醫(yī)療記錄以電子文件格式導出的功能。
|
應該必須支持XML格式。
|
|
