论电子病历文本编辑器Word格式.docx
《论电子病历文本编辑器Word格式.docx》由会员分享，可在线阅读，更多相关《论电子病历文本编辑器Word格式.docx（19页珍藏版）》请在冰豆网上搜索。
因此在医学信息化中，病历文书是作为最为重要的信息是需要得到最为特别的照顾。
在过去的传统HIS阶段，应用系统对病历文书的照顾就是一个最简单的TextBox，高级一点的用上MSWORD。
不过这显然是远远不够的，那样做不是与时俱进，而且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控件进行一些深入的开发就不行了。
比如留痕、续打、知识库等等，此时一些开发企业就骑虎难下了，终究是要放弃的。
基于MSWORD进行开发
一些EMRE是基于MSWORD进行开发。
其优点如下：
1.
MSWORD的文档编辑器功能是任何其他文本编辑器所无法逾越的。
文字、图片、表格等等都是至尊级的，而且MSWORD应用广泛，群众基础好。
基于它开发，在文档编辑用户体验上来说，用户是很容易接受的。
2.
MSWORD的二次开发接口比较多，各种支持COM的开发工具都支持。
而且MSWORD的开发学习资源比较丰富，网上能找到很多。
不过使用MSWORD进行开发也有不少缺点：
MSWORD不是免费软件，使用它必须购买一个完整的MSOffice软件包，这是一笔不小的版权费用。
医院可能拒绝使用盗版MSWORD，此时会比较大的增加项目成本。
比如有微软经销商报价MSOFFICE2010为4000元/套。
这样就很不利于HIT企业市场销售。
客户端电脑必须逐个安装MSWORD，部署工作量比较大。
而且不同版本的MSWORD的开发接口存在一定的兼容性问题，增加软件开发、部署和调试的难度。
比如不同的客户已经安装了WORD2003、WORD2007、WORD2010等等，此时麻烦不小。
3.
MSWORD开发是基于OLE自动化技术，使用了跨进程的操作，操作不当系统中会留下MSWORD的进程，容易资源泄露，因此一般避免在服务器端使用MSWORD。
4.
大量的电子病历特定业务功能使用MSWORD是无法实现或者很难实现的。
比如痕迹保留和三级权限控制；
半结构化；
续打、整洁打印和留痕打印；
对于B/S系统，如何将MSWORD文件传到服务器上也是个难题；
难于实现知识库。
而且生成的WORD文件格式复杂难于解析，难于进行统计分析。
基于MSWORD开发电子病历编辑器可以在某些情况下应急，但由于上述无法解决的缺陷，从长远上来说是不可取的，终究是要放弃这种方式的。
基于开源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。
易迅电子病历编辑器在常规的文档编辑器功能是差不多够用了，但有些功能做得还不够，在此挑出几个：
谈不上支持半结构化技术。
未发现支持XML技术。
单元格无法单独的设置宽度，当编辑复杂表格布局时比较费劲。
开发帮助文档太简单了。
文字排版无法两端对齐，文字右边缘层次不齐，影响美观。
5.
图片可以编辑后无法修改已经改过的内容，无法撤销。
易讯编辑器的东家天方达公司还据此经营着一个电子病历文档的网络社区。
任何人注册就可以上传和下载电子病历文档范文，这是他们的一个不错的特色。
这里是病历文档范文，还谈不上是病历文档模板。
病历宝典
病历宝典软件是北京华信慧典科技有限公司研发的电子病历编辑器。
其用户界面如下：
该软件也应该是使用Delphi基于TRichViewEdit开发的。
相比易迅病历编辑器，其功能改善了不少，主要有：
总体感觉用户界面比易迅编辑器要现代多了。
相比而言易迅编辑器的用户界面还是比较粗糙的。
能进行文字的两边对齐了。
增强了医学表达式。
笔者测试的是《慧典电子病历系统学习版》，这个版本有一个很要命的缺点，那就是当该软件显示对话框，比如插入表格对话框时，在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开发的不是控件，而是软件包的二次开发。
这点很类似MSWORD。
OpenOffice体积庞大的另一个原因就是为了实现跨平台的，它能运行在Windows/Linux/MacOS/Solaris等多种操作系统，支持各种接口和规范。
而国内电子病历客户端基本上都是MSWindows平台，OpenOffice的这些跨平台的功能对于EMR用户来说就是画蛇添足的了。
使用OpenOffce比MSWORD相比唯一的好处就是OpenOffice是自由软件的，没有版权现金成本，其开源的特性对于HIT企业来说其实是没啥实际作用，就跟小学生学奥数一样。
OpenOffice文档编辑功能也很强大，但还是无法达到MSWORD的那种至尊境界。
使用OpenOffice会涉及到它的版权问题，中国国情是不尊重版权的，比如有些IT企业（特别是政绩企业）把OpenOffice或者开源操作系统简单封装一下，然后声称国产原创，跑到政府面前邀功套现套证书。
不过在此还是提一下OpenOffice的版权，以下内容摘自XX百科
OpenOfficeorg采用GNU通用公共许可证（GPL）和Sun工业标准源码许可证（SunIndustryStandardsSourceLicense，SISSL）8的“双许可证”方式对源码进行许可；
采用独立的公共文档许可证9（PublicDocumentationLicense，PDL）对发布在OpenOfficeorg网站上、但不期望集成进软件的绝大多数文档进行许可。
“双许可证”方式意味着要么应用GNUGPL许可证，要么应用SISSL许可证。
当应用GPL许可证的时候，OpenOfficeorg源码中的库和组件功能将根据GNULGPL进行许可。
由于LGPL与GPL完全兼容，这样就能够鼓励更多的人参与到OpenOfficeorg社区建设中来。
SISSL则是为商业应用设计的。
由于GPL许可证对于自由复制、修改、发布等权利的严格保证，某些软件商会因此而受限、不能参与到开放源码社区中来。
OpenOfficeorg的双许可证方式解决了这个问题，他们可以选择根据SISSL进行许可。
SISSL是经过开放源码促进会（OpenSourceInitiative，OSI）确认的开放源码许可证10，它规定在被许可者承诺保证“标准”一致的条件下，可以分发软件但不公开修改过的源代码。
这里的“标准”是指OpenOfficeorg的XML文件格式规范11，和OpenOfficeorg的应用程序接口规范12。
由于这个授权限制，使得基于OpenOffice开发自定义的适合电子病历业务需求的XML文档格式从授权上是违反的，从技术上是不可行的。
EMRPad
由于基于开源软件而开发EMRE困难重重，于是国内有人开始自主研发编辑器了。
其中最为著名的是陈联忠开发的EMRPad了。
陈联忠陈老师，技术达人，我等程序猿的楷模。
中国最早做出了比较实用的电子病历编辑器EMRPad，该软件2006年被北京嘉和美康信息技术有限公司收购，从此不再独行于江湖。
可以说，嘉和公司的壮大，陈老师的编辑器出力不少。
当年该编辑器提出了很多目前业界关于编辑器的标准功能，主要有：
半结构化文档。
将所谓的元素（也称输入域、关键字）和普通文本自由混排。
实现全结构化文档和自由文本的混合。
这样提供比较好的用户体验，而且也大大便利的程序对病历数据的处理。
XML存储。
将病历文档以纯XML的方式进行存储。
而且文档内容和排版样式控制信息存在一个文件中。
增强打印。
包括续打、留痕打印和清洁打印。
三级查房权限控制。
由于嘉和公司收购陈老师的编辑器，因此编辑器不会再单独对外销售了，不过奇怪的是，还是有传闻有单独销售的，不知是真是假。
陈老师现在任嘉和公司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服务器端程序、命令行和WindowsService程序的开发。
此外文档中还能嵌入.NET控件和WPF控件，实现了编辑器包含业务的软件架构。
因此对于.NET开发，在诸多EMRE控件中，DCWriter是首选。
在用户界面上，该编辑器的知识库采用弹出列表的方式显示，并使用拼音码检索然后插入，弹出式列表的用户界面相比对话框的方式能较少的干扰使用者的思路。
该编辑器支持半结构化文档，病历文件就是XML格式。
程序可以直接快速处理病历XML文件。
它对卫生部的电子病历系统功能规范支持得很不错。
另外该编辑器的文档写得很详细，用户手册有300多页13万字，事无巨细的说明了该编辑器的所有细节内容。
此外还有类似MSDN的那种开发SDK文档。
DCWriter和ZYTextDocumentLib存在一些关系，DCWriter完全兼容ZYTextDocumentLib生成的电子病历文档。
而且由于DCWriter采用开放的软件接口架构，加上适配器即可直接加载其他编辑器生成的病历文档。
理想EMRE功能需求
根据作者的实践，列出比较理想的PC版EMRE的功能需求
文档编辑功能需求
文字编辑：
可自由输入文字，可设置文字的字体名称、大小、粗体、斜体、下划线、删除线样式。
可设置文字的颜色和背景色。
支持文字套圈。
图片：
可插入图片，图片和文字混排，能手动拖拽设置图片的宽度和高度，能保持图片的宽度高度比例。
图片的图像数据可保持在文档中，也可链接引用其他地方的图像数据。
能设置文字围绕模式。
支持替换文字。
段落：
可设置段落的行间距、段前间距、段后间距。
可设置段落的首行缩进和整体缩进量。
可设置多种段落列表头显示样式。
表格：
支持单元格的横向合并和纵向合并。
支持表格单元格内部的图文混排，支持表格套嵌表格。
支持鼠标拖拽表格线来设置表格列的宽度和表格行的高度，支持鼠标拖拽来单独是设置一个单元格的宽度（不影响其他单元格）。
支持设置每页都显示的标题行。
支持表格单元格边框线的设置和背景颜色的设置。
支持单元格斜线。
图形：
能插入矢量图形，包括椭圆形、正多边形、五角星、菱形等等等。
6.
条形码：
支持一维条形码。
7.
页眉页脚：
支持设置页眉页脚，其内容和正文一样编辑和排版。
能插入页码元素。
8.
排版：
支持文档，能设置文档节的边框和背景。
支持分页符进行强制分页。
9.
文档编辑控件：
支持分页视图模式和普通视图模式。
支持OLE拖拽插入数据，支持和其他程序的复制、粘贴，支持重做和撤销操作。
支持鼠标和键盘拖拽选择文档的部分内容。
10.
打印：
支持文档的打印，支持打印预览。
支持多个文档在一个界面中预览和打印。
11.
VBA：
支持在文档中嵌入VBA脚本代码。
12.
文档结构图：
支持显示树状的文档结构图，使得用户能快速定位内容。
13.
DOM模型：
提供可开发和扩展的文档内容DOM开发模型，支持自定义文档元素类型。
14.
数据过滤：
支持数据过滤，在向文档插入数据时，应用程序能进行过滤和处理。
15.
开发环境：
微软WindowsXP及更高版本操作系统。
能用于MS.NET/VB/PB/DELPHI开发，能
升级会员 