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模式，输入如下指令：

cd c:\

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

在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部分。

参考资料：

http://www.orthanc-server.com/index.php，Orthanc官网

http://www.orthanc-server.com/blog.php，Orthanc

http://www.auntminnie.com/index.aspx?sec=ser&sub=def&pag=dis&ItemID=107001，Deconstructed PACS

http://www.auntminnie.com/index.aspx?sec=sup&sub=pac&pag=dis&ItemID=55408，Deconstructed PACS

http://siim.org/siim2014/scientific-program/deconstructed-pacs，Deconstructed PACS

http://idoimaging.com/blog/?p=288，I Do Imaging

http://www.codeproject.com/Articles/797118/Implementing-a-WADO-Server-using-Orthanc，Orthanc Plugins SDK

http://baike.baidu.com/view/5798116.htm?fr=aladdin，RESTful APIs

http://www.cnblogs.com/springyangwc/archive/2012/01/18/2325784.html，RESTful APIs