4. DICOM服务类与SOP类
在DICOM网络中，两台设备之所以能“对话”，并不是因为它们碰巧使用相同的消息格式，而是因为它们事先约定了“要一起完成什么任务”以及“这个任务具体操作哪类信息对象”。DICOM用两个层层嵌套的概念来描述这种约定：服务类（Service Class）和SOP类（SOP Class）。理解这两者的定义与关系，是读懂后续所有DICOM服务（C-STORE、C-FIND、C-MOVE、C-ECHO等）的基础。
一、服务类：定义“能做什么”
服务类描述的是DICOM应用实体（Application Entity，AE）之间可以执行的一类操作能力。它回答的问题是：“这个设备能提供或使用哪种服务？”常见的服务类包括：
- 验证服务类（Verification Service Class）：用于确认对端AE是否在线、能否响应，对应操作是C-ECHO。
- 存储服务类（Storage Service Class）：用于把图像或其它复合对象发送到对端，对应操作是C-STORE。
- 查询/检索服务类（Query/Retrieve Service Class）：用于按条件查询患者、检查、序列、图像，并把结果取回，对应操作是C-FIND、C-MOVE、C-GET。
- 工作列表管理服务类（Modality Worklist Management Service Class）：用于让影像设备从RIS/HIS获取待检查患者的工作列表，对应操作是C-FIND（针对工作列表信息模型）。
- 打印管理服务类（Print Management Service Class）：用于把图像排版后送到DICOM打印机或打印服务器，对应操作包括N-CREATE、N-SET、N-ACTION、N-DELETE等。
服务类本身只规定“能力”，不规定“操作对象”。例如“存储服务类”只说“我能接收或发送存储请求”，但存储的到底是CT图像、MR图像还是超声图像，需要由SOP类来进一步限定。
二、SOP类：定义“对什么对象做什么”
SOP是Service-Object Pair的缩写，即“服务—对象对”。一个SOP类把某个信息对象定义（IOD）与一组允许在其上执行的服务操作绑定在一起。例如：
- CT图像存储SOP类：信息对象是CT图像IOD，允许的操作是存储（C-STORE）。
- MR图像存储SOP类：信息对象是MR图像IOD，允许的操作同样是存储。
- 患者根查询/检索SOP类：信息对象是患者根查询模型，允许的操作是C-FIND、C-MOVE、C-GET。
- 模态工作列表SOP类：信息对象是模态工作列表模型，允许的操作是C-FIND。
- 基本灰度打印管理SOP类：信息对象是打印管理相关IOD，允许的操作是N-CREATE、N-SET、N-ACTION等。
因此，SOP类 = 信息对象 + 服务操作。它比服务类更具体，是设备在关联协商时真正声明和匹配的单元。
三、服务类与SOP类的关系
两者是“能力类别”与“具体实现单元”的关系。一个服务类可以包含多个SOP类；一个SOP类通常归属于某一个服务类。设备在建立DICOM关联（Association）时，会在A-ASSOCIATE请求中列出自己支持的表示上下文（Presentation Context），每个表示上下文由一个SOP类和一个传输语法组成。对端如果也支持该SOP类，就接受这个表示上下文，双方才能在该SOP类上执行对应操作。
举例来说，一台CT设备要发送图像到PACS：CT声明支持“CT图像存储SOP类”，PACS也声明支持该SOP类，双方协商成功后，CT才能发起C-STORE。如果PACS只支持“MR图像存储SOP类”而不支持CT，那么即使两者都声称支持“存储服务类”，也无法完成CT图像的存储。这说明：服务类决定“能不能做这类事”，SOP类决定“具体能不能做这件事”。
四、关联协商中的实际匹配过程
在实际工程中，服务类与SOP类的关系最终体现在关联协商上。以一台CT向PACS发送图像为例，典型过程如下：
- CT作为发起方，在A-ASSOCIATE请求中列出多个表示上下文，每个上下文包含一个SOP类UID和一个传输语法（如Implicit VR Little Endian、Explicit VR Little Endian）。
- PACS作为接收方，逐项检查自己是否支持该SOP类。如果支持，就在A-ASSOCIATE响应中接受该表示上下文，并指定最终使用的传输语法。
- 协商成功后，CT才能在该SOP类对应的表示上下文上发起C-STORE请求。
- 如果PACS不支持某个SOP类，该表示上下文被拒绝，CT无法通过该上下文发送对应对象。
这里有一个容易混淆的点：服务类不是协商单元，SOP类才是。 设备在配置DICOM连接时，通常需要填写“支持的SOP类列表”，而不是“支持的服务类列表”。服务类更多是标准文档中的分类框架，用于组织SOP类。
五、常见服务类与SOP类的对应关系
| 服务类 | 典型SOP类 | 主要DIMSE操作 | 典型应用场景 |
|---|---|---|---|
| 验证服务类 | 验证SOP类 | C-ECHO | PACS连通性测试、AE在线检测 |
| 存储服务类 | CT/MR/US等图像存储SOP类 | C-STORE | 设备向PACS发送图像 |
| 查询/检索服务类 | 患者根/研究根/序列根查询SOP类 | C-FIND、C-MOVE、C-GET | PACS查询、调阅历史检查 |
| 工作列表服务类 | 模态工作列表SOP类 | C-FIND | CT/MR从RIS获取待检查患者 |
| 打印管理服务类 | 基本灰度/彩色打印SOP类 | N-CREATE、N-SET、N-ACTION | 图像排版后送DICOM打印机 |
六、工程配置中的注意事项
在实际配置DICOM连接时，工程师需要关注以下几点：
- SOP类UID必须精确匹配：不同厂商可能对同一类对象使用不同的SOP类UID，配置时要核对标准UID，不能凭名称猜测。
- 传输语法要兼容：即使SOP类匹配，如果传输语法不被接受，关联仍可能失败。常见做法是同时声明隐式VR小端、显式VR小端和显式VR大端。
- 角色选择：查询/检索服务类中，发起方可以是SCU（请求查询）或SCP（响应查询），配置时要明确设备扮演的角色。
- 工作列表与查询/检索的区别：两者都使用C-FIND，但信息模型不同，SOP类UID也不同，不能混用。
掌握服务类与SOP类的定义和关系后，后续学习C-ECHO、C-STORE、C-FIND、C-MOVE等具体操作时，就能清楚知道每个操作属于哪个服务类、作用于哪个SOP类、在关联协商中如何被匹配，从而在实际工程中快速定位连接失败、传输失败或查询无结果等问题。