DICOM：DICOM Print服务中PresentationContext协商之 MetaSOPClass与SOPClass对比分析

最新推荐文章于 2024-10-16 11:14:37 发布

原创

最新推荐文章于 2024-10-16 11:14:37 发布 · 8.6k 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#DicomPrint #dcmtk #fo-dicom #MetaSOP #SOPClass

背景：

最近项目中遇到的实际问题较多，且大多是较隐蔽的、不易被发现的错误。究其根源来看，还是对DICOM3.0协议中的细节掌握不够仔细，因而导致在实际编码过程中，常常想当然。前一篇中剖析了由于DicomClient中的AddRequest与Send函数调用逻辑错误导致的System.ObjectDisposedException异常，接下来要讲的是关于DICOM胶片打印的问题，由于在Association Negotiation中PresentationContext协商失误导致DICOM Print SCU在连接某些型号打印机时无法出片。

DICOM Print：

DICOM3.0协议中关于PRINT的部分主要有：第4部分的附录H、第17部分的附录BB，在第4部分的附录H中主要讲解的是整体DICOM Print SOP，即服务对象对；而第17部分附录BB中给出的是一个具体的DICOM Print SCU实现过程。因此在利用dcmtk、fo-dicom或者dcm4che开源库来实现自己的DICOM Print服务（SCU或SCP）时应该先仔细阅读第4部分附录H中关于该服务的详细定义与介绍，然后再按照第17部分的附录BB中示例的流程进行实际开发。第17部分附录BB中给出的具体流程如下：
这里写图片描述
由图中可见，在Association Negotiation阶段并未给出详细的步骤，而这部分恰恰是项目实际部署过程中遇到隐含问题的地方，在介绍问题之前先介绍一个DICOM Print服务中独有的服务。。

DICOM Meta SOP Class与DICOM SOP Class：

Presentation Context：

在DICOM协议底层建立连接时，会用到Presentation Context，如下图所示：
这里写图片描述
简而言之PresentationContext就是连接上下文，存储用于连接双方进行协商的信息，具体的介绍可参阅专栏中的博文和。DICOM协议规定，在连接请求（Association Negotiation）过程中，由请求发起方设置各个Presentation Context的ID号，该ID号不具有实际意义，类似于数据库中的主键Primary Key，仅用于区别各个Presentation Context，被请求端在接收到请求端发送过来的请求后，并不会修改消息中PresentationCont