Welches Datum stellt der Bildschirm tatsächlich dar?
Betrachten Sie ein fiktives Serviceticket: Eine Ultraschalluntersuchung erscheint am 23. Oktober am Ultraschallgerät, aber am 22. Oktober im Bildarchivierungs- und Kommunikationssystem (PACS). Der Anfragende vermutet die Geräteuhr. Ein Screenshot von jedem System dokumentiert eine Diskrepanz, lokalisiert deren Ursache jedoch noch nicht.
Für das Medizintechnik-Team eines Krankenhauses oder einen unabhängigen Serviceanbieter ist die erste Entscheidung, wer die Untersuchung durchführen sollte. Stellen Sie fest, welches Ereignis und welche Darstellung der jeweilige Bildschirm anzeigt, bevor Sie die Kalenderdifferenz als Hardwaresymptom behandeln. Die aktuelle Uhr des Ultraschallgeräts, die Startzeit einer Untersuchung und die Empfangszeit eines Archivs beantworten unterschiedliche Fragen.
Beginnen Sie mit den Ereignisdefinitionen. DICOM Study Date und Study Time beschreiben den Untersuchungsbeginn. Acquisition DateTime beschreibt den Beginn der Datenakquisition, die zu der Instanz führte. Keine der beiden Definitionen macht einen Zeitstempel zu einer messtechnischen Garantie für die Genauigkeit der Uhr. 7 8
- Untersuchungsbeginn: Vergleichen Sie
(0008,0020)und(0008,0030)mit dem dokumentierten Untersuchungsstart-Ereignis für die installierte Scanner-Version. - Akquisitionsbeginn: Wenn
(0008,002A)vorhanden ist, bestimmen Sie die Akquisition, die dadurch beschrieben wird. Verwenden Sie nicht ersatzweise den Zeitpunkt von Freeze, Speicherung, Untersuchungsende oder Netzwerkübertragung. - Instanzerstellung:
(0008,0012)und(0008,0013)beziehen sich auf die Erstellung der SOP-Instanz und die Zuweisung ihrer UID, nicht auf den Archiveingang. 2 - Empfänger und Anzeige: Erfragen Sie beim PACS-Verantwortlichen, was ein Datum in einer Listenspalte, einem Overlay oder einem Portal darstellt. Erfassen Sie jede Konvertierungsrichtlinie sowie den Benutzer- oder Kunden-Zeitzonenkontext getrennt von den Quellwerten.
Zwei Datumsangaben können nach einer Konvertierung denselben Zeitpunkt korrekt beschreiben. Sie können jedoch auch unterschiedliche Ereignisse beschreiben oder fehlerhafte Quelldaten widerspiegeln. Behandeln Sie jede Möglichkeit als Hypothese, bis Werte, Ereignisbedeutungen und Systemeinstellungen eine Erklärung stützen. Eine plausible Differenz von zwei Stunden allein verifiziert nicht den gesamten Datensatz.
Was sollte das Evidenzprotokoll erfassen, bevor Einstellungen geändert werden?
Sichern Sie einen Ausgangszustand, bevor Sie Einstellungen ändern. Andernfalls kann ein späterer Vergleich ein älteres exportiertes Objekt mit einer neu korrigierten Uhrzeit oder einem anderen Anzeigeprofil vermengen. Erfassen Sie, wer jede Beobachtung erhoben hat, von welchem System und wann. Belassen Sie die ursprünglichen patientenbezogenen Nachweise innerhalb der von der Einrichtung zugelassenen Kanäle; eine Serviceanfrage sollte bereinigte Befunde oder ein synthetisches Beispiel verwenden.
Nutzen Sie das nachstehende Protokoll, um einen autorisierten schreibgeschützten Vergleich zu strukturieren. Halten Sie für jede Zeile die unformatierte Zeichenkette fest, ob sie fehlt oder leer ist, aus welchem Objekt sie stammt und welche Interpretation vorgeschlagen wird. Ein Tag-Inspector kann helfen, doch eine angezeigte Header-Ansicht sollte nicht automatisch als unveränderte Kopie des ursprünglich übertragenen Objekts behandelt werden. Bitten Sie bei Bedarf die Systemverantwortlichen, die aufbewahrten Quell- und die empfangenen Instanzen zu vergleichen.
| Zu vergleichender Wert | Ereignis oder Rolle | Beizubehaltender Kontext | Was unbewiesen bleibt |
|---|---|---|---|
Untersuchungsdatum / -zeit(0008,0020) / (0008,0030) | Untersuchungsbeginn; DA / TM. | Originalwerte und Kontext des Quell-Offsets. | Zeitpunkt der einzelnen Akquisition oder Empfangszeitpunkt am Empfänger. |
Erfassungsdatum und -zeit(0008,002A) | Akquisitionsbeginn; DT, falls vorhanden. | Vollständiger Wert einschließlich etwaigem Inline-Offset; zutreffendes Objekt und Release. | Freeze-Zeitpunkt, Zeitpunkt jedes Einzelbilds oder externe Uhrensynchronisation. |
Zeitzonenversatz gegenüber UTC(0008,0201) | Kontext für DA / TM und DT ohne eigenen Offset. | Wert mit Vorzeichen oder expliziter Vermerk, dass er fehlt oder leer ist. | Eine benannte Zeitzone, historische Umstellungsregel oder genaue Quelluhr. |
Instanzerstellungsdatum / -zeit(0008,0012) / (0008,0013) | Instanzerstellung und UID-Zuweisung. | Ursprüngliches Objekt und Erstellungskontext. | Akquisitions- oder Netzwerkübertragungszeitpunkt. |
| Quell- und empfangenes Objekt | Vergleich über eine Zwischensystem- oder Archivgrenze hinweg. | Von der Einrichtung genehmigte Objektbezeichner und etwaige autorisierte Änderungshistorie. | Welches System einen Wert geändert hat, es sei denn, die Nachweise an der Systemgrenze belegen dies. |
| Viewer-Spalte / Datumsfilter | Darstellung oder Auswahl in der Anwendung. | Feldbezeichnung, Produkt-Release, angezeigte Zeitzone und Filtergrenzen. | Der ursprünglich gespeicherte Wert oder die erfolgreiche Archivierung der vollständigen Untersuchung. |
Quelle: Redaktionelles Protokoll unter Verwendung von DICOM-Definitionen aus den Quellen 1, 2, 7 und 8; kein vorgeschriebenes Standardformular.
Ein aussagekräftiger Vergleich benennt einen Befund und dessen Grenzen: „Dieselbe empfangene Instanz zeigt in der Tag-Ansicht Study Date 20261023 und in der Studienliste den 22. Oktober; die Zeitzone der Liste ist noch nicht bestätigt.“ Dies ist fundierter, als den Header als beschädigt zu bezeichnen. Zudem teilt es dem PACS-Verantwortlichen genau mit, welche Nachweise fehlen.
Wie unterscheiden sich getrennte Datums- und Zeitfelder von einer Datums- und Zeitangabe mit Offset?
Die DICOM-Value-Representation (VR) bestimmt, wie ein Feld codiert wird. Die drei relevanten Formen sind Date (DA), Time (TM) und DateTime (DT). Trennen Sie die Codierungssyntax vom Nachweis, dass die Uhrzeit korrekt war. 1
- DA: Ein Kalenderdatum wie
20261023, ohne integrierten UTC-Offset. - TM: Eine Uhrzeit wie
010000, ohne integriertes Datum oder Offset. - DT: Ein Datums-/Uhrzeitwert, der einen vorzeichenbehafteten Offset enthalten kann, wie etwa
20261023010000+0200. Die Genauigkeit kann variieren. Ohne Suffix gilt die lokale Interpretation des Erstellers, sofern das separate Offset-Attribut nichts anderes angibt. 1
Study Date und Study Time benötigen daher Kontext, um einen Vergleich mit einer UTC-Anzeige zu ermöglichen. Behalten Sie das Rohwertepaar zusammen und ermitteln Sie anschließend den anwendbaren Offset anhand des Objekts oder einer verifizierten Quellkonfiguration. Leiten Sie eine Zeitzone nicht aus dem Namen des Krankenhauses, dem Standort des Empfängers oder der Uhr der Workstation zum Zeitpunkt der Untersuchung ab.
In SOP Common ist Timezone Offset From UTC optional (Typ 3). Es liefert Kontext für DA/TM sowie für DT-Werte ohne expliziten Offset. Ein DT-Wert mit eigenem Offset behält diesen Kontext unabhängig bei. 2
Wenn der separate Offset fehlt, identifiziert dieses Attribut den lokalen Offset nicht. Das Fehlen ist keine Deklaration von UTC. Ebenso ist ein Empfänger-Fallback eine Frage der Implementierung: Ermitteln Sie die dokumentierte Richtlinie und den tatsächlichen Quellkontext, bevor Sie entscheiden, dass dieser den Wert fehlerhaft interpretiert hat. 2
Ein Offset ist ein numerisches Verhältnis zu UTC, kein Zeitzonenname und keine vollständige Sommerzeitregelung. Zwei identische lokale Uhrzeitangaben können unterschiedliche Zeitpunkte beschreiben, wenn sich ihre Offsets unterscheiden. Kann der erforderliche Kontext nicht wiederhergestellt werden, bewahren Sie diese Unsicherheit, anstatt eine präzise Chronologie allein aus einer Datumszeichenfolge zu rekonstruieren.
Das separate Timezone Module definiert den Offset innerhalb dieses Moduls als Typ 1. Seine Anforderung muss im Kontext der zutreffenden Information Object Definition und Implementierung gelesen werden. Weder diese Zeile noch die optionale SOP-Common-Zeile belegt für sich allein, dass ein gesamtes Ultraschallobjekt konform oder nicht konform ist. 3
Kann eine korrekte Umrechnung eine Ultraschalluntersuchung über Mitternacht verschieben?
Ja. Vergleichen Sie einen einzelnen, vollständig spezifizierten Zeitpunkt, bevor Sie einen Fehler diagnostizieren. Die folgenden Beispiele verwenden ausschließlich feste numerische Offsets. Sie stellen weder eine namentlich genannte Stadt noch eine tatsächliche Sommerzeitumstellung, ein Patientenereignis oder ein an einem bestimmten PACS getestetes Verhalten dar.
In einem fiktiven Testdatensatz liegen Untersuchungsbeginn und Akquisitionsbeginn beide am 23. Oktober 2026 um 01:00 mit dem Offset +02:00. Die anschaulichen Werte lauten:
- Untersuchungsdatum
(0008,0020):20261023 - Untersuchungszeit
(0008,0030):010000 - Zeitzonenverschiebung gegenüber UTC
(0008,0201):+0200 - Aufnahmedatum/-zeit
(0008,002A):20261023010000+0200
Wenn ein Empfänger diesen Zeitpunkt in UTC anzeigt, ergibt das Subtrahieren des zweistündigen Offsets:
2026-10-23 01:00:00 (+02:00) minus 2 Stunden = 2026-10-22 23:00:00 (UTC)
Das Kalenderdatum wird zum 22. Oktober, während der Zeitpunkt unverändert bleibt. Die Umrechnung beträgt zwei Stunden; es handelt sich nicht um eine Änderung der verstrichenen Zeit um 24 Stunden. Eine korrekte UTC-Anzeige und eine korrekte lokale Anzeige können daher aufeinanderfolgende Tage anzeigen. Ob eine bestimmte Anwendung diese Umrechnung durchführt, muss anhand ihrer Dokumentation und Konfiguration ermittelt werden.
| Fall | Eingabe und Kontext | Vergleichsergebnis | Entscheidungsgrenze |
|---|---|---|---|
| A. Vorheriger Tag in UTC | 20261023010000+0200 | 2026-10-22 23:00 UTC | Derselbe Zeitpunkt; Kalenderdaten von Quelle und UTC weichen voneinander ab. |
| B. Unterschiedliche Ereignisse | Untersuchungsbeginn: 22. Okt., 23:45; Akquisitionsbeginn: 23. Okt., 00:15; beide +00:00. | Untersuchung und Akquisition haben unterschiedliche Kalenderdaten. | Überprüfen Sie die tatsächliche Ereigniszuordnung; zur Erklärung dieses Beispiels ist keine Zeitzonenkonvertierung erforderlich. |
| C. Nächster Tag in UTC | 20261023223000-0500 | 2026-10-24 03:30 UTC | Derselbe Zeitpunkt fällt in den nächsten UTC-Tag. Es wird keine Rechtsordnung oder saisonale Regel impliziert. |
| D. Unbekannter Offset | 20261023 und 011500; Quell-Offset nicht verfügbar. | Aus diesem Paar allein lässt sich kein eindeutiger UTC-Zeitpunkt ermitteln. | Ein Empfänger-Fallback muss mit verifiziertem Quellkontext abgeglichen werden; das bloße Fehlen beweist keine Beschädigung. |
| E. Wiederholte lokale Ablesung | 20261023013000-0400 gegenüber 20261023013000-0500 | 05:30 UTC versus 06:30 UTC am 23. Oktober. | Identischer lokaler Text mit unterschiedlichen Offsets beschreibt Zeitpunkte im Abstand von einer Stunde. Dies ist kein datiertes Beispiel für eine Sommerzeitumstellung. |
Quelle: Redaktionelle synthetische Berechnung unter Verwendung fester Offsets; keine Daten von Patienten oder installierten Produkten.
Fall D erfordert ein anderes Ergebnis als die übrigen Fälle: Lassen Sie die UTC-Interpretation unaufgelöst. Fragen Sie nach der Zeitzonenkonfiguration der Quelle und der Fallback-Richtlinie des Empfängers. Ein geschätzter Offset kann eine saubere Konvertierung erzeugen und dennoch falsch sein. Dokumentieren Sie, ob jeder Offset codiert, in der Konfiguration dokumentiert oder lediglich angenommen wurde.
Könnten Untersuchungsbeginn und Akquisition schlicht unterschiedliche Ereignisse sein?
Unterschiedliche Ereignisdaten können die Beobachtung ebenfalls ohne jede Zeitzonenkonvertierung erklären. Der Untersuchungsbeginn ist nicht der Akquisitionsbeginn, und keines von beiden ist der Archiveingang. Die folgende fiktive Sequenz verwendet durchgehend einen festen Offset von +00:00. 7 8
Gehen Sie davon aus, dass die Testimplementierung die folgenden Ereignisse aufzeichnet. Das Beispiel veranschaulicht die Bedeutung von Ereignissen; es behauptet nicht, dass alle Scanner beim selben Tastendruck Zeitstempel vergeben.
- Der Untersuchungsbeginn wird am 22. Oktober um 23:45 aufgezeichnet.
- Die Akquisition von Daten für eine spätere Instanz beginnt am 23. Oktober um 00:15.
- Der Empfänger zeichnet den Empfang noch später auf. Dieser Empfangszeitstempel gehört zum Empfängerereignis.
Die ersten beiden Datumsangaben können beide korrekt sein. Überprüfen Sie, welches Feld die Benutzeroberfläche als Untersuchungsdatum kennzeichnet und welches Feld ihr Filter verwendet. Gehen Sie nicht davon aus, dass ein Listendatum, ein Bild-Overlay und ein Befundportal alle dasselbe Ereignis auswählen. Das nachstehende Lumify-Beispiel zeigt, warum eine releasespezifische Ereigniszuordnung wichtig ist.
Falls die Datensätze stattdessen eine unmögliche Reihenfolge klinischer Ereignisse nahelegen, leiten Sie diese Frage an die zuständigen klinischen Verantwortlichen und Dokumentationsverantwortlichen weiter. Dieses technische Protokoll kann nicht feststellen, was mit einem Patienten geschehen ist. Ein Serviceteam sollte die beobachteten Werte und Unsicherheiten melden, ohne die Untersuchung stillschweigend umzubenennen, damit zwei Bildschirme übereinstimmen.
Warum könnte eine nach Datum gefilterte Abfrage einen vorhandenen Datensatz übergehen?
Wenn eine Untersuchung in einer nach Datum gefilterten Liste fehlt, identifizieren Sie zunächst den Suchpfad. Ein Worklist-Filter der Anwendung ist möglicherweise eine lokale Datenbankoperation; eine Archivabfrage verwendet möglicherweise DICOM Query/Retrieve (Q/R); ein Scanner, der geplante Aufträge abruft, verwendet möglicherweise Modality Worklist (MWL). Alle drei als „Worklist-Abfrage“ zu bezeichnen, verschleiert die benötigten Nachweise.
Im Rahmen einer autorisierten Überprüfung kann eine bekannte Untersuchung, die über eine andere Suche gefunden wurde, zeigen, dass ein Datumsfilter sie ausgeschlossen hat. Dies belegt jedoch nicht, warum. Sichern Sie die angeforderten Grenzen, das durchsuchte Feld, die Antwort sowie jede zusätzliche clientseitige Filterung. Bitten Sie den Verantwortlichen, die Auswahl mit einem synthetischen Datensatz zu reproduzieren, bevor Sie eine produktive Abfrage ändern.
Für das Q/R-Single-Value-Matching schreibt PS3.4 C.2.2.2.1.3 eine Anpassung vor, wenn Timezone Query Adjustment ausgehandelt wurde und der Offset im Identifikator bereitgestellt wird. Das Conformance Statement beschreibt das Implementierungsverhalten. Es gibt keine allgemeine Regel, dass jede nicht ausgehandelte Abfrage Literalzeichenfolgen vergleicht. 4
- Bereichsabgleich: Ein TM-Bereich kann Mitternacht nicht überschreiten. DT-Bereiche berücksichtigen codierte Offsets. Ein ausgehandelter kombinierter DA/TM-Abgleich kann die gepaarten Grenzen als kontinuierliches Intervall behandeln; die Bereichsregeln erlauben zudem eine Offset-Anpassung unabhängig von anderen erweiterten Aushandlungen. Prüfen Sie die unterstützten Schlüssel und die genaue Implementierung. 5
- DT-Abfragen mit negativem Offset: Ein negativer Offset kollidiert mit dem Bindestrich, der zur Unterscheidung von Einzelwert- und Bereichsabgleich verwendet wird. Dies ist eine Einschränkung der Abfragesyntax, keine Ungültigkeit von DT mit negativem Offset in gespeicherten Objekten. Der Aufbau von Abfragen liegt beim Integrationsverantwortlichen. 4
- Nachweisanforderung: Sichern Sie bei einer DICOM-Abfrage den Dienst bzw. die SOP-Klasse, die unterstützten Schlüssel, die Roh-Anfrage und -Antwort, den Offset und die relevante Aushandlung. Sichern Sie bei einem Benutzeroberflächen-Filter dessen Feld- und Zonenrichtlinie. Ein Screenshot allein kann keinen der beiden Abgleichalgorithmen belegen.
MWL hat separate Offset-Bedingungen für Anfrage und Antwort in K.4.1.1.3. K.6 spezifiziert ein kontinuierliches Intervall für den geplanten Beginn, wenn sowohl der Schlüssel für das geplante Datum als auch für die geplante Uhrzeit einen Bereichsabgleich verwenden. Übertragen Sie die Q/R-Aushandlungsregel nicht auf MWL und nehmen Sie nicht an, dass ein Viewer-Filter einen der beiden Dienste implementiert. 6 15
Was belegen die genauen Lumify- und PACS-Dokumente?
Die nachstehenden Dokumente belegen ausgewählte Verhaltensweisen auf verschiedenen Schichten. Sie stellen kein Kompatibilitätsranking und keine geprüfte Sender-Empfänger-Paarung dar. Ein Produktname ohne dessen Release ist unzureichend: Rufen Sie die zur installierten Software passende Erklärung ab und bitten Sie den Systemverantwortlichen, die lokale Konfiguration zu bestätigen.
Nutzen Sie das dokumentierte Verhalten, um eine überprüfbare Frage zu formulieren. Stellen Sie die Unbekannten den Fakten gegenüber, insbesondere bei der Lektüre historischer Unterlagen. Eine Konformitätserklärung beschreibt eine Implementierung; sie bescheinigt nicht den Zustand einer Installation.
| Produkt und Dokument | Dokumentiertes Verhalten | Evidenzgrenze | Frage an den Verantwortlichen |
|---|---|---|---|
| Philips Lumify Release 5.0, HSDP-1299212 9 | Tabelle 41, S. 38 ordnet Study Date/Time dem Beginn des durchgeführten Schritts zu. Tabelle 43, S. 40–41 erfasst diesen Beginn beim Schließen der Patientendateneingabe. | Getrennte DA/TM-Felder; diese Zuordnung belegt kein Weglassen des Bild-Offsets. | Verwendet das installierte Release diese Ereigniszuordnung, und welcher Offset-Kontext begleitet dessen Ausgabe? |
| Philips IntelliSpace PACS 4.4.551.0, 31. März 2017 (historisch) 10 | MWL-Hinweis [3], S. 89–90, verwendet den Anfrage-Offset, dann die DMWL-Konfiguration, danach den Server-Offset als Fallback; geplante Werte werden für die Client-Zone zurückgegeben, ohne das Offset-Attribut zurückzugeben. | Dies ist MWL-Verhalten für ein historisches Release, keine Normalisierungsrichtlinie für die Bildspeicherung. | Welcher Anfrage- und welcher konfigurierte Offset wurden tatsächlich angewendet? |
| Dedalus DeepUnity PACSonWEB 3.4.300 Handbuch, 3. März 2026 11 | Benutzerseitige Datumsangaben und Filter verwenden die Benutzerzone; die Interpretation der Kundenzone ist dokumentiert. Die Roh-Tag-Anzeige ist unkonvertiert, mit hinzugefügtem Offset; Geburtsdaten bilden eine Ausnahme. | Der Tag-Dialog ist eine Anwendungsansicht, kein unabhängiger Nachweis dafür, dass gespeicherte Bytes niemals modifiziert wurden. | Welche Benutzer-/Kundenzone und welches Feld haben das angezeigte Datum erzeugt? |
| Lifetrack LifeSys Support, März 2019 (historisch) 12 13 | Der Support unterscheidet das von der Modalität gesetzte Study Date von anderen standardmäßigen UTC-Zeitstempeln und behandelt Anfragen zu falschem Study Date. | Eine einzelne historische Support-Linie; keine Prävalenzschätzung oder universelles Korrekturverfahren. | Folgt die installierte Version dieser Unterscheidung? |
Quelle: Genannte primäre Produktdokumente; ausgewählte Beispiele über verschiedene Workflow-Ebenen hinweg.
Eine nützliche Gegenprüfung ist das Dedalus-Handbuch: Es erläutert die Zeitzonendarstellung für die eigene Anwendung bereits klar. Der praktische Beitrag besteht hier im systemübergreifenden Evidenzpaket und der Zuständigkeitsentscheidung. Vergleichen Sie bei einem realen Vorfall die Quell-, Empfänger- und Anzeigestufen, anstatt ein einzelnes Handbuch als allgemeingültige Erklärung zu behandeln.
Wer ist für Untersuchungen zu Anzeige, Quell-Metadaten und Geräteuhr zuständig?
Die folgende Zuweisungsmatrix ist eine redaktionelle Hilfestellung für eine gemeinsame Untersuchung. Sie stellt keine Ferndiagnose dar und ersetzt nicht die Verantwortlichkeiten der Einrichtung. Lokale Teams können diese Rollen anders zuweisen; benennen Sie einen namentlichen Verantwortlichen und die nächste Evidenzanforderung, bevor Sie das Ticket schließen.
Weisen Sie anhand der verifizierten Beobachtung zu. Wo eine Zeile noch mehrere Erklärungen zulässt, halten Sie diese offen, bis der nächste Vergleich sie unterscheidet.
| Beobachtete Evidenz | Nächster Vergleich | Einschränkung der Schlussfolgerung | Vorgeschlagener Verantwortlicher |
|---|---|---|---|
| Empfangener Rohwert und Viewer-Datum weichen voneinander ab. | Vergleichen Sie das angezeigte Ereignis, die Benutzer-/Kunden-Zeitzone und die Darstellungsrichtlinie; anschließend bei Bedarf Quell- mit empfangenen Werten. | Eine Umrechnung für die Darstellung ist eine Hypothese, bis Richtlinie und Arithmetik übereinstimmen. | PACS-Administrator / Herstellersupport |
| Studienbeginn und Erfassung weisen aneinandergrenzende Datumsangaben auf. | Bestimmen Sie jedes Ereignis und dessen Offset; prüfen Sie die installierte Ereigniszuordnung. | Unterschiedliche Ereignisse können die Differenz erklären, belegen für sich allein jedoch keine korrekten Quelluhren. | Bildgebende Informatik / Modalitätenspezialist |
| Ein Datumsfilter schließt einen separat abgelegten Datensatz aus. | Identifizieren Sie die Filterung im Viewer, Q/R oder MWL; sichern Sie Schlüssel, Grenzen und die anwendbare Aushandlung. | Der Ausschluss allein belegt weder einen Verlust noch einen Zeitzonenfehler. | PACS-Integrationsingenieur |
| Eine Gangabweichung oder ein Zurücksetzen der Scanner-Uhr wird unabhängig beobachtet. | Erfassen Sie das Symptom und die bestehende Zeitsynchronisationskonfiguration; veranlassen Sie eine qualifizierte modellspezifische Bewertung. | Konfiguration, Synchronisation, Software und Hardware bleiben mögliche Bereiche. Durch diese Beobachtung allein wird kein Bauteil identifiziert. | Medizintechnik / qualifizierter Scanner-Service |
| Identität oder zeitliche Abfolge klinischer Ereignisse bleibt unklar. | Sichern Sie die Datensätze und leiten Sie die Unklarheit über den Vorfall-Workflow der Einrichtung weiter. | Erzwingen Sie keinen Abgleich, ändern Sie keine Datumsangaben und leiten Sie keine klinische Chronologie ab. | Autorisierte Verantwortliche für Identität, Dokumentation und Klinik |
Quelle: Redaktioneller Zuweisungsrahmen auf Basis des Quellenvergleichs; kein freigegebenes Protokoll von Rongtao.
Ein scannerseitiges Uhrensymptom kann eine weitergehende Begutachtung rechtfertigen, ohne eine Ersatzplatine zu rechtfertigen. Vermeiden Sie improvisierte Verfahren zur Netztrennung oder Batteriespannungsprüfung aus einem allgemeinen Artikel. Nutzen Sie die bestehende Anleitung, um ein Ausgabeproblem von einer Frage der I/O-Platine abzugrenzen, und leiten Sie tatsächliche Symptome beim Systemstart oder beim Erhalt der Uhrzeit an den qualifizierten Host-System-Servicepfad weiter.
Wie sollte eine synthetische Abnahmeprüfung die Dokumentation sichern?
Vereinbaren Sie für eine Abnahme oder eine Software-/Konfigurationsänderung einen synthetischen Test mit den Verantwortlichen für Modalität und PACS. Verwenden Sie eine genehmigte Testumgebung und eine Testidentität der Einrichtung und halten Sie Testdatensätze aus klinischen Arbeitslisten fern, es sei denn, die Einrichtung verfügt über einen expliziten, kontrollierten Workflow. Eine Simulation kann die Arithmetik prüfen, ohne die Uhr eines Produktiv-Scanners zu verändern.
Die folgende Checkliste schlägt aufzubewahrende Nachweise vor. Sie stellt kein OEM-Verfahren, keinen Standard für Uhrentoleranzen und keinen Nachweis der Eignung für den klinischen Einsatz dar. Umfang, zulässige Maßnahmen, Abnahmekriterien und Freigabe gehören in den von der Einrichtung genehmigten Plan.
| Stufe | Aufzeichnung | Abnahmefrage | Stopp oder Eskalation |
|---|---|---|---|
| 1. Ausgangszustand | OEM/Modell, Software, zugehörige Dokumente, Quelluhr/-zeitzone und unterstützte Zeitsynchronisationskonfiguration. | Sind Quell- und Empfängerkontexte bekannt und dokumentiert? | Belassen Sie unbekannte Offsets unaufgelöst; erfinden Sie keine allgemeingültige Uhrentoleranz. |
| 2. Kontrollierte Eingabe | Genehmigte Testidentität, Ereignisabfolge und synthetische Werte oder autorisierte Phantomuntersuchung. | Lässt sich die Eingabe ohne Patientendaten oder Änderungen der Systemuhr im Produktivbetrieb nachvollziehen? | Verwenden Sie das freigegebene modellspezifische Prüfverfahren; es ist keine universelle Frame-Anzahl erforderlich. |
| 3. Objektvergleich | Original- und empfangene Werte, Offsets und relevante Objektidentitäten. Erfassen Sie das Fehlen getrennt von leeren Feldern. | Stimmt jeder Wert mit seinem dokumentierten Ereignis und der beabsichtigten Interpretation überein? | Bewerten Sie den Test nicht allein deshalb als nicht bestanden, weil ein lokales Datum von einer UTC-Anzeige abweicht. |
| 4. Anzeige und Suche | Viewer-Feld/-Bereich, angezeigtes Ergebnis, Filtergrenzen und Nachweise des Abfragedienstes, sofern zutreffend. | Folgt die beobachtete Ausgabe der dokumentierten Richtlinie, einschließlich der Grenzfälle? | Unerklärte Konvertierungen oder Ausschlüsse gehen an den zuständigen Integrationsverantwortlichen. |
| 5. Entscheidung | Befund, verbleibende Unsicherheit, autorisierte Änderungen, Nachtestergebnis und verantwortliche Freigabe. | Hat der Verantwortliche die ursprüngliche Beobachtung innerhalb des vereinbarten Umfangs gelöst? | Ein anhaltendes Scanner-Symptom geht an eine qualifizierte Beurteilung; diese Checkliste kann die Rückkehr in den klinischen Einsatz nicht autorisieren. |
Quelle: Redaktioneller Vorschlag für ein Abnahmeprotokoll; wenden Sie die Verfahren der Einrichtung und des OEM an.
Bewahren Sie den ursprünglichen klinischen Datensatz. Verwenden Sie Ad-hoc-Tag-Umschreibungen, Löschungen oder erneutes Senden nicht als Abkürzung, um ein Datum an eine Bildschirmanzeige anzupassen. Eine bestätigte Korrektur erfordert den autorisierten Datensatzverantwortlichen und den geregelten Prozess der Einrichtung.
DICOM bietet Mechanismen zur Aufzeichnung früherer Attributwerte und des Änderungskontexts. Diese Mechanismen stellen keine vollständige rechtliche oder einrichtungsbezogene Änderungsrichtlinie dar. Eine technische Erklärung der Diskrepanz sollte jeder autorisierten Korrektur beigefügt werden, einschließlich dessen, was geändert wurde, warum und was weiterhin ungewiss ist. 2
Halten Sie benachbarte Entscheidungen getrennt. Identitätsunsicherheit erfordert den Pfad zum Abgleich der Patientenidentität. Für einen abgeschlossenen Auftrag, der offen bleibt, ist eine Untersuchung des MPPS-Status vorgesehen. Archivierungsverantwortung und lokale Vorhaltung erfordern Storage-Commitment-Nachweise; ein Datumsfilter-Ergebnis kann diese Entscheidung nicht klären.
Wo Rongtao passt – und wo nicht
Zu den veröffentlichten Dienstleistungen von Rongtao gehören die Reparatur von Ultraschallplatinen/-baugruppen, Diagnosen auf Systemebene und geprüfte Ersatzteile. Dieser Bericht hilft bei der Vorbereitung der technischen Nachweise für eine Servicebewertung; er begründet keine bestimmte RTC-Reparaturfähigkeit, Teileverfügbarkeit oder einen erfolgreichen Zeitzonenfall. 14
Wo Rongtao Medical passt:
- Wenn der Scannerservice weiterhin relevant ist: Senden Sie das unabhängig beobachtete Gerätesymptom und die installierte Konfiguration ein, damit der vorgeschlagene Umfang bewertet werden kann. Modell, Platinenrevision und Fehlernachweise müssen einer Teileempfehlung vorausgehen.
- Wenn die Nachweise an anderer Stelle hingehören: Archivanzeigerichtlinien, Worklist-Integration und Änderungen klinischer Datensätze erfordern die zuständigen Teams der Einrichtung und Herstellersupport. Dieser Bericht ist kein Angebot zur Administration dieser Systeme.
- Vor einem Angebot: Prüfen Sie den dokumentierten Serviceprozess und vereinbaren Sie die Bewertung, Prüfung und Lieferumfänge für den konkreten Artikel. Schließen Sie nicht aus einer Datumsdifferenz von einem Tag auf Kompatibilität oder Reparierbarkeit.
Rongtao ist ein unabhängiger Service- und Teileanbieter. OEM-Namen kennzeichnen hier dokumentierte Geräte oder Software; sie implizieren keine Autorisierung oder Billigung durch den OEM.
- Belassen Sie identifizierbare Studien, Header und Protokolle innerhalb der von der Einrichtung genehmigten Kanäle. Ein entfernter Patientenname allein macht ein vollständiges DICOM-Objekt nicht für eine kommerzielle Anfrage geeignet.
- Stellen Sie vorhandene Fotos von Etiketten oder Platinen nur bereit, wenn diese durch qualifizierte Handhabung sicher verfügbar sind. Zerlegen Sie Geräte nicht nur, um ein Foto für ein Angebot zu erhalten.
Für eine bereinigte System-Serviceanfrage geben Sie OEM, genaues Modell, installierte Software, Symptom-/Fehlertext, wann die Diskrepanz auftritt, welches Ereignis jeder Bildschirm anzeigt sowie den bekannten Offset-Kontext an. Falls Hardware betroffen ist, geben Sie die Hersteller-Teilenummer/-Revision an und fügen Sie gefahrlos verfügbare Fotos des Typenschilds oder beidseitige Fotos bei. Geben Sie Stückzahl und Zielland an. Fordern Sie eine Beurteilung des beobachteten Symptoms an, anstatt eine nicht verifizierte ausgefallene Platine zu benennen.
Häufig gestellte Fragen
Bedeutet ein fehlendes Zeitzonen-Offset-Feld UTC?
Nein. Schließen Sie aus dem Fehlen nicht auf einen Null-Offset. Ein explizites DT-Suffix kann Kontext liefern; andernfalls ermitteln Sie den Quellkontext und prüfen Sie vor der Konvertierung die dokumentierte Interpretation des Empfängers.
Kann eine Studie vor Mitternacht beginnen und spätere Akquisitionen enthalten?
Ja. Es handelt sich um unterschiedliche Ereignisse. Prüfen Sie deren Definitionen und Offsets, bevor Sie die Datumsangaben als inkonsistent bezeichnen. Der Akquisitionsbeginn ist nicht automatisch der Zeitpunkt des Einfrierens oder Speicherns des Bildes.
Beweist ein erfolgreicher Bildversand, dass das angezeigte Datum korrekt ist?
Nein. Der Übertragungsstatus validiert weder das für die Anzeige ausgewählte Ereignis noch dessen Konvertierung. Bestätigen Sie die tatsächlichen Werte und die Darstellungsrichtlinie separat; nutzen Sie die Leitlinien zur Archivierungsverantwortung für Entscheidungen zur Aufbewahrung.
Verwenden Modality Worklist und Archiv-Query/Retrieve einen identischen Datumsabgleich?
Nein. Sie haben unterschiedliche Bestimmungen für den Abgleich. Der Datumsfilter eines Viewers kann sich wiederum unterscheiden. Ermitteln Sie den tatsächlichen Dienst und die Konfiguration, bevor Sie eine Abfrageregel anwenden.
Kann eine Änderung der heutigen Uhrzeit bereits im PACS gespeicherte Datumsangaben korrigieren?
Das Ändern der Quelluhrzeit allein schreibt zuvor erzeugte Instanzen nicht um. Das zukünftige Verhalten hängt zudem von der Konfiguration und der Ereigniszuordnung ab. Historische Korrekturen erfordern den autorisierten Workflow für Datensätze, anstatt anzunehmen, dass eine Änderung der Uhrzeit alte Studien aktualisiert.
Sollte eine Differenz von einem Tag einen Platinenaustausch auslösen?
Nein. Dies ist ein unzureichender Beleg für eine ausgefallene Komponente. Stellen Sie fest, ob das Problem die Ereignisbedeutung, die Offset-Interpretation, eine Abfrage oder ein unabhängig beobachtetes Scanner-Symptom betrifft. Eine qualifizierte Beurteilung muss einen etwaigen Reparaturbedarf feststellen.