DICOM-SOP

SOP：Service Object Pairs
IODs定义DICOM数据信息
DIMSE定义DICOM服务命令
通俗来讲，我们需要通过命令来操作数据，也就是我们常说的服务对象对

下图是一个SOP类的结构：

每一个SOP都对应着一个描述性的名字和一个对应的DICOM UID，通过它来告诉我们一个DICOM应用都提供了哪些服务。
下面附表是2007版标准里的DICOM SOP UIDs：在此不一一列举，可以查阅DICOM标准。

下面是最基本和最常用的SOP Class：
（1）Verification SOP
验证两个AE的DICOM连接。其中DIMSE是C-Echo，因为不进行任何的数据数据处理，所以不传递数据，IOD为空。
它与C-Echo作用相似。如果没能返回success，大概有两个原因；1、网络不通，通过ping进行确认。2，AE配置不正确
（2）Storage SOP

他实现图像从一个AE到另一个AE的传输，因为不同对象的处理方式不通，所以它针对不同的设备类型和数据类型定义了不同的UID下表是常用的storage sop
Storage Sop中
DIMSE：C-Store
   C-Store-SCU：请求存储图像方
            请求参数tag值：
                     SOP class UID图像类型UID，例如CT图像、MR图像
                     SOP Instance UID，被存储的图像的UID
                     Priority，一般不用
                     Move Originator title and message ID：因为C-Get和C-Move都能引起C-Store，所以
                     此字段包含了调用的AR Title和Message ID。
                     Data set type：在C-Echo中，0101表示空，在C-Store中，0000表示不空
C-store-SCP：提供图像存储，返回Rsp方
   响应的参数多数来源于请求
   其中，status：0000表示存储成功
                 00FF表示正在进行
                 其它表示警告或者错误
IOD：需要被存储的数据，每一个C-Store请求只能包含一个IOD实例，即如果我们有多幅图像，只能一幅一副的传，而不能一次传不传输，唯一的例外是超生的多帧图像，他可以作为一个IOD instance一次性传输过去。

（3）Query-Find Sops

Find并不像Store，包含大量的基于设备的SOP，它主要将查询分为3个level，也就是它包含三个Sop，分别是
Patient Root Q/R Find SOP
Study Root Q/R Find SOP：默认支持，应用最广
Patient-Study Q/R Find SOP
DIMSE：C-Find
在不同的AE之间传递C-Find IOD，当有多个匹配参数时，每一个匹配都需要DIMSE+IOD对。
IOD：包含了在C-Find服务提供器里需要被匹配的参数。
C-Find level include Patient，Study，Series，Image

（4）C-Cancel SOP
没有响应返回，没有参数传递。
（5）C-Get SOP

DIMSE：C-GetDICOM-SOP
C-Get Rsp响应dataset type 不是空的，包括一共多少幅图像，传了多少，还剩多少等信息。
IOD：匹配C-Find参数的patient data

（6）C-Move SOP

Move在请求参数中包含了目的DICOM AE的title
与Get相比，安全性更高一些，是双通道的，Get是单通道的
（7）MPPS SOP
（8）Storage Commit SOP
用来确信接收图像存储的设备确实进行了存储。