医疗信息化领域的软件设计模式

如果说上一篇关于医疗信息可靠性的讨论还是残留了一些商业方面的味道（虽然名义上是要回归技术，但还是涉及到了一些业务方面的问题）；那么，这篇打算把技术方面的牛角尖继续钻下去，讨论一下设计模式，而且：

- 要只是讨论集成领域设计模式好像还不过瘾，那就先从整个医疗行业软件的角度开个头，不过不包括嵌入式系统；
- 都是些常见的技术方案，未必是最优化的，也不会涉及任何商业机密，因为一些公开的出版物和网络社区里面都有相关描述。
- 对于这些技术方案，不会进行明确的分类，也不可能很全面，大都只是自己记忆中印象深刻的，这里毕竟只是随笔，不是论文。

需要注意的是，现在我们要考察的是这些信息系统的另外一面，这一面展现给我们的只是一些技术的抽象，并不会存在完整的业务图景。

--

在进入正题之前，还是忍不住想抱怨一下业界的浮躁，同时也是对自己的警戒。

最近去听了某位号称为软件架构大师的讲座，讲座之前看到讲义的时候我已经心存质疑，在现场听了5分钟，验证了这种质疑，讲座之后听到同事的议论，更加坚定了我的判断。不过我只做了5分钟的听众，不好妄加评论，只是感觉演讲中用到的比喻多到几乎掩盖了工程实践了。本来软件就是一个比喻泛滥的领域，从盖房子到拍电影，从飞机设计到汽车工厂，什么都拿来跟软件撤上关系。难道软件的地位真的就如此低下到要用这么多东西来撑门面吗？这回甚至把中国文化也扯进来了。

其实我听过的专门针对软件架构的讲座并不多，也没法做个全面的比较，只是感觉温昱老师还是把设计的理论和工程的实践结合得比较好的，也不乏启发性。如果要听中国文化，我还是非常推荐余秋雨的。如果某天余秋雨先生讲软件架构，我倒一定要去听听。

关于业界的浮躁，还有一个方面的表现，主要发生在销售人员和技术人员之间。这应该是程序员圈子里老生常谈的话题，这里还是忍不住想炒一下旧饭。总之销售人员总是觉得技术人员过于理想主义，技术人员又觉得销售人员太过现实，通常销售人员又比较能说会道，也比较aggressive，技术人员大部分都没这么能说，人也比较nice，这场争论的结果可想而知。

这种现象在中国也许会表现的更加明显一些，毕竟中国还是IT产业的低端。国外的情况不太清楚，但至少还有些高端的技术论坛，让技术人员自己也有个可以说话的地方。不过有个事实是大家公认的，西方文化更加尊重技术创新，东方文化更加注重人际交往。美国的不少大公司（Kodak，GE，MS等）的创始人首先都是技术人员，有些甚至是技术很牛的技术人员（很多内部资料可能会显示BillGates并不是个技术天才，那也是他转型成为商务人员之后的表现而已），正是这些人还是技术人员的时候创造了这些个商业平台，然后商务人员让这些平台最终取得了成功。

然而，在我曾经工作过的一个技术型的公司，技术和市场策略都是对的，甚至在国内是相对领先的，一些理念的正确性也不断地被行业的发展所证明，但是在实施具体的销售策略和方案的时候遇到了近乎疯狂的对手：这些对手向客户免费提供软件。注意，这跟互联网行业不同，这种免费并不是一种商业模式的创新，而是把整个市场变成一个低服务质量，高政治回报的地狱。这也就是很多销售人员整天跟我们谈论的现实。这些销售人员喜欢研究甲方组织内部人与人之间的关系，而不会去研究自己正在销售的技术将如何改变世界：而这种取舍正好创造了他们的骄人业绩，以及我们赖以活命的薪水。

还有一个有趣的现象，销售人员与IT Pro（运维人员）的一个共同点是对数字的极端敏感，前者特别注意货币的金额，后者特别注意设备的参数，这两种数字之间通常有着某种天然的映射，于是这两种人往往十分投缘。他们偶尔也会讨论技术，每每提到的时候，都会不屑于顾地说，嗨，这些都是程序员的活。

不过话说回来，上面说到的每一种人在每一个成功的组织里面都缺一不可，团队的作用就是就是让各种奇形怪状的人协同工作，最终达到1+1大于N的效果。

总结一下，每个人都应该把自己擅长的事情做到最好；每个人都应该尊重其他人的劳动，尤其是创新性的劳动。

--

我们还是先从前端应用开始，比如说各种工作站。

前不久我们要做一个支持可用性的技术方案，我查了一下SEI的书（虽然有点学院派的嫌疑），用以支持可用性的架构设计决策竟在一定程度上跟可修改性（即应用程序的灵活性）密切相关，其中的假设是在程序写好之后，用户和UI设计师还是会频繁地要求修改用户界面。回想一下，还真的蛮有道理。早期很多行业软件的用户界面，基本上是在客户化开发的阶段才能够定型的，于是一些公司也会让工程师在项目中的某个阶段常驻医院。尽管这种方式会一定程度上增加质量控制和项目管理的难度，但对于工程师来说，这是获得领域知识最好的途径。

我们熟知的MVC是用来支持可用性的最常见的设计模式之一，后来还发展到MVP和MVVM，它们的核心思想都没有改变，都是让界面和逻辑尽量地分离。我们看到的很多技术也是基于这种思想，比如MFC的文档视图模型，ASP.Net的Code Behind等。当然，也有一些界面设计方面的Best Practices，比如必要的支持信息、条理化的界面分区和Step By Step的操作等，这些通常属于详细设计时候要考虑的问题。

如果在可用性方面继续深究下去，就要走出电脑屏幕的框框，在医生的整个工作环境的角度来考虑了。比如很多影像诊断工作站提供了1+N的显示器组合；很多临床工作站则是在医生的办公桌里挖个洞，把显示器嵌在里面，医生则是趴在他早已习惯的一个玻璃板上工作。这就造成了一个有趣的结果，有些医生总是仰着头，有些则总是低着头。以前有个放射科医生还跟我抱怨，竖屏显示器太高了，看久了会得颈椎病，然而我们却没有办法卖给他一张更高的椅