集成的故事 - 集成的本质

 
一次出差的时候,我给热衷艺术设计的爱人买了一本书,名字叫做“设计中的设计”。书名中的递归形式,本来就很容易让熟悉程序设计的人怦然心动,前言中的一句话,更是耐人寻味。

“能下定义或以文字记述下来并不能称为了解,反而是将已知的事物未知化后,尝试挑战其真实性,才能对其更深入了解。” ——原研哉

几篇故事下来,对于医学信息系统集成领域,无异于冰山一角。倘若哪天真能记录下整座冰山,在这位设计大师的眼里,也不能称为了解。或许我可以按照他推荐的方法,尝试把集成这件事未知化,才能探求到其中的本质。

---

在“集成的故事 - 动态数据迁移”一文里,我提到动态数据迁移的方法其实来自跟同事讨论所得到的启发。记得当时我们一起研究那个HIS的编码系统的时候,发现它跟RIS中编码差别实在很大。实际上RIS是用一个字段来表示检查方法,里面同时包含了检查部位和体位,而HIS里面检查部位和体位信息是分开成两个字段的,也就是说RIS的一个编码需要跟HIS的两个编码相对应。基于这个事实,至少LUT的解决方案理论上还是可行的,虽然跟动态方案相比工作量会大得出奇,而且能用静态映射解决的问题动态的方案也一定能解决。于是,我开始思考,到底两个异构系统差异到什么程度,集成才变得不可能,或者换句话,具备什么必要条件,集成才变得有可能。

不需要太多的推理或者求证,我大概能猜到集成的前提应该是一种语义上的相似性。这个前提,不管在多大的两个互操作的系统之间,或者小到一个主程序和一个子程序之间,应该都存在。比如要调用一个函数,调用方必须知道要把什么东西传给被调用方,被调用方也要知道它将获得什么东西。这就有点象SOA里面的contract。当然SOA的contract应该会规定得更加的具体,里面应该同时包含了语法和语义,这样才能达到所谓的“边界清晰”的要求。而我们平时的集成工作,其实就是做语法的转换,这种转换应该具有语义的不变性。比如,我们把DICOM的(0010,0010)字段取出来,放到HL7消息的PatientName字段中,数据表示的方式改变了,但图象系统知道在DICOM的这个字段里保存的是病人姓名,临床系统也会假设它从HL7的这个字段里应该能取到病人姓名。作为语义的病人姓名,在这整个过程中是不会改变的,哪怕其语法形式从简体变成了繁体,从汉字变成了拼音,甚至姓和名的位置颠倒一下,但集成双方还是会把它作为病人姓名,而不会作为性别,年龄或者是其他。当然也有特殊情况,比如有些系统里面不能保存年龄,我们会把年龄信息拼接到姓名后面在一个字段里一起传给它,但这正是这个系统的使用者对它的期待,他们所想在界面上看到的,正是在来源系统里面可能是分别存储在两个字段里面的病人姓名和年龄。再特殊一点,比如要判断来源的某个字符串里包含一个特殊的字符才去触发目标系统的一个事件,其本质也是一样,是否触发事件如果可以定义为一个布尔值,那么人们对这个布尔值的解释,也就是语义,应该跟人们对“来源的这个字符串里是否包含这个特殊字符”这个解释,应该是一样的。

我们进行这种语法转换的最初动机,应该是弥补两个系统之间的信息差异,把来源系统的某个信息传输给目标系统,而语法转换只是确保传输能正常进行的一种手段。这就是通常意义上的数据集成。从这个意义上说,其他的工作流集成和桌面集成应该都是建立在数据集成的基础上的,它们通常是在原来无序的数据流之上建立了一些时序,或者追加了一些特殊的语义,其目的已经不是简单地在多个系统之间共享数据,而是让多个系统协同工作,不管是在一个分布式环境里,还是在同一台工作站上。

---

于是我们惊奇地发现,在Broker和工作流引擎之间,似乎并没有太大的距离。传统意义上的Broker,会做数据格式的转换,字段的映射,记录和合并拆分,这些都是数据集成的工作。在这基础之上,工作流引擎也许只需要增加可配置的状态机,可配置的处理逻辑;而且这些也会进一步增强Broker的功能,比如可以做Routing,以及分布式事务等等。这真是一件激动人心的事情。

然而让人沮丧的是,所有的这一切,几乎都可以在Biztalk Server里面找到,我们最后还是得跟着微软跑。前不久微软还把其中的工作流引擎以及可视化的流程编辑器集成到.Net Framework 3.0,他们在微软技术大会上的演示,甚至能给人一种只需要在visio上画一张图就可以实现所有程序逻辑的幻觉。其他的软件巨头应该也有跟Biztalk类似的EAI工具,我没有太多了解,只是觉得在简单易用方面,微软应该一直还是做得不错的。所以我还是期待某一天微软把Biztalk Mapper给拆分出来,这样也可以象在visio上画图一样编写那些琐碎的XSLT文件了。

前不久听说在某个医疗器械管理部门最新颁布的某个文件里,似乎把Broker这种东西也作为一种需要严格验证其可靠性的医用设备。从它在系统集成中扮演的重要角色来看,这样的规定好像也不无道理。如今整个人类文明都已经越来越依赖于软件,软件的疏漏当然也有可能导致医疗的失误,比如Broker一不小心把放疗的剂量突然增加了十倍之类。这好像有点危言耸听。不过如果有医院想在集成的时候使用Biztalk Server,微软是否也应该拿这个庞然大物到医疗器械管理部门去验一验呢。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值