Warum Krankentagegeld in jede Versicherungs-App gehört

Krankentagegeld gehört zu den Leistungsfällen, bei denen für Versicherte viel auf dem Spiel steht: Einkommen, wirtschaftliche Stabilität, das Gefühl, „aufgefangen“ zu werden. Trotzdem läuft der Leistungsantrag in vielen Versicherungen noch immer erstaunlich analog: Papierformulare, Fax, Rückfragen per Telefon mit entsprechend langen Bearbeitungszeiten und hoher Fehleranfälligkeit.

Aus Sicht von CEOs und Enscheidungstragenden ist das doppelt teuer. Zum einen ist der Prozess intern aufwendig, zum anderen erwarten die Versicherten heute mobile, geführte Lösungen und diese Erwartung steigt mit jeder Banking- und E‑Commerce-App, die sie nutzen.

Hinzu kommt: Schlankere Prozesse verkürzen die Bearbeitungszeiten, senken Personalkosten und erhöhen die Kundenzufriedenheit.

Dieser Blog-Beitrag zeigt, wie aus einer kleinen Idee ein reales Feature werden kann. Kein Großprogramm, keine hundertköpfige Projektorganisation, sondern ein fachlich klar umrissenes Vorhaben, getragen von wenigen Personen und technisch umgesetzt von einem kleinen Entwicklerteam.

Worum es mir dabei geht:

• zu zeigen, dass du mit wenigen Ressourcen und einem klaren fachlichen Bild in kurzer Zeit ein belastbares Feature live bringen kannst,
• zu erklären, warum Fachlichkeit und tarifliche Logik den Unterschied machen, nicht nur die Technik
• und zu beschreiben, wie du mit dynamischen Fragebögen und einem Rule-Editor dafür sorgst, dass dein Fachbereich handlungsfähig bleibt, ohne ständig neue App-Releases anzustoßen.

Natürlich müssen bei der Integration in eine bestehende App-Plattform trotzdem alle aufsichtsrechtlichen Anforderungen (wie DORA), die Vorgaben zum Datenschutz (DSGVO) sowie interne Richtlinien beachtet werden. Der Vorteil: Du kannst meist auf bereits etablierte Standards aufsetzen und musst kein komplett neues Konzept entwickeln.

Warum Krankentagegeld in die App gehört

Die Geschichte beginnt nicht mit einem großen Strategieworkshop, sondern eher „nebenbei“. Im Austausch mit Kolleginnen und Kollegen tauchte immer wieder dieselbe Beobachtung auf:

„Es gibt schon eine App, aber es fehlen wirklich relevante Leistungsprozesse.“ Krankentagegeld ist dafür ein ideales Beispiel:

• Der Prozess ist klar abgrenzbar.
• Es gibt konkrete Nachweise (zum Beispiel Arbeitsunfähigkeitsbescheinigung).
• Derzeit wird vieles noch über Papierformulare bearbeitet.

Statt eine komplett neue App zu bauen, wurde schnell klar, dass wir das Krankentagegeld-Feature in eine bestehende Versicherungs-App integrieren.

Das hat mehrere Vorteile:

• Login, Identität und Sicherheit sind bereits gelöst.
• Die Versicherten kennen die App schon, somit ist die Einstiegshürde gering.
• Die IT-Infrastruktur ist bereits vorhanden, relevante Schnittstellen sind angebunden.

Gleichzeitig waren die Ressourcen bewusst knappgehalten:

Eine Person hat fast alle fachlichen Rollen übernommen: von der Produktdefinition über die UX-Perspektive bis hin zur fachlichen Qualitätssicherung. Auf der technischen Seite gab es zwei Entwickler:innen, die das Feature umgesetzt und den Prototypen gebaut haben.

Für CEOs und Entscheidungstragende ist an dieser Stelle vor allem der konkrete Umfang wichtig. Statt alles auf einmal zu wollen („alle Leistungsprozesse digital“), haben wir uns für den ersten Prototypen auf folgende Fragen konzentriert:

• Was muss ein Krankentagegeld-Feature im ersten Wurf zwingend können, damit es echten Mehrwert stiftet?
• Wo können wir bewusst sagen: „Das brauchen wir jetzt noch nicht, sondern erst im fertigen Produkt“?

Für unseren ersten Prototypen waren das im Kern:

• 1. Krankentagegeld-Fall einreichen: direkt aus der bestehenden App, per Kamera- oder Dateiupload.
• 2. Dynamisch geführter Fragebogen, der nur die wirklich relevanten Fragen stellt.
• 3. Einfache Rückmeldung inklusive Gamification, damit die Versicherten sehen, dass ihr Fall bearbeitet wird.
• 4. Push-Benachrichtigungen für Status-Updates.

Im Prototyp nicht enthalten waren zum Beispiel:

• eine vollautomatische Leistungsentscheidung,
• anspruchsvolle OCR-/KI-Auswertung der Dokumente,
• eine hochgradig individualisierte Benachrichtigungslogik.

Die Daumenregel dahinter lautet: Alles, was fachlich heikel ist, bei Versicherern unterschiedlich gehandhabt wird oder technischen Overhead erzeugt (zum Beispiel zusätzliche APIs oder neue Datenbanken), aber nicht zwingend für den ersten Prototypen nötig ist, wird erst bei der Integration in das reguläre Produkt umgesetzt.

Die Konsequenz: Mit einer fachlich verantwortlichen Person und zwei Entwicklern bleibt der Prototyp überschaubar und ist, abhängig von Kapazitäten und internen Freigabeprozessen, in kurzer Zeit erreichbar.

Idee schärfen und Rahmen abstecken

Der eigentliche Unterschied zwischen einer „netten App-Idee“ und einem tragfähigen Use Case liegt in der Fachlichkeit. Krankentagegeld ist kein Self-Service-Spielplatz, sondern ein Leistungsversprechen, das rechtlich und tariflich sauber erfüllt werden muss.

Deshalb beginnt der Weg zum Prototyp nicht in der Entwicklungsumgebung, sondern mit Fragen wie:

• Welche Ereignisse lösen typischerweise einen Krankentagegeld-Fall aus?
• Welche Nachweise sind zwingend, welche optional?
• Welche Informationen benötigt der Versicherer, um über die Leistungen entscheiden zu können?
• Welche fachlichen Entscheidungen (zum Beispiel Wartezeiten, Karenzzeiten, Obergrenzen) müssen vorbereitet werden?

Aus diesen Fragen entsteht das Herzstück des Features: der dynamische Fragebogen.

Statt ein langes Papierformular eins zu eins zu digitalisieren, denken wir den Prozess als Dialog:

• Die App stellt nur die Fragen, die zum konkreten Fall passen.
• Die Antworten steuern, welche Folgefragen überhaupt auftauchen.
• Fachliche Regeln sorgen dafür, dass nur die Daten erhoben werden, die wirklich benötigt werden.

Ein (vereinfachtes) Beispiel:

• Ist die versicherte Person angestellt oder selbstständig?
• Hat sich der Beruf verändert?
• Wird eine Rente bezogen?

Aus diesen Bausteinen ergibt sich ein Fragebaum: Angestellte durchlaufen einen anderen Weg als selbstständig Tätige. Wichtig ist dabei: Der Fragebogen bleibt für die Versicherten nachvollziehbar und für den Fachbereich steuerbar.

Damit sind wir beim zweiten zentralen Baustein: dem Rule-Editor bzw. Low-Code-Ansatz.

Statt alle Entscheidungslogik tief im Code zu verankern, sollten die fachlichen Regeln so modelliert sein, dass sie über einen Editor gepflegt werden können. Das bedeutet zum Beispiel:

• Fachliche Regeln wie „Für selbstständig Tätige ist immer Frage Y zu stellen“ sind in einer Regelbasis hinterlegt.
• Anpassungen, etwa bei neuen Tarifen oder geänderten Bedingungen, können durch den Fachbereich vorgenommen werden.

Hierbei sollte trotzdem eine interne Qualitätssicherung sichergestellt werden, zum Beispiel durch das Vier-Augen-Prinzip und einen schlanken, aber geregelten Freigabeprozess.

Für Entscheiderinnen und Entscheider ist genau das ein strategischer Hebel:

• Die Time-to-Market sinkt nicht nur beim ersten Prototyp, sondern auch bei späteren Anpassungen.
• Der Fachbereich wird nicht zum „Bittsteller“ bei der IT, sondern bekommt echten Gestaltungsspielraum.

Natürlich ersetzt ein Rule-Editor keine fachliche Verantwortung. Im Gegenteil: Er macht transparent, wo fachliche Entscheidungen getroffen werden, und zwingt zu einer klaren, strukturierten Modellierung der Regeln.

Krankentagegeld ist dabei nur ein Beispiel. Das Muster lässt sich auf andere Leistungsprozesse übertragen: stationäre Aufenthalte, Zahnleistungen, Unfallmeldungen. Überall dort, wo heute Papier, E‑Mail und Callcenter dominieren, lohnt sich der Blick: Was wäre, wenn wir genau diesen Prozess als schlankes App-Feature denken? Wo gibt es noch papierbasierte Prozesse, die nicht einfach nur digitalisiert, sondern neu gedacht werden sollten?

Wenn du in deinem Haus über ein ähnliches Vorhaben nachdenkst, sei es Krankentagegeld oder ein anderer Leistungsfall, lohnt sich ein kurzer, fokussierter Austausch:

• Welche Use Cases eignen sich für ein Minimum Viable Product (MVP)?
• Welche fachlichen Rollen brauchst du und was kannst du intern abdecken?
• Wie könnte eine sinnvolle Kombination aus Fachlichkeit, Rule-Editor und risikobasierter Qualitätssicherung für deinen konkreten Kontext aussehen?

Genau dafür entwickeln wir bei adesso gemeinsam mit Versicherern praxisnahe Ansätze. Vom ersten Workshop über den MVP bis zum skalierbaren Betrieb. Wenn du darüber sprechen möchtest, wie aus einer Idee in deinem Haus eine App-Funktion mit echtem Mehrwert wird, melde dich gern.