[转帖]闲话医疗信息系统集成

闲话医疗信息系统集成 梁梁 占志刚 张继武

梁梁先生，Carestream Health全球研发中心(上海)工程师；占志刚先生，项目经理；张继武先生，博士，总经理，大亚太区研发总监。

关键词: 医疗信息系统集成  PACS RIS

一  前言

　　很多人说医疗信息系统是世界上最复杂的信息系统之一，此话的真伪难以考究，毕竟很少有人做过定量的估算或者跨行业的比较。但这种说法，无论是对外提升这个行业在人民群众心目中的地位，以维持它应有的产品价格；还是对内激励那些热衷于挑战自己的年轻工程师，以维持他们加班时的工作热情，都是很有好处的。
　　对于医疗信息系统的复杂性，前人已经有过不少关于平台异构和业务多样性的直接论述。但我们的客户，在一线工作的医学家们，最习惯的思维方式还是对照，或者说对比。回顾前一轮的企业信息化浪潮，开始很多小公司也是从财务、人力资源等部门级系统起步，经过几年间行业发展和整合，不少公司已经可以包揽财务、生产、进销存、客户关系等等整个完整的ERP系统。这也是很多企业客户非常愿意看的，商务上他们不会再被众多低水平的厂商弄得晕头转向，技术上也降低了部门系统之间集成的风险。但在医疗行业，至今为止几乎没有一家公司能把PACS、RIS、LIS、EHR、HIS等全部做完。而且，就算有一个厂商能招揽到熟悉医院里每个科室的业务专家，它也还要花大力气来打破白色巨塔里面早已形成的一道道屏障，因为信息系统本身就要求穿透这些屏障，从而实现更高效率的共享和协作。
　　于是厂商们首先只能采取分治的策略，有人做PACS/RIS，有人做LIS，有人做HIS/EHR，每个厂商都成为某个部门系统的专家，并把是否要上马做另外一个部门系统看作像进军一个新行业一样困难。然而最后在医院，每个系统如果只是独立运行，它所能提供的生产力都会大打折扣，唯一的方式就是建立一套跨厂商集成，甚至可能相互协作的机制。
　　对于一些简单的HIS，让临床医生开开药方，写写病历，这些文字工作可能不需要太多来自其它厂家的数据也能正常运行。有些系统，比如PACS/RIS，如果无法从设备上获得图像，便形同虚设，因此也成为最早引入行业标准的领域。从上世纪90年代末到本世纪初，PACS/RIS的迅速发展也促使DICOM迅速地更新换代。最早这个标准只是为了解决影像设备之间数据传输的问题，从3.0版本之后，工作流相关的部分得到了增强，任务清单的出现让PACS/RIS与设备之间的集成从数据共享提升为协同工作。
　　但行业标准还远远不能覆盖医疗集成中的所有问题，于是人们建立了IHE这样的集成框架，相当于业务层的设计模式。不太清楚其它行业是否存在这样的先例，至少对于医疗行业的工程师们，除了用那些可怕的DICOM二进制流，或者生硬的HL7文本，还可以用这种模式语言来相互交流。医疗行业的工程师们的确值得为拥有IHE而感到幸运。IHE也许无法抽象出现实世界中所有的复杂性，但至少为我们提供了一种目前可以使用的有效工具。近几年间IHE的发展，已经进入包括医学影像在内更加广阔的医学领域，为我们在UML图纸上不断展现出更多关于集成的故事。
　　尽管如此，集成领域还有太多的问题没有解决。在现场工作的人们，顶着老板和客户的压力，有时只能抛弃之前所有标准和模式的框框，凭借自己的经验、分析、猜测，甚至还要有一点点的运气，方能左右逢源，见招拆招。然后他们的经验也会慢慢累积，成为标准和模式的一部分，供大家分享。为此目的，本文总结了以PACS/RIS为主的医疗信息系统集成中的一些琐碎经验，希望在主流的行业标准和框架之外，给技术人员提供一些参考和启发。

二  背景

　　我们把不少公司的PACS/RIS产品线从时间轴上展开，会发现一些有趣的相似之处。大家刚开始做miniPACS时，RIS和PACS几乎都是糅合在一起，一个明显的标志就是在工作站上看图和报告是在同一个进程内强耦合地运行。有些系统虽然声称有独立RIS服务器和PACS服务器，并且用Broker来集成它们。但国内的应用环境太小，为了实现完整的诊断流程，只能把RIS服务器和PACS服务器以及Broker全部安装在一台机器上，这真是让人尴尬。其实Broker应该是国外一些PACS/RIS前驱们提出的一个概念，不知是盲从还是想作为提高价格的筹码，很多做miniPACS的公司，以及很多想做fullPACS但市场环境又要求他们只能做miniPACS的公司，都不约而同地把Broker纳入他们的产品线，于是陷入了吃力不讨好的境地。
　　其实Broker只是这种高不成低不就的产品线架构的一个缩影，似乎能反映出当时大家对市场细分还没有太多的概念。其实国内很多中小医院，以及对信息系统还不太了解想先试探一下的大医院，都更能接受miniPACS的方案，比如只需要一些独立运行的工作站，能从设备上获得图像，然后看图，写报告，打印胶片，刻录光盘，甚至修改信息，然后把图像发送出去就行。于是灵活便捷的单机版工作站成为了热卖。与此同时，还有余力的公司，以及其实没有什么余力但还存有梦想的公司，终于把RIS和PACS彻底地分开。RIS提出了Brokerless的概念，自己提供DICOM和HL7的接口；PACS也可以面向整个医疗机构存储和处理更多不同类型的图像信息。这就有点SOA的味道了，每个系统业务完整，系统之间松散而清晰，Broker也不再只是做DICOM和HL7之间的转换，更应该扮演ESB的角色了。
　　于是，我们在PACS/RIS的演化树上看到了一个明显的分支，一个是更简单的miniPACS，一个是更复杂的full-PACS。如果把集成的工作放在这样的时间轴上，不难发现我们现在已经站在向更复杂和更松散延伸的分支上；因为另外一个分支更像传统医用设备上的嵌入式软件，需要的是独立和内聚。在这样的软件内部也会有很多松散的模块，然后在一个基础框架上组装起来，但这已经远离信息系统集成的概念了。

三  关于桌面集成

　　我们习惯性地把集成分成几种类型，数据集成，工作流集成和桌面集成。一般意义上的互联，比如DICOM，HL7或者非标准的数据共享，应该算是数据集成。我们也愿意把简单的互操作也理解成数据集成，它无非是把带有命令语义的数据传给对方而已，而真正的工作流集成应该是一种有序和受控的数据流，最好是符合IHE，符合工作流参考模型，并基于工作流引擎来实现，于是可配置。关注前两种集成的人应该占大多数，也创造了各种千奇百怪的集成工具，从最简单的验证DICOM的命令行工具到巨无霸似的Biztalk Server。这些工具的一个共同特点就是在后台运行，这似乎让做集成的工程师有一种莫名的优越感，因为实现用户界面总被认为是实习生应该做的工作。然而对大多数用户来说，用户界面几乎就是软件本身。不清楚CCOW对桌面集成的理解里面，有没有真正关于用户界面的东西，总之我们理解的界面集成里面，不仅包含CCOW提到的在同一台机器上不同应用程序间的相互通信，还包括这些应用程序应该具备统一的人机交互方式。也许这已经有点在讨论可用性(Usability)的味道了，但在医疗领域，可用性却是避免操作失误和医疗事故的重要设计。
　　前面讲到PACS和RIS的独立实现，为了实现真正的弱耦合，除了服务器端的拆分以外，还有客户端的拆分。也就是把报告模块和看图模块分开成两个进程，然后在同一台机器上互相通信，打开报告的时候可以看到图像，打开图像的时候可以看到报告。按照CCOW推荐的做法，我们要定义一个消息分发服务，应用程序启动时候先到这个服务上注册一下，运行的时候就可以根据注册时提供的应用程序ID来收发消息。当然具体实现的时候还要考虑消息的时序，同步或者异步，以及给Web应用和桌面应用提供相应的接口等等。
　　关于统一的用户界面，业界也有不少Best Practice。不少厂家工作站上的主要模块可以用屏幕一侧的选项卡来切换，然后每个模块里面图像显示区域和工具面板也有固定的位置和比例。如果你仔细研究，甚至发现调节图像的鼠标操作也有非常细致入微的设计，不管是普放的挂片还是断层的定位，不管是Zooming的比例还是Windowing的步长。这一部分的桌面集成，比如基于选项卡的界面结构，以及记录用户浏览和操作习惯的User Profile，通常都是通过公司内部产品线的一些共享组件或框架来实现，的确难以定义成行业标准。不过像User Profile之类的配置如果能在程序间共享，的确是件有趣的事，这样某个左撇子医生不管在临床的WEB工作站还是在专业的CAD工作站上都可以用他习惯的鼠标左键来调节窗宽窗位。想想其实类似的事情还挺多，比如Hanging Protocol和Key Image。
　　不过选项卡式集成一个明显的不足是不能同时看到两个应用程序的界面，比如这两个界面刚好一个是报告一个是图像呢？好，那我们就把它们分别摆在两个显示器上。这似乎能更好地解决这个问题，也是现在业界流行的做法。其中的一个关键细节在于，医生常常需要拿现在的图像跟过去的图像相比较，在多屏系统上打开以前的图像的时候，希望打开当时写过的报告，同时也不需要关闭现在正在写的这份报告。我们显然不愿意当用户在一个显示器上选中任何一张图像的时候，在另外一个显示器上都会自动同步显示它对应的报告，这看起来似乎理所当然，但会导致报告和图像之间循环调用，从可用性的角度，自动化的滥用也会产生不便和混乱。
　　这应该用到另外一个Best Practice了，也许不见得是什么Best Practice，只是在现场重重压力之下的应急之策。因为大多数RIS都提供了在WEB上看报告的功能，通常是给临床科室使用的。为了在看历史图像的时候能看到既往报告，我们让医生点击一个按钮打开RIS的网页，网页上就是当时写的报告，这其实就把桌面程序和WEB程序给集成起来。我们知道WEB程序跟桌面程序最大的区别在于他们使用不同的状态控制模型，为了让医生切换到另外一份图像的时候，能够自动关闭不再使用的报告，我们要把网页用IE控件嵌入到桌面程序里。于是才知道IE原来不只是一个简单的浏览器，而是一个如此灵活而且开放的框架。
　　当下以Ajax和XAML等为代表的新技术，似乎在暗示着桌面程序和WEB程序编程模型的差别，在未来的软件开发中会越来越小，以后我们也许就不需要用在桌面程序里嵌入IE这种奇怪的方式来跨越这两个模型之间的鸿沟了。记得在某次Vista的商业演示中，看到一个电子病历演示，在一个有点象电子游戏的界面上，3D头颅在不停地旋转，红色的心电图在兴奋地跳跃，整个界面设计真是让人耳目一新。让我们期待新技术伴随着医疗信息集成走向更加光明的未来。

（全文完）

来源：《世界医疗器械》

集成难达成的因素里面，技术其实只是很小的一块了，最重要的还是业务因素和客户中人的因素啊

最主要是适合特定用户群的系统。其实管理系统编制没什么难的，但是否能真正适合客户使用却不容易。