Datenverarbeitung

Datenverarbeitung

Belastbare Ergebnisse gehen mit einer validen Datengrundlage einher. Die einbezogenen Daten sollten daher vollzählig, vollständig, plausibel und korrekt sein, um die Versorgungsqualität anhand der berechneten Ergebnisse beurteilen zu können.
Zur Sicherstellung einer hohen Datenqualität werden die gelieferten Daten im Laufe der Entgegennahme und Verarbeitung diversen formalen und inhaltlichen Prüfungen unterzogen. Um zu gewährleisten, dass die übermittelten Daten auch korrekt sind, d. h. diese auch den dokumentierten Inhalten entsprechen, werden Originalprotokolle anhand von Stichproben mit dem zugehörigen Exportdatensatz abgeglichen.

Ablauf der Datenverarbeitung

Die Daten stammen aus drei voneinander getrennten Datenquellen, von Notarztstandorten, RTW-Standorten und Leitstellen. Sie sind inhaltlich und strukturell sehr verschieden, was eine unterschiedliche Datenverarbeitung zur Folge hat (siehe Tabelle), wobei das MIND-Format von Notarzt- und RTW-Daten identisch ist.
Nach dem Einlesen werden die Daten aufbereitet. Dabei werden weitere Felder angelegt, deren Werte aus den bestehenden Feldinhalten oder aus den Stammdaten abgeleitet bzw. zugeordnet werden. Bei komplexen Zuordnungsregeln werden sogenannte Mappingtabellen eingesetzt. Beispielhaft für solch eine Tabelle ist die bereits online veröffentlichte Beschreibung zur Ermittlung des M-NACA-Scores (s. Infothek). Die Berechnung der Indikatoren und Kennzahlen erfolgt jeweils auf Standort-, Bereichs- und Landesebene unter Verwendung der aufbereiteten Daten. Basierend auf den Indikatordatenblättern werden Kriterien für den Einschluss in die Grundgesamtheit sowie Regeln für die Indikatoren- und Subgruppenberechnung tabellarisch formuliert. Je nachdem, welche Analysen mit welchem Anonymisierungsstatus für einen Empfänger hinterlegt sind, werden die Ergebnisse entsprechend ausgegeben.

Verknüpfung

Die Verknüpfung zwischen Leitstellen- und MIND-Daten findet statt, nachdem die Daten aufbereitet wurden. Sie erfolgt auf der Standortebene und geht von den MIND-Daten aus. Für Bereichs- und Landesergebnisse werden diese Werte aufsummiert.

Vollzähligkeit

Die Vollzähligkeitsstatistik ergibt sich aus dem Vergleich zwischen der Anzahl der von Notarzt-/RTW-Standorten gelieferten Datensätze und der Anzahl der Leitstellendatensätze, die zu diesen Standorten gehören. Die Feststellung der Standortzugehörigkeit erfolgt über die Projekt-ID-Zuordnung der Wachen/FRN. Die dadurch in den Leitstellen vorgefundenen frühesten und spätesten Alarmierungszeitpunkte bilden den Betrachtungszeitraum der Vollzähligkeit (s. u. Abbildung). Eine Vollzähligkeit der Datensätze kleiner als 100 % bedeutet demzufolge, dass für einen Notarzt-/RTW-Standort im betrachteten Zeitraum weniger Datensätze (MIND/MIKD) vorliegen (Ist-Wert), als in den Leitstellendaten für diesen Standort Datensätze vorhanden sind (Soll-Wert).

Ursachen für auffallend hohe/niedrige Vollzähligkeit können beispielsweise sein:

• Zeitliche Lücken in den Standort-Lieferungen (Daten bestimmter Tage/Monate fehlen)
• Export von Einsätzen unter der falschen Projekt-ID
• Funkrufnamen-Wechsel von Rettungsmitteln
• Eine Auftragsnummer für mehrere Patienten an einem Einsatzort
• Falscher Rettungsmitteltyp in den Leitstellendaten (z. B. NAW-RTW-Tausch)
• Nicht von der Leitstelle erfasste Sekundäreinsätze
• Projekt-ID-Mapping durch die SQR-BW
• Fehlende MIKD

Verknüpfbarkeit

Nach der Ermittlung der Vollzähligkeit werden die Notarzt-/RTW-Daten mit den Leitstellendaten über die Auftragsnummer (= Primärschlüssel im MIND/MIKD) verknüpft. Ein Datensatz gilt dann als verknüpfbar, wenn folgende Kriterien erfüllt sind:

• Die Projekt-ID passt zum Funkrufnamen des Rettungsmittels
• Das Rettungsmittel ist kein Fremdrettungsmittel
• Das vom Standort dokumentierte Einsatzdatum passt zu dem des Leitstellendatensatzes
• Die Auftragsnummer ist eindeutig (nur jeweils einmal in den Daten des Standortes und der Leitstelle)

In verschiedenen Rettungsdienstbereichen besteht die Auftragsnummer aus einer fortlaufenden Nummer, der ein oder mehrere Präfixe vorangestellt sind. Über diese Präfixe werden beispielsweise die Rettungswachen, das Einsatzjahr und der Einsatzmonat oder die rettungsdienstdurchführende Organisation kodiert. Dementsprechend haben die Leitstellenauftragsnummern dort eine fest vorgegebene Struktur. In den Datensätzen befinden sich vielerorts nur die fortlaufenden Nummern, nicht aber die zugehörigen Präfixe und etwaige Nullstellen. Die Struktur und der Aufbau der kompletten Auftragsnummer, also inklusive Präfix, Länge und fortlaufender Nummer, werden durch die SQR-BW anhand der Leitstellendaten auf Ebene der einzelnen Standorte hinterlegt und beim Import von MIND/MIKD-Daten erforderlichenfalls ergänzt.

Bei Änderungen der Auftragsnummernstruktur oder bei Verletzungen der durch die Leitstellendaten vorgegebenen Struktur (z. B. Auftragsnummernlänge in der Leitstelle: 8 Stellen plus 3 Stellen Präfix, gelieferte Auftragsnummer: 10 Stellen ohne Präfix) ist diese Systematik fehleranfällig und führt zu nicht verknüpfbaren Datensätzen. Eine entsprechende Prüfung der Primärschlüssel-/Auftragsnummer-Systematik ist auch der Gegenstand der Datenprüfung zur rechtzeitigen Erkennung von Präfixänderungen (s. unteren Abschnitt).

Datenprüfung

Notarzt- und RTW-Daten

Alle auf dem SFTP-Server abgelegten MIND/MIKD-Daten werden auf strukturelle Fehler überprüft und unmittelbar zur Korrektur zurückgemeldet.

Während des Imports in die Datenbank erfolgt darüber hinaus eine Prüfung auf logische Datenfehler:

• Einsatzjahr ist ungültig, Jahr MIN/MAX wird datenbankintern vorgegeben (Nicht-Import)
• Diskrepanzen zwischen gelieferten Angaben zu Leitstelle, Protokolltyp, Projekt-ID mit den entsprechenden Einträgen in der Datenbank der SQR-BW (Nicht-Import)
• Codetabellen-Fehler (Nicht-Import)
• Der gelieferte Primärschlüssel entspricht nicht der Präfix-Systematik der Leitstellen-Auftragsnummer (falls vorhanden)
• Derselbe Primärschlüssel ist mehrfach in der Datenlieferung enthalten: Der Primärschlüssel wird protokolliert (Rückmeldung über SQR-BW-Portal)
• Derselbe Primärschlüssel wurde bereits von einem anderen Standort geliefert, der zur gleichen Leitstelle gehört: Der Primärschlüssel wird protokolliert (Rückmeldung über SQR-BW-Portal) und in der Datenbank als dubios markiert
• Anhand von Soft-Key-Merkmalen (Einsatzdatum, Geburtsdatum/Alter, Geschlecht) wird geprüft, ob es sich bei gleichem Primärschlüssel um den gleichen Patienten handelt. Ist es nicht der Fall, dann wird der entsprechende Primärschlüssel als Soft-Key-Änderung gezählt und protokolliert
• Liegt zu dem gelieferten Primärschlüssel keine passende Leitstellenauftragsnummer vor, dann wird eine Meldung generiert

Dateninhalte lassen sich anhand diverser Plausibilitätsregeln prüfen, die plausible inhaltliche Abhängigkeiten, auch quer über mehrere Felder, definieren. Viele dieser Regeln flossen in den Datensatz MIND3.1 ein und können somit bereits vor oder bei Export der Daten mithilfe des Programms „MIND Checker“ überprüft werden.

Die detaillierte inhaltliche Prüfung bei Entgegennahme und Verarbeitung der Daten wurde auf Grundlage der Erfahrungen und Erkenntnissen aus den vergangenen Jahren entwickelt und dynamisch angepasst. Hierbei werden in der Vergangenheit aufgetretene Exportfehler unterschiedlicher Dokumentationssysteme ebenso berücksichtigt wie häufig vorkommende Implausibilitäten. Die Ergebnisse der inhaltlichen Prüfung werden den Standorten und zum Teil auch den Systemanbietern zurückgemeldet, um die Datenqualität zu verbessern.

Die folgenden Punkte werden aktuell bei der Entgegennahme von MIND3.1-Daten auf inhaltliche Auffälligkeiten untersucht:

• Einhaltung der Namenskonvention für den Dateinamen
• Verteilung der Anzahl der Datensätze über die Monate
• Angabe von Transportziel bei nicht transportierten Patienten
• Ungültige Klinik-ID
• Systematische Fehler bei der Diagnosen-Dokumentation
• Diagnose trotz fehlendem Patientenkontakt
• Angabe von Verletzungsdetails ohne Verletzung
• Systematische Fehler bei der Dokumentation eines Feldes
• Implausible Angabe-Kombinationen in Mehrfachangabefeldern
• Reanimationsdetails in Abhängigkeit von Reanimationssituation
• Auffallend häufig/selten dokumentierte Feldinhalte
• Implausible Altersangaben
• Implausible Zeitfolgen
• Rettungsmitteltyp oder Personalangaben passen nicht zum Protokolltyp
• Abgleich der Primärschlüssel-Systematik mit der Systematik der Auftragsnummern der Leitstelle inklusive Prüfung auf Präfix-Änderungen