DICOM醫學圖像處理：Deconstructed PACS之Orthanc

目錄(?)[+]

背景：

        此篇博文介紹一個開源的、基于WEB的DICOM Server軟體。該開源軟體完全使用C++編寫，不依賴于第三方資料庫（内置了SQLite資料庫）或其他架構，支援RESTful API設計模式。官網上提供了源代碼，同時也給出了編譯後的Windows和Linux系統的二進制安裝包。Orthanc是PACS領域的一種改革，提出了“解構PACS概念”，即Deconstructed PACS，使用者可以通過三種方式通路Orthanc：DICOM Server、Web Server和RESTful API。

Orthanc：

        開源中國社群中對于Orthanc有一段這樣的描述：Orthanc是一個輕量級的，基于REST的DICOM伺服器，主要用于衛生保健和醫療研究。Orthanc可将任意運作Windows和Linux的計算機程式設計DICOM存儲（或者說是一個小型PACS系統），其架構是輕量級的，沒有複雜的資料庫管理，不依賴于第三方軟體。

        除此以外，Orthanc官網（http://www.orthanc-server.com/about.php）對于Orthanc的描述着重提到：Orthanc之是以與衆不同是因為它提供RESTful API。是以，Orthanc可以使用任何計算機語言開發。Orthanc存儲的DICOM圖像的标簽可以以JSON檔案格式下載下傳，此外，Orthanc對于存儲的DICOM執行個體可以動态生成對應的PNG圖像。

        Orthanc隐藏了複雜的DICOM檔案格式和DICOM協定，使使用者隻專注于DICOM檔案内容。

Deconstructed PACS：

        Deconstructed PACS是新一代的PACS系統，原文的描述為"The latest strategy for imaging informatics is actually "deconstructed PACS," where the core elements of PACS are best-of-breed or component-based solutions, integrated together using standards-based approaches.” PACS系統最早是通過組合多個獨立的子系統來實作簡單擷取和轉存圖像，對于圖像（images）和醫學資訊（demographics）分别采用不同的網絡；随後發展為C/S模式，通過Client的工作站來實作（胖用戶端thick-client）；最後演變成基于浏覽器的Web PACS（瘦用戶端thin-client）。

【Deconstructed PACS概念目前我還沒有搞太明白，官網的資料比較多，後續會補充更多的資料，有興趣的讀者也可以直接閱讀博文後我給出的連接配接】

Orthanc安裝：

        通過上述簡短的介紹，想必大家已經對Orthanc有了大緻的了解。下面給出Orthanc的安裝方法，Orthanc是一個開源軟體，是以有兩種安裝方式。

Orthanc二進制包在Windows下安裝：

        下載下傳位址：http://www.orthanc-server.com/download-windows.php。在官網下載下傳頁面中輸入基本資訊就會在郵箱中獲得下載下傳連結，Windows下的二進制安裝包名稱為：Orthanc-0.8.5-Installer.exe。輕按兩下安裝包，如下圖所示，單擊“下一步”就可以順利完成安裝。

        該檔案夾用于設定Orthanc軟體的安裝目錄，即主要程式OrthancService.exe和Orthanc-0.8.5-Release.exe的存放位置。

        此處用于設定Orthanc軟體中DICOM Server的資料存儲目錄，可以簡單的了解為mini-PACS的歸檔目錄，後續示例中的圖像就儲存在該檔案夾下。

        此處用于設定Orthanc軟體在開始菜單中快捷鍵的檔案夾。

        單擊Install，稍等片刻即可完成Orthanc在Windows下的安裝。

Orthanc源碼在Windows下編譯運作：

        開源軟體最常用的是源碼編譯，如是可以生成跟本機系統最比對的可執行檔案。Orthanc源代碼下載下傳位址為：http://sourceforge.net/projects/orthancserver/files/Orthanc-0.8.5.tar.gz/download，源碼包名稱為：Orthanc-0.8.5.tar.gz。解壓Orthanc-0.8.5.tar.gz到希望的目錄（本機我選擇C:\），得到C:\Orthanc-0.8.5，如下圖：

        打開INSTALL安裝說明文檔，可以看到安裝必須的準備：

1）CMake，我直接利用本地安裝的CMake2.8（也可以到官網下載下傳最新版本：http://www.cmake.org/）；

2）Python，安裝過程中有一些自動生成的腳本需要用到Python解釋器，下載下傳位址http://www.python.org/，我本機安裝的版本為：Python2.7；

3）7-Zip：用于解壓縮安裝過程中下載下傳的壓縮包，下載下傳位址為http://www.7-zip.org/。

        在選擇CMake GUI界面，指定source code和build路徑後，單擊Configure會出現缺少7-zip的錯誤提示，如下圖：

        原因是我本機起初并未安裝7-zip軟體。按照INSTALL給出的官網下載下傳并安裝完成後，重新啟動CMake再次進行配置後，又會出現錯誤，如下所示。提示缺少libgoogle-glog-dev package，這個應該是google的用于日志記錄的庫。

        在搜尋并下載下傳libgoogle-glog-dev package時遇到了問題，未找到直接的下載下傳連結。是以利用CMake GUI編譯Orthanc的路暫時走不通。重新仔細閱讀INSTALL文檔，找到了在Windwos系統下利用Microsoft Visual Studio進行Orthanc源碼編譯的方法，具體說明如下：

Native Windows build with Microsoft Visual Studio

-------------------------------------------------

# cd [...]\OrthancBuild

# cmake -DSTANDALONE_BUILD=ON -DSTATIC_BUILD=ON -DALLOW_DOWNLOADS=ON -G "Visual Studio 8 2005" [...]\Orthanc

Then open the "[...]/OrthancBuild/Orthanc.sln" with Visual Studio.

        利用cmd進入到指令提示符狀态，仿照上述代碼，建立安裝緩存目錄，mkdir c:\OrthancBuild；随後啟動cmake指令行模式，按照INSTALL中的說明設定編譯模式，具體指令為：

cd c:\OrthancBuild

cmake -DSTANDALONE_BUILD=ON -DSTATIC_BUILD=ON -DALLOW_DOWNLOADS=ON -G "Visual Studio 10" ..\Orthanc-0.8.5\Orthanc-0.8.5

        注：目錄要指定到源碼中CMakeList.txt檔案所在的層級。另外對于本地編譯器的選擇，可以現在cmd狀态下輸入cmake，檢視目前支援的編譯器類型，如下圖所示，我選擇的是Visual Studio 10。

        上述打開了自動下載下傳第三方支援庫的選項，即-DALLOW_DOWNLOADS=ON 。在啟動cmake後，會自動下載下傳我們在CMake GUI模式下提示缺少的各種支援庫。等待所有第三方庫自動下載下傳并安裝完成後，Orthanc源碼就順利編譯完成了，如下圖所示：

        打開上圖中提示的Build files檔案路徑C:\Orthanc-0.8.5，輕按兩下打開VS工程Orthanc.sln。選擇“生成”下的“批生成”，勾選ALL_BUILD項目，單擊“生成”後等待編譯完成。

        順利編譯完成後，在C:\Orthanc-0.8.5\Debug目錄下看到了與二進制安裝後相同的可執行檔案，名稱為Orthanc.exe，如下圖所示：

        至此利用Orthanc源碼進行安裝的過程順利結束。其實在CMake GUI模式下我們勾選了配置項中的“ALLOW_DOWNLOADS”，也可以順利完成Orthanc源碼的編譯。

Orthanc測試：

        Orthanc被描述為一款開源的、輕量級的，滿足RESTfu API 的DICOM伺服器。它獨特之處在于存在多種與Orthanc的互動方式，主要有三種：DICOM Server，Web Server和RESTful API。下面就利用這三種通路方式對上述兩種安裝環境進行執行個體測試：

二進制包的測試：

1）作為DICOM Server：

        安裝并啟動OrthancService.exe後，在任務管理器中可以看到啟動了兩個服務駐留程序OrthancService.exe和Orthanc-0.8.5-Release.exe

        Orthanc提供了發送和接收DICOM圖像的基本功能，類似于一個mini PACS。可以與DCMTK提供的工具包進行良好的互動，此處我就借助DCMTK提供的storescu.exe工具将C:\test.dcm檔案發送到Orthanc，具體指令如下：

storescu.exe –d –aec ORTHANC localhost 4242 c:\test.dcm

        對于storescu.exe工具包的使用可參照我前幾篇的專欄，此處ORTHANC是Called AE Title，4242是Orthanc中DICOM服務的監聽端口，該資訊在安裝過程中指定的資料歸檔目錄（即c:\Orthanc）中的Connfiguration.json配置檔案中可以自行設定，上述指令行中的參數是Orthanc安裝時預設的設定。

        指令執行後，storescu.exe的輸出結果如下圖所示，說明test.dcm檔案已經順利發送到Orthanc。

        打開Orthanc預設的資料歸檔檔案夾C:\Orthanc\OrthancStorage\6a\d6可以看到一個大小與test.dcm相同的檔案，利用DICOM Viewer打開可以看到兩者是同一個檔案。這說明Orthanc成功接收到storescu.exe發送的測試圖像。

2）作為Web Server：

        Orthanc内置了一個Web Server（也可嵌入到Apache服務中），即Orthanc Explorer。Orthanc Explorer提供了一種友好的互動方式，可通過拖拽檔案的方式實作DICOM檔案上傳。下面我們示範一下：

        在開始菜單中選擇Open Orthanc Explorer，或者在Chrome或者Firefox浏覽器中直接輸入http://localhost:8042/app/explorer.html（注：目前不支援IE浏覽器）。打開後此處可以直接看到我們剛才 利用storescu.exe上傳的test.dcm檔案，如下圖所示：

        單擊上圖右上角的Upload DICOM，出現如下界面：

       此時我們可以使用“拖拽”方式實作DICOM檔案上傳。下面我選擇c:\test2.dcm檔案，拖拽到上述頁面中，然後單擊Start the upload，會彈出上傳進度條，如下所示：

        傳回上層界面，可以看到我們“拖拽”的test2.dcm檔案已經順利完成上傳，如下圖所示：

3）利用RESTful API：

        下面介紹Orthanc最令人振奮的通路方式——RESTful API。它提供了一種使用标準網絡協定與圖像伺服器進行互動的方式，使得可以在任何地方（隻要有網絡覆寫）通過網絡連接配接通路Orthanc伺服器，并且無需考慮服務運作的平台或開發語言。RESTful APIs使用URIs來實作資源的定位與通路，此處的資源包括patients、studies和images三級，與DICOM協定中定義相同，傳統的PACS也多以此作為資料庫的設計原則。對于該類請求，Orthanc會将文本資訊以JSON格式傳回（JSON是一種輕量級的廣泛應用的檔案格式）；對于圖像資訊會傳回PNG網絡圖像格式。該部分想必大家都很熟悉，下面我們就直接示範一下：

        此處借助于curl.exe工具，在cmd模式下輸入：

cd c:\

curl –X POST http://localhost:8042/instances –data-binary @test3.dcm

        得到如下結果表明test3.dcm圖像上傳成功，

        打開Orthanc Explorer可以看到剛才上傳的test3.dcm檔案：

源碼編譯後測試：

        在任務管理器中先手動終止OrthancService.exe和Orthanc-0.8.5-Release.exe兩個Orthanc背景服務程序，轉到編譯源碼生成的目錄C:\Orthanc-0.8.5\Debug下，啟動Orthanc.exe，如下圖所示：（調試狀态下Orthanc.exe會輸出狀态資訊，也可以在指令行下啟動Orthanc.exe --verbose輸出調試資訊）

        仿照上一節，從DICOM Server、Web Server和RESTful API三種方式進行測試：

1）DICOM Server

        進入cmd模式，輸入：

storescu.exe –d –aec ORTHANC localhost 4242 c:\test.dcm，可以看到圖像上傳成功的結果：

2）Web Server

        打開谷歌浏覽器，位址欄輸入http://localhost:8042/app/explorer.html，可以看到剛才上傳的test.dcm檔案，如下圖：

        單擊Upload DICOM，拖拽test2.dcm檔案到浏覽器頁面，然後單擊Start the Upload，傳回到首頁面可以看到順利上傳的結果，如下圖：

        打開目錄C:\Orthanc-0.8.5\Debug\OrthancStorage，可以看到順利歸檔的兩個檔案

3）RESTful API

        進入cmd模式，輸入如下指令：

        在Orthanc Explorer中可以順利看到結果，如下圖：

        【注】：與二進制安裝環境下不同的是，curl運作時會偶爾傳回錯誤提示，出現這種情況後重新開機Orthanc.exe就可以解決。

知識點補充：

RESTful API：

        RESTful API是目前比較成熟的一套網際網路應用程式的API設計理論。REST，全稱Representational State Transfer，最早是由Roy Thomas Fielding在他2000年的博士論文中提出的。論文中的部分摘要如下：

“

This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture.

”

        如果一個架構符合REST原則，就稱它為RESTful架構。要了解RESTful結構，需要充分了解Representational State Transfer 這個詞組的含義，每個詞代表什麼意思。該詞組中省略了主語，表現層（representational）其實指的是資源（resources）的表現層。所謂資源就是網絡上的一個實體，或者說網絡上的一個具體資訊。REST從資源的角度來觀察整個網絡，分布在各處的資源由URI确定，而用戶端的應用通過URI來擷取資源的表示方式。所謂上網，就是網際網路上一系列“資源”的互動，一系列URI的調用。

        資源是一種資訊實體，可以有多種表現形式，叫做“表現層（representation）”，例如文本可以用txt表示，也可以用html、xml、JSON表示，甚至可以使用二進制格式；圖檔可以用JPEG、PNG等格式。URI隻代表資源實體，不代表它的表現形式。有些網址最後的.html字尾名是不需要的，因為.html字尾是一種表示格式，屬于“表現層”範疇，URI隻代表資源的位置。

        通路一個網站，就代表用戶端與伺服器的一個互動過程。這個過程中勢必會涉及到資料和狀态的改變。網際網路通信協定HTTP協定，是一個無狀态協定。這意味着，所有的狀态都儲存在伺服器端。是以，如果用戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀态轉化"（State Transfer）。而這種轉化是建立在表現層之上的，是以就是"表現層狀态轉化"。用戶端用到的手段，隻能是HTTP協定。具體來說，就是HTTP協定裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分别對應四種基本操作：GET用來擷取資源，POST用來建立資源（也可以用于更新資源），PUT用來更新資源，DELETE用來删除資源。獲得這些表會緻使這些應用程式轉變了其狀态。随着不斷擷取資源的表示方式，用戶端應用不斷地在轉變着其狀态，所謂表述性狀态轉移（Representational State Transfer）。——這一觀點不是憑空臆造的，而是通過觀察目前Web網際網路的運作方式而抽象出來的。Roy Fielding 認為，“設計良好的網絡應用表現為一系列的網頁，這些網頁可以看作的虛拟的狀态機，使用者選擇這些連結導緻下一網頁傳輸到使用者端展現給使用的人，而這正代表了狀态的轉變”。

        綜合上面的解釋，我們總結一下什麼是RESTful架構：

• 每一個URI代表一種資源；
• 用戶端和伺服器之間，傳遞這種資源的某種表現層；
• 用戶端通過四個HTTP動詞，對伺服器端資源進行操作，實作"表現層狀态轉化"；

WADO：

        關于WADO的詳細介紹可以參考DICOM3.0标準的第18部分。