云计算技术在海量电子病历数据分析中的应用研究
2018-10-16张东林
张东林
(山西中医学院附属医院,山西 太原 030024)
引言
信息化的电子病历与传统手抄病历相比,所包含的信息内容更加广泛,除记录病状、检验结果和诊疗记录等静态信息外,还记录了各类与诊疗相关的动态服务信息。例如病人的历年健康体检记录、转院记录、具有法律效力的医学证明等。此外,电子病历的作用也不仅被用于辅助医生诊疗,还可以用于病历信息的快速共享和数据挖掘应用。但是现有的电子病历管理系统大部分只能对规范化的文本信息进行有效的分析与处理,而对于一些不能明确显示其含义的非结构化文本信息,例如医生用自然语言表达和记录下来的医嘱、病人的临床症状等,还无法进行准确的识别与检索[1]。随着医疗信息化技术的不断发展,电子病历的数据规模也呈现出高速增长态势,实现对海量电子病历数据的高效检索与分析,是未来医疗信息化发展中面临的重要问题。而实现海量数据检索的关键在于对信息内容进行准确的识别,并在此基础上建立相应的关键词标注与检索机制,本文基于云计算技术与UIMA框架构建了一种电子病例文本数据管理与分析模型,为有效提升电子病历数据的检索与处理效率提供了新的解决方案。
1 云计算技术与UIMA框架
云计算技术是一项新兴的、共享式的信息化数据处理技术。它集合了计算机网络分布技术、服务器集群技术、信息通信、网格计算、虚拟化存储等一系列技术,其核心思路就是通过计算机网络将各类不同配置的数据处理设备高效整合后通过统一的接口为网络用户提供共享式的数据处理服务[2]。本文中所选用的Hadoop是一款开源的云服务平台,为基于云服务的第三方应用服务开发人员提供了性能优异的研究和实验环境。Hadoop平台主要包含两大核心模块:Map/Reduce并行处理模块,用于实现对复杂任务的分布式控制。HDFS分布式文件管理模块,实现数据的分布式存储与统一管理。HDFS能够有效屏蔽底层硬件的特性差异,可部署在廉价硬件设备集群之上,大幅度降低了资金成本的投入。
UIMA是由IBM研发,后又移交至Apache维护的一个开源结构框架。UIMA的主要作用就是将各类非结构化的数据中的有效信息分析与提炼出来,并按照用户的需求将分析结果呈现给用户。UIMA包含有三个核心业务模块,分别为控制读取(CR)、分析引擎(AE)、结果提交(CAS)。UIMA为这些底层组件的部署都提供有统一的API接口,支持开发者在其框架上扩展、部署和应用,为非结构化数据处理提供了非常有效的解决方案。
2 电子病历的非结构化数据处理需求
电子病历中的非结构化数据主要指的是无法通过固定格式对其内容进行表述和显示的数据信息,比如用自然语言表述的临床诊断记录,计算机是无法通过直接的检索操作获取到其中的各项关键信息的,若要求采用固定格式完成诊断记录的录入,就需要改变医生们长期形成的表述习惯,会严重影响到医生的工作效率,因此在短期内无法实现。同时,在涵盖了多所医院的区域级电子病历共享数据中心里,历年来积累的电子病历数据的存储量也极其庞大,医生如果想在海量的完全非结构化的电子病例数据资源中检索出所需的信息,以作为临床诊疗与学术研究的参考依据,也需要计算机提前对这些信息进行分析与预处理[3]。因此,该问题解决需要从技术层面来完成,即对非结构化的数据进行分析和处理,通过相应的计算机技术将非结构化的数据转换为结构化数据,而成功转化的关键在于对数据文件的整合以及对数据内容的分析并最终建立能够高效运行的索引库的过程。
3 云计算技术在海量电子病历数据分析中的应用
3.1 设计思路
系统通过在Hadoop平台中部署基于UIMA框架设计的数据分析引擎来实现电子病历中非结构化数据的分析处理,系统的数据分析处理流程如图1所示。
图1 数据分析处理流程
Hadoop与UIMA的整合首先需要进行小文件的预处理,由于电子病历中存在很多K级的小文件,存储时如不能进行有效的整合,将浪费大量的存储空间并严重降低数据检索速度。因此,电子病历的数据信息在导入到Hadoop之前,先要采用整合类优化算法对小文件进行排序组合。
在预处理完成后即将数据提交至Hadoop平台,Hadoop接收到待处理的数据时,会将数据同时交由主服务器和HDFS进行分布式存储与管理,Hadoop是典型的主从式服务架构,主服务器主要负责任务的分派与调度,主服务器主要实现与Map/Reduce的交互,创建Map任务列表,并将其按照先到先出的排列顺序分配到若干从服务器上执行[4]。UIMA的核心业务模块CR、AE将部署在所有的从服务器上,专门用于实现Map任务中非结构数据转换分析;HDFS则负责对输入的源数据进行存储。数据处理完成后的最终结果由UIMA的CAS模块提交至用户响应服务模块。
系统主要采用了分层的架构模型设计,主要包括数据维护、核心技术、业务逻辑三个层级如图2所示。
图2 系统分层架构图
其中数据维护层主要用于实现源数据、索引结果的存储与维护,主要包括HDFS、索引数据库两个功能模块;核心技术层则集合了UIMA的所有功能模块以及Hadoop的并行任务执行模块Map/Reduce,用于并行完成非结构化数据的初始化、关键语义分析、创建标注的核心业务处理;业务逻辑层主要包括服务类型分析、检索服务响应、索引创建三个模块,面向核心技术层提供快速的业务类型预处理操作,面向用户提供响应结果的索引创建和检索服务响应功能。
系统的用户访问功能实现并不局限于特定的程序开发语言与框架,用户可以通过WEB页面、APP应用等方式与系统进行交互,并可以基于第三方数据库创建用户访问权限验证机制,为系统的安全访问提供保障,系统在为用户提供快速检索服务的流程如图3所示。
图3 系统快速检索服务流程图
3.2 关键技术的应用分析
3.2.1小文件的预处理
在云存储模型中,小文件是指体积在20M以下的文件,由于Hadoop的HDFS文件系统的存储单位是64M,小文件长度即使不足64M,也会占用一个64M的存储单元,因此过多的小文件会增加系统的存储开销,降低存储空间的有效利用率[5]。小文件的预处理实际上就是在将文件提交至HDFS子系统进行存储之前就利用二维装箱算法对小文件进行排序、整合优化处理,以弥补HDFS文件系统在小文件存储管理上的不足。
对于病历数据中所包含的大量k级小文件,系统采用Hadoop API提供的SequenceFile机制,将多个小文件中包含数据记录都以
图4 SequenceFile文件结构
SequenceFile的结构特征非常适用于海量电子病历数据的优化存储,在对病例文件进行处理的过程中可以将每一条病例数据的唯一识别码作为Key,文本内容作为Value连续存储至SequenceFile文件中,并通过Hadoop专为SequenceFile提供块压缩功能对记录进行批量压缩,在有效整合大量小文件的同时,获得更高的存储效率。
3.2.2数据的分布式存储与管理
数据文件的存储主要基于HDFS分布式文件管理模块来完成,HDFS属于M/S(主从模式)体系架构,HDFS 集群由1个(且每集群中仅1个)NameNode节点与多个(集群中数量大于等于1)DataNode节点组成,各节点均由服务器构成。其结构如图5所示。
图5 HDFS体系架构
在HDFS的数据架构中,扩展索引作为一个重要的组成部分对数据检索的响应速度起到了决定性的影响。扩展索引由NataNode负责创建,在HDFS系统初始化的时候上传至NameNode节点并加载至内存中。在数据检索时,用户的每一次检索操作都会对该索引的内容进行扩展，以便再进行相同的检索时能够快速获取到结果,该机制可以有效地降低节点之间的网络通信频率,大量节省系统资源、提高运行效率。
在不同的应用环境中,有针对性的设计合理高效的扩展索引结构,不仅能够优惠数据检索的速度,也能够提升HDFS的文件存储数量。因此,本文针对电子病历的数据结构特征设计了相应的扩展索引结构,如图6所示。
RecodIDDataSourceFileTypeStoragePathStartPosition 记录标识数据来源文件类型存储路径起始位置
图6扩展索引结构
RecodID为电子病例数据库中记录的唯一编码,以bigint类型存储,长度为8字节;DataSource为创建该数据的医疗机构编码以Int类型存储,长度为4字节;FileType则用于标识文本、图片、影像等有限的类型信息,长度仅2个字节标识;StoragePath是在完成小文件合并与记录批量压缩操作之后生成的SequenceFile 文件在HDFS系统中的存储位置,由8个字符进行表示。StartPosition用于标识小文件在合并后的SequenceFile起始位置,长度为6字节。将以上数据汇总后可知,每个电子病历文件在HDFS系统中的扩展索引的大小为8+4+2+8+6=28字节。从理论上来说，NameNode节点服务器上仅1GB的内存空间中就可以缓存3234万条文件索引数据,可以为文件检索操作提供良好的响应速度。
文件在经过预处理和扩展索引之后,HDFS系统对文件读写的管理可简单概括为以下两个方面:
文件的写入。将预处理后的医疗文件序列信息添加至HDFS的命名空间,将整合后的数据块信息写入到数据节点,同时将数据块中整合的小文件与对应序列文件生成索引记录。
文件的读取。读取医疗小文件时,首先由HDFS的命名空间检索到文件所属数据块的存储位置信息,然后通过扩展索引列表获取文件在整合数据块中的序列信息,以锁定最终的文件位置信息。
3.2.3非结构化数据的分析
为用户提供快速高效的数据检索服务的基础是构造合理的索引数据库结构,而索引数据库是基于对病例中的非结构化文本数据进行合理的分词处理之后来完成构建的。在本文所设计的系统模型中,经过预处理的待转换数据在写入到Hadoop的分布式文件系统当中后,由核心技术层中的UIMA与Hadoop模块合作完成数据的分析转换,其处理流程主要包括以下三个步骤:
1)通过Hadoop的Map/Reduce模型为待处理数据创建Map任务,Map任务创建同时也会对待处理数据进行数据片段的分割,主要是依据预处理数据格式索引列表中的类型值进行分割。
2)通过创建好的Map任务获取到数据格式索引列表中的一组Key、Value值,依据Value值明确数据分析所要获取的中间结果类型,然后调用相应的UIMA组件进行处理,最后将获取到的制定类型的中间结果存储至HDFS,同时对Value值完成标注。
3)HDFS当中的Reduce任务将获取到的中间结果再依据Key值进行合并简化,也就是将具有相同输入路径的数据结果进行排序、整合、去重、过滤等一系列操作,并将最终结果存储至索引数据库当中。
在具体实现过程中,用于对文本进行分词的分析引擎由AE模块结合开源汉语分词工具Stanford与CMV(受控医学词汇库)共同组成,下面通过一个简单的病例文件来说明分词的过程。现有2个病历数据记录,其中包含的病例描述内容如下:
Datarecord1:性别女,微创手术。
Datarecord2:是扩张性心脏病患者,伴有心脏衰竭
通过分词工具处理后,获得的中文数据为:
Datarecord1:性别女,微创手术。
DataRecord2:是扩张性心脏病患者,伴有心脏衰竭
将“性别”、“是”等在医疗数据检索中无具体含义的词与标点符号过滤掉。获取到的数据为:
Datarecord1: [女] [微创] [手术]
DataRecord2:[扩张性] [心脏病] [患者] [心脏] [衰竭]
在数据检索中除记录数据文件中包含的关键词的内容以外,还应对各个关键词在每个文件中的数量与位置进行标记。主要包括两个方面,首先是关键词在整篇文挡中的字符位置,便于在向用户显示数据检索结果时提高对关键词进行突高亮显示定位的执行速度。其次是记录它在关键词序列中的位置,以提升在词组查询中的执行效率。根据所获取的关键词及相关信息而建立的索引数据表如表1所示。
表1 索引结果表
3.2.4索引数据库的构建
根据以上分析结果,可以在索引数据库创建数据表Index-Key-Table,该表格的字段结构与数据类型(以常见的MySQL5.0数据库中的类型格式进行描述)如表2所示。
表2 Index-Key-Table表的数据结构
其中RecordId字段用于对病例文件进行快速查找,内容为病例记录在数据库中的唯一编码,Place字段用于实现检索时关键词在文本中的突出高亮显示,内容以“N1,N2…Nm”的格式进行存储。在具体使用时,开发人员可以通过前端编程对字段内容进行预处理后再应用在检测结果的显示页面中。
4 结论
由于电子病历中存在大量的非结构化数据信息,这些数据信息增加了系统管理的难度,也影响了各个医疗机构之间信息的有效共享,因此本文提出了一种基于Hadoop云计算平台与UIMA框架的电子病历非结构化数据处理解决方案。在该方案中构建了专门应用于海量电子病例数据的分层模型,并根据电子病历数据的非结构化类型特点设计电子病历数据的预处理机制和数据处理引擎的核心部分Map-Reduce编程模型与UIMA分析引擎。该方案针对医疗类非结构化数据的检索优化可以显著提升大规模电子病历数据的处理速度,进而有效改善基于此类数据库运行的各类数据挖掘应用的运行效率，为未来智慧医疗系统的建设与应用提供可靠的基础数据支持。
