1. Verfahrensablauf

1.1 Anfrage

Der für die Anfrage Berechtigte erhält eine Bildschirmmaske, in die er identifizierende Angaben zum Patienten sowie ergänzende Angaben einträgt.

Als Antwort erhält er einen PID für den Patienten.

1.2 Abgleich (Match-Verfahren)

Um festzustellen, ob für den angefragten Patienten schon ein PID vorliegt, soll ein stochastisches Match-Verfahren verwendet werden, das die Wahrscheinlichkeit eines Homonym-Fehlers (= falsche Gleichsetzung zweier verschiedener Personen) minimiert. Die Basis des Match-Verfahrens bilden Häufigkeitstabellen für die Ausprägungen der einzelnen Merkmale in der relevanten Population. Diese Häufigkeitstabellen werden bei der Initialisierung des Verfahrens mit Hilfe eines typischen Datenbestands angelegt und aufgrund der getätigten Abfragen laufend aktualisiert. Aus den Häufigkeitstabellen werden Gewichte für den Match-Algorithmus hergeleitet, die entsprechend aktualisiert werden.

Da diese Häufigkeitstabellen in unbefugten Händen evtl. personenbeziehbare Informationen preisgeben könnten, werden die Merkmalsausprägungen in verschlüsselter Form, als »Kontrollnummern«, abgelegt.

Verwendet werden für den Match-Algorithmus die Daten:

• Geburtsname, anderer Name und Vorname, jeweils in bis zu drei Bestandteile zerlegt, dazu zwei phonetische Codes (Kölner Phonetik [2, 3] und Hannoveraner Phonetik [4]). Die phonetischen Codes werden aus dem Gesamtnamen -- in normalisierter Form -- gebildet.
• Geburtsdatum, zerlegt in Tag, Monat und Jahr.
• Wohnort, repräsentiert durch die Gemeindekennziffer.
• Staat (des Wohnorts).
• Geschlecht.

Der Abgleich ist auch möglich, wenn nicht alle Daten vorliegen; der Mindest-Datenumfang ist: Name, Vorname, Geburtsdatum.

Synonym-Fehler (= Nichterkennen der richtigen Zuordnung und daher Erzeugung eines neuen PID) müssen zu Gunsten der Minimierung der Homonym-Fehler evtl. in Kauf genommen werden. Sie können in der Regel bei der Aufnahme des Patienten ins Kinderkrebsregister erkannt und beseitigt werden.

In einem ersten Schritt wird zunächst ein deterministisches Abgleich-Verfahren implementiert, dessen Spezifikation folgt.

1.3 PID-Ausgabe

Falls der Patient beim Abgleich als schon vorhanden identifiziert wird, wird der vorhandene PID ausgegeben, ansonsten ein neuer erzeugt. Um welchen dieser beiden Fälle es sich handelt, wird in der Regel nicht mitgeteilt, da die Tatsache, ob ein Patient schon früher einmal gemeldet wurde, eine schützenswerte Information ist. In seltenen Zweifelsfällen erfordert die Sicherheit vor Homonymfehlern allerdings eine Rückmeldung, die den Zweifelsfall beschreibt; sie lässt eventuelle Rückschlüsse auf vorhandene Fälle zu.

1.4 PID-Erzeugung

Als PID wird eine mit einem geheimen Schlüssel verschlüsselte laufende Nummer verwendet. Die Spezifikation dieses Verfahrens folgt.

2. Datenstrukturen

2.1 Anfragemaske

2.2 Matchverfahren

Die Merkmalsausprägungen werden vor dem Abgleich durch Kontrollnummern ersetzt.

2.3 Häufigkeitstabellen

Je eine Tabelle für die folgenden Merkmale, bestehend aus den Spalten »Merkmalsausprägung« und »Häufigkeit«:

Die Merkmalsausprägungen werden jeweils durch eine Kontrollnummer repräsentiert, werden also nicht als Klartext gespeichert.

2.4 PID-Tabelle

Die zum Abgleich verwendete Tabelle aller bereits vergebenen PIDs besteht aus den Spalten:

Die Angaben über die bisherigen Anforderungen dienen als Hilfe bei einer evtl. nötigen späteren Korrektur von Synonym-Fehlern sowie zur Löschung offensichtlich nicht mehr benötigter PIDs. Die Bezeichnung der anfordernden Stellen wird verschlüsselt gespeichert.

2.5 Ortsliste

Die Ortsliste kann vom Krebsregister Rheinland-Pfalz übernommen werden. Die Redundanz durch Postleitzahl und Ortsname kann zur Plausibilitätsprüfung genutzt werden.

3. Funktionen

3.1 Pflege des Match-Algorithmus

Initialisierung der Häufigkeitstabellen

mit Hilfe eines umfangreichen, für die zu erwartende Patientenpopulation repräsentativen Datenbestands. Da für den bisherigen Datenbestand des Kinderkrebsregisters PIDs zu erzeugen sind, soll er dabei gleichzeitig zur Initialisierung verwendet werden.

Bestimmung der Gewichtsfaktoren

für den Match-Algorithmus mit Hilfe der Häufigkeitstabellen; die Angabe, ob der Name sicher ist oder nicht, ist zu berücksichtigen. [Feinspezifikation steht noch aus.]

3.2 Aufbereitung der Eingabe-Daten

Übernahme der Formulareingaben

unzulässige Zeichen ersetzen (um Sicherheitsprobleme zu vermeiden), Plausibilitätsprüfung; bei unplausiblen Angaben, z. B. zum Wohnort, wird dem Clienten das Formular mit den eingegeben Daten und gegebenenfalls einer Auswahlliste für Ortsnamen sowie einem erklärenden Hinweis noch einmal präsentiert.

Normalisierung eines Namens

Zerlegung in bis zu drei Bestandteile; Bindestriche und weitere Bestandteile werden verworfen, Namenszusatz wie »von« oder »zu« immer in die dritte Komponente.
Der Zeichensatz wird auf die 26 Großbuchstaben A...Z abgebildet; z. B. ä --> AE. [Feinspezifikation der Umwandlungstabelle steht noch aus.]
Quelle: [1]

Kölner Phonetik

Es handelt sich hierbei um das etablierte Verfahren zum phonetischen Abgleich nach Postel.
Quelle: [2, 3]
Ein fertiges C-Unterprogramm, erstellt im Landeskrebsregister Rheinland-Pfalz, liegt vor.

Hannoveraner Phonetik

Es handelt sich hierbei um das Verfahren Phonet von J. Michael. Dieses hat gegenüber der Kölner Phonetik den Vorteil, ausländische Namen besser zu berücksichtigen; dies ist wegen des hohen und weiter wachsenden Anteils an ausländischen Namen bei pädiatrischen Patienten erwünscht.
Anmerkung: Die Bezeichnung wurde hier in Analogie zur Kölner Phonetik gewählt.
Quelle: [4]
Ein fertiges C-Programm wurde vom Autor zur freien Verfügung gestellt.

Kontrollnummern-Erzeugung

Aus dem (gegebenenfalls normalisierten) Merkmal wird ein schlüsselabhängiger Hash-Wert gebildet (z. B. SHA-1 + 3DES oder SHA-2 + AES).
Das Geschlecht wird im Klartext verwendet (als Boolescher Wert), da eine Verschlüsselung hier nichts nützt.

3.3 Datenabgleich und PID-Erzeugung

Match-Algorithmus

Feinspezifikation für den deterministischen Abgleich folgt; für den stochastischen Abgleich steht sie noch aus.
Quelle: [...]
Falls der Fall wiedererkannt wird, wird sein PID ausgegeben; evtl. bisher nicht erfasste Merkmale werden in die PID-Tabelle aufgenommen und ihre Häufigkeit in der Häufigkeitstabelle inkrementiert. Falls der Fall neu ist, wird er mit einem neu erzeugten PID in die PID-Tabelle aufgenommen; die Häufigkeitstabelle wird entsprechend inkrementiert.

PID-Erzeugung

Ermitteln der nächsten freien laufenden Nummer, Verschlüsselung.

3.4 Ausgabe

Aufbereitung als HMTL-Seite. Es sollen die eingegebenen Daten sowie der PID zurückgemeldet werden sowie Name des Nutzers (aus der Authentisierung) und Datum und Uhrzeit, dazu gegebenenfalls Hinweise für den Nutzer über die Zuverlässigkeit der Identifizierung.

3.5 Ungültigmachung eines PID

Ein PID ist dann ungültig, wenn er als Synonym vergeben und dieses später erkannt wurde. Die Ungültigmachung darf nur vom Betreiber des Servers vorgenommen werden; Korrekturanträge können von Berechtigten per E-Mail eingereicht werden.

4. Benutzungsoberfläche

Einzelabfrage

Verwendet wird ein WWW-Browser, der das Bildschirm-Formular darstellen kann.

Batch-Abfrage

Für umfangreiche Datenbestände (z. B. bei der Initialisierung des Verfahrens) soll ein Batchverfahren zur PID-Erzeugung zur Verfügung stehen. Dieses ist nur für den Server-Betreiber vorgesehen und soll nicht automatisiert, sondern durch Benutzer-Aktion an der Konsole des Servers gestartet werden. [Feinspezifikation steht noch aus.]

5. Systemumgebung

Server

Der Dienst soll mindestens lauffähig sein unter

• UNIX-Systemen mit Apache-Webserver und SSL,
• Windows NT/2000 mit Apache-Webserver und SSL,
• Windows NT/2000 mit IIS und SSL.

Datenbank

Es soll jede SQL-fähige relationale Datenbank nutzbar sein.

Client

Es soll jeder formularfähige WWW-Browser nutzbar sein.

Sicherheit

Datenübertragung

durch Verwendung von SSL grundsätzlich verschlüsselt.

Server

Gesicherte Aufstellung; Systemsicherheit nach dem Stand der Technik.
Identifizierende Daten im Klartext werden nur während der Verarbeitung im Hauptspeicher gehalten; sie werden niemals auf der Festplatte oder anderen permanenten Speichermedien gespeichert.

Client

Für die Sicherheit des Clienten ist der Besitzer zuständig. Da es sich bei den anfordernden Stellen durchweg um medizinische Einrichtungen handelt, die selbst Patientendaten speichern, ist dort ohnehin auf ausreichende Sicherheit zu achten.

Entwicklungsumgebung

Programmiersprache: C/C++; CGI-Skripts mit Perl.