Data-Warehousing von IV-Systemen – Struktur und Abläufe - OptiMedis AG

Direkt zur Hauptnavigation Zum Inhalt wechseln

Data-Warehousing von IV-Systemen – Struktur und Abläufe

Wir möchten Ihnen hier vorstellen, wie unser Data-Warehouse im Einzelnen funktioniert. Dies ist teilweise sehr komplex ist, bei Rückfragen können Sie sich gern an uns wenden. Ihr Ansprechpartner ist Timo Schulte.

Um aus den Daten von Krankenkassen, Leistungspartnern oder weiteren Quellen Hinweise für die Steuerung und Optimierung Integrierter Versorgungssysteme (IV) zu bekommen, sind viele einzelne, hochkomplexe Schritte notwendig. Auf dem folgenden Bild sehen Sie, in welchen Schichten die verschiedenen Daten in dem hochmodernen Data-Warehouse von OptiMedis verarbeitet werden. Weiter unten erläutern wir Ihnen die einzelnen Schritte – von der Integration der Daten in die Basisschicht bis zur Aufbereitung für die Analyseschicht.

 

 Data_Warehouse

Abbildung 1: Controlling-Architektur für Integrierte Versorgungssysteme

Die Datenquellen

In der Integrierten Versorgung gibt es verschiedene Quellsysteme (s. Abbildung 1), die Daten für das Controlling liefern können. Dies sind Daten der Krankenkassen, der Leistungspartner, der Managementgesellschaften und externe Vergleichsdaten.

Zentrale Basis für unsere Auswertungen sind die GKV-Routinedaten der Krankenkassen in pseudonymisierter Form. In unserem regionalen Versorgungssystem „Gesundes Kinzigtal“ beispielsweise können wir auf die Daten aus allen Versorgungssektoren der in der Region wohnenden Versicherten der AOK und der LKK von 2003 an in pseudonymisierter Form zugreifen.

GKV-Routinedaten werden routinemäßig zu Abrechnungszwecken erhoben und bieten einige Vorteile: Sie sind zum Teil relativ schnell und auch für größere Stichproben verfügbar. Sie ermöglichen eine prospektive und retrospektive Betrachtung für längere Beobachtungszeiträume. Und sie erlauben Analysen über den gesamten Behandlungsprozess eines Krankheitsbildes hinweg, da die Daten aller Leistungserbringer einbezogen sind. Problematisch ist, dass die ambulanten Daten in der Regel erst nach rund einem dreiviertel Jahr für Auswertungen zur Verfügung stehen. Angaben zur Krankenhausbehandlung, zur Arzneimittelversorgung, zur Kurbehandlung, zur Heil- und Hilfsmittelversorgung und zur Arbeitsunfähigkeit dagegen kommen relativ zeitnah.

Durch die Pseudonymisierung der GKV-Routinedaten ist jeder Versicherte eindeutig im Datenpool identifizierbar. Dies erlaubt das Zusammenspielen und Analysieren von Informationen aus den einzelnen Bereichen der Gesundheitsversorgung bezogen auf einen Patienten. Ein Rückschluss auf die Identität des Versicherten ist nicht möglich.

Um diese Daten zu ergänzen, können wir zum einen die Daten der Leistungspartner, also die Daten aus den Praxisverwaltungssystemen der Ärzte nutzen, zum anderen eigene Daten der Managementgesellschaft. So haben wir in „Gesundes Kinzigtal“ strukturierte Zusatzdokumentationen für unsere Programme zum Krankheitsmanagement entwickelt und in die Praxisverwaltungssysteme der Leistungspartner integriert. Bei dem Programm Gesundes Gewicht werden beispielsweise folgende Angaben dokumentiert: Gewicht, Bauchumfang, Blutdruck, Nüchtern-BZ, Normwert BZ etc.. Auch Abrechnungsdaten für spezielle IV-Leistungen können wir hier erfassen und weiterverarbeiten.

Eine ganz wesentliche Rolle spielen auch externe Vergleichsdaten. Das können beispielsweise die standardisierten Leistungsausgaben aus dem (morbiditätsadjustierten) Risikostrukturausgleich sein, die Entwicklung der Generikaquoten oder die Ergebnisse.

Die Basisdatenbank

Die Daten aus den verschiedenen Quellsystemen integrieren wir zunächst in die Basisdatenbank, das Core Data Warehouse. Über ETL-Prozesse – ETL bedeutet Extract, Transform and Load – vereinheitlichen, bereinigen und prüfen wir die Daten zuvor. Im Einzelnen bedeutet das:

  1. Vereinheitlichung der Daten
    • Zum Beispiel einheitliche Identifikationsnummer der Versicherten, Leistungspartner etc über alle Datenquellen hinweg
    • Einheitliche Tabellenstruktur für Kosten- und Leistungsdaten als Voraussetzung für krankenkassen- und regionsübergreifende Analysen
  2. Normalisierung der Daten
    • Vermeidung von Redundanzen und Inkonsistenz
  3. Prüfung der Datenqualität und Bereinigung der Daten
    • Vollständigkeit
    • Validität
    • Konsistenz
    • Semantik und Syntax

Insgesamt haben wir hierfür bereits über 300 verschiedene ETL-Prozesse entwickelt.

Die analytische Datenbank

Im nächsten Schritt bereiten wir die Daten über weitere ETL-Prozesse für die analytische Datenbank auf. Aus dieser speisen sich dann die verschiedenen OLAP-Cubes (OLAP = Online Analytical Processing), die wir weiter unten näher erläutern.

Einige Beispiele dafür, wie die Daten für die Analyseschicht verarbeitet werden:

  • Umwandlung der Daten in Star-Schemata mit Galaxie-Konzept
    Dies ist ein IT-technischer Prozess, der zur Erstellung von OLAP-Cubes nötig ist. Hier soll auf diese technischen Details aber nicht näher eingegangen werden. Weitere Informationen finden Sie beispielsweise unter http://de.wikipedia.org/wiki/Sternschema. Gern können Sie uns auch kontaktieren (Dr. Alexander Pimperl, Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!)
  • Zuordnung der Versicherten:
    Für Auswertungen in Integrierten Versorgungsnetzen ist eines besonders wichtig: Wer Patientenkollektive analysieren will, muss sie erst aus dem Datenpool heraus identifizieren. Bei „Gesundes Kinzigtal“ beispielsweise gruppieren wir sie u.a. nach folgenden Kriterien:
    • Hausarztzuordnung
    • Identifikation von speziellen Versichertenpopulationen (Versicherte mit speziellen Erkrankungen, wie Herzinsuffizienz, Diabetes Typ II etc.; Multimorbide Versicherte, Multimedikamentös behandelte Versicherte etc.)
    • Versichertengruppenbildung gemäß RSA/Morbi-RSA

Relevante Kriterien zur Identifikation recherchieren und erarbeiten wir zuvor über entsprechende Studien, Leitlinien oder Expertengespräche mit Ärzten. Meist sind dies krankheitsspezifische Arzneimittelverordnungen und/oder ambulante Diagnosen und/oder stationäre Diagnosen. Diese Kriterien werden dann in der Regel über ein „Trichter“-Verfahren angewendet. Die folgende Abbildung zeigt ein solches Verfahren für Diabetes Typ II Versicherte.

Abbildung 5: Trichterverfahren zur Identifikation von Diabetes Typ II Patienten

  • Matched-Pair-Gruppenbildungen:
    Auch die Bildung von Matched-Pairs, wobei jedem Patienten eine möglichst gut vergleichbare Kontrollperson zugeordnet wird, ist ein wichtiger Schritt in der Aufbereitung der Daten. Wenn wir faire Vergleiche zwischen einer Interventionsgruppe und einer Vergleichsgruppe ziehen wollen, müssen wir sicherstellen, dass in beiden Gruppen ähnliche Risiken enthalten sind. Nur so können wir die Effektivität und Effizienz unserer Interventionen überprüfen. Alter und Geschlecht sind zwei Variablen, die wir auf jeden Fall berücksichtigen müssen. Daneben können auch – je nach Ausrichtung der Analyse – andere Risikoparameter, wie Kosten- und oder Risikogewichte oder hierarchisierte Morbiditätsgruppen herangezogen werden.
  • Szenariokalkulationen
    Während der Aufbereitung der Daten für die Analyseschicht stellen wir bereits verschiedene Szenariorechnungen an – so zum Beispiel RSA-/Morbi-RSA-Szenariorechnungen oder Krankheitskosten-Attributionsmodelle.

Die OLAP-Cubes

Der Begriff OLAP-Cube bezeichnet die logische Darstellung von Daten. Die Daten werden dabei als Elemente eines multidimensionalen Würfels (s. Abbildung 4) arrangiert. Die Dimensionen dieses Würfels (Cube) beschreiben die Kennzahlen (z.B. Anzahl oder Alter der Patienten, Indikation, Arzneimittelkosten, Anzahl der Verordnungen etc.) und erlauben so auf einfache Weise den Zugriff. Diese Kennzahlen können dann über eine oder mehrere Achsen des Würfels analysiert werden.

Ein Beispiel für einen sehr einfachen dreidimensionalen Cube sehen Sie auf dem folgenden Bild. Mit diesem Cube lassen sich zum Beispiel folgende Fragen beantworten:

  • Wie hoch sind die Behandlungskosten für Herzinsuffizienz?
  • Welcher Schweregrad verursacht die höchsten Behandlungskosten für Herzinsuffizienz?
  • Welche Altersgruppe verursacht die höchsten Behandlungskosten für Herzinsuffizienz?
  • In welchem Jahr sind die höchsten Behandlungskosten für Herzinsuffizienz angefallen?
  • Wie hoch sind die Behandlungskosten im Jahr 2004 für Herzinsuffizienz-Patienten mit dem Schweregrad IV in der Altersklasse von 50 bis 60 Jahren? (s. hellgrau markierter Würfel + dazugehörige Tabelle in Abbildung 4)

Anm.:
Dimension = z.B. Kunde
Bezugsobjekttyp = Eigenschaften, die den Kunden näher beschreiben. Das können z.B. Alter, Geschlecht, Wohnort, Krankenkasse etc. sein
Bezugsobjekt = Ausprägungen dieser Kundeneigenschaften: Z.B. bei Alter: Altersklasse 11-20; Altersklasse 21-30 etc.; oder bei Geschlecht: weiblich und männlich

Abbildung 4: vereinfachtes dreidimensionales Beispiel eines OLAP-Würfels für Behandlungskosten von Herzinsuffizienz (Schicker 2008)

Das Metadatenmanagement

Für den effizienten Betrieb eines DataWarehouse spielen gut organisierte Metadaten eine große Rolle, da man sie zur Steuerung fast aller Prozesse benötigt. Deshalb betreiben wir bei OptiMedis ein eigenes Metadatenmanagement. Metadaten werden häufig als „Daten über Daten“ bezeichnet. Im Fall des Data-Warehouses sind dies alle Informationen, die die enthaltenen Daten – beispielsweise die Herkunft oder den Zeitpunkt der Änderung –, deren Transformationen und das sie umgebende System beschreiben. Sie helfen uns, die Qualität der Daten stetig zu verbessern und den Betrieb des Data-Warehouses effizienter zu machen.