Im August 2014 war ich 27 Jahre alt, lebte in Amman und tat das Ding, das jeder vernünftige Mensch dir ausrät: Ich gründete eine Softwarefirma. Kein SaaS-Side- Projekt. Eine Healthcare-Software-Beratung, die am Ende ein vollständiges Electronic Health Record System an das Prince Sultan Cardiac Centre in Al-Ahsa, Saudi-Arabien deployen würde.

Wir nannten es AFAQ. Zwölf Engineers. Echte Krankenhäuser. Echte Patienten. Ich war Founder, CTO, Principal Engineer, Product Manager, Acting CEO, IT Manager und Development Manager — gleichzeitig, auf derselben Visitenkarte, mit demselben Gehalt (das im ersten Jahr faktisch null war).

Niemand warnte mich, dass “Chief Everything Officer” eine Stellenbeschreibung ist, die einen in Hundejahren altern lässt.

Was AFAQ wirklich baute

Wir bauten eine EHR/EMR-Plattform — klinische, administrative und finanzielle Module, mit vollständigen ERP-Fähigkeiten drangebaut. Die Idee war, dass ein Krankenhaus nicht sieben verschiedene Anbieter für sieben verschiedene Systeme brauchen sollte. Wir würden eine kohärente Plattform liefern, in Jordanien gebaut, deployed für Golf-Healthcare-Einrichtungen, die sich mitten im Upgrade-Zyklus von Papier-und-Legacy zu etwas Modernem befanden.

Der Stack war nicht minimal. Java EE. Spring Boot, Spring Security, Spring WS. Hibernate mit JPA. Auf dem Frontend: GWT (Google Web Toolkit) für die schweren klinischen Interfaces, AngularJS und Bootstrap für die administrativen. Talend für ETL. Tomcat und WildFly als App-Server. PHP mit Symfony und Yii für Integrationen. MySQL und Oracle als primäre Datenbanken. HL7 und FHIR für Interoperabilität.

Das ist viel. Das ist zu viel für ein zwölfköpfiges Team. Wir shippten es trotzdem, weil man sich nicht über den Scope beschweren kann, wenn man derjenige ist, der den Vertrag verkauft hat.

Der Datenbank-Connector, den sonst niemand schrieb

Hier ist der Teil, auf den ich noch stolz bin: Wir schrieben neue Datenbank- Connectors für fis GT.M.

Falls du noch nie von GT.M gehört hast — du bist nicht allein, und das ist der Punkt. GT.M ist eine hierarchische NoSQL-Datenbank, die in VistA läuft, dem Open-Source-EHR der VA, das seit den 1990ern in amerikanischen Veteranenkrankenhäusern deployed ist. Es läuft auf einer Sprache namens MUMPS (jetzt M genannt). Seine Zugriffsmuster sind antik, sein Tooling ist dünn, und die Dokumentation setzt voraus, dass du den vierjahrzehnte-alten Kontext des Systems bereits kennst.

Niemand schrieb 2015 moderne Datenbank-Connectors für GT.M. Wir taten es, weil AFAQs Plattform mit Krankenhaussystemen interfacen musste, die GT.M-Infrastruktur betrieben — und “wir routen daran vorbei” war keine Option, wenn die Pharmacy- und Billing-Daten deines Kunden darin leben. Also setzte ich mich hin, las den GT.M- Programmierleitfaden, las die MUMPS-Spezifikation und schrieb Connectors, die GT.M so verhalten ließen, dass man es von einem modernen Java-Service aus aufrufen konnte.

Die meisten Engineers werden in ihrer Karriere nie einen Datenbank-Connector schreiben. Die meisten der wenigen, die es tun, werden einen für Postgres oder MySQL schreiben, wo jede Frage eine Stack-Overflow-Antwort hat. Einen Connector für GT.M im Jahr 2015 zu schreiben bedeutete, Source-Code und Mailinglisten von Leuten zu lesen, die das machten, seit bevor ich geboren wurde.

Zwölf Engineers, ein Org-Chart, das keinen Sinn ergab

Zwölf Engineers zu managen, während man gleichzeitig der Principal Engineer am Produkt ist, ist ein Koordinationsproblem ohne saubere Antwort. Man soll technische Entscheidungen delegieren. Man soll sie auch schneller treffen als jeder andere im Team, weil man derjenige ist, der für den Vertrag haftet. Diese zwei Dinge bekämpfen sich ständig.

Was ich lernte: Die Constraint, die in einer kleinen Beratung am meisten zählt, ist nicht technisch, es ist Scope-Spezifität pro Person. Jeder Engineer braucht eine einzige Sache, die er besitzt und für die er verantwortlich ist. In dem Moment, wo zwei Engineers beide “am klinischen Modul arbeiten”, hast du ein Merge-Problem und Communication-Overhead, der deinen Sprint auffrisst.

Wir betrieben schlanke Domain-Ownership, bevor das ein Blog-Post-Konzept war. Der Billing-Engineer besaß Billing. Der Pharmacy-Engineer besaß Pharmacy. Ich besaß die Architekturentscheidungen, die diese Linien überschnitten, und ich traf maximal zwei davon pro Monat — weil jede cross-cutting-Entscheidung eine Context-Switch- Steuer auf alle ist.

Wie KPI-Analyse in einem Kardiologie-Krankenhaus-Deployment aussah

Vor dem Go-Live im Prince Sultan Cardiac Centre führten wir KPI-Analyse und -Implementierung über ihre klinischen Workflows durch. Das klingt abstrakt. Hier ist, was das konkret bedeutet.

Ein Kardiologen-Zentrum interessiert sich für: Door-to-Balloon-Zeit (wie lange von Brustschmerzen bis zur Intervention), Medikations-Abstimmungs-Fehler, duplizierte Testaufträge, Patienten-ID-Mismatches zwischen Abteilungen. Das sind keine theoretischen KPIs. Das sind Life-and-Safety-KPIs. Das Reporting falsch zu machen produziert keinen schlechten Quartalsbericht — es produziert ein klinisches Audit, in dem du nicht namentlich erwähnt werden willst.

Also saßen wir mit ihren klinischen Leitern, mappten ihre bestehenden papier- und legacy-systembetriebenen Workflows und bauten dann Reporting-Pipelines in unserem EHR, die die richtigen Zahlen an der richtigen Stelle anzeigten. Talend ETL leistete die schwere Arbeit für Transformationen zwischen ihren Legacy-Daten und unseren Modellen. HL7-Nachrichten trugen die Interoperabilitätsschicht.

Das Go-Live war kein dramatischer Moment. Es war ein Dienstag. Ein paar Schwestern fragten, wo der Button hingewandert sei. So weiß man, dass es gut gelaufen ist.

Wofür AFAQ wirklich da war

AFAQ dauerte von August 2014 bis Januar 2017. Zwei einhalb Jahre. Wir shippten. Wir hatten Kunden. Wir hatten laufende Systeme in Produktionskrankenhäusern.

Aber AFAQ war weniger ein Unternehmen als eine Schmiede. Zwölf Engineers, die Java oder PHP konnten, als sie kamen, und die verstanden, wie Healthcare-Datenmodelle funktionieren, warum HL7 existiert, wie man einen Vertrag mit einer Krankenhaus-IT-Abteilung mit zwölf Genehmigungsebenen verhandelt, und was es kostet, auf der Datenmodell-Ebene über eine Annahme falsch zu liegen, wenn die Produktionsdatenbank Oracle ist und der Kunde ein Kardiologie-Krankenhaus in Saudi-Arabien, als sie gingen.

Aus AFAQ kam ich mit einem sehr spezifischen Satz von Meinungen heraus. Dass Healthcare-Software auf Arten schwieriger ist als Enterprise-Software, die nichts mit dem Code zu tun haben. Dass ein zwölfköpfiges Team groß genug ist, um echte Systeme zu produzieren, und klein genug, um noch auf Arten fragil zu sein, die ein hundertköpfiges Unternehmen nicht ist. Dass einen Datenbank-Connector für eine 1980er-hierarchische Datenbank zu schreiben eine bessere Ausbildung in Datenmodellierung ist als jeder Kurs, den du belegen wirst.

Die Visitenkarte mit sechs Jobtiteln war chaotisch. Die Systeme, die wir shippten, waren es nicht. Das war der ganze Punkt.