gms | German Medical Science

Einleitung: Die Arbeit in medizinischen Forschungsverbünden erfordert einerseits die Möglichkeit, Patienten institutionsübergreifend und in heterogenen Datenbanken eindeutig zu identifizieren, andererseits ist aufgrund des Datenschutzes der Zugriff auf identifizierende Patientendaten (IDAT), insbesondere bei Verknüpfung mit medizinischen Daten (MDAT), stark reglementiert. Aus Datenschutzgründen ist also eine Pseudonymisierung nötig. Die Heterogenität der Datenquellen erfordert dabei ein fehlertolerantes Record Linkage, um auch bei fehlerhafter Eingabe (z.B. Tipp- und Übertragungsfehlern) das richtige Pseudonym zuzuordnen. Aus Performanz-, Aufwands- und Datenschutzgründen soll dieser Prozess weitgehend automatisch ablaufen. Sowohl Pseudonymisierung als auch Record Linkage sind Teil des Mainzer Record-Linkage-Frameworks für Patientendaten, die Mainzer Patientenliste. Um Abwärtskompatibilität zum PID-Generator [1], dem Vorgänger dieses Frameworks, zu schaffen, sollte die Software um einen phonetischen Algorithmus erweitert werden. Seine Stärke liegt in der Beseitigung von Fehlern, die in einer unterschiedlichen Aussprache begründet sind (z.B. Mayer -> Maier). Es sollte außerdem evaluiert werden, ob der Einsatz der Phonetik das Matching der Patientenliste ggü. eines auf Bigrammen basierenden Zeichenkettenvergleichs [2] verbessert und damit nicht nur für Bestandsdaten, sondern auch neue Datensammlungen für die Pseudonymisierung von Forschungsdaten zweckmäßig ist.

Material und Methoden: Als Phonetik wurde der Phonet-Algorithmus gewählt, für den bereits eine Implementierung in C vorliegt [3]. Nach der Java-Portierung des Phonet-Algorithmus erfolgte eine Integration in die Mainzer Patientenliste. Zum Zwecke der Evaluation des Verfahrens wurden bei der Eingabe der Patientendaten folgende Fehler simuliert:

• Generische Fehler: Bindestriche anstatt Leerzeichen, Einfügen von Zeichen (Thomas -> Thormas), Umlaute und scharfes S (Straesser -> Sträßer), sowie jeweils auch die Umkehroperation.
• Ersetzungsfehler bedingt durch Texterkennung in Scannern (Lingen -> Ingen).
• Phonetische Fehler (Mayer->Meyer).

Mithilfe der Software TDgen [4] wurden diese Fehler jeweils auf den Feldern „vorname“, „nachname“, „ort“ und „geburtsname“ auf einem mit TDGen mitgelieferten Referenzdatensatz aus 10.000 Einträgen angewandt und erzeugten so den Fehlerdatensatz. Im Testverfahren wurde der Referenzdatensatz in die Patientenliste eingegeben, danach der Fehlerdatensatz. Dann wurde dieses Verfahren unter Verwendung des vorgeschalteten Phonet-Algorithmus wiederholt. Gezählt wurde jeweils die Anzahl der nicht wiedererkannten Duplikate (Synonymfehler) und der fälschlicherweise als Duplikat klassifizierten Matche (Homonymfehler). Für die Feldvergleiche wurde in der Referenz der o.g. Zeichenkettenvergleich basierend auf Bigrammen benutzt. Für die Verwendung mit dem Phonet-Algorithmus wurde ein Binärvergleich (gleich oder ungleich) durchgeführt. Die Evaluation erfolgte im Rahmen eines gewichtsbasierten Record Linkage nach dem Epilink-Algorithmus [5].

Ergebnisse: Bei der Verwendung des Phonet-Algorithmus und einer Epilink-Erkennungsschwelle von 0.85 werden beim Phonet 2747 Duplikate nicht (automatisch) wiedererkannt, gegenüber 80 bei der Verwendung mit N-Grammen. Das Epilink-Gewicht verringert sich gegenüber dem ursprünglichen Verfahren ohne Phonet um etwa 7%. Bei einer Reduzierung der Epilink-Erkennungsschwelle auf 0.75 werden bei Phonet 365 Duplikate nicht erkannt, beim N-Gram-Vergleich 5.

Diskussion: Die Implementierung von Phonet hat in Bezug auf das Record Linkage keine Verbesserung gegenüber dem Verfahren mit N-Grammen gebracht. Für eine Verwendung im Rahmen bestehender Lösungen (Abwärtskompatibilität) sollte zur automatisierten Bearbeitung der Wert für den Epilink-Übereinstimmungsschwellenwert weniger restriktiv gewählt werden. Dadurch entfällt möglicherweise eine manuelle Zuordnung.

Fazit: Die Phonetik sollte nur für die Abwärtskompatibilität eingesetzt werden (wenn vorhandene Datenbestände mit der Patientenliste weitergeführt werden), für neue Anwendungen ist der zuerst implementierte Zeichenkettenvergleich vorzuziehen.