编辑1：

Question

我的应用程序是Storage SCU。它将NM和CT实例推送到第三方PACS。我在我的协会（Associate Request）中提出了四个演示文稿上下文。 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表示上下文协商

℃。 Association-acceptor 可以接受或拒绝每个演示文稿背景单独。

查看规格中的可能。这是什么意思？是由SCP决定接受还是拒绝（或者按照[提议]的方式离开）＆＃34;状态？

Answer 1

＆＃34;建议＆＃34;意味着SCP没有在回复中包含具有正确代码的抽象语法：

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

因此，DCMTK在抽象语法中留下＆＃34;尚未协商的原始状态＆＃34; （打印为＆＃34;建议＆＃34;在日志中）。

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

看起来SCP应该归咎于此

DICOM：这是一个有效的员工响应吗？

编辑1：

1 个答案: