gms | German Medical Science

Die Zuständigkeitsbereiche der derzeit 16 im Verband Deutscher Hörscreening-Zentralen (VDHZ e.V.) organisierten Hörscreening-Zentralen sind überwiegend deckungsgleich mit Grenzen von Bundesländer. In zwei Bundesländern haben sich mehrere regionale Zentralen etabliert und in einem Bundesland gibt es zwei kleinere lokale Lösungen. Drei Bundesländer sind bisher unversorgt. Die Trackingeinrichtungen haben gemeinsame Grenzen zu bis zu fünf anderen Zentralen.

Bei einem Wechsel der Zuständigkeitsbereiche zwischen dem Screening- und Kontrollscreening und/oder der fachärztlichen Nachuntersuchungsstelle durch Umzug der Eltern oder aufgrund einer Präferenz der Eltern kommt es vermehrt zu „lost to follow-up“- Fällen in der primär zuständigen Hörscreening-Zentrale mangels Informationsaustausch zwischen den Hörscreening-Zentralen. Hörscreening-Zentralen in Stadtstaaten sind dabei in einem größeren Umfang von diesem Problem betroffen als jene in Flächenstaaten, da relativ viele Eltern mit einem Wohnsitz in einem anderen Bundesland für die Geburt selbst ein Krankenhaus in ihrem Einzugsbereich aufsuchen, dann aber wohnortnah die fachärztlichen Nachuntersuchungen in Anspruch nehmen.

Die Notwendigkeit der Lösung dieses Problems durch einen geregelten Datenaustausch zwischen den Hörscreening-Zentralen wurde früh erkannt [1], [3], dieser konnte jedoch wegen der fehlenden Einigung auf die Nutzung einer einheitlichen Screening-ID für alle Hörscreening-Zentralen nicht bundesweit umgesetzt werden. Erschwerend für die Umsetzung einer Lösung kommt hinzu, dass in den 16 Hörscreening-Zentralen mindestens 7 unterschiedliche Softwarelösungen für das Tracking eingesetzt werden.

Ziel dieses Projektes war die Entwicklung eines Konzepts und die erste Implementierung eines von einer einheitlichen Screening-ID und damit von einer speziellen Trackingsoftware unabhängigen Lösungsansatzes auf der Grundlage einer einfachen Programmierschnittstelle (API) als Angebot an die Entwickler von Trackingsoftware.

Die Implementierung der Schnittstelle, der Transport der Daten und die Authentifizierung gegenüber der Schnittstelle erfolgt über aktuelle und standardisierte Internettechnologien (HTTPS, REST-API und OAuth2).

Die Implementierung der Schnittstelle folgt einer Client-Server-Architektur. Der Server stellt einen Dienst bereit, dessen Endpunkte (Ressourcen) bei Bedarf vom Client mittels Standardmethoden (HTTP-Verben POST, GET, PUT, DELETE) angefragt werden können und dessen Antworten zustandslos und selbstbeschreibend sind.

Die Verwendung mehrerer unterschiedlicher Screening-IDs pro Kind ist möglich. Es werden ausschließlich Streuwerte (Hashwerte) der verwendeten Screening-ID, des Namens, des Vornamens und des Geburtsdatums sowie optional des Geschlechtes und des Namens der Mutter, jedoch keine personenbeziehbaren Daten der Kinder auf dem Server gespeichert.

Die Variablen mit Namensbestandteilen werden einer Vorverarbeitung (Kleinschreibung, Umlaut-Normalisierung, Entfernung von Sonderzeichen, Abtrennung von Füllseln, Wandlung in einen Zahlenwert mittels Kölner Phonetik, Erzeugung des Hashwertes) unterzogen, um Vergleichbarkeit zu erzeugen und fehlertolerantes und von unterschiedlichen Schreibweisen unabhängiges Suchen zu ermöglichen [2]. Regelbasiert wurden zusätzliche Maßnahmen ergriffen, Anonymisierungen des Namens oder Vornamens (z.B. weibl., Junge, noname) oder Datenmüll in den einzelnen Variablen zu erkennen und zu eliminieren.

Die Integration der Schnittstelle sollte im Dateneingang der Trackingsoftware erfolgen. Nach der Berechnung (neues Kind) oder Neuberechnung (neue Daten zu einem bestehenden Kind) des Screeningstatus des Kindes erfolgt eine Abfrage des Kindes auf den Trackingserver (GET /tc). Ist das Kind auf dem Server nicht vorhanden, wird es bei einem Status „kontrollbedürftig“ dort angelegt (POST /child) und der eigenen Hörscreening-Zentrale zugeordnet. Ist es auf dem Server vorhanden und nicht der eigenen Zentrale zugeordnet, erfolgt ein Update (PUT /child), um es der eigenen Screening-Zentrale zuzuordnen. Dieser Prozess kann prinzipiell bei jedem neuen Dateneingang oder zeitversetzt listenbasiert erfolgen.

Abbildung 1 [Abb. 1] zeigt den Ablauf als Flussdiagramm.

Auf Seiten der Trackingsoftware sind folgende zusätzliche Funktionalitäten wünschenswert:

1.

Eine Suchmaske (GET /tc) für die manuelle Suche mit allen optionalen Endpunkten der API.

2.

Eine Warnung, wenn bei einem Kind manuell oder automatisch der Status auf lost to follow-up gesetzt werden soll, dieses aber auf dem Trackingserver angelegt und nicht der eigenen Zentrale zugeordnet ist.

3.

Eine Warnung vor dem Erzeugen eines Erinnerungsschreibens an die Eltern, wenn das Kind auf dem Trackingserver angelegt aber nicht der eigenen Zentrale zugeordnet ist.

Die Programmierschnittstelle wurde mit dem API-Server-Framework Luracast RESTLER umgesetzt. Die Schnittstelle selbst und deren Dokumentation ist in ihrer ersten Implementierung über die Homepage des VDHZ zu erreichen (http://www.vdhz.org/tracking/explorer/index.html) und steht Softwareentwicklern für Testzwecke bereit. Die Schnittstelle wird kostenfrei zur Verfügung gestellt. Die dahinterliegende Datenbank liegt wegen erweiterter Sicherheits- und Sicherungsoptionen im Rechenzentrum des Universitätsklinikums Münster.

Eine Abschätzung der Serverlast am Beispiel der Hörscreening-Zentrale für Westfalen-Lippe mit 55.000 Neugeborenen pro Jahr ergab, dass gemäß der in Abbildung 1 [Abb. 1] dargestellten Abläufe mit maximal doppelt so vielen Serverzugriffen wie nachverfolgten Kindern zu rechnen ist (in allen Fällen auf den Endpunkt GET /tc und zusätzlich in 15% auf POST /child und in 3% auf PUT /child, insgesamt 96.300 Zugriffe).

Ein erster Belastungstest der Schnittstelle mit handelsüblicher Hardware zeigte mit einer durchschnittlichen Verarbeitungszeit von 0,55 Sekunden pro Kind (n=8.446), dass das System ausreichende Reserven für einen bundesweiten Einsatz hat. In zwei Fällen (0,0002%) kam es zu Ablehnungen einer Eintragung mit Hinweis auf eine Datenkollision, ohne dass es sich um richtige Doppeleintragungen von Kindern in der Hörscreening-Datenbank gehandelt hätte.

In den nächsten Monaten sollen auf der Grundlage von Daten eines ganzen Geburtenjahrgangs unserer Hörscreening-Zentrale Fehleranalysen durchgeführt werden und die Vorverarbeitungsmodule daraufhin angepasst werden. Die Möglichkeit der Nutzung von als Bloom-Filter kodierten N-Grammen zur Verringerung von falsch-positiven Suchergebnissen soll untersucht werden. Weiterhin wird eine Simulationen mit mehreren Hörscreening-Zentralen vorbereitet, um das Verhalten des Systems bezüglich Fehlern und Last möglichst realitätsnah zu evaluieren.