Das Problem der Fragmentierung des MRN-Formats
Die Vereinigten Staaten haben ungefähr 6.100 Krankenhäuser, die jeweils ihr eigenes elektronisches Gesundheitsakten-System mit ihrem eigenen Format für medizinische Aktennummern betreiben. Es gibt keinen nationalen MRN-Standard. Die Joint Commission, die Gesundheitsorganisationen akkreditiert, gibt an, dass MRNs Patienten innerhalb eines Systems eindeutig identifizieren müssen – spezifiziert jedoch nicht das Format.
Die Konsequenz: MRN-Formate in der Praxis umfassen 7-stellige Ganzzahlen, 8-stellige Ganzzahlen, alphanumerische Zeichenfolgen unterschiedlicher Längen, formatierte Zeichenfolgen mit Präfixcodes (HOSP-, MRN-, PT-, PAT-), institutionelle Codes, die vorangestellt sind (SVHS-, CHOP-, MDACC-), und datencodierte Formate, bei denen das Einschreibejahr in der Nummer eingebettet ist.
Die De-Identifizierungsmethode von HIPAA's Safe Harbor listet medizinische Aktennummern als Kategorie 8 von 18 Identifikatoren, die entfernt werden müssen (45 CFR Abschnitt 164.514(b)(2)). Die Anforderung ist nicht durch das Format qualifiziert – alle MRN-Formate, die von der Organisation verwendet werden, müssen erkannt und entfernt werden. Eine Organisation, die klinische Notizen verarbeitet, ohne ihr spezifisches MRN-Format zu erkennen, erreicht keine HIPAA Safe Harbor-De-Identifizierung, unabhängig davon, welche anderen Identifikatoren entfernt werden.
Die Codierungsbarriere
Der Standardansatz zur Hinzufügung eines benutzerdefinierten MRN-Formats zu einer De-Identifizierungs-Pipeline erfordert die Implementierung des Formats im benutzerdefinierten Erkennungsrahmen von Presidio. Dies umfasst:
Das Schreiben einer Python-Klasse, die EntityRecognizer erweitert, das Definieren des Regex-Musters für das spezifische MRN-Format, die Implementierung der analyze()-Methode, die das Muster anwendet, das Hinzufügen des Erkennungsmoduls zum Presidio-Register, das Testen der Implementierung an repräsentativen Proben und das Warten der Implementierung, während sich das Format weiterentwickelt.
Für klinische Informatikteams ohne Python-Expertise – was die Mehrheit des Personals für Compliance und Datenschutz im Gesundheitswesen beschreibt – schafft dies eine Abhängigkeit vom Engineering-Team für jede Formatänderung. Ingenieurressourcen in Gesundheitsorganisationen werden typischerweise der EHR-Integration und der klinischen Entscheidungsunterstützung zugewiesen, nicht der Konfiguration von Compliance-Tools.
Der KI-Musterhelfer
Der KI-unterstützte Ansatz zur Mustererstellung ersetzt den Codierungsworkflow durch eine geführte Schnittstelle:
Das klinische Informatikteam öffnet den benutzerdefinierten Entitätsersteller in der Webanwendung. Sie geben 5 Beispiel-MRN-Werte aus ihrem System an (SVHS-0012345, SVHS-0987654, SVHS-1122334, SVHS-4455667, SVHS-8899001). Sie klicken auf "Muster generieren." Die KI analysiert die Struktur der Beispiele und gibt zurück: das Muster SVHS-d{7} passt zu den bereitgestellten Beispielen; Vertrauensniveau hoch; vorgeschlagener Entitätsname: HOSPITAL-MRN; vorgeschlagener Ersatz: [MRN]; Testen gegen zusätzliche Proben zur Validierung.
Das Team gibt 5 weitere Testproben an. Das Muster validiert korrekt. Die benutzerdefinierte Entität wird im HIPAA-Compliance-Voreinstellung gespeichert. Alle nachfolgenden De-Identifizierungssitzungen – Webanwendung, Office-Add-In, Desktop-App und API – erkennen automatisch MRNs im SVHS-Format als Teil des Standard-PHI-Erkennungslaufs.
Die Forschungsbefreiung gemäß Artikel 89 der DSGVO erfordert Pseudonymisierung und Datenminimierung für Forschungsdatensätze. Die Erstellung benutzerdefinierter Entitäten stellt sicher, dass institutionsspezifische Identifikatoren im Pseudonymisierungsbereich enthalten sind – und schließt die Deckungslücke, die generische Tools für proprietäre Formate offenlassen.
Quellen: