DICOM：这是有效的关联响应吗？

Question

我的应用程序是 Storage SCU。它将 NM 和 CT 实例推送到第三方 PACS。我在我的协会（协会请求）中提出了四个演示文稿上下文。 PACS 正在响应（Associate Response），如下所示：

Application Context:     DICOM Application Context Name
Implementation Class:    1.2........
Implementation Version:  XYZ
Maximum PDU Size:        32768
Called AE Title:         PACS
Calling AE Title:        MyApp
Presentation Contexts:   4
  Presentation Context:  1 [Accept]
      Abstract:  Nuclear Medicine Image Storage
      Transfer:  Explicit VR Little Endian
  Presentation Context:  3 [Reject - Transfer Syntaxes Not Supported]
      Abstract:  Nuclear Medicine Image Storage
      Transfer:  JPEG 2000 Lossy
  Presentation Context:  5 [Proposed]
      Abstract:  CT Image Storage
      Transfer:  Explicit VR Little Endian
  Presentation Context:  7 [Reject - Transfer Syntaxes Not Supported]
      Abstract:  CT Image Storage
      Transfer:  JPEG 2000 Lossy

第二个和第四个（id 3 和 7）表示上下文按预期被拒绝。 PACS DICOM 一致性声明指出它不支持该传输语法。

第一个 (id 1) 表示上下文按预期被接受。

查看第三个 (id 5) 演示上下文。它的状态显示 [Proposed].

根据我的理解，PACS 应该接受演示文稿上下文或拒绝它。它不能保持 SCU 设置的状态 [Proposed]，即我的应用程序。

我的理解正确吗？
我正在查看规格以找到结论；到目前为止没有成功。请指出规范中对此进行解释的位置。

编辑 1：

PS 3.7-2011 - 消息交换
D.3.2 表示上下文协商

c. the Association-acceptor may accept or reject each Presentation Context individually.

查看规格中的可能。这是什么意思？是否由 SCP 决定“接受或拒绝（或保持原样，即 [提议]）”状态？

Answer 1

"Proposed" 表示 SCP 没有在回复中包含带有正确代码的抽象语法：

0 接受
1 次用户拒绝
2无理由（供应商拒绝）
3 不支持抽象语法（提供者拒绝）
4 transfer-syntaxes-not-supported（供应商拒绝）

因此 DCMTK 在抽象语法中留下 "Not yet negotiated" 的原始状态（在日志中打印为 "proposed"）。

在 DCMTK 中，此状态由常量 ASC_P_NOTYETNEGOTIATED 表示。

看来 SCP 是罪魁祸首

DICOM：这是有效的关联响应吗？

DICOM : Is this a valid Associate Response?

dicom

编辑 1：