Ein Morgen auf Station
Es gibt kaum noch einen klinischen Arbeitstag ohne Software. Wir melden uns am KIS an, suchen Laborwerte, schreiben Anordnungen, erstellen Medikationspläne, dokumentieren Aufklärungsgespräche, kommunizieren über (hoffentlich) sichere Messenger, beantworten digitale Patientenanfragen, arbeiten mit PDMS, PACS, ePA, TI, KIM, DiGA, Terminlogik, Abrechnungssystemen, Qualitätsindikatoren und zunehmend auch mit KI-Funktionen.
Und trotzdem behandeln viele Ärztinnen und Ärzte Software noch so, als sei sie eine Art Naturereignis: Sie ist da, sie funktioniert manchmal, sie stört oft, sie wird von anderen gebaut, und wenn sie schlecht ist, muss man eben damit leben.
Das ist ein Problem.
Nicht, weil jede Ärztin und jeder Arzt professionell programmieren können muss. Aber wir sollten verstehen, was Software ist, wie sie entsteht, welche Entscheidungen in ihr stecken und warum sie sich nicht durch einen Satz wie “das müsste doch einfach gehen” verändern lässt.
Denn Software ist nicht nur ein Werkzeug, das neben der Medizin steht. Software strukturiert inzwischen, wie Medizin praktisch abläuft.
Software ist Teil unserer Arbeitsumgebung
Früher konnte man viele klinische Abläufe noch relativ direkt sehen. Eine Papierkurve lag am Bett. Eine Patientenliste wurde ausgedruckt. Aufgaben wurden aufgeschrieben, übergeben, abgehakt oder vergessen. Das war fehleranfällig, aber sichtbar.
Heute verschwinden viele dieser Abläufe in Systemen. Eine Aufgabe existiert als Statusfeld. Eine Dringlichkeit als Dropdown. Eine Anordnung als Datenbankeintrag. Eine Kommunikation als Nachricht in einem System, das nicht mit dem nächsten System spricht. Eine Leitlinie als PDF im Intranet. Eine Pflegeinformation als Freitext. Eine Abrechnungslogik als Kodierregel. Eine Eskalation als Alarm, der irgendwann ignoriert wird, weil zu viele davon von allen Seiten eintreffen.
Wenn wir diese Systeme nicht verstehen, verstehen wir einen wachsenden Teil unserer eigenen Arbeitsrealität nicht mehr.
Wir erleben dann nur noch die Oberfläche: langsame Masken, unlogische Pflichtfelder, schlechte Übergaben, Medienbrüche, doppelte Dokumentation, nicht auffindbare Informationen. Dahinter stehen aber konkrete technische und organisatorische Entscheidungen: Datenmodelle, Rollen- und Rechtekonzepte, Schnittstellen, Deployments, regulatorische Anforderungen, Haftungsfragen, Beschaffungsprozesse, Priorisierungen und manchmal schlicht fehlende klinische Rückkopplung.
Wer das nicht einordnen kann, bleibt beim Ärger stehen. Wer es einordnen kann, kann präziser kritisieren, bessere Anforderungen formulieren und an Lösungen beteiligt werden. Gerade letzteres ist mir wichtig: Ohne Verständnis von den Systemen bleiben wir als Ärzt:innen immer außen vor und können nicht sinvoll in die Entwicklung neuer Lösungen einbezogen werden.
Was ich mit “coden lernen” meine
Mit “coden lernen” meine ich nicht, dass Ärztinnen und Ärzte nach Dienstschluss alle zu Softwareentwicklern werden sollen. Es geht nicht darum, dass Oberärztinnen React-Komponenten bauen oder Assistenzärzte Kubernetes-Cluster administrieren.
Es geht um eine Basiskompetenz.
Ärztinnen und Ärzte sollten verstehen, dass Software aus Daten, Regeln, Schnittstellen und Zuständen besteht. Sie sollten eine einfache Logik lesen können. Sie sollten wissen, warum strukturierte Daten anders nutzbar sind als Freitext. Sie sollten verstehen, was eine API ist, warum Systeme nicht automatisch miteinander reden, was ein Deployment bedeutet und warum eine Änderung in einem integralen System ihres Krankenhauses nicht einfach am nächsten Morgen live geht.
Sie sollten grob wissen, was Versionskontrolle ist (wer in der Wissenschaft arbeiten will vielleicht auch etwas weniger grob - I mean seriously guys….Word Files per eMail verschicken?…), warum Tests wichtig sind, warum Sicherheit kein Add-on ist, was ein Berechtigungskonzept leisten muss, weshalb Interoperabilität mehr ist als ein Export-Button oder ein PDF-Import und warum medizinische Software in bestimmten Kontexten regulatorisch anders behandelt werden muss als eine normale App.
Das ist keine Spezialausbildung. Das ist im digitalen Gesundheitswesen berufliche Allgemeinbildung.
So wie wir nicht alle Epidemiolog:innen werden müssen, aber Studiendesigns verstehen sollten. So wie wir nicht alle Jurist:innen werden müssen, aber Einwilligung, Aufklärung und Schweigepflicht und die Konsequenzen deren nicht-Befolgung verstehen müssen. So wie wir nicht alle Medizintechniker werden müssen, aber wissen sollten, was ein Monitor misst und wo seine Grenzen liegen.
Bei Software erlauben wir uns noch zu oft eine Unschärfe, die wir in anderen Bereichen unseres Berufs nicht akzeptieren würden.
Warum das gerade für Ärztinnen und Ärzte wichtig ist
Medizinische Arbeit ist schwer von außen zu verstehen. Nicht, weil Ärztinnen und Ärzte grundsätzlich klüger wären als andere Berufsgruppen, sondern weil die Realität der Versorgung dicht, kontextabhängig und voller impliziter Prioritäten ist.
Was auf dem Papier wie ein einfacher Prozess aussieht, ist auf Station oft ein Geflecht aus Verantwortung, Unsicherheit, Zeitdruck, Erfahrungswissen, Teamkommunikation, Angehörigengesprächen, Verfügbarkeit von Betten, Pflegekapazität, Laborlaufzeiten, OP-Plan, Konsilen, Leitlinien, lokalen SOPs und dem Zustand eines konkreten Patienten um 03:17 Uhr.
Wenn Menschen Software für diese Umgebung bauen, ohne diese Realität ausreichend zu kennen, entstehen Werkzeuge, die formal korrekt und praktisch unbrauchbar sein können.
Das ist kein Vorwurf an Entwicklerinnen, Produktmanager oder Krankenhaus-IT. Gute Software entsteht immer an der Schnittstelle zwischen Fachlichkeit und Technik. Aber diese Schnittstelle funktioniert nur, wenn beide Seiten übersetzen können.
Wir Ärztinnen und Ärzte müssen deshalb nicht die Rolle der IT übernehmen. Wir müssen aber besser darin werden, unsere klinische Wirklichkeit in Anforderungen, Datenflüsse, Risiken und Prioritäten zu übersetzen. Dafür braucht es Softwareverständnis.
Ein Beispiel: “Wir brauchen eine bessere Übergabe” ist als Satz richtig, aber technisch zu ungenau. Besser ist: Welche Informationen müssen bei jeder Übergabe strukturiert vorliegen? Welche dürfen Freitext bleiben? Wer darf sie ändern? Welche Aufgaben müssen offen sichtbar sein? Was passiert mit erledigten Aufgaben? Welche Patienten sind für welches Team relevant? Welche Informationen müssen historisiert werden? Was muss exportierbar sein? Welche Fehler wären patientengefährdend? Welche Warnungen würden im Alltag ignoriert?
Das hat noch nichts mit Programmieren im engeren Sinne zu tun. Aber die Formulierung dieser Fragen ist die gedankliche Grundlage dafür, dass gute Software entstehen kann.
Die Ausbildung bildet diese Realität noch nicht ausreichend ab
In Deutschland wird das Medizinstudium stark durch Prüfungs- und Zulassungslogiken geprägt. Das IMPP beschreibt selbst, dass Gegenstandskataloge die Prüfungsgegenstände der Prüfungs- und Approbationsordnungen explizit machen und Orientierung für Prüfungsteilnehmende und Prüfende geben. Gleichzeitig ergibt sich der eigentliche Prüfungsstoff aus den Prüfungs- und Approbationsordnungen.
Das ist nachvollziehbar. Ein Staatsexamen braucht Standards. Patientensicherheit braucht Mindestkompetenzen. Niemand will ein Medizinstudium, das jeder Fakultät völlig beliebig überlassen bleibt.
Aber genau hier liegt das Strukturproblem: Wenn eine neue Kompetenz nicht prüfungsrelevant, nicht longitudinal verankert und nicht klar verantwortlich zugeordnet ist, bleibt sie im Curriculum oft randständig. Und die digitale Landschaft verändert sich schneller als die regulatorischen Zyklen der ärztlichen Ausbildung.
Der Masterplan Medizinstudium 2020 wurde 2017 als wichtiger Schritt zu einem moderneren Medizinstudium beschlossen. Im Februar 2026 schreiben MFT und AWMF allerdings, dass der Reformprozess der ärztlichen Ausbildung seit mehreren Jahren stockt, unter anderem wegen ungeklärter Finanzierungsfragen zwischen Bund und Ländern. Gleichzeitig empfehlen sie, vorhandene Spielräume der geltenden Approbationsordnung stärker zu nutzen.
Das zeigt ziemlich gut, wie langsam sich das System bewegt.
Natürlich gibt es Fortschritte. Die Weiterentwicklung der Gegenstandskataloge und einzelne Fakultätsinitiativen nehmen Digitalisierung zunehmend ernst. In Mainz wurde bereits 2017 das Wahlpflichtfach “Medizin im digitalen Zeitalter” implementiert. Halle bietet seit dem Wintersemester 2020/2021 verpflichtende Lehre zu “Digitalisierung in der Medizin” an, unter anderem zu KI, ePA, Telemedizin, DiGA, Extended Reality und 3D-Druck. Andere Universitäten bieten ähnliche Programme.
Das sind wichtige Beispiele. Aber sie lösen das Grundproblem noch nicht flächendeckend.
Digitale Lehre in der Medizin bedeutet häufig: medizinische Informatik, Klassifikationen (ICD, OPS, DRG), Datenschutz oder Telemedizin. Das ist wichtig. Aber es ist nicht dasselbe wie Softwarekompetenz.
Wer ICD und OPS kennt, versteht noch nicht, wie ein Produkt entsteht. Wer FHIR schon einmal gehört hat, versteht noch nicht automatisch Schnittstellenarchitektur. Wer eine KI-Vorlesung gehört hat, kann noch nicht beurteilen, ob ein klinisches KI-Feature sinnvoll in einen Workflow eingebettet ist. Wer Datenschutzregeln kennt, versteht noch nicht, wie Rollen, Rechte, Logging, Deployment und Betrieb zusammenhängen.
Wir brauchen deshalb eine andere Schicht von Ausbildung: nicht nur digitale Medizin als Thema, sondern Software als Arbeitsrealität.
Nach der Approbation wird es nicht einfacher
Nach dem Studium verschwindet das Problem nicht. Es wird eher größer.
In der Weiterbildung zählt zuerst, was für den Facharzt gebraucht wird. Dienste, Rotationen, Kataloge, OP-Zahlen, Dienste, Forschung, Familie, Schlaf. In dieser Realität ist es unrealistisch zu erwarten, dass breite Softwarekompetenz einfach nebenbei entsteht.
Wer sich weiterbilden will, muss oft selbst zahlen, Freizeit investieren oder Urlaub nehmen. Gute Zusatzkurse existieren, aber sie sind meist teuer und zeitlich schwer unterzubringen. Ein aktueller IHK-Kurs zur Medizininformatikerin beziehungsweise zum Medizininformatiker kostet beispielsweise 3.950 Euro und läuft über mehrere volle Kurstage. Das kann sinnvoll sein, ist aber keine niedrigschwellige Basisausbildung für eine ganze Berufsgruppe. Einige Fachgesellschaften versuchen mit noch höherem Aufwand eine Zusatzbezeichnung Medizinische Informatik zu etablieren. Mit ausbleibendem Erfolg. Insbesondere weil es hier anders als bei anderen Zusatzbezeichnungen wie der Notfallmedizin oder der Schmerztherapie keinerlei finanziellen Anreiz gibt. Wer seine Zusatzbezeichnung Notfallmedizin hat kann im Rettungsdienst tätig sein und erschließt sich eine tolle neue Einsatzmöglichkeit mit attraktivem Verdienst. Aber jetzt mal ehrlich - was bringt mir aktuell eine Zusatzbezeichnung Medizinische Informatik wie sie von manchen Fachgesellschaften in Kursen bereitz angeboten wird?
Das Ergebnis ist vorhersehbar: Es bilden sich vor allem diejenigen weiter, die ohnehin schon ein starkes Interesse an Digitalisierung, Informatik oder Healthtech haben. Genau diese Menschen brauchen wir, aber sie reichen nicht.
Wenn digitale Kompetenz nur ein Hobby der Interessierten bleibt, erreicht sie nicht die Breite der Versorgung. Dann verstehen vor allem einige wenige Enthusiasten, wie Software die Klinik verändert, während viele Entscheidungsträgerinnen und Entscheidungsträger auf Oberarzt-, Chefarzt- oder Geschäftsführungsebene weiterhin vor allem aus Beschaffungspräsentationen, Vendor-Demos und Bauchgefühl heraus entscheiden müssen.
Das ist zu wenig.
Gerade ärztliche Führung braucht mehr technisches Grundverständnis. Nicht, um selbst Code zu schreiben, sondern um bessere Fragen zu stellen: Welche Daten entstehen hier? Wem gehören sie? Welche Schnittstellen gibt es? Wie wird das System betrieben? Welche Ausfälle sind kritisch? Welche Änderungen sind möglich? Welche Abhängigkeiten entstehen? Welche regulatorische Rolle nimmt das Produkt ein?
Die häufigsten Einwände
Der erste Einwand lautet: Dafür haben wir keine Zeit.
Das stimmt. Ärztliche Ausbildung ist bereits überladen. Aber genau deshalb sollten wir nicht so tun, als sei Softwarekompetenz ein nettes Zusatzthema. Wenn digitale Systeme jeden Tag klinische Entscheidungen vorbereiten, Arbeitsabläufe priorisieren, Informationen sichtbar oder unsichtbar machen und Kommunikation strukturieren, dann ist ihr Verständnis kein Freizeitprojekt. Dann gehört es in die Ausbildung.
Der zweite Einwand lautet: Dafür gibt es doch IT.
Auch das stimmt, aber nur teilweise. Es gibt auch Juristinnen, trotzdem müssen wir Aufklärung verstehen. Es gibt Statistiker, trotzdem müssen wir Studien lesen. Es gibt Medizintechnik, trotzdem müssen wir Geräte sicher anwenden. IT kann Systeme betreiben, absichern und entwickeln. Aber IT kann nicht allein definieren, was klinisch sinnvoll, sicher und alltagstauglich ist. Diese Verantwortung können wir nicht vollständig delegieren.
Der dritte Einwand lautet: Ärztinnen und Ärzte sollen Medizin machen.
Genau deshalb sollten sie Software verstehen. Denn Medizin findet heute nicht außerhalb digitaler Systeme statt. Eine schlechte Aufgabenlogik kann Patientensicherheit gefährden. Eine schlechte Datenstruktur kann Qualitätssicherung verhindern. Eine schlechte Schnittstelle kann Entlassungen verzögern. Eine schlechte Benutzeroberfläche kann kognitive Last erhöhen. Ein schlecht integriertes KI-Feature kann Vertrauen erzeugen, wo Skepsis nötig wäre.
Softwarekompetenz entfernt uns nicht von der Medizin. Sie hilft uns, die Bedingungen zu gestalten, unter denen Medizin stattfindet.
Was wir konkret lehren sollten
Wir brauchen keine Pflichtveranstaltung, in der alle Studierenden am Ende eine App veröffentlichen. Wir brauchen ein realistisches Grundcurriculum.
Medizinstudierende sollten einmal selbst einfache Programme schreiben, nicht um produktive Software zu bauen, sondern um zu verstehen, wie explizit ein Computer denkt. Sie sollten mit Tabellen, einfachen Datenbanken und kleinen Skripten arbeiten. Sie sollten sehen, wie aus Freitext strukturierte Daten werden und was dabei verloren geht. Sie sollten einen einfachen API-Aufruf verstehen. Sie sollten lernen, was Tests leisten und warum Fehler in Software erwartbare Systemrisiken sind.
Sie sollten Anforderungen an klinische Software formulieren lernen. Sie sollten an Beispielen diskutieren, wann eine Anwendung ein Medizinprodukt sein kann, was Datenschutz praktisch bedeutet und warum Deployment im Krankenhaus immer auch Betrieb, Schulung, Rechte, Support, Haftung und Change Management umfasst.
In der Weiterbildung sollten diese Themen wieder auftauchen, angepasst an Verantwortung. Assistenzärztinnen und Assistenzärzte brauchen Grundlagen für den Alltag. Fachärztinnen und Fachärzte brauchen Verständnis für Prozessgestaltung. Leitende Ärztinnen und Ärzte brauchen Kompetenzen für Beschaffung, Governance, Risikobewertung und Produktentscheidungen.
Das Ziel ist nicht, aus der Ärzteschaft eine zweite IT-Abteilung zu machen. Das Ziel ist eine sprachfähige Ärzteschaft.
Wir müssen unsere Werkzeuge wieder mitgestalten
Die zentrale Frage ist nicht, ob Medizin digital wird. Diese Frage ist entschieden. Die Frage ist, ob Ärztinnen und Ärzte die digitalen Werkzeuge ihres Berufs verstehen und mitgestalten, oder ob sie sie nur noch bedienen.
Wenn wir Software als etwas behandeln, das andere für uns bauen und das wir anschließend ertragen, verlieren wir Einfluss auf unseren eigenen Arbeitsalltag. Dann entstehen Systeme, die vielleicht abrechenbar, beschaffbar und technisch lauffähig sind, aber klinisch zu wenig Sinn ergeben. Dann geben wir die Gestaltung unserer Werkzeuge an Menschen ab, die oft hochkompetent sind, aber nie eine Nacht in der Notaufnahme gearbeitet, nie eine palliative Krisensituation begleitet, nie eine Intensivübergabe um 7:15 Uhr gemacht und nie erlebt haben, wie kleine Informationsverluste echte Konsequenzen haben können.
Das ist nicht fair gegenüber den Entwicklerinnen und Entwicklern. Und es ist nicht professionell von uns. Professionalisierung bedeutet heute, Software als Teil der ärztlichen Wirklichkeit ernst zu nehmen. Nicht als Modewort. Nicht als KI-Hype. Nicht als weiteres Zertifikat für den Lebenslauf. Sondern als Grundkompetenz für sichere, gute und gestaltbare Medizin.
Ärztinnen und Ärzte müssen nicht alle coden können wie Softwareentwickler.
Aber sie sollten genug coden, um zu verstehen, was Code ist. Genug, um Fragen zu stellen. Genug, um schlechte Systeme nicht nur zu beklagen, sondern bessere zu fordern. Genug, um mit IT, Produktteams, Datenschutz, Geschäftsführung und Regulierung auf Augenhöhe zu sprechen.
Wenn Software unseren Alltag prägt, dann gehört Softwareverständnis in die ärztliche Ausbildung. Vor der Approbation. Nach der Approbation. Und besonders dort, wo ärztliche Führung über die Werkzeuge entscheidet, mit denen andere täglich arbeiten müssen.