Gesundheitswesen · 16 Wochen · Ein Gesundheitsdienstleister
Vereinheitlichte Customer-Data-Platform
Kundenname unter NDA anonymisiert. Branche, technischer Ansatz, Tools und gemessene Ergebnisse sind unverändert wiedergegeben. Namentliche Referenzen auf Anfrage.
# RESULTS
- Dubletten bereinigt
- 87%
- Single Source of Truth
- 1
- End-to-End
- 16 Wo.
- Privacy-by-Design
- DSGVO
# THE-CHALLENGE
4 CRMs, 3 Abrechnungsplattformen, kein einheitliches Bild. Jede Abteilung hatte ihre eigene Version des Patienten – und keine stimmte mit der anderen überein. Das Marketing versendete doppelte Mailings. Die Abrechnung konnte Konten nicht abgleichen. Klinische Teams arbeiteten mit unvollständigen Datensätzen.
Die eigentliche Ursache war nicht nur die technische Fragmentierung – sie war organisatorischer Natur. Jede Abteilung hatte über das vergangene Jahrzehnt ihr eigenes System gewählt. Niemand hatte die Befugnis, diese zusammenzuführen, also entstanden Punkt-zu-Punkt-Integrationen, die unbemerkt abbrachen und widersprüchliche Daten erzeugten. Ein Patient konnte über vier Systeme hinweg drei unterschiedliche Adressen haben, und niemand wusste, welche davon aktuell war.
# THE-TRANSFORMATION
// vorher
- 4 CRMs und 3 Abrechnungsplattformen, von denen keine mit der anderen sprach
- Das Marketing versendete doppelte Mailings, die Abrechnung konnte nicht abgleichen
- Patient #10042 im CRM ≠ Patient #10042 in der Abrechnung
- Die DSGVO-Konformität lautete „wir denken, wir sind auf der sicheren Seite“
// nachher
- Eine zentrale Datenwahrheit über alle 7 Systeme hinweg
- 87 % der Dubletten identifiziert und zusammengeführt
- Lückenloser DSGVO-Audit-Trail – Konformität ist dokumentiert, nicht angenommen
- Nachgelagerte Systeme beziehen Daten per API aus der vereinheitlichten Plattform
# OUR-APPROACH
Datenarchäologie
Alle 7 Quellsysteme auditiert. Entitätsbeziehungen abgebildet, Überschneidungen identifiziert und jedes Feld katalogisiert, das zur Frage „Wer ist dieser Patient?“ beitrug.
Identitätsauflösung
Eine probabilistische Matching-Pipeline in Python aufgebaut – nicht nur Name + Geburtsdatum, sondern auch Adresshistorie, Kontaktmuster und Abrechnungskennungen. Validiert anhand einer manuell geprüften Stichprobe von 500 Datensätzen.
Plattform-Aufbau
Vereinheitlichte Datenschicht in Snowflake mit Pseudonymisierung, Einwilligungsverwaltung und lückenlosen DSGVO-Audit-Trails. Fivetran für die Ingestion, dbt für die Transformation, Terraform für die Infrastruktur.
API & Übergabe
API-Endpunkte geschaffen, damit nachgelagerte Systeme aus der vereinheitlichten Plattform beziehen statt voneinander. Alles dokumentiert. Internes Team für die Wartung der Pipeline geschult.
Drei der sieben Systeme hatten überlappende Patienten-IDs in unterschiedlichen Formaten. Der schlimmste Fall: Zwei Systeme nutzten denselben Feldnamen für die ID, vergaben diese jedoch aus unterschiedlichen Sequenzen. Patient #10042 im CRM war eine völlig andere Person als Patient #10042 in der Abrechnung. Wir bemerkten es während der Validierung – andernfalls hätte die vereinheitlichte Plattform die Krankenakten zweier fremder Personen zusammengeführt.
# TECH-STACK
Wir hatten mehrere Systeme, die nie wirklich zusammengepasst haben. Juri und Oleks haben uns Schritt für Schritt durch das Projekt geführt und dabei Datenschutz und Fachbereiche von Anfang an eingebunden. Am Ende hatten wir eine Lösung, mit der alle gut leben konnten.
# OPERATING-CONTEXT
Rahmenbedingung
Patientendaten bedeuteten null Toleranz für fehlerhafte Zusammenführungen – ein falsch-positives Ergebnis bei der Identitätsauflösung konnte das Zusammenführen der Krankenakten zweier fremder Personen bedeuten. Jede Matching-Regel erforderte die Freigabe durch die Compliance-Verantwortlichen. DSGVO-Audit-Trails mussten vorhanden sein, bevor ein einziger Datensatz zusammengeführt wurde, und durften nicht nachträglich ergänzt werden.
Einführung & Rollout
Nachgelagerte Systeme (CRM, Abrechnung, klinisch) wurden so umgestellt, dass sie per API aus der vereinheitlichten Plattform beziehen statt voneinander – ohne Big-Bang-Umstellung. Der Rollout erfolgte abteilungsweise über 4 Wochen, mit Rückfalloptionen bei jedem Schritt. Das interne Datenteam übernahm die laufende Verantwortung für die Pipeline 4 Wochen vor Projektende; wir blieben über den ersten Monat des eigenständigen Betriebs hinweg erreichbar.
Häufige Fragen zu diesem Projekt
Wie vereinheitlicht man Kundendaten über Systeme hinweg ohne falsche Zusammenführungen?
Konservative Identitätsauflösung: Jede Matching-Regel wurde vom Compliance-Verantwortlichen freigegeben, gegen bekannte Fälle validiert und im Zweifel auf Nicht-Zusammenführen ausgelegt — im Gesundheitswesen bedeutet ein falsch-positiver Merge, die Akten zweier fremder Personen zu vermischen. 87 % der Dubletten wurden aufgelöst; der Rest blieb bewusst getrennt, statt einen falschen Merge zu riskieren.Wie passt die DSGVO in eine Customer-Data-Platform?
Privacy by Design, in der wörtlichen Arbeitsreihenfolge: Die Audit-Trails standen, bevor der erste Datensatz zusammengeführt wurde — nicht nachträglich. Jeder Merge ist nachvollziehbar: wer, wann, nach welcher Regel. Genau das fragt eine Aufsichtsbehörde oder ein internes Audit ab.Wie migriert man nachgelagerte Systeme ohne Big Bang?
CRM, Abrechnung und klinische Systeme wurden nacheinander per API auf die vereinheitlichte Plattform umgestellt, abteilungsweise über vier Wochen sequenziert, mit Rückfallpfad bei jedem Schritt. Das interne Team übernahm die Pipeline-Verantwortung vier Wochen vor Projektende.