Termbox fonctionne désormais sur Databricks Lakebase
Termbox, le serveur de Terminology FHIR, peut désormais s'exécuter sur Databricks Lakebase PostgreSQL. Le contenu SNOMED, LOINC et RxNorm, ainsi que les ensembles de valeurs que vous utilisez, résident maintenant dans la même plateforme que vos autres produits et au même endroit où vos équipes de données travaillent déjà.
Le problème des listes de codes
La plupart des questions intéressantes en analytique de la santé sont, au fond, des questions de Terminology. Les équipes de données résolvent ce problème à l'aide de listes de codes. Parfois exportées d'un outil de Terminology il y a plusieurs mois. Parfois saisies à la main. Parfois au moyen de processus complexes de type ELT pour se maintenir à jour avec les sources de Terminology. Pendant ce temps, le serveur de Terminology opérationnel détient la définition des concepts — ceux utilisés pour valider les données, alimenter la barre de recherche dans l'interface utilisateur et mapper les concepts entre les vocabulaires. Cela crée un fossé qui influe sur les décisions architecturales et entraîne des coûts supplémentaires.
Les données de Terminology sont différentes
Si ce pipeline semble inefficace, c'est parce que la Terminology ne se comporte en rien comme des données cliniques. Elle possède quatre propriétés qui, prises ensemble, changent l'endroit où elle devrait résider.
Elle est immuable et versionnée. Une publication de Terminology est un instantané, et non un jeu de données modifiable. SNOMED CT 20260301 est ce qu'il est, de façon permanente ; la publication suivante est un nouvel instantané. C'est ce qui permet à Termbox d'être aussi rapide qu'il l'est. Le contenu est chargé une seule fois et indexé de manière intensive. Il n'y a aucune contention en écriture, presque aucune invalidation de cache, aucune logique de réconciliation. C'est le fondement des temps de réponse que nous avons publiés dans le FHIR TX Benchmark.
Elle est principalement en lecture, et en rafale. Un serveur de Terminology connaît des périodes d'inactivité et des périodes de forte sollicitation : une construction de cohortes nocturne qui exécute des milliers d'expansions, une validation en lot sur un arriéré de données. La mise à l'échelle automatique de Lakebase convient bien à ce type de système, avec la possibilité de le suspendre entièrement lors des périodes d'inactivité.
Son cycle de vie appartient à quelqu'un d'autre. Ce n'est pas vous qui décidez quand SNOMED CT change, ni LOINC, ni RxNorm, ni ICD-10. Ce sont les éditeurs qui en décident, selon leurs propres calendriers, et ces calendriers sont suffisamment fréquents pour que les analyses risquent de s'exécuter sur une version de Terminology périmée. Si la Terminology se trouve à l'extérieur de votre plateforme de données, chacune de ces publications doit être propagée en franchissant une frontière. La conserver à l'intérieur permet de maintenir la boucle de mise à jour en un seul endroit.
C'est une dépendance partagée, pas les données d'un seul locataire. Les données cliniques appartiennent à un patient, une rencontre, un organisme. La Terminology appartient à tout le monde. Le même LOINC sert à la validation de l'ingestion, à la barre de recherche clinique, au constructeur de cohortes et à l'agent qui répond aux questions sur les résultats de laboratoire.
Ces quatre propriétés révèlent un schéma. Dans les systèmes transactionnels, l'utilisation de la Terminology est diffuse et imprévisible — n'importe quoi peut nécessiter la validation d'un code à tout moment. En analytique, c'est différent : ciblée, contextualisée, répétée. Les mêmes quelques ensembles de valeurs, expansés encore et encore, contre les mêmes tables. C'est exactement le cas de figure qui justifie de placer la Terminology aux côtés des données.
De l'API FHIR à la surface SQL
Pour l'instant, tout dans Termbox est exposé via l'API de Terminology FHIR : $lookup, $validate-code, $expand, $subsumes et $translate. Pour les charges de travail analytiques, l'API est la bonne interface pour certaines tâches et la mauvaise pour d'autres. Expanser un ensemble de valeurs une fois et joindre le résultat à une table d'un milliard de lignes n'est pas quelque chose que l'on souhaite faire via HTTP.
Une partie de cette fondation est déjà en place. Termbox repose sur un schéma relationnel complet, construit autour de concepts empruntés au RDF et fortement inspiré du modèle de Terminology FHIR : les concepts, les propriétés et les désignations ne sont que des lignes. Ce schéma est stable, et son exécution sur Lakebase le rend accessible depuis la plateforme où l'analytique se déroule.
Un schéma seul ne suffit toutefois pas. Un ensemble de valeurs est une définition : inclusions et exclusions, filtres, traversée de hiérarchie, références à d'autres ensembles de valeurs. Transformer cette définition en l'ensemble de codes qu'elle désigne réellement est un calcul, et un calcul lourd. C'est le travail qu'effectue $expand à chaque appel. Pour qu'un ensemble de valeurs soit utilisable depuis un JOIN SQL, cette expansion doit être matérialisée et maintenue à jour à mesure que de nouvelles publications arrivent.
C'est la partie que nous sommes en train de construire : des expansions matérialisées dans le lakehouse, documentées et suffisamment stables pour bâtir des pipelines dessus. Une définition faisant autorité, accessible de deux façons : $expand depuis l'application, un JOIN depuis le carnet de notes. L'exécution sur Lakebase en est le prérequis.
Comment l'exécuter
Termbox se connecte à Lakebase en tant que principal de service Databricks, en utilisant des identifiants de base de données émis par OAuth à durée de vie limitée. Termbox résout les identifiants, les met en cache et les renouvelle de façon transparente avant leur expiration. Il n'y a aucun mot de passe de base de données à longue durée de vie dans la configuration de votre service de Terminology.
La configuration complète se trouve dans la documentation Termbox. Pour l'essayer, vous pouvez obtenir une licence de développement gratuite en quelques clics.
