不知是錯覺還是現實，醫療信息化似乎是對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的活動在成都拉開序幕了，雖然任重道遠，但還是給我們帶來了希望。