基于HTML5的电子病历编辑器 X-EMR

bensenplus

已于 2023-12-28 11:17:17 修改

阅读量7.5k

点赞数 10

文章标签： html5 编辑器 javascript

于 2022-11-12 11:11:08 首次发布

本文链接：https://blog.csdn.net/u011065436/article/details/127735992

版权

HTML5文档优势

近年来，随着医疗信息化建设的不断推进，推进电子病历区域共享，甚至全国共享，已经是一个不可回避的话题。

电子病历结构化数据的信息共享在技术上不存在难度，但是电子病历文书的数据共享在不同医疗机构，不同HIS厂商的共享很难形成统一的标准。

传统的桌面版电子病历，由于数据格式封闭，需要本地安装或控件方式安装，开发技术门槛高，难以二次开发，操作系统兼容程度低等原因，逐步淡出医疗信息化厂商，医疗机构信息化人员的视线。

网页技术HTML5是互联网成熟开放标准， 基于HTML5技术的电子病历编辑器近几年来已经成为各大医疗信息化厂商的必选项，特别是具有创新精神和长远战略目光的新型医疗信息化行业公司的关注焦点和战略选择方向。

传统的医疗信息化厂商的研发人员由于从业经历和历史经验的原因，基本是以J2EE技术为主的传统web技术和C#技术为主的客户技术。

而以熟练掌握前端技术的研发人员基本来自于互联网公司，对于医疗信息化行业的业务和需求了解，没有长期从事医疗信息化行业的经历和经验。

因此，一个使用HTML前端技术，又能贴合医疗业务需求的电子病历编辑器技术研究是一个必要课题。一个好用的电子病历编辑器应该具备特性是：

功能丰富，满足多场景书写需求；
结构化数据，满足电子病历数据集标准；
兼容性，兼容PC移动设备，操作系统无关性；
自由开放API，支持功能可扩展；

技术路线

目前可选的HTML编辑器技术路线主要有：

大厂在线文档编辑器：如金山在线文档，腾讯文档，微软在线文档，这些大厂的在线文档编辑由于定位于全功能的在线Word文档共享，功能复杂，也不太可能开发代码给第三方接入，因此不在考虑范围之内。

基于UEditor的HTML编辑器：UEditor是由百度web前端研发部开发的所见即所得的开源富文本编辑器，功能较复杂，实用于富文本编辑，用于二次开发为电子病历编辑器，入手门槛低，但加载大文档后，由于底层设计的原因，运行效率已经变低，另外对于电子病历的高级需求来说，比如打印分页反而是难以下手。开源技术上曾出现过一个SoDiaoEditor的电子病历编辑器，后来不知道什么原因没有持续更新下去，可见直接拿UEditor也不是一条合适的路，但可以作为技术参考。

基于Cavans的文档编辑器：canvas是HTML的一个画图元素，具有底层控制的画图API，底层变成可控性高，但是用于做为电子病历文档编辑器缺点也很明显，首先是二次开发者无法操作内部节点元素，其次是在加载大文档效率低下，再次是由于过于偏底层，对于文档的排版，控件的展示全部要编写代码，代码复杂度高，另外就是打印文档主要以位图输出，像素分辨率低。因此不建议采用此技术方案做为电子病历编辑器。网络上也出现了使用ThinkEdit的Canvas电子病历编辑器，有可能由于以上原因，后续也不再做代码更新。

纯HTML5的文档编辑器：目前是一个最优选择，原因如下：

HTML5语言标准是一般开发人员甚至非技术人员都能轻易掌握的文档格式， HTML5浏览器是一个成熟天然的文档浏览器，不需要开发人员过度关注流式文档排版等底层细节技术，只要掌握HTML基本语法，其他留给浏览器来负责展现。

网页浏览器也是一个天然的成熟病历文档浏览器，只要病历文档格式遵循HTML5标准，就能够在不同操作系统的电脑桌面和移动终端中无差别展示病历文档。国产网页浏览器一般都是基于开源浏览器内核开发，因此使用HTML5病历编辑器对于国家推行的软件国产化更是有力的支持。

目前市场上能够实际落地使用的电子病历编辑器基本都是以HTML5格式为编辑器的展现标准，主要有以南京都昌BS版电子病历，大成电子病历为代表，已经有一定规模的市场用户规模，客观证明了HTML5编辑器技术的实用性。

存储格式

电子病历文档存储格式的选择，由于电子病历文档共享是发展趋势，所以非开发式的自定义文档格式给淘汰也只是一个时间问题，从发展的角度，开放式文档结构会是开发商及医疗机构客户的优先选择。电子病历文档数据所有权目前是医疗机构，而不是软件开发厂商的，更需要软件厂商对医疗机构开放电子病历结构。

目前开放式病历文档结构有如下选择：

XML数据格式

XML数据格式优势是容易编码，人工可阅读程度高，容错性高，HTML5文档结构上也是遵循XML标准的结构。XML用于结构化电子病历数据的存储是非常适合的，但是用于文档结构节点的存储就显得比较臃肿复杂了，解析为文档时需要代码还原为HTML节点,效率相对低下。

目前市场占有量比较大的都昌BS版电子病历采用的是XML数据格式存储，优点是兼容客户端版的电子病历编辑器，但也是为了兼容，病历数据存储结构相对复杂，二次开发解析难度较大。CSDN中有一篇文章也做过分析 XML半结构化存储的优缺点。

JSON数据格式

JSON数据格式是一种轻量级的数据交换格式，流行于前端技术开发。HIT行业广泛采用的HL7标准，已经由3.0版本的XML格式演进到了最新的FHIR版本，其中数据协议就已支持JSON格式。另外国家医保接口标准也推荐使用JSON数据格式。

所以JSON也适合使用存储树状层次结构不多（5层以下）的结构化数据，但不适合用于存储层次结构较深的病历文档结构（通常10层以上）。

HTML5数据格式

以HTML5数据结构的病历文档可以直接用任何普通浏览器就能打开，极其方便病历文档跨业务系统共享，也直接利用了浏览器的原生解析能力，读取性能优越。

医疗信息软件开发人员可以根据实际业务场景需要，调用电子编辑器的开发API，或直接编写JavaSript脚本，修改处理电子病历文档节点，绑定文档处理事件等操作。比如：在电子病历文档中选取业务系统的诊断字典，下诊断后，存储到业务系统。这些完全可以不依赖于电子病历编辑器接口，直接用普通的JS处理即可，有非常高的自由度。

结论：“不做单选题，做多选”。充分利用XML，JSON和HTML的各自优势

直接使用HTML5作为病历文档节点存储格式、使用XML和JSON作为病历结构化数据存储格式，XML格式和JSON格式可以相互转换， 目前应该是最优选择。

也能容易做到文档视图和文档数据分离的处理，文档视图用于用户展示，文档数据用于表结构化存储，甚至直接提供给数据集成平台进行数据采集和交换。

以JSON存储的全结构化电子病历数据可以直接提供给国家或政府电子病历共享平台，以XML存储的数据格式直接以CDA（HL7临床文档结构）存储，直接支持HL7卫生信息交换标准。

产品实践

基于以上结论，本人认为基于HTML5 电子病历编辑器将成为未来电子病历系统的主流选择，本人也用一些业余时间尝试了研发了一款HTML电子病历编辑器，使用了HTM5底层API接口，性能效果较好，HTML文档结构简洁可读，支持编辑过程中自动分页，不依赖服务端，纯客户端js脚本代码，有感兴趣的可以留言进行交流。　

在线演示地址： http://www.x-emr.cn

命名为X-Emr : Exchange Electronic Medical Record，以电子病历数据交换共享为目的，跨平台的、跨终端的、开放易用的电子病历文档编辑器。

在线电子病历编辑器设计页面

http://www.x-emr.cn/edit/999.html