论电子病历文本编辑器

论电子病历文本编辑器

袁永福

28348092@qq.com

http://www.dcwriter.cn

2013-5-12

 

前言

受chisc.net网站的邀请，特撰此文，一家之言，如果有不妥，敬请指出。

 

作者简介

袁永福，2001年东南大学毕业，从事IT十多年，2008年度微软MVP，著书立说。现在南京从事电子病历编辑器相关工作。博客网址http://www.cnblogs.com/xdesigner。

电子病历文本编辑器概述

电子病历编辑器，简称EMRE（EMR Editor）。EMRE是电子病历系统的核心关键基础技术。在HIT大市场中，EMRE已经是一个专业子市场。为什么会形成这个子市场，笔者在此讨论一番。

其实观察整个医疗行业，所有的人都是围绕着治病救人这个中心而忙碌着，无论是卫生系统的官员、医院各级管理人员、医务人员、各级医疗服务单位，还有我们这么多的HIT企业等等都是的。如果人不生病，全球立马有几千万人失业。

在医生治病救人的过程中会产生大量的信息，这些信息中最为重要的就是病历，如果没有这些病历，诊疗过程就成为低水平的重复又重复，很多的涉及到生命的资料无从可查。因此病历信息是整个医疗信息化中的核心信息。数据库存储的是病历数据、网络传输的是病历数据、终端显示的是病历数据、打印机输出的是病历数据、后台分析的是病历数据、医疗司法活动的基础证据也是病历数据。

这里的病历数据范围比较广，包括各种病历文书、医学影像、检查检验结果等等。从HIT系统应用的角度上来说，各种类型的病历数据处理手段不一样，从而形成各个子市场。

比如医学影像数据的处理比较专业，由此形成PACS子市场，里面已经有很多厂家，甚至还形成了医学显示器这种微市场。那里的人卖硬件卖软件，生意兴隆。

病历文书数据也是病历数据中的一个关键数据，也是应用最为频繁的数据。毕竟一个人看病，可以不拍片子、不检验检查，但医生肯定会写下一段文本病历。PACS系统折腾一番生成的高清图像也只是在医生诊疗过程中作为参考，关键还是医生写下的病历文本。

因此在目前的阶段，所有的诊疗过程产生的最为关键的信息是病历文书。

因此在医学信息化中，病历文书是作为最为重要的信息是需要得到最为特别的照顾。

在过去的传统HIS阶段，应用系统对病历文书的照顾就是一个最简单的TextBox，高级一点的用上MS WORD。不过这显然是远远不够的，那样做不是与时俱进，而且HIT客户已经越来越专业越挑剔了。

理论上来说，医生拿着菜刀也能做手术，实际上那将是非常恐怖的事情。但实际上，很多医生还是拿着菜刀写病历，而专业的EMRE就是医生写病历时的上好工具。

EMRE子市场

现今开发和使用电子病历系统不可避免的要使用到EMRE，这基本上是绕不过去的。对于EMRE，软件开发公司主要有自行开发和对外采购的方式来获得。

开发EMRE的技术那是老复杂了，难度是非常非常高，业界能开发编辑器的人才凤毛麟角。因此一些HIT业务型软件公司自主研发EMRE那是勇气可嘉的，至于能否成功那只能是尽力而为了。

笔者的观察中大多数软件公司是搞不定自主研发EMRE的，经过一番折腾，弄得头破血流的，最后还是转而寻求外购EMRE。于是就形成了非常专业的EMRE子市场。

EMRE子市场不大，但由于掌握了技术高地，因此在HIT大市场中是还是比较关键的。大家讨论电子病历系统时必然会提到这个系统中使用的EMRE。大家所说的病历控件基本上就是指电子病历文本编辑器控件。

很多HIT企业在外购EMRE时都想同时购买源代码，笔者觉得这是不现实的也是没有多少实际意义的。

目前的EMRE企业基本上是不会出售源代码的，这事关中国国情，大家都懂的。通过非正常途径获得的源代码，那是有相当的法律风险，因为国内HIT圈子不算大，有一定的风险被EMRE厂家发现，引起纠纷，而且不管结局如何，医院甲方都会有想法的。

也存在个人出售编辑器代码，很有可能是网络上已经流传的代码，特别是ZYTextDocumentLib的源代码。笔者觉得这对于正规的HIT企业来说没多大作用，因为改造这些代码并进行二次开发的过程差不多等于走回自主研发EMRE的老路。

另外购买编辑器代码并没有多少实际意义。HIT企业购买代码无非担心EMRE企业倒闭转行，使得编辑器无法更新换代。根据笔者观察，现实中HIT企业的管理者会让程序猿们时刻忙于项目，天天干活，特别是高级程序猿更是忙得团团转；此时高级程序猿不会有大把的时间认真系统的消化吸收编辑器代码的，而初级程序猿是没有相关能力的。因此如果编辑器有BUG或者新功能需求，基本上还是要找EMRE企业。

这就是即使是东软这样的HIT巨头也没有自主研发EMRE控件的原因之一。

另外EMRE企业之所以成立，也必然有相应的技术力量，否则接下EMRE这种重活是害人害己。

另外EMRE企业相比于HIT企业更不在乎企业的规模。HIT业务型企业天天拉单子做项目，实施一个有点规模的医院的HIS/EMR，没有个一年半载是搞不定的，大批人员驻场开发那是常见，常年的驻点运维工程师也是常有的。因此HIT企业虽然人多有规模，当几个项目同时运行时还是会人手不够。

但EMRE企业不一样，它是做通用产品的，它的客户都是懂技术的，技术人员之间的沟通交流速度是很快的，而且所有HIT企业对于EMRE的需求的交集是不大的，无需大型团队来应付。EMRE企业专注于特定技术钻研，更在乎人员的精干而不是数量。因此小规模企业也能胜任EMRE业务。

实施HIT项目时，接口工作量不小。现在很多医院的系统都是万国系统，各种牌子的系统纠缠在一起，产生了大量的软件和硬件接口需求，各个HIT企业、甲方内部小集团之间还存在互掐的现象；此外还有医保银行相关的接口，这些接口工作也耗掉了不少HIT企业的精力。

相比而言EMRE企业的接口工作量少的多。技术上EMRE企业是强势的，HIT企业必须使用EMRE企业制定的开发接口。就这点而言，EMRE企业能省掉不少人力。

这些原因使得HIT企业可以追求做大或做强，但EMRE企业必然是追求做强而不是做大。

EMRE控件产品及技术路线介绍

目前业界存在一些EMRE控件产品及技术路线，在此介绍几种常见的：

基于标准TextBox控件进行开发

基于TextBox控件来开发EMRE那是最为原始最为简单的方式。比如在用户界面上，放一个“主诉”文本标签，后面跟着一个TextBox用于手动录入主诉文本，现病史也类似。在存储上，可能是主诉内容存一个文本型字段，现病史内容存一个文本型字段。

这种方式实现简单，几十年前就出现了，但现在早就OUT了，若还拿出来都不好意思见人了。

基于RichTextBox控件进行开发

很多开发工具提供一个RichTextBox控件，实际上就是Windows自带的RichTextBox控件的简单包装。

使用RichTextBox控件能实现一些格式文本的编辑、录入，文字格式的设置，能插入图片，简单的表格。

不过基于RichTextBox控件进行一些深入的开发就不行了。比如留痕、续打、知识库等等，此时一些开发企业就骑虎难下了，终究是要放弃的。

基于MS WORD进行开发

         一些EMRE是基于MS WORD进行开发。其优点如下：

1.       MS WORD的文档编辑器功能是任何其他文本编辑器所无法逾越的。文字、图片、表格等等都是至尊级的，而且MS WORD应用广泛，群众基础好。基于它开发，在文档编辑用户体验上来说，用户是很容易接受的。

2.       MS WORD的二次开发接口比较多，各种支持COM的开发工具都支持。而且MS WORD的开发学习资源比较丰富，网上能找到很多。

不过使用MS WORD进行开发也有不少缺点：

1.       MS WORD不是免费软件，使用它必须购买一个完整的MS Office软件包，这是一笔不小的版权费用。医院可能拒绝使用盗版MS WORD，此时会比较大的增加项目成本。比如有微软经销商报价MS OFFICE2010为4000元/套。这样就很不利于HIT企业市场销售。

2.       客户端电脑必须逐个安装MS WORD，部署工作量比较大。而且不同版本的MS WORD的开发接口存在一定的兼容性问题，增加软件开发、部署和调试的难度。比如不同的客户已经安装了WORD2003、WORD2007、WORD2010等等，此时麻烦不小。

3.       MS WORD开发是基于OLE自动化技术，使用了跨进程的操作，操作不当系统中会留下MS WORD的进程，容易资源泄露，因此一般避免在服务器端使用MS WORD。

4.       大量的电子病历特定业务功能使用MS WORD是无法实现或者很难实现的。比如痕迹保留和三级权限控制；半结构化；续打、整洁打印和留痕打印；对于B/S系统，如何将MS WORD文件传到服务器上也是个难题；难于实现知识库。而且生成的WORD文件格式复杂难于解析，难于进行统计分析。

基于MS WORD开发电子病历编辑器可以在某些情况下应急，但由于上述无法解决的缺陷，从长远上来说是不可取的，终究是要放弃这种方式的。

基于开源DELPHI的TX控件进行开发

TX控件以前是一个免费开源的DELPHI控件，现在作者据此成立公司不再免费开源了。TX控件是用DELPHI开发的，有COM接口。因此很适合DELPHI或VB/PB的开发。

业界还有大量的已经运行中的信息化系统是由PB/VB/DELPHI开发的，而且还有一些新系统也是靠这些老技术开发的。因此业界还存在不少使用TX开发的EMRE控件。

使用TX控件开发编辑器控件，能轻松的实现常规的文档编辑功能，比如图文混排、表格、图片等等。不过想要开发超出TX控件能力范围而实现新的文档编辑功能就非常难了。比如表格线上下拖拽调整表格行高度、续打等等。

另外TX控件是通用文档编辑器控件，而电子病历行业很多特种业务需求就很难实现。有些鸡肋。

为实现电子病历行业特定需求，需要在TX基础上开发重大新功能，这需要深入理解TX的内部结构。只要是带格式文档编辑器控件都是非常复杂的，理解起来那是相当难的，而且现在的DELPHI熟练程序员越来越少，因此对于基于TX开发编辑器的厂商，许多电子病历业务特定功能很难实现或者基本上是不可能实现。

HIT企业可以向TX供应商申请加功能，不过HIT行业只是TX供应商的市场的一部分，人家或许不在乎为这点市场而大改TX控件，因此进展缓慢。

另外DELPHI本身也是一项老技术，虽然还能用于开发一些新系统，不过相关人才会越来越少，系统维护将逐渐成为一个大问题。笔者觉得此时不未雨绸缪搞转型，以后想转就来不及了。

易讯电子病历编辑器

易讯电子病历编辑器是天方达软件开发有限公司的产品，其软件界面如下：

 

技术分析易迅电子病历编辑器应该是Delphi开发的，可能是在TRichViewEdit的基础上进行二次开发的。支持自由的文档编辑，支持表格。控件程序文件大小为10MB。

易迅电子病历编辑器在常规的文档编辑器功能是差不多够用了，但有些功能做得还不够，在此挑出几个：

1.       谈不上支持半结构化技术。未发现支持XML技术。

2.       单元格无法单独的设置宽度，当编辑复杂表格布局时比较费劲。

3.       开发帮助文档太简单了。

4.       文字排版无法两端对齐，文字右边缘层次不齐，影响美观。

5.       图片可以编辑后无法修改已经改过的内容，无法撤销。

易讯编辑器的东家天方达公司还据此经营着一个电子病历文档的网络社区。任何人注册就可以上传和下载电子病历文档范文，这是他们的一个不错的特色。这里是病历文档范文，还谈不上是病历文档模板。

病历宝典

病历宝典软件是北京华信慧典科技有限公司研发的电子病历编辑器。其用户界面如下：

 

该软件也应该是使用Delphi基于TRichViewEdit开发的。相比易迅病历编辑器，其功能改善了不少，主要有：

1.       总体感觉用户界面比易迅编辑器要现代多了。相比而言易迅编辑器的用户界面还是比较粗糙的。

2.       能进行文字的两边对齐了。

3.       增强了医学表达式。

笔者测试的是《慧典电子病历系统学习版》，这个版本有一个很要命的缺点，那就是当该软件显示对话框，比如插入表格对话框时，在Win7环境下，切换到其他程序后在切换回来，对话框将隐藏在主窗体后面，此时应用程序根本无法操作，只能强制杀进程。

由于是未注册版本，无法判断是否真的支持半结构化文档等重要功能。

初步感觉易迅编辑器和病历宝典编辑器存在微妙的关系，这不仅仅是共同是基于TRichViewEdit开发的原因。因为笔者发现这两个编辑器很多细节是高度一致的，猜测两者应该共享很多代码吧。

病历宝典的编辑器是不单独销售的，是集成在慧典电子病历系统中的，因此HIT企业不能指望它了。

基于开源OpenOffice进行开发

也有HIT企业在著名的开源OpenOffice的基础开发电子病历编辑器，OpenOffice保存的文件扩展名默认为odt（或ods,odp），这种文件实际上是ZIP格式，可以将odt扩展名改成ZIP，双击即可使用WinRAR打开。
使用OpenOffice进行开发的风险比Delphi开源控件为基础的高得多。因为OpenOffice比其他任何开源控件要复杂得多，底层程序基本上无人可以修改。

OpenOffice最早可追朔至1980年代，多次易主，现在归ORACLE所有。经过30多年的发展，已经包含1000多万行C++/Java混合代码，源代码文件有1.6GB大小，其中的功能模块不计其数，组件引用网格非常复杂，真是牵一发而动全身，为此历史上遗留下来了一些无法剔除的垃圾模块。下图就是OpenOffice中各个功能模块的引用关系图：

 

如此复杂的内部结构，使得OpenOffice确实能拿过来就能用，但基本上无法修改。只能在表面上做一些尽力而为的事情了。

另外其他的编辑器是轻量级的控件，程序文件都不大，而且是从用户界面上还是运行架构上都能紧密嵌入在应用程序中的。

但OpenOffice则是重型办公软件包而不是控件，功能齐全、文件数量多、体积庞大，精简下来也有近百MB大小，用于B/S开发时需要谨慎。

而且从运行架构上，OpenOffice的文档编辑用户界面虽然能嵌入到应用程序中，但后台还是跑着编辑器的独立进程soffice.exe/soffice.bin，出现了复杂易错的跨进程操作，应用程序有时候需要强制杀掉OpenOffice进程，这对操作系统运行环境比较伤。因此说基于OpenOffice开发的不是控件，而是软件包的二次开发。这点很类似MS WORD。

OpenOffice体积庞大的另一个原因就是为了实现跨平台的，它能运行在Windows/Linux/Mac OS/Solaris等多种操作系统，支持各种接口和规范。而国内电子病历客户端基本上都是MS Windows平台，OpenOffice的这些跨平台的功能对于EMR用户来说就是画蛇添足的了。

使用OpenOffce比MS WORD相比唯一的好处就是OpenOffice是自由软件的，没有版权现金成本，其开源的特性对于HIT企业来说其实是没啥实际作用，就跟小学生学奥数一样。OpenOffice文档编辑功能也很强大，但还是无法达到MS WORD的那种至尊境界。

使用OpenOffice会涉及到它的版权问题，中国国情是不尊重版权的，比如有些IT企业（特别是政绩企业）把OpenOffice或者开源操作系统简单封装一下，然后声称国产原创，跑到政府面前邀功套现套证书。

不过在此还是提一下OpenOffice的版权，以下内容摘自百度百科http://baike.baidu.com/view/406051.htm。

OpenOffice org采用GNU通用公共许可证（GPL）和Sun工业标准源码许可证（Sun Industry Standards Source License，SISSL）8的“双许可证”方式对源码进行许可；采用独立的公共文档许可证9（Public Documentation License，PDL）对发布在OpenOffice org网站上、但不期望集成进软件的绝大多数文档进行许可。

“双许可证”方式意味着要么应用GNU GPL许可证，要么应用SISSL许可证。当应用GPL许可证的时候，OpenOffice org源码中的库和组件功能将根据GNU LGPL进行许可。由于LGPL与GPL完全兼容，这样就能够鼓励更多的人参与到OpenOffice org社区建设中来。

SISSL则是为商业应用设计的。由于GPL许可证对于自由复制、修改、发布等权利的严格保证，某些软件商会因此而受限、不能参与到开放源码社区中来。OpenOffice org的双许可证方式解决了这个问题，他们可以选择根据SISSL进行许可。SISSL是经过开放源码促进会（Open Source Initiative，OSI）确认的开放源码许可证10，它规定在被许可者承诺保证“标准”一致的条件下，可以分发软件但不公开修改过的源代码。这里的“标准”是指OpenOffice org的XML文件格式规范11，和OpenOffice org的应用程序接口规范12。

由于这个授权限制，使得基于OpenOffice开发自定义的适合电子病历业务需求的XML文档格式从授权上是违反的，从技术上是不可行的。

EMRPad

由于基于开源软件而开发EMRE困难重重，于是国内有人开始自主研发编辑器了。其中最为著名的是陈联忠开发的EMRPad了。

陈联忠陈老师，技术达人，我等程序猿的楷模。中国最早做出了比较实用的电子病历编辑器EMRPad，该软件2006年被北京嘉和美康信息技术有限公司收购，从此不再独行于江湖。

可以说，嘉和公司的壮大，陈老师的编辑器出力不少。当年该编辑器提出了很多目前业界关于编辑器的标准功能，主要有：

1.       半结构化文档。将所谓的元素（也称输入域、关键字）和普通文本自由混排。实现全结构化文档和自由文本的混合。这样提供比较好的用户体验，而且也大大便利的程序对病历数据的处理。

2.       XML存储。将病历文档以纯XML的方式进行存储。而且文档内容和排版样式控制信息存在一个文件中。

3.       增强打印。包括续打、留痕打印和清洁打印。

4.       三级查房权限控制。

由于嘉和公司收购陈老师的编辑器，因此编辑器不会再单独对外销售了，不过奇怪的是，还是有传闻有单独销售的，不知是真是假。

陈老师现在任嘉和公司CTO，应该是专注于电子病历系统的大的框架性的研发，焦点可能已经不在编辑器上面了。不过这些对于广大的需要编辑器的HIT企业来说没啥关系了。

ZYTextDocumentLib系列编辑器

在国内HIT业界还流传着ZYTextDocumentLib的病历编辑器及其衍生版本，有一些HIT企业和个人使用这种编辑器。该编辑器用户界面大致如下：

 

这种编辑器是使用C#1.1开发的，业界有源代码流传。其程序文件名为ZYTextDocumentLib.dll或变体。

这种编辑器是采用完全的XML存储格式，其最大的特点就是XML根节点名称为“emrtextdoc”。这种编辑器初步实现了半结构化的编辑和存储，支持知识库，还有痕迹保留功能，有些衍生版本支持简单的表格。

不过该软件运行还不稳定，容易出错，功能也有不少欠缺。不建议使用。

DCWriter的编辑器

DCWriter编辑器是南京都昌信息科技有限公司的产品。其界面如下：

 

它是C#开发的，还提供COM接口，可用于VB/DELPHI之类的开发。该款编辑器功能还是非常全面的。比如续打，留痕打印，痕迹保留，三级权限控制，知识库，级联模板，医学表达式，条码等等。虽然功能多，但程序文件只有3MB大小，不依赖第三方组件，因此也适用于B/S开发。

该编辑器表格功能比较突出，相比其他编辑器而且已经比较接近于WORD的表格功能了，能实现标题行、单独的设置单元格的宽度，能方便的进行复杂表格的排版。而且单元格内部可以加上网格线，很容易实现护理记录的特殊文档样式。

另外对于.NET开发者，该编辑器提供DOM模式的文档内容开发接口，使得开发者能详细控制文档内容的各种细节内容，甚至派生出自定义的文档元素类型；而且DOM式的接口可用于非GUI程序的开发，能用于ASP.NET服务器端程序、命令行和Windows Service程序的开发。

此外文档中还能嵌入.NET控件和WPF控件，实现了编辑器包含业务的软件架构。因此对于.NET开发，在诸多EMRE控件中，DCWriter是首选。

在用户界面上，该编辑器的知识库采用弹出列表的方式显示，并使用拼音码检索然后插入，弹出式列表的用户界面相比对话框的方式能较少的干扰使用者的思路。

该编辑器支持半结构化文档，病历文件就是XML格式。程序可以直接快速处理病历XML文件。

它对卫生部的电子病历系统功能规范支持得很不错。

另外该编辑器的文档写得很详细，用户手册有300多页13万字，事无巨细的说明了该编辑器的所有细节内容。此外还有类似MSDN的那种开发SDK文档。

DCWriter和ZYTextDocumentLib存在一些关系，DCWriter完全兼容ZYTextDocumentLib生成的电子病历文档。而且由于DCWriter采用开放的软件接口架构，加上适配器即可直接加载其他编辑器生成的病历文档。

理想EMRE功能需求

根据作者的实践，列出比较理想的PC版EMRE的功能需求

文档编辑功能需求

1.       文字编辑：可自由输入文字，可设置文字的字体名称、大小、粗体、斜体、下划线、删除线样式。可设置文字的颜色和背景色。支持文字套圈。

2.       图片：可插入图片，图片和文字混排，能手动拖拽设置图片的宽度和高度，能保持图片的宽度高度比例。图片的图像数据可保持在文档中，也可链接引用其他地方的图像数据。能设置文字围绕模式。支持替换文字。

3.       段落：可设置段落的行间距、段前间距、段后间距。可设置段落的首行缩进和整体缩进量。可设置多种段落列表头显示样式。

4.       表格：支持单元格的横向合并和纵向合并。支持表格单元格内部的图文混排，支持表格套嵌表格。支持鼠标拖拽表格线来设置表格列的宽度和表格行的高度，支持鼠标拖拽来单独是设置一个单元格的宽度（不影响其他单元格）。支持设置每页都显示的标题行。支持表格单元格边框线的设置和背景颜色的设置。支持单元格斜线。

5.       图形：能插入矢量图形，包括椭圆形、正多边形、五角星、菱形等等等。

6.       条形码：支持一维条形码。

7.       页眉页脚：支持设置页眉页脚，其内容和正文一样编辑和排版。能插入页码元素。

8.       排版：支持文档，能设置文档节的边框和背景。支持分页符进行强制分页。

9.       文档编辑控件：支持分页视图模式和普通视图模式。支持OLE拖拽插入数据，支持和其他程序的复制、粘贴，支持重做和撤销操作。支持鼠标和键盘拖拽选择文档的部分内容。

10.   打印：支持文档的打印，支持打印预览。支持多个文档在一个界面中预览和打印。

11.   VBA：支持在文档中嵌入VBA脚本代码。

12.   文档结构图：支持显示树状的文档结构图，使得用户能快速定位内容。

13.   DOM模型：提供可开发和扩展的文档内容DOM开发模型，支持自定义文档元素类型。

14.   数据过滤：支持数据过滤，在向文档插入数据时，应用程序能进行过滤和处理。

15.   开发环境：微软WindowsXP及更高版本操作系统。能用于MS.NET/VB/PB/DELPHI开发，能用于B/S开发。

16.   运行环境：微软WindowsXP及更高版本操作系统。对B/S客户端为IE7及更高版本浏览器。

17.   文件：核心程序文件数量少，总大小不超过15MB；对于B/S应用总大小不超过10MB，不依赖第三方组件。

电子病历业务功能需求

1.       UI用户体验：尽量少使用对话框，而使用弹出式的用户界面。因为对话框比较容易打断用户的思路，而弹出式的用户界面对此影响比较少。

2.       痕迹保留：支持痕迹保留，用户对文档中的内容的新增、修改和删除都能产生痕迹信息并保留在文档中，痕迹信息包括操作员的名称、时间、操作类型和操作的文档内容。痕迹信息能在用户界面上展现出来。支持用户配置痕迹可视化效果。

3.       权限控制：支持多级权限控制，每个用户可以分配不同的权限等级。高权限等级的用户能修改和删除低权限等级的文档内容；低权限等级的用户无法修改和删除高权限等级的文档内容，只能看，不能改。

4.       内容保护：能设置指定文档内容是只读的，不能删除和修改样式。

5.       半结构化：支持半结构化文档的录入和存储。文档中关键区域被标记出来，而且对用户的文本自由录入的影响很小。

6.       输入域：支持在文档中插入输入域，输入域可以设置背景文本、固定宽度、数据录入方式、数据校验格式等信息。

7.       知识库：支持加载知识库，知识库中以树状结构组织了多个知识库节点，节点可以采用可选内容列表，也可以链接引用到模板中。知识库的内容可以动态的来自其他程序模块或数据库。

8.       数据源绑定：文本输入域能绑定数据源。应用程序能传递数据源来批量的修改文档中输入域中的内容。文档中的内容也可以批量的回填到数据源中。

9.       级联模板：设置某个输入域的内容能自动的控制其他文档片段的显示和隐藏。使得文档具有一定的智能判断效果。

10.   医学表达式：支持带分子分母的医学表达式。能直接在文档中编辑医学表达式中的数据。

11.   嵌入组件：支持在文档中嵌入第三方组件，第三方组件参与文档的排版和打印。

12.   网格线：支持整个文档的网格线，支持单元格中设置网格线。实现类似护理记录的录入界面。

13.   继续打印：支持断点继续打印。用户和程序都能设置继续打印的位置。

14.   整洁打印：支持不带有痕迹信息的整洁打印。

15.   文件格式：必须支持单文档的XML格式，文档中所有的信息，包括文档内容、排版样式控制、痕迹保留信息等都所有细节信息都存储在一个XML文档中。

16.   表单视图模式：支持表单视图模式，用户的编辑操作将限制在输入域中。可编辑区域不得超出输入域。

17.   视图加密：支持加密模式显示文档中的部分内容，比如星号显示患者姓名。

18.   事件：提供丰富的用户界面事件进行二次开发。

功能规范

理想的EMRE能实现卫生部制定的《电子病历系统功能规范》中的针对病历文档编辑器而制定的功能需求，这些需求列出如下：

电子病历功能规范条款	点评
第九条第二点：对电子病历数据的创建、修改、删除等任何操作自动生成、保存审计日志（至少包括操作时间、操作者、操作内容等），并提供按审计项目追踪查看其所有操作者、按操作者追踪查看其所有操作等功能。
第十条第一款第一点：支持对各种类型的病历资料的转换、存储管理，并采用公开的数据存储格式，使用非特定的系统或软件能够解读电子病历资料。	存储格式首推XML格式。
第十条第一款第五点：具有电子病历数据备份和恢复功能；当电子病历系统更新、升级时，应当确保原有数据的继承与使用。	编辑器提供向上和向下兼容性，新版本的编辑器能加载旧版本保存的电子病历文档。旧版程序也能部分的加载新格式的文档。
第十条第二款第一点：以适当的方式保存完整医疗记录，能够以原有样式再现医疗记录。
第十一条第一款第一点:对电子病历设置保密等级的功能，对操作人员的权限实行分级管理，用户根据权限访问相应保密等级的电子病历资料。授权用户访问电子病历时，自动隐藏保密等级高于用户权限的电子病历资料。	支持加密显示文档内容。例如
第十三条: 为患者创建电子病历，必须赋予患者唯一的标识号码，建立包含患者基本属性信息的主索引记录，确保患者的各种电子病历相关记录正确地与患者唯一标识号码相对应。
第十四条第一款第一点：为患者（含急诊或其他情况下身份不确定的患者）创建电子病历并赋予统一编码的唯一标识号码功能，通过该标识号码可查阅患者的电子病历相关信息。
第十四条第一款第二点：为每位患者电子病历创建唯一的主索引，并记录患者基本信息（应当至少包括患者姓名、性别、出生日期、常驻地地址等），并能够对患者基本信息进行必要的修改、补充和完善。
第十四条第一款第三点：提供电子病历主索引自动查重功能，按照患者基本信息记录对系统可能存在的重复记录给予提示并由人工确认。
第十五条：提供电子病历自动查重功能，能够将同一患者的多重电子病历与该患者唯一标识号码进行关联，通过唯一标识号码可查阅患者的电子病历相关信息。
第十九条第二点：提供以自由文本方式录入诊断（或主诉）、手术及操作名称的功能。
第二十条第一款第二点：提供以自由文本方式录入诊断、手术及操作名称的功能。
第二十条第二款第二点：提供为临床试验病例、教学病例等特殊病历资料进行标识的功能。
第二十三条第二点：提供住院病历创建信息补记、修改等操作功能，对操作者应当进行身份识别、保存历次操作印痕、标记准确的操作时间和操作者信息。	痕迹保留
第二十四条第一款第一点：支持各类型病历资料录入与编辑的功能。	支持文字、图片、表格等等。
第二十四条第一款第二点：提供按照病历类型、内容和要求，根据电子病历系统中相关数据，自动生成住院病历部分内容的功能。
第二十四条第一款第三点：提供自由文本录入功能。	提供仿MS Word的用户体验，能自由录入文本。
第二十四条第一款第四点：提供在住院病历指定内容中复制、粘贴患者本人住院病历相同信息的功能；禁止复制、粘贴非患者本人信息的功能。	在粘贴文档内容时需要进行数据过滤。
第二十四条第一款第五点：提供模板辅助录入功能，可以按照住院病历类型、疾病病种选择所需模板；模板内容应当符合该疾病现有诊疗指南、规范要求。
第二十四条第一款第六点：提供为医疗机构定制各类型住院病历默认样式的功能，默认样式包括纸张尺寸、字体大小、版面设置等。	支持页面设置，支持自定义纸张大小，支持信纸样式的网格线。
第二十四条第一款第七点：提供暂时保存未完成住院病历记录，并授权用户查看、修改、完成该病历记录，提供住院病历记录确认完成并记录完成时间的功能。
第二十四条第一款第八点：提供住院病历记录双签名功能，当由实习医师、试用期医务人员书写病历时，应当经过本医疗机构注册的医务人员审阅、修改，并保留书写者与审阅者的双签名。	提供痕迹保留、审阅标记等功能。
第二十四条第二款第一点：提供在住院病历记录中插入患者基本信息、医嘱信息、辅助检查报告、生命体征信息等相关内容的功能。
第二十四条第二款第三点：提供结构化病历记录项目内容合理性检查与提示功能，包括项目独立检查和项目之间、项目与患者个人特征间的相关性检查。
第二十四条第二款第四点：提供包含展现样式的病历记录录入编辑和保存功能；提供所见即所得的病历记录录入编辑功能。
规范第二十四条第三款第一点：提供在住院病历记录中嵌入图片、表格、多媒体数据并进行编辑的功能。
第二十四条第三款第三点：.提供常用术语词库辅助录入功能，术语词库包括症状名称、疾病名称、药物名称、手术名称、护理常规名称等.
第二十四条第三款第四点：提供结构化（可交互元素）模板辅助录入功能，并在病历记录中保留结构化模板形成的结构。
第二十五条第一款第一点：提供病历记录的修改和删除功能，并自动保存病历记录修改的痕迹；对已确认完成的病历记录进行修改时，系统自动记录修改内容、修改人、修改时间。
第二十五条第一款第二点：对病历记录按照用户修改权限管理的功能，允许上级医务人员修改下级医务人员创建的病历记录。
规范第二十五条第二款：提供病历记录禁止修改的设置功能。
第二十六条第二款第一点：提供创建结构化模板功能，结构化模板至少包含单选项、多选项、必填项、填空、不可修改文本等元素。
第二十六条第二款第二点：提供模板中定义自动宏替换元素功能，宏替换元素可用于在病历记录中经常出现的患者姓名、性别、主诉等内容。
第二十六条第二款第三点：提供结构化模板中，对结构化元素设定录入方式、取值范围、校验规则等属性功能。
第四十二条第一款：提供可浏览患者各类电子病历内容的独立软件。
第四十三条第三款第二点：提供与病历数据同时展现相关修改痕迹信息的功能，至少包括修改时间、修改人、修改内容等信息。
第四十四条第一款第一点：提供将电子病历中的各类医疗记录进行纸张打印的功能，打印格式符合卫生行政管理部门对纸质病历的相关要求。
第四十四条第一款第二点：提供电子病历记录按照最终内容（不含修改痕迹）打印的功能。
第四十四条第一款第三点：提供电子病历打印预览、接续打印功能。
第四十四条第二款第一点：提供将一次就诊的病历资料全部或部分进行批量打印的功能。
第四十四条第三款第二点：提供将电子病历中的各类医疗记录以电子文件格式导出的功能。	应该必须支持XML格式。