Zwei Krankenhäuser verwenden dieselbe Patientennummer: Prüfen Sie den Issuer vor dem Ultraschall-Import

Das Support-Ticket: eine bekannte Nummer bei einer externen Untersuchung

Fiktives Fallbeispiel: Krankenhaus A empfängt eine Ultraschalluntersuchung von Klinik B auf freigegebenen Übertragungsmedien. Ihre Patient ID lautet 940218, eine Nummer, die lokal bereits vergeben ist. Das empfangende Bildarchivierungs- und Kommunikationssystem (PACS) zeigt eine mögliche Patientenübereinstimmung an. Das Medizintechnik-Team wird gefragt, ob das Ultraschallgerät defekt ist oder ob die Untersuchung dieser Patientenakte zugeordnet werden kann.

Die Nummer allein kann keine der beiden Fragen klären. Klinik B hat sie möglicherweise einer anderen Person zugewiesen, oder dieselbe Person verfügt in beiden Organisationen über Kennungen. Ein Header kann zudem eine fehlerhafte Registrierungsauswahl enthalten. Eine ungeklärte Übereinstimmung sollte im freigegebenen Ausnahmeworkflow der Einrichtung verbleiben, während die Verantwortlichen für PACS und Patientenidentität die Quelldatensätze überprüfen. Gehen Sie nicht davon aus, dass jedes Importprodukt dieselbe Warnung anzeigt oder eine Isolationsfunktion bereitstellt.

Ein Overlay verknüpft Datensätze verschiedener Personen; ein frakturierter Datensatz trennt Datensätze, die zu einer Person gehören. Dennisons Facharbeit zum Reifegrad der Patientenidentität erörtert beide Risiken in konsolidierten Bildgebungsunternehmen. Eine Prüfung des Ausstellers adressiert den Geltungsbereich der Kennung, kann jedoch für sich allein nicht belegen, dass die ursprüngliche Aufnahme dem richtigen Patienten zugeordnet wurde. ⁵

Was beweist eine DICOM-Patient-ID – und was verspricht der Standard niemals?

Der Standard Digital Imaging and Communications in Medicine (DICOM) trennt Kennungen für Patienten, Aufträge und Studien voneinander. Die Study Instance UID (0020,000D) ist eine eindeutige Studienkennung; die Patient ID (0010,0020) ist die von einer vergebenden Stelle verwendete Patientenkennung. Eine korrekt formatierte Studienkennung validiert die Zuordnung zum Patienten nicht. ^{2 3}

In DICOM PS3.3 Abschnitt C.7.1.1 (Patient Module, Tabelle C.7-1) wird das Attribut Patient ID (0010,0020) schlicht wie folgt definiert: ²

Patient ID (0010,0020): Primäre Kennung für den Patienten.— DICOM PS3.3 Abschnitt C.7.1.1 Tabelle C.7-1

Die Patient ID ist im zitierten Patient Module vom Typ 2: Das Element ist erforderlich, ein unbekannter Wert darf jedoch leer sein. Ihre Definition verleiht ihr keine universelle Eindeutigkeit. Die praktische Frage ist, welches Identifikationsschema den Wert zugewiesen hat und ob das empfangende System über ein verifiziertes Mapping für dieses Schema verfügt. Eine fehlende oder temporäre Kennung erfordert den lokalen Abgleichsprozess, anstatt anzunehmen, dass die Untersuchung ungültig ist. ^{1 2}

So können beispielsweise das fiktive Krankenhaus A und die Klinik B jeweils 100452 verwenden. Eine übereinstimmende Zeichenkette zeigt nicht, ob ihre Datensätze dieselbe Person beschreiben. Schließen Sie nicht allein aus Nummernlänge, Interpunktion, einem vertrauten Präfix oder dem Transport-Endpunkt auf das Ausstellerschema. Belassen Sie die ausstellende Stelle und deren Provenienz während der Überprüfung bei der Nummer.

Was der Aussteller und seine Qualifikatoren festlegen

Issuer of Patient ID identifiziert die Stelle, die die Patientennummer ausgestellt hat. Die Identitätsdomäne ist das ausstellende Schema; die Patientenkennung wird innerhalb dieser Domäne interpretiert. DICOM PS3.3 Abschnitt 10.15 definiert das Issuer-Makro und dessen Beziehung zum Datentyp HL7 v2 CX, der in PID-3 verwendet wird. Die zitierte aktuelle Ausgabe und die Ausgabe 2019e enthalten diesen Mechanismus. ^{1 4}

Die Vergabestelle kann ein System, eine Organisation, eine Behörde oder eine Abteilung sein. Das Issuer-Attribut entspricht der lokalen Namensraumkomponente der zuweisenden HL7-Stelle. Ein bloßer Wert wie RIS ist nur innerhalb einer vereinbarten Konfiguration aussagekräftig: Unabhängige Organisationen können dieselbe Bezeichnung verwenden. Umgekehrt können historische und aktuelle Issuer-Bezeichnungen genehmigte Aliase für eine einzelne Domäne sein. Vergleichen Sie konfigurierte Zuordnungen der Vergabestellen, nicht nur die reine Textgleichheit. ^{1 5}

Die optionale Issuer of Patient ID Qualifiers Sequence (0010,0024) liefert weiteren Kontext zur Vergabestelle oder zum Identifikator. Es ist nur ein Item zulässig. Zu ihren Komponenten gehören: ¹

• Universal Entity ID (0040,0032): ein universeller oder eindeutiger Identifikator für die Vergabestelle. Wenn sowohl dieser als auch Issuer of Patient ID vorhanden sind, müssen sie dieselbe Vergabestelle identifizieren.
• Universal Entity ID Type (0040,0033): erforderlich, wenn Universal Entity ID vorhanden ist; kennzeichnet das verwendete Format. Prüfen Sie die im Standard definierten Begriffe und das lokale Register der Vergabestellen.
• Identifier Type Code (0040,0035): beschreibt den Identifikatortyp anhand der HL7-Tabelle 0203. Dies unterscheidet sich von Type of Patient ID (0010,0022), dessen definierte Begriffe TEXT, RFID und BARCODE umfassen.
• Assigning Facility Sequence (0040,0036), Assigning Jurisdiction Code Sequence (0040,0039) und Assigning Agency or Department Code Sequence (0040,003A): liefern Kontext zu Standort, Zuständigkeitsbereich oder Behörde. Diese berechtigen den Leser nicht dazu, eine fehlende Vergabestelle zu erraten.

Typ 3 beschreibt das optionale Vorhandensein; dies ist kein Maß dafür, wie häufig ein Feld befüllt wird. Das PIM3-Modell beschreibt Level-0-Systeme dahingehend, dass sie von einer einzelnen Identitätsdomäne ausgehen, anstatt Patientenidentifikatoren über Domänen hinweg zu qualifizieren. Das Zusammenführen von Domänen ohne geeignete Kontrollen kann Kollisionen verursachen; dies ist ein Risiko, kein unvermeidliches Ergebnis jedes Imports. ^{1 5}

Warum hat der Standard ein Attribut zurückgezogen, weil ihm ein Issuer fehlte?

Das Patient Module stellt zudem die Other Patient IDs Sequence (0010,1002) für alternative Identifikatoren bereit. Dies ist relevant, wenn eine Person Identifikatoren bei mehreren Organisationen hat: Eine zweite Nummer ist nicht automatisch eine zweite Person. ²

Die aktuelle Tabelle erläutert, dass diese Sequenz das zurückgezogene Attribut Other Patient IDs (0010,1000) ersetzte, dessen einzelnen Werten ein Issuer fehlte. Dies unterstützt die Beibehaltung des Issuer-Kontexts für jeden alternativen Identifikator. Es dokumentiert keine Kollisionsrate und macht optionale Issuer-Werte nicht verpflichtend. ²

Jedes Item eines alternativen Identifikators enthält eine Patient ID sowie Type of Patient ID und bindet das Issuer-Makro ein. Die Issuer-Attribute in diesem Makro bleiben optional. Prüfen Sie den Geltungsbereich jedes Items, anstatt davon auszugehen, dass jede alternative Nummer die Vergabestelle der obersten Ebene erbt. ^{1 2}

Für ein Serviceteam besteht die praktische Konsequenz in einer Frage des Nachweises: Behält der empfangene Datensatz die Vergabestelle für den verglichenen Identifikator bei? Eine Sequenz, die Issuer-Informationen aufnehmen kann, ist kein Beweis dafür, dass der Sender sie befüllt hat oder dass der Empfänger sie korrekt verwendet.

Warum ist die Auftragsidentität keine Patientenidentität? Accession-Nummern und ihr eigener Aussteller

Eine Übereinstimmung der Accession-Nummer kann dem autorisierten Team dabei helfen, einen ursprünglichen Auftrag zu lokalisieren. Sie kann einen Konflikt bei den Patientennachweisen nicht aufheben. Dieselbe Accession-Zeichenkette kann in unabhängigen Vergabesystemen vorkommen, genau wie Patientennummern. Trennen Sie die Vergabestelle des Auftrags von der Vergabestelle, die die Patienten-ID zugewiesen hat.

DICOM PS3.3 Tabelle C.7-3 definiert die Accession-Nummer als Bezeichner des Abteilungsinformationssystems für einen Imaging Service Request. Ihre optionale Issuer of Accession Number Sequence grenzt den Geltungsbereich dieses Anforderungsbezeichners ein. ³

Die Unterscheidung ist praxisrelevant: Ein Patient kann mehrere Aufträge haben, und eine empfangende Einrichtung kann einen eigenen Auftrag für eine externe Studie anlegen. Erhalten Sie die Verbindung zum externen Auftrag über den freigegebenen Import-Workflow aufrecht. Eine Accession-Aussteller-Sequenz mit einem einzelnen Element speichert keine zwei Accession-Nummern. ^{3 12}

Unser Leitfaden zum MPPS-Worklist-Status behandelt den Status von Prozedurschritten und deren Auftragsverknüpfungen. Dieser Artikel beschränkt sich auf Nachweise zur Patientenidentität: Weder ein abgeschlossener Workflow-Status noch eine scheinbar eindeutige Accession-Nummer beweist, dass eine externe Studie zu einer lokalen Patientenakte gehört.

Der Import-Abgleich kann berechtigterweise lokale Patienten- und Prozedurinformationen verwenden, die über Worklists oder demografische Abfragen bezogen wurden. IHE beschreibt dies als einen Integrations-Workflow mit Ausnahmebehandlung für fehlerhafte Auswahlen. Verwechseln Sie eine Importoption, die die Auftragsnummerierung auflöst, nicht mit einer verifizierten Patientenübereinstimmung. Folgen Sie dem dokumentierten Workflow des Empfängers statt einer allgemeingültigen Regel darüber, was ein Assistent tun muss. ¹²

Wie gehen reale Ultraschallketten mit Ausstellern um? Nachweise aus Conformance Statements

Diese Beispiele beschreiben verschiedene Rollen in der Kette: Modalitäten erstellen Instanzen, ein Worklist-Broker liefert Informationen und ein Archiv ergänzt möglicherweise Attribute. Sie stellen weder eine Rangliste noch eine Kompatibilitätsmatrix oder einen Nachweis dar, dass sich eine bestimmte Installation wie getestet verhält. Die Zeilenbeschränkungen sind ebenso wichtig wie das angegebene Verhalten.

• GE Venue 40 v2.xx, DOC0837847 Rev 2, Tabelle 3-3, S.24: Die Patienten-ID stammt aus der Eingabe über die Benutzeroberfläche (UI) oder aus der Worklist; Issuer of Patient ID ist als aus der Worklist stammend dokumentiert. Das Dokument führt keine manuelle Quelle für den Aussteller auf. Prüfen Sie einen zulässigen Testexport, bevor Sie darauf schließen, was bei einem bestimmten installierten Build fehlt. Das PDF trägt einen Copyright-Vermerk von 2011; sein Hosting-Pfad enthält Datumsangaben aus 2018, bei denen es sich nicht um ein Software-Freigabedatum handelt. ⁷
• ExactVu 2.9/3.0, Rev 1.3, Abschnitt 4.2.2.3.1.3: Die Tabelle der erstellten Instanzen kennzeichnet die Patient ID als aus der Modality Worklist (MWL) bezogen, sofern verfügbar, und andernfalls als generiert; die Issuer-Zeile ist als generiert gekennzeichnet. Das Dokument erläutert, dass generierte Werte aus Benutzereingaben, Aufnahmedetails oder einer Zufallszeichenfolge stammen können; es spezifiziert weder den Issuer-Wert noch, ob Geräte einen gemeinsamen Namensraum teilen. Dies ist in der Tabelle nicht auf Fälle manueller Eingaben beschränkt. ⁸
• Sectra Connectivity Hub 9.5.0.2442, August 2025, Abschnitt 3.2.1, S. 14: Die Worklist-Tabelle bildet die Patient ID aus HL7 PID-3.1 und deren ausstellende Stelle (Assigning Authority) aus PID-3.4 ab. Überprüfen Sie sowohl die eingehenden Werte als auch das konfigurierte Broker-Mapping; die Zeile belegt nicht, was ein nachgelagerter Scanner letztlich speichert. ⁹
• Philips Lumify R5.0, HSDP-1299212, Tabelle 40, S. 38: Das gespeicherte Patient-Modul dokumentiert die Patient ID aus der Worklist, durch Benutzereingabe oder durch Systemgenerierung. Es führt den Issuer of Patient ID in dieser Tabelle nicht auf. Dies ist eine Dokumentationseinschränkung, kein Beleg für eine Remote-AE-Issuer-Konfiguration oder dafür, wie häufig Handheld-Untersuchungen Issuer auslassen. ¹⁰
• dcm4che Archive 5, Dokumentationsversion 5.35, Gerätekonfiguration: Die Issuer-Einstellung stellt Standardwerte bereit und kann von konfigurierten Attributanpassungen (Attribute Coercions) des Archivs genutzt werden, um eine fehlende ausstellende Stelle (Assigning Authority) beim Empfang und bei anderen Transaktionen zu ergänzen. Die Ergänzung hängt von der Aktivierung dieser Konfiguration ab; sie ist kein bedingungsloses Verhalten bei allen eingehenden Untersuchungen. Ein vom Empfänger bereitgestellter Wert darf nicht mit einer senderseitig verifizierten ausstellenden Stelle verwechselt werden. ¹¹

Unterscheiden Sie bei jeder Übertragung Werte, die bereits beim Export vorhanden waren, von Werten, die erst später hinzugefügt wurden. Erfragen Sie die genaue Softwareversion der Modalität, die Versionen von Broker und Archiv sowie die zutreffenden Abschnitte der Konformitätserklärung. Ein generischer Issuer oder ein Standardwert des Empfängers erfordert eine dokumentierte Interpretation. Ein ausgefülltes Feld ist nicht zwingend ein stärkerer Beleg als ein fehlendes Feld, wenn niemand erklären kann, woher sein Wert stammt.

Die Prüfsequenz vor dem Import: Lesen, Vergleichen, Klassifizieren, Weiterleiten

Verwenden Sie diese vierstufige Nachweissequenz innerhalb des genehmigten Importprozesses der Einrichtung. Es handelt sich um eine redaktionelle Synthese der zitierten Standards und Informatikprinzipien, nicht um einen validierten Algorithmus für den Patientenabgleich. Der Bediener, der einen Abgleich autorisiert, sowie die Kriterien hierfür werden durch die Richtlinien der Einrichtung festgelegt. ^{5 6 12}

Stufe 1: Den empfangenen Identitätsblock ohne Änderungen lesen. Ein autorisiertes Teammitglied sollte einen freigegebenen schreibgeschützten Viewer oder ein freigegebenes Metadaten-Tool in der sicheren Umgebung der Einrichtung verwenden. Halten Sie die ursprünglich empfangenen Dateien geschützt. Erfassen Sie, ob es sich bei dem Export um eine originale klinische Übertragung, eine de-identifizierte Kopie oder ein wiederhergestelltes Backup handelt; fehlende Identitätswerte haben in jedem Fall unterschiedliche Auswirkungen.

• Patienten-ID (0010,0020)
• Aussteller der Patienten-ID (0010,0021) und Qualifikatoren-Sequenz (0010,0024)
• Patientenname (0010,0010)
• Geburtsdatum des Patienten (0010,0030) und Geschlecht des Patienten (0010,0040)
• Auftragsnummer (0008,0050) und Aussteller der Auftragsnummer (0008,0051)
• Study-Instance-UID (0020,000D), Series-Instance-UID (0020,000E) und Service-Object-Pair-(SOP)-Instance-UID (0008,0018), um die betroffenen Objekte zu lokalisieren; die SOP-Class-UID (0008,0016) identifiziert den Objekttyp. ^{3 14 15}
• Hersteller und Modellbezeichnung des Herstellers (0008,0070 / 0008,1090), zuzüglich der installierten Softwareversion aus der Geräteakte.

Stufe 2: Identitätsdomänen und Provenienz vergleichen. Vergleichen Sie über autorisierte Systeme die empfangenen Werte mit dem vorgeschlagenen lokalen Datensatz und den bestätigten Registrierungsinformationen der sendenden Organisation. Überprüfen Sie die konfigurierte Autoritätszuordnung, anstatt eine Aussteller-Zeichenkette als Authentifizierung zu behandeln.

• Aussteller scheint übereinzustimmen: Prüfen Sie Qualifikatoren und das Autoritätsregister. Zwei Standorte können beide eine generische Bezeichnung wie RIS verwenden. Selbst eine anerkannte Domäne und übereinstimmende demografische Daten schließen eine ursprüngliche falsche Patientenauswahl nicht aus.
• Aussteller weicht ab: Prüfen Sie, ob die Werte verschiedene Domänen oder freigegebene Aliase für eine Domäne identifizieren. Die Datensätze können unterschiedliche Personen oder dieselbe Person mit domänenübergreifenden Identifikatoren beschreiben. Erzwingen Sie keine Übereinstimmung; bitten Sie das Identitätsteam, die Beziehung zu überprüfen.
• Aussteller fehlt oder ist mit einem Standardwert belegt: Ermitteln Sie, wer die Patienten-ID bereitgestellt hat und ob ein Gateway oder Empfänger eine Autorität hinzugefügt hat. Füllen Sie die Lücke nicht mit einem Kliniknamen, der anhand eines Datenträgeretiketts erraten wurde. Ein fehlendes optionales Feld ist für sich genommen kein Gerätefehler.

Stufe 3: Demografische Daten vergleichen und Unsicherheiten beschreiben. Name, Geburtsdatum und Geschlecht können eine Unstimmigkeit aufdecken, sind jedoch keine eindeutigen Identifikatoren oder fehlersicheren Prüfsummen. Unser Leitfaden zu Zeichensätzen für Patientennamen behandelt Darstellungsprobleme. Geburtsdaten und Geschlechtsangaben können ebenfalls fehlen, falsch eingegeben oder korrigiert worden sein; eine Diskrepanz beweist nicht, dass es sich um zwei verschiedene Personen handelt.

Stufe 4: Entscheidung weiterleiten und dokumentieren. Die autorisierten PACS- und Patientenidentitäts-Teams entscheiden gemäß den lokalen Richtlinien, ob verknüpft, abgeglichen, ein Datensatz angelegt oder der Import abgelehnt wird. Bewahren Sie die ursprünglich empfangene Identität und ein Audit der genehmigten Zuordnungen auf. Falls sich eine Studie möglicherweise bereits in der falschen Patientenakte befindet, eskalieren Sie dies über das Patientensicherheits- und Archivkorrekturverfahren der Einrichtung; wiederholte Importe oder ein informelles Löschen können die Rekonstruktion der Nachweise erschweren.

Fünf fiktive Fälle und die Nachweise zur Eskalation

Die folgenden fünf fiktiven Fälle veranschaulichen, an welchen Stellen die Abfolge der Nachweise die Übergabe verändert. Es handelt sich nicht um Berichte über tatsächliche Patientenvorfälle oder Produkttestergebnisse, und sie enthalten keine Anweisungen zur Import- oder Datenbankkonfiguration.

Fall 1: Zwei Standorte vergeben beide 100452. Krankenhaus A übernimmt Klinik B. Beide verfügen über einen Datensatz mit der Nummer 100452. Das Migrationsteam muss vor dem Verschieben von Studien die ursprüngliche Autorität von Klinik B und die genehmigte lokale Zuordnung verifizieren. Das bloße Voranstellen von Präfixen an Nummern kann Kollisionen trennen, ohne die Datensätze derselben Person domänenübergreifend zu verknüpfen. Lassen Sie die Migration einschließlich der Überprüfung von Ausnahmen von den Verantwortlichen für die Unternehmensidentitäten konzipieren und validieren. ^{5 6}

Fall 2: Ein fahrbares Gerät erstellt eine lokale ID. Eine Untersuchung ohne Worklist verwendet die fiktive Kennung GEN-004. Diese Kennung kann in ihrem lokalen Schema legitim sein, ohne eine einrichtungsweite Patientenaktennummer (MRN) darzustellen. Der Eingabeleitfaden für das Sonosite PX behandelt die Einstellung einer Plattform für generierte IDs; er legt das Ausgabeformat dieses Beispiels nicht fest. Das empfangende Identitätsteam muss die Registrierungsbeziehung verifizieren, bevor die Bilder einer Krankenhausakte zugeordnet werden.

Fall 3: Studien kehren nach der Reparatur zurück. Ein autorisiertes Backup wird nach dem Service erneut importiert. Vergleichen Sie die beibehaltenen Kennungen von Studie, Serie und SOP-Instanz sowie die Patientennachweise mit dem Archiveintrag. Eine Übereinstimmung der Study-UID allein belegt weder identische Instanzen noch schließt sie einen Fehler bei der Patientenzuordnung aus. Bewahren Sie das Backup auf, während der Archiveigentümer die Untersuchung durchführt. Der Leitfaden zum Umgang mit Daten vor der Reparatur regelt Entscheidungen zur Aufbewahrung und Bereinigung; dieser Fall berechtigt nicht zu Löschungen oder UID-Änderungen.

Fall 4: Der empfangende Standort legt einen neuen Auftrag an. Krankenhaus B vergibt eine lokale Accession-Nummer, während das empfangene Bild die Accession-Nummer von Krankenhaus A trägt. Erfassen Sie beide im genehmigten Abgleichssystem mit ihren korrekten Autoritäten. Die Issuer of Accession Number Sequence definiert den Geltungsbereich für eine einzelne Accession-Nummer und lässt nur ein einziges Element zu; das Hinzufügen eines weiteren Ausstellers an dieser Stelle ist kein Weg, um zwei Aufträge beizubehalten. Die für das PACS und das Radiologie-Informationssystem (RIS) zuständigen Teams müssen ihre unterstützte Zuordnung von extern nach lokal verwenden. ^{3 12}

Fall 5: Eine bekannte Nummer mit abweichendem Geburtsdatum. Ein externer Datenträger enthält die fiktive Patienten-ID 55412 und keinen Issuer. Der infrage kommende lokale Datensatz weist denselben Namen, aber ein anderes Geburtsdatum auf. Halten Sie die vorgeschlagene Zuordnung an und holen Sie verifizierte Registrierungsinformationen der Quelle ein. Die Diskrepanz kann eine Kollision oder ein Registrierungsfehler sein. Schließen Sie nicht auf eine neue Person, legen Sie keinen Gastdatensatz an und tragen Sie auf Basis der Datenträgerbeschriftung keinen erfundenen Issuer ein.

Wenn die Identität unklar ist: Demografiedaten, Provenienz und die strikten Stopps

Die serviceseitige Grenze besteht darin, Nachweise zu sichern und unautorisierte Änderungen an klinischen Datensätzen zu vermeiden. Wenn Kliniker eine ungesicherte externe Untersuchung dringend benötigen, nutzen Sie den Pfad der Einrichtung zur dringlichen Identitätsprüfung und klinischen Eskalation. Ein Artikel kann dieses Verfahren nicht ersetzen. Für die Untersuchung im Support gelten diese drei Grenzen:

• Modifizieren Sie Identitäts-Tags nicht, um eine Datei passend zu machen. Behalten Sie das empfangene Original bei und nutzen Sie eine freigegebene schreibgeschützte Überprüfung. Unkontrollierte Änderungen können die Provenienz verschleiern und zu einer Fehlzuordnung führen. Bewahren Sie die empfangenen Originaldateien und das Prüfprotokoll jedes autorisierten Abgleichs auf.
• Akzeptieren Sie eine vorgeschlagene Zuordnung nicht ohne die erforderlichen Nachweise. Ein autorisierter Importabgleich darf Kennungen und Demografiedaten legitim zuordnen. Die IHE spezifiziert Workflows dafür; der Unterschied besteht in einer verifizierten, dokumentierten Zuordnung gegenüber einem improvisierten Überschreiben. ¹²
• Führen Sie Patientenzusammenführungen nicht anhand einer Serviceanleitung durch. Funktionen für Abgleich, Zusammenführung und Wiederherstellung hängen vom System und den Richtlinien der Einrichtung ab. Überlassen Sie diese autorisiertem Personal für PACS/RIS und Identitäts-Governance; es wird hier nicht pauschal behauptet, dass jede Zusammenführung unumkehrbar ist.

Wenn Werte zwischen der gesendeten Kopie und dem gespeicherten Objekt abweichen, ermitteln Sie die erste Stelle der Änderung: Modalitätenexport, Transfer-Gateway, Importanwendung oder Archiv. Fordern Sie von den Verantwortlichen autorisierte Vorher-Nachher-Nachweise und aktivierte Zuordnungsregeln an. Der Leitfaden zu DICOM-Netzwerk und I/O behandelt die separate Untersuchung des Transports. Eine Identitätsdiskrepanz allein ist kein Beleg dafür, eine Ersatzplatine zu bestellen.

Wer verantwortet den Identitätsabgleich und die Querverweisbildung?

Die endgültige Festlegung obliegt den autorisierten Teams für Bildinformatik und Patientenidentität der Einrichtung, zu denen das Health Information Management (HIM) sowie ein Master Patient Index (MPI) oder ein unternehmensweiter MPI-Dienst gehören können. Berufsbezeichnungen und Berechtigungen variieren. Medizintechniker stellen Nachweise zum Gerät und zur Übertragung bereit; die Identitätsverantwortlichen verifizieren die Person und die Beziehung zum lokalen Datensatz.

Das Profil IHE Patient Identifier Cross-referencing (PIX) unterstützt die Weitergabe von Informationen zur Patientenidentität und das Abrufen domänenübergreifend querverwiesener Kennungen. Es definiert Transaktionen, nicht den Abgleichsalgorithmus oder die Richtlinien des Unternehmens. Zudem korrigiert es mangelhafte Demografiedaten der Quelle nicht automatisch. ⁶

Für eine fiktive Person mit der Kennung 100452 von Krankenhaus A und der Kennung 98765 von Klinik B kann ein freigegebener Querverweis diese Beziehung darstellen und dabei die Domänen getrennt halten. Das Vorhandensein eines PIX-Dienstes beweist nicht, dass diese Beziehung verifiziert wurde, dass ein bestimmter Viewer sie abfragt oder dass jeder Bild-Header unverändert bleibt. Dies sind Fragen der Implementierung. ⁶

Die IHE spezifiziert zudem den Importabgleich unter Verwendung lokaler Patienten- und Prozedurinformationen. Ihr Radiology Technical Framework Rev 23.0 behält den veralteten ursprünglichen IRWF-Text bei und verweist neue Implementierungen auf IRWF.b, das separat für die Trial Implementation aufgeführt ist. Dies sind Integrationsreferenzen für die zuständigen Teams, kein Konfigurationsrezept. Überprüfen Sie den unterstützten Workflow der installierten Produkte erneut, bevor Sie entscheiden, wie externe Identifikatoren dargestellt werden. ¹²

Erstellen Sie ein zielgerichtetes Eskalationspaket. Identifizierbare Header, Protokolle und Screenshots verbleiben innerhalb des freigegebenen sicheren Support-Kanals der Einrichtung. Geben Sie nur das erforderliche Minimum an Informationen an autorisiertes PACS/RIS- und Identitätspersonal weiter. Externe Serviceanfragen sollten bereinigte technische Nachweise verwenden; senden Sie keine Patientenakten über ein allgemeines Website-Kontaktformular.

• Empfangene und lokale Kandidaten-Identitätswerte, einschließlich Aussteller-Qualifikatoren und der Angabe, welche Werte fehlen, aufbewahrt im autorisierten Datensatz der Einrichtung.
• Modell des sendenden Systems und installierte Softwareversion; Exportmethode, Status von Worklist bzw. manueller Eingabe und der zutreffende Konformitätsabschnitt.
• Übertragungsweg und empfangende Softwareversion, mit allen bekannten Aussteller-Standardwerten oder Coercion-Regeln und der Stufe, auf der sich Werte geändert haben.
• Betroffene Studien-, Serien- und SOP-Instanz-Identifikatoren sowie Auftragsreferenzen, behandelt als potenziell identifizierende Informationen.
• Die vorgeschlagene Übereinstimmung, die ungelöste Diskrepanz, der Status der Aufbewahrung der Originaldatei und das benannte, für die Disposition zuständige Team.

Was belegt der historische Rückruf des LOGIQ e?

Die Bildzuordnung zum falschen Patienten ist eine dokumentierte Gefährdung im Ultraschallbereich. Der Datensatz der FDA zum Rückruf Z-1849-2013 beschreibt den Softwarezustand des GE LOGIQ e, bei dem Bilder mit der Kennung eines anderen Patienten verknüpft werden konnten. Der Datensatz nennt das Softwaredesign als Ursache. ¹³

Der FDA-Eintrag gibt an, dass das Unternehmen ein Software-Update für betroffene Systeme plante, wobei Serviceanfragen bis zum Abschluss nachverfolgt wurden. Er verzeichnet die Einleitung am 9. November 2012 und die Beendigung am 15. September 2014. Er belegt nicht, dass Issuer-Kollisionen den Defekt verursacht haben, dokumentiert keine resultierende Verletzung und beweist nicht, dass die Prüfungen dieses Artikels diesen Softwarefehler verhindern würden. ¹³

Die Erkenntnis ist begrenzt, aber nützlich: Eine Kennung kann plausibel wirken, während ihre Bildzuordnung falsch ist. Sichern Sie Beweise und fordern Sie die zuständigen Produkt- und klinischen Teams auf, ein vermutetes Ereignis mit falscher Patientenzuordnung zu untersuchen. Die Überprüfung des Issuer-Geltungsbereichs ist ein Teil der Importprüfung, kein Ersatz für eine herstellerseitige Korrektur oder das Vorfallmanagement der Einrichtung.

Für die separate Serviceentscheidung zwischen Hardware und Software siehe den GE LOGIQ e Symptom-Leitfaden. Verallgemeinern Sie diesen historischen Rückruf nicht auf andere GE-Produkte, jedes LOGIQ e-Gerät oder aktuelle Software zur Patientenidentifikation.

Wo Rongtao passt — und wo nicht

Rongtao Medical bietet unabhängige markenübergreifende Ultraschall-Platinenreparaturen, Sondenservices, geprüfte Teile und technischen Support. Die Namen unterstützter Geräte kennzeichnen die Serviceabdeckung, keine OEM-Autorisierung. Für diese Entscheidung besteht der nützliche Servicebeitrag in einer technischen Übergabe, die dazu beiträgt, eine Identitätsuntersuchung von einer unbewiesenen Hardwarediagnose getrennt zu halten.

• Wo Rongtao passt: Überprüfung von Gerätemodell, Teileetikett und Symptomen für einen möglichen Ultraschall-Hardware-Servicefall, nachdem die Einrichtung das Problem der Datenintegration bewertet hat. Eine Platinenreparatur dauert in der Regel 5–8 Werktage und die Garantie beträgt typischerweise 90 Tage; Anwendbarkeit und endgültige Bedingungen hängen vom Artikel sowie der Serviceleistung ab und müssen bestätigt werden.
• Wo die Teams der Einrichtung federführend sind: Festlegung der Patientenidentität, Zuordnung externer Kennungen, Autorisierung von Importen, Korrektur von Archivdatensätzen und Durchführung von Zusammenführungen. Rongtao ersetzt weder den PACS/RIS-Hersteller noch die Governance der Einrichtung zur Patientenidentität.

Für eine Hardware-Anfrage kontaktieren Sie Rongtao Medical unter Angabe von OEM, genauem Systemmodell und Softwareversion, Teilenummer des Herstellers (sofern bekannt), deutlichen Fotos der Etiketten sowie beider Seiten jeder sicher zugänglichen Platine, Symptom/Fehlermeldung, Servicehistorie, Stückzahl und Zielland. Der Zugang zu Platinen ist qualifiziertem Personal vorbehalten. Schwärzen Sie Namen, Patienten-IDs, Untersuchungskennungen und sonstige Patientendaten in externen Protokollen und Bildern; belassen Sie das identifizierbare Eskalationspaket bei den autorisierten Teams der Einrichtung.

Häufig gestellte Fragen

Ist eine DICOM-Patienten-ID krankenhausübergreifend eindeutig?
Gehen Sie nicht davon aus. Ihre ausstellende Stelle bestimmt den Geltungsbereich. Eine vertraute Nummer in einer externen Untersuchung erfordert Prüfungen der ausstellenden Stelle und der Provenienz, bevor der lokale Workflow zum Patientenabgleich sie freigeben kann. ^{1 2}

Was ist der Issuer of Patient ID und warum kann dieses Feld leer sein?
Er identifiziert die ausstellende Stelle. Er ist im zitierten Patientenmodul optional. Produktversion, Erfassungs-Workflow und zwischengeschaltete Konfigurationen bestimmen, ob und wie er befüllt wird; das Fehlen allein diagnostiziert keinen Fehler. ^{1 7 8 11}

Zwei Untersuchungen haben dieselbe Patienten-ID, aber unterschiedliche Namen—was sollte ich tun?
Halten Sie den vorgeschlagenen Abgleich zurück und leiten Sie die Diskrepanz an das autorisierte Identitätsteam weiter. Unterschiedliche Personen, Korrekturen bei der Registrierung und Fehler bei der Namensdarstellung sind möglich. Erstellen Sie keinen neuen Patientendatensatz und mutmaßen Sie keinen Issuer allein aus dieser Diskrepanz.

Kann die Accession-Nummer bei der Identitätsprüfung helfen?
Sie kann dabei helfen, eine verifizierte Auftragsherkunft zu ermitteln, identifiziert jedoch einen Imaging Service Request. Sie kann für sich allein weder widersprüchliche Patientennachweise auflösen noch ein Überschreiben autorisieren. ³

Kann ein genehmigter Import-Workflow DICOM-Identifikatoren ändern?
Ja. Ein geregelter Abgleich kann verifizierte lokale Patienten- und Prozedurinformationen nutzen. Die unzulässige Abkürzung besteht hierbei in einer unbefugten Änderung, die nur vorgenommen wird, um eine Annahme zu erzwingen; bewahren Sie das Original und das genehmigte Mapping-Audit auf. ¹²

Was sollte ich vor dem Import einer externen Ultraschalluntersuchung prüfen?
Lesen Sie die empfangenen Patienten- und Issuer-Attribute aus, vergleichen Sie Demografiedaten und Autoritätszuordnungen, stellen Sie die Herkunft von Absender und Zwischeninstanzen fest und behalten Sie Auftrags-/Untersuchungsreferenzen bei. Nutzen Sie das von der Einrichtung genehmigte Verfahren; eine Übereinstimmung in diesen Feldern ist keine unabhängige Garantie für die Identität.

Wer sollte eine Patientenzusammenführung durchführen?
Nur Personal, das gemäß den PACS/RIS- und Patientenidentitätsverfahren der Einrichtung autorisiert ist. Berechtigungen, Wiederherstellungsoptionen und Dokumentation hängen vom jeweiligen Produkt und den Richtlinien ab; dieser Leitfaden schreibt keinen Zusammenführungsvorgang vor.

Sind von der Modalität erzeugte Patienten-IDs außerhalb des Standorts gültig?
Sie können in ihrem ursprünglichen Vergabeschema aussagekräftig sein. Der Empfänger muss den Geltungsbereich und eine verifizierte lokale Zuordnung herstellen; eine erzeugte Nummer ist weder automatisch ungültig noch automatisch eine unternehmensweite Identität. ^{5 8}