平時在論壇上我都是潛水居多，突然心血來潮回覆了兩篇，姑且轉載一下，至少在這裏，永遠不會沉底。
對於初學者，先看DICOM第一章，瞭解DICOM的內容。其實在現實世界中，DICOM真正落地以後，主要就是以下幾個方面的協議，因此，你首先要弄清楚這幾個方面分別是在DICOM的哪些章節裏面描述的。
- 文件格式
- 網絡通信協議
- 圖像顯示方式
然後熟悉一下DICOM文件格式：在網上順便找幾個DICOM文件，用ultraedit等二進制編輯工具打開，同時打開DICOM標準的文檔，對照着看。搞清楚一些常用的概念和技術，如隱式顯式，大頭小頭，壓縮不壓縮，字符編碼等。通過具體的實例對DICOM的數據結構建立感性認識的以後，可以看看第三章裏面的對象模型，尤其是Patient/Study/Series/Instance之間的關係，是DICOM對象模型的核心。
DICOM文件格式，或者準確地說，DICOM信息對象的數據格式，是學習DICOM網絡通信和圖像顯示的基礎。有了這個基礎，對於網絡通信和圖像顯示的學習可以並行進行，如果你有一個團隊，可以分別讓不同的人去做。
關於網絡通信協議：找一些可以進行DICOM通信的服務端和客戶端程序，如果你們自己有PACS，就更好。然後，找一些比較方便易用的DICOM SDK，用你自己熟悉的編程語言，自己做一個簡單的客戶端和服務端程序，跟你們自己的PACS裏面的服務端和客戶端通信，從而獲得一個直觀的認識。必要的話，還可以用網絡抓包工具，看看二進制層面的通信過程，當然也是對照着DICOM標準的文檔，一起看。剛開始可以從比較簡單的通信過程如echo,store開始，搞清楚一些常用的概念和技術，如SCU/SCP，抽象語法，傳輸語法，服務類等，有了這些基礎，你就可以慢慢學習一些常用的但可能稍微複雜一些的通信過程，如查詢檢索，存儲確認，worklist/mpps，WADO等。
關於圖像顯示方式，或者說把DICOM文件中的像素編碼解碼成GUI上的像素的過程：你首先要有一些數字圖像的基礎。拿最常見的灰度圖象來說，你要知道像素深度，窗寬，窗位，LUT等概念，如果你們自己的PACS工作站支持直方圖調節（好像Photoshop裏也有）的話，對於這些概念可能會有一些更加直觀的認識。網上也可以找到很多代碼，能夠把DICOM像素解碼成8位的Bitmap，或者反之，你可以找來看看。不過這個只是個開始，後面還有很多醫生常用的圖像瀏覽和處理技術，比如測距，縮放，CT定位線，顯示狀態，關鍵對象，懸掛協議，GSDF和一致性顯示等，就要你慢慢去摸索了。
贊同wholx的觀點，我們的確應該從業務需求出發來考慮集成平臺的問題。
首先看看醫院的業務。
我想我們這些搞醫療IT的，如果平時工作中到醫院去機會比較少，至少自己去看病的時候可以多留心一下。當然最好的情況是，懷揣一顆敏感的心，親自到醫院去體驗一段時間。雖然沒有這麼好的機會，但至少我自己去醫院看病的時候，所看到的情況是，樓道里，走廊上，到處都是拿着各種各樣的單據穿梭着的病人，各種病原體也隨着這些單據到處飄散。想想看，如果集成做得好，會不會出現這種狀況？
好了，就算有一天，病人不再需要懷揣一大堆單據，但是他們還是得在各個科室各個樓層之間到處穿梭啊？包括很多行動不便的病人。對於這種狀況，我們的確無能爲力，這是那些建築師應該考慮的問題。但集成至少是第一步，集成給病人帶來的價值遠不至減輕手上的那一點點負擔而已，它帶來的是更好的醫療服務：醫生可以依據你詳盡的病史，爲你設計最適合你的體質的治療方案，或者根據你家庭成員情況，爲全家設計家庭保健計劃；如果你在互信的醫院做過檢查，不就再需要接受更多的輻射或者獻出不必要的鮮血；彙總的醫療記錄還可以提供某些公共衛生狀況的警示，在全院或者社區範圍內定位流行病狀況和趨勢。。
我們看看以上這些集成能夠帶來的好處，多半都是跟病人直接相關的，有哪條能讓醫院直接賺到錢啦？你病人拿着髒兮兮的單據來又怎麼拉，我可以用手套接着；你病人多做一次檢查又怎麼啦，我還可以多賺錢。。但人這一輩子，誰能說他沒有當上病人的那一天呢。。
前幾天在公交車上看到政府鼓勵社會力量投資辦醫院，我舉雙手贊成，的確應該殺殺這些公立醫院的威風了，要不醫療改革措施再多，也是上有政策下有對策。
但是，作爲普通老百姓，誰又敢用自己的健康做賭注去嘗試那些私立醫院呢，中國的騙子不要太多了。看來還是需要有很多配套的，切實可行的監管啊。。
不管怎麼樣，稍微有點良知的人，都渴望實現全民共有的，高質量的醫療服務，而這一切的基礎，就是集成。
再看看醫療IT廠商的業務。
首先我們必須承認，商務上的技巧永遠比技術上的技巧更容易讓公司取得成功，尤其在一個不成熟的市場裏面。很遺憾，我們（技術人員）還是把責任推給了一個幾乎沒有人能掌控的東西，比如不成熟的市場、不成熟的社會、不成熟的GOV等等等。。
但是，每個真正懂得信息系統的工程師，都會明白，世界上絕對沒有一個all-in-one的系統，你想用一個開發部門級業務系統的方式去開發一個醫院級業務系統，是絕對不可能的。這幾年很多人，包括HIS業內人士，都在討論HIS的概念和範疇，還有按照SOA的原則來重新組織各個部門業務系統，這裏我就不多說了。我只是想提醒大家，一個定義良好的集成平臺，不僅是醫院信息科理清各個部門業務系統之間的關係，從而實現更好的業務流程的切入點，更是醫療IT廠商理清自己的產品和產品線規劃，從而滿足各種個性化的解決方案需求的切入點。
另外，tyq提到標準的問題。不管是院內的標準，還是行業的標準，我們都需要把握一點，我們必須學會駕馭標準，而不是被標準駕馭。尤其是對於集成平臺廠商，不管在員工面前，還是在客戶面前，過分地強調標準，都是愚蠢的。否則，你就只能跟這標準的屁股跑，而意識不到這些標準（尤其是行業標準）其實都是其他（制定這些標準）廠家已經炒過的冷飯。更加糟糕的是，這些行業標準大多都是業務相關的，而且業務本身也不斷的發展和變化，大家還會不斷地把這個冷飯炒下去，你就永遠沒有跟得上的那一天。當然，我們並不鼓勵每個廠商都自己搞一個標準，而是鼓勵這些廠商積極地參加到這些標準中來。先進的廠商可以根據自己對行業的理解，在標準中加入自己的東西，爲別人設立一些門檻，也爲了建立行業經驗共享和發展的良性循環；後進的廠商可以通過這些標準儘快地理解這個行業的核心業務，因爲如果換成軟件工程的術語，這些標準給你提供的可是一套很好的領域模型啊。
企業信息化領域的EAI和SOA搞了很多年，也爲我們積累了很多經驗和教訓，其中《SOA實踐指南——分佈式系統設計的藝術》一書讓人受益匪淺。正是因爲醫院的業務需要堅固需要靈活，公司的產品需要模塊化需要互操作，行業的標準需要改進需要優化，才使得集成和集成平臺更加有價值。
而這一切最終還是爲了老百姓(也就是我們自己）的健康——就算是因爲我自己被洗腦了也罷，就讓我們這些工程師保持一些純潔的理想吧。
最後簡單回答一下Paullee的問題：
1、你需要瓶頸嗎？等到私立醫院靠物美價廉的服務取得成功的時候吧。
2、業務上的不同可以從IHE TF ITI中帶cross的IP（包括很多在討論之中的IP）中看出來，技術上嘛，主要就是基於互聯網這個平臺的各種新東西了。
3、個人的理解不一定準確，總之看到國外不少原來做集成引擎起家的廠商，把他們的集成引擎/平臺產品稍微延展一下，比如加上一個集中存儲、一個病人ID管理、一個門戶等，就變成一個簡單的電子病歷了。
4、這個不太清楚，請大家指教，總之作爲電子病歷，存儲需求應該是：長期/可靠/海量。
5、雖然這方面經驗不多，但不太贊成或不太理解這個觀點。信息系統的一步步發展的確要有一個規劃，以充分考慮到資金狀況、用戶接受的過程等。但是在一個好的架構下面，應該沒有任何一個部件是必須先上的，如果是這樣的話，用分佈式領域的術語就是單點故障，這對於要求高可用性的醫療系統，是不可理喻的。