基于.NET平台和Cache数据库的结构化电子病历系统设计

来源:岁月联盟 作者:江凤莲 邓书显 时间:2010-07-12

【摘要】  病历(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系统的设计必须针对国情,便于管理及符合医患的利益,我们提出的这个结构化病历系统设计方案主要创新点在数据库平台选择、病历模型结构、接口模型设计以及规则引擎的引入等,有一定的推广与借鉴意义。

 

【参考】
    [1]计世资讯, 2007年医卫行业的IT投入总额将超过60个亿[EB/OL].第一通信门户,http://market.c114.net/38/a177604.html

  [2]唐维新.病历书写规范[M].南京:东南大学出版社,2002.

  [3]颜志展,严钟琴,江明惠,等.数位医管一医疗知识新风暴[M].中国:葛瑞特健康生技学园,2002.

  [4]Danieile Arts. Comparison of methods for evaluation of a medical terminological system.In:M. Fieschi et al. [M].MEDINFO 2004. Amsterdam: IOS Press, 2004.

  [5]Curtis L. Cole, Andrew S. Kanter. Using a Terminology Server and Consumer Search Phrases to Help Patients Find Physicians with Particular Expertise. In: M. Fieschi et al. MEDINFO 2004. [M]. Amsterdam: IOS Press, 2004.

  [6]Alan Cooper, Robert Reimann.软件观念革命一交互设计精髓[M].北京:电子出版社,2005.