Ultraschall-Abfrage funktioniert, aber Abruf schlägt fehl: Die separate C-MOVE-Verbindung nachverfolgen

Warum kann die Abfrage erfolgreich sein, während jeder Abruf fehlschlägt?

Wenige Netzwerksymptome verwirren Serviceteams mehr als ein Ultraschallsystem, das das Picture Archiving and Communication System (PACS) des Krankenhauses fehlerfrei durchsuchen kann, aber jedes Mal fehlschlägt, wenn ein Sonograf versucht, eine Voruntersuchung abzurufen. Die Konsole listet die Untersuchungen des Patienten auf, der Bediener wählt eine aus und drückt auf Retrieve, und nach einer Pause meldet das System einen allgemeinen Übertragungs- oder Abruffehler. Der genaue Wortlaut variiert je nach Hersteller und Softwareversion.

Die intuitive Annahme ist, dass die Netzwerkkonnektivität symmetrisch ist: Wenn der Scanner das Archiv durchsuchen kann, funktioniert die Pipeline, sodass ein Abruffehler einen internen Scannerfehler, eine beschädigte Softwareoption oder eine fehlerhafte Netzwerk-Ein-/Ausgabeplatine (I/O) bedeuten muss. Für den DICOM-Abruf (Digital Imaging and Communications in Medicine) über C-MOVE ist diese Annahme falsch. Abfrage und Abruf verwenden unterschiedliche Operationen und bei C-MOVE unterschiedliche Netzwerkassoziationen, die in entgegengesetzten Richtungen geöffnet werden. ^{1 5}

Wenn ein Ultraschallsystem eine Abfrage durchführt, fungiert es als Service Class User (SCU) der Query/Retrieve Service Class und verwendet die C-FIND-Operation. ⁹ Der Scanner öffnet eine TCP-Verbindung zur konfigurierten IP-Adresse und zum Listening-Port des Archivs. Port 104 ist der bekannte DICOM-Port, Ports werden jedoch standortspezifisch konfiguriert; bei der unten zitierten Philips-Familie ist der Listening-Port standardmäßig 104 und ändert sich zu 2762, wenn Secure DICOM aktiviert ist. ³ Der Scanner fordert eine Assoziation unter Verwendung seines eigenen (Calling-)AE-Titles und des (Called-)AE-Titles des Archivs an, sendet die C-FIND-Anforderung mit Suchschlüsseln wie Patienten-ID, Name oder Untersuchungsdatum und empfängt die Treffer über dieselbe Assoziation.

Wenn der Sonograf auf Retrieve drückt, lädt der Scanner keine Dateien über diese Assoziation herunter. Er sendet eine C-MOVE-Anforderung, in der das Archiv aufgefordert wird, die ausgewählten Instanzen an einen benannten Move Destination AE Title zu übermitteln. DICOM PS3.4 Abschnitt C.4.2 besagt, dass die C-STORE-Unteroperationen „stets über eine Assoziation ausgeführt werden müssen, die sich von der Assoziation unterscheidet, die die C-MOVE-Operation ausführt“, wobei der Query/Retrieve-SCP als Storage-SCU fungiert. ¹

Der Grund findet sich im selben Abschnitt: Die Application Entity, die die gespeicherten Instanzen empfängt, „kann der Urheber der C-MOVE-Operation sein oder auch nicht.“ C-MOVE ist so konzipiert, dass ein Anforderer eine Studie an ein Drittsystem senden kann, beispielsweise an eine Review-Workstation. Aus diesem Grund öffnet das Archiv und nicht der Anforderer die Übertragungsverbindung, selbst wenn der Scanner anfordert, dass die Bilder an ihn selbst zurückgesendet werden. ¹

Eine erfolgreiche Abfrage beweist somit nur, dass der Scanner den Listening-Port des Archivs erreichen kann. Sie beweist nicht, dass der Rückweg vom Archiv zurück zum Listening-Port des Ziels konfiguriert ist, von Firewalls zugelassen wird oder vom DICOM-Empfänger des Scanners akzeptiert wird. Bevor Sie einen Hardwarefehler vermuten, trennen Sie scannerseitige Speicherungsfehler von Fehlern in Abrufrichtung, indem Sie jede Assoziation separat nachverfolgen.

Was sind die drei Endpunkte und zwei Assoziationen bei einem Ultraschall-Abruf?

Um einen C-MOVE-Fehler präzise zu diagnostizieren, muss ein Ingenieur erkennen, dass ein DICOM-Abruf drei unterschiedliche logische Endpunkte und zwei unabhängige Netzwerkassoziationen umfasst, selbst wenn das Ultraschallsystem anfordert, dass Bilder an es selbst übermittelt werden. DICOM PS3.4 Abschnitt C.4.2 definiert diese Rollen mit technischer Präzision: ¹

• Anfordernder SCU (Ultraschallkonsole): Das System, das die Assoziation 1 zum Archiv initiiert, C-FIND-Abfrageanforderungen stellt und den C-MOVE-Abrufbefehl ausgibt. Es identifiziert, welche Studien, Serien oder Instanzen übertragen werden sollen, und bestimmt den Move Destination AE Title.
• Query/Retrieve-SCP (PACS-Archiv oder VNA): akzeptiert Assoziation 1, gleicht die Abfrage ab, empfängt das C-MOVE, schlägt den Move-Destination-AE-Title in der eigenen Konfiguration nach und fungiert als Storage-SCU, um die Instanzen zu senden.
• Move Destination (Storage-SCP): der in der C-MOVE-Anforderung benannte Knoten, der die Bilder empfangen soll. Häufig ist dies derselbe Scanner, der die Anfrage gestellt hat, doch der Standard erlaubt jeden beliebigen Speicherknoten, wie etwa eine Befund-Workstation. Bei der hier zitierten Philips-Familie benennt der Scanner seinen eigenen AE-Title als Ziel. ^{1 3 5}

Da die Move Destination ein Drittanbieter-Knoten sein kann, wurde das C-MOVE-Protokoll bewusst so ausgelegt, dass das Archiv die Zustellungsverbindung initiiert. Dadurch entstehen zwei getrennte Netzwerkassoziationen mit entgegengesetzten Verbindungsrichtungen:

Assoziation 1 (Vorwärts-Anforderungsassoziation): Wird von der Ultraschall-SCU zum PACS-Q/R-SCP initiiert. Diese Assoziation übernimmt den A-ASSOCIATE-Handshake, den C-FIND-Abfrageaustausch, die C-MOVE-Anforderung, periodische C-MOVE-Pending-Statusantworten und die finale C-MOVE-Abschlussantwort. Schlägt diese Assoziation fehl, kann das Ultraschallsystem weder nach Patienten suchen noch den anfänglichen Abrufbefehl senden.

Assoziation 2 (rückwärtige Speicherassoziation): Wird vom Archiv, das als Storage-SCU fungiert, zur Move Destination, die als Storage-SCP fungiert, geöffnet, nachdem das Archiv die C-MOVE-Anforderung empfangen hat. Sie überträgt eine C-STORE-Anforderung pro Instanz, ob Einzelbild, Cine-Sequenz oder Structured Report. Kann diese Assoziation nicht geöffnet werden, wird sie durch eine Firewall blockiert oder vom Empfänger abgelehnt, schlagen die Teiloperationen fehl, während Assoziation 1 weiterhin funktioniert. ^{1 2 6}

PS3.2 Anhang F veranschaulicht dieselbe Aufteilung in einer informativen Beispiel-Konformitätserklärung für einen fiktiven Query/Retrieve-Server. Dort wird die Application Entity QUERY-RETRIEVE-SCP „niemals Assoziationen initiieren“; bei einem C-MOVE weist sie eine separate Application Entity STORAGE-SCU an, „eine Assoziation mit der Destination DICOM AE zu initiieren“. Deren Tabelle F.4.2-8 zeigt, dass ein Timeout, ein Abbruch oder ein Socket-Verlust auf dieser Zustellungsassoziation zurückgemeldet und ein entsprechender Status in der C-MOVE-Antwort übermittelt wird. Reale Produkte implementieren dies unterschiedlich, doch die Richtung der zweiten Verbindung ist dieselbe. ²

Was sagt Ihnen die finale C-MOVE-Antwort tatsächlich?

Die meisten Konsolen zeigen nur ein kurzes Pop-up an, wenn ein Abruf fehlschlägt. Nützlichere Anhaltspunkte finden sich in der über Assoziation 1 zurückgegebenen C-MOVE-Antwort, die gewöhnlich im DICOM-Protokoll des Archivs und manchmal im Service-Protokoll des Scanners einsehbar ist. PS3.4 Tabelle C.4-2 führt die C-MOVE-Status unter Failure (abgelehnt, Fehler oder Verarbeitung nicht möglich), Cancel, Warning, Success und Pending auf. ¹

PS3.4 definiert zudem Zählattribute für Teiloperationen. Pending-Antworten müssen diese enthalten. Finale Antworten können einige davon enthalten, sodass ein fehlender Zähler für sich genommen kein Fehler ist:

• Number of Remaining Sub-operations (0000,1020): noch zu sendende Instanzen. Erforderlich in Pending-Antworten, optional bei Cancel und nicht enthalten in Warning-, Failure- oder Success-Antworten.
• Number of Completed Sub-operations (0000,1021): C-STORE-Teiloperationen, die erfolgreich abgeschlossen wurden. Erforderlich in Pending-Antworten, optional in finalen Antworten.
• Number of Failed Sub-operations (0000,1022): C-STORE-Teiloperationen, die fehlgeschlagen sind. Erforderlich in Pending-Antworten, optional in finalen Antworten.
• Number of Warning Sub-operations (0000,1023): Teiloperationen, die mit einem Warning-Status endeten.
• Failed SOP Instance UID List (0008,0058): in Cancel-, Failure- oder Warning-Antworten die Bezeichner der Instanzen, deren C-STORE fehlschlug. Fehlt, wenn keine Teiloperation fehlgeschlagen ist. ¹

Lesen Sie Status und Zähler zusammen. Ein Fehlschlag mit null abgeschlossenen und ausnahmslos fehlgeschlagenen Instanzen bedeutet, dass nichts übertragen wurde. Dies deutet meist auf die Assoziation selbst hin, doch kann ein Archiv dasselbe Muster erzeugen, wenn das Ziel jeden Objekttyp ablehnt. Liegen die Werte für Completed und Failed beide über null, bedeutet dies, dass der Rückweg für zumindest einige Instanzen funktioniert und das Problem bei bestimmten Objekten, Kodierungen oder Zielressourcen liegt. Die Zähler grenzen die Suche ein; das Protokoll des Archivs zeigt die Ursache. ^{1 5}

Die Failed SOP Instance UID List (0008,0058) ist nach dem Status oft das nützlichste Attribut. Vergleichen Sie bei einer Teilübertragung die fehlgeschlagenen UIDs mit dem Archiveintrag jedes Objekts. Wenn jedes fehlgeschlagene Element ein Multiframe-Cine-Clip ist, während Einzelbildaufnahmen angekommen sind, ist eine Nichtübereinstimmung bei Transfer-Syntax oder Presentation Context ein starker Kandidat. Bestätigen Sie dies im Assoziationsprotokoll des Archivs, bevor Sie Änderungen vornehmen.

Was kennzeichnet „Refused: Move Destination unknown“ (A801)?

Der Status A801 (Refused: Move Destination unknown) ist einer der spezifischsten Codes, die Sie erhalten können, und eine neutrale PACS-Schulungslektion beschreibt ein unbekanntes Ziel als die häufigste Ursache fehlgeschlagener Move-Vorgänge. Er bedeutet, dass das Archiv den als Ziel angegebenen AE-Title nicht auflösen konnte. ^{1 4 5}

Die C-MOVE-Anforderung enthält das Ziel ausschließlich als AE-Title im Feld Move Destination (0000,0600), ohne IP-Adresse oder Port. ¹ Das Archiv muss diesen AE-Title anhand seiner eigenen Konfiguration in eine Adresse und einen Port übersetzen. Medical Connections, ein Anbieter von DICOM-Toolkits, merkt an, dass, so umständlich dies auch erscheinen mag, „von DICOM keine Alternative zugelassen wird“. ⁶

Findet das Archiv keinen passenden Eintrag, hat es keine Adresse für einen Verbindungsaufbau und lehnt die Anforderung mit A801 ab. Es werden keine Teiloperationen versucht. PS3.4 führt für diesen Status als zugehöriges Feld lediglich einen Fehlerkommentar auf; erwarten Sie daher keine aussagekräftigen Zähler für Teiloperationen. ^{1 4}

Zu den häufigen klinischen Ursachen für den Status A801 gehören:

• Neuer oder neu aufgesetzter Scanner: Der Scanner wurde für das Senden von Studien an das PACS konfiguriert, aber niemand hat dessen AE-Title, IP-Adresse und Port als Abrufziel im Archiv hinzugefügt.
• Abweichung der exakten Zeichenkette: Ein AE-Title umfasst höchstens 16 Zeichen, und PS3.5 behandelt führende sowie nachgestellte Leerzeichen als nicht signifikant. ¹² Eingebettete Zeichen sind dennoch relevant. Vergleichen Sie die Zeichenketten Zeichen für Zeichen, einschließlich Groß- und Kleinschreibung, Unterstrichen im Vergleich zu Bindestrichen sowie dem Buchstaben O gegenüber der Ziffer Null, anstatt davon auszugehen, dass eines der Systeme diese normalisiert.
• Unterschiedliche AE-Titles für Senden und Empfangen: Einige Systeme ermöglichen es der Konsole, beim Speichern einen AE-Title zu verwenden und einen anderen als ihr Abrufziel anzugeben. Wenn nur der Sende-Title im Archiv registriert ist, ist der Ziel-Title unbekannt.
• Falsches Ziel am Scanner eingegeben: Die Konsole gibt ein Ziel an, das von dem Datensatz abweicht, den der PACS-Administrator angelegt hat. In diesem Fall liegt die Korrektur aufseiten des Scanners, unter Änderungskontrolle.

Ein A801 gibt keinen Anlass, Netzwerk-Hardware auszutauschen oder Switch-Ports zu wechseln. Die Lösung besteht darin, dafür zu sorgen, dass der vom Scanner gesendete Ziel-AE-Title mit einem Knoteneintrag im Archiv übereinstimmt, der die aktuelle IP-Adresse und den Listening-Port des Scanners enthält. Der Archiveintrag fällt in den Zuständigkeitsbereich des PACS-Administrators; die eigene Zieleinstellung des Scanners liegt in der Verantwortung desjenigen, der den Scanner wartet.

Was bedeutet es, wenn das Ziel die Assoziation des Archivs ablehnt?

Wenn das Archiv das Ziel auflöst, versucht es, Assoziation 2 zu dieser IP-Adresse und diesem Port zu öffnen. Wie hierbei ein Fehler gemeldet wird, hängt von der Implementierung ab. Das Datenmanagementsystem Canon HCBA-01 dokumentiert beispielsweise A702, wenn „C-STORE-Teiloperationen aufgrund des Fehlschlagens einer Assoziationsanforderung oder einer C-STORE-Anforderung nicht durchgeführt werden können“. Andere Archive verwenden möglicherweise einen anderen Status; gleichen Sie den Code daher mit dem eigenen Conformance Statement dieses Archivs ab. ⁴

Ein Fehlschlag in dieser Phase unterteilt sich in zwei unterschiedliche technische Szenarien: Blockierung des Netzwerktransports und Assoziationsablehnung auf Anwendungsebene.

1. Blockierung des Netzwerktransports (TCP-Verbindungsverweigerung): Der PACS-Server versucht, ein TCP-SYN-Paket an die IP-Adresse des Ultraschallsystems auf dessen konfiguriertem Listening-Port zu senden, empfängt jedoch entweder ein TCP-RST (Verbindung abgelehnt) oder überhaupt keine Antwort (SYN-Timeout). Dies tritt auf, wenn:

• Der DICOM-Listener-Dienst des Ultraschallscanners ist in der Software gestoppt oder deaktiviert.
• Eine Host-Firewall auf der Konsole, sofern die Plattform über eine solche verfügt, blockiert eingehende Verbindungen auf dem Listening-Port.
• Netzwerk-Firewalls auf Abteilungsebene oder Zugriffskontrolllisten (ACLs) virtueller lokaler Netzwerke (VLANs) erlauben ausgehenden Datenverkehr von medizinischen Modalitäten zum PACS, blockieren jedoch eingehenden Datenverkehr, der vom Serverraum zurück zu klinischen Ultraschallwagen initiiert wird. ⁵

2. Assoziationsablehnung auf Anwendungsebene (A-ASSOCIATE-RJ): Die TCP-Verbindung ist erfolgreich, das Ziel lehnt die DICOM-Assoziation jedoch ab. Philips dokumentiert dies als den Mechanismus, bei dem die Abfrage funktioniert, das Abrufen jedoch fehlschlägt, für die Familie EPIQ Elite, Elite Advanced, E7, E5, CVx, CVxi und Affiniti 70/50/30 Release 6.0.x (000737000000163 Rev A, Abschnitt 4.1.2.1): ³

„Auf dem Ultraschallsystem muss ein zweites ‚DICOM Storage Server‘-Gerät verwendet werden, um den sendenden AE-Title des Servers für die C-Store-Assoziation hinzuzufügen, die durch die an den Query-Retrieve-Server gesendete C-Move-Anforderung initiiert wird. Ohne dieses zweite Gerät ist die Abfrage erfolgreich, das Abrufen schlägt jedoch fehl, da das Ultraschallsystem jede Assoziationsanforderung von einem ‚unbekannten‘ AE-Title ablehnt.“— Philips EPIQ/Affiniti Release 6.0.x DICOM Conformance Statement, 000737000000163 Rev A, Abschnitt 4.1.2.1 (Schreibweise wie in der Quelle)

Der Konfigurationsabschnitt desselben Dokuments ergänzt zwei Details, die beim Service von Bedeutung sind. Erstens wird das Archiv für den C-STORE „üblicherweise einen anderen AE-Title verwenden“ als den, den der Scanner abfragt, sodass der Scanner einen zusätzlichen Storage-Device-Eintrag mit diesem sendenden AE-Title und der IP-Adresse oder dem Hostnamen des Archivs benötigt. Zweitens erklärt Philips, da das Archiv von keinem festen Port aus sendet, dass ein Platzhalter-Port wie etwa 9999 eingegeben werden kann und zu erwarten ist, dass die automatische Verifizierung nach dem Speichern dieses Eintrags fehlschlägt; „Das ist kein Fehler.“ Für unaufgeforderte Pushes verlangt das Dokument ebenfalls, dass der AE-Title und die IP-Adresse des Senders im Voraus konfiguriert werden. ³

Bei dieser Familie akzeptiert der Scanner bis zu fünf gleichzeitige Speicherassoziationen (Tabelle 4.4), ein Wert, den die Konfigurationstabelle als nicht konfigurierbar aufführt. Wenn ein Archiv mehr parallele Übertragungsassoziationen zu einem Ziel öffnet, als das Ziel akzeptiert, können die überzähligen Assoziationen abgewiesen werden; vergleichen Sie daher die Parallelitätseinstellung des Archivs pro Ziel mit dem dokumentierten Grenzwert des Ziels. Gehen Sie nicht davon aus, dass dieser Grenzwert für andere Modelle oder Releases gilt. ³

Bei derselben Familie ist Query/Retrieve eine Option: In der Fußnote der Übersicht heißt es: „Erfordert Option ‚Ultrasound Query Retrieve‘ oder ‚Multi-Modality Query Retrieve‘“. Vergewissern Sie sich, dass die Option auf genau diesem System vorhanden ist, bevor Sie mit der Fehlersuche im Netzwerk beginnen, insbesondere nach einer Software-Neuinstallation oder bei einem gebrauchten System, dessen Optionen von der ursprünglichen Bestellung abweichen können. ³

Dekodierung der Assoziationsabweisung: PDU-Telemetrie und Diagnosecodes

Wenn Assoziation 2 abgewiesen wird, zeigt ein Paketmitschnitt oder Archivprotokoll, wie. DICOM PS3.8 Abschnitt 9.3.4 definiert die A-ASSOCIATE-RJ-PDU, die Ein-Byte-Felder für Result, Source und Reason/Diag. enthält. ¹¹

Das Verständnis dieser Diagnosecodes verhindert einen unnötigen Hardwareaustausch, indem es Abweisungen aufgrund von Sicherheitsrichtlinien von Fehlern beim Netzwerktransport unterscheidet:

• Result: 1 ist rejected-permanent; 2 ist rejected-transient. ¹¹
• Source: 1 ist der DICOM-UL-Service-User (die empfangende Anwendung); 2 ist der UL-Service-Provider (ACSE-bezogene Funktion); 3 ist der UL-Service-Provider (präsentationsbezogene Funktion).
• Reason/Diag.: Bei Source 1 steht 1 für no-reason-given, 2 für application-context-name-not-supported, 3 für calling-AE-title-not-recognized und 7 für called-AE-title-not-recognized. Bei Source 3 steht 1 für temporary-congestion und 2 für local-limit-exceeded. ¹¹

Eine Abweisung mit Source 1 und Reason 3 (calling-AE-title-not-recognized) ist ein starker Beleg dafür, dass der TCP-Pfad funktioniert und die Zielanwendung den Calling-AE-Title des Archivs abgewiesen hat. Ob ein bestimmter Scanner genau diesen Ursachencode oder einen weniger spezifischen sendet, hängt von seiner Implementierung ab; lesen Sie den Code daher aus dem Paketmitschnitt oder Protokoll ab. In jedem Fall wird ein Austausch von Netzwerkkarten oder Kabeln das Problem nicht beheben.

Andere Ultraschallplattformen: Lesen Sie das Conformance Statement des jeweiligen Releases

Die obigen Angaben zu Philips gelten spezifisch für eine dokumentierte Release-Familie. Andere Hersteller und Releases konfigurieren Query/Retrieve, akzeptierte Gegenstellen und Listening-Ports auf ihre eigene Weise, und dieser Leitfaden überträgt Menüs oder Fehlermeldungen eines Systems nicht verallgemeinernd auf ein anderes. Beschaffen Sie sich für jeden anderen Scanner das DICOM Conformance Statement für das genaue Modell und das jeweilige Software-Release und prüfen Sie folgende Punkte:

• Optionsstatus: ob Query/Retrieve zum Standardumfang gehört oder eine lizenzierte Option ist.
• Zielidentität: welchen AE Title der Scanner als Move Destination benennt und ob dieser von dem beim Speichern verwendeten AE Title abweichen kann.
• Akzeptierte Gegenstellen: ob Speicher-Sender nach AE Title, IP-Adresse oder beidem vorab registriert sein müssen.
• Listening-Port und Sicherheit: der Standardport und der konfigurierbare Port sowie die Frage, ob ein TLS-Modus (Secure DICOM) diesen ändert.
• Assoziationsgrenzen: wie viele gleichzeitige Speicherassoziationen der Scanner akzeptiert.
• Akzeptierte Objekte: die SOP-Klassen und Transfer-Syntaxen, die der Scanner als Storage SCP akzeptiert.

Wenn das Conformance Statement einen Punkt nicht beantwortet, erfassen Sie ihn als unbekannt und fragen Sie beim Servicekanal des Herstellers nach. Füllen Sie die Lücke nicht mit Annahmen von einer anderen Marke.

Wann ist die Anfrage selbst fehlerhaft (A900- und Level-Fehler)?

Nicht alle C-MOVE-Fehler werden durch Konnektivitäts- oder Routing-Probleme verursacht. Wenn das Archiv den Status A900 zurückgibt, liegt der Fehler in der Struktur der C-MOVE-Anforderung selbst. DICOM PS3.4 Abschnitt C.4.2 Tabelle C.4-2 definiert den Status A900 als „Error: Data Set does not match SOP Class“. Die Conformance-Erklärung des Canon HCBA-01 (Tabelle 4.2-30) bezeichnet ihn als „Identifier does not match SOP Class“. ^{1 4}

Eine C-MOVE-Anforderung enthält einen Identifier-Datensatz, der das Abfrage-Informationsmodell und die Zielinstanzen spezifiziert. Der Status A900 tritt auf, wenn dieser Identifier gegen die normativen Regeln der Query/Retrieve Service Class verstößt:

• Fehlendes QueryRetrieveLevel (0008,0052): Der Anforderungs-Identifier muss die hierarchische Ebene des Abrufs angeben: PATIENT, STUDY, SERIES oder IMAGE. Wird dieses Attribut ausgelassen oder enthält es eine nicht unterstützte Zeichenkette, weist das Archiv den Befehl zurück. ¹
• Fehlende erforderliche eindeutige Schlüssel: Im Study-Root-Modell erfordert ein Abruf auf STUDY-Ebene die Study Instance UID (0020,000D); ein Abruf auf SERIES-Ebene erfordert zusätzlich die Series Instance UID (0020,000E), und ein Abruf auf IMAGE-Ebene erfordert darüber hinaus die SOP Instance UID (0008,0018). ¹
• Nichtübereinstimmung des Informationsmodells: Der Identifier passt nicht zu dem für C-MOVE ausgehandelten Informationsmodell, beispielsweise wenn für Study Root erstellte Schlüssel in einem Patient-Root-Kontext gesendet werden.
• Mehrdeutigkeit der Patienten-ID: PS3.4 weist darauf hin, dass der Aussteller der Patienten-ID in einer C-MOVE-Anforderung implizit ist – mit „keiner Vorkehrung zur Übermittlung des Issuer of Patient ID“ – und dass „ein Abruf auf STUDY-Ebene anstelle eines Abrufs auf PATIENT-Ebene verwendet werden sollte“, wenn die Patienten-ID mehrdeutig sein kann. Zu standortübergreifenden Identitätsproblemen siehe wenn dieselbe Patienten-ID unter zwei Ausstellern existiert. ¹

Verwechseln Sie Modality Worklist nicht mit Query/Retrieve. Die Worklist nutzt C-FIND gegenüber einer Terminplanungsquelle, um die Aufträge des aktuellen Tages abzurufen; Query/Retrieve durchsucht ein Bildarchiv nach abgeschlossenen Studien. Ein Scanner kann seine Worklist fehlerfrei empfangen und dennoch bei jedem Abruf fehlschlagen, da die beiden Dienste häufig auf unterschiedlichen Hosts mit verschiedenen AE-Titeln laufen. Halten Sie den Worklist-Status während der Untersuchung getrennt von Archiv-Query/Retrieve.

Warum kamen einige Bilder an und andere schlugen fehl (Warnung B000 und Zähler)?

Ein Warnstatus von B000 (Sub-operations Complete – One or more Failures) bedeutet, dass einige Teiloperationen erfolgreich waren und einige fehlschlugen. In der Praxis öffnet der Sonographeur die abgerufene Studie und stellt fest, dass Einzelbilder vorhanden sind, aber einige Cine-Loops, Volumina oder Berichte fehlen. ¹

B000 ist ein deutlicher Beleg dafür, dass beide Assoziationen aufgebaut werden können: Das Archiv hat das Zielsystem erreicht und mindestens einige C-STORE-Anforderungen waren erfolgreich. Der Fehler liegt bei bestimmten Instanzen oder SOP-Klassen oder an Ressourcen auf dem Zielsystem.

Zu den Hauptursachen für unvollständige Abrufe gehören:

• Nichtübereinstimmung der Transfer-Syntax: Das Archiv speichert einen Clip in einer Codierung, die das Zielsystem nicht akzeptiert (beispielsweise MPEG-4 AVC/H.264 oder JPEG-LS), und kann oder führt keine Konvertierung durch. Archive unterscheiden sich: Die Conformance-Erklärung für das Canon HCBA-01 beschreibt beispielsweise eine konfigurierbare Transfer-Syntax-Liste pro Ziel-AE-Titel und Versuche einer Transkodierung, wenn das Zielsystem die gespeicherte Syntax nicht unterstützt. ⁴
• Nicht-Bildobjekte abgelehnt: Studien können Structured Reports, Encapsulated PDF oder Presentation States enthalten. Ein Empfänger, der nur SOP-Klassen für Ultraschallbilder akzeptiert, lehnt die übrigen ab. Akzeptanz ist nicht gleichbedeutend mit Anzeige: Die Erklärung zu Philips Release 6.0.x besagt, dass das System SR-Objekte mit einer Studie akzeptiert und importieren kann, importierte SR jedoch nicht anzeigt. ³ Um Berichtsobjekte zu überprüfen, gleichen Sie die tatsächlich eingetroffenen Instanzen mit der ursprünglichen Erfassung ab.
• Speicherplatz am Zielort: Geht der Konsole während eines umfangreichen Abrufs der lokale Speicherplatz aus, kann ihr Empfänger spätere Instanzen ablehnen. Bevor Sie Speicherplatz freigeben, verifizieren Sie beibehaltene Instanzen, bevor Sie sich auf lokale Kopien verlassen oder diese löschen.

Beginnen Sie bei B000 mit der Failed SOP Instance UID List (0008,0058). Der Abgleich dieser UIDs mit den Datensätzen des Archivs zeigt, welche SOP-Klassen und Transfersyntaxen fehlgeschlagen sind, sodass die Behebung gezielt erfolgen kann.

Schrittweiser Diagnoseablauf für Medizintechniker

Um unkoordinierte Änderungen zwischen Medizintechnik, PACS und IT zu vermeiden, arbeiten Sie jedes Mal dieselbe Abfolge durch, wenn ein Abruf fehlschlägt. Jeder Schritt gibt an, wer ihn normalerweise durchführt:

1. Schritt 1 — Status und Anzahlen erfassen: Ermitteln Sie den endgültigen C-MOVE-Status (zum Beispiel A801, A702, A900 oder B000) und alle gemeldeten Anzahlen aus dem DICOM-Protokoll des Archivs (PACS-Administrator) oder dem Service-Protokoll des Scanners, sofern dieser sie anzeigt. Gleichen Sie das Muster mit Tabelle 2 ab.
2. Schritt 2 — DICOM-Identität des Scanners dokumentieren: seinen sendenden AE Title, den als Move Destination angegebenen AE Title, seinen Listening-Port und seine aktuelle IP-Adresse (Scanner-Service).
3. Schritt 3 — Zieleintrag des Archivs prüfen: Bestätigen Sie gemeinsam mit dem PACS-Administrator, dass ein Knoteneintrag für diesen Ziel-AE-Title mit der aktuellen IP-Adresse und dem Port des Scanners vorhanden ist, und vergleichen Sie die Zeichenketten exakt.
4. Schritt 4 — Erreichbarkeit von der Archivseite aus testen: Das Netzwerk- oder PACS-Team prüft mit seinen freigegebenen Werkzeugen, ob das Archiv den Listening-Port des Scanners erreichen kann. Beachten Sie, dass ICMP-Ping richtlinienbedingt blockiert sein kann, selbst wenn der DICOM-Port offen ist; ein fehlgeschlagener Ping allein beweist daher wenig.
5. Schritt 5 — Akzeptierte Aufrufer am Scanner prüfen: Bestätigen Sie bei Systemen, die Storage-Sender vorab registrieren, wie beispielsweise der dokumentierten Philips-Familie, dass der sendende AE Title und die IP-Adresse des Archivs eingetragen sind (Scanner-Service).
6. Schritt 6 — Option bestätigen: Prüfen Sie, ob die vom Hersteller geforderte Query/Retrieve-Option, falls erforderlich, auf dem System vorhanden ist (Scanner-Service).
7. Schritt 7 — Objekte und Kodierungen abgleichen: Prüfen Sie bei Teilübertragungen, ob die fehlgeschlagenen Objekte eine SOP-Klasse oder Transfersyntax gemeinsam haben, die das Ziel nicht akzeptiert (PACS-Administrator und Scanner-Service).

Komplexe Netzwerktopologien: NAT, VLANs und drahtlose DHCP-Gerätewagen

In modernen Krankenhaus-Unternehmensnetzwerken arbeiten Ultraschallsysteme zunehmend in dynamischen oder segmentierten Infrastrukturen, was Routing-Komplexitäten mit sich bringt, die stationäre Bildgebungsmodalitäten wie CT oder MRT nicht betreffen:

1. Netzwerkadressübersetzung (NAT): Befindet sich der Scanner hinter NAT, beispielsweise in einem segmentierten Drahtlosnetzwerk, sieht das Archiv die Adresse des Gateways, während sein Knoteneintrag für den Ziel-AE-Title möglicherweise auf eine Adresse verweist, die es nicht direkt erreichen kann. Unaufgeforderte eingehende Verbindungen an diese Adresse werden verworfen, es sei denn, das Netzwerk ist dafür ausgelegt. Die Wissensdatenbank von Medical Connections beschreibt Router, NAT und Software-Firewalls als häufige Blockierer der umgekehrten C-MOVE-Verbindung; ihre desktoporientierten Behelfslösungen wie das Deaktivieren von Firewalls oder das Öffnen von Router-Ports sind in einem Krankenhausnetzwerk nicht angemessen. ⁶

2. Wechselnde IP-Adressen: Mobile Scanner, die zwischen Abteilungen bewegt werden, erhalten möglicherweise über DHCP neue Adressen. Wenn der Knoteneintrag des Archivs eine feste Adresse für den AE-Title des Scanners enthält, sendet jede Änderung Assoziation 2 an die alte Adresse und es kommt zu einem Timeout. Scanner, die Abrufe benötigen, erfordern im Allgemeinen eine stabile Adresse, wie eine statische Zuweisung oder eine DHCP-Reservierung, die vom Netzwerkteam festgelegt wird.

3. Stateful Inspection und asymmetrisches Routing: Enterprise-Firewalls implementieren häufig Stateful Inspection, wodurch eingehende Rückpakete für Verbindungen, die aus einer geschützten Zone heraus initiiert wurden, automatisch zugelassen werden. Während Assoziation 1 (Ultraschall zu PACS) als aktiver zustandsbehafteter Datenfluss erkannt wird, handelt es sich bei Assoziation 2 um eine völlig neue TCP-Verbindung, die vom PACS-Server in Gegenrichtung initiiert wird. Sofern der Firewall-Administrator keine explizite bidirektionale Richtlinie oder eine eingehende Regel erstellt, die den Datenverkehr vom PACS-Server zum Listening-Port des Ultraschallsystems gestattet, verwirft die Firewall Assoziation 2 als unautorisierten eingehenden Verbindungsversuch.

Aushandlung des Präsentationskontexts und Syntax-Diskrepanzen

Sobald Assoziation 2 einen TCP-Socket aufbaut, schlägt das PACS-Archiv (in der Rolle als Storage SCU) dem Ultraschall-Fahrwagen (in der Rolle als Storage SCP) eine Liste von Präsentationskontexten vor. Jeder vorgeschlagene Kontext verknüpft eine Abstract Syntax (die SOP-Klassen-UID) mit einer oder mehreren Transfer-Syntaxen (dem Kodierungsformat und dem Kompressions-Codec). Das Ultraschallgerät wertet jeden Vorschlag aus und gibt in seiner A-ASSOCIATE-AC-Antwort einen Annahme- oder Ablehnungscode zurück.

Ultraschallsysteme verarbeiten eine einzigartige Kombination aus Cine-Loops mit hoher Bildfrequenz, Mehrzonen-Farbflussdarstellungen und komplexen strukturierten Messungen. Die nachstehende Tabelle führt die häufigsten Kollisionen bei Präsentationskontexten auf, die während C-STORE-Teiloperationen auftreten:

Diagnose auf Paketebene und nicht-intrusive Erfassung des Datenverkehrs

Installieren Sie keine Packet-Capture-Tools, Portscanner oder andere Software auf der Ultraschallkonsole. Es handelt sich um ein Medizinprodukt, das der Softwarekontrolle des Herstellers und dem Änderungsmanagement der Einrichtung unterliegt, und nicht freigegebene Software kann seine validierte Konfiguration und Sicherheit beeinträchtigen.

Ist eine Aufzeichnung gerechtfertigt, kann das Netzwerkteam diese über die Infrastruktur vornehmen, beispielsweise mittels Switch-Port-Spiegelung (SPAN) oder einem passiven Netzwerk-TAP, und auf einer separaten autorisierten Workstation analysieren. Aufzeichnungen von unverschlüsseltem DICOM-Datenverkehr enthalten Patientendaten; sie müssen daher gemäß den Datenschutz- und Sicherheitsrichtlinien der Einrichtung autorisiert, minimiert, gespeichert und gelöscht werden. Kommt sicheres DICOM (TLS) zum Einsatz, zeigt die Aufzeichnung die TCP-Verbindung, nicht jedoch die darin enthaltenen DICOM-Nachrichten; nutzen Sie stattdessen die Archiv- und Scanner-Protokolle.

In Wireshark isoliert ein Anzeigefilter wie dicom || tcp.port == <listening port> unter Verwendung der am Standort konfigurierten Ports den relevanten Datenverkehr. Prüfen Sie anschließend beide Assoziationen der Reihe nach:

• Verifizierung von Assoziation 1: Lokalisieren Sie den TCP-Drei-Wege-Handshake (SYN, SYN-ACK, ACK), der vom ephemeren Port der Ultraschallkonsole zum Listening-Port des PACS ausgeht. Überprüfen Sie unmittelbar nach dem Handshake die PDU A-ASSOCIATE-RQ (Typ 01H), die vorgeschlagene Präsentationskontexte für Study Root Query/Retrieve Information Model – FIND und MOVE enthält. Bestätigen Sie, dass der PACS-Server eine PDU A-ASSOCIATE-AC (Typ 02H) zurückgibt, die beide Kontexte akzeptiert.
• Versand der C-MOVE-Anforderung: Verfolgen Sie die PDU P-DATA-TF, die den Befehl C-MOVE-RQ enthält. Überprüfen Sie die Message-ID, das QueryRetrieveLevel (z. B. STUDY), den Abgleichsschlüssel StudyInstanceUID sowie das Attribut Move Destination AE Title (0000,0600). Bestätigen Sie, dass die Zielzeichenfolge exakt mit dem erwarteten Listening-AE-Title des Ultraschallgeräts übereinstimmt.
• Initiierung und Handshake von Assoziation 2: Achten Sie auf ein neues, unabhängiges TCP-SYN-Paket, das von der IP-Adresse des PACS-Servers eingeht und an die statische IP-Adresse sowie den Listening-Port des Ultraschallwagens gerichtet ist. Dies ist der entscheidende diagnostische Dreh- und Angelpunkt. Das Verhalten dieses Pakets identifiziert die Ursache unmittelbar.

Nebenläufigkeit, Warteschlangenverwaltung und Socket-Timeouts

In klinischen Bildgebungsabteilungen mit hohem Durchsatz treten Abruffehler bei hoher Arbeitslast häufig intermittierend auf. Ein Ultraschall-Fahrwagen, der eine Schilddrüsenuntersuchung mit fünf Bildern problemlos abruft, kann beim Versuch, eine komplexe Echokardiographie-Untersuchung mit 600 Einzelbildern oder eine umfassende periphere Gefäßuntersuchung zu importieren, reproduzierbar fehlschlagen. Diese volumenabhängigen Fehler werden durch Begrenzungen der Netzwerk-Warteschlangen und Socket-Timeout-Konfigurationen verursacht.

1. Archiv-Drosselung und Client-Timeouts: Archive begrenzen häufig gleichzeitige ausgehende Übertragungen. Wenn mehrere Benutzer gleichzeitig große Studien anfordern, können sich Teiloperationen in der Warteschlange anstauen. Wendet der anfordernde Scanner ein eigenes Timeout auf den gesamten Abruf an, bricht er möglicherweise ab und meldet einen Fehler, während das Archiv noch Daten sendet. Vergleichen Sie den zeitlichen Ablauf im Archiv-Protokoll mit dem Zeitpunkt, zu dem der Scanner den Fehler gemeldet hat.

2. Langsame Schreibvorgänge am Ziel: Ein Ziel, das Daten nicht so schnell schreiben kann, wie sie eintreffen, verlangsamt die Übertragung. Überschreitet ein Stillstand das Nachrichten- oder Netzwerk-Timeout des Archivs, bricht das Archiv die Assoziation 2 ab. Das informative PS3.2-Beispiel beschreibt genau dies: ein A-ABORT bei einem Timeout auf Nachrichten- oder niedriger Ebene, wobei in der C-MOVE-Antwort ein entsprechender Fehlerstatus zurückgegeben wird. ²

3. Wiederholte Versuche: Jedes Betätigen von „Retrieve“ sendet eine neue C-MOVE-Anforderung, was doppelte Übertragungen in die Warteschlange einreihen und den ersten Fehler in den Protokollen überdecken kann. Erfassen Sie den Status des ersten Fehlers und führen Sie nach Behebung der Ursache einen einmaligen, kontrollierten Neuversuch durch.

Validierung nach dem Abruf: lokale Datenbankindizierung und Vermeidung von Studienteilungen

Ein Endstatus von 0000 (Success) bedeutet, dass jede C-STORE-Teiloperation übertragen und bestätigt wurde. Dies garantiert jedoch nicht, dass sich die Studie dort auf dem Scanner befindet, wo der Sonograf sie erwartet.

Ultraschallsysteme unterscheiden sich darin, wie sie empfangene Studien ablegen und auflisten; maßgeblich ist das Conformance Statement oder das Bedienerhandbuch für den exakten Versionsstand. Empfangene Objekte werden in der Regel nach ihren identifizierenden Attributen gruppiert, wie der Patienten-ID (0010,0020), der Study Instance UID (0020,000D) und der Accession-Nummer (0008,0050), sodass Unterschiede bei diesen Werten verändern, wo eine Studie erscheint.

Erscheinen abgerufene Bilder trotz einer Bestätigung mit dem Status 0000 nicht auf dem Konsolenbildschirm, sollten Techniker drei häufige Anomalien bei der Datenbankübernahme untersuchen:

• Geöffnete Untersuchung: Einige Systeme aktualisieren ihre Studienliste möglicherweise nicht, während eine Untersuchung läuft. Prüfen Sie den im Bedienerhandbuch beschriebenen Bildschirm für Review oder empfangene Studien.
• Unter einem anderen Patientendatensatz abgelegt: Weist die archivierte Studie eine andere Patienten-ID oder Accession-Nummer auf als der heutige Auftrag, listet der Scanner sie möglicherweise unter einem separaten Patienteneintrag auf. Suchen Sie nach der Study Instance UID oder dem Datum, bevor Sie schlussfolgern, dass der Abruf fehlgeschlagen ist.
• Fehler beim lokalen Speicher oder bei der Indizierung: Ist der lokale Speicher nahezu voll oder ist der Importprozess fehlgeschlagen, weist das Service-Protokoll des Scanners üblicherweise darauf hin. Geben Sie Speicherplatz ausschließlich über das vom Hersteller freigegebene Verfahren und gemäß der Aufbewahrungsrichtlinie der Einrichtung frei.

Wer ist für die jeweilige Behebung zuständig: Scanner-Service, PACS-Administrator oder Netzwerkteam?

Serviceteams der klinischen Medizintechnik spielen eine entscheidende Triage-Rolle im Lebenszyklus des medizintechnischen Managements (Healthcare Technology Management). Wenn klinische Sonographen Abruffehler melden, sind Medizintechniker vor Ort im Krankenhaus oft die ersten Einsatzkräfte. Anstatt die Störung sofort an externe IT-Helpdesks zu eskalieren oder eine Rücksendegenehmigung wegen eines Geräteausfalls einzuholen, sollten klinische Medizintechniker bei der ersten Inbetriebnahme des Geräts eine formelle DICOM-Konnektivitäts-Baseline erstellen. Diese Baseline sollte die verifizierte statische IP-Adresse, Subnetzmaske, das Standard-Gateway, die physische MAC-Adresse, den lokalen Storage-SCP-AE-Titel, den Listening-Port und den Software-Build des Ultraschallwagens sowie das Datum und die Change-Ticket-Nummer jeglicher Netzwerkänderungen dokumentieren. Die Pflege dieses Konnektivitäts-Baseline-Datensatzes im computergestützten Instandhaltungsmanagementsystem (CMMS) des Krankenhauses stellt sicher, dass künftige IP-Neubewertungen, Switch-Port-Rekonfigurationen oder Software-Updates sofort mit einem bekannten funktionierenden Zustand abgeglichen werden können, was die Diagnosezeit drastisch verkürzt und unnötige Serviceeinsätze verhindert.

Da ein DICOM-Abruf institutionelle Grenzen überschreitet – über Firmware von Medizinprodukten, Netzwerk-Switches des Krankenhauses, Firewalls und unternehmensweite PACS-Datenbanken hinweg –, artet die Fehlersuche häufig in abteilungsübergreifende gegenseitige Schuldzuweisungen aus. Klinische Medizintechniker werfen der Krankenhaus-IT vor, Ports zu blockieren, die IT gibt dem PACS-Hersteller die Schuld an Softwarefehlern, und PACS-Administratoren machen den Ultraschallwagen für defekte Hardware verantwortlich.

Um unnötige Ausfallzeiten zu vermeiden, müssen technische Teams im Krankenhaus klare Zuständigkeitsgrenzen auf der Grundlage objektiver Protokollnachweise durchsetzen. Jede Ebene der Abrufkette gehört zu einer bestimmten Fachdisziplin:

Was sollte dokumentiert werden, bevor jemand eine Einstellung ändert?

Protokollieren Sie jede Änderung: was geändert wurde, von wem, unter welchem Arbeitsauftrag und das Ergebnis der Vorher-Nachher-Tests. Schlägt ein späterer Abruf fehl, zeigt dieses Protokoll, ob die Ursache eine kürzliche Infrastrukturänderung oder ein neuer Gerätefehler ist. Sofern der Hersteller einen unterstützten Konfigurationsexport anbietet, erstellen Sie vor dem Ändern von Scannereinstellungen einen solchen und speichern Sie ihn gemäß den Richtlinien der Einrichtung, damit die Änderung rückgängig gemacht werden kann.

Wenn ein Ultraschallsystem Studien nicht abrufen kann, muss das Servicepersonal dem Drang widerstehen, willkürlich Konfigurationsparameter zu ändern, Firewall-Einstellungen umzuschalten oder Ersatz-Netzwerk-I/O-Platinen zu bestellen. Unkoordinierte Fehlersuche nach dem Trial-and-Error-Prinzip birgt erhebliche Sicherheitsrisiken und verursacht häufig sekundäre Fehler, die die Wiederherstellung erschweren.

Routing-Fehler stellen auch ein Datenschutzrisiko dar. Versucht jemand, einen A801 durch Erraten von Ziel-AE-Titeln zu beheben oder indem die Move Destination auf einen anderen bekannten Knoten verwiesen wird, ohne zu bestätigen, worum es sich dabei handelt, sendet das Archiv Patientenstudien an dieses Gerät. In vielen Rechtsordnungen kann dies ein meldepflichtiger Datenschutzvorfall sein; der Datenschutzbeauftragte der Einrichtung entscheidet, wie damit umzugehen ist.

Bevor Konfigurationsdateien geändert, Support-Tickets eröffnet oder Ersatzkomponenten angefordert werden, müssen Medizintechniker ein strukturiertes, bereinigtes Evidenzpaket zur Serviceaufnahme erfassen:

Kontrollierte Simulationswerkzeuge: synthetische Verifikation ohne Risiko für Patientendaten

Wenn ein Ultraschall-Abruf intermittierend fehlschlägt oder Netzwerkteams darüber uneins sind, ob ein Firewall-Port tatsächlich geöffnet ist, benötigen Medizintechniker eine objektive, wiederholbare Methode, um den fehlerhaften Endpunkt zu isolieren, ohne wiederholt reale Patientenuntersuchungen über klinische Subnetze zu senden. In regulierten Krankenhausumgebungen erzeugt das wiederholte Auslösen fehlgeschlagener Übertragungen echter klinischer Studien Audit-Rauschen und erhöht das Risiko einer unbeabsichtigten Offenlegung geschützter Gesundheitsdaten.

Um eine verlässliche Referenz zu schaffen, können Teams der Medizintechnik standardisierte DICOM-Verifikationssuiten (wie Dienstprogramme des DCMTK-Toolkits oder DVTk-Testwerkzeuge) einsetzen, die auf einer dedizierten, von der IT autorisierten Test-Workstation innerhalb desselben klinischen Subnetzes ausgeführt werden:

• Prüfung des Rückwegs mit einem Test-Listener: Starten Sie einen temporären DICOM-Storage-Listener auf der autorisierten Test-Workstation auf einem mit dem Netzwerkteam abgestimmten Port und bitten Sie den PACS-Administrator, dessen AE-Title als Ziel zu registrieren. Wenn ein C-MOVE einer dafür vorgesehenen Teststudie den Listener erreicht, kann das Archiv dieses Netzwerksegment erreichen, und die Aufmerksamkeit richtet sich auf die Konfiguration des Scanners selbst.
• Überprüfung des Ultraschall-Storage-Listeners aus dem Netzwerk: Umgekehrt kann ein Techniker mittels C-STORE eine synthetische, de-identifizierte Ultraschall-Teststudie vom Test-Laptop direkt an die Listening-IP und den Port des Ultraschallwagens senden. Akzeptiert das Ultraschallgerät die Assoziation und importiert das Testbild, sind der lokale Storage-SCP-Dienst des Wagens, die lokale Betriebssystem-Firewall und die interne Datenbank nachweislich voll funktionsfähig. Weist der Wagen die Assoziation mit A-ASSOCIATE-RJ ab, ist die Konfiguration der vom Scanner akzeptierten Calling-AE-Titles unmittelbar als Fehlerursache bestätigt.
• Sicherheits- und Compliance-Grenze: Testprogramme dürfen niemals ohne formelle Genehmigung der Informationssicherheit des Krankenhauses mit klinischen VLANs verbunden werden. Darüber hinaus müssen Testbilder vollständig aus Phantomaufnahmen oder synthetisch generierten DICOM-Objekten bestehen, die keinerlei demografische Patientendaten oder geschützte Gesundheitsdaten enthalten.

Abnahmeprüfung nach dem Service und klinische Freigabe

Testen Sie nach jedem Platinenaustausch, jedem Neuladen der Software, jeder Netzwerkänderung oder Konfigurationsänderung die DICOM-Funktionen erneut, bevor der Scanner wieder für den klinischen Einsatz freigegeben wird. Serviceprüfungen beschränken sich oft darauf, ein einzelnes Bild an das PACS zu senden, sodass der Abruf ungetestet bleibt, bis ein Sonograf eine Voruntersuchung benötigt.

Verwenden Sie das für die Einrichtung festgelegte Testpatienten-Verfahren, damit kein realer Patientendatensatz angelegt oder verändert wird, und überprüfen Sie jede konfigurierte Funktion:

• 1. Verifikation (C-ECHO): Führen Sie einen Ping-/Echo-Test von der Ultraschallkonsole zu allen konfigurierten DICOM-Knoten durch (PACS-Archiv, Worklist-Server, Storage-Commitment-Server und DICOM-Drucker). Bestätigen Sie die erfolgreiche Rückmeldung.
• 2. Modality Worklist (C-FIND): Rufen Sie die für heute geplanten Patientenaufträge ab. Wählen Sie einen geplanten Patienten aus, übernehmen Sie die demografischen Patientendaten in den Erfassungsbildschirm und bestätigen Sie, dass Accession-Nummern, Studienbeschreibungen und die Namen der durchführenden Ärzte korrekt zugeordnet werden.
• 3. Akquisition & Speicherung (C-STORE): Nehmen Sie unter Verwendung eines gewebeäquivalenten Phantoms eine Multi-Frame-Farbdoppler-Schleife und statische 2D-Bilder auf. Senden Sie die abgeschlossene Untersuchung an das PACS. Bestätigen Sie, dass alle Instanzen fehlerfrei übertragen werden und das Archiv die Speicherung bestätigt.
• 4. Abfrage und Abruf (C-FIND, C-MOVE): Fragen Sie die soeben gespeicherte Teststudie ab, rufen Sie sie zurück auf den Scanner ab und bestätigen Sie, dass sich Bilder und Cine-Loops öffnen und kein Warnstatus wie B000 protokolliert wird. Prüfen Sie Messberichte nur dort, wo für das System dokumentiert ist, dass es diese importiert und anzeigt.

Geben Sie den Serviceeinsatz erst dann frei, wenn jede konfigurierte Funktion erfolgreich getestet wurde, damit sich Sonografen während der Untersuchungen auf Voruntersuchungen verlassen können.

Häufig gestellte Fragen

Beweist ein erfolgreiches C-ECHO oder eine erfolgreiche Abfrage, dass auch der Abruf funktionieren sollte?

Nein. Eine DICOM-Verifikation (C-ECHO) oder -Abfrage (C-FIND) prüft nur den vorwärtsgerichteten Netzwerkpfad, der vom Ultraschallgerät zum Listening-Port des PACS-Archivs initiiert wird (Assoziation 1). Ein C-MOVE-Abruf erfordert, dass das PACS-Archiv eine separate, umgekehrte Netzwerkverbindung zurück zum Listening-Port des Ultraschallgeräts initiiert (Assoziation 2). Da Firewalls, Netzwerk-Routingtabellen und lokale Sicherheitsrichtlinien des Scanners eingehende Verbindungen häufig anders behandeln als ausgehende Verbindungen, bietet ein Erfolg bei C-ECHO oder C-FIND keinerlei Garantie dafür, dass Assoziation 2 erfolgreich sein wird. ^{1 5}

Ist das Move-Ziel immer das Gerät, das die Anfrage gesendet hat?

Nicht notwendigerweise. In DICOM PS3.4 Abschnitt C.4.2 legt das Attribut „Move Destination“ den Application Entity Title des Systems fest, das die C-STORE-Teiloperationen empfangen wird. Während klinische Sonografen Untersuchungen üblicherweise auf das von ihnen bediente Fahrgerät abrufen, erlaubt das C-MOVE-Protokoll einem Anforderer ausdrücklich, jeden beliebigen DICOM-Speicherknoten eines Drittanbieters als Ziel anzugeben – wie etwa eine dedizierte Workstation, einen 3D-Visualisierungsserver oder eine Offline-Befundstation. Das Archiv löst den Move Destination AE Title stets unabhängig davon auf, welcher Client die Anfrage initiiert hat. ¹

Der Move meldet Erfolg, aber es ist keine Studie erschienen – was sollte zuerst geprüft werden?

Wenn die C-MOVE-Antwort den Status 0000 (Erfolg) anzeigt und die Anzahl der abgeschlossenen Teiloperationen der erwarteten Bildanzahl entspricht, war die Netzwerkübertragung vollständig erfolgreich. Wenn keine Bilder auf dem Bildschirm des Ultraschallgeräts erscheinen, prüfen Sie zwei Faktoren unmittelbar: Überprüfen Sie erstens den internen Patientendatenbank-Index des Ultraschallgeräts – manche Systeme speichern abgerufene Studien in einem lokalen Archiv oder Patientenverzeichnis, das manuell aktualisiert oder über eine Registerkarte „Importierte Studien“ geöffnet werden muss. Prüfen Sie zweitens, ob der Move Destination AE Title in der Anfrage versehentlich auf ein anderes physisches Gerät eingestellt war (wie etwa einen anderen Scanner oder eine Befundungsworkstation); in diesem Fall wurden die Bilder erfolgreich an dieses andere Gerät übermittelt. ^{1 6}

Können wir einfach die Firewall öffnen oder einen Port weiterleiten, damit der Abruf funktioniert?

Nein. Im klinischen Krankenhausumfeld sind Ultraschallgeräte mobile Medizinprodukte, die geschützte Gesundheitsdaten (Protected Health Information, PHI) verarbeiten. Das pauschale Öffnen von Firewall-Regeln, das Deaktivieren von Host-Sicherheitssoftware oder das Konfigurieren unkontrollierter Portweiterleitungen verstößt gegen Cybersicherheitsstandards im Gesundheitswesen und institutionelle Sicherheitsrichtlinien. Netzwerkänderungen müssen formell mit der Krankenhaus-IT und den Netzwerksicherheitsteams abgestimmt werden, wobei der Datenverkehr auf bestimmte Quell-IPs (den PACS-Server), Ziel-IPs (das fahrbare Ultraschallgerät) und festgelegte DICOM-Listening-Ports zu beschränken ist, ohne klinische Subnetze unberechtigtem Datenverkehr auszusetzen.

Würden C-GET oder DICOMweb dieses Problem der Rückverbindung vermeiden?

Im Prinzip ja. Bei C-GET (PS3.4 Abschnitt C.4.3) laufen die C-STORE-Teiloperationen über dieselbe Assoziation wie die Anfrage, und der Empfänger ist stets das anfordernde System. Der Abruf über DICOMweb wird vom Client ebenfalls über HTTP initiiert. Keines von beiden erfordert, dass das Archiv eine Verbindung zurück zum Scanner öffnet. ¹⁰ Doch beide Seiten müssen die Alternative unterstützen. Die vor einigen Jahren verfasste Wissensdatenbank von Medical Connections stellte fest, dass nur sehr wenige kommerzielle DICOM-Server C-GET unterstützten. ⁶ Prüfen Sie beide Conformance Statements. Ein Protokollwechsel ist eine Planungsfrage für den PACS-Eigentümer, keine Lösung für einen aktuellen C-MOVE-Fehler.

Bedeutet ein fehlschlagender Abruf, dass die Netzwerkplatine des Ultraschallgeräts defekt ist?

Unwahrscheinlich, wenn der Scanner über dieselbe Schnittstelle Abfragen durchführen, verifizieren oder Untersuchungen an das PACS senden kann. Netzwerk-Hardware überträgt Pakete unabhängig davon, ob sie eine C-FIND-Abfrage oder ein C-STORE-Bild enthalten. Wäre die Schnittstelle fehlerhaft, wäre normalerweise auch der ausgehende Datenverkehr beeinträchtigt. Funktioniert ausgehendes DICOM, ist ein reiner Abruffehler weitaus wahrscheinlicher auf ein Problem mit dem AE-Titel, autorisierten Aufrufern (Accepted-Caller), dem Routing oder der Firewall zurückzuführen. Sporadische Verbindungsabbrüche oder eine ausgefallene Schnittstelle sind andere Symptome, die im oben verlinkten Leitfaden zur Netzwerk-I/O-Platine behandelt werden.

Was ist, wenn Patientenuntersuchungen an das falsche Ziel übertragen wurden?

Behandeln Sie dies als potenziellen Datenschutzvorfall. Stoppen Sie den Test, erfassen Sie die Uhrzeit, die Study Instance UID sowie den verwendeten Ziel-AE-Titel und benachrichtigen Sie den PACS-Administrator sowie den Datenschutzbeauftragten der Einrichtung. Diese entscheiden, wie das Empfangsgerät überprüft wird und wie fehlgeleitete Kopien entfernt werden.

Wo Rongtao unterstützen kann – und wo nicht?

Rongtao Medical ist ein unabhängiges Unternehmen für Ultraschallreparaturen und -teile mit Sitz in Guangzhou, China, das Händler, Serviceorganisationen und Medizintechnik-Teams von Krankenhäusern betreut. Klarheit darüber, wo wir helfen können, spart allen Beteiligten Zeit.

Wo Rongtao unterstützen kann:

• Hardware-Fehlerisolierung: Wenn das Problem tatsächlich an der Hardware liegt, beispielsweise bei fehlendem Ethernet-Link, zeitweiligem Verbindungsverlust oder einer ausfallenden I/O-Platine oder einem ausfallenden Mainboard, bietet Rongtao Diagnose und Reparatur auf Platinenebene. Jede reparierte Platine wird vor der Freigabe 48 Stunden lang in einem realen Ultraschallsystem betrieben. ⁷
• Ersatzplatinen und -teile: Platinenreparatur und Teile für unterstützte OEM-Systeme. Der Lagerbestand ändert sich; bestätigen Sie eine bestimmte Teilenummer daher über den Live-Katalog oder ein Angebot. ⁸
• Sondenreparatur: Fehlerdiagnose und Reparatur von Linear-, Konvex-, Phased-Array-, Endokavitäts-, TEE- und Volumensonden mit einer typischen Garantie von 90 Tagen, die pro Artikel und Serviceleistung bestätigt wird. ⁸
• Beratung bei der Serviceannahme: Unterstützung bei der Feststellung, ob ein Symptom auf die Hardware oder auf eine anderweitige Konfiguration hindeutet, damit Sie scannerseitige Servicenachweise vorbereiten können, bevor Sie Teile bestellen.

Wo Rongtao nicht unterstützen kann:

• Netzwerk- & Firewall-Administration im Krankenhaus: Rongtao konfiguriert keine Netzwerk-Switches von Krankenhausabteilungen, administriert keine Enterprise-Firewalls, modifiziert keine VLAN-Zugriffskontrolllisten und verwaltet keine Active-Directory-Domänen von Krankenhäusern.
• Administration von PACS-Archivknoten: Wir verwalten, lizenzieren oder konfigurieren weder PACS-Archive von Krankenhäusern noch herstellerneutrale Archive (Vendor Neutral Archives, VNAs) oder Radiologie-Informationssysteme. Änderungen an PACS-Zieltabellen und serverseitigen AE-Titel-Zuordnungen verbleiben in der ausschließlichen Verantwortung der PACS-Administration des Krankenhauses.
• Autorisierte OEM-Vertretung: Rongtao Medical ist ein unabhängiger Serviceanbieter und ist kein autorisierter Vertreter, Händler oder Repräsentant von GE HealthCare, Philips, Siemens Healthineers, Canon Medical Systems, Mindray oder Samsung Medison.

Wenn Sie bei anhaltenden Kommunikationsfehlern technischen Hardware-Support oder Ersatzteile anfragen, senden Sie bitte die bereinigten DICOM-Nachweise und Modellangaben an unser technisches Team: OEM-Marke, genaue Modellfamilie, Software-Release, Hardware-Teilenummern und eine bereinigte Zusammenfassung der Fehlersymptome. Senden Sie niemals Patientengesundheitsdaten, Patientenbilder oder klinische Identifikatoren über Kanäle für technische Angebote.