我看了军惠的电子病历，就是用ole控件，总觉得有点落后。尤其不能实现结构化的查询，规则等管理，其实还是采用拷贝方式，很容易出问题，如女性的疾病也同样可以出现在男性的病历中。
编辑器技术是电子病历系统中的重点和难点，它是电子病历系统的核心技术，它的功能是否强大直接关系到电子病历系统的成败。因为在病历书写过程中，既要支持医学术语的结构化存储，又要支持自由描述语言的书写，同时还要支持图文混排，表格操作等，现有的书写工具很难完成上述要求。但是开发专用电子病历编辑器难道非常大，目前国内有成熟并且已经大量商业应用电子病历编辑器的公司据我所知只有2家，一家是北京华信慧典的病历宝典2009（穆鹏义开发的），一家是北京嘉禾美康的EMRpad3.0（陈联忠开发的），而且都是有6、7年的开发经历了。这个两家公司的技术水平都很高，产品也都很稳定，但个人认为华信慧典的病历宝典在技术上更胜一筹，主要表现在他们的编辑器表格处理能力很强大（编辑器中最难的就是表格技术），而且结构化做的也很好。从电子病历编辑器的复杂性来说，没有3、4年的时间，不可能研发出可以商业应用的成熟产品。所以楼主可以跟这2家公司接触一下，看能否得到他们的帮助。
B>重庆中联电子病历系统(ZLRichEPR :
基本介绍
【功能概述】
配合医生工作站，ZLRichCPR主要完成如下功能：
实现各类门诊/住院病历文件书写规范、格式和书写审核要求的设置调整
各种病历文件的全文示范、段落示范和词句示范的编辑管理
病人就诊过程各种病历的书写、审签、归档管理与质量控制
对病人病历的查阅、分析和利用
【注】丰富文本格式(Rich Text Format，简称RTF)：
是一种多格式文本信息的描述格式，将文本信息及其格式说明以文本的方式共同存放，以便于数据的传输，是一种通用的计算机文件格式，目前已被作为我国电子公文传递的标准格式之一采用。ZLRichCPR充分利用该格式，保证了电子病历的格式和编辑的灵活性。
【功能特色】
可控制的丰富格式病历文档编辑：在电子病历范畴中，现阶段多数还是以文档形式存在；伴随不同医疗过程的病历具有不同的内容要求和格式规定，不同地区和学科也存在差别。ZLRichCPR在提供丰富格式病历的基础上，实现病历定义过程内容规范和格式上的灵活性，在编辑过程中的可控制性
真正结构化病历，支持数据结构化输入与控制：结构化始终是电子病历发展不变的追求,实现电子病历可利用性的前提,在丰富格式文档中,包含了填空、选择等内容结构化输入控制,以及对表格化病历的支持
增强的病历质量管理功能：电子病历伴随病人诊疗过程由医护人员按规定完成；在此过程中，对病历的及时性、完成性和基本的正确性提醒控制，有利于病历质量的提高，进而有利于医疗质量的提高
可分科定制病历书写规范
病历全文模板元素模板功能a
导入历史病历功能
疾病诊断诊疗用药参考管理
【功能概述】
配合医生和护士工作站，利用计算机强大的存储、检索功能，将大量的诊疗措施及药品的功能、特性、用法用量、注意事项等信息组织起来，提供诊断参考规范和诊疗措施应用参考规范的管理，包括常规知识参考和局部合理性检测，供医护人员查阅了解，并在实际诊断治疗护理过程中随时调阅或应用参考规范
【功能特色】
基于标准疾病编码体系的疾病辅助诊断和治疗措施参考功能
药品用法参考功能
中药方剂参考功能
诊疗措施用法参考功能
基于.NET平台和Cache数据库的结构化电子病历系统设计
来源：中国论文下载中心 [ 08-11-17 15:32:00 ] 作者：江凤莲 邓书显 编辑：studa20
多智网校诚招全国各地市独家线下代理商，共同开发网上教育市场。多智教育(DOZEDU.COM)！
【摘要】 电子病历(CPR)系统是医疗信息化的重要部分,在国外有不少广泛使用的系统，但不能通过汉化提高国内CPR水平，现基于.NET平台和Cache数据库提出一种结构化电子病历系统方案，主要创新点包括平台选择、病历模型结构、接口模型设计以及规则引擎的引入等。
【关键词】 结构化电子病历系统 病历模型结构 接口模型 规则引擎
电子病历(Computer-based Patient Record, CPR)是以病人为中心的信息集成，是医院所有业务系统的有机融合，能完整、动态地反映患者的医疗过程，是对个人医疗信息及其相关处理过程综合化的体现［1］。电子病历又称电子病人记录（EMR），现正向电子健康记录（EHR）发展。
《2007年中国医卫行业信息化建设与IT应用趋势研究报告》显示，电子病历、PACS、HIS系统的升级、完善和集成、信息安全等是2007年医卫行业信息化建设的投资重点［2］。目前不能通过汉化国外CPR软件提高国内CPR使用水平。首先，病历的组织结构、描述方式中外有别，国外的CPR系统不能完全适应国内的病历管理规范。其次，由于电子病历相关立法以及监督机制等方面的差异，国外CPR系统的设计理念和国内不一样。现国内的CPR要求将病历打印出来进行手工签名以起到法律效应。国外的CPR系统以表格或树形结构的方式录入数据，很难将计算机中的数据还原成“手工病历”。
因此，我们在认真分析了国内外CPR系统的基础上开发了基于.NET平合和Cache数据库的结构化电子病历系统。
1 系统体系结构
系统结构见图1。
数据访问层中对数据库的操作分两部分。访问组件在微软Enterprise Library中Data Access Application Block基础上修改，增加了对ODBC数据源的支持(因为目前.NET平台上还没有支持Cache的驱程)，对Database抽象类功能进行扩充。图2所示的数据访问组件是以工厂模式［3］设计的，Database和DbCommandWrapper都是抽象类。客户端代码通过DatabaseFactory类创建Database实例。通过Cache提供的CacheObject访问Cache多维数组。
因病历输入过程中使用大量代码字典表数据，如诊断、症状、药品目录等。客户端在输入时都从数据库中读取，服务器负担很重，可用数据缓存方式加以解决。
2 开发平台选择
因国内医院普遍使用Windows操作系统，本系统基于Windows平台以WinForm程序为主，采用.NET平台进行开发。
数据库选择相对复杂。CPR系统中包括病历数据和其它基础数据。对于一般性数据可用关系型数据库进行建模、存储，而结构化处理后的病历数据就不能满足数据分析的需要。
病历本身数据量很大，再加上结构化处理时增加的描述符，最终数据会增加很多。基于共享需要，病历数据以XML格式保存［4］，对它处理要用XQuery、XPath等技术。虽然主流关系型数据，如SQL Server、Oracle、DB2等都支持XML数据，但要提高数据查询效率，必须对数据添加索引。然而，病历数据的结构是动态的，不能有效建立索引。因而，将动态结构的数据分解为固定格式的明细数据。
在关系型数据库中，路径表示数据在病历结构中的位置。同步数据时借助路径来定位，分析数据时通过路径过滤。因为病历数据分解为明细数据后数据量非常大，相应的路径数量非常多，且查询数据时因缺乏必要的索引信息需遍历整个表。同时，值字段需要保存各种类型的数据，而字段类型只能是字符类型，在进行数据比较时要进行类型转换，查询的代价急剧上升。若能够提高数据遍历速度，并避免类型转换，将大大提高效率［5］。而这恰恰是Cache数据库的特点之一。
Cache数据库的核心是高效的多维数据引擎。通过内置的CacheObjectScript脚本语言，可以直接访问多维数据结构，这样可以获得最高的性能和最好的存储利用率。当有特别的或者专业的结构并且不需要提供对象或者SQL的方法来访问数据时，或者当要求尽可能高的性能时，直接的“global访问”是特别普遍的。
3 插件式应用程序框架
本系统客户端使用基于SmartClient技术的插件式应用程序框架，主要包括：①加载基本模块:基础框架类库定义接口IPlugin、IStartup模块程序实现接口，主程序通过PlugInHelper辅助类加载:②数据访问:基础框架类库定义接口IDataAccess，并实现SqlDataAccess，主程序通过DataAccessFactory访问数据库;③浮动窗口:主程序支持浮动窗口显示，基础类库定义DockingWindow,
DockingForm,DockingContent提供各模块类创建浮动窗口，例如工具窗口、病人列表等，在加载模块同时通过DockingHelper辅助类实现浮动窗口显示，并动态保存浮动窗口位置、显示方式，支持不同操作人员设置;④登录部分:采用基于角色方式的帐户管理，并加密处理，所有主程序加载的功能模块，都基于这个帐户的权限信息进行控制;⑤报表部分:提供统一的报表服务。
4 病历模型结构图
系统对病历数据处理分为3个部分：
数据访问部分负责处理和病历有关的数据存储操作。
ModelStorage组件负责处理数据库中数据与病历对象之间的转换、实际数据与查询数据之间的同步。
病历业务负责病历的内部逻辑。在EMRModel组件中完成病历对象维护、检查等工作。EMRWidget组件用来统一处理病历的展现及录入、病历对象数据与RTF文本之间的转换。
病历界面包括病历模板设置程序和病历录入组件。在病历录入组件中只负责和文字编辑有关的操作，数据的内部逻辑处理由EMRWidget组件完成。
病历模型的实现比较复杂，主要内容如下。
EMRNode为基本元素，表示病历内容，有三个继承类:EMREntity,EMRNativeText, EMRPackage。EMREntity表示数据实体，病历结构中最小输入单位，也是数据分析基本单位，可以是多个数据项的组合。如 “身高”数据，应同时包含“身高的值”和“身高的单位”两部分。EMRNativeText为原生文本，即以自然语言输入的文本。
EMRPackage为病历内容包，相当于文档结构中的目录，是个容器，可包含实体、原生文本或另一个包。
EMRDynamicMoleNode为嵌入式模板，即“主诉”、“现病史”这一层次内容，由EMREmbededMoleNode构成。
EMREmbededMoleNode为嵌入式对象，即“胸痛描述”、“头部检查”这一层次内容，由EMRObject构成。
EMRObject为元数据对象，即“发病时间”、“伴随症状”这一层次的内容，它由EMREntity构成，是病历结构中的最小显示单位。
另为在模型中表示表格对象引入EMRTable、EMRRow、EMRCelI三个类，分别对应表、表中的行和行的单元格记录。
5 数据接口模型
CPR系统是医院信息系统的核心，HIS、LIS、RIS、PACS等系统都需要与其进行数据交换。在CPR的应用范围提升以后，还会和其它系统进行数据交换。所以，CPR的数据接口定义非常重要。在医疗信息领域各种数据标准也非常多，其中影响最大、应用最广的是HL7协议。
目前国内系统真正支持HL7协议的很少，系统投入使用前要么花大力气改造与CPR联网的系统，要么根据对方要求定制CPR系统数据接口，因此，我们设计了自己的接口模型。
在接口中传输数据请求可分为两类:同步数据请求和读取数据请求［6］。由于同步数据请求发出后不需立即得到结果，可将这类信息放入一个异步消息队列，由专门的异步消息处理进程处理。而读取数据的请求需要实时处理。
定义接口首先定义数据的传输格式、调用方式等。数据格式是中立格式，调用接口的系统与被接口调用的系统都要处理系统内部数据与接口数据之间的格式转换。由于各系统使用技术不同，对于接口我们都通过WebService来发布。
接口分独立消息处理服务程序、客户端接口处理组件两部分。
因接口数据传输涉及两个系统，一要按通用技术标准设计接口屏蔽技术差异，二要提供接口处理程序处理意外情况，所以建立专门的消息处理服务程序。
接口组件处理接口数据与内部数据转换及与消息服务程序间通讯。将接口组件放在客户端一是减轻消息服务器的负担提高并发性，二是降低程序实现的复杂度。
接口消息体格式参考HL7的消息格式如下:
编号发出系统接收系统〖〗消息类型应答标记请求编号数据体
编号是唯一序号，发出系统是发出消息的系统代号，接受系统是消息要送达的系统代号，消息类型是消息需要完成操作的代号，答标记标识此消息是否已被对方系统接收(保留字段)，请求编号是本消息要回复的消息的编号，数据体包含了消息处理时所需的接口数据。
6 规则引擎
在CPR数据逻辑处理中，需经常进行数据校验、联动处理，如以代码形式固化在程序里，工作量大，且业务规则变复杂后很难维护。同时不同用户业务有不同的规则需求，需不断修改处理逻辑，增加系统维护工作量。因此，本系统通过规则引擎维护一个规则库(通常以配置方式放入引擎)，运行时将一组对象作为事实库交给规则引擎处理；规则引擎将对事实库中的诸条事实与规则库中诸规则的“事实”部分进行模式匹配，一旦某条规则指定事实存在，则执行该规则指定行为。
在需要处理业务规则时，规则引擎会执行所有能够与事实库中事实相匹配的规则。
如病案首页中的住院次数、住院天数通常其标准的校验规则如下:
IF住院次数<>数据库中该病人病案首页记录数 THEN提示住院次数输入错误IF住院天数<>(出院日期－入院日期)THEN提示住院天数输入错误
但在部分医院，这样的规则就不适用了。如病人在使用计算机系统前住过院，但以前的数据并不在当前系统中。又如精神病医院中与普通医院不同，患者在得到允许的情况下可回家休息，所以在医院的实际住院天数可能比出院日期和入院日期之间的差值小。在使用规则引擎方式处理后，只需在规则库中添加或删除规则即可。
7 结语
CPR系统的设计必须针对国情，便于管理及符合医患的利益，我们提出的这个结构化电子病历系统设计方案主要创新点在数据库
|
|
资源大小：46.60 KB 
