DICOM通讯（ACSE-＞DIMSE-＞Worklist）

DICOM 通讯协议中的 ACSE → DIMSE → Worklist 这条通讯链路。DICOM 通讯栈本身是一个多层的协议结构，就像 OSI 模型一样，逐层封装功能。

一、DICOM 通讯协议栈总体架构

DICOM 通讯使用 TCP/IP 建立连接，其上面封装了多个协议层次，如下所示：

物理层 (TCP/IP)
└── 应用服务元素层（ACSE）
    └── DICOM 消息服务元素层（DIMSE）
        └── DICOM 服务类（如 Worklist、C-FIND、C-STORE）

二、分层结构分析（ACSE → DIMSE → 服务类）

三、各层通讯流程详解

1. ACSE – 建立连接和协商参数

• 目的： 类似“握手”，保证双方都支持相同的 SOP Class 和传输语法。
• 主要操作： A-ASSOCIATE 请求/响应。
• 双方角色：
  • SCU（Service Class User）——客户端，一般是 Modalities（如 CT、MR）；
  • SCP（Service Class Provider）——服务端，一般是 RIS、PACS 系统。

🔁 示例流程：

Modality（SCU） ---- A-ASSOCIATE-REQUEST ----> RIS/PACS（SCP）
                  <---- A-ASSOCIATE-ACCEPT ----

2. DIMSE – 封装命令与数据

• DIMSE-C（Command）服务：
  • C-ECHO：测试网络连通性；
  • C-FIND：查找 Worklist；
  • C-STORE：存储影像；
• DIMSE-N（Normalized）服务：
  • 如 N-CREATE, N-SET，多用于打印、影像挂接等场景。

📌 这些命令都是通过 P-DATA 传输的，一次 DICOM 命令可能包含多个数据块（PDUs）。

3. 服务类：Modality Worklist 实际通讯流程

Modality Worklist（MWL）服务帮助 Modalities 自动获取病人检查信息，避免人工输入。

🧭 实际通讯步骤如下：

🌐 查询参数举例（Worklist C-FIND 请求 DataSet）

四、现实系统中的典型场景（示意图）

+-----------+            +-------------+
|  Modalities| <--C-FIND--|  Worklist SCP|
|  (CT/MR)  | --C-FIND--> |   (如RIS)   |
+-----------+            +-------------+
       \                       ^
        \-C-STORE 影像--------/
         \--> PACS 存储服务器

🧠 总结知识点（结构化回顾）

🌐模块一 DICOM 通讯分层机制简明解析

DICOM 通讯协议遵循类似于 TCP/IP 的分层架构，其核心通信流程由以下三层构成：

🔷 1. ACSE（Association Control Service Element）

负责 建立、确认、拒绝或释放会话连接

✅ 功能：

• 完成 SCU（客户端） 与 SCP（服务器）之间的会话建立和协商
• 协议协商内容：SOP Class、传输语法、AE Title 等

📦 ACSE 层常见 PDU（协议数据单元）类型：

🔷 2. DIMSE（DICOM Message Service Element）

处理 DICOM 命令、响应和数据，如查询、存储、回声测试等

✅ 功能：

• 接收 ACSE 层传入的 P-DATA PDU；
• 解包获取 DIMSE 命令：如 C-ECHO、C-FIND、C-STORE 等；
• 执行 DICOM 服务操作，封装响应回传。

📌 数据识别关键：

📍若接收到的第一个字节为 0x04（十进制 4），则代表该 PDU 类型为 P-DATA-TF，表明数据需进入 DIMSE 层进一步处理。

🔷 3. DICOM 服务类（以 Worklist 为例）

通过 DIMSE 封装的服务，提供真实的医疗影像业务能力，例如病人信息查询、影像传输等。

✅ Worklist 示例（Modality Worklist）：

• 基于 DIMSE 层的 C-FIND 命令；
• 查询参数包括病人姓名、检查日期、检查类型等；
• 返回结果包含待检查病人的详细信息，供 Modalities 自动填充。

你的分析很精准，抓住了 DICOM 协议中从 ACSE 到 DIMSE 的过渡细节。下面我将对你这段内容进行条理清晰的结构化分析，并补充：

1. PDU → PDV → DIMSE Command/DataSet 的转换流程图解
2. DIMSE 服务组（11种服务）全部列出并说明作用
3. PDV Flags 字节说明表格

🔄 模块二 DICOM 通讯处理流程：PDU → PDV → DIMSE

当 ACSE 层接收到 PDU 且其类型为 0x04（P-DATA-TF） 时，进入以下处理流程：

PDU（P-DATA-TF）
  ↓
剥离 PDU Header
  ↓
分解为一个或多个 PDV（Presentation Data Value）
  ↓
每个 PDV 包含：
  - Presentation Context ID（表示关联 SOP Class）
  - PDV Header Flags（标识 Command/Data Set 及是否结束）
  - PDV 内容（真正的数据）
  ↓
根据 Flags 判断：
  - 是 Command 还是 Data Set
  - 是否已完成该 PDV 单元
  ↓
交由 DIMSE 层解析并执行服务操作（如 C-FIND、C-STORE）

🧱 DIMSE 层完整服务列表（11种）

DIMSE（DICOM Message Service Element）定义了 11种服务原语，包括命令和响应，分为两类：

1️⃣ DIMSE-C 服务（基于 Composite 信息对象，最常用）

2️⃣ DIMSE-N 服务（基于 Normalized 信息对象，主要用于打印管理等）

🧾 PDV Header Flags 字节说明

每个 PDV（Presentation Data Value） 的头部包含一个 Flags 字节（1字节），用于指示数据性质：

示例：

🎯 完整结构梳理

每个 DIMSE 服务对应的典型 SOP Class UID（服务对象类唯一标识符） 和实际应用场景。我们将从 DIMSE-C 和 DIMSE-N 两大类出发，列成表格。

🧱 模块三 DIMSE-C 服务类：SOP Class UID & 典型场景

📝 说明：

• C-FIND 与 C-MOVE、C-GET 对应的 SOP Class UID 会根据查询层级（Patient/Study/Image）变化；
• C-STORE 的 SOP Class UID 会根据图像类型变化（CT、MR、US、CR 等）；
• 有超过百种 SOP Class UID，但常用如上所列。

🧱 DIMSE-N 服务类：SOP Class UID & 典型场景

📝 DIMSE-N 服务多用于 DICOM 打印系统（DICOM Print Management），在临床中已有 PACS 较少使用，但仍用于一些医疗影像打印服务器对接中。

🧩 补充说明：SOP Class UID 的作用

• 每个 SOP Class UID 唯一标识一种 DICOM 服务或数据模型；
• 在 ACSE 建立连接时，双方通过 A-ASSOCIATE-RQ 中的 Presentation Context 协商 SOP Class（即功能）；
• 若某一端不支持该 UID，则连接请求会被拒绝或功能无法执行。

📌模块四 总结 Modality Worklist 通讯涉及的完整流程

🔁 流程图概览（通讯交互顺序）

[SCU]                                  [SCP]
  |                                      |
  |-- A-ASSOCIATE-RQ (请求连接) -------->|
  |<-- A-ASSOCIATE-AC (接受连接) --------|
  |                                      |
  |-- P-DATA-TF (封装 C-FIND-RQ) ------->|
  |<-- P-DATA-TF (封装 C-FIND-RSP) -----|
  |<-- P-DATA-TF (封装 C-FIND-RSP) -----|  多次，返回一个或多个结果
  |<-- P-DATA-TF (Status=0x0000) -------|  表示返回完毕
  |                                      |
  |-- A-RELEASE-RQ --------------------->|
  |<-- A-RELEASE-RP ---------------------|

🧾 关键服务元素详解

1️⃣ A-ASSOCIATE-RQ 包含协商内容：

2️⃣ C-FIND-RQ 包含查询数据集（DataSet）

一个标准的 Worklist 查询参数示例：

(PatientName, PN, “DOE^JOHN”)
(ScheduledProcedureStepStartDate, DA, “20250414”)
(Modality, CS, “CT”)

3️⃣ C-FIND-RSP 包含：

🎯 四、Status 字段值说明（C-FIND-RSP）

✅典型场景回顾（应用于 Modalities 自动填充）

1. CT 设备启动时主动发起 Worklist 查询；
2. 查询参数通常为当天日期；
3. PACS 或 RIS 返回病人待检查列表；
4. 技术员选择一条记录，设备自动填充病人信息；
5. 完善检查项后进行采集、图像发送等操作。

📘 模块五 连接释放的作用

在 DICOM 网络通讯中，一个完整的会话由“建立 → 通讯 → 释放”三阶段构成：

📌 释放连接并不是“强制断开”，而是一种双向确认的正常断开过程。

🧱 A-RELEASE-RQ / RP 数据结构说明（简化）

A-RELEASE-RQ（SCU 发起）

A-RELEASE-RP（SCP 响应）

🔁 释放流程图（时序）

[SCU]                                  [SCP]
  |                                      |
  |-- A-RELEASE-RQ --------------------->|  ← 客户端请求释放连接
  |<-- A-RELEASE-RP ---------------------|  ← 服务端确认释放
  |                                      |
  |----> 关闭 Socket ------------------->|  ← 通讯资源释放完成

🔍 为什么“释放连接”是必须的？

🎯 释放连接失败的处理（异常处理建议）

✅ 总结：释放连接在 DICOM 中的地位

• 是整个 ACSE 协议的重要组成；
• 是符合 DICOM 协议的“优雅断开”；
• 必须在 SCU 或 SCP 完成所有 DIMSE 命令操作后再发起；
• 在调试网络通讯时，如果发现连接悬挂不释放，极可能是 A-RELEASE 环节未正确处理。