曾经有人说过，医疗信息系统是世界上最复杂的信息系统之一，甚至将它的复杂性与登月计划相比。此话的真伪难以考究，而且很少有人做过定量的估算或者跨行业的比较，因此我一直姑且以为这只是医疗信息系统的制造商们向医院兜售自己的产品时，为了抬高价格而编造的一个说辞。
不过，它确实很复杂。跟企业信息化一样，医疗信息化同样需要理解和协调不同部门/科室之间的关系。可能是企业信息化已经发展了很多年，不少公司已经可以包揽财务，生产，进销存，客户关系等等整个完整的ERP系统，但在医疗行业，至今为止几乎没有一个公司能把PACS, RIS, LIS, EHR, HIS等全部做完。而且，就算有一个厂商能招揽到熟悉医院里每个科室的业务专家，它也还要在商务上花大力气来打破白色巨塔里面早已形成的一道又一道的屏障，因为信息系统本身就要求穿透这些屏障，从而实现更高效率的共享和协作。可想而知其间的难度之大。
于是厂商们首先只能采取分治的策略，有人做PACS/RIS，有人做LIS，有人做HIS/EMR，每个厂商都成为某个部门系统的专家，并把是否要上马做另外一个部门系统看作象进军一个新行业一样困难。然而最后在医院，每个系统如果只是独立运行，它所能提供的生产力都会大打折扣，唯一的方式就是建立一套跨厂商集成，甚至可能相互协作的机制。
对于一些简单的HIS，让临床医生写写医嘱，看看病历，这些文字工作似乎不需要太多来自其他系统的数据也能正常工作。有些系统，比如PACS/RIS，如果无法从设备上获得图象，便形同虚设，于是也成为最早引入行业标准的领域。从90年代末到00年代初，PACS/RIS的迅速发展也促使DICOM迅速地更新换代。这个标准最早只是为了解决影像设备之间数据传输的问题，从3.0版本之后，工作流相关的部分得到了增强，任务清单的出现让PACS/RIS与设备之间的集成从数据共享提升为协同工作。
相比其他行业的信息化，也可以找到类似DICOM这样的例子，来解决不同厂商之间的通信问题。以前通过一位同学了解到智能楼宇的通信协议，也有类似信息对象，服务类这样的术语。但这样的协议似乎还远远不能覆盖医疗集成中的所有问题，于是人们建立了IHE这样的集成框架，相当于业务层的设计模式。我没有了解过其他行业是否存在这样的先例，至少对于医疗行业的工程师们，除了用那些可怕的DICOM二进制流，或者生硬的HL7文本，还可以用这种模式语言来相互交流。这大概也能从一个侧面反映出医疗信息系统的复杂性吧。
医疗行业的工程师们的确值得为拥有IHE而感到幸运。IHE也许无法抽象出现实世界中所有的复杂性，但至少提供了一种我们目前暂可使用的一种有效工具。近几年间IHE的发展，已经进入除了医学影像以外更加广阔的医学领域，为我们在UML图纸上不断展现出更多关于集成的故事。
尽管如此，在医院下班后冷清黑暗的过道和狭小的工作室里，我们仍然常常看到工程师们挑灯奋战的身影，这些可怜的人们似乎被永远地抛弃在IHE专家们所吹嘘的神奇光环之外。
的确，集成这个领域还有太多的问题没有解决。有些问题不到最后一刻，可能永远也想不到。在现场工作的人们，顶着老板和客户的压力，有时只能抛弃之前所有标准和模式的框框，凭借自己的经验、分析、猜测，甚至还要有一点点的运气，方能左右逢源，见招拆招。然后他们的经验也会慢慢累积，成为标准和模式的一部分，供大家分享，人类也就这样慢慢的有了一点进步。
（将来有空的时候把标题中的“集成的故事”改成“医疗集成的故事”）
集成的故事 - DICOM互联
1574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
