HAKEEM Nationales EHR

Im Jahr 2010 landete Node.js v0.4 und das Internet verbrachte das Jahr damit zu diskutieren, ob JavaScript auf einem Server ein Witz sei. Gleichzeitig schrieb ich mit 22 Jahren beim Team von Electronic Health Solutions (EHS) - einer Public-Private-Partnership zwischen der jordanischen Regierung und einem Healthcare-Provider-Konsortium - MUMPS-Routinen für das Apotheken-Dispensing-Modul eines nationalen EHR, das schließlich vier Krankenhäuser in ganz Jordanien bedienen sollte.

Das war HAKEEM. Meine Rolle: Developer und System Analyst, 2010 bis 2013. Drei Jahre. Vier Krankenhäuser. Ein national-scale-System gebaut auf einem Technology-Stack, der moderne Engineers ein Gesicht ziehen ließ - was sich als exakt die richtige Vorbereitung für das nächste Jahrzehnt herausstellte.

Worauf HAKEEM gebaut wurde

HAKEEM wurde auf VistA gebaut - der Veterans Information Systems and Technology Architecture, entwickelt vom U.S.-Department of Veterans Affairs. VistA ist eines der am längsten laufenden EHR-Systeme des Planeten, seit den 1980ern in amerikanischen Veteranen-Krankenhäusern deployed. Es läuft auf MUMPS (später M), einer hierarchischen Datenbank- und Sprachkombination, die wie nichts anderes aussieht, das man je geschrieben hat.

Die Entscheidung war solide. VistA ist in einer Weise battle-tested, mit der kommerzielle EHRs schwer mithalten: Apothekenmodule, klinische Entscheidungsunterstützung, Scheduling, Abrechnung - alles unter einem kohärenten Datenmodell. Open-Source bedeutete, dass Jordanien keine proprietäre Software für eine nationale Deployment lizenzieren musste. Die Tatsache, dass es auf GT.M läuft, einer hierarchischen NoSQL-Datenbank, bedeutete, dass man Engineers brauchte, die MUMPS lesen konnten und vor einem vierzig Jahre alten Stack keine Angst hatten.

Wie die Arbeit wirklich aussah

Der Titel war Developer/System Analyst. In der Praxis waren es drei verschiedene Workstreams, die parallel liefen.

MUMPS-Routinen. Das Team schrieb M-Routinen in drei Paketen: Pharmacy, Billing und HL7-Messaging. Apotheken-Dispensing-Logik in MUMPS ist eine von diesen Sachen, die die eigenen ästhetischen Empfindlichkeiten beleidigt und dann vierzig Jahre lang korrekt funktioniert. Variablen sind standardmäßig global. Die Datenbank ist die Sprache - Globals (MUMPS’ Begriff für persistente Variablen) mappen direkt auf die hierarchische Datenbankstruktur. Eine Routine ist eine Datei. Es gibt keine Funktionen im modernen Sinn; es gibt Labels und GOTO-Äquivalente, die Menschen mit strukturiertem Programmier-Hintergrund unwohl fühlen lassen. Und dennoch: Die Dispensing-Logik, die für HAKEEM’s Apothekenmodul geschrieben wurde, läuft fast sicher noch in irgendeiner Form in jordanischen Krankenhäusern. Das kann man von den meisten JavaScript-Frameworks nicht sagen.

C#-GUI-Anwendungen. Die zwei wichtigsten waren das Patient-Information-Management-GUI und das Scheduling-GUI, beide kommunizierend mit dem VistA-Backend über sein RPC-Broker-Protokoll. Das klingt langweilig. War es nicht. Patientendaten-Management in einem nationalen EHR bedeutet, dass das Registrierungs-Interface der Krankenschwester der Einstiegspunkt für Daten ist, die in jedes nachgelagerte System fließen - Apotheke, Labore, Abrechnung, Reporting. Das GUI so zu bauen, dass Garbage hineinkommt, und man debuggt sechs Monate nach Go-live Patienten-ID-Mismatches im Prince-Hamza-Krankenhaus. Das Scheduling-GUI hatte ähnliches Gewicht: ambulante Klinik-Planung an der Amman Comprehensive Clinic bedeutete Terminslots über mehrere Abteilungen, Stornierungshandling und Personalberichte. Langweilige Software, die enorm wichtig ist, wenn sie kaputtgeht.

Mobile-GUIs. Im Jahr 2012. Für ein Healthcare-EHR. Java für Android, Objective-C für iOS. Mobile Healthcare 2012 war kein ausgereifter Bereich - Android war auf Version 4.0, iOS 6 war Monate entfernt, und die UX-Konventionen für Clinicians, die auf einem Mobilgerät auf Patientenakten zugreifen, existierten noch nicht. Das Team arbeitete es unter der Constraint aus, dass ein falsch gelesener Patientendatensatz auf einem Mobilgerät Patient-Safety-Implikationen hat, die ein falsch gelesener Tweet nicht hat.

Bash-Backup-Scripts. Auch Teil des Jobs. Die GT.M-Datenbank lief auf Linux-Servern und brauchte zuverlässige Backups und Task-Management. Nicht glamourös. Vollständig tragendes Element. Krankenhäuser, die Daten verlieren, machen aus den falschen Gründen Schlagzeilen.

Vier Krankenhäuser, vier Deployment-Geschichten

HAKEEM rollte an vier Einrichtungen aus, und jede war ihr eigenes Projekt.

Prince Hamza Hospital war das große Allgemeinkrankenhaus - hohes Volumen, mehrere Fachgebiete, die volle Breite der EHR-Fähigkeiten. Wo man herausfindet, ob Patientenregistrierung und Scheduling skalieren, wenn man Hunderte von ambulanten Besuchen pro Tag hat.

Amman Comprehensive Clinic war das ambulante Modell. Weniger stationäre Versorgung, mehr Terminmanagement und Nachsorge für chronische Krankheiten. Das Scheduling-GUI verdiente sich hier seinen Lebensunterhalt.

Prince Hussein Hospital hatte klinische Workflow-Anforderungen, die sich nicht sauber auf die Standard-VistA-Konfiguration mappen ließen. Customization auf der MUMPS-Schicht. Die Art Arbeit, bei der man eine Routine von 1993 liest und entscheidet, welche Zeilen man ändern kann, ohne alles Nachgelagerte kaputtzumachen.

King Hussein Cancer Centre war das Integration-Projekt - KHCC hatte sein eigenes EHR, seine eigenen Patientenakten, seine eigenen Workflows und musste sich via HL7 v2 mit HAKEEM verbinden. Diese Integration wurde vom Team gebaut und ist separat dokumentiert; die Kurzversion ist Patienten-Identitätsauflösung über zwei MRN-Spaces, Event-Ordering und Pipe-Delimited-Message-Parsing und -Transformation.

Was nationale Infrastruktur lehrt

Drei Jahre auf HAKEEM lehrten etwas, das mich durch jedes Projekt seitdem begleitet: die Lücke zwischen “funktionierender Software” und “Infrastruktur, von der ein Land abhängt” ist ein organisatorisches Problem, kein technisches.

Der Code war schwer. MUMPS ist schwer auf Weisen, die legitim sind, nicht nur ästhetisch. HL7 ist schwer. Ein Mobile-EHR-GUI 2012 zu schreiben, bevor irgend jemand ein Playbook dafür hatte, war schwer.

Aber die schwierigeren Probleme hatten keinen Debugger. Welches Krankenhaus bekommt den nächsten Customization-Sprint? Wer besitzt die Entscheidung, wenn zwei Krankenhäuser widersprüchliche Änderungen an derselben MUMPS-Routine brauchen? Was bedeutet Rollback, wenn man gerade mid-Deployment an einer Einrichtung ist, die morgen früh Patienten sieht?

Die technischen Skills aus diesen drei Jahren waren wertvoll. Das Verständnis dafür, wie komplexe Systeme auf der organisatorischen Ebene scheitern, war es mehr. Apotheken-Logik in MUMPS zu schreiben stellte sich als ziemlich guter Weg heraus, beides gleichzeitig zu lernen.