Die elektronische Patientenakte (ePA) ist eine Art der digitalen Dokumentenverwaltung. Dort können wichtige Unterlagen von Patienten eingereicht und Freigaben, zum Beispiel an Ärzte, erteilt werden. Seit Anfang 2021 gibt es die staatliche Verpflichtung für alle gesetzlichen Versicherer, eine entsprechende App für die Versicherten anzubieten. Für die privaten Versicherer existiert bislang noch keine derartige Verpflichtung, doch sehe ich auch für sie hier mehr Nutzen als Risiko. Die aktuelle, bundesweite Initiative sorgt schon einmal für die Aufmerksamkeit, die das Thema verdient.

In einem ersten Schritt muss die erforderliche digitale Infrastruktur von den privaten Versicherern aufgebaut werden. Immerhin muss einerseits die tadellose Funktionalität der Backend-Systeme der Versicherer gewährleistet werden, andererseits ist auch das Design und die User-Experience der App von außerordentlicher Wichtigkeit. Doch dazu später mehr.

Auch die Frage nach der Gesundheitskarte soll kurz erwähnt werden. Bei der Überlegung, die Plastikkarte durch eine virtuelle Karte zu ersetzen, sind ein paar Vor- und Nachteile zu berücksichtigen. Das digitale Einlesen über das Smartphone erscheint auf den ersten Blick elegant, entpuppt sich beim Praxisversuch aber als fehleranfällig. Die Plastikkarte sollte zumindest als Option bestehen bleiben.

Entwicklung der App: make or buy?

IT-Anwendungen stellen heute nicht mehr nur Kostenreduzierer, sondern signifikante Werttreiber für einen Versicherer dar. Sie bilden zunehmend das Kerngeschäft eines Versicherers. Dementsprechend sollte ihnen die Aufmerksamkeit zuteil werden, die sie verdienen. Die entsprechenden Unternehmensstrukturen und Kompetenzen vorausgesetzt, ergibt es Sinn, die App für die ePA selbst zu entwickeln. Das Problem: So, wie die IT-Organisation vieler Privatversicherer aufgestellt ist, ist das nicht zu stemmen. Die Gründe hierfür liegen u. a. in dem unzureichenden Skill-Set der Organisation und ihrer allgemeinen Prozessabläufe. Die Herausforderung Kernversicherungssysteme und Backend-Systeme zu entwickeln, ist eine völlig andere, als intuitiv zu bedienende, schicke Apps für den Kunden.

Es stehen nun grundsätzlich drei Möglichkeiten zur Beschaffung einer ePA-App zur Verfügung: Entweder wird sie komplett intern entwickelt, extern eingekauft oder man kauft sich lediglich die Programmierleistung ein, ohne die Kontrolle über die Entwicklung vollständig abgeben zu müssen. Option Nummer drei scheint mir persönlich die beste Lösung zu sein. Sie bietet eine Reihe von Vorteilen: Die App kann schnell online gehen, kontinuierlich in kleinen, inkrementellen Schritten weiterentwickelt werden und es findet eine schnellere Wertrealisierung des Investments statt. Klassische von Versicherungsunternehmen durchgeführte Projekte, seien sie auch noch so cross-funktional und agil aufgebaut, brauchen zu lange, sind zu teuer und schlicht nicht für die Entwicklung einer solchen Software optimiert.

Regulatoren und: eine oder mehrere Apps?

Zunächst ein technischer Aspekt: Anwendungen, die auf die Telematik-Infrastruktur zugreifen, müssen von der gematik (Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH) freigegeben und zertifiziert werden. Die standardmäßige Integration der Freigabe in den Prozess der Softwareentwicklung kostet etwas Geld – ich halte sie aber für nötig.

Zur Frage nach der Anzahl der Apps: Hier ist die Sachlage komplizierter. Als Versicherer, mit mehreren Sparten, wie Kranken-, Lebens- und Sachversicherung kann es Sinn ergeben, eine App für jeden dieser Bereiche anzubieten. Innerhalb eines Versicherungsbereichs ist hingegen keine weitere Unterteilung nötig. Zum einen, da multiple Apps für den Benutzer kompliziert in der Handhabung sind. Sie müssen alle einzeln installiert und aufgerufen werden, damit der Benutzer Zugriff auf den gewünschten Service erhält. Darüber hinaus müssen alle Apps einzeln vom Versicherer beworben werden, da der Kunde sie sonst gegebenenfalls nicht findet. Auch die Verwaltung auf dem Smartphone ist aufwendig. Der Nutzer muss sich auf allen Apps separat anmelden und Einstellungen vornehmen. Wenn die Apps von verschiedenen Entwicklerteams programmiert wurden, können sich Design und Navigation voneinander unterscheiden. Auch diese Unterschiede können für Verwirrung beim Kunden sorgen. Außerdem kann das Problem auftreten, später dazu gekaufte Software nicht mehr in bestehende Systeme integrieren zu können.

„Im Zweifel haben die Apps unterschiedliche Entwicklungsstände, weil sie von unterschiedlichen Teams entwickelt werden. Das heißt Look und Feel sind unterschiedlich. Das ist gruselig für jeden Nutzer.“

Eine Studie: Welche White-Label-App ist besser?

Im Rahmen eines vergangenen Projekts haben wir die zwei großen Anbieter von White-Label-Apps miteinander verglichen (Link zum Download der Studie).

IBM auf der einen und RISE zusammen mit BITMARCK auf der anderen Seite. Die Produktqualität des Versicherers haben wir hierbei ausgeblendet und uns ausschließlich auf die technische Umsetzung der App fokussiert.

„Kauft das Aktensystem einfach von der Stange ein, […] aber das ist nichts, wo man sich in erster Linie signifikant vom Wettbewerb differenzieren kann. Bei den Apps sieht das anders aus.“

Bei der RISE-BITMARCK sind wir oft auf Fehlermeldungen gestoßen, ohne zu wissen, wie diese zu beheben sind. Auch was die Navigation der Apps betrifft, nimmt die IBM-App den Nutzer besser an die Hand. Die RISE-BITMARCK verlangt nach einer aufwendigen Video-Identifizierung, bei der in einem Video-Call der Personalausweis vorgezeigt wird. Auch technische Probleme beim Login machten uns hier zu schaffen. Die schwarz-weißen E-Mails von RISE-BITMARCK, die für die Geräte-Freischaltung benötigt werden, tun ihr Übriges und wirken wie aus der Zeit gefallen. Das bestärkt den Gesamteindruck, dass IBM nicht nur bei funktionalen Fragen, sondern auch bei Designentscheidungen einen besseren Job macht.

Technische Unzulänglichkeiten sowie Grafik- und Navigationsmakel gehen klar auf die Kappe der Entwickler. Fairerweise sei aber gesagt, dass ein paar der Komplikationen, auf die wir während unseres Tests gestoßen sind, auf die Vorgaben der gematik zurückzuführen sind. Die weiteren Unterschiede zwischen IBM und RISE-BITMARCK liegen mutmaßlich in der unterschiedlichen Schwerpunktsetzung bei der Entwicklung der Apps, dem Budget und der Unternehmensorganisation. Meine These lautet daher: Die Diskrepanz, die – Stand heute – zwischen den beiden Apps liegt, wird auch in fünf Jahren noch nicht verschwunden sein.

Die Podcast-Ausgaben zur elektronischen Patientenakte sind in Form einer 4-teiligen Miniserie im Digital Insurance Podcast erschienen. Hier geht es zu den einzelnen Folgen:

Teil 1: Was ist eine ePA und wie funktioniert das?

Teil 2: Wie sollte ich als Versicherer heute Apps entwickeln?

Teil 3: Wie viele Apps braucht ein Versicherer und wie viele ein Kunde?

Teil 4: Vergleich der White-Label-Apps der großen Anbieter

Über den Podcast

Seit April 2020 veröffentlicht Jonas Piela regelmäßig Gespräche zur digitalen Transformation mit Vorständen und Managern der Versicherungswirtschaft. Sein Ziel ist, dass seine Zuhörer einem lockeren Gespräch unter Gleichgesinnten lauschen und so Ideen und Anregungen für die eigene Arbeit mitnehmen. Zu finden ist der Podcast unter anderem bei Google, Apple und Spotify sowie unter pielaco.com/podcast und dkm365.de.

Bild: © HNFOTO – stock.adobe.com

Source: ImmoCompact