基于NET平台和Cache数据库的结构化电子病历系统设计_第1页
基于NET平台和Cache数据库的结构化电子病历系统设计_第2页
基于NET平台和Cache数据库的结构化电子病历系统设计_第3页
基于NET平台和Cache数据库的结构化电子病历系统设计_第4页
基于NET平台和Cache数据库的结构化电子病历系统设计_第5页
已阅读5页,还剩1页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、基于.NET平台和Cache数据库的结构化电子病历系统设计 TOC o 1-5 h z 基于.NET平台和CACHE数据库的结构化电子病历系统设计1 HYPERLINK l bookmark0 o Current Document 系统体系结构2 HYPERLINK l bookmark2 o Current Document 开发平台选择2 HYPERLINK l bookmark4 o Current Document 插件式应用程序框架3 HYPERLINK l bookmark6 o Current Document 病历模型结构图3 HYPERLINK l bookmark8 o C

2、urrent Document 数据接口模型4 HYPERLINK l bookmark10 o Current Document 规则引擎5 HYPERLINK l bookmark12 o Current Document 结语5【摘要】电子病历(CPR)系统是医疗信息化的重要部分,在国外有不少广泛使用的系统,但不能通过汉化提高国内CPRK平,现基于.NET平台和Cache数据库提出一种结构化电子病历系统方案,主要创新点包括平台选择、病历模型结构、接口模型设计以及规则引擎的引入等。【关键词】结构化电子病历系统病历模型结构接口模型规则引擎电子病历(Computer-basedPatientR

3、ecord,CPR)是以病人为中心的信息集成,是医院所有业务系统的有机融合,能完整、动态地反映患者的医疗过程,是对个人医疗信息及其相关处理过程综合化的体现1o电子病历又称电子病人记录(EMR,现正向电子健康记录(EHR发展。2007年中国医卫行业信息化建设与IT应用趋势研究报告显示,电子病历、PACSHIS系统的升级、完善和集成、信息安全等是2007年医卫行业信息化建设的投资重点2o目前不能通过汉化国外CPFC件提高国内CPRR更用水平。首先,病历的组织结构、描述方式中外有别,国外的CPRS统不能完全适应国内的病历管理规范。其次,由于电子病历相关立法以及监督机制等方面的差异,国外CPR!(统的

4、设计理念和国内不一样。现国内的CPR5求将病历打印出来进行手工签名以起到法律效应。国外的CPRS统以表格或树形结构的方式录入数据,很难将计算机中的数据还原成“手工病历”。因此,我们在认真分析了国内外CPRS统的基础上开发了基于.NET平合和Cache数据库的结构化电子病历系统。1系统体系结构系统结构见图1。数据访问层中对数据库的操作分两部分。访问组件在微软EnterpriseLibrary中DataAccessApplicationBlock基础上修改,增加了对ODB嗷据源的支持(因为目前.NET平台上还没有支持Cache的驱程),对Database抽象类功能进行扩充。图2所示的数据访问组件是

5、以工厂模式3设计的,Database和DbCommandWrapp都是抽象类。客户端代码通过DatabaseFactory类创建Database实例。通过Cache提供的CacheObject访问Cache多维数组。因病历输入过程中使用大量代码字典表数据,如诊断、症状、药品目录等。客户端在输入时都从数据库中读取,服务器负担很重,可用数据缓存方式加以解决。2开发平台选择因国内医院普遍使用Windows操作系统,本系统基于Windows平台以WinForm程序为主,采用.NET平台进行开发。数据库选择相对复杂。CP添统中包括病历数据和其它基础数据。对于一般性数据可用关系型数据库进行建模、存储,而结

6、构化处理后的病历数据就不能满足数据分析的需要。病历本身数据量很大,再加上结构化处理时增加的描述符,最终数据会增加很多。基于共享需要,病历数据以XMLB式保存4,对它处理要用XQuery、XPath等技术。虽然主流关系型数据,如SQLServer、Oracle、DB2等者B支持XML数据,但要提高数据查询效率,必须对数据添加索引。然而,病历数据的结构是动态的,不能有效建立索引。因而,将动态结构的数据分解为固定格式的明细数据。在关系型数据库中,路径表示数据在病历结构中的位置。同步数据时借助路径来定位,分析数据时通过路径过滤。因为病历数据分解为明细数据后数据量非常大,相应的路径数量非常多,且查询数据

7、时因缺乏必要的索引信息需遍历整个表。同时,值字段需要保存各种类型的数据,而字段类型只能是字符类型,在进行数据比较时要进行类型转换,查询的代价急剧上升。若能够提高数据遍历速度,并避免类型转换,将大大提高效率5。而这恰恰是Cache数据库的特点之一。Cache数据库的核心是高效的多维数据引擎。通过内置的CacheObjectScript脚本语言,可以直接访问多维数据结构,这样可以获得最高的性能和最好的存储利用率。当有特别的或者专业的结构并且不需要提供对象或者SQL的方法来访问数据时,或者当要求尽可能高的性能时,直接的“global访问”是特别普遍的。插件式应用程序框架本系统客户端使用基于Smart

8、Client技术的插件式应用程序框架,主要包括:加载基本模块:基础框架类库定义接口IPlugin、IStartup模块程序实现接口,主程序通过PlugInHelper辅助类加载:数据访问:基础框架类库定义接口IDataAccess,并实现SqlDataAccess,主程序通过DataAccessFactory访问数据库;浮动窗口:主程序支持浮动窗口显示,基础类库定义DockingWindow,DockingForm,DockingContent提供各模块类创建浮动窗口,例如工具窗口、病人列表等,在加载模块同时通过DockingHelper辅助类实现浮动窗口显示,并动态保存浮动窗口位置、显示方式

9、,支持不同操作人员设置;登录部分:采用基于角色方式的帐户管理,并加密处理,所有主程序加载的功能模块,都基于这个帐户的权限信息进行控制;报表部分:提供统一的报表服务。病历模型结构图系统对病历数据处理分为3个部分:数据访问部分负责处理和病历有关的数据存储操作。ModelStorage组件负责处理数据库中数据与病历对象之间的转换、实际数据与查询数据之间的同步。病历业务负责病历的内部逻辑。在EMRModefi件中完成病历对象维护、检查等工作。EMRWidge组件用来统一处理病历的展现及录入、病历对象数据与RTF文本之间的转换。病历界面包括病历模板设置程序和病历录入组件。在病历录入组件中只负责和文字编辑

10、有关的操作,数据的内部逻辑处理由EMRWidge组件完成。病历模型的实现比较复杂,主要内容如下。EMRNodeJ基本元素,表示病历内容,有三个继承类:EMREntity,EMRNativeText,EMRPackageEMREntity表示数据实体,病历结构中最小输入单位,也是数据分析基本单位,可以是多个数据项的组合。如“身高”数据,应同时包含“身高的值”和“身高的单位”两部分。EMRNativeText为原生文本,即以自然语言输入的文本。EMRPackag吻病历内容包,相当于文档结构中的目录,是个容器,可包含实体、原生文本或另一个包。EMRDynamicMoleNod的嵌入式模板,即“主诉”

11、、“现病史”这一层次内容,由EMREmbededMoleNode成。EMREmbededMoleNode嵌入式对象,即“胸痛描述”、“头部检查”这一层次内容,由EMRObject构成。EMRObject为元数据对象,即“发病时间”、“伴随症状”这一层次的内容,它由EMREntity构成,是病历结构中的最小显示单位。另为在模型中表示表格对象引入EMRTableEMRRowEMRCell三个类,分别对应表、表中的行和行的单元格记录。数据接口模型CPR系统是医院信息系统的核心,HIS、LIS、RIS、PAC潴系统都需要与其进行数据交换。在CPR勺应用范围提升以后,还会和其它系统进行数据交换。所以,C

12、PR勺数据接口定义非常重要。在医疗信息领域各种数据标准也非常多,其中影响最大、应用最广的是HL7协议。目前国内系统真正支持HL7协议的很少,系统投入使用前要么花大力气改造与CPFK网的系统,要么根据对方要求定制CPRS统数据接口,因此,我们设计了自己的接口模型。在接口中传输数据请求可分为两类:同步数据请求和读取数据请求6。由于同步数据请求发出后不需立即得到结果,可将这类信息放入一个异步消息队列,由专门的异步消息处理进程处理。而读取数据的请求需要实时处理。定义接口首先定义数据的传输格式、调用方式等。数据格式是中立格式,调用接口的系统与被接口调用的系统都要处理系统内部数据与接口数据之间的格式转换。

13、由于各系统使用技术不同,对于接口我们都通过WebService来发布。接口分独立消息处理服务程序、客户端接口处理组件两部分。因接口数据传输涉及两个系统,一要按通用技术标准设计接口屏蔽技术差异,二要提供接口处理程序处理意外情况,所以建立专门的消息处理服务程序。接口组件处理接口数据与内部数据转换及与消息服务程序间通讯。将接口组件放在客户端一是减轻消息服务器的负担提高并发性,二是降低程序实现的复杂度。接口消息体格式参考HL7的消息格式如下:编号发出系统接收系统消息类型应答标记请求编号数据体编号是唯一序号,发出系统是发出消息的系统代号,接受系统是消息要送达的系统代号,消息类型是消息需要完成操作的代号,

14、答标记标识此消息是否已被对方系统接收(保留字段),请求编号是本消息要回复的消息的编号,数据体包含了消息处理时所需的接口数据。6规则引擎在CP哪据逻辑处理中,需经常进行数据校验、联动处理,如以代码形式固化在程序里,工作量大,务业务规则变复杂后很难维护。同时不同用户业务有不同的规则需求,需不断修改处理逻辑,增加系统维护工作量。因此,本系统通过规则引擎维护一个规则库(通常以配置方式放入引擎),运行时将一组对象作为事实库交给规则引擎处理;规则引擎将对事实库中的诸条事实与规则库中诸规则的“事实”部分进行模式匹配,一旦某条规则指定事实存在,则执行该规则指定行为。在需要处理业务规则时,规则引擎会执行所有能够

15、与事实库中事实相匹配的规则。如病案首页中的住院次数、住院天数通常其标准的校验规则如下:IF住院次数哪据库中该病人病案首页记录数THEN提示住院次数输入错误IF住院天数(出院日期一入院日期)THEN示住院天数输入错误但在部分医院,这样的规则就不适用了。如病人在使用计算机系统前住过院,但以前的数据并不在当前系统中。又如精神病医院中与普通医院不同,患者在得到允许的情况下可回家休息,所以在医院的实际住院天数可能比出院日期和入院日期之间的差值小。在使用规则引擎方式处理后,只需在规则库中添加或删除规则即可。7结语CPR系统的设计必须针对国情,便于管理及符合医患的利益,我们提出的这个结构化电子病历系统设计方

16、案主要创新点在数据库平台选择、病历模型结构、接口模型设计以及规则引擎的引入等,有一定的推广与借鉴意义。【参考文献】1计世资讯,2007年医卫行业的IT投入总额将超过60个亿EB/OU.中国第一通信门户, HYPERLINK /38/a177604.html /38/a177604.html2唐维新.病历书写规范MD.南京:东南人生出版社,2002.3颜志展,严钟琴,江明惠,等.数位医管一医疗知识新风暴MD.中国台湾:葛瑞特健康生技学园,2002.DanieileArts.Comparisonofmethodsforevaluationofamedicalterminologicalsystem

17、.In:M.Fieschietal.M.MEDINFO2004.Amsterdam:IOSPress,2004.CurtisL.Cole,AndrewS.Kanter.UsingaTerminologyServerandConsumerSearchPhrasestoHelpPatientsFindPhysicianswithParticularExpertise.In:M.Fieschietal.MEDINFO004.M.Amsterdam:IOSPress,2004.AlanCooper,RobertReimann.软件观念革命一交互设计精髓M.北京:电子工业出版社,2005.出师表两汉:诸

18、葛亮先帝创业未半而中道崩殂,今天下三分,益州疲弊,此诚危急存亡之秋也。然侍卫之臣不懈于内,忠志之士忘身于外者,盖追先帝之殊遇,欲报之于陛下也。诚宜开张圣听,以光先帝遗德,恢弘志士之气,不宜妄自菲薄,引喻失义,以塞忠谏之路也。宫中府中,俱为一体;陟罚臧否,不宜异同。若有作奸犯科及为忠善者,宜付有司论其刑赏,以昭陛下平明之理;不宜偏私,使内外异法也。侍中、侍郎郭攸之、费祎、董允等,此皆良实,志虑思纯,是以先帝简拔以遗陛下:愚以为宫中之事,事无大小,悉以咨之,然后施行,必能裨补阙漏,有所广益。将军向宠,性行淑均,晓畅军事,试用于昔日,先帝称之日能”,是以众议举宠为督:愚以为营中之事,悉以咨之,必能使行阵和睦,优劣得所。亲贤臣,远小人,此先汉所以兴隆也;亲小人,远贤臣,此后汉所以倾颓也。先帝在时,每与臣论此事,未尝不叹息痛恨于桓、灵也。侍中、尚书、长史、参军,此悉贞良死节之臣,愿陛下亲之、信之,则汉室之隆,可计日而待也口。臣本布衣,躬耕于南阳,苟全性命于乱世,不求闻达于诸侯。先帝不以臣卑鄙,猥自枉屈,三

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论