Termbox en Databricks Lakebase

Termbox ahora funciona en Databricks Lakebase

Termbox, el servidor de terminología FHIR, puede ejecutarse ahora sobre Databricks Lakebase PostgreSQL. El contenido de SNOMED, LOINC y RxNorm, junto con los conjuntos de valores que utiliza, reside ahora en la misma plataforma que el resto de sus productos y en el mismo lugar donde ya trabajan sus equipos de datos.

El problema de las listas de códigos

La mayoría de las preguntas interesantes en analítica sanitaria son, en el fondo, preguntas de terminología. Los equipos de datos las resuelven mediante listas de códigos: a veces exportadas de una herramienta de terminología hace meses, a veces introducidas a mano, a veces mediante complejos procesos de tipo ELT para mantenerse al día con las fuentes terminológicas. Mientras tanto, el servidor de terminología operacional almacena la definición de los conceptos: los que se usan para validar datos, para alimentar el cuadro de búsqueda en la interfaz y para mapear conceptos entre vocabularios. Eso genera una brecha que afecta a las decisiones arquitectónicas y conlleva costes adicionales.

Los datos de terminología son diferentes

La razón por la que ese flujo resulta ineficiente es que la terminología no se comporta en absoluto como los datos clínicos. Presenta cuatro propiedades que, consideradas en conjunto, cambian el lugar al que pertenece.

Es inmutable y versionada. Una publicación de terminología es una instantánea, no un conjunto de datos mutable. SNOMED CT 20260301 es lo que es, de forma permanente; la siguiente publicación es una nueva instantánea. Esto es lo que permite que Termbox sea tan rápido. El contenido se carga una sola vez y se indexa de forma intensiva. No existe contención de escritura, prácticamente no hay invalidación de caché ni lógica de reconciliación. Esa es la base de los tiempos de respuesta que publicamos en el FHIR TX Benchmark.

Es predominantemente de lectura y con picos de carga. Un servidor de terminología tiene períodos de inactividad y momentos de carga masiva: una construcción nocturna de cohortes que ejecuta miles de expansiones, una ejecución de validación masiva sobre un backlog acumulado. El autoescalado de Lakebase encaja bien con este tipo de sistema, ya que el escalado a cero permite suspenderlo por completo cuando el servidor está inactivo.

Su ciclo de vida lo gestiona un tercero. Usted no decide cuándo cambia SNOMED CT, ni LOINC, ni RxNorm, ni ICD-10. Lo deciden los organismos publicadores, según sus propios calendarios, y esos calendarios son lo suficientemente frecuentes como para que los análisis corran el riesgo de ejecutarse sobre una versión de terminología obsoleta. Si la terminología reside fuera de su plataforma de datos, cada una de esas publicaciones debe propagarse cruzando una frontera. Mantenerla dentro significa que el ciclo de actualización permanece en un único lugar.

Es una dependencia compartida, no los datos de un único inquilino. Los datos clínicos pertenecen a un paciente, un episodio, una organización. La terminología pertenece a todos. El mismo LOINC sirve para la validación en la ingesta, el cuadro de búsqueda clínico, el constructor de cohortes y el agente que responde preguntas sobre resultados de laboratorio.

Existe un patrón en esas cuatro propiedades. En los sistemas transaccionales, el uso de terminología es difuso e impredecible: cualquier operación puede necesitar validar un código en cualquier momento. En analítica es diferente: acotado, contextualizado y repetitivo. Los mismos conjuntos de valores, expandidos una y otra vez, contra las mismas tablas. Lo que es exactamente el caso para situar la terminología junto a los datos.

De la API FHIR a la superficie SQL

Actualmente, todo en Termbox está expuesto a través de la API de terminología FHIR: $lookup, $validate-code, $expand, $subsumes y $translate. Para cargas de trabajo analíticas, la API es la interfaz adecuada para algunas tareas y la errónea para otras. Expandir un conjunto de valores una vez y hacer un join del resultado contra una tabla de mil millones de filas no es algo que se quiera hacer por HTTP.

Parte de esa base ya está en su lugar. Termbox se sustenta en un esquema relacional completo, construido en torno a conceptos tomados de RDF y fuertemente inspirado en el modelo de terminología FHIR: conceptos, propiedades y designaciones son simplemente filas. Ese esquema es estable, y ejecutarlo sobre Lakebase lo hace accesible desde la plataforma donde ocurre la analítica.

Un esquema por sí solo no es suficiente, sin embargo. Un conjunto de valores es una definición: inclusiones y exclusiones, filtros, recorrido de jerarquías, referencias a otros conjuntos de valores. Convertir esa definición en el conjunto de códigos que realmente denota es un cómputo, y uno costoso. Ese es el trabajo que $expand realiza en cada llamada. Para que un conjunto de valores sea utilizable desde un JOIN de SQL, esa expansión debe materializarse y mantenerse actualizada a medida que llegan nuevas versiones.

Esa es la pieza que estamos construyendo: expansiones materializadas en el lakehouse, documentadas y suficientemente estables para construir pipelines sobre ellas. Una definición autoritativa, accesible de dos formas: $expand desde la aplicación, un JOIN desde el notebook. Ejecutarse sobre Lakebase es el requisito previo.

Cómo ejecutarlo

Termbox se conecta a Lakebase como una service principal de Databricks, utilizando credenciales de base de datos de corta duración emitidas por OAuth. Termbox resuelve la credencial, la almacena en caché y la renueva de forma transparente antes de que expire. No existe ninguna contraseña de base de datos de larga duración almacenada en la configuración de su servicio de terminología.

La configuración completa está disponible en la documentación de Termbox. Para probarlo, puede obtener una licencia de desarrollo gratuita en un par de clics.