在雲計算的時代，什麼都流行搞集中化，多家醫院集中預約、集中**、集中儲存臨床文件（索引）、集中管理轉診業務。當醫療整合遭遇到區域應用，海量資料交換就成為乙個首當其衝的問題。跟傳統的部門級或院級整合場景相比，業務單位的擴充套件使得資料量成倍的增加；如果把可靠性考慮進來，這些資料可能還要double一下，以便通過資料冗餘實現異地映象和災備。做慣了傳統的整合方案，這樣規模的整合方案也許會讓我們不知所措。
但仔細分析下來，其實再複雜的問題都可以分解成若干個簡單的小問題。只要把問題切分到其規模可以用傳統的方案來解決的程度，然後把很多個傳統方案組合起來，就可以用較低的成本把複雜的問題解決掉，而不是重新設計乙個昂貴的方案來重新解決這個問題。其實，這才是雲計算的本質。
於是，問題本身是否能夠簡化，就成為是否可以採用這個策略的乙個重要前提。在醫療整合領域，也許存在一條行業中固有的法則。這條法則確保了大規模資訊整合和工作流整合問題的可簡化性，也為大規模資料交換最終能夠化簡為小規模資料交換提供了必要的理論支援。我們暫且把這個法則稱為「有限資料流量法則」：
完成事務性的業務活動所需的資料量總是有限的，或者說是可化簡的，只有分析性的業務活動才可能需要大規模的資料。
這個法則的背景是：在一定的時間和空間範圍內，人腦的資料處理能力是有限的。特別是對於執行事務性業務活動的角色（醫生、**），他們需要在短時間內完成乙個醫療活動，你給他提供的資訊，夠用就行，多了他也用不完，否則既占用計算資源又浪費他的時間。對於分析性業務活動，比如衛生部門的研究員，他們也許需要大量的資料，但往往不要求在短時間內提供結果。對於需要在短時間內提供結果的分析性業務，mapreduce處理模型已經幫我們進行了簡化。最終，分析活動的結果也還是要提供給事務性活動使用的，因此，從系統間資料交換的角度，這些資料分析的結果，跟原始資料相比，資料量已經大大地減少了。
這個法則的有個典型的案例，也是一般資訊系統設計的個常用原則：一次查詢返回的結果越多，對使用者帶來的價值就越小。當查詢結果條數大於某個數目，對使用者的價值趨近於零。如果使用者只關心條數，不關心內容，那就只返回條數而不是內容，這樣一來他所需的資料量就更小了。
有限資料流量法則在整合引擎中的推論/應用：再大的資料流量，總有辦法針對不同終端使用者，進行過濾和分流。
就拿集中預約/**/註冊來說，雖然負責集中scheduling的系統中資料量很大，但對於某一時刻，執行某次醫療活動所需的scheduling資訊總是十分有限的。簡單地說，你沒有必要把其他醫療活動的scheduling資訊一下全部傳輸到終端。很多時候，你總能根據最終醫療活動執行者的不同需求，用時間、空間、型別等多種條件進行過濾和分流，比如只把他當前（這個時間點附近）的一些scheduling資訊提供給他。這個分流可以分級或分時進行，從而使得問題得以簡化。
最近看到有些醫院把這個原則應用到極致，比如在包含技師工作站的放射流程中，技師工作站不僅可以做資訊qa或影象qa，還可以把工作量統計跟dicom worklist的生成結合起來。至少從整合的視角來看，只是在成像裝置真正需要這個worklist的時候，才把這個資訊提供給這個終端，即便這只是個部門級的方案，也能把不必要的跨系統資料交換將到最低。
當然，ihe的理論家可能會反對，他們總覺得只有mpps或影象到達才能真實表達技師的工作量，或者這個技師工作站流程裡面還有這樣那樣的漏洞或隱患。但這裡只是想通過這個案例說明，在一定時間和空間內，終端所需的資料量總是有限的。不管是部門級系統還是區域級系統，都可以利用這個法則，在確保系統可用性前提下，有效降低解決方案的成本。
有限資料流量法則在臨床門戶中的推論/應用：醫生不需要太多的原始資料，門戶的價值一是方便，二是智慧型，兩者缺一不可。
在各種宣傳醫療整合、電子病歷和健康檔案的ppt中，大家都在拼命宣講門戶的價值，好像不把這麼多資料砸到醫生桌面上，醫生就沒法工作一樣。不過確實也是，你不這樣講，也沒有人會理你。特別是當醫院的經濟效益跟醫療質量沒有掛上鉤（或者掛反了鉤）的時候，醫生根本也不需要這麼多資訊：我不就是沒拿到你上次檢查的x光片嘛，再拍一張好了。
好了，現在我們只能相信一切都會慢慢變好，該掛上的鉤遲早都會掛上，臨床門戶也有了。醫生開啟病人的健康檔案，這個人從出生到現在所有的醫療文件譁的一下全部列了出來，這樣真正有用嗎？於是，你會發現門戶的價值一是方便，即集中展現，不需要你到各個系統裡面去找；二是智慧型，即預先對資訊做一些加工的處理，而不是把原始資料一股腦搬出來。兩者缺一不可。而加工過的資料，不管是乙份評估報告，還是乙個智慧型提示，其資料量畢竟是有限的，資料交換方案的規模也是可控的。
因此，對於前面提到的查詢案例，對查詢結果的控制，既能確保使用者價值的實現，又能有效降低技術成本。當然，為了進一步提公升使用者價值，可以在簡化使用者輸入和提高命中率方面下功夫。依靠搜尋引擎技術，可以在這些方面做到極致，而智慧型化也其中的關鍵。
推廣一下，其實「有限資料流量」不僅可以降低技術成本，還能實現更好的使用者體驗。曾經有一套影像診斷解決方案，為了突出其針對某種影象的強大的處理功能，把原始影象傳輸到工作站上，便於讓醫生用這種處理功能來讀片。確實，這種方案受到一些發燒友級醫生的擁護，但更多的醫生接受的是另一種更加簡單的方案。影象在到達桌面之前就已經用這種很酷的功能，哪怕是一些沒這麼酷，但足夠用的功能處理好，出來的就是乙個基本上不需要過多調整就可以讀片的影象。有人爭辯說，這樣可能會提高誤診和漏診率。但市場似乎並不關心這些，就像蘋果***的使用者就是不需要在螢幕上同步顯示歌詞那樣，因為他們只想讓自己一邊被美好的**環繞，一邊做別的事情，而不是讓自己被乙個小小的螢幕鎖住。好吧，扯遠了。
回到整合的話題。去年我在中國bme的年會上提交了一篇**，叫做《醫療資訊系統整合模式初探》，裡面總結了下面這些醫療整合方案中常用的幾條設計原則。其實這些東西都是前年整理的，現在確實有點老了。如果有機會更新的話，現在可以增加一條「有限資料流量法則：整合方案的一種優化設計策略」。
1. 複製和遷移：針對醫療系統基礎資料依賴性相關的問題
2. 索引和資訊樁：針對醫療系統之間物件引用和管理問題
3. id私有：針對醫療業務實體標識的區域性性和全域性性問題
4. 確認和重試：針對整合醫療系統中的資料容錯問題
5. 請求和通知：關於弱耦合系統間通訊方式選擇的建議
6. 外掛程式和宿主：強耦合系統間實現靈活裝配的一種方案
TCP互動資料流 成塊資料流
tcp資料流分類 基於tcp的各類解決方案，可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telnet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種型別的協議要求tcp能盡量的運載資料，把資料的吞吐量做...
C 的資料流
1 stringstream std stringstream png file png file qq 此時是把qq賦值給png file，png file.str 就是qq 即 std cout png file.str 輸出是qq 2 ofstream ofstream outfile out...
HDFS的資料流
1.客戶端通過distributed filesystem模組向namenode請求上傳檔案,namnode檢查目標未見是否已經存在,父目錄是否存在.2.namenode返回是否可以上傳 3.客戶端請求第乙個block上傳送到那幾個datanode伺服器上 4.namenode返回三個datanod...