Jahre beim Bauen von EHR/EMR-Plattformen — zuerst bei HAKEEM, dann bei AFAQ als Gründer — haben mir beigebracht, dass das sichtbare Produkt (die UI, die Buttons, die Ansicht der Krankenakte) vielleicht 15 % davon ist, was das System tatsächlich in einem Krankenhaus zum Laufen bringt. Die anderen 85 % sind unsichtbarer Papierkram: Regulierung, Audit, Interoperabilität und das exakte Wire-Format, das ein Apotheken-Drucker um 03:00 Uhr erwartet. Jede Healthcare-Engineerin, die ich je eingearbeitet habe, hat die 85 % vor dem Shipping unterschätzt — und sie danach verstanden.

Das Eisberg-Prinzip

Stell dir die erste Demo einer “Vitalzeichen-Ansicht” durch eine Junior- Engineerin vor. Herzfrequenz, Blutdruck, Temperatur, ein schönes Diagramm. Sieht super aus. Wird in einem Sprint geshipt.

Dann trifft die Realität ein:

  • Das Vitalzeichen muss von sechs verschiedenen Gerätemarken über drei verschiedene Protokolle kommen (HL7 v2 over TCP, ein vendor-spezifisches Binary, eine FHIR REST API für die neueren Sachen). Die Hälfte der Geräte stammt aus der Zeit vor FHIR und wird nie upgegradet.
  • Die Zahl, die der Arzt manuell eingibt, muss neben der Gerätezahl koexistieren. Welche ist kanonisch? Antwort: das kommt auf die Schicht, das Krankenhaus, das Gerätemodell und das Protokolldokument der Station an. Du brauchst ein Provenance-Feld, kein Value-Feld.
  • Die Ansicht muss einen Audit in sechs Jahren überstehen. Nicht “zeig die gleiche Zahl” — beweise, wer was wann gesehen und bestätigt hat. Das bedeutet immutable Logs, keine Überschreibungen.
  • Dieselbe Ansicht darf nicht über Mandanten hinweglecken. Die Vitalzeichen von Klinik A erscheinen nicht den Mitarbeitern von Klinik B — auch wenn Klinik A und Klinik B einige Mitarbeiter teilen, die zwischen ihnen wechseln. Das Berechtigungsmodell ist ein Relationship-Graph, kein Role-Enum.
  • Regulierungsstandards ändern sich. HL7 v2 war der Standard 2010; FHIR ist der Standard 2025; was auch immer 2035 kommt, muss sich einfügen, ohne die Chart-Ansicht neu zu schreiben.

Jeder dieser Punkte ist eine Woche Arbeit, die niemand abgerechnet hat. Die meisten davon lassen sich auch nicht aufschieben — sie sind vertraglich, rechtlich oder patientensicherheitskritisch vom ersten Tag an.

Das Framing, das hilft

Ich erziele bessere Ergebnisse mit Junior-Engineers, wenn ich das Eisberg- Modell ausdrücklich zu Beginn eines Healthcare-Projekts aufzeige. Das sichtbare Produkt sind 15 %. Der sichtbare Scope sind 15 %. Das Sprint-Planning dreht sich um 15 %. Die anderen 85 % müssen zuerst architektonisch bedacht werden, weil das Nachrüsten doppelt kostet.

Konkret lade ich diese fünf Dinge bei jedem neuen Healthcare-Build vorne auf:

  1. Immutable Audit Log. Jeder Schreibvorgang auf irgendwas Patient-nahem wird nur angehängt, nie überschrieben. Mir ist es egal, ob das eine Row-Level-Ledger-Tabelle, ein Event-Stream oder eine Flat-File ist — aber sie muss da sein, bevor Feature eins geshipt wird. Das nachzurüsten ist das teuerste, was ich je in einer Healthcare-Codebase tun musste.
  2. Provenance, keine Values. Jedes Feld hat (value, source, observed_at, confidence). Vorzugeben, ein Feld sei nur ein Skalar, ist okay im Banking; nicht okay in einem System, wo zwei Kliniker verschiedene Zahlen von zwei verschiedenen Monitoren eingegeben haben.
  3. Tenant-Isolation auf Query-Ebene. Row-Level Security in Postgres oder equivalent. Nicht “die App filtert nach tenant_id” — weil eines Tages die App das nicht tut, und das ist dann ein Breach.
  4. Ein Interop-Layer, keine direkten Integrationen. Ein kleiner Service, der HL7 v2 + FHIR + was auch immer Vendor-Binary spricht und dem Rest der App eine saubere interne Form exponiert. Du wirst Formate hinzufügen. Du wirst nie welche entfernen.
  5. Ein Regulatory-Review-Rhythmus. Kein Gate, ein Rhythmus. Jeden Quartal sieht jemand, dessen Job es ist, sich um HIPAA / DSGVO / lokale Entsprechung zu kümmern, was geshipt wurde und erhebt Bedenken. Wenn du das nicht hast, wirst du sechs Monate vor dem Launch eine einzige gigantische Panik-Gate haben.

Was die CV-Zeile verschweigt

In meinem CV ist AFAQ zwei Zeilen: “EHR/EMR-Plattform für Krankenhäuser gebaut.” HAKEEM ist zwei Zeilen: “Nationales EHR für öffentliche Krankenhäuser.”

Was diese Zeilen nicht sagen:

  • Bei AFAQ habe ich die erste Version einer Drug-Interaction-Prüfung in MUMPS-nahem Code geschrieben, weil das der Apothekensystem als Input wollte. In der Woche, in der ich es geshipt habe, hat sich eine Klinikerin bedankt, weil der bisherige Prozess ein gedrucktes PDF war, das man am Schreibtisch aufbewahren musste.
  • Bei HAKEEM habe ich eine Deployment-Stabilisierung über mehrere Krankenhäuser hinweg miterlebt, bei der der Blocker nicht der Code war — sondern sechs verschiedene Ärztliche Direktoren dazu zu bringen, sich darüber zu einigen, was “aufgenommen” im Datenmodell bedeutet. Den Code haben wir in Wochen geshipt. Die Einigung hat Monate gedauert. Die Einigung war das echte Deliverable.
  • Beide Systeme laufen noch irgendwo. Code, den ich 2012 geschrieben habe, routet noch immer Vitalzeichen in einem Krankenhaus in Jordanien. Das ist kein Angeben — es ist eine Erinnerung daran, dass Healthcare-Systeme ihre Designer und ihre Verträge überleben. Plant das vom ersten Tag an.

Der Plot-Twist 2026

Ich sage die stille Wahrheit laut: KI-gestütztes Engineering ist ein außerordentlicher Beschleuniger für die 85 %. Der unsichtbare Papierkram ist meistens Musterarbeit — Audit-Verdrahtung, Provenance-Transforms, Interop- Adapter, Tenant-Filter. Das sind genau die Dinge, die ein LLM gut generiert, wenn man es richtig formuliert. Die sichtbaren 15 % sind der Ort, wo menschliches Urteilsvermögen noch am meisten zählt, weil dort klinische Workflows auf UI treffen und die falsche Wahl den Nachmittag von Menschen ruiniert.

Der Fehler, den ich 2026 bei Teams sehe, ist die Umkehrung davon: Sie nutzen KI, um das auffällige Dashboard zu generieren, und winken dann die Audit-Schicht weg. Die richtige Reihenfolge ist umgekehrt. Nutze die KI, um die 85 % schnell und korrekt einzubauen; verwende deine menschliche Aufmerksamkeit auf die 15 %, die Krankenpflegerinnen tatsächlich anfassen.

Das eine Ding, das jede Healthcare-Engineerin lernen sollte

Wenn ich morgen eine neue Engineerin in ein Healthcare-Projekt einarbeiten würde, würde ich sie die erste Woche damit verbringen lassen, Incident-Reports aus echten Krankenhaus-IT-Systemen zu lesen. Keine HIPAA-Breach-Einreichungen (das sind Anwälte). Echte Post-Mortems aus der Krankenhaus-IT-Community — das Apothekensystem, das die falsche Dosis gedruckt hat; der Interop-Adapter, der ein halbes Prozent der Laborbefunde verloren hat; das Backup, das die Akte eines Patienten von vor drei Jahren wiederhergestellt hat, und niemandem ist es eine Woche lang aufgefallen.

Diese eine Woche erklärt, warum die 85 % existieren. Jede “das brauchen wir nicht”-Abkürzung ist der letzte Dienstag von jemand anderem. Lies genug davon, und du hörst auf, nach dem Überspringen des Audit-Logs zu fragen.