M技术主要是美国从医疗行业里面发展出来的一个程序设计语言，它是美国国家标准语言，在1977年就是了，也就是说美国第三个国家标准语言就是这个语言，我们现在叫它M语言，当时是叫MUMPS语言，它首先是从医院信息系统应用中发展起来的，因为医疗领域数据关系很复杂，正好发挥这种语言的长处，它最早是麻省理工学院的研究成果。我刚才说它是美国三个最早的国家标准语言之一，其他两个是FORTRAN和COBOL，它们的名字是大家很熟悉的，第三个就是MUMPS，不搞医学领域信息化的人对它就可能不熟悉了，所以我解释一下。它的特点就是面向数据库的程序设计语言，在世界上用的地方很多，美国、日本、欧洲等等好多国家。1992年5月份被批准成为国际标准语言ISO M，大家知道程序设计语言至少有上千种以上，但真正成为标准的很少，除非它有很好的特色。也只有保持标准化保持得很好的话才有发展前途。92年5月份ISO国际标准组织开会的时候经过投票，批准它成为ISO M标准语言，当时有三十几个国家参加，我们国家的代表也投了赞成票，但是回来后没有见到做什么宣传，所以大家还不知道M语言已经是ISO国际标准的程序设计语言。
M语言的特长是它里头存在有一个独特的多维数据库机制，我们叫它“稀疏数组”，这个比较好的数据库结构能更好表示真实世界里的数据关系。因为医疗行业的数据关系特别复杂，所以M语言出来以后，首先在医疗行业里面得到大规模使用。经过长期的运行考验和发展，现在已经发展成为在M技术基础上融合了面向对象、面向Web和优化SQL技术的Caché后关系型数据库，它具有突出的OLTP高速响应性能和高伸缩性，运行可靠性很高又便于维护，非常适合于像医院信息系统和集成医疗提供网络这样的场合使用，所以它是在美国医疗行业里面应用的主流数据库，而不是一般的两维的关系数据库，例如在美国起码有几千所医院在用基于M技术的医院信息系统，例如在《美国新闻和世界报道》列为美国前十位的大医院都在使用这些技术，美国军方的医院采用的更普遍，经过美国国会组织的专家组评审以后，美国退伍军人署(VA)所属的172所医院都采用这种M技术设计的医院信息系统，就是著名的DHCP系统；接着，美国的国防部(DoD)又有580所医院也用了这种技术设计的CHCS系统。可见它应用的范围是很宽广的。事实上除了北美以外，在欧洲、大洋洲、拉丁美洲、亚洲、非洲的90多个国家都在采用这种多维的后关系型数据库技术。
我今天发言的题目是谈谈“我国HIS产品的现状、存在的瓶颈问题和出路”，也就是说这个医院信息系统市场蛋糕应当是很诱人的，但是眼下的情况不那么好，熟悉计算机医学应用的都知道医院信息系统在计算机医学应用中起码占了一半以上的比重，一谈到计算机医学应用的话，一些大的医疗信息学会开会的时候，这方面交流的文章一般都会占到一半以上。我们国内有一个CMIA学会，就是中国医药信息学会，也是中国电子学会下面的一个学会，它和国际医药信息学会(IMIA)保持着联系；今年7月31到8月2号在北京就将要开一次大会，那是第九届全国医药信息学大会，到时候在会上会有很多关于医疗信息化的文章发表，大家将会看到许多文章是围绕着医院信息系统建设的。
为什么讲这个医院信息系统的蛋糕很诱人？最近我看到了一些材料，有人分析，我们全国医院现在一年营业额总量大概是四千个亿，如果拿出1%投入医院信息系统建设的话，就是每年四十个亿，1%多不多？不多，因为在发达国家例如美国的统计每年实际平均数是2到4%，通常他们的医院每年都是拿相当于营业额里面的这个比例来做信息化的，国内当然比例不可能一下子大到2%到4%，但是到1%是可能的。比如北京的协和医院，它全年大概是六个亿人民币的营业额，它现在一年大概就是拿六百万人民币左右投入它们医院的信息化建设的。和它类似的一些大医院也是可以做得到的，因此分析者他分析的市场蛋糕情况，也是有一定依据的。假定每年有可能达到四十亿，那么五年就是二百个亿，一个五年计划下来就会是二百个亿。这当然是相当诱人的大蛋糕。但目前这还只是假设。
另一方面现实情况实际又是苦涩的，现实的情况并不是那么诱人，有很多困惑，我讲一下为什么会造成这个情况。大家知道从1993年八五计划开始，我们国内开始商品化的医院信息系统产品的建设，在此之前都是各个医院内部自己做，都是小规模的在微型机和局域网上的很简单的应用。1993年以后卫生部抓了一下，计委支持了一下，经过几年努力，有了进展。从1996年底以后，当时卫生部支持的众邦慧智公司的第一个商品化的HIS产品出来了。几乎与此同时，总后卫生部抓的由301医院开发的军惠HIS产品也出来了；接着又有广东巨龙和瑞得恒昌公司最早的几家公司产品以及后来另外几家的产品相继通过了卫生部组织的评审。这些商品跟过去医院自己开发的HIS系统相比有什么主要标志性的特点呢？一个是它是Client/Server结构的，另一个是有了GUI界面，从1997年到现在的几年时间里，又一下子冒出了一大批做HIS产品的厂商和类似产品，到现在为止有多少家HIS公司，可能大家比我清楚，我没做过调查，有人说是三百家，有人说不止五百家，因此有人说这状态好比是“诸侯混战”，有人说是“鱼龙混杂”，反正也分不大清楚谁家产品好，基本上是同一档次同一水平的同质化重复。当然前几年的进步和成绩应该是充分肯定的，但是客观地说这些现有的HIS产品仍然是初级产品，为什么？因为做出来的产品主要功能还只是着眼于完成医院收费和财务管理方面，并没有涉及到医院最主要的临床方面的业务，对临床信息管理方面的支持很少。我们说它是初级产品也可以是从规模上来讲，基本上大概都是使用一个主服务器的规模档次，在线同时用户数量到一百来个以上就有点吃不消了。特别是系统健壮性不够好，所以还不能说是胜任大中型医院的HIS产品。存在的通病是系统设计不够完善，不仅功能上有欠缺，而且性能也比较差，系统运行时不那么可靠。
这些初级产品原先设计的时候，比较仓促，或者比较粗糙，在系统设计上下的功夫不是太多，系统的体系结构设计也差，所以这里面没有涉及到医疗信息标准化的问题，因而没有能很好解决医院信息的共享问题，现在问题来了，上了医保以后，就不仅需要解决医院内部的信息共享问题，而且必须要解决医院与外部的信息共享的问题，可是目前各个医院所用的医院信息系统都是非标准化的不一样的产品，和医保要实现系统接口就麻烦困难不少。因为当时设计HIS时没有采用像HL7这样的国际上通用的标准，其实关于医疗信息交换方面的事实上的标准早就有了，HL7适用于OSI网络模型的第七层，也就是应用层的使用，但当时我们没有用这个标准，因为在那时做得很仓促，各个医院的计算机室的人临时抽调出来凑在一起来做，没想到这么远的事。应用程序都是集中在客户端那一头的，我们叫它胖客户机程序，所以由于应用程序的业务逻辑部分都在前端，改起来就非常麻烦。而现在医院里头的工作流程也还没有规范化，用户需求经常地在变化，使得应用程序也就少不了要跟着作改动，而原先依赖设计人员个人随意设计的程序又很难改动，再加上人员的流动因素，最初设计程序的人可能走掉了，他也没有写下很好的文档留下来，所以造成后来的人对于程序的技术维持的难度和工作量特别大，所以有很多公司为什么不赚钱，主要原因之一就在这儿。辛辛苦苦一个合同签下来，可能也就是几万块钱，十几万、二十几万，这种档次多一点。因为软件在用户眼里本来就不值钱，再高一点价格他不肯接受，加上厂商间也存在恶性竞争问题有的把价格压的很低，利润就很有限；等到因为用户使用中有问题或系统有故障要你多次派人去维护的时候，你坐飞机出差去一趟就化不少钱，所以最后那点利润基本上也就没有什么了，有的公司还赔钱亏损，所以现在HIS厂商的日子都不是太好过。现实中的苦涩与诱人的蛋糕形成了反差。
从HIS产品本身的质量和系统运行的状况来看也不能令人满意，系统比较脆弱，这个脆弱就是不能够支持可靠运行，就是做不到365天天全时可用，但是我们医院天天都要运作，医院信息系统不应该也不能停下来。可是我们现在可以看到这样的现象，也就是安装了HIS系统的医院遇到了HIS系统健壮性不好也就是系统脆弱的麻烦，北京的医院就出现这种情况，门诊系统负载一大就随时可能瘫痪。前些日子报纸上都报道了，有的医院系统一停就是几个小时，病人排长队去交药费几个小时都交不上。所以系统的可靠性最重要，而现在的HIS产品恰恰在这方面存在隐患。造成这个问题的很多因素很多，这里面有大环境的问题，我们政府的投入本来就少，有医院管理上的问题，再加上有一个认识问题，很重要一点是对于HIS的复杂性认识不够，往往低估了在建设、实施、和管理HIS系统上的困难。
造成HIS系统脆弱的瓶颈问题，从设计上看原因也是多方面的，我认为主要有三点：第一点，是最根本的就是因为数据库选择不恰当造成的，例如目前HIS系统初级产品的响应速度很慢，而且系统的响应速度性能还会随着时间的增长而逐渐衰减，这就很难令人满意了，另一方面数据库里的数据量增长得非常快，有的医院说是海量增加，三个月下来硬盘就满了，这样就只好清除数据，好不容易积下来的信息也就随着垃圾数据一起都要“请”出去了，不能放在系统里头，清除数据后还要因此停机重新做索引，这也会影响系统的正常运行，本来系统内积累的信息可能是有用的，假如能积累到全年、二年、三年或更长一些的数据，对这些数据就可以统计分析一下，对医院分析各个部门和环节的运行状态，研究如何提高工作效益、提升医疗质量，和降低医药费用就可能有用了，但是现在有的三个来月就把它“请”出去了，这就很可惜，更不用说系统因不可靠、不稳定造成的死机或宕机的严重影响是如何令人难堪和不能容忍的了。分析起来看，目前的HIS系统产品为什么存在着系统性能不好和可靠性脆弱的瓶颈问题呢，其中很重要的一个原因就是所选用的数据库存在着本身固有的根本性瓶颈问题。目前所用的关系数据库对于有些行业中应用来说是个很好的数据库，但是对于数据复杂的医疗行业来说就不见得是好的数据库，这种数据库一般主要只是适合于数据关系比较简单的场合使用，因为所有数据要想存进关系数据库中，便都要拆分成两维的关系表格才能存储，否则它就不能存储了，像一些非结构性的数据，例如现在大量的多媒体的数据要存到关系数据库里就比较困难。而且关系数据库里的关系表格的结构事先需要定义，结果不仅在表格结构扩展变动时就会有麻烦，而且特别是实际上并没有数据存储的也要地方也会白白占用大量数据存储空间，这种浪费和占用数据空间的直接影响是造成医院信息系统在使用中数据会动态增长过快的重要原因。此外关系数据库比较擅长的是OLAP方面的应用，而对于像HIS需要作大量快速OLTP处理的场合中的应用就不那么适用了。
而且医院信息系统又很复杂，一个医院信息系统要拆分成多少张关系表才能构成呢？一般要几百张表才行，再大一点HIS系统将会有五、六百张的表甚至更多，医疗环境中真实世界的数据关系本来就复杂，你要把这些复杂数据硬拆成那么多的表，来塞进关系数据库里就更不那么容易了，所以设计难度很大，怎么设计关系表和索引，怎么优化它们就成了设计中难以解决的问题，关系表的数量大到这个程度的时候，设计人员往往就失去控制能力了。这对于个别对关系数据库特别精通，设计水平高的人来说，也许还有点办法，对于一般的设计人员来说就会很难胜任设计要求了，那么多的表怎么合理拆分，怎么避免数据的冗余，怎么优化这个数据库的结构等等就会很难掌握了，原来一些在简单的数据关系中可以用的关系数据库设计的办法没有多大作用了，像“范式1、范式2、范式3”，在书本上告诉我们的几个办法，在这儿实际上很难用上，也起不了太大的作用。事实上数据存到关系数据库里边，基本上是个黑箱子，就是数据实际存储到哪个位置了设计者是不清楚的，所以你也没法控制它。假如我们有一个五六百张表的HIS系统，等你检索取数据的时候，你要依靠大量索引才能从这么多有关的表里边选取数据，就相当于把这些几百张表“连接”起来，检索的速度也就不可能快，而且取数据的时候还要对这些表加锁，加上“页”锁还不行，还要加上“行”锁，因为怕别人在你检索时改动这些表，但是这样锁来锁去就很容易造成死锁。
我有一次，在天津一家医院听到一个反映，医院说他们的HIS系统到下午五点就会闹鬼出性能问题，去看了以后发现不是别的问题，它出的问题是系统软件老是试图去解开一个并没有加锁的地方的“锁”，而这个地方实际上是没加过锁的，那也就根本没有可能来解开实际不存在的“锁”，这样一来其结果不就是形成了一个解不开的死结，一个死循环吗？这个出错的原因就是所用的那种关系数据库软件本身的毛病出的错，影响了HIS系统的正常运行。
所以HIS选用数据库不当这是造成系统脆弱的很重要的原因，许多基于关系数据库设计的HIS系统刚安装的时候初期的响应速度可能还行，等到用户数多一点，时间长一点，就会响应很慢甚至慢得令人难以忍受。我有一次去北京的一家技术力量相当不错的医院计算机室访问，就恰巧遇到过这样一件事，正好医院中有人打电话向计算机室反映情况，说是在计算机终端上已经等了一个来小时了，系统也不回答响应他的使用请求，计算机室当时查了一下发现其原因只是财务科有人在读一张大一点的表，结果就会造成了这种对用户使用产生严重影响的问题。目前在一些医院中安装使用的HIS系统实际上就是存在着这样或那样的性能脆弱问题，但是我们仍在凑合着用。美国人在早期HIS建设中就遇到和知道医疗行业数据关系特别复杂这个问题，所以他们大量的HIS系统就不用两维的关系数据库，他们一般选用多维的基于M技术的树型结构数据库的来做HIS，因为这种数据库引擎用的是稀疏数组，事先不需要声明定义数据库结构，数据库的大小可以按需要自动增长，而且只有存放实际数据的节点才会占用空间，没有数据的地方就不会白白占用数据空间，也就不会像用关系数据库时那样出现数据库无谓增加得很快和很大的问题。，根据国外医院所做的实际对比表明，采用多维数据库比用关系数据库时存储空间可以节省硬盘存储空间三分之二以上。而且它的查询响应速度不会随用户数加大和运行期间的长短而出现性能明显衰减现象。目前国外最大规模的医院信息系统在那里呢，就在哈佛大学的教学医院之一的Brigham & Women’s医院，采用的就是基于M技术的多维数据库,我也去看过，他那儿的HIS是很大的一个系统,利用55台服务器构建的分布式数据库大系统,这些服务器都带有镜象服务器，在系统上支持的同时用户数在6000以上都没问题，系统在性能上照样可以快速响应，而且系统很健壮安全,，一年三百六十五天二十四小时运行。而我们现在医院里安装的HIS系统往往有一两百个用户同时使用就吃不消了，响应速度会慢得令人忍受不了。我们现在的系统设计也不好做分布式数据库系统，例如发现门诊量大了，想在门诊马上加一台数据库服务器都办不到，人家用的是多维数据库本身就自带有高速缓冲网络协议，要做分布式数据库很容易，而且对于程序设计人员是透明操作的，不需要他们干预。而我们目前的HIS产品就不能或很难实现分布式数据库，因为要实现它就全得靠程序人员自己去编程序实现，就太麻烦了，即使理论上可以实现，实际工作量也太大。
现在基于M技术的数据库已经上升到融合了面向对象和面向Web的新技术的新阶段，国际上广泛采用的是Cache’数据库，它就是一个带有分布式高速缓冲协议的独特报道的多维数据库，因为在分布数据库的情况下，它自动可以为你开了好多高速缓冲区。你想增加应用服务器可以在命名逻辑空间中去加，不用停机，不会影响系统正常运行，随时可以增加，也随时可以去掉，所以那个系统非常方便，响应速度又快。例如我们在Caché数据库上做过一些实验，就可以用SQL语句从一百万条数据库记录中查到所需结果，查询响应速度非常快。我们现在的HIS产品中用的还是关系数据库，而且可能用的还可能是几个用户版的小规模数据库软件，我经常说它是小孩的骨架做不了大人事。所以医院用它开始安装HIS时好像可以用，但是实际上不可能支持一个中型或者大型医院来使用，这是一个非常突出的需要认真解决的瓶颈。 |
发表于 2004-2-23 19:23:36