🔥 FHIR TX Benchmark: Runde 0

FHIR TX Benchmark — performance scores across terminology servers

Bei Health Samurai ist uns Performance außerordentlich wichtig.

Wir arbeiten an einer Reihe offener FHIR-Benchmarks. Den ersten, den wir veröffentlichen, ist der FHIR TX Benchmark: ein Terminology-Server-Benchmark mit 20 Testfällen, 5 Servern, die auf denselben Daten und derselben Hardware, in isolierter Umgebung betrieben werden.

Terminology-Server sind häufig ein kritischer Bestandteil der Systeminfrastruktur und können leicht zu einem Performance-Engpass werden. Sie werden im Rahmen der Validierung eingesetzt, können UI-Elemente antreiben, als Backend für Suche und Filterung dienen und werden zunehmend in KI-gestützte Workflows integriert, um Agenten mit der Realität zu verankern.

Wir möchten alles so transparent wie möglich gestalten: Alle Skripte, Tests, Daten, Ergebnisse und Anleitungen sind auf GitHub verfügbar. Unter https://healthsamurai.github.io/tx-benchmark gibt es eine aus dem Repository generierte Live-Website mit den Ergebnissen.

Zur Methodik und zu Interessenkonflikten

Health Samurai hat die erste Version dieses Benchmarks entwickelt, und unser eigener Server (Termbox, der noch in diesem Monat veröffentlicht wird) ist einer der fünf getesteten Server. Wir wissen, wie das aussieht. Unsere Antwort ist die Methodik selbst: Jeder Test, jeder Parameter und jede Formel ist dokumentiert und offen, die Daten sind reproduzierbar, und wir stehen im Austausch mit den anderen Implementierern. Nach unserem Kenntnisstand existiert kein vergleichbarer Benchmark für FHIR-Terminology-Server. Die Methodik, die Testsuite und die Bewertung stehen zur Überprüfung offen, und wir begrüßen Vorschläge, Korrekturen und Beiträge aus der Community sowie von anderen Implementierern.

Methodik

Die FHIR Terminology Server Spec umfasst mehrere Operationen, Ressourcentypen, erweiterte Funktionen und Anwendungsfälle. Dies stellt eine Herausforderung dar, wenn es darum geht, was und wie getestet werden soll. Tests wurden nach ihrer Performance-Relevanz ausgewählt – eine Volltextsuche ist beispielsweise wichtig für Benutzeroberflächen und hat einen ganz anderen Implementierungsaufwand als eine einfache Code-Suche: Für jedes davon gibt es einen eigenen Test.

Konformität war kein Ziel; dafür gibt es bereits eine umfassende Konformitäts-Testsuite im Terminology Ecosystem IG.

Die Fähigkeiten und Zielsetzungen der Server variieren: Einige bieten nur teilweise Unterstützung für bestimmte Operationen, andere sind für spezifische Anwendungsfälle entwickelt oder für bestimmte Terminologien optimiert. Wir testen jeden Server nur auf die Funktionen, die er unterstützt. Die vollständige Methodik ist auf der Methodikseite dokumentiert.

Tests

Für die Tests haben wir einige der wichtigsten Terminology-Operationen ausgewählt: Lookup, Validate Code, Expand, Translate und Subsumes. Jeder Test wird durch einen Kurzcode identifiziert: die Initialen der Operation gefolgt von einer laufenden Nummer: LK01 für den ersten Lookup-Test, EX02 für den zweiten Expand-Test und so weiter.

Für dieselbe Operation gibt es oft mehrere Tests. Dies ermöglicht es uns, verschiedene performance-relevante Pfade, unterschiedliche Terminologien oder spezifische Funktionen einer Operation zu testen, die einen eigenen Test rechtfertigen.

Die vollständige Liste der Tests und deren Beschreibungen sind auf der Testseite dokumentiert.

Daten

Wir laden denselben Terminologie-Datensatz in jeden Server (sofern möglich). Anweisungen und Lizenzanforderungen sind im GitHub-Repository dokumentiert.

Terminologien wurden nach Bedeutung und Vielfalt (in Struktur, Hierarchie, Eigenschaften, Größe) sowie nach unterschiedlichen Typen von Value Sets ausgewählt. Die wichtigsten, die für diese Runde geladen wurden, sind:

SNOMED International - 20260201
SNOMED US Edition - 20260301
SNOMED UK Edition - 20260211
LOINC - 2.82
RxNorm - März 2026
Eine Reihe von FHIR-Paketen, darunter r4 core, THO, US Core, VSAC und andere

Die vollständige Liste finden Sie auf der Datenseite.

Bewertung

Der Benchmark erzeugt einen zusammengesetzten Score, der es ermöglicht, die Gesamtperformance der Server auf einen Blick zu vergleichen. Zwanzig Tests über sechs Operationen produzieren viele Zahlen, und der zusammengesetzte Score destilliert diese in einen einzigen vergleichbaren Wert. Wir wurden maßgeblich von den TechEmpower Framework Benchmarks inspiriert und haben unsere Algorithmen auf deren Basis entwickelt.

Die Bewertung basiert auf dem Durchsatz. Jeder Test wird auf drei Parallelitätsstufen ausgeführt: 1, 10 und 50 virtuelle Benutzer. Wir verwenden den höchsten Durchsatz über alle drei Stufen hinweg (wenn ein Server bei 10 VUs seinen Höchstwert erreicht und bei höherer Parallelität nachlässt, verwenden wir den besten Wert für die Bewertung).

Normalisierung: Die Durchsatzwerte werden auf Basis von LK01 normalisiert. Ein Lookup-Test ist immer schneller als eine komplexe Expansion; rohe RPS-Werte würden „einfache" Tests dominieren lassen, was weder fair noch sinnvoll ist.

Gewichtung: Wir multiplizieren die Testergebnisse mit einem Bias-Koeffizienten. Damit können wir den Einfluss eines Tests auf den Gesamtscore je nach Wichtigkeit anpassen. Zum Beispiel sollte die Performance eines Lookups in SNOMED für einen Terminology-Server mehr Gewicht haben als eine CodeSystem-Suche, da ersterer häufiger Teil eines kritischen Pfads ist. Die Koeffizienten sind dokumentiert und stehen wie alles andere zur Diskussion.

Imputation: Fehlende Unterstützung ist nicht dasselbe wie schlechte Performance. Null Punkte für nicht unterstützte Tests zu vergeben ist zu hart; einen schwierigen Test ohne Bewertung zu übergehen ist ebenfalls nicht fair. Server erhalten einen imputierten Wert, der aus einem Perzentil der Ergebnisse der teilnehmenden Server abgeleitet wird.

Gesamtscore: Der beste Gesamtperformer erhält 100 Punkte. Der Score jedes anderen Servers wird als Prozentsatz davon ausgedrückt – sowohl pro Test als auch im zusammengesetzten Gesamtscore.

Hardware und Stack

Lasttests werden mit k6 durchgeführt, mit Prometheus und cAdvisor für die Metrikenerfassung. Alle Server laufen in Docker-Containern auf demselben Host wie der Lastgenerator und verwenden ausschließlich Loopback – ohne Netzwerklatenz.

Runde 0 wurde auf einem Laptop ausgeführt: Apple M3 mit 8 Kernen, 24 GB RAM, Docker Desktop konfiguriert mit 8 CPUs und 20 GB. Zukünftige Runden werden auf einer dedizierten Cloud-VM mit deutlich mehr Ressourcen ausgeführt, und der Prozess wird vollständig automatisiert.

Ergebnisse Runde 0

Runde 0 ist die erste Runde und diejenige, die derzeit auf der Website veröffentlicht ist. Es handelt sich um einen Pilotlauf (wir arbeiten mit Implementierern zusammen, um sicherzustellen, dass die Server korrekt konfiguriert sind, und die Ergebnisse können noch aktualisiert werden, während wir Feedback einarbeiten). Nach Runde 1 wird der Prozess automatisiert und regelmäßig mit den neuesten Versionen jedes Servers und einer verbesserten Testsuite durchgeführt, sobald wir Feedback gesammelt haben.

Fünf Server sind in dieser Runde enthalten: FHIRsmith, Hades, Ontoserver, Snowstorm und Termbox. Nicht jeder Server hat jeden Test ausgeführt; dies wird in der Capability-Matrix dargestellt.

#	Server	Score
1	termbox	100%
2	fhirsmith	38%
3	ontoserver	21%
4	snowstorm	7%
5	hades	6%

Die vollständigen Ergebnisse, serverweise Detailansichten, rohe RPS-Werte und Latenz-Perzentile sind auf der Website verfügbar.

Ausblick

Runde 1 kommt bald – sie wird auf einer dedizierten Cloud-VM ausgeführt, automatisiert und mit verbesserten Konfigurationen auf Basis des Feedbacks aus dieser Runde. Danach planen wir, die Ergebnisse in einem vierteljährlichen Rhythmus zu veröffentlichen.

Wir sehen dies als Community-Projekt. Health Samurai ist derzeit der Betreiber, aber das Ziel ist, dass dieses Projekt von der breiteren FHIR-Community – Implementierern, Nutzern und allen, die ein Interesse an der Performance von Terminology-Servern haben – mitgestaltet und mitgetragen wird.

Wenn Sie sich einbringen möchten: Schlagen Sie neue Tests vor, melden Sie eine Fehlkonfiguration, schlagen Sie einen Server zur Aufnahme vor, oder eröffnen Sie einfach ein Issue auf GitHub. Jedes Feedback ist willkommen.

Häufig erwartete Fragen

Wir gehen davon aus, dass Sie möglicherweise viele Fragen haben. Hier sind einige, die wir vorwegnehmen. Aber kontaktieren Sie uns gerne, wenn Sie eine Frage haben, die wir hier nicht behandeln, oder wenn Sie uns mitteilen möchten, dass wir etwas falsch machen.

„Server X ist falsch konfiguriert – das erklärt die Zahlen.": Das ist durchaus möglich. Wir haben unser Bestes getan, um jeden Server korrekt zu konfigurieren, sind aber keine Experten für alle von ihnen. Wenn Sie wissen, wie eine Konfiguration verbessert werden kann, eröffnen Sie bitte einen Pull Request oder melden Sie ein Issue, und wir werden die Ergebnisse aktualisieren.
„Warum ist Server X nicht enthalten?": Möglicherweise kennen wir ihn nicht. Eröffnen Sie ein Issue oder einen PR mit Setup-Anweisungen, und wir werden daran arbeiten, ihn in einer zukünftigen Runde aufzunehmen.
„Warum diese Tests? Warum wird Operation X nicht getestet?": Tests wurden nach ihrer Performance-Relevanz ausgewählt. Wenn Sie der Meinung sind, dass eine wichtige Operation oder ein Anwendungsfall fehlt, ist die Testsuite zur Erweiterung gedacht – wir haben für Runde 1 bereits einige im Sinn. Bitte helfen Sie uns, indem Sie ein Issue eröffnen.
„Health Samurai hat diesen Benchmark erstellt, und Termbox schneidet gut ab. Ist das nicht ein Interessenkonflikt?": Wir haben dies am Anfang des Beitrags angesprochen. Kurz zusammengefasst: Die Methodik, die Daten und die Bewertung sind vollständig offen und reproduzierbar. Es ist auch erwähnenswert, dass Termbox speziell mit Blick auf Performance entwickelt wurde – wir würden erwarten, dass er gut abschneidet. Wenn Sie einen Fehler in der Methodik finden, eröffnen Sie bitte ein Issue.
„Die Bias-Koeffizienten und das Imputations-Perzentil könnten so eingestellt werden, dass bestimmte Server bevorzugt werden.": Sie sind eine Ermessensentscheidung, und wir haben sie aus genau diesem Grund explizit dokumentiert. Wenn Sie mit den Gewichtungen nicht einverstanden sind, eröffnen Sie ein Issue – wir sind offen dafür, sie auf Basis von Community-Feedback anzupassen.
„Sie haben das auf einem Laptop ausgeführt?": Ja. Runde 0 ist ein Pilotlauf auf einem Apple M3. Die Zahlen werden sich auf besserer Hardware ändern, aber wir erwarten, dass die relativen Rankings weitgehend konsistent bleiben. Zukünftige Runden werden auf einer dedizierten Cloud-VM ausgeführt.
„Und was ist mit Caching? Die meisten Produktivumgebungen schalten einen Cache vor den Server.": Das stimmt, und es verändert das Bild erheblich. Aber wir führen einen Benchmark für den Server durch, nicht für die Deployment-Architektur. Reale Produktivumgebungen sind komplexer, und wir sind uns dessen bewusst – aber das ist eine andere Messgröße.
„Was ist mit Clustering oder horizontaler Skalierung?": Dieser Benchmark testet ausschließlich die Performance eines einzelnen Knotens. Horizontale Skalierung ist eine valide Dimension, hängt aber stark von der Deployment-Architektur ab und nicht nur vom Server selbst.