电子病历对存储系统的挑战_薛万国

  • 格式:pdf
  • 大小:224.94 KB
  • 文档页数:4

计算机世界/2010年/8月/9日/第030版新卫生“电子病历大讨论”系列之七电子病历对存储系统的挑战解放军总医院计算机室薛万国医院对存储容量的需求巨大。

与之相应的,医院对于存储系统的应用也面临诸多重要的技术与管理的挑战。

目前以电子病历为核心的医院信息系统备受关注。

根据卫生部颁发的《电子病历基本规范(试行)》的要求,电子病历的推广应用,必将对传统的存储系统提出更高的需求。

电子病历是个人终生的医疗和健康记录,要求医院建立与之相应的电子病历系统并且能够随时随地访问该系统。

这意味着:假设某个人10年前得过肝炎,在医院看过病,那么今天他再来医院看肝病的时候,医生就可以立即调阅病人在10年前的病历记录,而不用等待半个小时或一个小时,甚至更长的时间。

医院存储的五大挑战总体看来,以电子病历为主导的应用,正在给医院存储系统带来五个最主要的挑战。

一是“存得下”。

即电子病历客观上要求存储系统容量大幅度增加。

特别是对于病人人满为患的大医院而言,要把所有病人的电子病历长期保存下来,对信息存储容量的需求是非常可观的。

二是“取得出”。

即医院所存储的各种信息,要随时随地能够完整地取出来。

而要保证所有信息都是完整无损的,就要求存储系统具备高可靠性。

不能因为存储年限长了,出现数据丢失或残缺不全的问题。

三是存取速度快。

电子病历系统是支撑医院日常服务运营的业务系统,使用者主要就是医生和护士。

通常医护人员的业务过程都非常紧张,这就要求与电子病历系统相关的数据存储过程必须快速高效。

比如,医生在计算机上调阅影像时,最好把等待的时间控制在几秒钟之内,如果调一张片子要等上几分钟,医生肯定无法忍受,电子病历系统的应用效果势必大打折扣。

四是价格低。

由于技术的进步和应用的普及,各种存储介质的成本仍在不断降低,但是,电子病历对于存储系统的快速增容压力,势必导致医院存储系统投资的快速上升。

医院对于存储的投入,肯定是希望控制在自身可承受的范围内,并且要凸显相比以往纸介质存储病历的成本优势。

五是周期长。

按照卫生行业的相关行政法规,病人的信息资料保留的周期要足够长,至少几十年。

而按照全生命周期的居民健康档案的要求,一些基本数据要求保存更长的年限。

近几年,存储技术发展变化很快。

技术的发展使得电子病历的信息存储体系也在发生变化。

比如,5年前,存储方式分为紧急在线、近线、离线等方式,存储体系有三、四级之分。

当时离线的存储还要考虑磁带库、光盘库这些方式;现在,存储体系基本上就是一级或者两级,存储方式通常是在线和近线,而不会再去考虑磁带库或者光盘库这样离线的方式。

技术的进步,使得磁盘联机存储已经成为可能。

分层应对的基本思路根据医院的实际应用状况,我们可以将存储系统分为三个层次:最底层是存储物理层,即磁盘阵列,如:SAN阵列、NAS阵列、DAS阵列等。

中间层是存储管理层,包括备份、迁移、虚拟化等存储管理系统,负责管理存储物理设备,构建一个对应用系统透明的存储系统。

最上层是存储应用层,由应用系统对存储设备进行配置和使用。

比如:数据备份可以在应用层实现,依靠应用层的软件对数据进行备份。

之所以把存储系统分为三层,就是要从不同层次去解决医院信息存储面临的挑战。

也就是说,对于同一类挑战,我们可以从不同的层次考虑综合解决方案。

比如:对于数据备份的问题,既可以从数据管理层寻找解决之道,也可以从应用层加以解决;对于容量的挑战,既可以通过扩充同一阵列的磁盘来解决,也可以通过扩充不同的阵列,然后从应用层配置入手加以解决,还可以通过云计算在管理层加以解决。

现在,存储管理发展的趋势是,逐渐把一些管理的功能从上层向底层迁移,让各种应用不用感知相应的信息存储细节,比如是怎么存的、存放在何地。

总之,上述挑战其实是可以从不同层次解决的。

医院存储之忧与解决之道挑战一:容量电子病历包含的数据类型非常丰富,既有结构化的文本、自由文本,还有波形、图像、视频等。

随着技术的进步,现在医院需要记录的信息比过去要多得多,诸如超声、手术等动态过程,由此带来的数据增量巨大。

以北京某大型三甲医院为例,每年静态医学影像的增量大约为10TB~20 TB,有放射类的需要20TB,如果把一些动态的影像都算上,每年的数据增量在数十TB。

如果按保留10年计算,那就需要几百TB。

可以想像,医院对存储容量的需求是多么巨大!解决方案:可以从底层的存储物理层扩大磁盘,同时从应用层想办法,比如可以进行有损压缩。

例如,三年以上的影像数据,对于诊断已基本没有价值,只是具有作为医生临床诊断比对的参考价值,或者是供教学使用。

医院可以对这类影像进行最高20倍的压缩。

挑战二:数据生命周期管理到目前为止,医院数据的生命周期管理问题在实际应用中还没有很好地解决,尽管前些年很多IT厂商就在讲数据的生命周期管理。

首先,数据库中的数据怎么办?很多数据存放在数据库,比如医嘱、化验结果等,医院每年OLTP数据库的记录数就达数千万行。

对数据库管理构成的最大挑战不是容量,而是大数据量后的性能。

这也是具有中国特色的一个问题,国外很少提及,因为中国的医院规模太大,病人太多。

对于电子病历而言,其数据长期存放于数据库,肯定不行;而是要将数据取出来,电子病历的数据如何归档?这一问题在存储管理层无法解决,只能从应用层解决。

其次,文件型数据如何迁移?影像就是典型的文件型数据。

一般而言,近3个月之内的数据使用较频繁,3个月以前的数据就使用得比较少了。

我们经常要把一些不常用的数据从昂贵的阵列里迁移到廉价的阵列里,从而提高存储投资的应用成效。

而要将大量的原始数据向压缩数据迁移,其实现方式仍未可知。

即使数据迁移之后,又如何让访问透明化?让用户感觉不到存储介质和路径的变化?这些问题目前还没有很好地解决。

这既有存储厂商的技术问题,也有应用系统厂商的问题,需要IT业界从不同层面加以解决。

解决方案:应用层要特别针对医疗业务系统设计历史数据管理功能,解决数据库数据的卸出和文件型数据的迁移,也可以通过存储管理系统软件实现文件型数据的透明迁移。

挑战三:性能首先是文件系统的性能。

比如PACS系统,大量的数据不断进入系统中,接入设备增多就造成系统的响应速度越来越慢。

“慢”的根源在哪里呢?并不一定在于服务器,而可能在于存储。

大容量数据的并发与实时读写会导致磁盘阵列出现瓶颈。

磁盘阵列瓶颈怎么解决?一般可以用多重阵列并行分担,把数据分到不同的阵列。

这就对应用层的存储配置能力提出了很高的要求,应用系统需支持同时把数据写到不同的阵列上。

其次是数据库的性能问题,数据库真正的瓶颈往往是在磁盘,数据库对磁盘容量的要求相对较小,但对速度的要求较高。

对于这一问题,我们是否可以依托于固态盘这一新兴的存储介质来解决?但固态盘在寿命上是否有问题?这些问题都有待进一步验证观察。

解决方案:可从存储物理层和应用层这两个层面来解决。

挑战四:备份与恢复(可靠性)以往,在服务器比较少的时候,备份和恢复是比较容易的,而且还能做到实时备份,能把服务器当时产生的变化实时地记录下来。

现在的问题是,临床信息系统越来越细分、越来越专业,服务器数量越来越多。

医院的机房里一般有几十个系统、七八十台服务器,这么多的服务器还能不能都各自建立一个备份系统?这件事情非常难。

在备份方面,医院还面临着如下挑战:怎么做备份?一旦出了问题能否恢复到任何一个时间点?如何对备份进行管理?几十台服务器总不能逐一去备份,能不能做集中备份?备份的介质又怎么管理?这些都是令我们苦恼的问题。

我们不希望把所有鸡蛋放在一个篮子里,数据到底是统一存储,还是分散存储?存储的容量越来越大,一旦出了问题,数据恢复的时间如何保证?我们知道,一个几十TB的磁盘崩溃了,不是短时间内能恢复的。

还有备份方案的选择,是用磁盘备份还是磁带?过去我们用磁带库模拟磁盘,现在用磁盘阵列模拟磁带。

我个人以为磁带仍然还是很有用、很可靠的。

解决方案:从存储管理层寻求解决路径。

挑战五:能耗磁盘阵列的散热已成为机房管理的重点。

磁盘阵列越来越多,一个阵列一个柜子,夏天一到,机房热得不行,对空调系统构成巨大压力。

如何减少能耗?磁盘在不用的时候能否休眠,一旦有数据访问请求的时候再启动?但磁盘响应的速度稍微慢一点。

还有一种办法是增大单盘容量,减少磁盘数量。

解决方案:着重优化存储物理层。

挑战六:长期持久性第一,随着存储容量的线性增长,采用什么样的存储技术来支撑线性增长?第二,磁盘阵列要不断更新,由此带来了数据移动的问题。

以PACS系统为例,以前是1TB 一个卷,现在是10TB一个卷,要把原来存放在不同卷上的数据合并到一个卷上,原来的数据位置就要移动,移动后应用系统就访问不到了。

第三,随着电子病历的不断发展,数据的格式也在改变,怎么样保证存储系统的兼容性?这不是一个物理的问题,是应用层面的问题。

解决方案:存储物理层:扩展技术;应用层:数据管理。

选择存储的基本原则:简单即美根据多年来的实践经验,我个人对存储方案选择有如下几点认识。

首先,保持简单化。

存储技术呈现日益复杂化趋势,分布式存储、云计算等新技术层出不穷。

从应用的角度,我的观点是:简单即可靠、简单即可管理,不能贪图复杂与先进。

而且,同样的问题可以在不同的层面解决,不一定都要全部从最底层的物理层解决。

其次,合理选择阵列配置,把握好产品的设计与应用的环境的匹配,选择合适的产品。

磁盘阵列有很多系列,包括不同的性能、不同的型号、不同的定位。

我们在采购的时候,要把我们的需求和定位选择好,不要一味地追求高价格产品。

比如SAN阵列,拿惠普来讲,有EV8000、EV4000、MS2000等不同系列,配置不一样。

SAN的设计目标是在网络环境下使用的——是多台服务器共用。

多台服务器共享的时候,它的性能会很好,足以支撑,可是在我们医院的环境里,存储处理大都是点对点的,SAN阵列只为一台服务器所用。

在这种情况下,我们就不一定非要选择EV8000,可能EV4000更合适。

第三,合理选择产品生命周期。

现在的技术发展很快,最初购买的时候总想到今后的扩容,容量要能够线性增长,但实际上线性增长不一定通过一个阵列实现。

比如,现在买一台10TB的阵列,而且实际只用10TB,将来可以扩到100TB。

但结果往往是,三五年以后,当我们需要扩的时候根本就无法再扩了,因为那个磁盘的型号早就没有了。

过去的阵列磁盘容量是146GB,现在磁盘容量是2TB,你还会对过去的阵列进行扩充吗?不大可能。

所以,实际产品选型,还要在扩展性与产品生命周期之间取得平衡。

(根据会议发言整理)。