Web-App für die Praxis entwickeln: Anforderungen vor dem Angebot klären

Kurzantwort: Eine Praxis-Web-App braucht vor dem Angebot fünf Anforderungsblöcke geklärt: Rollen und Rechte, Termin-Regelwerk, Altdatenbestand, Schnittstellen zum bestehenden System und Betriebsfallplan. Feature-Listen ohne diese Regeln führen zu Nachträgen, die mehr kosten als die Entwicklung selbst.

Über eine Praxis-Web-App entscheiden fünf Anforderungsblöcke, die selten auf der Feature-Liste stehen: Das Rollen- und Rechtemodell, das Termin-Regelwerk, der Altdatenbestand, die Schnittstelle zum vorhandenen Praxissystem und ein definierter Weg für den Fall, dass um 07:55 nichts geht. Design, Framework und Hosting sind danach Umsetzungsfragen.

Eine Feature-Liste entsteht in zwanzig Minuten. „Terminbuchung, Dokumenten-Upload, Nachrichten, Erinnerungen" — damit lässt sich kein Preis rechnen und kein System bauen, weil in jedem dieser vier Wörter eine Praxisregel steckt, die nur die Praxis kennt. Unten steht der Katalog, mit dem ich diese Regeln vor dem Angebot einsammle: 46 Fragen in sieben Blöcken, dazu eine Lastrechnung und ein Punktetest, der sagt, ob ein Festpreis überhaupt sinnvoll ist.

Eine Praxis-App ersetzt kein Praxisverwaltungssystem

Der häufigste Konstruktionsfehler im Anforderungskatalog ist der Größenwahn: Die neue Web-App soll auch Karteikarte, Abrechnung und Dokumentenarchiv können. Das Ergebnis ist ein Zweitsystem mit denselben Daten in zwei Zuständen — und die Frage, welches von beiden recht hat, wenn sie sich widersprechen.

Die tragfähige Variante ist eine App, die sich neben das bestehende System hängt und genau die Vorgänge übernimmt, die Patientinnen und Patienten selbst auslösen: Termin anfragen, Formular vorab ausfüllen, Befund abholen, Rückruf anfordern. Alles, was Ihr Praxisverwaltungssystem heute schon macht, streichen Sie aus dem Katalog. Als Regel: Steht eine Funktion in beiden Systemen, muss im Katalog stehen, welches System die Wahrheit hält und in welche Richtung Daten fließen. Ohne diesen Satz ist die Funktion nicht spezifiziert.

Falls Sie ohnehin gerade vor der Systemfrage stehen und nicht sicher sind, ob überhaupt eine Eigenentwicklung nötig ist, gehört die Auswahlrunde vor den Katalog: Praxis Management Software: Auswahl, Kosten und Einführung.

Der Katalog: 46 Fragen in sieben Blöcken

Die Spalte ganz rechts zeigt, was es kostet, einen Block erst während der Umsetzung zu klären — Spannen aus meiner eigenen Kalkulation, nicht aus einer Branchenerhebung.

Alle sieben Blöcke offen ergeben 76 bis 148 Stunden Nacharbeit. Das ist typischerweise mehr, als ein schlankes Praxisportal im Erstumfang überhaupt hat. Nachträge sind nicht deshalb teuer, weil jemand daran verdienen will, sondern weil sie in fertigen Code eingreifen: Ein Rollenmodell, das nach der Umsetzung geändert wird, berührt Datenbank, API, Oberfläche und Tests gleichzeitig.

Drei Blöcke tragen den größten Teil dieses Risikos. Sie stehen deshalb ausführlich unten.

Block 1: Die 6×9-Matrix

Sechs Rollen, neun Aktionen, 54 Zellen — und jede Zelle braucht ein Ja, ein Nein oder ein Bedingt. Die Rollen: Praxisleitung, angestellte Behandelnde, MFA am Empfang, Abrechnung/Backoffice, Urlaubsvertretung, Patient. Die Aktionen: Termin anlegen, Termin verschieben oder absagen, Patientendaten sehen, Dokumente hochladen, Dokumente freigeben, Nachricht schreiben, Nutzer anlegen, Daten exportieren, Protokoll einsehen.

Ein Ausschnitt, damit das Format klar wird:

Jedes „bedingt" braucht eine Regel in genau einem Satz. Lässt sich die Regel nicht in einem Satz sagen, ist sie noch nicht entschieden, sondern noch eine Diskussion.

Die Zelle, die in Praxen am zuverlässigsten offen bleibt, ist die Urlaubsvertretung: Darf die vertretende Kollegin Dokumente der abwesenden Kollegin sehen — ja, nein, oder nur im Zeitraum der Vertretung? Die dritte Antwort ist die realistische und zugleich die aufwändigste. Sie bedeutet zeitlich befristete Berechtigungen, also eine eigene Tabelle mit Gültigkeitszeitraum, eine Ablauflogik, die nachts sauber greift, und eine Anzeige in der Oberfläche, warum jemand gerade Zugriff hat. In meiner Kalkulation ist das der Unterschied zwischen vier und achtzehn Stunden im Rechtemodul.

Block 2: Termine sind kein Formular

Ein Terminmodul ist erst dann beschrieben, wenn zu jeder Terminart vier Werte feststehen: Dauer, wer sie ausführen darf, welcher Raum gebraucht wird, wie viele parallel laufen dürfen. Bei sieben Terminarten sind das 28 Angaben — die kleinste sinnvolle Fassung eines Regelwerks.

Rechnen Sie die Kombinationen einmal aus, bevor Sie ein Angebot einholen. Beispiel: Sieben Terminarten mal vier Behandelnde ergeben 28 mögliche Paarungen; in einer typischen Praxis sind davon etwa 19 zulässig, weil nicht jede Person jede Leistung erbringt. Genau diese Lücke von neun unzulässigen Kombinationen ist das Modul. Ein Buchungskalender, der alle 28 anbietet, produziert Termine, die der Empfang anschließend von Hand korrigiert — und dann nutzt ihn niemand mehr.

Dazu kommen Fälle, die in keinem Standardprodukt vorgesehen sind: Etwa Blutabnahme, die doppelt belegt werden darf; das Ultraschallgerät, das einen von zwei Räumen bindet; oder ein 30-Minuten-Puffer nach dem Hausbesuch. Solche Sätze schreibt niemand auf, weil sie am Tresen selbstverständlich sind. Deshalb kommt Block 2 nicht von der Praxisleitung, sondern von der Person, die den Kalender wirklich führt.

Block 3: Der Import, den niemand angeschaut hat

Exportieren Sie Ihren Bestand, bevor jemand ein Migrationskonzept schreibt. Ein Beispiel aus einer typischen Bestandsaufnahme: 4.100 Patientendatensätze, davon 380 mit identischem Namen und Geburtsdatum, 210 ohne E-Mail-Adresse und 90 Adressen, die mehrfach vergeben sind — Familien teilen sich ein Postfach.

Jede dieser drei Zahlen ist eine Entscheidung, kein Fehler: Zusammenführen, trennen oder außen vor lassen. Und die dritte Zahl kippt eine Annahme, die in fast jedem Login-Konzept steckt. Wenn Vater, Mutter und Kind dieselbe Adresse nutzen, ist „E-Mail gleich Konto" keine tragfähige Identität mehr; Sie brauchen entweder eine Kontoebene über den Personen oder eine zweite Kennung. Diese Entscheidung im Katalog kostet einen Absatz, dieselbe Entscheidung nach dem Go-live kostet eine Datenmigration.

„Datenschutz muss erfüllt sein" ist keine Anforderung

Der Satz steht in fast jedem Lastenheft und ist technisch wertlos, weil er nichts prüfbar macht. Prüfbar wird er erst durch sieben konkrete Festlegungen: In welchem Land steht der Server? Mit wem schließen Sie einen Auftragsverarbeitungsvertrag? Welche Datenfelder gehen überhaupt in die App? Welche Löschfrist gilt je Datenart? Wer darf exportieren? Was wird protokolliert, und wie lange bleibt das Protokoll? Für welche Rollen gilt ein zweiter Faktor beim Login?

Die rechtliche Bewertung dieser Punkte treffen Sie nicht mit dem Entwickler, sondern mit Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung. Meine Aufgabe ist, Ihre Festlegungen technisch umzusetzen und nachweisbar zu machen — nicht, sie für Sie zu entscheiden. Lassen Sie sich deshalb auch keine pauschalen Zusicherungen in ein Angebot schreiben; brauchbar sind Zeilen wie „Hosting in Frankfurt, Anbieter X, AVV liegt bei" und „Löschung von Upload-Dokumenten nach 90 Tagen, Job läuft täglich um 03:00".

Eine Regel, die Umfang und Risiko gleichzeitig senkt: Ein Datenfeld, das in der App keine Entscheidung auslöst, gehört nicht in die App. Diagnosen im Terminportal sind ein häufiger Kandidat zum Streichen — sie werden dort angezeigt, aber nirgends gebraucht.

Die Lastannahme: Nicht Skalierung, sondern 90 Minuten

Hier ein Rechenweg mit Beispielzahlen, den Sie mit Ihren eigenen Werten wiederholen können. Eine Gemeinschaftspraxis mit vier Behandelnden hat rund 180 Patientenkontakte am Tag. Realistisch nutzt ein Teil davon das Portal — nehmen wir 30 Prozent, also 54 Online-Vorgänge täglich. Verteilt über zehn Öffnungsstunden sind das 5,4 Vorgänge pro Stunde. Nur verteilen sie sich nicht: Erfahrungsgemäß fällt der größte Anteil in das Fenster, in dem sonst das Telefon dauerklingelt. Bei etwa 38 Prozent zwischen 07:30 und 09:00 sind das 21 Vorgänge in 90 Minuten, also 14 pro Stunde und ein Spitzenfaktor von 2,6 gegenüber dem Tagesmittel.

Vierzehn Schreibvorgänge pro Stunde trägt jede vernünftige Architektur auf der kleinsten Instanz. Die Anforderung lautet damit nicht „skalierbar", sondern: Im Fenster 07:30 bis 09:00 erreichbar, Antwortzeiten unter einer Sekunde bei rund 15 gleichzeitigen Sitzungen, und ein Limit auf dem einen Endpunkt, den jeder ohne Login erreicht. Denn das ist die eigentliche Lastfrage einer Praxis-App: Die öffentliche Terminanfrage ist offen im Netz und wird von Bots gefunden, lange bevor sie von Patienten gefunden wird. Ein Rate-Limit pro IP und eine einfache Missbrauchserkennung sind hier kein Luxus, sondern zwei Zeilen im Katalog.

Wächst die Praxis später zum MVZ mit mehreren Standorten, verschiebt sich diese Rechnung — dann lohnt der Blick auf die Punkte in Web-App-Skalierung: Technische und geschäftliche Anforderungen. Für eine Einzel- oder Gemeinschaftspraxis ist Skalierung dagegen typischerweise nicht das Problem, das den Preis treibt.

Was um 07:55 passiert, wenn nichts geht

Fragen Sie sich beim Schreiben des Katalogs einmal konkret: Wie lange darf das Portal am Vormittag weg sein, bevor jemand zum Telefon greifen muss? Wenn die Antwort „30 Minuten" lautet, brauchen Sie keine hochverfügbare Architektur, sondern ein Monitoring, das innerhalb von fünf Minuten eine echte Person erreicht, und eine statische Ersatzseite mit Telefonnummer und Öffnungszeiten, die unabhängig von der Anwendung ausgeliefert wird.

Dazu drei Sätze, die in Block 6 gehören und zusammen typischerweise weniger als einen Tag Aufwand kosten: Wer schaltet die Ersatzseite? In welcher Zeit? Und wo liegt die Tagesliste, wenn die App nicht erreichbar ist? Eine Praxis, die ihre Terminliste des Tages ausschließlich in der neuen App hat, hat sich ein Betriebsrisiko gebaut. Ein automatischer PDF-Export der Tagesliste um 06:00 in ein Praxis-Verzeichnis ist eine Anforderung von einem Satz — und der Unterschied zwischen einer unangenehmen Stunde und einem chaotischen Vormittag.

Nicht-Anforderungen: Die Liste, die den Preis rettet

Der Katalog braucht ein zweites, kürzeres Kapitel: Was bewusst draußen bleibt. Beispiele: Keine Videosprechstunde, keine Abrechnung, keine App im Store, keine zweite Sprache, kein Datenimport vor 2021, keine Anbindung an ein Labor.

Schreiben Sie zu jeder Nicht-Anforderung dazu, was passieren müsste, damit sie wieder hereinkommt. Aus „keine Videosprechstunde" wird so „Videosprechstunde erst, wenn mindestens zwei Behandelnde sie regelmäßig anbieten wollen; dann als eigener Change Request mit eigener Schätzung". Das ist der Unterschied zwischen einem Streichposten, über den in Monat drei erneut diskutiert wird, und einer Entscheidung mit Wiedervorlage.

Wenn Sie mit dem Katalog anschließend Angebote einholen, hilft die Struktur aus Web-App-Angebot einholen: Checkliste für Anfrage und Vergleich beim Vergleich — vor allem, um zu erkennen, welcher Anbieter die Nicht-Anforderungen stillschweigend wieder eingerechnet hat.

Reifegrad-Test: Ab wann ein Festpreis trägt

Zählen Sie einen Punkt pro beantworteter Frage. „Klären wir später" zählt null. „Das hat mein Vorgänger eingerichtet" zählt ebenfalls null, solange niemand nachgesehen hat.

• 38 bis 46 Punkte: Ein Festpreis über den Gesamtumfang ist sinnvoll und für beide Seiten fair.
• 28 bis 37 Punkte: Festpreis nur über die geklärten Blöcke, dazu eine bezahlte Konzeptphase für den Rest. Wer hier trotzdem einen Gesamtfestpreis anbietet, hat entweder einen Risikoaufschlag eingerechnet, den Sie nicht sehen, oder plant Nachträge ein.
• Unter 28 Punkten: Kein Angebot, sondern zwei Tage Prozessaufnahme in der Praxis. Vormittags mitlaufen, nachmittags aufschreiben.

Eine wichtige Einschränkung zum Punktestand: Block 4 ist ein K.-o.-Kriterium. Ein Katalog mit 40 Punkten, in dem alle fünf Schnittstellenfragen fehlen, ist nicht angebotsreif. Ob es eine dokumentierte Schnittstelle zu Ihrem Praxissystem gibt, was sie kostet, wer sie freischaltet, welche Felder sie liefert und in welche Richtung sie schreibt — diese fünf Antworten holen Sie schriftlich beim Hersteller oder Systemhaus ein, bevor irgendjemand eine Zahl nennt. Eine mündliche Zusage am Telefon hat in dieser Frage keinen Wert.

Fünf Signale, dass der Katalog noch nicht trägt

1. Es stehen Screens darin, keine Regeln. Wenn im gesamten Dokument kein einziger Satz mit „Wenn … dann …" beginnt, beschreibt es eine Oberfläche und kein System.
2. Nur die Leitung war beteiligt. Der Kalender und der Tresen kennen Regeln, die in keiner Leitungsrunde vorkommen.
3. Es kommt keine Zahl vor. Keine Dauer, keine Frist, keine Menge, keine Uhrzeit — dann sind alle Anforderungen Meinungen.
4. Die Altdaten wurden nie exportiert. Über Datenqualität lässt sich nicht diskutieren, sie lässt sich nur ansehen.
5. Zu keiner Funktion steht ein Abnahmekriterium. „Fertig" muss ein Satz sein, den zwei Personen unabhängig voneinander gleich beurteilen.

Das erste Signal ist der zuverlässigste Frühindikator. Regeln entstehen im Kopf von jemandem, der den Betrieb kennt; Screens entstehen im Kopf von jemandem, der eine andere App gesehen hat.

Häufige Fragen

Wie entwickle ich eine Web-App für meine Praxis, wenn ich selbst nicht technisch bin? Sie liefern Regeln, nicht Architektur. Alle 46 Fragen oben lassen sich ohne IT-Kenntnisse beantworten — sie handeln von Ihrem Betrieb. Technologieentscheidungen wie Datenbank, Framework oder Hosting-Modell gehören auf die Gegenseite und sollten Ihnen mit Begründung und Alternative vorgelegt werden, nicht als gesetzt.

Reicht eine Web-App, oder braucht die Praxis eine native App? Entscheidungsregel: Brauchen Sie Zugriff auf Gerätefunktionen oder Offline-Betrieb auf dem Gerät des Patienten? Wenn nein, ist eine Web-App der kürzere Weg, weil Store-Freigaben und zwei Codebasen entfallen. Bei Benachrichtigungen lohnt ein Blick auf die tatsächlichen Zielgeräte Ihrer Patienten, denn welche Wege dort funktionieren, hängt von Plattform und Version ab — das prüfen Sie am besten an zwei, drei realen Geräten aus dem Team, bevor Sie es als Anforderung festschreiben.

Wie lange dauert es, so einen Katalog zu erstellen? In meinen Projekten sind das zwei Termine à 90 Minuten plus etwa vier Stunden Nacharbeit auf Praxisseite, verteilt über zwei bis drei Wochen. Der Zeitraum ist länger als der Aufwand, weil zwischendurch jemand beim Systemhaus antworten muss.

Kann eine Praxis das mit einem Baukasten oder No-Code selbst lösen? Sehen Sie sich Ihre Antworten in Block 3 und 4 an. Lauten sie „kein Altdatenimport, keine Schnittstelle", ist ein Standardprodukt oder Baukasten meist der günstigere Weg, und der Katalog dient dann als Auswahlraster. Sobald eine echte Schnittstelle ins Spiel kommt oder das Rechtemodell mehr als drei Rollen kennt, kippt die Rechnung — dort endet der Baukasten typischerweise bei einer Einschränkung, die sich nicht umgehen lässt.

Der Schritt, der nichts kostet

Exportieren Sie zwei Listen: Ihre Terminarten mit Dauer und Zuständigkeit, und Ihren Patientenbestand mit Name, Geburtsdatum und E-Mail. Setzen Sie sich mit der Person zusammen, die den Kalender führt, und gehen Sie die 54 Zellen der Rollenmatrix durch. Das sind zusammen etwa zwei Stunden.

Wenn danach noch ein Dutzend Fragen offen sind, ist das kein Rückschlag. Es ist der günstigste Zeitpunkt, an dem sie auffallen können.

Die Datenschutz-Hinweise in diesem Artikel sind eine technische Einordnung und ersetzen keine Rechtsberatung.