不知是错觉还是现实，医疗信息化似乎是对IT新技术接受最慢的几个领域之一。记得还在学校的时候，就有机会用beta版的.Net SDK来编写最初的Web Service，走出校门才发现自己只能基于迷宫似的C++类库来编写所有的代码，不管是繁琐的底层交互，还是简单的用户界面，指针把程序逻辑编织成一堆混杂的面团。期间经历的各种经验教训，尽管对自己是很大提高，而且也为推动和参与后来的组件化进程提供了机会，以实现象VB那样优雅的编程模型，象ASP+COM+DB那样久违的三层结构；然而在很长一段时间里，企业却承受着低下的生产力，并且为员工的成长买单。对技术狂热者来说，为了让小公司更好的活下来，与其花更高的成本，打破原有的隐性规则，建立更加完善的管理流程，还不如采用可控制的新技术来优化低效笨重的技术架构，也许能更直接地达到提高产品质量的目的。就算还是会有BUG，至少程序crash的时候，会弹出明确的异常信息和详细的调用堆栈，而不是象劣质C++代码里面最可怕最难以琢磨又最常见的内存非法访问。类似的情况在那些不一定需要用到指针的业务系统中可能会好很多，但我还是听说过以前有个HIS厂商用DCOM来搭建它的中间层，最后出了问题连微软专家都解决不了。不了解的事也无法去评论是非，也许当时的DCOM还没有臭名昭著到能改变这个公司的技术决定的程度吧。
话说回来，大概是很多医疗软件厂商都是从设备开始做起，嵌入式系统和图象处理领域的技术更新远没有互联网和企业级应用来得快；而且就算在专门的信息系统部门或者独立的纯软件公司看来，医疗信息化行业的市场发展也远没有IT技术的更新那么快，在新技术采纳方面略微的迟缓，不仅不会妨碍生产力的提高，而且还可能对技术风险的控制有好处。正如千禧年左右发迹的SOA，在其他行业领域积累了足够的经验和教训，并招来种种的褒扬和质疑以后，终于开始在医疗行业大展手脚了，Web Service和SOAP在技术人员中早已如雷贯耳，商务人员也在用面向服务准备着新一轮的攻势，一些医院也宣称自己成为首批成功吃到螃蟹的人（台大医院系统架构全面转向SOA http://www.ithome.com.tw/itadm/article.php?c=41609&s=3）。
---
我想那些经历过90年代末第一次互联网浪潮的人，对Web Service和SOAP的概念一定不会陌生，抛开商业上的泡沫不说，这个小小的技术革新，似乎是非常自然而然的事情，HTTP以它的简洁赢得了天下，XML以它强大的描述能力取代了IDL。如果你当时是个设备控制软件或小型信息系统的开发者，能用IDL取代被指针穿插得千疮百孔的类库头文件就已经很不错了，其他的一切跟你并没有多大关系，毕竟这次技术革新主要是发生在粗粒度的系统间互操作领域的，与其说是革新，还不如说是让互操作问题有了它专用的一组技术，而真正成为一个技术领域。当然，这只是站在EAI立场上的一种视角。这次技术革新在CIO眼里，可能意味着更能与业务对齐的IT规划和更敏捷的管治模式；在架构师眼里，可能是所谓边界清晰、服务自治、共享契约、基于策略的大尺度架构风格；在程序员眼里，可能就是一片XML的海洋，上面漂浮着SOAP，WSDL，WS-*，BPEL等等形形色色的怪物。
的确，我们需要在更宏观的层面上运用面向服务来规划业务和IT模块，但这并不意味着我们有多厉害，其中的困难未必比嵌入式系统里让一个指针安全快速地遍历一个内存区域大多少。对于面向服务的技术人员，所有困难的问题最终归结起来，可能也只是很少的几个。有人也许会说如何让SOAP具备企业级服务质量（如安全性、事务、元数据管理等）很难，一些经典书籍也在这方面花费了大量的篇幅，一堆商业利益驱使下的专家也为WS-*的标准争论不休。于是一些聪明人抛弃了所有这些舍本逐末的办法，用REST和XML over HTTP实现了一种优雅简洁的回归；另外一些不辞辛劳的人，干脆用回复杂的组件技术（比如CORBA）来实施他们自己的面向服务（见Eric Newcomer等的Understanding SOA with Web Services）。但我始终觉得，真正困难的，其实是大多数图书和资料上都试图回避的那些问题。比如说如何划分服务。
---
很多资料都认为，掌握好服务划分的粒度应该是实现面向服务所承诺的那些好处（比如灵活性、重用性）的关键，甚至影响到SOA实施的成败。在医疗领域，还要考虑如何将现有的HL7、DICOM和IHE放到面向服务架构中合适的地方，这无疑又增加了设计的难度。有人在2006年的一个PPT（Grahame Grieve，HL7, Web Services and SOA - Past, Present and Future）上指出了一种可能的途径：
- Implement services based on HL7 messages
- SOA defines services in terms of messages
- SOA provides a wider context for a service
同时也在服务划分上留下了疑虑：
- Healthcare business services are poorly characterised
- Is HL7 going to start dictating business services?
比这些理论更有价值的，可能还是关于台大医院SOA实施的一个报道（2007年初），尽管它看起来只是一则新闻（台大医院系统架构全面转向SOA http://www.ithome.com.tw/itadm/article.php?c=41609&s=3）：
- 台大医院的系统架构转换，将会涉及的应用范围，同时包括了门诊系统、住院系统与急诊系统等3大核心领域，赖飞罴说，过去的系统虽然稳定，但是延展性差，任何一个需求产生都是痛苦，举凡健保局需要医院提供的一些医令资料，往往都需要半天一天的时间，才能完成资料转换，系统架构转换成SOA之后，因为同时遵循HL7以及Web Services两个开放标准，因此，就可以直接与外部系统介接，进而达到快速回应需求的目的。
- 目前台大医院的系统架构，由上至下可以区分成Web Application（应用层）、HL7 over SOAP（网路协定层）、Web Services（共用业务模组层）以及资料库等4层。
- 台大医院资讯室系统组组长杨子翔进一步表示，HL7虽然是内容讯息传输标准，但是由于标准制定范围涵盖了每一个医疗流程，因此台大医院决定依循HL7，并且依序在共用业务模组层，切割出查询、病人基本资料管理以及财务管理等10个共用模组。
- 目前台大医院的共用模组，主要是透过Web Services沟通，杨子翔表示，当初虽然也有考虑过使用MQ，不过后来因为考量到与其他医疗单位等外部系统介接的需求，因此还是决定采用Web Services作为跨平台标准。台大医院历时1年半开发的系统，总算从去年开始陆续上线，预计今年4月要完成所有系统的转换。
- 目前针对Web Services的系统效能监控，主要是用CA的管理工具，对于转向SOA之后，延伸出来的模组重复使用性监控，则是经由应用系统呼叫共用业务模组的程式码过程间接掌握，长期来说，台大医院仍旧需要透过工具进行共用模组的管理，不过碍于现阶段正在进行系统转换，因此，相关的管理工具评估，自然就成了第二顺位。
这的确是个鼓舞人心的消息，至少说明在服务划分方面，基于HL7的设计策略成为一种可行的方案。把服务识别出来以后，在服务契约、数据模型、交互模式和传输协议方面的选择，都变得顺理成章。服务准备好以后，下一步就该IHE出场了，有人也基于IHE的流程模型做了一些BPEL的工作（Rainer Anzbock等，Semi-automatic generation of Web services and BPEL processes - A Model-Driven approach）。这样一来，医疗行业通往SOA的主干道就铺设好了，就等着大家伙上路了。
不过总感觉IHE过去太长时间都关注于放射、实验等部门领域，涉及供全院使用的IT基础设施领域时间也不长，肯定还有很多覆盖不到的地方，包括一些中国特色的地方（比如收费方面），或者一些医院独特的业务流程优化（比如前不久在CCTV2对话节目上听到某院长介绍的提高床位流转效率的一些办法）。而且在做服务编制/编排的时候，更关注的是跨部门甚至跨医院的流程，传统IHE里面一些部门级的流程估计都已经被封装到服务内部去了。行业框架和标准的发展永远都是比实际应用慢一步的，因此也不用抱怨，至少它们提供了一套术语和机制，便于我们交流和总结。前不久，IHE-C的活动在成都拉开序幕了，虽然任重道远，但还是给我们带来了希望。