发送影像并发起存储承诺
约 661 字大约 2 分钟
PACSDICOMStorage CommitmentC-STORE
2026-03-20
Storage Commitment 的前半段，核心就是两步：先发影像，再发承诺请求。顺序不能颠倒，因为 N-ACTION 的本质是让对端针对“已经接收的一批对象”执行承诺动作。
1. 发送前先准备什么
在进入 C-STORE 之前，建议先准备好本次事务上下文：
- 事务号或批次号。
- 本次待发送的 SOP Instance UID 列表。
- 目标 PACS 节点信息。
- 本地回调接收端信息，用于后续接收 N-EVENT-REPORT。
如果这些信息在开始时就没有落表，后面通常很难把回报结果和上传批次对上。
2. 第一步：发送影像
先用 9.C-STORE 把影像对象发送到 PACS：
foreach (var filePath in dicomFiles)
{
var request = new DicomCStoreRequest(filePath);
await client.AddRequestAsync(request);
}
await client.SendAsync();工程上更关键的不是这几行代码本身，而是发送完成后要把“哪些对象发送成功”记录下来。最少建议记录：
- 批次号。
- SOP Instance UID。
- 发送时间。
- C-STORE 响应状态。
3. 第二步：构建存储承诺请求
在对象发送完成后，再通过 12.N-ACTION 发起 Storage Commitment 请求。常见做法是把刚才成功发送的实例 UID 列表放进动作数据集：
var request = new DicomNActionRequest(
storageCommitmentPushModelSopClassUid,
transactionSopInstanceUid,
actionTypeId: 1);
request.Dataset = actionDataset;
await client.AddRequestAsync(request);
await client.SendAsync();这里的关键点不在于代码长什么样，而在于 actionDataset 里必须携带足够的信息，让 PACS 知道你请求承诺的是哪一批对象。
4. 动作数据集一般要包含什么
不同实现会有差异，但至少应围绕下面两类信息组织：
- 本次事务标识。
- 需要承诺的 Referenced SOP Sequence。
如果没有事务标识，本地往往只能靠时间窗口去猜哪条 N-EVENT-REPORT 属于哪次上传，这在并发场景下很不可靠。
5. 发送端的落地建议
- 把“上传完成”和“承诺完成”分成两个状态字段。
- N-ACTION 发出后，不要立刻删除本地文件。
- 对每个批次保留可追踪日志，至少包括批次号、实例 UID 数量和请求时间。
- 如果目标 PACS 不支持 Storage Commitment，要在能力探测或配置层提前暴露出来。
6. 下一步
N-ACTION 发出后，真正决定业务状态的，是后续收到的 16.接收承诺结果与状态回写.md。