集成的故事 - 有限数据流量法则

 

在云计算的时代，什么都流行搞集中化，多家医院集中预约、集中挂号、集中存储临床文档（索引）、集中管理转诊业务。当医疗集成遭遇到区域应用，海量数据交换就成为一个首当其冲的问题。跟传统的部门级或院级集成场景相比，业务单位的扩展使得数据量成倍的增加；如果把可靠性考虑进来，这些数据可能还要double一下，以便通过数据冗余实现异地镜像和灾备。做惯了传统的集成方案，这样规模的集成方案也许会让我们不知所措。

但仔细分析下来，其实再复杂的问题都可以分解成若干个简单的小问题。只要把问题切分到其规模可以用传统的方案来解决的程度，然后把很多个传统方案组合起来，就可以用较低的成本把复杂的问题解决掉，而不是重新设计一个昂贵的方案来重新解决这个问题。其实，这才是云计算的本质。

于是，问题本身是否能够简化，就成为是否可以采用这个策略的一个重要前提。在医疗集成领域，也许存在一条行业中固有的法则。这条法则确保了大规模信息集成和工作流集成问题的可简化性，也为大规模数据交换最终能够化简为小规模数据交换提供了必要的理论支持。我们暂且把这个法则称为“有限数据流量法则”：

完成事务性的业务活动所需的数据量总是有限的，或者说是可化简的，只有分析性的业务活动才可能需要大规模的数据。

这个法则的背景是：在一定的时间和空间范围内，人脑的数据处理能力是有限的。特别是对于执行事务性业务活动的角色（医生、护士），他们需要在短时间内完成一个医疗活动，你给他提供的信息，够用就行，多了他也用不完，否则既占用计算资源又浪费他的时间。对于分析性业务活动，比如卫生部门的研究员，他们也许需要大量的数据，但往往不要求在短时间内提供结果。对于需要在短时间内提供结果的分析性业务，Mapreduce处理模型已经帮我们进行了简化。最终，分析活动的结果也还是要提供给事务性活动使用的，因此，从系统间数据交换的角度，这些数据分析的结果，跟原始数据相比，数据量已经大大地减少了。

这个法则的有个典型的案例，也是一般信息系统设计的个常用原则：一次查询返回的结果越多，对用户带来的价值就越小。当查询结果条数大于某个数目，对用户的价值趋近于零。如果用户只关心条数，不关心内容，那就只返回条数而不是内容，这样一来他所需的数据量就更小了。

--

有限数据流量法则在集成引擎中的推论/应用：再大的数据流量，总有办法针对不同最终用户，进行过滤和分流。

就拿集中预约/挂号/注册来说，虽然负责集中Scheduling的系统中数据量很大，但对于某一时刻，执行某次医疗活动所需的Scheduling信息总是十分有限的。简单地说，你没有必要把其他医疗活动的Scheduling信息一下全部传输到终端。很多时候，你总能根据最终医疗活动执行者的不同需求，用时间、空间、类型等多种条件进行过滤和分流，比如只把他当前（这个时间点附近）的一些Scheduling信息提供给他。这个分流可以分级或分时进行，从而使得问题得以简化。

最近看到有些医院把这个原则应用到极致，比如在包含技师工作站的放射流程中，技师工作站不仅可以做信息QA或图像QA，还可以把工作量统计跟DICOM Worklist的生成结合起来。至少从集成的视角来看，只是在成像设备真正需要这个Worklist的时候，才把这个信息提供给这个终端，即便这只是个部门级的方案，也能把不必要的跨系统数据交换将到最低。

当然，IHE的理论家可能会反对，他们总觉得只有MPPS或图像到达才能真实表达技师的工作量，或者这个技师工作站流程里面还有这样那样的漏洞或隐患。但这里只是想通过这个案例说明，在一定时间和空间内，终端所需的数据量总是有限的。不管是部门级系统还是区域级系统，都可以利用这个法则，在确保系统可用性前提下，有效降低解决方案的成本。

--

有限数据流量法则在临床门户中的推论/应用：医生不需要太多的原始数据，门户的价值一是方便，二是智能，两者缺一不可。

在各种宣传医疗集成、电子病历和健康档案的PPT中，大家都在拼命宣讲门户的价值，好像不把这么多数据砸到医生桌面上，医生就没法工作一样。不过确实也是，你不这样讲，也没有人会理你。特别是当医院的经济效益跟医疗质量没有挂上钩（或者挂反了钩）的时候，医生根本也不需要这么多信息：我不就是没拿到你上次检查的X光片嘛，再拍一张好了。

好了，现在我们只能相信一切都会慢慢变好，该挂上的钩迟早都会挂上，临床门户也有了。医生打开病人的健康档案，这个人从出生到现在所有的医疗文档哗的一下全部列了出来，这样真正有用吗？于是，你会发现门户的价值一是方便，即集中展现，不需要你到各个系统里面去找；二是智能，即预先对信息做一些加工的处理，而不是把原始数据一股脑搬出来。两者缺一不可。而加工过的数据，不管是一份评估报告，还是一个智能提示，其数据量毕竟是有限的，数据交换方案的规模也是可控的。

--

因此，对于前面提到的查询案例，对查询结果的控制，既能确保用户价值的实现，又能有效降低技术成本。当然，为了进一步提升用户价值，可以在简化用户输入和提高命中率方面下功夫。依靠搜索引擎技术，可以在这些方面做到极致，而智能化也其中的关键。

推广一下，其实“有限数据流量”不仅可以降低技术成本，还能实现更好的用户体验。曾经有一套影像诊断解决方案，为了突出其针对某种图像的强大的处理功能，把原始图像传输到工作站上，便于让医生用这种处理功能来读片。确实，这种方案受到一些发烧友级医生的拥护，但更多的医生接受的是另一种更加简单的方案。图像在到达桌面之前就已经用这种很酷的功能，哪怕是一些没这么酷，但足够用的功能处理好，出来的就是一个基本上不需要过多调整就可以读片的图像。有人争辩说，这样可能会提高误诊和漏诊率。但市场似乎并不关心这些，就像苹果mp3的用户就是不需要在屏幕上同步显示歌词那样，因为他们只想让自己一边被美好的音乐环绕，一边做别的事情，而不是让自己被一个小小的屏幕锁住。好吧，扯远了。

--

回到集成的话题。去年我在中国BME的年会上提交了一篇论文，叫做《医疗信息系统集成模式初探》，里面总结了下面这些医疗集成方案中常用的几条设计原则。其实这些东西都是前年整理的，现在确实有点老了。如果有机会更新的话，现在可以增加一条“有限数据流量法则：集成方案的一种优化设计策略”。

1. 复制和迁移：针对医疗系统基础数据依赖性相关的问题
2. 索引和信息桩：针对医疗系统之间对象引用和管理问题
3. ID私有：针对医疗业务实体标识的局部性和全局性问题
4. 确认和重试：针对集成医疗系统中的数据容错问题
5. 请求和通知：关于弱耦合系统间通信方式选择的建议
6. 插件和宿主：强耦合系统间实现灵活装配的一种方案