集成的故事 - 医疗集成的未来

本文试图展望一下未来一段时间内医疗信息系统集成领域一些可能的发展。事实上这对我是个太大的题目，所以也只能在博客上胡编乱造一番。限于一些粗浅经验、现在所处的位置以及视野所及的范围，确实不敢对不可知的未来做出什么有根据的猜测。虽然涉世不深，但我还是愿意思考，愿意尝试。

最早我进入集成这个题目的时候，也没有想到要写这篇，只是后来写完“集成的本质”之后，开始在想，在biztalk server之类的巨人之外，我们到底还能做些什么。事实上，也没有什么太多的东西可做。对于技术人员来说，面向终端的应用开发本来就是软件技术链条中的最后一环，更何况又被这些中间件或者集成平台架得高高在上。也许这些平台带来的效率同样能创造不错的商业价值，但在这个用代码搭建起来的市场上，没有人喜欢巨人肩膀上摇摇欲坠的感觉。于是一堆一堆的程序员开始重复实现着同样的功能，同质化的产品布满眼球，随后商务人员开始兴风作浪，不堪入目的营销露出水面，于是蓝海再次沦落，技术人员的地位变得岌岌可危。这真是个Sad Ending，就像某个时期的PACS/RIS一样。

或者再编一个Happy Ending：尽管现在biztalk server之类的EAI平台已经不少，如Intersystem之类也有特别针对医疗的EAI和EII产品，但创新技术不断出现，新产品的诞生也迫使老产品不断地改进。尤其在医疗行业，在外部推动力方面，面向社区和地区的大规模医疗系统对集成提出了更高的要求；在内部的准备方面，行业标准和集成框架已经为更高效率的智能化集成提供了充分的语法和语义支持。于是，EAI技术在继企业、金融信息化之后，在医疗信息化领域获得了新的腾飞。这真是个激动人心的时代，历史再次证明创新才是软件行业的第一推动力。

关于其中的细节，我大致整理了一篇文章应邀投到《中国数字医学》杂志，这里就不再详述了。再次非常感谢各位领导和同行对晚辈工作的肯定。有点遗憾的是，文中虽以应用集成入题，但论述似乎略偏重EII一些，毕竟相对于复杂的业务流程定义和工作流参考模型，数据映射之类的工作还是简单很多。文中选择了DICOM任务清单作为集成的案例，一是比较熟悉，二也可以兼顾一下工作流的概念。关于基于IHE和BPEL的工作流集成，参考文献[3]中已经给出了非常专业而且详细的描述。

虽然我们不希望最后看到的是Sad Ending，但如今工作流技术的庸俗化似乎已不可避免，这也是任何一种技术走向成熟的标志。事实上，EAI这个术语从90年代末就开始变得十分红火，SOA更是让EAI变得如虎添翼，当时的一些分析机构认为EAI将成为IT行业中增长最快的部分。如今工作流引擎之类的核心组件，已经从那些重量级的EAI服务器中剥离出来，工作流技术的成本也越来越低。

工作流引擎轻量化的趋势很有意思，也许有一天流程定义语言（比如轻量化的BPEL）也会变得象javascript或者sql一样，成为每个程序员都需要学习的语言。到那时可能一些常见的系统（比如RIS, LIS等）都会用一个小型的工作流引擎来指挥和监控业务的状态，从而实现一定范围内的流程可定义，这样客户化的工作也会简化很多。

而且也会有更多的人开始研究工作流持久化的技术，数据库里保存的不再只是生硬的数据，还可以是形式化的业务流程和判断逻辑。于是人们在已有的流程监控系统上建立一套反馈机制，根据对效率瓶颈的分析动态地调整流程定义，从而实现业务流程改进的自动化，这样我们距离MDA和自动化的程序生成又接近一步，IT系统的开发也会从以数据/信息为核心的时代进入以逻辑/流程为核心的时代。

---

关于我投稿文章中的概念模型，还有一个问题可能可以继续讨论。注意看文中那个IHE式workflow的人可能会发现，其实它在形式上有意无意地被定义成了一个可嵌套的模型，因为其中的<GenericTransaction>可以指代任何一种Transaction，就像编程的时候使用的模版类一样。那么，如果自己把自己嵌套进去会发生什么呢？

这种纯粹概念上的玩弄已经变得有点钻牛角尖了，也许哲学家和暂时想冒充一下哲学家的工程师才适合这种纸上谈兵的游戏吧，而工程师的真正责任，还是老老实实地把这些关于集成的真实故事不断地延续下去。