Im Jahr 2024 übernahm RomSoft im Rahmen des EDIH-DIZ-Projekts eine Rolle in der sogenannten „Test-before-Invest“-Phase: Unsere Aufgabe war es, medizinischen Praxen zu zeigen, wie Digitalisierung in der Praxis tatsächlich aussieht. Online-Terminvereinbarungen, virtuelle Sprechstunden, elektronische Patientenakten – jeder erdenkliche digitale Service wurde vorgeführt, damit jede Praxis selbst entscheiden konnte, ob sie diese Werkzeuge überhaupt benötigt.

Wo wir standen

Wir sind mit Erfahrung aus ähnlichen Projekten in dieses Vorhaben gestartet – etwa EMIM – das auf dem Papier alles bot, was man von einer vollständigen medizinischen Plattform erwarten würde: Online-Terminplanung mit automatischen Erinnerungen, elektronische Patientenakten, integrierte Abrechnung und darüber hinaus eine reibungslose Kommunikation zwischen allen Beteiligten im System, insbesondere zwischen Ärzten und Patienten, sowie ein Modul zur Kommunikation mit Apothekern und zur Medikamentensuche.

Was Nutzer sich tatsächlich wünschten

Was sich in der Realität als anders herausstellte, war nicht die Technologie – es waren die Erwartungen der Projektbeteiligten. Sie waren nicht an einer generischen Plattform interessiert. Ihre Fragen waren konkret: Wie helfe ich meinen Patienten mit Ernährungs- und Diabetesproblemen, ein extrem strenges und komplexes Protokoll einzuhalten? Wie bringe ich einen Patienten in einer ländlichen Region, ohne jegliche Erfahrung mit Technologie, dazu, tatsächlich eine mobile App zu nutzen, um Termine zu buchen?

So gut sie auch gebaut war – eine generische Anwendung blieb eine abstrakte Geschichte. Die Praxen konnten sich in einer Anwendung, die im Grunde für jemand anderen entwickelt worden war, nicht wiederfinden.

Vom Präsentieren einer Demo zum Erstellen einer eigenen

Wir verabschiedeten uns von der Idee, „eine Demo zu präsentieren“, und verfolgten stattdessen den Ansatz, „eine Demo zu erstellen“. Für jede Praxis entwickelten wir eine maßgeschneiderte App – mit ihren eigenen Leistungen, ihrer eigenen Mischung aus Fachrichtungen und Ärzten, ihrem eigenen Patientenablauf. Wir zeigten ihnen nicht mehr irgendeine Anwendung. Wir zeigten ihnen ihre eigene Praxis, digitalisiert.

Das bedeutete natürlich jedes Mal deutlich mehr Aufwand – jede Demo war praktisch ein eigenes kleines Projekt. Aber dadurch kamen Dinge zum Vorschein, die eine generische Demo nie ans Licht gebracht hätte. Die oben erwähnte Praxis für Ernährungsberatung und Diabetesbehandlung etwa bat uns um etwas, das wir überhaupt nicht bedacht hatten: nicht nur eine Terminplanung, sondern einen Medikamentenplan mit Push-Benachrichtigungen – denn für sie zählte die Therapietreue genauso viel wie die Konsultation selbst.

Andere Praxen trieben diese Individualisierung noch weiter. In einem pädiatrischen Therapiezentrum etwa änderte sich das gesamte Vokabular – es gab keinen „Arzt“, nur „Therapeuten“ – und ebenso das Patientenprofil selbst: Kinder folgten personalisierten Interventionsplänen über mehrere Therapiearten hinweg, jede unterteilt in Bewertungsbereiche, in denen das Personal fortlaufend Ziele und Aktivitäten hinzufügen und verfolgen konnte, um anschließend für einen beliebigen Zeitraum einen Fortschrittsbericht zu erstellen.

Bei einem anderen Projektpartner aus dem juristischen Bereich ging die Individualisierung in eine völlig andere Richtung. Termine erforderten herunterladbare Einwilligungsformulare – für die Verarbeitung personenbezogener Daten, für biologische Probenentnahmen, für psychiatrische Gutachten auf Anfrage – sowie weitere, für Rechtsfälle spezifische Anpassungen, und Bestätigungen wurden als offizielles Dokument statt als einfache Benachrichtigung ausgestellt.

Jedes solche Gespräch offenbarte einen Bedarf, der von unseren Annahmen abwich, und mit der Zeit zeichnete sich ein Muster ab: Die Bedürfnisse der Praxen waren keine kleinen Variationen desselben Produkts. Es waren grundlegend unterschiedliche Konfigurationen derselben zugrunde liegenden Bausteine – Fachrichtungen, Terminplanung, Patientenakten, Patientenkommunikation.

Der nächste Schritt

Das führt uns in die Phase, an der wir gerade arbeiten: Statt jedes Mal eine individuelle Demo zu erstellen, bauen wir diese Bausteine zu einer modularen Plattform um, die ein Praxisadministrator selbst konfigurieren kann – wie viele Fachrichtungen, wie viele Ärzte pro Fachrichtung, welche Art von Terminen akzeptiert werden, welche Dokumente erzeugt werden. Im Grunde übertragen wir das, was uns Dutzende reale Gespräche gelehrt haben, in konfigurierbare Optionen, anstatt jedes Mal Code von Grund auf neu zu schreiben.

Die gleiche Logik, angewendet auf KI

Die gleiche Logik griff, als KI ins Spiel kam. Eine wiederkehrende Beschwerde der Ärzte betraf die verlorene Zeit beim manuellen Ausfüllen standardisierter medizinischer Formulare – etwa Anlage 43, auch als „Arztbrief“ bekannt, jedenfalls Dokumente mit festem Format, die jede Praxis unabhängig von ihrer Fachrichtung erstellen muss.

Daraus entstand ein Transkriptionsmodul: Ein Arzt diktiert während der Konsultation, und das System transkribiert das Gespräch, extrahiert genau die Informationen, die eine bestimmte Vorlage benötigt, und trägt sie automatisch ein. Nach der Validierung war es keine einmalige Individualisierung mehr, sondern wurde zu einer eigenständigen Funktion – verfügbar für die gesamte Plattform, für jede Praxis, jeden Projektpartner.

Ein Assistent zur Terminbestätigung, aufgebaut auf einem Telefondienst, ging den entgegengesetzten Weg. Er ruft Patienten an, um bevorstehende Termine per Sprachanruf zu bestätigen, und übergibt das Gespräch an einen menschlichen Mitarbeiter, wenn er es nicht selbst abschließen kann – womit ein reales Engpassproblem für einen Projektpartner gelöst wurde, der täglich Hunderte Termine manuell bestätigen musste. Entwickelt wurde er jedoch nur als Proof of Concept. Das ist wohl die klarste Test-before-Invest-Entscheidung im gesamten Projekt: Mit jedem Projektpartner konnten wir von Fall zu Fall vereinbaren, wie weit eine Umsetzung gehen sollte – eine vollständig ausgebaute Funktion, offen für die gesamte Plattform, oder ein Proof of Concept, der zunächst nur eine Frage beantworten sollte: Lohnt es sich überhaupt, weiterzubauen.

Eine Erkenntnis, die in beide Richtungen wirkt

Wir sind mit der Überzeugung in dieses Projekt gestartet, dass unsere Aufgabe das Lehren sei: den Praxen zu zeigen, was wir bereits entwickelt hatten, und sie entscheiden zu lassen, was sie brauchten. Womit wir nicht gerechnet hatten, war, dass das Lehren in beide Richtungen verlaufen würde. Jede Frage, die wir nicht sofort beantworten konnten, jedes „Aber wie würde das bei uns funktionieren“ – das war eine Praxis, die uns etwas beibrachte, das wir lernen mussten.

Das ist der Teil, den wir in das mitnehmen, was wir jetzt entwickeln. Aus dem Zuhören, mehr als wir erwartet hatten – gerade in dem Moment, in dem wir dachten, wir seien diejenigen, die erklären sollten – entstand die Idee für ein neues Produkt: ein Produkt, das noch mitten in der Entwicklung steckt, mit echten technischen Entscheidungen, die dabei laufend getroffen werden. Warum also lesen Sie das hier?

Wir würden gerne mit Ihnen sprechen

Der Lernprozess geht weiter. Wenn Sie eine Klinik oder eine kleine Arztpraxis führen und uns Ihre Vorstellung davon mitteilen möchten, wie Ihre digitale Praxis aussehen soll, freuen wir uns, von Ihnen zu hören.