Meine Anwendung ist Storage SCU. Es überträgt NM- und CT-Instanzen an PACS von Drittanbietern. Ich schlage vier Präsentationskontexte in meiner Assoziation vor (Associate Request). PACS reagieren (assoziierte Response) wie unten:DICOM: Ist dies eine gültige 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

zweite und vierte (id 3 und 7) Präsentationskontext wie erwartet abgelehnt. Die PACS DICOM Conformance-Anweisung besagt, dass diese Übertragungssyntax nicht unterstützt wird.

Der erste (ID 1) Präsentationskontext wird wie erwartet akzeptiert.

Betrachten Sie dritten (ID 5) Präsentationskontext. Es ist Status sagt [Proposed].

In meinem Verständnis sollte PACS entweder den Präsentationskontext akzeptieren oder ablehnen. Es darf nicht den Status [Proposed] behalten, der von SCU gesetzt wurde, d. H. Meine Anwendung.

Ist mein Verständnis korrekt?
Ich schaue in Spezifikationen, um etwas abschließendes zu finden; bisher kein Erfolg. Bitte zeigen Sie mir den Ort in den Spezifikationen, wo dies erklärt wird.

Edit 1:

PS 3,7-2011 - Message Exchange
D.3.2 Präsentation Kontexten Verhandlung

c. der Association-Acceptor kann jeden Presentation Kontext einzeln akzeptieren oder ablehnen.

Schauen Sie sich die können in Spezifikationen. Was bedeutet das? Ist es Sache des SCP, den Status "zu akzeptieren oder abzulehnen (oder zu belassen, d. H. [Vorgeschlagen])"?

Quelle

2017-03-23 Amit Joshi

schuld Der "vorgeschlagen" Code nicht einmal im Standard: 0 - Akzeptanz 1 - benutzer Ablehnung 2 - no-Grund (Anbieter Ablehnung) 3 - abstract-Syntax-nicht-unterstützt (Provider-Ablehnung) 4 - Transfer-Syntaxe-nicht unterstützt (Provider-Ablehnung) –

Durch Überprüfung des Quellcodes in DCMTK sieht es so aus, als ob dieser Wert beim SCP gesetzt ist akzeptiert oder lehnt die abstrakte Syntax nicht ab (sie enthält sie nicht in der Antwort). Nach diesem http://dicom.nema.org/medical/Dicom/2016a/output/chtml/part08/chapter_7.html#sect_7.1.1.14 scheint es, als ob der SCP nicht korrekt antwortet (alle vorgeschlagenen abstrakten Syntaxen sollten sein entweder accepter oder zurückgewiesen) –

Nur zur Klarstellung, für DCMTK bedeutet "vorgeschlagen" "noch nicht ausgehandelt" (suchen Sie im DCMTK-Quellcode nach ASC_P_NOTYETNEGOTIATED) –

"Vorgeschlagen" bedeutet, dass der SCP nicht die abstrakte Syntax mit dem richtigen Code in der Antwort enthalten war:

0 Akzeptanz
1 Benutzer-Ablehnung
2 no-reason (Anbieter Abstoßung)
3 Abstrakt-Syntax-not-unterstützte (Anbieter Abstoßung)
4 Transfer-Syntaxen-nicht-unterstützte (Anbieter Abstoßung)

Daher hinterlässt DCMTK in der abstrakten Syntax den ursprünglichen Status "Noch nicht ausgehandelt" (gedruckt als "vorgeschlagen" in den Protokollen).

In DCMTK wird dieser Status durch die Konstante ASC_P_NOTYETNEGOTIATED repräsentiert.

Es sieht aus wie der SCP hier

Quelle

2017-03-23 15:02:00

DICOM: Ist dies eine gültige Associate Response?

Edit 1:

Antwort

Verwandte Themen