Generieren von Berichten und Online-Analysen

portiert“ werden mussten. Die Probleme traten in allen über die Zeit genutzten Versionen von SPSS (13-17), MySQL (5.0x) und ODBC-Treibern (3.x, 5.x) auf.

3.10 Generieren von Berichten und Online-Analysen

Den letzten Baustein eines Erhebungszyklus stellen die Berichte dar. Diese sollten zu jedem Zeitpunkt erzeugt werden können und folgende Anwendungen abdecken:

• Rückmeldung an die einzelnen Praxen

o Zu deren BDT-Datenlieferung insgesamt

o Vergleich des Datenbestandes mit dem aller Praxen

• Skizzierung des Datenbestandes

• Aufdecken offensichtlicher Fehler

Anwendungen wie Online Analytical Processing [OLAP] und die Erstellung von Berichten aus umfangreichen Datenbeständen legt die Verwendung eines speziellen Analysesystems (Datawarehouse) nahe. Primär aus drei Gründen wurde jedoch auf den Einsatz eines solchen Systems verzichtet. Zum einen schien die in dieser Arbeit anfallende Datenmenge noch von einer einzelnen Serverinstanz zu bewältigen zu sein, zum anderen existieren kaum quell-offene, frei verfügbare Systeme für diesen Zweck. Ferner war es nicht vorgesehen, dass Ana-lysen online in der Datenbank durchgeführt werden, dies sollte vielmehr innerhalb von SPSS geschehen.

Daher wurde ein Java-Programm neu entwickelt werden, welches aus der Forschungsdaten-bank die benötigten Berichte druckfertig erzeugen und einen hohen Grad der Automatisierung gewährleisten sollte. Dafür wurde auf die freien Java-Bibliotheken iText (128) und JFreeChart (129) zurückgegriffen.

Die einzelnen Stufen der Datenverarbeitungen, die für die Berichterstellung durchgeführt wurde, veranschaulicht die folgende Grafik. Die XML-Datei mit den aggregierten Daten ent-spricht dabei in etwa der Funktion eines „Cube“ in einem OLAP-System.

3.10 Gen erieren von Ber ichten und On lin e-An alysen

Abbildung 14 - Schema des für die Berichte und Analysen durchgeführten Datenverarbeitungsprozesses

Das für die Berichterstellung entwickelte Programm erzeugt für jede einzelne Praxis eine Aus-gabe (eine PDF-Datei) mit folgenden Informationen:

• Allgemeine Kennzahlen des gesamten Datenbestandes (Anzahl Praxen, Patienten etc.)

• Zum Vergleich die Kennzahlen nur für den Bestand der jeweiligen Praxis

• Die häufigsten 20 Ausprägungen der codierte Werte (Gesamt und pro Praxis):

o Diagnosen (ICD)

o Pharmazentralnummern (PZN) o Wirkstoffe (ATC)

o Gebührenziffern (EBM)

Dieselben Statistiken wurden noch einmal zusätzlich für einen begrenzten Beobachtungszeit-raum errechnet. Eine regelmäßige Erstellung derartiger Berichte für das jeweilige zurück-liegende Jahr oder Quartal wäre wünschenswert gewesen, aufgrund der ungleich verteilten Daten wurde jedoch ein längerer Zeitraum, vom 01.01.2000 bis zum 31.12.2006 für die Be-rechnung der Vergleichsberichte gewählt, die den Praxen im Rahmen dieser Arbeit zugestellt wurden.

Neben den zuvor genannten Kennzahlen und Häufigkeitsstatistiken wurden für den Ver-gleichszeitraum die einzelnen Quartale nach Anzahl der Behandlungen, Geschlechter- und Altersverteilung dargestellt.

Da hierfür bereits umfangreiche SQL-Abfragen mit teils langen Ausführungszeiten nötig waren, wurde die Berichtserstellung in den bereits zuvor erwähnten zwei Schritten durch-geführt. Im ersten Schritt wurde eine Zwischenversion im XML-Format erzeugt, die lediglich alle für die Darstellung notwendigen Ergebnisse enthält. Im zweiten Schritt wurden daraus die einzelnen PDF-Berichte für die Praxen erzeugt. Einen Auszug aus dem XML-Zwischenergebnis zeigt das nachstehende Bildschirmfoto:

3.10 Gen erieren von Ber ichten und On lin e-An alysen

Abbildung 15 – Beispielhafter XML-Auszug der Zwischenergebnisse der Berichterstellung

Die Berichte enthalten, neben einigen Erklärungen zu den Daten, auch den Namen der Praxis aus den BDT-Dateien. Dies ist zwangsläufig notwendig, wenn die Berichte den Praxen zu-gestellt werden sollen. An dieser Stelle wird deutlich, dass die Daten auf der Ebene der Praxen bzw. Ärzte nicht anonymisiert werden dürfen, wenn man Rückmeldungen zu den Ergebnissen haben will, analog zum zyklischen Vorgehen im Qualitätsmanagement.

In unserem Fall wurden die Berichte den teilnehmenden Praxen aus Hannover persönlich überreicht oder postalisch zugestellt. Im Gegenzug wurden sie gebeten, ein Antwortformular zurückzuschicken, in dem um die Einschätzung der Richtigkeit und Aussagekraft der Daten gebeten wurde. Das Formular <7.12> und ein kompletter Beispielbericht <7.6> sind im Anhang zu finden. Die Ergebnisse zu den Rückmeldungen sind in <5.3> dargestellt.

3.11 Zusamm enfassun g

3.11 Zusammenfassung

In Kapitel <3> wurde der Erhebungsprozess der BDT-Daten dargestellt und zunächst ein Über-blick über die einzelnen durchgeführten Schritte gegeben: Rekr utierung, Erhebung, Programm- und Datenbankentwicklung. Datenimport, Auswertung, Berichte und Feedback.

Für die BDT-Datenerhebung, die der vorliegenden Arbeit zugrunde liegt, wurden die seinerzeit 168 Lehrpraxen des Instituts für Allgemeinmedizin der MHH um Teilnahme gebeten.

Zusätzlich konnte auf die BDT-Dateien von 139 weiteren Praxen aus dem abgeschlossenen MedViP-Projekt zurückgegriffen werden.

Für die zentrale Datenhaltung wurde ein Server auf der Basis von Linux und MySQL ein-gerichtet. Die Software-Komponenten zur Datenaufbereitung wurden mit Netbeans in Java entwickelt. Als Basis dafür dienten die Vorarbeiten von Weitling.

Die in den Praxen erhobenen BDT-Dateien wurden noch vor Ort pseudonymisiert. In diesem Schritt wurden mit einem eigens dafür entwickelten Java-Programm alle kritischen BDT-Felder entfernt, lediglich die Patientennummer aus dem AIS (Feldkennung 3000) blieb er-halten. Im selben Schritt wurden die Daten verschlüsselt und konnten anschließend zum Institut transportiert werden.

An der MHH wurden die BDT-Dateien, zusammen mit denen aus dem MedViP-Projekt, in die zentrale MySQL-Datenbank eingelesen. Datenbank-Schema und Java-Programm für diesen Zweck wurden teilweise von Weitling übernommen und weiterentwickelt.

Eine wichtige Neuentwicklung war die Identifizierung von Wirkstoffen nach ATC in den Ver-ordnungseinträgen während des Imports in die Datenbank. Dabei wurde auf die Stammdaten des WiDO zurückgegriffen. Ferner wurden dem Erhebungsverfahren Statistikfunktionen hinzugefügt, um die einzelnen Schritte der Datenaufbereitung besser prüfen zu können.

Die so erhaltenen Daten wurden auf zwei Arten aufbereitet. Zum einen wurden flache Sichten (Views) der Daten angelegt und diese zeitpunktbezogen in analoge SPSS-Dateien überführt, um den Forschern eine solide Datenbasis für unabhängige, dezentrale Forschung zu bieten. Ferner wurden Vergleichsberichte für die Praxen über ein dafür neu entwickeltes Programm erzeugt.

Abschließend wurden die Praxen mit den Berichten konfrontiert und um Stellungnahme zur Datenqualität gebeten.

4.1 Umfr age zur Schnittstellenunterstützung unter den Systemherstellern