Turbine Kreuzberg beim XPOMET Health Hackathon 2019

15.10.2019 – Stefan Adolf

Hackathon Nummer 7 hat mich dieses Jahr in die unbekannten Gewässer der Gesundheitstechnologie und des maschinellen Lernens geführt. Ich habe schon länger versucht, mich in diesen Feldern einzuarbeiten, weshalb ich froh bin, dass mich endlich ein Anlass gezwungen hat, mich damit auseinanderzusetzen. Das Organisationsteam (danke impactfarm, dass es hervorragende Arbeit geleistet hat) erzählte uns vier Wochen im Voraus von der Herausforderung, die sie für uns vorgesehen hatten – und glücklicherweise haben sie sich auch einen Team-Namen ausgedacht: Ab dem 14. September konnten wir uns als "Turbiners" bezeichnen (was ein wenig falsch ist, da zwei von uns absolut nichts mit Turbine Kreuzberg zu tun haben). Wir hatten also vier Wochen Zeit, um unser Projekt vorzubereiten – was immer noch schwer ist neben dem Vollzeitjob – und es las sich: "intelligentes Claim-Management im digitalen Gesundheits-Ökosystem".

Nun, was Ihnen vielleicht nicht bewusst ist: Betrug ist ein hochgradig unterschätztes und sehr relevantes Thema in der Gesundheitsbranche. Laut einer McKinsey-Studie gibt es nur durch eine gründlichere Prüfung der Erstattungsansprüche der Leistungserbringer (Ärzte, Krankenhäuser, Hospize etc) ab 2017 ein Einsparpotenzial für die Krankenkassen in Deutschland von bis zu einer halben Milliarde Euro pro Jahr. Wie sich herausstellt, müssen 70% aller Anträge geprüft werden, aber nur 8-10% der potentiell betrügerischen Fälle werden schließlich identifiziert und korrigiert. Wenn das nicht nach einem guten Fall für maschinelles Lernen klingt, was dann?

Team Turbiners während einer "Sortier-Sitzung"

Da unser Team ziemlich zufällig zusammengestellt worden war, hatten wir außerordentliches Glück, Elena Williams in unserem Team gehabt zu haben. Sie studiert derzeit Data Science in Hamburg und konnte viel von ihrem Wissen in unser Projekt einbringen. Etwa zwei Wochen vor dem Hackathon suchten wir nach Datensätzen, die uns helfen könnten, und schließlich kam Elena auf die Idee diesen zu verwenden. Er enthält 130.000 Ansprüche von mehr als 5400 Anbietern und wurde von Experten geprüft, die betrügerische Einträge identifizieren konnten. Dabei ist es wichtig zu verstehen: Betrug kann nur auf der Ebene der Anbieter beobachtet werden. Die einzelnen Ansprüche sind ziemlich unauffällig, so dass jedes Modell, auf das wir kommen könnten, nur auf der Ebene der Anbieter und niemals auf der Ebene bestimmter Behauptungen operieren würde.

Das ursprüngliche Dokument verwendet drei Ansätze zur Analyse des Datensatzes: Logistische Regression, Random Forest Classifiers, Unterstützung von Vektormaschinen und einen Auto Encoder. Sie erreichten eine Vorhersagegenauigkeit von 50-90%. Um die Genauigkeit noch weiter zu erhöhen, versuchte Elena, bessere Funktionen zum Trainieren des Modells zu finden, und stützte sich dabei auf ein Keras-Deep-Learning-Modell mit vier Schichten. Laut der Trainingsauswertung erreichte sie am Ende eine Genauigkeit von 93%, was ziemlich hervorragend ist.

In der Zwischenzeit konzentrierte sich der Rest des Teams darauf, das Vorhersagemodell nutzbar zu machen. Also habe ich eine neue React-Anwendung erstellt, alle Testdaten in eine Sqlite-Datenbank (sic) importiert und eine Flask-Mikro-API geschrieben, die in der Lage ist, alle Ansprüche für einen bestimmten Anbieter auszuwählen. Sie enthält auch einen Endpunkt, um die Vorhersagefunktion des trainierten Modells aufzurufen. Ich habe recht früh bemerkt, dass dies keine einfache Aufgabe ist: All diese Datenwissenschaftler verwenden ihre hochgradig interaktiven Jupyter Notebooks aus dem einen oder anderen Grund, aber das ist nicht etwas, auf dem man einen "zuverlässigen" Dienst aufbauen möchte (oder?). Die meiste unserer Backend-Arbeit bestand also darin, Elenas Datentransformations- und Funktionsextraktionscode in ein plain-Python-Backend zu übertragen.

Der Plan war, eine Excel- / CSV-Datei mit einem Stapel von Empfänger- / Antragsdaten auf das Frontend hochzuladen, sie in die Präsentation zu übersetzen, die Elenas Modell erwarten würde, und die Vorhersage darauf laufen zu lassen. Zum Glück hat sich unser Junior-Entwickler Sascha um den Upload-Teil gekümmert, so dass ich mich auf die Integration konzentrieren konnte. Ich habe eine Beobachtung gemacht, die für andere hilfreich sein könnte: Obwohl Sqlite mit großartiger Unterstützung für den automatischen CSV-Import ausgeliefert wird, übersetzt es leider einen String-Wert von "NaN" in "NA" (was die NaN-Darstellung von Sqlite sein könnte, wer weiß). Beim erneuten Lesen dieser Daten mit Pandas interpretiert er sie als String. Als wir das herausgefunden hatten, war das Nachverfolgen der anderen 250 Zellen fast ein Kinderspiel. Python-Leute könnten das wissen, aber ich muss mich wiederholen: Die Features zur Tensor-Manipulation von Pandas DataFrame sind einfach hervorragend! Wer zufällig eine Datenanalyse in einer beliebigen Sprache durchführt – aufhören und zu Python wechseln, das erspart Tage der Datenverarbeitung.

Ein großes Problem, das wir nicht lösen konnten, ist die Skalierung der vorhergesagten Werte. Elenas Modell hat beim Training und Testen von Datensätzen gut funktioniert, aber das Aufrufen der Vorhersage auf einem einzigen Datensatz (bestehend aus etwa 60 Ansprüchen, die aus den ursprünglichen Trainingsdaten abgeleitet wurden) endete einfach in einer Reihe von unbrauchbaren Float-Daten. Am Ende entwickelte sie keinen binären Klassifikator, sondern eher einen Prädiktor, der eine gewisse Wahrscheinlichkeiten für die Identifizierung eines Betrugs liefert. Leider war es uns ohne eine klare Ausgabe nicht möglich, die Genauigkeit unseres Modells zu demonstrieren, aber ich bin ziemlich sicher, dass dies hauptsächlich auf unsere fehlende Erfahrung zurückzuführen ist.

Wenn man einfach nur ein Gefühl für alle Fortschritte bekommen möchte, findet sich hier ist ein entsprechendes Deployment (es schläft gerade, einfach 30 Sekunden Zeit geben, um aufzuwachen & weitere 20 Sekunden, um die Datenbank aus meinem S3-Eimer herunterzuladen): turbiners.netlify.com. Die Codebasis ist aufgeteilt in ein Python-Backend und ein React-Frontend. Es sieht so schön aus, weil ich Grommet JS für das Styling verwendet habe.

Ein weiterer Teil der Bewertung der Jury war ein Business Model Canvas für unseren Fall. Nun, da ich ein bodenständiger, klebriger, hart zuhörender Entwickler bin, muss ich zugeben, dass meine Fähigkeiten im Bereich der Geschäftsentwicklung nachgelassen haben, und ich bin immer noch der festen Überzeugung, dass "Business" und "Hackathon" nie gut zusammenpassen. Ich werde dennoch einige unserer Ideen teilen und möchte mich bei Florian Schulze bedanken, Turbiners Teammitglied Nr. 4, für die Mühe, die er uns erspart hat durch seine Ideen:

  • Werteversprechen: Wir wollen einen digitalen Service für das Management von Versicherungsfällen (auf unserer Seite) und einen Obfuscator / Anonymisierungsdienst (auf der Seite der Versicherung / des Kunden) aufbauen.
  • Unsere Hauptpartner wären Versicherungsprüfer mit viel Erfahrung in der Aufdeckung von Betrugsfällen bei medizinischen Ansprüchen.
  • Unsere Hauptkundensegmente wären Deutsche Krankenkassen und die ihnen angeschlossenen Beratungsunternehmen.
  • Als Vertriebskanäle haben wir Gesundheitskonferenzen und SaaS-Lösungsmarktplätze identifiziert (z.B. das Anbieten einer Blackbox-Service-Instanz von uns auf von Kunden betriebenen dedizierten AWS-Instanzen).
  • Nach einiges an Diskussion haben wir uns darauf geeinigt, dass unser bevorzugtes Geschäftsmodell darin besteht, einen Anteil von 0,5% aller analysierten Rückerstattungsdossiers zu übernehmen (was je nach Vorhersagequalität und Marktanteil etwa 50-100 Mio. € Umsatz/Jahr ausmachen könnte).

Hier ist unser finales Pitch Deck:

Einige Takeaways und Randbemerkungen

  • Das Gewinnerteam (bestehend aus nur 1 Mitglied) in unserer Kategorie hat sich seinen Preis absolut verdient: Er hat eine Android-App, eine Blockchain, einen VR-Kanal und MongoDB zusammengestellt und eine App entwickelt, die zunächst sagt, welche Fitnessübung man ausführen sollte, und dann Körperbewegungen scannt, um zu erkennen, dass man es richtig macht. Danach speichert sie die Leistung auf einer Blockchain und registriert Aktivitäten in Mongo. Ich bin mir todsicher, dass es die meiste Zeit der vierwöchigen Vorbereitung gebraucht hat, um all diese Teile zusammenzufügen, und ich war von seiner Demo ziemlich beeindruckt.
  • Die andere Kategorie befasste sich hauptsächlich mit der maschinellen Unterstützung bei "echten" Gesundheitsanwendungen, z.B. bei Augenerkrankungen. Ein Team stach sichtbar heraus: Sie benutzten ein seltsam aussehendes Linsenkonzept, um den Augapfel zu scannen. Mit ein wenig maschinellem Lernen / Bildklassifikation konnten sie wichtige Gesundheitszustände innerhalb eines Bruchteils der Kosten identifizieren, die ein "echtes" medizinisches Gerät benötigen würde.
Sascha scheint seinen Gang durch einen aufgeblasenen Darm zu genießen

Kontakte und Takeaways

Der wichtigste Grund, warum ich persönlich am Gesundheitshackathon teilnehmen wollte: Ich war auf der Suche nach Kontakten, Inspiration und Validierung des realen Anwendungsfalles, an dem ich derzeit bei Turbine arbeite. Das heißt: die Speicherung der Patientendaten eines Patienten und seiner Zugriffsrechte auf einem dezentralisierten Ledger. Und wurde nicht enttäuscht:

Mehrere Parteien, darunter vier Mitarbeiter der Berliner Charité, Anwälte, Ärzte und Berater, bestätigten meine Vermutung nachdrücklich: Es gibt in Deutschland absolut nichts Besseres als eine gemeinsame digitale Patientenakte. Alle Ansätze dazu gehen entweder in die Richtung von Medikamentenplänen, Fitnesstracking oder "eGK"-Anwendungen, die Daten sammeln und speichern, die ein Patient selbst erhebt (z.B. durch Verfolgung seines Blutdrucks). Es ist erstaunlich, aber jedes Mal, wenn ich unsere Idee grob illustriert habe, waren alle sehr aufgeregt und haben sofort ihre volle Unterstützung angeboten.

Fazit

So sollte eine Konferenz und ein Hackathon aussehen. Das Essen hätte besser sein können (keine Beschwerden über schlechtes Essen, wenn es kostenlos ist, ja, es tut mir jetzt schon leid), das Bier hätte reichlicher sein können, der Surround-Sound aller vier Konferenzpanels hätte weniger störend sein können und der unnötige künstliche "Druck", den die Hauptsponsoren des Hackathons im Vorfeld aufgebaut haben, war unnötig. Aber abgesehen davon hatten wir alle eine Menge Spaß! :) Als nächstes: Auf zur Diffusion 2019!