Qué significa realmente construir una capa Gold de datos clínicos (y por qué el modelo técnico no es la parte difícil)

En un proyecto de evolución de una plataforma de datos sanitaria, participé en la construcción de uno de los primeros datasets pensados para formar parte de la capa semántica: la capa "Gold" que los usuarios de negocio iban a poder consultar directamente, sin pasar por el equipo técnico.

El modelo estaba bien construido. Los campos reflejaban con precisión los sistemas de origen, las transformaciones eran correctas, la lógica de negocio estaba bien aplicada.

Y aun así, cuando lo pusimos delante de los usuarios que tenían que utilizarlo, no se enteraban de qué era cada cosa.

Los nombres de los campos arrastraban la terminología técnica de los sistemas de origen: abreviaturas, convenciones internas, nombres que tenían sentido para quien había construido el pipeline pero ninguno para quien solo quería consultar un dato clínico. Hubo que volver atrás y renombrar buena parte del dataset, esta vez pensando en quien lo iba a leer, no en quien lo había construido.

Nada de eso apareció en ningún documento de arquitectura. No hubo ningún error técnico que corregir. El dataset era correcto desde el primer día. Lo que faltaba no era exactitud, era legibilidad.

La parte del trabajo que no sale en el diagrama de arquitectura

Cuando se habla de construir una capa semántica común —lo que en el post anterior llamábamos "un sitio donde vive el significado del dato"— es fácil imaginar el resultado como un ejercicio de modelado: definir entidades, relaciones, nombres de campos, tipos de dato.

Esa parte es necesaria, pero no es la que determina si la capa semántica funciona.

Lo que la determina es si alguien que no participó en construirla puede mirarla y entender, sin ayuda, qué representa cada dato. Si no puede, esa capa no cumple su función, por muy bien modelada que esté. La gente que necesita el dato no va a aprender la terminología interna del equipo de datos. Va a evitar esa capa y va a construir su propia versión del dato en otro sitio, con sus propias definiciones.

Y eso nos devuelve exactamente al problema del post anterior: cuantas más versiones distintas de "lo mismo" conviven en una organización, menos fiable es cualquier etiqueta de calidad que se ponga encima.

Legibilidad no es lo mismo que documentación

Un error habitual es pensar que este problema se resuelve documentando el dataset: un diccionario de datos, una wiki, un catálogo con descripciones. Ayuda, pero no es lo mismo.

La documentación es algo que alguien tiene que ir a buscar cuando ya sospecha que no entiende algo. La legibilidad es que no tenga que sospechar nada, porque el propio dato ya se explica por sí mismo la primera vez que lo ve.

Diseñar para legibilidad implica decisiones que no son puramente técnicas: qué nombre usar cuando hay varias formas correctas de llamar a algo, cuánto contexto clínico incluir en la propia estructura del dato, qué nivel de agregación tiene sentido para quien lo va a consultar. Son decisiones de producto, aunque el resultado sea una tabla en un lakehouse.

Por qué esto también es un problema del EHDS

Las obligaciones del EHDS sobre describir datasets y etiquetar su calidad asumen, de nuevo, que hay alguien capaz de mirar ese dataset —muchas veces alguien externo a la organización que lo generó, en otro país, con otro idioma de trabajo— y entender qué representa. Si la legibilidad no formaba parte del diseño desde el principio, esa descripción se convierte en un ejercicio de traducción a posteriori, hecho deprisa y con las mismas ambigüedades que el propio dataset ya tenía puertas adentro.

Construir esa legibilidad desde el principio es mucho más barato que reconstruirla cuando ya hay una fecha límite regulatoria encima.

Cómo saber si tu organización tiene este problema

Esta es exactamente la pregunta que reviso en el Diagnóstico de Datos Clínicos: no solo si existe un modelo semántico, sino si ese modelo es legible para quien tiene que usarlo sin depender de quien lo construyó. Es una diferencia que rara vez se ve en un diagrama de arquitectura, y que casi siempre determina si una plataforma de datos termina adoptándose o termina esquivada por sus propios usuarios.