Storage Commitment 流程总览
约 727 字大约 2 分钟
PACSDICOMStorage Commitment实战
2026-03-20
Storage Commitment 的目标，不是“把文件发出去”这么简单，而是要求对端明确告诉你：这批对象已经被它可靠接收并纳入存储承诺流程。只有做到这一步，业务上才更适合把本地上传状态标记为完成。
1. 这组流程为什么值得单独拆开
单看命令层面，Storage Commitment 主要会涉及三块：
- 先通过 9.C-STORE 把对象发送给 PACS。
- 再通过 12.N-ACTION 发起存储承诺请求。
- 最后通过 13.N-EVENT-REPORT 接收承诺结果。
如果只看这三篇命令文档，能知道每条命令是什么，但还不够形成完整的工程流程。真正落地时，还要处理事务号、批次关联、状态回写、失败重试和结果审计。
2. 一条完整链路通常怎么走
一个常见的 Storage Commitment 流程可以拆成下面几步：
- 本地准备待发送的 DICOM 对象清单。
- 使用 C-STORE 把对象发送到 PACS。
- 记录本次上传批次、实例 UID 列表和时间戳。
- 使用 N-ACTION 针对这一批对象发起存储承诺请求。
- PACS 异步回发 N-EVENT-REPORT。
- 本地解析成功对象和失败对象，并回写业务状态。
这意味着它不是一次“单请求单响应”的简单调用，而是一条跨多个命令、可能跨多个进程的链路。
3. 工程上最容易漏掉的点
- 没有给上传批次分配唯一事务号，导致回报结果无法关联。
- 只记录了文件路径，没有记录 SOP Instance UID。
- 收到 N-EVENT-REPORT 后没有把成功列表和失败列表拆开处理。
- 认为 C-STORE 成功就等于存储承诺完成。
其中第 4 点是最常见误区。C-STORE 成功只能说明对象已经被对端接收，不能等同于“对端已经完成承诺并可安全删除本地副本”。
4. 这组实战文档建议怎么读
- 先看 15.发送影像并发起存储承诺.md，理解请求链路如何组织。
- 再看 16.接收承诺结果与状态回写.md，理解异步回报如何落地到业务系统。
5. 使用建议
- 把 Storage Commitment 当成一条完整业务流程，不要拆成互不相关的三个协议命令。
- 一开始就设计好批次号、事务号和对象 UID 的映射关系。
- 如果后续要做自动清理本地缓存，必须以承诺结果为准，而不是只看上传响应。