AFAQ Healthcare Suite

Im August 2014 war ich 27 Jahre alt und tat das, wovor einen jeder vernünftige Mensch warnt: Ich gründete mit in Amman ein Healthcare-Softwareunternehmen. Kein SaaS-Side-Project mit Runway-Plan und Pivot-Option. Eine Consultancy, die ein vollständiges Electronic-Health-Record-System an ein lebendiges Herzinfarktzentrum in Saudi-Arabien liefern sollte - mit echten Patienten, echten klinischen Workflows und echten Konsequenzen, wenn man es falsch macht.

Wir nannten es AFAQ. Zwölf Engineers. Ich als Gründer, CTO, Principal Engineer, Product Manager, amtierender CEO, IT-Manager und Development Manager - gleichzeitig, auf derselben Visitenkarte, mit einem Gehalt, das im ersten Jahr effektiv null war. Niemand hatte mich gewarnt, dass “Chief Everything Officer” einen in Hundejahren altern lässt.

Was die Suite tatsächlich war

AFAQs Kernprodukt war eine krankenhaus-weite EHR/EMR-Plattform: klinische, administrative und finanzielle Module mit vollständigen ERP-Fähigkeiten. Der Pitch war Kohärenz - ein Krankenhaus sollte nicht sieben verschiedene Anbieter für sieben verschiedene Systeme brauchen. Wir lieferten eine Plattform, gebaut in Jordanien, bereit für Golf-Healthcare-Einrichtungen in der Mitte des Upgrade-Zyklus von Papier-und-Legacy zu modern.

Der Stack war nicht minimal. Java EE. Spring Boot, Spring MVC, Spring Security, Spring WS. Hibernate mit JPA. AngularJS und Bootstrap für die administrativen Interfaces. Talend ETL für Datentransformation. Tomcat und WildFly als Application Server. PHP mit Symfony und Yii für Integration-Layers. MySQL und Oracle als primäre Datenbanken. HL7 und FHIR für Interoperabilität. Und GT.M - dazu gleich mehr.

Zu viel für ein 12-köpfiges Team? Ja. Wir lieferten es trotzdem, weil man, wenn man derjenige ist, der den Vertrag unterschrieben hat, nicht das Recht hat, sich über den Scope zu beschweren.

Der GT.M-Connector, den sonst niemand schrieb

Das ist das Stück, auf das ich noch ein Jahrzehnt später stolz bin.

GT.M ist eine hierarchische NoSQL-Datenbank - die Storage-Engine unter VistA, dem Open-Source-EHR der VA, das seit den 1980ern in amerikanischen Veteranen-Krankenhäusern läuft. Es läuft auf MUMPS (heute M). Das Tooling ist dünn. Die Dokumentation setzt Kontext voraus, der vierzig Jahre zurückreicht.

2015 schrieb niemand moderne Database-Connectors für GT.M. Wir mussten, weil AFAQ mit Krankenhaus-Systemen interfacen musste, in denen Apotheken- und Abrechnungsdaten in GT.M-Infrastruktur lebten - und “drumherum routen” war keine Option, wenn der Client ein Herzinfarktzentrum ist und die Daten klinisch entscheidend sind.

Also las ich das GT.M-Programmierhandbuch, las die MUMPS-Spezifikation und schrieb Connectors, die GT.M so verhielten, als wäre es etwas, das man von einem modernen Java-Service aufrufen kann. Die meisten Engineers schreiben null Database-Connectors in einer ganzen Karriere. Die meisten, die es tun, schreiben einen für Postgres oder MySQL, wo jede Frage eine Stack-Overflow-Antwort hat. Einen GT.M-Connector 2015 zu schreiben bedeutete, Source-Code und Mailinglists von Leuten zu lesen, die das schon machten, bevor ich geboren war. Jede Stunde wert.

Prince Sultan Cardiac Centre

Das Flaggschiff-Deployment war das Prince Sultan Cardiac Centre in Al-Ahsa, Saudi-Arabien - eine Spezialklinik für Herzerkrankungen, wo die KPIs keine Quartalswachstumszahlen sind, sondern Dinge wie Door-to-Balloon-Time (das Intervall zwischen dem Erscheinen eines Patienten mit Brustschmerzen und dem Beginn einer Intervention), Fehlerquoten bei der Medikationsabstimmung und Anzahl doppelter Test-Bestellungen.

Das sind KPIs mit Lebens- und Sicherheitsbezug. Vor Go-live führte das AFAQ-Team eine KPI-Analyse über die klinischen Workflows des Zentrums durch - kartierte die papier- und legacy-basierten Prozesse, identifizierte, wo die Zahlen am meisten zählten, und baute dann Reporting-Pipelines innerhalb des EHR, die die richtigen Daten an den richtigen Stellen ans Licht brachten. Talend ETL trug die Transformationslast. HL7-Messages handhabten die Interoperabilitäts-Schicht zwischen den Systemen.

Go-live war ein Dienstag. Einige Krankenschwestern fragten, wohin ein Button gewandert war. So weißt du, dass es gut lief.

Zwölf Engineers, eine Architekturentscheidung pro Monat

Zwölf Engineers zu managen und gleichzeitig Principal Engineer am gleichen Produkt zu sein, 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 gerade steht. Diese beiden Dinge kämpfen jede Woche gegeneinander.

Was funktionierte: extreme Spezifität des Ownership. Jeder Engineer besaß genau eine Sache. Der Billing-Engineer besaß Billing. Der Pharmacy-Engineer besaß Pharmacy. Cross-domain-Entscheidungen kamen zu mir, und ich traf genau zwei davon pro Monat, maximal - weil jeder übergreifende Call eine Context-Switch-Steuer auf alle anderen ist.

Wir betrieben schlankes Domain-Ownership, bevor es ein Blog-Post-Konzept war. Keine originelle Idee; einfach das Ding, das eine kleine Consultancy kohärent hält, wenn der Scope breit und das Team klein ist.

Was “archived” hier bedeutet

AFAQ lief von August 2014 bis Januar 2017. Zweieinhalb Jahre. Ich verließ es Anfang 2017; die Suite war zu dem Zeitpunkt in Produktion. Ob sie noch in irgendeiner Form am Prince Sultan Cardiac Centre läuft - ich weiß es ehrlich nicht. Healthcare-Software überdauert ihre ursprünglichen Autoren typischerweise deutlich. Die GT.M-Connectors ganz besonders: solche Infrastruktur wird in niemandes bevorzugtem Zeitrahmen ersetzt.

Das Unternehmen war weniger ein Unternehmen als eine Schmiede. Zwölf Engineers kamen rein, die Java oder PHP kannten. Sie gingen raus und wussten, wie Healthcare-Datenmodelle funktionieren, warum HL7 existiert, wie man einen Vertrag mit einer Krankenhaus-IT-Abteilung mit zwölf Genehmigungsebenen aushandelt, und was es kostet, auf der Daten-Modell-Ebene eine Annahme falsch zu machen, wenn die Produktionsdatenbank Oracle ist und der Client eine kardiologische ICU betreibt.

Ich kam mit demselben Wissen raus, plus einem sehr spezifischen Satz an Meinungen darüber, was Healthcare-Software schwer macht - und das hat fast nichts mit dem Code zu tun.