接收承诺结果与状态回写
约 742 字大约 2 分钟
PACSDICOMStorage CommitmentN-EVENT-REPORT
2026-03-20
Storage Commitment 真正难的部分，通常不在“发请求”，而在“收结果”。因为 N-EVENT-REPORT 往往是异步到达的，你需要把它和之前的上传批次正确关联，并且把结果稳定地回写到本地业务状态。
1. 本地接收端要承担什么职责
要接住承诺结果，本地通常需要准备一个能够处理 13.N-EVENT-REPORT 的服务端入口。这个入口至少要完成：
- 接收事件通知。
- 解析成功对象列表。
- 解析失败对象列表。
- 根据事务号或对象 UID 关联本地批次。
- 回写业务状态并记录审计日志。
2. 结果回写不要只存一个“成功/失败”
比较稳妥的做法，是把承诺结果拆成多个层次：
- 批次级状态，例如
Pending、PartiallyCommitted、Committed、Failed。 - 对象级状态，记录每个 SOP Instance UID 是否承诺成功。
- 通知级原始报文或摘要，方便事后审计。
如果只保留一个批次级布尔值，后续排查“为什么只有部分对象失败”会非常困难。
3. 一个典型的处理流程
收到 N-EVENT-REPORT 后，可以按下面顺序处理：
- 校验请求来源和 AE Title。
- 提取事务号或可关联字段。
- 解析成功 Sequence 和失败 Sequence。
- 更新对象级状态。
- 汇总并更新批次级状态。
- 写入日志并返回协议响应。
如果批次不存在，或者对象列表对不上，也不要直接吞掉，应该明确记录异常情况。
4. 回写策略建议
- 先写对象级结果，再汇总批次状态。
- 对失败对象单独记录失败原因或状态码。
- 对超时未收到回报的批次，设计补偿扫描或人工复核流程。
- 如果后续要删除本地文件，必须以对象级承诺成功为准。
5. 和前面两步的关系
如果前面没有做好事务号和对象 UID 记录，这一步通常会变得很被动。所以这组实战文档应该连起来看：
6. 使用建议
- 不要把 N-EVENT-REPORT 只当成“收到一条通知”，而要把它视为更新业务事实状态的关键输入。
- 联调阶段尽量保留原始报文或关键字段快照，后续排查会轻松很多。
- 如果系统并发上传批次很多，务必建立稳定的事务关联键，而不是用时间猜测匹配关系。