電子病歷編輯器,簡稱EMRE(EMR Editor)。EMRE是電子病歷系統的核心關鍵基礎技術。在電子病歷系統中起到了不可代替的做用,使用一個合適的電子病歷控件每每能夠起到事半功倍的做用。那麼當前電子病歷控件的主要模式和實現思路有哪幾種?前端
服務端控件模式。這種典型能夠參考.Net技術流派的服務端控件。它的好處就是封裝性更好,開發者使用起來更加的方便透明,而無需關心內部的複雜實現邏輯。可是壞處也是很明顯,當你選用這種技術的時候也意味着你被.Net綁定了,你只能選擇.Net支持的語言去進行開發。並且服務端控件意味着更加頻繁的客戶端與服務端的交互。從控件提供商的角度來看,這種產品顯然是不能知足市場上各類語言和技術流派的。web
2.1純前端控件模式。這種模式簡單來講就是和後端技術無關,徹底使用 Html,JavaScript和CSS進行製做控件。這種模式在互聯網盛行的狀況下愈發可以顯示出他的優點,由於互聯網的入口是瀏覽器,而Html,JavaScript和CSS做爲W3C的統一標準已經被全部的現代瀏覽器而支持。相似的控件能夠查看百度開源的富文本編輯器UEEditor。這種文本編輯好處也很明顯通用適用於全部的開發語言和瀏覽器。我我的更加傾向於使用該種技術方案去實現電子病歷控件。後端
2.2 ActiveX控件模式。這個其實Native模式的一種擴展,經過在Windows平臺下對Native控件提供COM接口從而實如今IE系列瀏覽器中實現操做電子病歷,可是這種模式顯然是限制更多:只能基於Windows平臺,只能基於IE內核的瀏覽器。瀏覽器
以上我從純技術角度分析了,當前電子病歷控件純在的兩種模式。那麼哪一種方式更加先進呢?第一種方式有他的優越性那就是操做更加的方便,可是它想要適用各個操做系統就須要開發不一樣的平臺版本,這對任何一家軟件開發商來講都須要巨大技術的投入,甚至有多是徹底不可能的。並且在互聯網大潮席捲各行各業的狀況下,第一種模式就有點背道而馳了。是第二種Web模式顯然更加的先進,它適用的範圍更加的廣,並且要實現跨平臺也更加的容易,因此它將來電子病歷控件的發展方向。那麼當前在我國醫療行業領域有哪些電子病歷控件可供你們選擇?他們又分別屬於上述模式中的那種模式呢?編輯器
1. EmrPad。這個控件想必只要從事醫療電子病歷開發的工做者都據說過它的大名。他是有現就任於嘉禾電子病歷科技的陳聯忠基於開源的AbiWord控件獨創開發的。現已被嘉禾徹底收購,從產生的電子病歷份數來講,此控件截止當前當屬第一。這也是國內首先有意識去獨立發展電子病歷控件的始祖。它屬於咱們前面說到兩種模式的Native模式。操作系統
2. DCWriter。南京都昌公司出品的產品。它是有都昌公司主要創始人袁永福親自設計和基於NET平臺開發的。它目前存在兩個版本分支,第一個是傳統的Winform控件,改分支版本主要經過NET平臺的GDI+技術進行實現,第二個版本是基於NET平臺的服務端控件,該控件爲咱們上面描述模式的Web模式下的第一種方式。相比國內其餘廠商只提供Native控件的模式,南京都昌的產品已經先走了一步實現了Web模式。並且兩種控件徹底實現了EMR DOM結構的徹底互解析,從傳統的WinFrom控件升級到Web服務端控件徹底不用擔憂,文檔解析出錯這個讓人糾結的問題。當時咱們開發電子病歷控件時,通過慎重的考慮和調研,本着從長遠發展的角度來講最後選擇了更加優秀和發展前景的DCWriter。設計
3.中標普華Office。目前中標軟件基於本身的Office也對醫療行業推出了深度定製電子病歷控件。宣傳號稱是支持目前主流的操做系統,也屬於咱們上面討論的Native模式。可是最致命的缺點是軟件大小太過龐大,引用過於複查。這給實際部署和分發形成了很多的困難。orm
4. 基於微軟Office。在電子病歷發展的初期,還曾經有不少廠家在沒法找到合適電子病歷控件狀況下,基於Word進行了簡單封裝開發。可是這種方式就更加不靠譜了,首先若是版權問題微軟就能把你整死!接口
5.基於其餘開源項目。開源有開源項目的好處就是免費,可是對公司的技術能力要求更高。開源項目應用好了是利器,應用不是致使項目失敗的比比皆是,醫療項目每每開始週期短,項目任務重,因此我的不推薦基於開源項目去開發電子病歷,一旦發生問題沒有售後支持極有可能致使項目的流產。ip
上述就是本人混跡醫療行業這麼多年,在電子病歷控件這個話題之王上的一些經驗和看法。DCWriter在我看來是如今電子病歷行業中的最優基礎控件,由於它徹底基於XML進行存儲,實現了Web模式的服務端控件(這也是國內首家)。同時但願DCWriter能支持更加通用化的純前端控件模式。
咱們選擇了DCWriter,你們呢?