Was die elektronische Patientenakte ausmacht und in welcher Umgebung sie idealerweise entwickelt wird. Dieser Gastbeitrag basiert auf der gleichnamigen Miniserie des Digital Insurance Podcasts mit Jonas Piel.
Was ist die ePA?
Die elektronische Patientenakte (kurz: 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.
“Das ist eine Wahnsinns-Chance, die hier die Versicherer haben.”
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 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 zunehmends das Kerngeschäft eines Versicherers. Dementsprechend sollte ihnen die Aufmerksamkeit zuteil werden, die sie verdienen. Die entsprechenden Unternehmensstrukturen und Kompetenzen vorausgesetzt, macht 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.
“Anders als vor 10 oder 20 Jahren ist heute die IT auch kernrelevant.”
Es stehen nun grundsätzlich drei Möglichkeiten zur Beschaffung einer solchen 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 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 Projekte von Versicherungsunternehmen durchgeführt, 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 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 machen 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 (Den Link zum Download der Studie findet ihr hier: https://bit.ly/3BXi1py):
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 entscheidenden 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 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 https://pielaco.com/podcast.