新一代跨平台(desktop,browser|web|B/S,mobile)電子病歷編輯器發展展望



~------------------------------------------------------------------------------------------------
       信譯web電子病歷編輯器 創新采用JS+Canvas方案(獨創) 。是時候 擯棄其它所有js+html dom方案web電子病歷編輯器。信譯完全自主實現布局和排版,不受限於瀏覽器排版引擎,讓WEB電子病歷編輯器擁有和桌面版一樣的功能,性能也更優異。
~------------------------------------------------------------------------------------------------
微信號: ThinkEditor

演示地址:www.thinkeditor.com
~------------------------------------------------------------------------------------------------

       電子病歷編輯器伴隨醫療信息化事業的推進迎來了發展的黃金十年。經過十年的大浪淘沙,市場上幸存下來的自主電子病歷編輯器數量稀少。功能完備、低耦合易於集成的優秀電子病歷編輯器更是鳳毛麟角。電子病歷在醫療軟件中的重要性早已形成行業共識,筆者將對電子病歷編輯器的行業現狀進行分析,並對下一代的電子病歷編輯器進行設想和展望。

現存問題一:電子病歷數據格式未全結構化

方案一:采用自定義字符串格式

優點:
1、格式靈活
缺點:
1、需自己編寫病歷格式解析器,工作量大,容易出錯
2、沒有結構化,第三方無法提取數據

方案二:采用XML格式的半結構化病歷數據

優點:
1、解析方便
缺點:
1、受XML結構限制,結合豐富的電子病歷業務需求時,導致數據冗余,可讀性較差
2、半結構化電子病歷,不利於數據共享

       不是基於XML的電子病歷就是全結構化電子病歷,全結構的概念是與現實認知或業務需要的數據對象在后台數據結構中是可以直接檢索和提取的。
       例如都昌電子病歷編輯器,也是典型的半結構化電子病歷,數據都是放到 節點中的並按流模式依次布局,遇到XParagraphFlag標志則布局器進行一次換行操作,其它復雜節點實現也存在相同問題,導致第三方無法通過XML直接取得某個段落或其它數據節點,必需通過都昌的編輯器進行提取,第三方使用XML受到很大限制。
       如此,非結構化電子病歷或半結構化電子病歷不利於第三方進行大數據分析,想轉換為全結構化的CDA(臨床文檔結構)也十分困難。

半結構化電子病歷冗余數據格式示例

半結構化電子病歷冗余數據格式示例

       XML無法做到全結構化,相關病歷數據提取、分析、整合業務還需要求助於電子病歷編輯器供應商, 這會損害醫療軟件開發商的利益。這也是醫療軟件開發商千方百計想要自主開發電子病歷編輯器的原因,面對電子病歷編輯器的高門坎,醫療軟件開發商會消耗大量資源最終頭碰血流沒有成果得不償失甚至錯過發展機遇。
       專業電子編輯器供應商提供編輯器細分服務,醫療軟件開發商整合各方資源,把精力和資源聚焦到醫療行業軟件上面來,這本是互利共贏的產業分工關系,卻困在了電子病歷編輯器這一症結上面。
       筆者認為全結構化電子病歷是解除這一症結的關鍵。 第三方在只使用全結構化電子病歷文本文檔的情況下,不依賴電子病歷編輯器就能實現數據提取、分析、整合、共享,從而實現病歷數據與編輯器解綁。讓電子病歷編輯器不再是醫療軟件開發商的掣肘,合作共贏才是產業發展主流。

現存問題二:電子病歷后台數據內容冗余,病歷過大

       筆者分析了市面上的典型的半結構化XML電子病歷入院記錄主頁,在頁面內容相同,頁面元素數量功能配置相同的情況下,該XML大小達到了驚人的500K以上。同時查看后台病歷數據,人眼明顯的感覺閱讀困難,數據冗余混亂。理想的文檔視圖是以段落為單位,但是半結構化病歷數據雜亂無法段落結構導致人眼進行內容檢索時閱讀十分困難,難以找到關鍵信息。
       病歷數據過大,會導致存儲備份成本高啟,病歷下載解析耗時長,致使整個病歷應用系統體驗不佳,無法提升醫療應用系統競爭力。
       病歷數據雜亂、冗余是電子病歷高速發展階段粗放管理,創新動力不足的結果。有必要采用一種兼顧可讀性,同時合理組織病歷后台數據,數量級精簡壓縮病歷內容的電子病歷數據格式以適應新一代電子病歷編輯器的發展。

現存問題三:CS版電子病歷技術路線陳舊

       現有被驗證比較成功的桌面版電子病歷大多基於MS WORD、開源DELPHI的TX控件、開源OpenOffice、C# .net框架。以上技術路線的優缺點網上資料很多,此處不再詳述。
       總結如下:開源產品內核臃腫,裁剪集成困難。微軟micosoft框架平台依賴過強,無法跨平台。

現存問題四:電子病歷未實現跨平台,BS版本產品不成熟

       傳統醫療廠商大多嚴重依賴桌面系統,隨着行業的競爭加劇,越來越多的互聯網廠商開始進入傳統醫療行業,同時傳統醫療廠商也在積極開拓互聯網產品。在CS版電子病歷市場日益飽和的今天,電子病歷行業急需一個功能全面、穩定的、跨平台的電子病歷編輯器。
       BS版電子病歷可以借助瀏覽器實現跨平台,是一個不錯的發展方向。比較主流的方案是使用HTML+JS架構,但是因為前端技術儲備不足且與電子病歷行業結合不緊密,導致大多數產品可用性都不高。電子病歷內容分頁、表格拆分、元素聯動相關特色算法移植到前端時,使用IE內核、webkit內核、blink內核的瀏覽器應用都無法介入html解析刷新過程,導致一系列的效率、適配問題。 究其原因是因為傳統醫療行業和電子病歷編輯器廠商絕大多是傳統桌面開發起家的,在互聯網WEB領域技術儲備不足,並且需要投入大量人力迭代功能適配顯示差異。
       互聯網行業的繁榮,促進了前端行業的高速發展,開源前端web編輯器多如牛毛,並且大同小異。因為網頁沒有頁面沒有頁概念,所以所有的開源web編輯器都不支持內容分頁、表格拆分等文檔基礎功能,都需要深度二次開發。
       網易旗下的有道雲筆記等雲筆記產品,仍然是一個普通web編輯器,內容分頁、表格拆分等功能實現不理想,進化不夠離文檔編輯器還差得遠。目前只有金山WPS有實力實現了HTML+JS方案的文檔編輯器,跨平台顯示較為理想,但是如果想與電子病歷編輯器結合又存在內核臃腫、成本高等問題。
       總體來說前端編輯器如果在開源WEB編輯器項目上做二次開發完善,需要深厚的功底及人力資源投入。
       在中美競爭日益激烈的今天,一個去微軟化,跨平台甚至能兼容鴻蒙操作系統的電子病歷編輯器一定會有很好的未來。

--------------------------------------------------------------------

理想的下一代電子病歷編輯器有如下構思和期望:

1、病歷數據全結構化,易共享

2、病歷數據精簡壓縮,易讀

3、跨平台,顯示一致性

4、跨平台,使用方式、接口、事件通知模型一致性

--------------------------------------------------------------------


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM