Termbox läuft jetzt auf Databricks Lakebase
Termbox, der FHIR-Terminologieserver, kann jetzt auf Databricks Lakebase PostgreSQL betrieben werden. Die Inhalte von SNOMED, LOINC und RxNorm sowie die von Ihnen verwendeten Value Sets befinden sich nun auf derselben Plattform wie Ihre übrigen Produkte – und genau dort, wo Ihre Datenfachleute bereits arbeiten.
Das Problem mit den Codelisten
Die meisten interessanten Fragen in der Gesundheitsanalytik sind im Kern Terminologiefragen. Datenfachleute lösen das mithilfe von Codelisten – manchmal vor Monaten aus einem Terminologie-Tool exportiert, manchmal manuell eingetippt, manchmal mithilfe komplexer ELT-artiger Prozesse, um mit Terminologiequellen Schritt zu halten. Gleichzeitig enthält der operative Terminologieserver die Definition der Konzepte: jene, die zur Datenvalidierung genutzt werden, das Suchfeld in der Benutzeroberfläche antreiben und Konzepte zwischen Vokabularen abbilden. Das erzeugt eine Lücke, die Architekturentscheidungen beeinflusst und zusätzliche Kosten verursacht.
Terminologiedaten sind anders
Der Grund, warum sich diese Pipeline verschwenderisch anfühlt, liegt darin, dass sich Terminology grundlegend von klinischen Daten unterscheidet. Sie besitzt vier Eigenschaften, die zusammengenommen bestimmen, wo sie hingehört.
Sie ist unveränderlich und versioniert. Ein Terminologie-Release ist ein Snapshot, kein veränderbarer Datensatz. SNOMED CT 20260301 ist, was er ist – dauerhaft; das nächste Release ist ein neuer Snapshot. Genau das ermöglicht die Geschwindigkeit von Termbox. Inhalte werden einmalig geladen und umfassend indexiert. Es gibt keine Schreibkonflikte, kaum Cache-Invalidierungen und keine Abgleichlogik. Das ist das Fundament der Antwortzeiten, die wir im FHIR TX Benchmark veröffentlicht haben.
Sie ist überwiegend lesend und stoßweise belastet. Ein Terminologieserver hat Leerlaufzeiten und enorme Lastspitzen: ein nächtlicher Kohorten-Build, der Tausende von Expansionen ausführt, oder ein Bulk-Validierungslauf über einen Rückstand. Das Autoscaling von Lakebase passt gut zu dieser Art von System – mit Scale-to-zero, das den Server im Leerlauf vollständig suspendiert.
Ihr Lebenszyklus wird von anderen bestimmt. Sie entscheiden nicht, wann sich SNOMED CT, LOINC, RxNorm oder ICD-10 ändern. Das tun die Herausgeber nach ihren eigenen Zeitplänen, und diese Zeitpläne sind häufig genug, dass Analysen Gefahr laufen, auf einem veralteten Terminologie-Release zu basieren. Liegt Terminology außerhalb Ihrer Datenplattform, muss jedes dieser Releases über eine Grenze hinweg übertragen werden. Bleibt es innerhalb der Plattform, verbleibt die Aktualisierungsschleife an einem einzigen Ort.
Sie ist eine gemeinsame Abhängigkeit, keine Mandantendaten. Klinische Daten gehören einem Patienten, einem Encounter, einer Organisation. Terminology gehört allen. Dasselbe LOINC dient der Ingestion-Validierung, dem klinischen Suchfeld, dem Kohorten-Builder und dem Agenten, der Fragen zu Laborergebnissen beantwortet.
Diese vier Eigenschaften folgen einem Muster. In transaktionalen Systemen ist die Nutzung von Terminology diffus und unvorhersehbar – irgendetwas könnte jederzeit einen Code validieren müssen. In der Analytik ist das anders: eng gefasst, kontextualisiert, wiederholt. Dieselbe Handvoll Value Sets, immer wieder expandiert, gegen dieselben Tabellen. Das spricht genau dafür, Terminology neben den Daten zu platzieren.
Von der FHIR-API zur SQL-Oberfläche
Derzeit ist alles in Termbox über die FHIR-Terminologie-API verfügbar: $lookup, $validate-code, $expand, $subsumes und $translate. Für analytische Workloads ist die API bei manchen Aufgaben die richtige Schnittstelle – bei anderen nicht. Ein Value Set einmal zu expandieren und das Ergebnis gegen eine Tabelle mit einer Milliarde Zeilen zu joinen, ist nichts, was Sie über HTTP erledigen möchten.
Ein Teil dieses Fundaments ist bereits vorhanden. Termbox basiert auf einem umfassenden relationalen Schema, das um aus RDF entlehnte Konzepte herum aufgebaut und stark vom FHIR-Terminologiemodell inspiriert ist: Konzepte, Eigenschaften und Bezeichnungen sind schlicht Zeilen. Dieses Schema ist stabil, und der Betrieb auf Lakebase macht es von der Plattform aus erreichbar, auf der Analysen stattfinden.
Ein Schema allein reicht jedoch nicht aus. Ein Value Set ist eine Definition: Einschlüsse und Ausschlüsse, Filter, Hierarchiedurchläufe, Verweise auf andere Value Sets. Diese Definition in die Menge der Codes zu überführen, die sie tatsächlich bezeichnet, ist eine aufwendige Berechnung – das ist die Arbeit, die $expand bei jedem Aufruf leistet. Damit ein Value Set per SQL-JOIN nutzbar ist, muss diese Expansion materialisiert und bei neuen Releases aktuell gehalten werden.
Genau daran arbeiten wir: Expansionen, die in den Lakehouse materialisiert werden, dokumentiert und stabil genug, um Pipelines darauf aufzubauen. Eine autoritative Definition, auf zwei Wegen erreichbar: $expand aus der Anwendung heraus, ein JOIN aus dem Notebook. Der Betrieb auf Lakebase ist die Voraussetzung dafür.
Einrichtung
Termbox verbindet sich mit Lakebase als Databricks-Service-Principal und verwendet kurzlebige, OAuth-ausgestellte Datenbankanmeldeinformationen. Termbox löst die Anmeldeinformationen auf, speichert sie im Cache und erneuert sie transparent vor dem Ablauf. In der Konfiguration Ihres Terminologiediensts liegt kein dauerhaftes Datenbankkennwort.
Die vollständige Einrichtung ist in der Termbox-Dokumentation beschrieben. Um es auszuprobieren, können Sie mit wenigen Klicks eine kostenlose Development License erhalten.
