Daten­migration in der privaten Kranken­versicherung

Bestandsführungssysteme in der privaten Krankenversicherung sind oft in die Jahre gekommen. Der Kern dieser Systeme ist häufig in den 70er /  80er Jahren entwickelt und seitdem kontinuierlich weiterentwickelt worden. Und das nicht selten unter Zeitdruck: Vertriebliche Rahmenbedingungen ließen keine umfangreicheren Reorganisationen zu oder die Fristen des Gesetzgebers keine Zeit für eine „saubere“ Implementierung neuer Anforderungen, wie zum Beispiel:

• die Einführung des Standardtarifs (1995),
• die Einführung der Pflegepflichtversicherung (1995),
• die Einführung von Übertragungswerten in der substitutiven Krankenversicherung und des Basistarifs (2009),
• die Einführung der geförderten Pflegezusatzversicherung (2013),
• die Einführung des Notlagentarifs (2013).

Hinzu kommt, dass Entwickler und Administratoren, die die Programmiersprachen der alten Systeme – beispielsweise COBOL – noch beherrschen altersbedingt ausscheiden. Und die jüngere Generation hat kein Interesse daran, veraltete Sprachen zu lernen.

Viele Versicherer stehen jetzt vor der Aufgabenstellung, die aktuelle Systemlandschaft zu modernisieren. Unabhängig davon, ob man dabei auf eine neue Eigenentwicklung oder eine Standardsoftware wie in|sure Health Policy setzt: Die Migration der Daten aus dem (alten) Legacy-System in das neue Zielsystem bleibt das zentrale Problem in derartigen Modernisierungsprozessen.

Die Anforderungen

Insbesondere in der privaten Krankenversicherung ist der Zugriff auf die historischen Vertragsstände zwingend notwendig. Neben diversen Statistiken für interne Anwender müssen auch für den PKV-Verband oder die BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) Auswertungen erstellt werden. Außerdem werden die historischen Daten u. a. auch für die Ermittlung der auslösenden Faktoren und die Nachkalkulation im Rahmen einer Beitragsanpassung herangezogen. Diese Daten wurden von den Legacy-Systemen bereitgestellt und teilweise mit hohem manuellem Aufwand aufbereitet. In einer zukunftsweisenden IT-Infrastruktur sollen diese Aufwände unter Einsatz eines modernen Data Warehouse oder ähnlicher Hilfsmittel minimiert werden, was aber nur mit einer entsprechend hohen Datenqualität erreicht werden kann.

Genau diese Datenqualität muss im Rahmen eines Migrationsprojektes geprüft und idealerweise durch Datenkorrekturen erhöht werden. Die Bestandsdaten in den Legacysystemen sind nicht immer von hoher Qualität. Häufige manuelle Eingriffe (z. B. notwendige manuelle Anpassungen der mathematischen Werte), Plausibilitätsprüfungen, die nicht immer vollständig und fehlerfrei implementiert wurden oder Einzelfallentscheidungen, die unerwartete Datenkonstellationen verursachten sind nur ein paar der möglichen Ursachen.

Die Projekte

Daraus ergibt sich, dass eine reine Datenmigration in der privaten Krankenversicherung nicht zielführend ist. Vielmehr müssen die Migrationsprozesse funktional und mit einem starken fachlichen Fokus durchgeführt werden.

In der Regel entspricht die Datenstruktur des alten Systems nicht der des neuen. Sinnvoll ist es, die Daten aus dem alten System zunächst mithilfe von definierten Transformationsregeln in die Zielstruktur zu überführen. Diese Regeln können in Form von Java-Quellcode und / oder auf Basis von Mappingregeln (z. B. in einem Excel-Sheet) hinterlegt werden. Die Quelldaten bleiben dabei im Ursprungsformat erhalten und so wird auch der Erhalt aller historischen Vertragsdaten gewährleistet. MIGSuite, unsere Lösung für fachlich komplexe Datenmigrationen, kann hierbei unterstützen und bietet sogar die Versorgung weiterer Systeme im Migrationsprozess an. Dazu gehören unter anderem:

• Die Umstellung des Inkassosystems im Rahmen der Migration auf ein anderes Belieferungsverfahren für Beitragsforderungen,
• die Übergabe der historischen Vertragsstände in ein Data Warehouse, um eine große Historientiefe zu vermeiden und
• das Informieren des Partnersystems, dass ein anderes Bestandsführungssystem den Vertrag ab sofort verwaltet.

Um Abweichungen zwischen dem Legacysystem und dem neuen Zielsystem zu identifizieren, empfiehlt es sich, die Verträge im neuen System simulativ (d. h. ohne Speicherung der Daten in der Datenbank) zu berechnen und die Ergebnisse zu validieren, bevor sie persistiert werden. MIGSuite übergibt beispielsweise den zu migrierenden Vertragsstand an das Bestandsführungssystem, lässt diesen dort simulativ berechnen und vergleicht die Ergebnisse mit (ausgesuchten) Werten aus dem Legacysystem. Die Vergleichswerte müssen dabei eine fehlerfreie Migration beweisen und in der Testphase eine schnelle Analyse des Abweichungsgrunds ermöglichen. Als plastische Beispiele seien hier der Zahlbeitrag und der gesetzliche Zuschlag genannt. Je nach Komplexität der zu migrierenden Produkte ist es sinnvoll, die Anzahl der Kontrollwerte zu erhöhen. In MIGSuite führen Kontrollwertabweichungen, die eine definierte absolute oder prozentuale Grenze überschreiten, zu einem Abbruch der Migration für diesen Vertrag. Wenn die Kontrollwertgrenze nicht überschritten wird, ist sichergestellt, dass immer die Werte des alten Systems in das neue (z. B. in|sure Health Policy) übernommen werden. Es wird somit keine Vertragsänderung durch die Migration herbeigeführt.

Besonders aufwändig werden Migrationen, wenn eine große Historientiefe notwendig ist. Zum einen erhöht sie den Umfang der Daten. Bei einer niedrigen Datenqualität muss die gesamte Historientiefe ggf. noch im Legacysystem bereinigt werden. Da diese Daten üblicherweise auch nicht mit dem letzten Vertragsstand im alten System übereinstimmen, ist auch eine manuelle Bereinigung aufwändiger. Zum anderen müssen die Berechnungsregeln und Konfigurationen des Zielsystems bei der Migration mit der Historie so implementiert werden, dass die Ergebnisse bei rückwirkenden Änderungen mit denen aus dem Legacysystem identisch sind. Das beinhaltet auch etwaige Fehler (Rundungsfehler, Rechenfehler etc.), die im Legacysystem bestanden. Es kann ein erheblicher Zusatzaufwand für die Implementierung und den Test des Zielsystems sowie für die Wartung der Algorithmen nach Produktionsstart entstehen.

Die Einführung eines neuen, modernen Systems ist in jedem Fall eine gute Gelegenheit, genau diese „alten Zöpfe“ abzuschneiden. Die Historientiefe zu minimieren und im Rahmen der Migration eher auf die Versorgung eines zentralen Data Warehouse zu setzen, ist ebenfalls sinnvoll. So können die erforderlichen Statistiken bereitgestellt werden, ohne eine tiefe Historie im neuen Bestandsführungssystem vorhalten zu müssen. Der optimale Migrationstermin reduziert zudem rückwirkende Änderungen im Zielsystem. Und die richtige Wahl der Migrationsstrategie bildet das i-Tüpfelchen für eine erfolgreiche Datenmigration.

Gerne beraten wir Sie zu Ihrem Migrationsprojekt!