Der Abend nach dem Besuch in der Praxis war einer von diesen Abenden, an denen man eigentlich nichts mehr tun will. Ich saß zu Hause, vor mir ein Notizbuch, in dem ich am Vormittag Strichlisten geführt hatte. Wie oft hat Mala nach einer Karteikarte gesucht? Wie oft hat sie dieselbe Telefonnummer abgeschrieben? Wie oft musste eine Ärztin einen Satz auf dem Rezept zweimal schreiben, weil der erste Zettel in der Apotheke nicht lesbar war?
Ich bin mit Zahlen vorsichtig, wenn ich sie nicht sauber gemessen habe, und diese hier habe ich nicht sauber gemessen. Es waren drei Stunden Beobachtung, ein Bleistift und mein Bauchgefühl. Aber das Bauchgefühl war eindeutig. Über den Tag verteilt gingen in dieser kleinen Praxis mehrere Stunden in Arbeiten, die ein Computer in Sekunden erledigt: suchen, abschreiben, abgleichen, neu schreiben. Mehrere Stunden, an jedem Tag, bezahlt von jemandem, der eigentlich für etwas anderes da ist.
Warum nicht einfach etwas kaufen
Das war meine erste Reaktion, und sie ist die richtige. Ich habe in zwanzig Jahren gelernt, dass Software selbst zu bauen fast immer die teuerste Antwort auf ein Problem ist. Also habe ich geschaut, was es gibt. Die Welt der Praxissoftware lässt sich grob in drei Sorten einteilen, jedenfalls wie ich sie damals erlebt habe.
Die erste Sorte ist zu groß. Das sind Systeme für Kliniken mit eigener IT-Abteilung, mit Schulungen, mit Einführungsprojekten über Monate. Für drei Ärzte und eine Empfangskraft ist das, als würde man einen Lastwagen kaufen, um Brötchen zu holen.
Die zweite Sorte ist zu alt. Programme, die irgendwann einmal gut waren, deren Oberfläche aber so aussieht, als hätte sie seit fünfzehn Jahren niemand angefasst, und bei denen man sich fragt, wer sie eigentlich noch pflegt.
Die dritte Sorte ist gut, aber aus einer anderen Welt. Die modernen Cloud-Produkte sind meistens hervorragend, aber sie sind für einen Markt gebaut, der nicht der von dieser Praxis ist: andere Währung, andere Steuerformate, anderes Internet. Ich habe das ausführlich in meinem Vergleich mit Cliniko beschrieben, deshalb will ich es hier nicht wiederholen. Nur so viel: Ich habe diese Produkte nicht abgelehnt, weil sie schlecht sind. Ich habe sie abgelehnt, weil sie für andere Räume gemacht wurden.
Die Regel, die ich mir gegeben habe
Bevor ich die erste Zeile Code schrieb, habe ich mir eine Regel aufgeschrieben: Ich baue nur, was in dieser Praxis jeden Tag benutzt wird. Nichts, was nur gut aussieht. Nichts, was ich nur baue, weil ich es kann.
Das klingt selbstverständlich. In Wirklichkeit ist es die schwerste Disziplin, die ich kenne, weil man als Entwickler ständig auf Ideen kommt. Ein Dashboard mit hübschen Diagrammen. Eine Erinnerungsfunktion. Eine Statistik. Ich habe alle diese Ideen auf eine Liste gesetzt, die ich “später” genannt habe, und sie nicht angerührt, bis die täglichen Dinge liefen.
Die täglichen Dinge waren, nach meiner Strichliste, fünf.
Was ich zuerst gebaut habe
Der Patient. Ein Formular mit dem, was Mala am Telefon ohnehin erfragt: Name, Geburtsdatum, Geschlecht, Telefonnummer, Adresse. Dazu Dinge, die eine Ärztin im Gespräch wissen will, bevor sie etwas verschreibt: Blutgruppe, Allergien, Vorerkrankungen. Ich habe lange überlegt, ob ich Allergien als eigenes Feld oder als Teil der Vorgeschichte führen soll. Ich habe mich für ein eigenes Feld entschieden, weil ich nicht wollte, dass es zwischen zwanzig Zeilen Text verschwindet.
Der Termin. Ein Termin gehört zu einem Patienten und einem Arzt, hat ein Datum, eine Uhrzeit, eine Art (zum Beispiel Konsultation oder Kontrolle) und einen Status. Auf der Startseite steht die Liste der Termine des Tages. Es klingt banal, aber genau diese Liste hat Mala früher jeden Morgen aus dem Buch abgeschrieben.
Die Konsultation. Das ist der Kern. Die Ärztin trägt ein, was die Patientin hat, welche Beschwerden und Symptome vorliegen, was sie diagnostiziert, was sie verschreibt, ob sie Laboruntersuchungen empfiehlt und wann die Patientin wiederkommen soll. Alles hängt an dem Termin und an der Patientin.
Das Labor. Eine Anforderung für eine Untersuchung, ein Status, ein Ergebnis. Mehr nicht. Aber es ersetzt den Stapel Fotos, die auf dem Messenger der Praxis ankamen.
Die Rechnung. Eine Rechnung hat Posten für Konsultation, Medikamente, Labor und Sonstiges, einen Rabatt, einen Gesamtbetrag, den bezahlten Betrag, die Zahlungsart und einen Status. Dazu kommt eine einfache Apothekenliste mit Bestand, Mindestbestand und Verfallsdatum, weil die Praxis ein paar Medikamente selbst abgibt.
Das ist alles. Keine Wunder, aber es ist das, was an einem normalen Tag tatsächlich passiert.
Warum ein Desktop-Programm
Die Frage, die mir jeder Entwickler stellt: Warum keine Web-App? Das wäre heute der selbstverständliche Weg. Die Antwort hat mit der Praxis zu tun, nicht mit mir.
Eine Web-App braucht einen Server und eine Internetverbindung. Wer den Server betreibt, muss ihn pflegen, sichern, aktualisieren. Eine kleine Praxis hat dafür niemanden. Wer ihn mietet, gibt Patientendaten aus der Hand, und genau das wollte die Ärztin nicht. Und wenn das Internet ausfällt, steht alles still.
Also habe ich ein Windows-Programm gebaut, das ohne Internet läuft. Die Daten liegen in einer einzigen SQLite-Datei auf dem Praxisrechner. Intern ist es VB.NET, und die Oberfläche ist eine Webansicht im Windows-Fenster, weil ich damit schneller ein sauberes Aussehen hinbekomme. Für die Praxis bedeutet das nur: Programm öffnen, arbeiten, Datei sichern.
Das hat einen Preis, und ich will ihn nicht verschweigen. Ein lokales Programm bedeutet, dass die Praxis selbst für die Sicherung verantwortlich ist. Mehrere Rechner, die gleichzeitig dieselben Daten benutzen, sind schwieriger als bei einer Cloud-Lösung. Und Updates muss jemand einspielen. Ich habe diese Nachteile gegen den Vorteil abgewogen, dass die Praxis auch dann weiterarbeiten kann, wenn der Strom flackert und das Netz weg ist, und mich für das Desktop-Programm entschieden. Für eine andere Praxis kann die Rechnung anders ausgehen.
Was mich überrascht hat
Ich dachte, die größten Herausforderungen wären technischer Natur. Das waren sie kaum. Die größten Überraschungen kamen von Mala und der Ärztin.
Mala wollte, dass beim Anlegen eines Termins sofort sichtbar ist, ob die Patientin schon einmal da war. Ich hatte das nicht vorgesehen. Es war ein kleiner Wunsch, aber er hat mir gezeigt, worauf jemand achtet, der den Hörer zwischen Schulter und Ohr klemmt. Ich habe ihn auf die Liste gesetzt.
Die Ärztin wollte das Wiedervorstellungsdatum direkt in der Konsultation setzen, nicht in einem eigenen Terminfenster. Sie sagte: “Wenn ich es dort hinschreibe, wo ich sowieso schreibe, vergesse ich es nicht.” Seitdem gibt es dafür ein Feld in der Konsultation.
Was mich am meisten beeindruckt hat: Beide haben mir kaum je gesagt, was ihnen gefällt. Sie haben mir gesagt, was im Weg ist. Das ist das wertvollere Feedback, und ich habe gelernt, auf Seufzer zu achten, nicht auf Komplimente.
Die Wochen, in denen ich zweifelte
Es gab eine Phase, etwa nach dem ersten Monat, in der ich ernsthaft überlegt habe, das Ganze wieder einzustampfen. Nicht, weil es technisch nicht ging. Sondern weil ich mir die ehrlichste aller Fragen gestellt habe: Wer braucht eigentlich noch eine weitere Praxissoftware?
Es gibt Dutzende. Manche sind sehr gut. Ich hatte zwei Wochen lang das Gefühl, ein Rad neu zu erfinden, das schon längst rund ist. Abends saß ich da, die Codezeilen vor mir, und dachte: Du hättest der Ärztin einfach ein Abonnement empfehlen können, und die Sache wäre erledigt.
Was mich am Ende bei der Stange gehalten hat, war kein großes Ziel, sondern eine kleine, ziemlich unromantische Beobachtung. Jedes Mal, wenn ich in der Praxis vorbeischaute, lag das Terminbuch noch auf dem Tisch, aber Mala schaute immer häufiger zuerst auf den Bildschirm. Nicht weil ich sie dazu gedrängt hätte, sondern weil die Liste dort schneller war. Das ist ein Satz, den ich mir gemerkt habe: Niemand wechselt wegen eines guten Arguments, die Menschen wechseln, weil etwas einfacher ist.
Was ich bewusst nicht gebaut habe
Eine Liste dessen, was nicht drin ist, sagt mehr über ein Produkt als eine Liste dessen, was drin ist. Hier ist meine.
Ich habe keine Künstliche Intelligenz eingebaut, die Diagnosen vorschlägt. Das wird oft verlangt, und ich halte es für eine schlechte Idee in einem Programm, das ein einzelner Entwickler allein baut und nicht klinisch prüfen kann. Ein Fehler wäre dort kein Schönheitsfehler.
Ich habe keine Arzneimitteldatenbank mit Wechselwirkungsprüfung eingebaut. Der Rezepttext in der Konsultation ist ein Textfeld. Die Ärztin schreibt, was sie verschreibt. Das Programm denkt dabei nicht mit, und ich will das nicht anders darstellen. Eine geprüfte Arzneimitteldatenbank ist ein Projekt von mehreren Jahren mit Fachleuten, nicht etwas, das man nebenbei einbaut.
Ich habe keine Benutzerkonten mit Rollen und Rechten in dem Sinn gebaut, wie es große Systeme haben. Für drei Ärzte und eine Empfangskraft, die sich kennen, war das nicht das dringendste Problem. Für eine größere Praxis wäre es eines, und dann müsste ich es nachziehen.
Und ich habe keine Anbindung an Krankenkassen oder Versicherungen gebaut. In dieser Praxis zahlen die meisten Patienten selbst, und jede Anbindung wäre ein eigenes Land mit eigenen Regeln.
Ein Vormittag mit dem Programm
Stell dir vor, es ist halb neun. Mala schaltet den Rechner ein und öffnet das Programm. Auf der Startseite stehen die Termine des Tages, nach Uhrzeit sortiert. Der Erste ist ein Kontrolltermin, der Zweite ein neuer Patient.
Der neue Patient kommt herein. Mala legt ihn an: Name, Geburtsdatum, Telefonnummer, ein Satz zu Allergien, die er auf Nachfrage nennt. Das dauert eine Minute. Die Ärztin öffnet den Termin, trägt die Beschwerden ein, schreibt die Diagnose, tippt das Rezept und setzt das Datum für die Kontrolle. Falls sie eine Blutuntersuchung möchte, legt sie eine Laboranforderung an.
Am Ende sitzt der Patient wieder bei Mala. Sie stellt die Rechnung aus: Konsultation, Medikamente, Labor, eventuell ein Rabatt, Bezahlung bar oder anders. Fertig.
Nichts davon ist spektakulär, und das ist der Punkt. Als Entwickler wünscht man sich manchmal, dass jemand “Wow” sagt. Hier wäre das ein schlechtes Zeichen. Wenn die Software gut ist, sagt niemand etwas. Sie ist einfach da, und der Vormittag geht schneller vorbei.
Was das Ganze mich gekostet hat
Ich will ehrlich sein, was Zeit und Aufwand betrifft, weil ich glaube, dass viele Entwickler hier schönreden.
Ein Programm wie dieses ist keine Sache von ein paar Wochenenden. Die erste Version, die man vorzeigen kann, ist in wenigen Tagen da. Die Version, auf die sich jemand im Alltag verlässt, braucht Monate, und sie braucht vor allem die Geduld, immer wieder in die Praxis zu gehen, zuzusehen und Dinge wegzuwerfen, die man für klug hielt. Ich habe mehr Zeit mit Zuschauen verbracht als mit Programmieren, und ich würde es wieder so machen.
Außerdem trägt man Verantwortung. Wenn eine Praxis ihre Termine und Akten einem Programm anvertraut, ist ein Fehler dort kein Spiel mehr. Ich habe deshalb gelernt, vorsichtig zu sein mit Versprechen, und ich habe mir angewöhnt, in jedem Text wie diesem zu sagen, was nicht geht.
Was noch fehlt, und warum ich es nicht verstecke
ClinicPlusPlus ist nicht fertig. Das schreibe ich nicht aus Bescheidenheit, sondern weil es stimmt.
Einige Bildschirme sind noch Prototypen. Die Startseite und die Berichte hängen noch nicht überall an den echten Daten. Es gibt keine automatische Sicherung, nur das manuelle Kopieren der Datei. Eine steuerkonforme Rechnung für Indien, mit GST, steht auf meiner Liste und ist noch nicht gebaut. Patienten können nicht online buchen, und es gibt keine Erinnerungen per SMS. Auch einen automatischen Schutz gegen doppelt vergebene Termine gibt es noch nicht, darüber schreibe ich in einem eigenen Beitrag.
Wer eine fertige Lösung braucht, sollte nicht auf mein Programm warten, sondern sich bei den ausgereiften Produkten umsehen. Ich meine das ernst.
Was ich daraus mitnehme
Wenn ich zurückblicke, war der wichtigste Satz dieser ganzen Geschichte nicht technisch. Es war die Frage, die ich mir an dem Abend mit dem Notizbuch gestellt habe: Löse ich ein Problem, das jemand wirklich hat, oder baue ich etwas, weil ich es kann?
Ich weiß nicht, ob ClinicPlusPlus am Ende ein großes Produkt wird. Ich weiß, dass es mit einem Problem begann, das ich mit eigenen Augen gesehen habe, und dass jede Funktion, die drin ist, dort hineingekommen ist, weil jemand sie täglich braucht. Das ist ein guter Anfang, auch wenn es kein Ende ist.
Wenn du eine Praxis führst und dich in einem Teil dieser Geschichte wiedererkennst, schreib mir. Mich interessiert weniger, ob dir das Programm gefällt, als was bei dir im Weg ist.
Dieser Beitrag beschreibt den Entwicklungsstand zum Zeitpunkt der Veröffentlichung.