Architektur für mobile Versicherungs-Apps

Mobile Anwendungen für Versicherungsprozesse im Außendienst sind mehr als digitale Formulare. Sie unterstützen Mitarbeitende bei Vertrags-, Schaden- oder Leistungsfalldaten, Terminen, Nachweisen und Entscheidungen unter wechselnden Einsatz- und Verbindungsbedingungen. Die Architektur sollte deshalb beim fachlichen Ablauf, bei Vertrauensgrenzen und Wiederanlaufverantwortung beginnen – nicht bei einem bevorzugten Framework.

Nicht jeder Prozess muss vollständig offline verfügbar sein. Entscheidend ist, welche Aufgaben im Einsatz weitergeführt werden müssen, welche Entscheidungen aktuelle Daten aus Bestandssystemen benötigen und wie mit verzögerten, zurückgewiesenen oder nur teilweise verarbeiteten Übermittlungen umgegangen wird.

Versicherungsprozess, Rollen und Vertrauensgrenzen abgrenzen

Der Ablauf vor, während und nach einem Termin sollte vollständig beschrieben werden. Je nach Einsatz gehören dazu Zuweisung, Anfahrt, Identitätsprüfung, gegebenenfalls Einwilligung, Schaden- oder Leistungsdokumentation, fachliche Prüfung, Eskalation, Nacharbeit und Abschluss.

Ebenso wichtig sind die beteiligten Rollen und Organisationen. Außendienst, Disposition, Schaden- oder Leistungsbearbeitung, externe Servicepartner und Versicherte benötigen unterschiedliche Daten und Berechtigungen. Zu dokumentieren ist, wer das Gerät betreibt, wer die Anwendung verantwortet, welches System die verbindliche Fallakte führt und wer fehlerhafte Vorgänge korrigieren darf.

Informationen zur Unterstützung des Einsatzes sind von verbindlichen Geschäftsentscheidungen zu trennen. Ein Gerät kann einen freigegebenen Auftrags- oder Vertragsausschnitt vorhalten, während Deckungsprüfung, Leistungsentscheidung, Zahlungsfreigabe oder Betrugsprävention in zentralen Systemen verbleiben. Offline-Verfügbarkeit darf zwischengespeicherte Daten nicht unbemerkt zur fachlich verbindlichen Quelle machen.

Datenklassen vor der lokalen Speicherung festlegen

Für jede Tätigkeit ist zu bestimmen, welche Daten benötigt werden, welchem Zweck sie dienen, wie sensibel und aktuell sie sind, welches System sie verbindlich führt und wie lange sie auf dem Gerät verbleiben dürfen. Mindestens zu unterscheiden sind:

• schreibgeschützte Referenzausschnitte für einen zugewiesenen Vorgang;
• lokal bearbeitete, noch nicht übermittelte Entwürfe;
• zur Backend-Verarbeitung vorgemerkte Aktionen;
• Fotos, Dokumente und weitere Anhänge;
• Entscheidungen und Empfangsbestätigungen zentraler Systeme;
• Daten, die nicht auf dem Gerät gespeichert werden dürfen.

Für jede Klasse werden Download, Aktualisierung, Ungültigkeit und Löschung geregelt. Außerdem muss feststehen, welche Handlung bei veralteten oder fehlenden Referenzdaten zulässig ist. Technisch verfügbare Daten sind nicht automatisch ausreichend für eine neue Deckungs-, Leistungs- oder Zahlungsentscheidung.

Offline-Fähigkeit mit einem eindeutigen Statusmodell beschreiben

Offline-Fähigkeit kann nur lesenden Zugriff, lokale Entwürfe, eine Synchronisationswarteschlange oder ausgewählte fachliche Prüfungen ohne Verbindung bedeuten. Für jeden Arbeitsschritt sollte der notwendige Mindestumfang und jede blockierende Abhängigkeit dokumentiert sein.

Lokale Vorgänge benötigen stabile Kennungen und nachvollziehbare Zustände. Ein Modell kann zwischen Entwurf, vorgemerkt, wird übertragen, übermittelt und bestätigt unterscheiden. Hinzu kommen Ausnahmezustände wie Konflikt, zurückgewiesen und Korrektur erforderlich. Die konkrete Benennung kann variieren; Nutzende und Support müssen jedoch erkennen können, ob eine fachliche Aktion das verbindliche Backend erreicht hat.

Ausstehende Aktionen sollten in einer dauerhaften Ausgangswarteschlange (Outbox) oder einem vergleichbaren Mechanismus geführt werden. Abhängige Schritte dürfen beim nächsten Verbindungsaufbau nicht ungeordnet versendet werden. Auch Schemaänderungen, gelöschte Datensätze, abgelaufene Referenzdaten und ein App-Update bei noch offenen Vorgängen benötigen ein definiertes Migrationsverhalten.

Die offizielle Android-Dokumentation zur Offline-first-Architektur beschreibt eine lokale Datenquelle als anwendungsnahe Datenbasis. Für Versicherungsprozesse bleibt davon zu trennen, welche Vertrags-, Schaden- und Berechtigungsinformationen in zentralen Systemen fachlich verbindlich sind.

Synchronisation, Wiederholung und Nebenläufigkeit regeln

Eine Verbindung kann abbrechen, nachdem das Backend einen Vorgang verarbeitet hat, aber bevor das Gerät die Bestätigung erhält. Sichere Wiederholung ist deshalb keine reine Einstellung der Netzwerkbibliothek.

Für jede schreibende Operation ist festzulegen, ob sie von sich aus idempotent ist oder einen anwendungsspezifischen Idempotenzschlüssel benötigt. Geltungsbereich, Aufbewahrungsdauer und Verhalten bei erneuter Verarbeitung müssen dokumentiert werden. Gleiches gilt für Reihenfolge, Abhängigkeiten, Wiederholungsgrenzen, Backoff, endgültige Fehler und den Übergang zur manuellen Korrektur.

Gleichzeitige Änderungen benötigen eine Serverrevision oder eine andere explizite Vergleichsregel. Sofern es zum Ressourcenmodell passt, können bedingte Requests mit ETag und If-Match verlorene Aktualisierungen verhindern; RFC 9110 definiert die entsprechenden HTTP-Semantiken. Die Gerätezeit darf nicht allein über die Reihenfolge fachlicher Änderungen entscheiden.

Auch Löschungen brauchen eine Synchronisationsstrategie. Tombstones oder vergleichbare serverseitige Markierungen können verhindern, dass ein Offline-Gerät bewusst gelöschte Daten erneut anlegt.

Synchronisationskonflikte fachlich entscheiden

Statt eines einheitlichen Verfahrens sollte für Felder und Operationen eine passende Konfliktregel festgelegt werden:

• Nur ergänzen: Neue Beobachtungen oder Ereignisse werden hinzugefügt, ohne Historie zu überschreiben.
• Backend ist maßgeblich: Der aktuelle Stand des zentralen Systems gilt; eine lokal zurückgewiesene Aktion muss geprüft werden.
• Zusammenführbar: Unabhängige Felder können nach dokumentierten Regeln kombiniert werden.
• Manuelle Prüfung: Änderungen mit Einfluss auf Schaden, Leistung oder Zahlung werden durch eine zuständige Person abgeglichen.

Ein stilles Last-Write-Wins-Verfahren kann Änderungen verlieren und Inkonsistenzen in der Fallakte verursachen. Nutzende müssen erkennen, ob ein Vorgang lokal gespeichert, zur Übertragung vorgemerkt, synchronisiert, zurückgewiesen oder zur Prüfung ausstehend ist. Lokale Eingabe und Serverantwort sollten für eine kontrollierte Korrektur erhalten bleiben, soweit die Aufbewahrungsregeln dies zulassen.

Anhänge und Nachweisführung eigenständig behandeln

Fotos, Videos, Dokumente und Unterschriften haben häufig einen anderen Lebenszyklus als strukturierte Formulardaten. Zu unterscheiden ist, ob eine Datei in der Anwendung aufgenommen oder importiert wurde, wie temporäre Dateien und Vorschaubilder behandelt werden, ob das Original erhalten bleibt und wann lokale Kopien gelöscht werden.

Große Dateien können eine fortsetzbare Übertragung, abschnittsweise Prüfung und eine eigene Warteschlange benötigen. Je nach Prozess können Fall- oder Auftragskennung, Nutzende, Sitzung, Anwendungsversion, Aufnahme- oder Importquelle, Gerätezeit, Eingangszeit des Servers, Medientyp, Dateigröße, Hash und Übertragungsereignisse protokolliert werden.

Ein Hash kann die unveränderte Übereinstimmung mit einer bestimmten Datei unterstützen. Er beweist nicht allein, wann, wo oder unter welchen Umständen der Inhalt entstanden ist. Auch GPS- und EXIF-Daten sind vom Gerät gelieferte Signale und keine unabhängige Bestätigung. Rechtliche Wirkung, Beweiswert und Aufbewahrungskette sind für den konkreten Prozess rechtlich und technisch zu prüfen; die NIST-Hinweise zur Bewahrung digitaler Beweismittel bieten einen neutralen Referenzrahmen.

Identität, Gerätezustand und fachliche Berechtigungen trennen

Das Identitätsmodell sollte menschliche Nutzende, Client-Anwendung, Gerät, Sitzung und Organisation unterscheiden. Ein vertrauenswürdiges Gerätesignal authentifiziert keine Person; eine gültige Sitzung berechtigt nicht automatisch zum Zugriff auf jeden Schadenfall oder Anhang.

Für native Anwendungen mit OAuth beschreibt RFC 8252 die Autorisierung über einen externen User-Agent und PKCE als Grundlage. Die konkrete Ausgestaltung muss zum Identitätsanbieter (Identity Provider), zur Client-Klassifizierung und zum Bedrohungsmodell passen. Zugriffstokens, Anmeldedaten zur Token-Erneuerung und fachliche Daten sind als getrennte Schutzklassen zu behandeln.

Zu definieren sind Sitzungsdauer, erneute Authentisierung für risikoreichere Aktionen, Offline-Gültigkeit, Kontowechsel, Widerruf von Zugangsdaten sowie das Verhalten, wenn eine Person oder Zuweisung bei einem nicht verbundenen Gerät entzogen wird. Jede Backend-Operation benötigt weiterhin eine serverseitige Berechtigungsprüfung anhand von Person, Organisation, Rolle, Fallbeziehung und Aktion.

Geräteintegritäts- oder App-Attestation-Dienste können, soweit unterstützt, zusätzliche Risikosignale liefern. Sie sind weder Identitätsnachweis noch Garantie für einen vertrauenswürdigen Gerätezustand. Für nicht unterstützte, kompromittierte, gerootete, mit Jailbreak versehene, gemeinsam genutzte oder unverwaltete Geräte ist eine betriebliche Reaktion festzulegen.

Datenminimierung, lokale Sicherheit und Geräteverwaltung zusammendenken

Auf dem Gerät sollten nur Daten liegen, die für den zugewiesenen Vorgang erforderlich sind, und nur für den benötigten Zeitraum. Anwendungsspezifischer Speicher, Schutz von Datenbank und Dateien sowie plattformgestützte Schlüsselverwaltung richten sich nach Datenklassifizierung und Bedrohungsmodell. Der OWASP Mobile Application Security Verification Standard kann die Prüfung von Speicherung und unbeabsichtigter Datenweitergabe strukturieren.

Die Betrachtung darf nicht bei der Hauptdatenbank enden. Backups, temporäre Dateien, Vorschaubilder, Dokumentansichten, Absturzberichte, Logs, Zwischenablage, Teilen-Funktionen, Screenshots und Benachrichtigungen können dieselben Informationen über andere Wege offenlegen.

Löschregeln sind nach Bestätigung, Abmeldung, Kontowechsel, Entzug eines Auftrags und Außerbetriebnahme der Anwendung festzulegen. Ein serverseitiger Token-Widerruf entfernt keine Daten von einem Offline-Gerät. Auch Remote Wipe hängt vom Modell des Mobile-Device-Managements (MDM) und von einer erneuten Verbindung ab; es darf nicht die einzige Schutzmaßnahme für sensible lokale Daten sein.

Standortdaten benötigen einen dokumentierten Zweck und eine angemessene Genauigkeit. Eine dauerhafte Ortung ist nicht allein deshalb angemessen, weil das Gerät sie technisch ermöglicht. Zweck, Zugriff, Aufbewahrung und Übermittlung sind ebenso für Fotos, Dokumente, Unterschriften und Supporttelemetrie zu prüfen.

Backend-Integration und Teilfehler beherrschbar machen

Der mobile Client sollte nicht jede Regel und Integration der Bestandssysteme nachbilden. Eine auf mobile Clients zugeschnittene Integrationsschicht oder ein Backend-for-Frontend (BFF) kann Daten aufbereiten, Aufrufe koordinieren und Änderungen in Bestandssystemen vom Client entkoppeln. Diese Grenze verbindet mobile Softwareentwicklung mit Enterprise Integration und benötigt eigene Regeln für Sicherheit, Verfügbarkeit, Verantwortung, Monitoring und Versionierung.

API-Kompatibilität, Timeouts, Wiederholungs- und Idempotenzverhalten, Größenlimits für Anhänge, asynchrone Verarbeitung und Teilfehler müssen dokumentiert werden. Wenn strukturierte Daten angenommen, Anhänge aber zurückgewiesen werden, braucht der Vorgang einen wiederaufnehmbaren Zustand statt einer unklaren Erfolgsmeldung oder einer doppelten Gesamtsendung.

Für teilweise ausgeführte Geschäftsaktionen ist festzulegen, ob Wiederholung, fachliche Kompensation oder manuelle Datenkorrektur möglich ist. Die mobile Oberfläche darf keinen Rollback versprechen, wenn nachgelagerte Systeme bereits eine nicht automatisch umkehrbare Aktion abgeschlossen haben.

Unterstützte Verteilung und Störungsbehebung verwenden

Die meisten Dienste von Visual Studio App Center einschließlich CodePush wurden am 31. März 2025 außer Betrieb genommen. Laut aktuellem Hinweis zur App-Center-Außerbetriebnahme wurde die Unterstützung für Analytics & Diagnostics anschließend bis Ende März 2027 verlängert. Das Repository react-native-code-push wurde am 20. Mai 2025 archiviert. Außer Betrieb genommene Dienste und archivierte Repositories sollten nicht als Standardbausteine einer neuen Architektur eingeplant werden.

Zu planen sind Verteilung über App-Stores oder unternehmensinterne Bereitstellung, Verantwortung für Signierung, Ablauf von Zertifikaten und Provisioning, Geräteabdeckung, unterstützte Mindestversionen des Betriebssystems, Backend-Kompatibilität und Kriterien für verpflichtende Updates. Store-Verfahren können die weitere Verteilung begrenzen, bringen bereits aktualisierte Geräte aber nicht automatisch auf eine frühere Binärversion zurück.

Ein gestaffelter Rollout bei Google Play kann angehalten werden; bereits aktualisierte Geräte behalten die Version bis zu einem weiteren Update. Ein Phased Release bei Apple verteilt automatische Updates über sieben Tage, erlaubt jederzeit einen manuellen Download und kann insgesamt bis zu 30 Tage pausiert werden.

Für Störungen sind mehrere Maßnahmen zu unterscheiden: weitere Verteilung stoppen, eine riskante serverseitige Funktion nur dann deaktivieren, wenn diese Möglichkeit bewusst vorgesehen wurde, Abwärtskompatibilität sichern und eine korrigierte Binärversion veröffentlichen. Feature-Schalter oder serverseitige Schalter bewirken keine Rückkehr zur vorherigen Binärversion und reparieren keine bereits veränderten Daten.

Dynamisches Nachladen von Code bringt zusätzliche Anforderungen an Sicherheit, Integrität und Store-Konformität mit sich. Die offizielle Android-Dokumentation zu Dynamic Code Loading empfiehlt, darauf ohne fachliche Notwendigkeit zu verzichten und bei Einsatz vertrauenswürdige Quellen und Integrität abzusichern. Auch die Apple-Vorgaben sind für den konkreten Update-Mechanismus zu prüfen. Eine OTA-Lösung sollte erst gewählt werden, wenn Wartungsverantwortung, Sicherheitsupdates und Store-Konformität geklärt sind.

Betriebsqualität an fachlicher Fertigstellung ausrichten

Zu überwachen sind geeignete Anwendungs- und Betriebssystemversionen, Verweildauer in der Synchronisationswarteschlange, Übertragungsergebnisse, API- und Berechtigungsfehler, Anhangsstatus, Absturzberichte und der fachliche Abschluss des Vorgangs. Dabei dürfen keine unnötigen personenbezogenen Daten, Zugriffstokens, Zugangsdaten oder sensiblen Falldetails in Logs gelangen.

Datenschutzgerechte Korrelationskennungen können Ereignisse aus mobiler Anwendung und Backend verbinden. Supportteams benötigen eine auditierbare Möglichkeit, ausstehende Vorgänge zu prüfen, Ablehnungsgründe zu verstehen und eine freigegebene Korrektur oder erneute Übermittlung anzustoßen. Direkte, undokumentierte Datenbankänderungen sollten nicht das reguläre Wiederanlaufverfahren sein.

Verantwortlichkeiten für Störungen, Identitäts- und Gerätezugriff, Datenkorrektur, Release-Entscheidungen, Kommunikation mit Versicherten oder Außendienst sowie Außerbetriebnahme müssen benannt sein. Ein technisch erfolgreicher API-Aufruf reicht nicht aus, wenn ein fachlicher Vorgang weder abgeschlossen noch kontrolliert wiederaufgenommen werden kann.

Betriebs- und Beschaffungsmodell festlegen

Die Architektur hängt auch davon ab, wer Geräteflotte, Mobile-Device-Management, App-Signierung, Store-Konten, Zertifikate, Backend-Dienste, Monitoring und Support verantwortet. Zu dokumentieren ist, ob Geräte dem Unternehmen gehören, privat genutzt oder geteilt werden und welche Kontrollen in jedem Modell tatsächlich umsetzbar sind.

Bei Produkt, Plattform oder Umsetzungspartner sollten unterstützte Geräte und Betriebssysteme, Zusagen zu Sicherheitsupdates, Incident- und Eskalationsverantwortung, Serviceabhängigkeiten, Unterauftragnehmer, Datenstandorte, Zugriff auf Quellcode und Dokumentation, Migrationsunterstützung und Ausstiegsregelungen bewertet werden. Abkündigung, Außerbetriebnahme und Repository-Status müssen während des gesamten Lebenszyklus beobachtet werden.

Diese Punkte sind Bewertungskriterien. Sie behaupten weder, dass jedes Vorhaben dasselbe Betriebsmodell benötigt, noch dass Deka Technology sämtliche genannten Betriebsleistungen anbietet.

Architektur- und Beschaffungscheckliste

• Sind Versicherungsprozess, Rollen, Vertrauensgrenzen und verbindliche Systeme dokumentiert?
• Welche Aktionen müssen offline funktionieren, und welche benötigen aktuelle Backend-Prüfung?
• Sind Referenzdaten, Entwürfe, Aktionen, Anhänge und Empfangsbestätigungen getrennt?
• Können Nutzende und Support vorgemerkte, übermittelte, bestätigte, konfliktbehaftete, zurückgewiesene und korrekturbedürftige Vorgänge unterscheiden?
• Sind Wiederholung, Idempotenz, Reihenfolge, Abhängigkeiten und endgültige Fehler geregelt?
• Gibt es für jedes relevante Feld eine Regel für Ergänzung, Backend-Vorrang, Zusammenführung oder manuelle Prüfung?
• Sind Aufnahme, Übertragung, Empfang, Aufbewahrung und Löschung von Anhängen dokumentiert?
• Sind die Aussagegrenzen von Hashes, GPS- und Gerätedaten bekannt?
• Bleiben Person, Anwendung, Gerät, Sitzung, Organisation und Fallberechtigung unterscheidbar?
• Sind Offline-Gültigkeit, Kontowechsel und entzogene Zuweisungen berücksichtigt?
• Werden Speicher, Backup, Cache, Logs, Zwischenablage, Screenshots und Benachrichtigungen geprüft?
• Lassen sich Teilfehler im Backend ohne doppelte oder unklare Geschäftsaktionen korrigieren?
• Verwendet das Release-Modell unterstützte Dienste, und sind Signierung sowie Mindestversionen verantwortlich zugeordnet?
• Können weitere Verteilung gestoppt, serverseitige Risiken begrenzt und korrigierte Versionen ausgeliefert werden, ohne dies als Rollback zu bezeichnen?
• Können Support und Betrieb einen fehlgeschlagenen Vorgang über mobile Anwendung und Backend nachvollziehen und kontrolliert korrigieren?
• Sind Geräteverwaltung, Betrieb, Lieferantenabhängigkeiten und Exit-Verantwortung geregelt?