DICOM 通訊協議中的 ACSE → DIMSE → Worklist 這條通訊鏈路。DICOM 通訊棧本身是一個多層的協議結構，就像 OSI 模型一樣，逐層封裝功能。
一、DICOM 通訊協議棧總體架構
DICOM 通訊使用 TCP/IP 建立連接，其上面封裝了多個協議層次，如下所示：
物理層 (TCP/IP)
└── 應用服務元素層（ACSE）└── DICOM 消息服務元素層（DIMSE）└── DICOM 服務類（如 Worklist、C-FIND、C-STORE）
二、分層結構分析（ACSE → DIMSE → 服務類）
| 層級 | 全稱 | 功能 | 示例 |
|---|
| ACSE | Association Control Service Element | 建立、維護、釋放連接 | 握手、驗證 AE Title、協商 SOP Class |
| DIMSE | DICOM Message Service Element | 封裝具體 DICOM 命令 | C-ECHO（測試聯通）、C-FIND（查詢）、C-STORE（存儲） |
| 服務類（SCP/SCU） | 如 Worklist、Storage 等 | 提供特定服務操作的實現 | Modality Worklist、Image Store 等 |
三、各層通訊流程詳解
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 自動獲取病人檢查信息，避免人工輸入。
🧭 實際通訊步驟如下：
| 步驟 | 通訊方向 | 操作 | 協議層 | 說明 |
|---|
| 1 | Modality → RIS | A-ASSOCIATE | ACSE | 連接并協商 SOP Class 和傳輸語法 |
| 2 | Modality → RIS | C-FIND 請求 | DIMSE | 提交查詢條件（如 Scheduled Station AE Title） |
| 3 | RIS → Modality | C-FIND 響應 | DIMSE | 返回匹配的 Worklist 項（可能多條） |
| 4 | Modality → RIS | A-RELEASE | ACSE | 釋放連接 |
🌐 查詢參數舉例（Worklist C-FIND 請求 DataSet）
| 屬性標簽 | 屬性名稱 | 說明 | 示例 |
|---|
| (0008,0050) | Accession Number | 檢查號 | 20240401-01 |
| (0010,0020) | Patient ID | 病人ID | 123456 |
| (0010,0010) | Patient Name | 病人姓名 | 張三 |
| (0040,0100) | Scheduled Procedure Step Sequence | 計劃檢查步驟 | 包含影像類型、時間等信息 |
四、現實系統中的典型場景（示意圖）
+-----------+ +-------------+
| Modalities| <--C-FIND--| Worklist SCP|
| (CT/MR) | --C-FIND--> | (如RIS) |
+-----------+ +-------------+\ ^\-C-STORE 影像--------/\--> PACS 存儲服務器
🧠 總結知識點（結構化回顧）
| 層級 | 關鍵術語 | 說明 | 舉例 |
|---|
| ACSE | A-ASSOCIATE, A-RELEASE, A-RJ | 建立/釋放會話連接 | 連接 RIS/PACS |
| DIMSE | C-FIND, C-STORE, C-ECHO | 封裝 DICOM 操作指令 | 查詢 Worklist、發送影像 |
| 服務類 | Worklist, Storage 等 | 提供具體 DICOM 服務 | 自動查詢病人信息、影像歸檔 |
🌐模塊一 DICOM 通訊分層機制簡明解析
DICOM 通訊協議遵循類似于 TCP/IP 的分層架構，其核心通信流程由以下三層構成：
🔷 1. ACSE（Association Control Service Element）
負責 建立、確認、拒絕或釋放會話連接
? 功能：
- 完成 SCU（客戶端） 與 SCP（服務器）之間的會話建立和協商
- 協議協商內容：SOP Class、傳輸語法、AE Title 等
📦 ACSE 層常見 PDU（協議數據單元）類型：
| PDU 類型 | 含義 | 功能說明 |
|---|
A-ASSOCIATE-RQ | 請求建立連接 | SCU 發起連接請求 |
A-ASSOCIATE-AC | 接受連接 | SCP 接受并返回 |
A-ASSOCIATE-RJ | 拒絕連接 | SCP 拒絕連接請求 |
A-RELEASE-RQ / RP | 釋放連接 | 通訊結束時使用 |
P-DATA-TF | 傳輸數據 | 封裝 DICOM 命令與數據（傳入 DIMSE 層） |
🔷 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 的過渡細節。下面我將對你這段內容進行條理清晰的結構化分析，并補充：
- PDU → PDV → DIMSE Command/DataSet 的轉換流程圖解
- DIMSE 服務組（11種服務）全部列出并說明作用
- 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 信息對象，最常用）
| 服務名 | 操作代碼 | 用途說明 |
|---|
C-ECHO | 0x0030 | 測試 DICOM 通訊連通性 |
C-FIND | 0x0020 | 執行查詢操作（如 Worklist 查詢） |
C-GET | 0x0010 | 從 SCP 獲取數據（圖像等） |
C-MOVE | 0x0021 | 將數據從 SCP 推送到其他 AE |
C-STORE | 0x0001 | 向 PACS 服務器存儲圖像或其他實例 |
2?? DIMSE-N 服務（基于 Normalized 信息對象，主要用于打印管理等）
| 服務名 | 操作代碼 | 用途說明 |
|---|
N-EVENT-REPORT | 0x0100 | 報告事件（如打印完成） |
N-GET | 0x0110 | 獲取屬性信息 |
N-SET | 0x0120 | 設置屬性（如修改打印參數） |
N-ACTION | 0x0130 | 請求操作（如開始打印） |
N-CREATE | 0x0140 | 創建對象（如打印作業） |
N-DELETE | 0x0150 | 刪除對象 |
🧾 PDV Header Flags 字節說明
每個 PDV（Presentation Data Value） 的頭部包含一個 Flags 字節（1字節），用于指示數據性質：
| 位 | 含義 | 值為 1 時 | 備注 |
|---|
| bit 0 | 命令/數據集標識 | 表示這是一個命令（Command）；為0則為數據集（Data Set） | |
| bit 1 | 最后一個片段標識 | 表示這是該 PDV 的最后一個片段 | PDV 可能被分片 |
| bit 2-7 | 保留 | 固定為0 | 未來擴展位 |
示例：
| Flags 十六進制 | 說明 |
|---|
0x01 | 命令，未結束（中間片段） |
0x03 | 命令，最后片段 |
0x00 | 數據集，未結束 |
0x02 | 數據集，最后片段 |
🎯 完整結構梳理
| 層級 | 數據類型 | 說明 |
|---|
| PDU 層（ACSE） | P-DATA-TF | 類型值為 0x04，承載 PDV |
| 表示層（PDV） | Flags + 數據 | 表示是否是命令、數據及是否最后片段 |
| DIMSE 層 | 命令/數據集 | 解析 PDV 后進入執行（如 C-FIND 查詢） |
每個 DIMSE 服務對應的典型 SOP Class UID（服務對象類唯一標識符） 和實際應用場景。我們將從 DIMSE-C 和 DIMSE-N 兩大類出發，列成表格。
🧱 模塊三 DIMSE-C 服務類：SOP Class UID & 典型場景
| DIMSE 命令 | SOP Class 名稱 | SOP Class UID | 應用場景 |
|---|
C-ECHO | Verification SOP Class | 1.2.840.10008.1.1 | 檢查 DICOM 節點聯通性（Ping 測試） |
C-FIND | Modality Worklist Information Model – FIND | 1.2.840.10008.5.1.4.31 | Modalities 查詢待檢病人信息（從 RIS） |
C-FIND | Patient Root Query/Retrieve Information Model – FIND | 1.2.840.10008.5.1.4.1.2.1.1 | PACS 查詢病人級別影像信息 |
C-FIND | Study Root Query/Retrieve Information Model – FIND | 1.2.840.10008.5.1.4.1.2.2.1 | PACS 查詢檢查級影像信息 |
C-MOVE | Study Root Query/Retrieve Information Model – MOVE | 1.2.840.10008.5.1.4.1.2.2.2 | 從 PACS 將圖像“推送”到目標 AE |
C-GET | Study Root Query/Retrieve Information Model – GET | 1.2.840.10008.5.1.4.1.2.2.3 | 客戶端主動“拉取”圖像 |
C-STORE | CT Image Storage | 1.2.840.10008.5.1.4.1.1.2 | CT 圖像發送至 PACS |
C-STORE | MR Image Storage | 1.2.840.10008.5.1.4.1.1.4 | MR 圖像發送至 PACS |
C-STORE | Secondary Capture Image Storage | 1.2.840.10008.5.1.4.1.1.7 | 屏幕截圖或再處理圖像存儲 |
📝 說明：
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 命令 | SOP Class 名稱 | SOP Class UID | 應用場景 |
|---|
N-CREATE / N-SET / N-ACTION | Basic Film Session | 1.2.840.10008.5.1.1.1 | 打印系統：創建打印會話 |
N-CREATE / N-SET | Basic Film Box | 1.2.840.10008.5.1.1.2 | 打印系統：設置打印頁布局 |
N-CREATE / N-SET | Basic Grayscale Image Box | 1.2.840.10008.5.1.1.4 | 打印圖像 |
N-GET / N-DELETE | Print Job SOP Class | 1.2.840.10008.5.1.1.14 | 查詢或取消打印作業 |
N-EVENT-REPORT | Basic Film Session Event Reporting | 1.2.840.10008.5.1.1.40 | 打印完成等事件通知 |
📝 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 通訊涉及的完整流程
| 階段 | 協議元素 | 操作描述 |
|---|
| 1?? 連接建立 | A-ASSOCIATE-RQ | SCU（模態設備）發起連接請求，協商服務（如 Worklist SOP Class）和傳輸語法 |
| A-ASSOCIATE-AC | SCP（Worklist Server）返回確認接受連接 |
| 2?? 查詢發起 | P-DATA-TF（封裝 C-FIND-RQ） | SCU 發送 Worklist 查詢請求，封裝在 P-DATA-TF 中 |
| 3?? 查詢響應 | P-DATA-TF（封裝 C-FIND-RSP） | SCP 多次返回查詢結果（逐條或批量），每次包含狀態字段 |
| 4?? 查詢結束 | C-FIND-RSP（Status=0x0000） | 表示查詢結果已全部返回，結束 |
| 5?? 會話釋放 | A-RELEASE-RQ / A-RELEASE-RP | 通訊完成后主動釋放連接 |
🔁 流程圖概覽（通訊交互順序）
[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 包含協商內容：
| 字段 | 含義 |
|---|
| Called AE Title | 接收方 AE 標識（服務器） |
| Calling AE Title | 發送方 AE 標識（客戶端） |
| SOP Class UID | 通訊中使用的服務類（如：1.2.840.10008.5.1.4.31） |
| Transfer Syntax | 如：Implicit VR Little Endian、Explicit VR 等 |
| Presentation Context ID | 綁定 SOP Class + Transfer Syntax |
2?? C-FIND-RQ 包含查詢數據集（DataSet）
一個標準的 Worklist 查詢參數示例：
(PatientName, PN, “DOE^JOHN”)
(ScheduledProcedureStepStartDate, DA, “20250414”)
(Modality, CS, “CT”)
3?? C-FIND-RSP 包含：
| 字段 | 含義 |
|---|
| Command Field | C-FIND-RSP |
| Status | 0xFF00（匹配項）、0x0000（完成）、其他值（錯誤） |
| DataSet | 一項或多項匹配結果（病人、預約信息） |
🎯 四、Status 字段值說明（C-FIND-RSP）
| Status 值 | 含義 | 說明 |
|---|
0xFF00 | Pending | 匹配項返回中，后續還有結果 |
0xFF01 | Pending | 同上（備用代碼） |
0x0000 | Success | 所有結果已返回，正常結束 |
0xA700 | Refused | SCP 拒絕處理請求 |
0xA900 | Error | 請求參數錯誤或內部失敗 |
0xCxxx | Failed | 查詢失敗，具體錯誤由 x 標識 |
?典型場景回顧（應用于 Modalities 自動填充）
- CT 設備啟動時主動發起 Worklist 查詢；
- 查詢參數通常為當天日期；
- PACS 或 RIS 返回病人待檢查列表；
- 技術員選擇一條記錄，設備自動填充病人信息；
- 完善檢查項后進行采集、圖像發送等操作。
📘 模塊四 連接釋放的作用
在 DICOM 網絡通訊中，一個完整的會話由“建立 → 通訊 → 釋放”三階段構成：
| 階段 | 操作 | 功能 |
|---|
| 建立連接 | A-ASSOCIATE-RQ / AC | 建立 DICOM 連接 |
| 數據交換 | P-DATA-TF 封裝 DIMSE 命令 | 進行 C-FIND、C-STORE 等業務操作 |
| 釋放連接 | A-RELEASE-RQ / RP | 優雅關閉連接，釋放網絡和會話資源 |
📌 釋放連接并不是“強制斷開”，而是一種雙向確認的正常斷開過程。
🧱 A-RELEASE-RQ / RP 數據結構說明（簡化）
A-RELEASE-RQ（SCU 發起）
| 字段 | 值 |
|---|
| PDU Type | 0x05 |
| Reserved | 00 |
| Length | 固定值 4（或0） |
| Data | 空（無實際數據） |
A-RELEASE-RP（SCP 響應）
| 字段 | 值 |
|---|
| PDU Type | 0x06 |
| Reserved | 00 |
| Length | 固定值 4（或0） |
| Data | 空（無實際數據） |
🔁 釋放流程圖（時序）
[SCU] [SCP]| ||-- A-RELEASE-RQ --------------------->| ← 客戶端請求釋放連接|<-- A-RELEASE-RP ---------------------| ← 服務端確認釋放| ||----> 關閉 Socket ------------------->| ← 通訊資源釋放完成
🔍 為什么“釋放連接”是必須的？
| 原因 | 描述 |
|---|
| ? 協議規范要求 | 不釋放會話會被視為異常斷開，影響后續通訊 |
| ? 系統資源回收 | 每個連接都占用線程、緩沖區、Socket 等資源 |
| ? 日志清晰 | 正常釋放連接便于審計和問題追蹤 |
| ? 反面案例 | 強制斷開（如關閉Socket）可能導致遠端狀態不一致或掛起 |
🎯 釋放連接失敗的處理（異常處理建議）
| 場景 | 建議 |
|---|
| 網絡中斷時強制斷開 | 日志記錄 + 自動重連機制 |
| SCP 未響應 A-RELEASE-RP | 設置超時后斷開連接并釋放資源 |
| 出現異常前未釋放連接 | 加入 finally 或連接池釋放機制 |
? 總結：釋放連接在 DICOM 中的地位
- 是整個 ACSE 協議的重要組成；
- 是符合 DICOM 協議的“優雅斷開”；
- 必須在 SCU 或 SCP 完成所有 DIMSE 命令操作后再發起；
- 在調試網絡通訊時，如果發現連接懸掛不釋放，極可能是
A-RELEASE 環節未正確處理。
