关于国内部分电子病历编辑器的评价

一、模式

国内电子病历系统的开发不外2种模式：C/S模式和B/S模式，其中C/S模式一般是以开放的文字编辑器为基础进行开发，而B/S一般采用页面填写模式，也有采用OCX控件模式（这种模式其实也是一种C/S）。两种模式各有优劣，从我个人角度讲，更趋向于C/S（这里是指三层结构的C/S），理由如下：

1、B/S相对于C/S最大优势在于客户端免维护，其实C/S做好了，也可以实现自动升级和客户端免维护，我以前在某地区做的医保系统，采用三层结构，广域网上1000多个C/S客户端，一样免维护。

2、C/S具有更好的界面操作性，尤其是能够实现更复杂的界面操作动作，能在一定程度上较好实现自然语言输入与结构化处理。B/S由于受编辑器功能限制，在文字间相互操作、数据元、各种提示、绘图处理等方面都存在一定的欠缺。

3、C/S具有更直观的界面，实现所见即所得模式的书写，而B/S不采用控件很难做到。

4、C/S具有更好的效率，尤其是在处理和展示大量数据量时，C/S优势更明显。B/S模式受服务器和浏览器限制，展示大量数据时效率直线下降。我们曾经试过IE同时显示1000条记录时，速度慢得让人无法忍受。

当然具体采用哪种模式，还需要看自己的产品路线及技术沉淀，最好与HIS采用相同模式。由于B/S的电子病历必需依赖数据库，正常渠道很难看到，只有在用户医院才能匆匆看看，所以下面主要是讲C/S模式下的电子病历编辑控件。

二、功能

C/S模式下，电子病历系统的核心是电子病历编辑器控件。有很多文章对电子病历编辑器控件的功能要求进行了论述，这里只是简单说明一下。

电子病历编辑器的功能主要概况为以下几个方面：

1、文字编写：这是最基本的要求，细节不多讲，按照临床医生习惯，最好是所见即所得书写模式，另外病历续打是文字编写功能中必不可少的。

2、数据元管理：按照卫生部要求，电子病历系统必须能够实现病历内容结构化，按照卫生部的数据标准进行管理。电子病历结构化的目的包括：

　　a)质控要求：要求系统能够识别和区分病历内容，针对不同内容按照要求进行书写限制、时效提醒、病历自动评分等工作。

　　b)教学要求：书写病历除了记录医疗过程外，还有一个很重要的功能，就是训练低年资医生的临床思维模式。所以电子病历编辑器要能够引导书写者以正确的思维方式完成书写过程。

　　c)科研要求：临床科研是为了从病历中获取既往医疗数据，其中病历检索是一个重要手段。病历检索可以采用文字检索模式，或精确检索模式，后者需要电子病历在数据上的完全结构化。

　　目前国内的电子病历编辑器都是基于文字编辑器开发的，在处理数据元及结构化上存在较大的缺陷。电子病历数据结构化，不是简简简单将病历内容分成几个块来书写就行了，必需在一定程度上，对书写内容进行结构化，区分书写内容，引导书写者书写，并还不能影响其用自然语言的描述。

3、安全管理：按照卫生部要求，电子病历系统必须能够实现电子签名、数据留痕等功能。

三、技术路线

国内已商品化的电子病历编辑器，从技术路线上讲，已知的有以下几个方向：

1、基于Delphi+RichView开发

RichView是一款基于Delphi的文字编辑控件，开发语言是pascal，收费（$499.00）后提供全部源代码。利用该控件开发电子病历的公司包括：病历宝典、易讯、医星等产品。

2、基于VC++AbiWord开发

AbiWord是一款开源的文字编辑器控件，开发语言是C++，可以跨平台运行，含全部源代码。利用该控件开发电子病历的公司主要是EMRPad，国内很多HIS厂家产品都是OEM其产品，或在其控件基础上实现的，如中联等。

3、基于中标电子病历控件开发

中标电子病历控件是近几年推向电子病历市场应用的office组件。从文字编辑方面来讲，其功能是最完整、最强大的，但该公司最大的缺陷在于自己不是医疗信息化方面的专业厂家，只是文字编辑器控件提供商，电子病历厂家无法拿到源代码，分发安装的文件也很多，几十兆上百个文件。

4、其他文字编辑器

有一些其他厂商，利用Word、RichEdit、TextControl、scintilla等富文本编辑器在做，总的来讲都存在很难结构化处理、续打实现困难、书写控制困难（如控制复制粘贴、表达式处理等）的问题。还有部分厂家的产品，由于个人能力有限无法看到，所以不好评估。

 

上述观点仅代表个人意见，若有失公正，敬请指正。