整合的故事 – 整合的本質

 
一次出差的時候，我給熱衷藝術設計的愛人買了一本書，名字叫做“設計中的設計”。書名中的遞迴形式，本來就很容易讓熟悉程式設計的人怦然心動，前言中的一句話，更是耐人尋味。

“能下定義或以文字記述下來並不能稱為瞭解,反而是將已知的事物未知化後,嘗試挑戰其真實性,才能對其更深入瞭解。” ——原研哉

幾篇故事下來，對於醫學資訊系統整合領域，無異於冰山一角。倘若哪天真能記錄下整座冰山，在這位設計大師的眼裡，也不能稱為瞭解。或許我可以按照他推薦的方法，嘗試把整合這件事未知化，才能探求到其中的本質。

---

在“整合的故事 - 動態資料遷移”一文裡，我提到動態資料遷移的方法其實來自跟同事討論所得到的啟發。記得當時我們一起研究那個HIS的編碼系統的時候，發現它跟RIS中編碼差別實在很大。實際上RIS是用一個欄位來表示檢查方法，裡面同時包含了檢查部位和體位，而HIS裡面檢查部位和體位資訊是分開成兩個欄位的，也就是說RIS的一個編碼需要跟HIS的兩個編碼相對應。基於這個事實，至少LUT的解決方案理論上還是可行的，雖然跟動態方案相比工作量會大得出奇，而且能用靜態映射解決的問題動態方案也一定能解決。於是，我開始思考，到底兩個異構系統差異到什麼程度，整合才變得不可能，或者換句話，具備什麼必要條件，整合才變得有可能。

不需要太多的推理或者求證，我大概能猜到整合的前提應該是一種語義上的相似性。這個前提，不管在多大的兩個互操作的系統之間，或者小到一個主程式和一個子程式之間，應該都存在。比如要調用一個函數，調用方必須知道要把什麼東西傳給被呼叫者，被呼叫者也要知道它將獲得什麼東西。這就有點象SOA裡面的contract。當然SOA的contract應該會規定得更加的具體，裡面應該同時包含了文法和語義，這樣才能達到所謂的“邊界清晰”的要求。而我們平時的整合工作，其實就是做文法的轉換，這種轉換應該具有語義的不變性。比如，我們把DICOM的(0010,0010)欄位取出來，放到HL7訊息的PatientName欄位中，資料表示的方式改變了，但圖象系統知道在DICOM的這個欄位裡儲存的是病人姓名，臨床系統也會假設它從HL7的這個欄位裡應該能取到病人姓名。作為語義的病人姓名，在這整個過程中是不會改變的，哪怕其文法形式從簡體變成了繁體，從漢字變成了拼音，甚至姓和名的位置顛倒一下，但整合雙方還是會把它作為病人姓名，而不會作為性別，年齡或者是其他。當然也有特殊情況，比如有些系統裡面不能儲存年齡，我們會把年齡資訊拼接到姓名後面在一個欄位裡一起傳給它，但這正是這個系統的使用者對它的期待，他們所想在介面上看到的，正是在來源系統裡面可能是分別儲存在兩個欄位裡面的病人姓名和年齡。再特殊一點，比如要判斷來源的某個字串裡包含一個特殊的字元才去觸發目標系統的一個事件，其本質也是一樣，是否觸發事件如果可以定義為一個布爾值，那麼人們對這個布爾值的解釋，也就是語義，應該跟人們對“來源的這個字串裡是否包含這個特殊字元”這個解釋，應該是一樣的。

我們進行這種文法轉換的最初動機，應該是彌補兩個系統之間的資訊差異，把來源系統的某個資訊傳輸給目標系統，而文法轉換隻是確保傳輸能正常進行的一種手段。這就是通常意義上的Data Integration。從這個意義上說，其他的工作流程整合和案頭整合應該都是建立在Data Integration的基礎上的，它們通常是在原來無序的資料流之上建立了一些時序，或者追加了一些特殊的語義，其目的已經不是簡單地在多個系統之間共用資料，而是讓多個系統協同工作，不管是在一個分布式環境裡，還是在同一台工作站上。

---

於是我們驚奇地發現，在Broker和工作流程引擎之間，似乎並沒有太大的距離。傳統意義上的Broker，會做資料格式的轉換，欄位的映射，記錄和合并拆分，這些都是Data Integration的工作。在這基礎之上，工作流程引擎也許只需要增加可配置的狀態機器，可配置的處理邏輯；而且這些也會進一步增強Broker的功能，比如可以做Routing，以及分散式交易等等。這真是一件激動人心的事情。

然而讓人沮喪的是，所有的這一切，幾乎都可以在Biztalk Server裡面找到，我們最後還是得跟著微軟跑。前不久微軟還把其中的工作流程引擎以及可視化的流程編輯器整合到.Net Framework 3.0，他們在微軟技術大會上的示範，甚至能給人一種只需要在visio上畫一張圖就可以實現所有程式邏輯的幻覺。其他的軟體巨頭應該也有跟Biztalk類似的EAI工具，我沒有太多瞭解，只是覺得在簡單易用方面，微軟應該一直還是做得不錯的。所以我還是期待某一天微軟把Biztalk Mapper給拆分出來，這樣也可以象在visio上畫圖一樣編寫那些瑣碎的XSLT檔案了。

前不久聽說在某個醫學器械管理部門最新頒布的某個檔案裡，似乎把Broker這種東西也作為一種需要嚴格驗證其可靠性的醫用裝置。從它在系統整合中扮演的重要角色來看，這樣的規定好像也不無道理。如今整個人類文明都已經越來越依賴於軟體，軟體的疏漏當然也有可能導致醫學的失誤，比如Broker一不小心把放療的劑量突然增加了十倍之類。這好像有點危言聳聽。不過如果有醫院想在整合的時候使用Biztalk Server，微軟是否也應該拿這個龐然大物到醫學器械管理部門去驗一驗呢。