集成的故事 - 动态数据迁移

Procedure Code是个有趣的东西，医院使用它的方式好像能在一定程度上反映出这个医院信息系统集成的水平。

在独立运行的设备上，技师在拍摄前选择一下拍摄部位和体位，可能只是为了在输出图象的DICOM头里面包含这些信息，以便在胶片上打印出来。尽管很多设备还是会把输入的部位和体位信息编码成Procedure Code来存储，但实际上这种转换没有起到什么作用。如果只是为了打印，可能只需要Procedure Description或者Body Part这些文字信息就足够了。除非你有一个胶片库，要求用Procedure Code来检索哪张胶片在哪个柜子的哪个抽屉里。

当设备接入PACS，图象的DICOM头信息被汇总到数据库，于是人们可以按照拍摄方法来进行查询和统计，这时似乎才开始有了建立一套编码系统的必要。有了RIS，这套编码更成为了登记台上必须输入的信息，这样技师就可以在Worklist里直接获得拍摄方法，而不需要重新输入了。这种一次输入，多次使用的工作流，正是信息系统集成所要达到的目标之一。

这样一来，原来设备上选择拍摄部位和体位的功能，就需要在RIS登记台上重新实现一次。当然我们希望是只实现这一次，然后在一个界面上完成CT，MR，DR等各种设备的集中登记，这样Procedure Code的编码表也要由原来在的每台设备上独立维护变成RIS上的集中维护。其实组成整个流程的步骤并没有减少，只是换了一种方式，希望能提高工作效率和减少多次输入带来的操作失误。

这些往往都是RIS软件设计说明书中的理想描述，当开发人员把这样一套东西做出来，他们才发现从产品发布到上线运行之间依旧存在上不小的差距。首先每台设备都来自不同的厂家，各自采用不同的Procedure Code编码方式，我们如何在RIS登记台上实现集中登记。其次，如果跟HIS集成，信息输入点就从放射科的登记台前移到了临床医生的桌面，我们如何把医嘱或者电子申请单中的检查代码转换成RIS所认识的Procedure Code，然后再用Worklist分发到设备上。这就是我们要解决的集成问题。

在继续讨论Procedure Code之前，不妨反思一下，这种集中登记真的会减少操作失误么。在实际应用中，RIS登记台输入错误数据的例子比比皆是，而且这样的错误可能影响的范围更大。如果出现了错误，一般来说都是从信息源头开始修改，这里面可能需要复杂的消息机制。信息错误的预防，发现和修改是一个大话题，暂且放下。也就是说，下面的讨论应该是基于信息输入点能确保输入正确信息的假设来进行的。

---

在维基百科上，可以查到Procedure Code的定义，以及目前世界上流行的好几种Procedure Code的编码系统。我们用排列组合可以计算出要实现所有这些编码之间的相互转换，需要多少张Lookup Table(LUT)。不过，我们在国内所见到过的设备和信息系统中的Procedure Code都是千奇百怪，几乎没有多少人使用维基百科网页上列出的任何一个编码系统。

也许在全球范围内统一Procedure Code是如此的困难，DICOM和HL7也不得不对编码系统的多样性做出了妥协，它们都只是提供了存储Procedure Code的字段，没有对使用哪种编码系统做出规定。就算有些地方曾经给出了具体的编码，比如DICOM里面的Study Status ID，最后也只能放弃掉，比如在国内的实际应用中就有多余的状态或者要增加一些状态。大概行业标准只能这样大而化之，并且远远滞后于实际应用吧。

因此，集成的时候Procedure Code Mapping只能一个一个地做，这本身就非常的琐碎。因为我们需要医学专业人士来阅读和理解两个系统里面的每个编码的含义，然后把他们对应起来，也有些可能是根本无法对应的。而且大多工程师很难完成这样的工作，作为项目实施方要动用医院的资源，更是不容易。

面对这个困难，各有各的解决办法。比如做RIS和设备的集成，病人把申请单交到登记台，登记台输入了检查方法，设备就可以从Worklist中获得Procedure Code，同时病人也会把申请单带到设备上。如果设备事先在本地的Mapping List里面输入了这个Procedure Code，自然可以在Worklist界面上显示出检查部位和体位；如果有个Procedure Code没有输入过，检查部位和体位显示不出来，技师就手动地把申请单上的部位和体位信息跟这个Procedure Code对应起来输入本地的Mapping List。经过一段时间的使用，Procedure Code的Mapping List也就慢慢地从RIS移植了一份到设备上。于是病人也不需要把申请单带到设备上了，只需要在登记的时候获得一个条码，把条码带到设备上扫描一下就可以从Worklist中获得病人信息和检查方法信息了。

上面这个工作流让我想起一个故事。听说一个图书馆要搬迁，就让在老馆借书的人到新馆去还书，经过一段时间以后，大部分的书都自动地迁移到新馆去了。这样图书馆不仅不会因为要搬迁而暂时关闭一段时间，还节省了一大笔费用。

我曾经做过一个集成项目，最初也想用LUT来完成HIS的医嘱代码和RIS的Procedure Code之间的映射。后来拿到双方的文档，每个系统都是数百项的编码，静态的映射短时间内几乎无法完成。而且就算花几天时间做好了这个LUT，HIS可能还会增加新的医嘱代码。因此最终还是选择了动态的方式，对于每个从HIS来的医嘱代码，都到RIS的Procedure Code列表里面查找看看有没有重复的，如果没有就添加；当然这也要求HIS同时提供医嘱代码的描述，包括检查部位和体位信息。

也许这只是一个很小的技巧，但这个项目重要而又紧急，当时我们跳出LUT的框框找到这种动态方法的时候，我们欣喜若狂。现在回想起来，当时更重要的其实是一种团队体验，如果没有人在一起讨论，独自一人也许难以找到灵感。没有RIS和HIS的相关支持，这样的工作流也无法实现。

集成的确需要太多先决条件。其实我们已经不知不觉地在前面每个方案里面加上各种各样的假设，比如RIS必须能支持外部接口调用增加Procedure Code，设备有用必须户界面让技师或者工程师输入新的Procedure Code等等。如果任何一个假设不成立，我们都有可能再回头修改我们的方案，甚至是修改项目验收的checklist。

---

我们遇到系统集成的问题的时候，总是希望从IHE中找到答案，但有时并非如你所愿。比如我们经常会在医院信息系统不断向外扩展的时候遇到问题，而IHE只是提供了一种静态的框架，它告诉我们这个系统应该是什么样，有时我们更想知道的是如何一步步地把现有的系统变成那样，通过一些扩展，或者是开放一些接口，然后组装。比如只有RIS的时候，临床医生通过纸质的申请单通知RIS，RIS在登记台上完成Procedure Code的输入；有HIS的时候，HIS成为Procedure Code的提供者和维护者，RIS需要随之更新自己的行为方式，如何做可以使得系统改动最小。也许我们只能在IHE框架之外，结合SOA、ESB等最新的EAI技术，自己整理这些面向医院信息化不断改进过程的动态框架了。

或者还有一种解决方案，把诸如Procedure Code这些基础数据统一存储到一个独立的系统中，要求所有HIS,RIS,LIS厂商都能够从里面动态获得这些基础数据，于是避免不必要的Procedure Code Mapping。就像设备上一般都应该可以增加或者删除本地的Procedure Code列表一样，这些信息系统应该既能够在独立运行时使用自己的基础数据，又可以在集成运行的时候使用外部共享的基础数据，而且这两种运行方式能够实现平滑迁移或者同时存在。不知道IHE里面有没有类似的Integration Profile，至少这个基础数据中心似乎可以定义为IHE里面的一个Actor，为整个医疗机构或者更大范围提供经过授权的对基础数据的增删查改的服务。

其实回想一下，在医疗信息系统集成里面，PatientID获得的关注似乎要比Procedure Code之类的基础数据要多得多，IHE里面好几个Integration Profile为Patient而设立，医生还是首先为病人考虑，这也是不无道理的。下一步是否应该定义跟基础数据相关的Profile呢，我想其他行业的信息化应该也有类似的先例，这种集中管理的基础数据（甚至可以包含一些元数据），不仅可以简化集成的工作，而且也能一定程度上抗拒行业标准（比如Procedure Code的编码体系）的变更对系统带来的冲击。