新一代跨平台(desktop,web,mobile)电子病历编辑器发展展望

新一代跨平台(desktop,web,mobile)电子病历编辑器发展展望

#########################################################################
       本方案web电子病历编辑器 创新采用JS+Canvas方案(独创) 。是时候摒弃其它所有js+html dom方案web电子病历编辑器。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、跨平台，使用方式、接口、事件通知模型一致性

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

    作者长期从事电子病历编辑器开发工作，团队使用C/C++作为主技术栈，熟悉系统底层结构原理，具备全栈开发能力。

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

微信号：ThinkEditor

演示地址： www.thinkeditor.com

业务设计及展示地址： 功能演示