1. INTRODUCCIÓN

La actividad sanitaria genera datos de forma continua: identificación de personas usuarias, citas, consultas, diagnósticos, procedimientos, prescripciones, dispensaciones, resultados clínicos, episodios hospitalarios, actividad de urgencias, utilización de recursos, costes, plantillas, contratación y múltiples indicadores de calidad. Sin una arquitectura corporativa, estos datos permanecen fragmentados en aplicaciones operacionales y resultan difíciles de comparar. La gestión de los datos corporativos persigue convertir ese conjunto heterogéneo en un activo gobernado, comprensible y reutilizable para la asistencia, la gestión, la planificación, la salud pública y la investigación.

El dato operacional se crea para ejecutar un proceso concreto. Una aplicación de citación debe reservar una agenda; una historia clínica debe registrar la asistencia; un sistema de farmacia debe gestionar la prescripción o la dispensación. Estos sistemas se optimizan para registrar transacciones correctas, concurrentes y rápidas. Sin embargo, la dirección de un centro puede necesitar responder a preguntas distintas: cómo evoluciona una lista de espera, qué factores explican una readmisión, dónde se concentra el consumo de un recurso, cuál es la prevalencia estimada de una patología o qué población presenta mayor riesgo. Para contestarlas es necesario integrar historia, contexto, calidad y significado.

El tema reúne tecnologías de varias generaciones que no deben estudiarse como compartimentos estancos. El data warehouse integra y conserva información histórica; los data marts ofrecen visiones analíticas por dominio; OLAP permite navegar por dimensiones y niveles de agregación; la minería de datos descubre patrones; las plataformas Big Data distribuyen almacenamiento y cálculo; los sistemas de soporte a la decisión convierten análisis en recomendaciones; y los cuadros de mando presentan indicadores para facilitar el control y la decisión.

La arquitectura tecnológica solo produce valor cuando se apoya en gobierno del dato. Un indicador sin definición, un código sin terminología común, una dimensión temporal mal construida o un proceso de carga sin trazabilidad pueden generar conclusiones formalmente precisas pero materialmente falsas. Por eso son esenciales los diccionarios de recursos de información, los catálogos de datos, los metadatos, la calidad, el linaje, la seguridad, la gestión de accesos y la asignación de responsables.

2. GESTIÓN DEL DATO CORPORATIVO Y GOBIERNO DEL DATO

2.1. Del dato al activo de información

Un dato es una representación de un hecho; la información aparece cuando ese dato se interpreta dentro de un contexto y con una semántica conocida. La gestión corporativa abarca todo su ciclo de vida: creación o captura, validación, integración, almacenamiento, uso, intercambio, conservación y eliminación. Cada fase debe tener reglas, responsables y evidencias de control. La organización necesita saber quién produce el dato, quién puede modificarlo, qué significado tiene, con qué frecuencia se actualiza y para qué finalidades puede utilizarse.

En una organización sanitaria, el mismo concepto puede aparecer con nombres, códigos y granularidades distintas. Un centro puede identificarse mediante un código local, un código corporativo o un código de directorio administrativo; una fecha puede representar solicitud, prestación, registro o alta; un «paciente activo» puede definirse por adscripción, contacto asistencial o ventana temporal. La integración no consiste en copiar columnas, sino en resolver esas diferencias mediante modelos canónicos, reglas de correspondencia y dimensiones conformadas.

2.2. Roles y responsabilidades

El gobierno del dato distribuye responsabilidades. El propietario del dato o data owner responde por su definición y uso dentro de un dominio; el responsable operativo o data steward mantiene reglas, calidad y metadatos; los equipos TIC implantan plataformas y controles; los responsables de seguridad y protección de datos supervisan riesgos y legitimidad; y los usuarios analíticos deben interpretar el dato conforme a su definición. Esta separación evita que la tecnología decida por sí sola el significado de la información.

Un modelo de gobierno eficaz dispone de un catálogo de dominios —persona usuaria, asistencia, profesional, centro, prestación, recurso, financiación—, un inventario de activos, políticas de calidad, procedimientos de resolución de incidencias y órganos de decisión. La administración debe distinguir los datos maestros, los datos de referencia, los datos transaccionales y los datos analíticos. Los datos maestros describen entidades relativamente estables; los datos de referencia contienen códigos y clasificaciones; los datos transaccionales registran hechos operativos; y los datos analíticos son datos integrados, historificados o agregados.

2.3. Calidad de datos

La calidad es multidimensional. La exactitud mide la correspondencia con la realidad; la completitud, la presencia de valores necesarios; la consistencia, la ausencia de contradicciones; la validez, el cumplimiento de formatos, dominios y reglas; la unicidad, la ausencia de duplicados; y la oportunidad, la disponibilidad dentro del plazo requerido. Un dato puede ser técnicamente válido y, sin embargo, no ser oportuno para una decisión operativa.

Las reglas de calidad deben expresarse de forma verificable. Por ejemplo: «la fecha de alta no puede preceder a la de ingreso», «todo episodio debe estar asociado a un centro válido en la fecha del hecho» o «el código diagnóstico debe pertenecer a la versión de la clasificación definida para el periodo». Las métricas de calidad se calculan, se publican y se vinculan con responsables y planes de corrección. La depuración en el data warehouse no sustituye la mejora en origen: si un defecto se corrige únicamente al cargar, el sistema operacional seguirá produciendo datos defectuosos.

3. ALMACÉN DE DATOS: DATA WAREHOUSE Y DATA MART

3.1. Concepto y Características del Data Warehouse

Un Data Warehouse (DW) es un repositorio analítico integrado, de alcance corporativo o de dominio, que consolida datos procedentes de múltiples fuentes para soportar análisis y toma de decisiones. La integración es lógica y semántica: un DW puede desplegarse físicamente en uno o varios sistemas, por lo que «corporativo» no equivale necesariamente a «una única base de datos». Bill Inmon, considerado el padre del concepto, lo definió como «una colección de datos orientada a temas, integrada, no volátil y variante en el tiempo, que ayuda a la toma de decisiones gerenciales». Esta definición encapsula las cuatro características fundamentales que distinguen un data warehouse de bases de datos operacionales tradicionales.

Orientado a Temas: Los datos se organizan alrededor de temas de negocio relevantes (pacientes, tratamientos, recursos hospitalarios) en lugar de procesos transaccionales. Por ejemplo, en un contexto sanitario, toda la información relacionada con un paciente se integra desde múltiples sistemas: historia clínica, farmacia, laboratorio, admisiones.

Integrado: Los datos de fuentes dispares se consolidan aplicando reglas de transformación consistentes, resolución de conflictos de nomenclatura, estandarización de formatos y limpieza de inconsistencias. Un data warehouse asegura que «médico» en un sistema y «facultativo» en otro se refieran a la misma entidad.

No volátil: el almacén está orientado a consulta y análisis, no a la actualización transaccional continua propia de OLTP. Las cargas, correcciones, reprocesos y políticas de retención pueden modificar físicamente el repositorio, pero deben hacerse de forma controlada y trazable, preservando la interpretación histórica. La idea de examen es estabilidad analítica, no «inmutabilidad absoluta».

Variante en el Tiempo: Todos los datos incluyen una dimensión temporal explícita, permitiendo análisis de tendencias, comparaciones interanuales y estudios longitudinales. En sanidad, esto permite seguir la evolución de indicadores epidemiológicos o patrones de utilización de servicios.

3.2. Data Marts: Especializaciones Departamentales

Un Data Mart es un subconjunto focalizado del data warehouse, orientado a las necesidades analíticas específicas de un departamento o área funcional. Mientras que el data warehouse corporativo es amplio y abarca toda la organización, un data mart es estrecho y profundo, optimizado para un dominio particular. En el SAS, podrían existir data marts especializados para atención primaria, hospitalaria, salud pública, farmacia, o gestión de recursos humanos sanitarios.

3.3. Modelado Dimensional: Esquemas Estrella y Copo de Nieve

El modelado dimensional, popularizado por Ralph Kimball, es el paradigma predominante para diseñar data warehouses orientados a consultas analíticas. A diferencia del modelado relacional normalizado usado en bases de datos OLTP, el modelado dimensional prioriza la simplicidad de consulta y el rendimiento de lectura sobre la minimización de redundancia.

Esquema Estrella (Star Schema)

El esquema estrella consiste en una tabla de hechos central rodeada de tablas de dimensiones desnormalizadas. La tabla de hechos contiene métricas numéricas (medidas) y claves foráneas que referencian las dimensiones. Las dimensiones contienen atributos descriptivos que proporcionan contexto para analizar los hechos. Por ejemplo, una tabla de hechos «Consultas_Médicas» podría tener medidas como duración_consulta, coste, y dimensiones como Paciente, Médico, Fecha, Centro_Salud, Diagnóstico.

Las ventajas del esquema estrella incluyen consultas simples de entender (joins directos entre hechos y dimensiones), excelente rendimiento (menos joins), y compatibilidad óptima con herramientas OLAP. La redundancia en dimensiones desnormalizadas se considera aceptable dado el contexto de solo lectura y el beneficio en velocidad de consulta.

Esquema Copo de Nieve (Snowflake Schema)

El esquema copo de nieve normaliza las tablas de dimensiones, creando jerarquías dimensionales explícitas. Por ejemplo, la dimensión Centro_Salud podría normalizarse en Centro_Salud → Distrito_Sanitario → Área_Gestión_Sanitaria → Provincia. Esto reduce redundancia y espacio de almacenamiento, pero incrementa la complejidad de consultas (más joins) y puede degradar el rendimiento. Se utiliza cuando el ahorro de espacio es crítico o las dimensiones son extremadamente grandes.

Esquema Constelación (Constellation o Galaxy Schema)

Un esquema constelación contiene múltiples tablas de hechos que comparten algunas dimensiones conformadas. Por ejemplo, «Ingresos_Hospitalarios» y «Urgencias» podrían compartir dimensiones Paciente, Fecha, y Centro, pero tener dimensiones específicas adicionales. Este es el patrón más común en data warehouses empresariales reales.

3.4. Procesos ETL y ELT Modernos

ETL (Extract, Transform, Load) es el conjunto de procesos que alimentan un data warehouse. Extract obtiene datos de sistemas fuente diversos (bases de datos operacionales, archivos, APIs, streams). Transform aplica limpiezas, conversiones de formato, cálculos, agregaciones, y resolución de conflictos. Load inserta los datos transformados en el data warehouse.

El enfoque tradicional ETL ejecuta transformaciones en un servidor de procesamiento intermedio antes de cargar al destino. ELT (Extract, Load, Transform) invierte el orden: carga primero los datos en bruto en el destino (típicamente un data lake o warehouse en la nube con gran capacidad de procesamiento), y ejecuta transformaciones in situ aprovechando el poder computacional del destino. ELT se ha extendido en plataformas analíticas capaces de ejecutar transformaciones de forma paralela en el propio destino, especialmente cuando almacenamiento y cómputo pueden escalar de manera independiente.

Las herramientas de integración pueden cubrir extracción, replicación, orquestación, transformación, calidad y observabilidad. Apache NiFi es un ejemplo de orquestación de flujos; Airbyte ilustra la replicación mediante conectores; y dbt aplica transformaciones SQL declarativas con pruebas y documentación. En oposición interesa sobre todo distinguir el patrón ETL/ELT de un producto concreto, porque las herramientas cambian con rapidez.

3.5. Data Lakes: Complemento al Data Warehouse

Un data lake es un repositorio centralizado que almacena datos estructurados, semi-estructurados y no estructurados en su formato original (en bruto), a cualquier escala. A diferencia del data warehouse que requiere esquema predefinido (esquema en escritura), el data lake aplica esquema en tiempo de lectura (esquema en lectura), proporcionando máxima flexibilidad. Los data lakes típicamente se implementan sobre almacenamiento de objetos distribuido como AWS S3, Azure Data Lake Storage, o Google Cloud Storage.

La arquitectura moderna tiende hacia un enfoque híbrido «lakehouse» que combina la flexibilidad y escalabilidad de data lakes con las capacidades de gestión transaccional, rendimiento de consulta y gobernanza de data warehouses. Tecnologías como Delta Lake, Apache Iceberg y Apache Hudi proporcionan capacidades ACID sobre data lakes.

3.6. Granularidad, medidas y dimensiones lentamente cambiantes

La primera decisión de una tabla de hechos es su grano: qué representa exactamente cada fila. Puede ser una consulta, un episodio, una dispensación, una persona por mes o un saldo diario. Todas las medidas de la tabla deben corresponder al mismo nivel de detalle. Mezclar en una misma tabla hechos de distinta granularidad provoca duplicidades y agregaciones incorrectas.

Las medidas pueden ser aditivas, semiaditivas o no aditivas. Un número de consultas puede sumarse por centro y por tiempo; un saldo de camas puede agregarse entre centros, pero no sumarse sin más a lo largo del tiempo; un porcentaje o una media no debe agregarse sumando valores ya calculados, sino reconstruyendo numerador y denominador. Esta distinción es especialmente importante en cuadros de mando sanitarios.

Las dimensiones cambian. Un profesional cambia de unidad, un centro se reorganiza o una persona cambia de zona de residencia. Las slowly changing dimensions ofrecen estrategias para conservar el historial. El tipo 1 sobrescribe el valor anterior y no conserva historia; el tipo 2 crea una nueva versión con fechas de vigencia; y el tipo 3 conserva un número limitado de valores anteriores. En análisis longitudinales, el tipo 2 suele ser necesario para reconstruir el contexto existente cuando ocurrió el hecho.

4. ARQUITECTURA OLAP

4.1. OLAP vs OLTP: Paradigmas Complementarios

OLTP (Online Transaction Processing) y OLAP (Online Analytical Processing) representan dos paradigmas fundamentalmente diferentes de procesamiento de datos, cada uno optimizado para cargas de trabajo distintas que coexisten en las organizaciones modernas.

4.2. Cubos Multidimensionales: Fundamento de OLAP

La metáfora central de OLAP es el cubo multidimensional (hipercubo). Mientras que una tabla relacional tradicional es bidimensional (filas y columnas), un cubo OLAP organiza datos en múltiples dimensiones simultáneamente. Por ejemplo, un cubo de análisis de consultas médicas podría tener dimensiones: Tiempo (año, trimestre, mes, día), Geografía (provincia, área sanitaria, distrito, centro), Especialidad (grupo, especialidad, subespecialidad), y Paciente (grupo edad, sexo, zona básica salud). Las celdas del cubo contienen medidas agregadas como número de consultas, tiempo medio de espera, o coste total.

Esta organización multidimensional permite a los usuarios «navegar» los datos intuitivamente mediante operaciones OLAP: Slice (seleccionar un único valor en una dimensión, reduciendo dimensionalidad), Dice (seleccionar rangos en múltiples dimensiones, creando sub-cubos), Drill-down (navegar de nivel agregado a detalle, ej: Año → Trimestre → Mes), Drill-up/Roll-up (agregar detalle hacia niveles superiores), Pivot/Rotate (reorientar el cubo para ver diferentes perspectivas).

4.3. Tipos de Implementación OLAP

MOLAP – Multidimensional OLAP

MOLAP almacena datos en estructuras multidimensionales propietarias optimizadas, precalculando y materializando agregaciones. Los datos se extraen del data warehouse relacional y se cargan en arrays multidimensionales densos o sparse. Ventajas: rendimiento de consulta extremadamente rápido (acceso directo a celdas precalculadas), análisis complejo eficiente. Desventajas: limitaciones de escalabilidad (cubos muy grandes o con alta dimensionalidad pueden ser inmanejables), procesos de carga pueden ser lentos, tecnología propietaria. Productos: Microsoft Analysis Services (SSAS en modo MOLAP), Oracle Essbase, IBM Cognos TM1.

ROLAP – Relational OLAP

ROLAP opera directamente sobre el data warehouse relacional existente, traduciendo dinámicamente operaciones OLAP en consultas SQL complejas. No requiere copiar datos a estructuras propietarias. Ventajas: aprovecha la escalabilidad y el ecosistema SQL del SGBD relacional y evita mantener una copia multidimensional propietaria. Desventajas: las consultas complejas pueden exigir índices, particionado, almacenamiento columnar, agregados y vistas materializadas para alcanzar tiempos interactivos; su rendimiento depende del motor y del diseño físico.

HOLAP – Hybrid OLAP

HOLAP combina lo mejor de MOLAP y ROLAP: almacena agregaciones precalculadas en estructuras multidimensionales para consultas frecuentes de alto nivel, mientras mantiene datos detallados en el RDBMS relacional accesible bajo demanda. Proporciona balance entre rendimiento y escalabilidad. Microsoft SSAS soporta modo HOLAP.

4.4. Operaciones de navegación multidimensional

Las operaciones OLAP permiten cambiar la perspectiva sin modificar el dato de origen. Roll-up asciende en una jerarquía y agrega, por ejemplo, de día a mes o de centro a distrito. Drill-down desciende hacia mayor detalle. Slice fija un valor de una dimensión y obtiene una sección del cubo; dice selecciona un subconjunto definido por varios valores o rangos; y pivot rota ejes para presentar otra vista.

Una jerarquía temporal debe estar definida con cuidado. Día, mes, trimestre y año forman rutas de agregación habituales, pero semana y mes no componen una jerarquía estricta porque una semana puede atravesar dos meses. Los calendarios corporativos deben explicitar calendario natural, fiscal, epidemiológico o laboral. La semántica de la dimensión es tan importante como la estructura técnica.

4.5. Agregaciones, almacenamiento y rendimiento

MOLAP materializa estructuras multidimensionales y agregados; ROLAP traduce la consulta analítica a SQL sobre tablas relacionales; HOLAP combina agregados multidimensionales con detalle relacional. Las soluciones de tiempo real o real-time OLAP reducen la latencia entre el hecho y su disponibilidad analítica, pero no deben confundirse con HOLAP: una denominación describe la estrategia de almacenamiento y la otra el requisito de actualización.

El rendimiento depende del particionado, índices, almacenamiento columnar, compresión, agregados materializados, cachés y optimización de consultas. El diseño debe equilibrar latencia de carga, frescura, coste y tiempo de respuesta. Una actualización inmediata no es siempre mejor: un indicador estratégico puede ser diario o mensual, mientras que una alerta operativa puede necesitar minutos.

5. MINERÍA DE DATOS

5.1. Proceso KDD: Knowledge Discovery in Databases

La minería de datos (data mining) es el núcleo del proceso más amplio de Descubrimiento de Conocimiento en Bases de Datos (KDD – Knowledge Discovery in Databases). El proceso KDD comprende las siguientes fases iterativas:

1. Comprensión del Dominio: Identificar objetivos del análisis desde perspectiva de negocio, entender el contexto del problema.
2. Selección: Identificar y extraer datasets relevantes desde repositorios corporativos.
3. Preprocesamiento: Limpiar datos (manejar valores faltantes, outliers, inconsistencias), integrar múltiples fuentes, realizar muestreo si necesario.
4. Transformación: Aplicar reducción de dimensionalidad, normalización, discretización, creación de atributos derivados (feature engineering).
5. Minería de Datos: Aplicar algoritmos de aprendizaje automático para descubrir patrones: clasificación, clustering, asociación, regresión.
6. Evaluación: Interpretar patrones descubiertos, evaluar calidad y relevancia, validar mediante métricas apropiadas.
7. Consolidación del Conocimiento: Integrar conocimiento descubierto en sistemas de soporte a decisiones, documentar hallazgos, establecer procesos de actualización.

5.2. Técnicas y Algoritmos Principales

Clasificación

Predecir la clase o categoría de instancias basándose en atributos conocidos. En sanidad: predecir riesgo de readmisión hospitalaria, diagnosticar enfermedades basándose en síntomas y pruebas, estratificar pacientes por riesgo. Algoritmos populares: árboles de decisión (C4.5, CART), Random Forests (ensambles de árboles), Support Vector Machines (SVM), redes neuronales profundas, Naive Bayes, k-Nearest Neighbors (k-NN).

Clustering (Agrupamiento)

Agrupar instancias similares sin etiquetas predefinidas (aprendizaje no supervisado). Aplicaciones sanitarias: segmentación de pacientes en grupos homogéneos para medicina personalizada, identificación de patrones epidemiológicos geográficos, descubrir subtipos de enfermedades. Algoritmos: k-means (particionamiento), clustering jerárquico (aglomerativo/divisivo), DBSCAN (basado en densidad), Gaussian Mixture Models.

Reglas de Asociación

Descubrir relaciones frecuentes entre items en grandes datasets transaccionales. Originalmente para análisis de cesta de compra, en sanidad: identificar comorbilidades frecuentes, asociaciones entre medicamentos y efectos adversos, patrones de prescripción. El algoritmo Apriori y sus variantes (FP-Growth) buscan itemsets frecuentes y generan reglas con métricas de soporte (frecuencia) y confianza (probabilidad condicional).

Regresión

Predecir valores numéricos continuos. Aplicaciones: estimar duración de estancia hospitalaria, predecir demanda de servicios sanitarios, modelar evolución de indicadores de salud. Técnicas: regresión lineal/múltiple, regresión polinomial, regresión logística (para probabilidades), LASSO/Ridge para regularización.

Detección de Anomalías

Identificar instancias que se desvían significativamente de la norma. Crítico en sanidad para detección de fraude en facturación, identificación de eventos adversos raros, alertas tempranas de brotes epidémicos. Métodos: modelos estadísticos (z-score, IQR), Isolation Forests, autoencoders neuronales, One-Class SVM.

5.3. Herramientas de Minería de Datos

Plataformas Visuales: RapidMiner, KNIME Analytics Platform, Orange Data Mining ofrecen interfaces visuales drag-and-drop para diseñar flujos de minería de datos, ideal para analistas sin programación extensiva. Incluyen conectores a múltiples fuentes, cientos de algoritmos preimplementados, y capacidades de automatización y deployment.

Programación Estadística: Python con bibliotecas scikit-learn (algoritmos ML), pandas (manipulación datos), NumPy/SciPy (computación numérica), matplotlib/seaborn (visualización), se ha convertido en el estándar de facto. R ofrece capacidades estadísticas avanzadas y paquetes especializados (caret, randomForest, e1071). Jupyter Notebooks proporcionan entornos interactivos excelentes para experimentación y documentación reproducible.

Plataformas Enterprise: SAS Enterprise Miner, IBM SPSS Modeler, Microsoft Azure Machine Learning Studio ofrecen soluciones integradas end-to-end con gobernanza, seguridad y escalabilidad empresarial.

5.4. CRISP-DM y evaluación del modelo

CRISP-DM organiza el proyecto en comprensión del negocio, comprensión de los datos, preparación, modelado, evaluación y despliegue. El proceso es iterativo: un resultado técnicamente correcto puede obligar a revisar la pregunta inicial o la calidad de las variables. En sanidad, la fase de comprensión del negocio debe incorporar el contexto clínico, los sesgos de selección y las consecuencias de los errores.

La evaluación no se limita a la exactitud global. En clasificación se utilizan sensibilidad, especificidad, precisión, valor predictivo, matriz de confusión y área bajo la curva, según el problema. Con clases desequilibradas, una exactitud elevada puede ocultar que el modelo no identifica casos relevantes. También deben comprobarse calibración, estabilidad temporal, explicabilidad y rendimiento en subgrupos.

La asociación estadística no implica causalidad. Un algoritmo puede detectar correlaciones útiles para predicción sin demostrar que una variable cause el resultado. La decisión sanitaria requiere distinguir analítica descriptiva, predictiva y causal, y someter los resultados a validación profesional, metodológica y ética.

5.5. Despliegue y vigilancia

Un modelo desplegado debe versionarse junto con datos, variables, parámetros y código. Se monitorizan deriva de datos, deriva de concepto, pérdida de rendimiento y cambios organizativos. Si cambia una codificación, una práctica clínica o la población atendida, el modelo puede dejar de ser válido aunque el software siga funcionando. La minería de datos es, por tanto, un proceso de ciclo de vida y no una ejecución aislada.

6. BIG DATA Y ARQUITECTURAS DISTRIBUIDAS

6.1. Definición y las 5 V’s del Big Data

Big Data se refiere a conjuntos de datos cuyo volumen, velocidad de generación, y variedad exceden la capacidad de herramientas tradicionales de procesamiento de datos. Las «5 V’s» caracterizan los desafíos y oportunidades:

• Volumen: Escala masiva de datos (terabytes a petabytes). En sanidad: imágenes médicas de alta resolución, datos genómicos, registros electrónicos de millones de pacientes, datos de wearables y sensores IoMT (Internet of Medical Things).
• Velocidad: Generación y procesamiento en tiempo real o tiempo casi real. Streams de dispositivos médicos de monitorización continua, flujos de datos de emergencias, feeds de redes sociales para vigilancia epidemiológica.
• Variedad: Datos estructurados (bases de datos), semi-estructurados (JSON, XML, logs), no estructurados (texto libre, imágenes, audio, video). Historias clínicas narrativas, radiografías, resultados de laboratorio, facturas, quejas de pacientes.
• Veracidad: Incertidumbre y calidad de datos. Datos incompletos, ruidosos, inconsistentes o fraudulentos. Es crítica en decisiones sanitarias, donde los errores pueden tener consecuencias graves.
• Valor: Transformar datos en insights accionables. El objetivo último: extraer valor de negocio (en sanidad: mejorar resultados clínicos, eficiencia operacional, investigación).

6.2. Arquitectura Big Data: Componentes Principales

Una arquitectura Big Data típica incluye capas para ingesta, almacenamiento, procesamiento, análisis y visualización:

Capa de Ingesta: Captura datos desde fuentes diversas. En ingesta por lotes pueden utilizarse conectores, exportaciones o transferencias programadas; históricamente Apache Sqoop se utilizó para mover datos entre Hadoop y SGBD relacionales, aunque hoy es un proyecto retirado. Para eventos y flujos se emplean plataformas como Apache Kafka, y Apache NiFi puede orquestar movimientos y transformaciones.

Capa de Almacenamiento: Data Lakes sobre sistemas de archivos distribuidos (HDFS y almacenamiento de objetos) almacenan datos en bruto en formato original. Bases de datos NoSQL (HBase columnar, MongoDB documental, Cassandra de columnas anchas distribuida) para acceso operacional a grandes volúmenes.

Capa de Procesamiento: Frameworks para procesamiento distribuido masivamente paralelo. Hadoop MapReduce (batch tradicional), Apache Spark (in-memory, batch y streaming), Apache Flink (streaming de baja latencia), Presto/Trino (queries SQL interactivas sobre data lakes).

Capa de Análisis: Herramientas para extraer insights. Notebooks interactivos (Jupyter, Zeppelin), plataformas ML (TensorFlow, PyTorch, H2O.ai), motores SQL (Hive, Impala, Presto).

Capa de Visualización: Dashboards y reporting. herramientas corporativas de BI y visualización consumen datos procesados y permiten exploración interactiva.

6.3. Procesamiento por lotes, flujos y arquitecturas híbridas

El procesamiento por lotes opera sobre conjuntos delimitados y resulta adecuado para cierres diarios, reconstrucciones históricas o cálculos intensivos. El procesamiento de flujos trata eventos conforme llegan y permite reducir latencia. No todo flujo exige respuesta instantánea: se usan ventanas temporales, marcas de agua y tolerancia a eventos retrasados para producir resultados coherentes.

La arquitectura Lambda separa una capa batch que reconstruye resultados completos y una capa de velocidad que aporta baja latencia; la arquitectura Kappa simplifica el modelo alrededor de un registro de eventos y reprocesamiento del flujo. Son patrones conceptuales, no productos. La elección depende de volumen, latencia, complejidad operativa, necesidad de reproceso y capacidad del equipo.

6.4. Data lake, lakehouse y formatos analíticos

Un data lake almacena datos con menor transformación inicial y admite estructura diversa. Su flexibilidad puede degenerar en un «pantano de datos» si no hay catálogo, calidad, políticas de ciclo de vida y control de accesos. El lakehouse intenta combinar almacenamiento de objetos y formatos abiertos con transacciones, esquema, versionado y rendimiento analítico. Apache Parquet y ORC son formatos columnares habituales; Apache Iceberg, Delta Lake y Apache Hudi aportan gestión tabular sobre almacenamiento distribuido.

Big Data no se define exclusivamente por petabytes. Una carga puede requerir técnicas distribuidas por velocidad, variedad o complejidad aunque el volumen sea menor. A la inversa, un gran volumen estable y estructurado puede resolverse con un SGBD analítico convencional. La arquitectura debe responder al problema, no a una etiqueta comercial.

7. ENTORNOS HADOOP, SPARK Y TECNOLOGÍAS SIMILARES

7.1. Arquitectura de Apache Hadoop

Apache Hadoop es un marco de software para almacenamiento y procesamiento distribuido de grandes conjuntos de datos. Su diseño asume que los fallos de nodos son normales y que el sistema debe detectarlos y recuperarse. La arquitectura desplaza el cálculo hacia los datos cuando resulta conveniente y prioriza el rendimiento agregado sobre el acceso interactivo de baja latencia.

Hadoop Common reúne bibliotecas y utilidades compartidas. HDFS es el sistema de archivos distribuido; YARN gestiona recursos y ejecución; y MapReduce es un modelo y motor de procesamiento paralelo sobre YARN. Estos módulos deben distinguirse de herramientas del ecosistema, como Hive, HBase o Spark.

7.2. HDFS

HDFS divide los archivos en bloques configurables y distribuye sus réplicas entre DataNodes. El NameNode mantiene el espacio de nombres, la jerarquía de directorios y la ubicación lógica de los bloques; los DataNodes almacenan y sirven los bloques. Los clientes consultan metadatos al NameNode y transfieren datos directamente con los DataNodes.

HDFS está orientado a archivos grandes y acceso secuencial de alto rendimiento. No pretende ser un sistema POSIX de propósito general ni optimiza millones de escrituras pequeñas y aleatorias. La replicación y la alta disponibilidad son mecanismos distintos: la primera protege bloques frente al fallo de nodos de datos; la segunda protege el servicio de metadatos mediante NameNodes redundantes y coordinación de estados.

7.3. YARN y MapReduce

YARN separa la gestión global de recursos de la coordinación de cada aplicación. ResourceManager arbitra recursos del clúster; NodeManager administra contenedores en cada nodo; y ApplicationMaster coordina la ejecución de una aplicación. Esta arquitectura permite ejecutar diferentes motores distribuidos sobre un mismo conjunto de recursos.

MapReduce divide un trabajo en fases de mapa, intercambio y reducción. La fase map transforma particiones de entrada; el shuffle agrupa datos por clave; y la fase reduce produce agregados o salidas. Sigue siendo útil para procesamiento por lotes robusto, aunque muchas cargas interactivas e iterativas se implementan hoy con motores de más alto nivel.

7.4. Spark y tecnologías similares

Apache Spark es un motor multilenguaje para ingeniería de datos, SQL, ciencia de datos y aprendizaje automático. Sus DataFrames y Spark SQL permiten optimizar planes de consulta; los RDD proporcionan una abstracción distribuida tolerante a fallos; y Structured Streaming aplica un modelo declarativo a flujos de datos. Spark utiliza memoria y disco según el plan, la persistencia y los recursos: describirlo simplemente como «procesamiento en RAM» es incompleto.

Spark puede ejecutarse en modo autónomo, sobre YARN o sobre Kubernetes. Puede leer y escribir HDFS, almacenamiento de objetos, bases de datos y formatos como Parquet, ORC, JSON o CSV. Apache Flink se orienta especialmente al procesamiento con estado de flujos; Trino proporciona consultas SQL distribuidas; Hive aporta una capa SQL y metadatos; HBase ofrece acceso distribuido a datos por clave y familia de columnas. Cada componente resuelve un problema diferente.

7.5. Componentes nucleares y ejecución

Para un clúster Hadoop básico se ponen en servicio HDFS y YARN. Los scripts de administración dependen de la instalación y deben ejecutarse con la configuración y permisos adecuados. En producción, el arranque se integra con gestores de servicios, autenticación, alta disponibilidad, monitorización y procedimientos operativos.

start-dfs.sh
start-yarn.sh
hdfs dfs -ls /
yarn application -list

Los comandos ilustran el inicio de los servicios, la consulta del espacio de nombres distribuido y la enumeración de aplicaciones. No sustituyen el diseño de seguridad ni la operación controlada del clúster.

7.6. Spark y acceso a HDFS

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("actividad_sanitaria").getOrCreate()
df = spark.read.parquet("hdfs:///datos/actividad/")
resultado = df.groupBy("centro", "mes").count()
resultado.write.mode("overwrite").parquet("hdfs:///resultados/actividad_mensual/")

El ejemplo muestra lectura y escritura en HDFS mediante DataFrames. En un sistema real se añadirían esquema, validación, particionado, control de errores, catálogo, seguridad y trazabilidad.

8. SISTEMAS DE SOPORTE A LA DECISIÓN

8.1. Concepto y Componentes de un DSS

Un Sistema de Soporte a la Decisión (Decision Support System – DSS) es un sistema de información interactivo que utiliza modelos, datos y conocimiento para ayudar a decidores a resolver problemas semi-estructurados o no estructurados. A diferencia de sistemas transaccionales que automatizan procesos repetitivos, los DSS aumentan y complementan el juicio humano en decisiones complejas que requieren análisis, evaluación de alternativas y consideración de múltiples criterios.

Los componentes fundamentales de un DSS incluyen: Base de Datos: Repositorio integrado con datos internos (transaccionales, históricos) y externos (benchmarks, indicadores sectoriales, datos públicos). Base de Modelos: Colección de modelos analíticos, estadísticos, de optimización, simulación que procesan datos. Motor de Inferencia/Razonamiento: En DSS basados en conocimiento, reglas que emulan razonamiento experto. Interfaz de Usuario: Dashboards, visualizaciones, capacidades de what-if analysis que permiten interacción intuitiva.

8.2. Tipos de Sistemas de Soporte a la Decisión

DSS Orientados a Datos (Data-Driven): Enfatizan acceso y manipulación de grandes volúmenes de datos estructurados. Data warehouses, OLAP, queries ad-hoc. Ayudan a identificar patrones, tendencias, excepciones. En sanidad: análisis de listas de espera, utilización de recursos, comparación de centros.

DSS Orientados a Modelos (Model-Driven): Usan modelos cuantitativos (optimización, simulación, estadística) para análisis prescriptivo y predictivo. Optimización de rutas de ambulancias, dimensionamiento de plantillas, simulación de flujos de pacientes, planificación de quirófanos.

DSS Basados en Conocimiento (Knowledge-Driven): Incorporan expertise especializado mediante reglas, razonamiento basado en casos, redes bayesianas. Sistemas de soporte a diagnóstico clínico, prescripción inteligente que alerta interacciones medicamentosas.

DSS Orientados a Comunicación (Communication-Driven): Facilitan colaboración entre múltiples participantes en decisiones. Groupware, sistemas de gestión de workflow, plataformas de decisión grupal distribuida.

8.3. Business Intelligence: DSS Moderno

Business Intelligence (BI) engloba tecnologías, aplicaciones y prácticas para recopilar, integrar, analizar y presentar información de negocio. BI moderno se caracteriza por self-service (empowerment de usuarios de negocio), visualización interactiva, integración de fuentes diversas, capacidades predictivas/prescriptivas mediante ML, y deployment cloud.

El stack BI típico incluye: ingesta de datos (conectores nativos a cientos de fuentes), modelado semántico (capa que abstrae complejidad técnica, define métricas y relaciones), motor analítico in-memory (para queries interactivas rápidas), visualización (dashboards, reportes, storytelling), y gobernanza (seguridad, auditoría, lineage).

8.4. Del análisis a la decisión

Un DSS combina datos, modelos y una interfaz orientada a problemas semiestructurados. Puede ser dirigido por datos, por modelos, por conocimiento, por documentos o por colaboración. Un sistema dirigido por datos explora grandes repositorios; uno dirigido por modelos utiliza simulación, optimización o predicción; uno basado en conocimiento aplica reglas o inferencia; y uno colaborativo estructura la decisión de un grupo.

En el ámbito clínico, un sistema de soporte a la decisión puede recordar una interacción farmacológica, sugerir una actuación conforme a un protocolo o estimar un riesgo. La recomendación debe presentarse en el momento adecuado, con datos suficientes, explicación comprensible y posibilidad de revisión. El exceso de alertas produce fatiga y reduce la eficacia. El sistema apoya, pero no elimina la responsabilidad profesional ni la necesidad de evaluar el contexto individual.

En gestión, el DSS puede simular escenarios de demanda, capacidad, contratación o distribución de recursos. La calidad de la decisión depende de la validez del modelo y de los supuestos. Un escenario no es una predicción cierta: es una consecuencia condicionada a hipótesis que deben mostrarse de forma transparente.

9. CUADROS DE MANDO Y KPI

9.1. Balanced Scorecard: Marco Estratégico

El Balanced Scorecard (BSC), desarrollado por Kaplan y Norton, es un sistema de gestión estratégica que traduce visión y estrategia en objetivos medibles organizados en cuatro perspectivas complementarias: Financiera (resultados económicos, sostenibilidad fiscal), Cliente/Usuario (satisfacción pacientes, calidad percibida, accesibilidad), Procesos Internos (eficiencia operacional, tiempos de espera, seguridad clínica), y Aprendizaje y Crecimiento (capacitación personal, innovación, cultura organizacional). En sanidad pública, la perspectiva financiera típicamente se reinterpreta como «sostenibilidad» dado que el objetivo no es maximizar beneficio sino valor en salud por euro invertido.

El BSC no es solo medición sino gestión: establece relaciones causa-efecto entre objetivos (ej: mejorar formación personal → mejora procesos → mejora satisfacción pacientes → mejora resultados → sostenibilidad), alinea iniciativas estratégicas con objetivos, y comunica estrategia a toda la organización mediante mapas estratégicos visuales.

9.2. Dashboards y Scorecards: Diferencias Clave

Aunque a menudo se usan como sinónimos, dashboard y scorecard ponen el foco en aspectos distintos. Un dashboard presenta de forma visual un conjunto de métricas para facilitar supervisión y análisis; puede ser operativo, táctico o estratégico y su latencia depende del caso de uso. En un hospital, un panel operativo podría mostrar ocupación, pacientes en espera y evolución temporal sin que ello obligue a una actualización segundo a segundo.

Un scorecard es estratégico: rastrea progreso hacia objetivos a largo plazo mediante KPIs, típicamente actualizados mensual o trimestralmente. Evalúa desempeño contra targets y benchmarks, identifica gaps estratégicos. Incorpora semáforos (verde/amarillo/rojo) y tendencias. El BSC es tipo específico de scorecard.

9.3. Diseño de KPIs Efectivos: Criterios SMART

Los Key Performance Indicators (KPIs) son métricas críticas que reflejan factores de éxito esenciales. Un KPI efectivo debe ser SMART: Específico (define claramente qué se mide, sin ambigüedad), Medible (cuantificable con datos disponibles y fiables), Alcanzable (realista dado recursos y contexto), Relevante (alineado con objetivos estratégicos, impacta decisiones), y Temporal (definido periodo de medición, permite seguimiento de tendencias).

9.4. Herramientas de visualización y elaboración de cuadros de mando

El autoservicio permite que usuarios autorizados creen análisis, pero requiere conjuntos certificados, métricas comunes y espacios diferenciados de desarrollo y producción. Sin gobierno, el autoservicio genera informes incompatibles y una nueva forma de silo.

Las herramientas pueden ofrecer conexión a fuentes, preparación, modelo semántico, expresiones de cálculo, visualización, publicación, alertas y seguridad. La comparación debe considerar despliegue local o en nube, identidad corporativa, accesibilidad, auditoría, control de versiones, rendimiento, portabilidad y coste total.

9.5. Definición, ficha y gobierno del indicador

Un KPI no es cualquier dato visible. Es un indicador vinculado con un objetivo y con capacidad para orientar una decisión. Su ficha debe incluir nombre, finalidad, fórmula, numerador, denominador, población, exclusiones, unidad, fuente, periodicidad, latencia, responsable, umbrales, desagregaciones y limitaciones. Sin esta ficha, dos áreas pueden mostrar el mismo título con cálculos incompatibles.

Los indicadores de resultado o lagging reflejan consecuencias ya producidas; los indicadores conductores o leading anticipan o influyen en el resultado. La tasa de readmisión es un resultado; el porcentaje de conciliaciones realizadas antes del alta puede ser un conductor. Un cuadro equilibrado combina actividad, calidad, resultados, eficiencia, experiencia, equidad y seguridad, evitando que la optimización de una sola métrica deteriore el sistema.

La visualización debe respetar la naturaleza del dato. Las series temporales requieren escalas coherentes; los porcentajes necesitan denominador y tamaño muestral; las comparaciones entre centros pueden exigir ajuste por riesgo; y los mapas deben evitar inferencias sobre personas a partir de agregados territoriales. El color debe reforzar significado, no decorar. Los umbrales deben justificarse y no convertir variación aleatoria en alarma.

10. DICCIONARIOS DE RECURSOS DE INFORMACIÓN, METADATOS, REPOSITORIOS Y BANCOS DE DATOS

10.1. Metadatos: Datos sobre Datos

Los metadatos son información descriptiva sobre datos, proporcionando contexto esencial para descubrimiento, comprensión, gestión y uso apropiado. Se clasifican en:

Metadatos Técnicos: Características estructurales y operacionales. Esquemas de bases de datos, tipos de datos, formatos de archivo, ubicaciones físicas, índices, particiones, estadísticas de volumen. Típicamente gestionados por herramientas técnicas (RDBMS catalogs, Hive Metastore).

Metadatos de Negocio: Significado funcional comprensible por usuarios no técnicos. Definiciones de términos de negocio, descripciones de datasets, propietarios de datos, clasificación de sensibilidad, políticas de uso. Documentados en glosarios de negocio y catálogos de datos.

Metadatos Operacionales: Información de gestión y calidad. Frecuencia de actualización, SLAs, métricas de calidad (completitud, exactitud, consistencia), historial de cambios, auditorías de acceso, lineage (rastreo de origen y transformaciones de datos).

10.2. Data Catalogs: Descubriendo Activos de Datos

Un catálogo de datos es un inventario centralizado y consultable de los activos de datos de una organización. Funciona como un buscador interno: los usuarios localizan conjuntos de datos por términos de negocio y consultan sus descripciones, esquemas, calidad, propietarios y condiciones de acceso. Los catálogos modernos incorporan conectores y rastreadores automatizados que inspeccionan bases de datos, data lakes, APIs y herramientas BI para extraer metadatos técnicos; también pueden utilizar aprendizaje automático para sugerir clasificaciones y relaciones e incorporar comentarios o validaciones de los usuarios.

Productos empresariales: Existen catálogos y suites de gobierno con metadatos, linaje y calidad. Su implantación debe evaluarse por cobertura funcional, integración, seguridad, portabilidad y coste total.

Open Source: Apache Atlas (metadatos para Hadoop ecosystem), DataHub (LinkedIn, moderno y extensible), Amundsen (Lyft, data discovery), OpenMetadata (emergente, feature-rich). Requieren infraestructura y customización pero sin licencias.

Servicios gestionados: los proveedores de nube ofrecen catálogos y servicios de gobierno integrados con sus plataformas. Sus nombres y capacidades evolucionan con rapidez; para el examen importa identificar la función —inventario, metadatos, linaje, clasificación y gobierno— y no memorizar una marca salvo que el temario o una pregunta oficial la exija.

10.3. Data Lineage: Rastreando el Viaje de los Datos

El lineage de datos mapea el ciclo de vida completo de datos: desde fuentes originales, a través de todas las transformaciones ETL/ELT, agregaciones en data warehouses, hasta reportes y dashboards finales. Proporciona visibilidad end-to-end respondiendo: ¿De dónde vienen estos datos? ¿Qué transformaciones se aplicaron? ¿Quién los modificó y cuándo? ¿Qué downstream depende de ellos?

El lineage es crítico para: Análisis de Impacto (antes de cambiar un campo en origen, saber qué reportes se romperían), Root Cause Analysis (cuando un KPI es incorrecto, rastrear hacia atrás para identificar el problema), Cumplimiento Regulatorio (auditorías RGPD requieren documentar procesamiento de datos personales), y Comprensión de Datos (entender significado de métricas complejas viendo su derivación).

10.4. Gobernanza de Datos: Marco Organizacional

La gobernanza de datos establece políticas, roles, procesos y controles para gestionar datos como activo estratégico. Componentes clave incluyen: Políticas y Estándares (nomenclaturas, definiciones canónicas, clasificación sensibilidad, retención), Organización (comité de gobernanza, data stewards por dominio, propietarios de datos), Calidad de Datos (métricas, perfilado, limpieza, monitorización continua), Seguridad y Privacidad (controles de acceso, cifrado, anonimización, auditoría), Gestión del Ciclo de Vida (creación, actualización, archivo, eliminación según políticas).

En sanidad, la gobernanza del dato debe articularse conforme al RGPD, la LOPDGDD y la normativa sanitaria aplicable, y resulta además éticamente esencial por el carácter especialmente sensible de los datos de salud.

10.5. Definiciones y Distinciones

Aunque a menudo confundidos, estos términos tienen matices distintos en contexto de gestión de información:

Base de Datos: Colección organizada de datos estructurados gestionada por un SGBD (Sistema Gestor de Bases de Datos), típicamente para uso operacional (OLTP). Optimizada para transacciones, actualizaciones frecuentes, consultas simples rápidas.

Data Warehouse: Repositorio analítico integrado, orientado a temas, histórico y estable, que consolida datos procedentes de múltiples fuentes operacionales para facilitar análisis y toma de decisiones.

Repositorio: Término más amplio para cualquier sistema centralizado de almacenamiento y gestión de activos de información. Puede contener código (repositorios Git), documentos (repositorios documentales tipo SharePoint, Alfresco), conocimiento (knowledge bases), o metadatos (repositorios de metadatos como registros de esquemas).

Banco de Datos: Término tradicional y de significado dependiente del contexto, usado para designar una colección organizada de datos de alcance temático o institucional. No debe equipararse automáticamente a un data warehouse: puede describir repositorios con finalidades y arquitecturas muy distintas.

10.6. Gestión Documental y Repositorios de Contenido

Los sistemas de gestión documental (DMS – Document Management Systems) o de contenido empresarial (ECM – Enterprise Content Management) gestionan el ciclo de vida completo de documentos no estructurados: captura (scanning, upload), indexación y metadatos, almacenamiento seguro, versionado y control de cambios, búsqueda y recuperación, workflow y aprobaciones, preservación a largo plazo y eliminación controlada.

En sanidad, DMS gestionan consentimientos informados escaneados, informes clínicos firmados digitalmente, documentación administrativa, imágenes diagnósticas con metadatos DICOM, y cada vez más, integración con historia clínica electrónica para vista unificada de información estructurada y documental del paciente.

10.7. Versionado y Control de Cambios

El control de versiones rastrea cambios en artefactos a lo largo del tiempo, permitiendo recuperar versiones anteriores, comparar diferencias, entender evolución, y colaborar sin sobrescribir trabajo ajeno. Git es el estándar de facto para código, pero conceptos análogos aplican a datos y modelos.

Data Version Control (DVC): Extensión de Git para versionar datasets y modelos ML. Los archivos grandes se almacenan en storage remoto (S3, Azure Blob), Git solo rastrea metadatos y punteros. Reproduce pipelines ML completos.

lakeFS: Sistema de versionado para data lakes. Proporciona branches, commits, merges tipo Git sobre object storage. Permite experimentación aislada, rollback de cambios erróneos, reproducibilidad.

Delta Lake, Apache Iceberg, Apache Hudi: Añaden capacidades transaccionales (ACID) y time-travel a data lakes, permitiendo consultar snapshots históricos y revertir cambios.

10.8. Diccionario, catálogo y registro de recursos

Un diccionario de datos describe elementos de un modelo: nombre, definición, tipo, longitud, dominio, obligatoriedad, claves, relaciones y reglas. Un diccionario de recursos de información amplía el alcance hacia conjuntos de datos, servicios, informes, indicadores, documentos, modelos y responsables. El catálogo de datos ofrece mecanismos de búsqueda, clasificación, linaje, calidad y solicitud de acceso. Los términos pueden solaparse, pero conviene distinguir el nivel técnico de columna del nivel corporativo de activo.

Los metadatos pueden ser técnicos —esquemas, tipos, ubicaciones—, de negocio —definiciones, propietarios, sensibilidad— y operacionales —fecha de carga, volumen, errores, duración y procedencia—. También existen metadatos de preservación, seguridad y uso. El catálogo no debe ser una documentación estática: se integra con las plataformas para descubrir esquemas, capturar linaje y actualizar evidencias de forma automática.

10.9. Repositorio, banco de datos y base de datos

Una base de datos es una colección estructurada gestionada por un SGBD. Un repositorio es un concepto más amplio: almacena y organiza activos con reglas de acceso, versiones y metadatos; puede contener datos, documentos, código, modelos o paquetes. «Banco de datos» se usa de forma general para designar una colección organizada y reutilizable, a menudo de alcance temático o institucional. El significado concreto debe deducirse de la norma o sistema que lo emplea.

El repositorio corporativo debe aplicar clasificación, retención, copias de seguridad, control de versiones, integridad y auditoría. La publicación de un conjunto de datos exige separar el repositorio interno de la vista autorizada para consumo. Un catálogo puede describir un activo sin conceder acceso a su contenido; descubrimiento y autorización son procesos diferentes.

11. DATA FABRIC, DATA MESH Y ARQUITECTURAS MODERNAS

11.1. Data Fabric

Data Fabric es un enfoque arquitectónico que conecta fuentes y plataformas mediante servicios comunes de integración, metadatos, calidad, seguridad, orquestación y acceso. No es un repositorio físico concreto. Puede abarcar data warehouses, data lakes, bases operacionales, APIs y plataformas en nube o locales. Su propósito es reducir silos y proporcionar una capa coherente de descubrimiento y gobierno.

La automatización basada en metadatos es un rasgo habitual: el catálogo conoce esquemas, linaje, políticas y patrones de uso, y esa información puede guiar integración, clasificación o controles. La arquitectura no elimina la heterogeneidad; la hace gestionable mediante servicios y políticas compartidas.

11.2. Data Mesh

Data Mesh es un enfoque sociotécnico y descentralizado. Propone que los dominios de negocio asuman responsabilidad sobre sus datos como productos, dentro de una plataforma autoservicio y una gobernanza federada. Sus principios suelen expresarse como propiedad por dominio, datos como producto, plataforma de datos autoservicio y gobierno computacional federado.

Data Fabric y Data Mesh no son mutuamente excluyentes. Fabric enfatiza capacidades técnicas integradoras; Mesh enfatiza organización y responsabilidad por dominios. Una organización puede usar servicios de fabric para implantar productos de datos gestionados por dominios. El riesgo de la descentralización es reproducir silos si no existen estándares, interoperabilidad, identificadores y dimensiones conformadas.

11.3. Selección arquitectónica

No existe una arquitectura universal. El data warehouse sigue siendo adecuado para información integrada, histórica y regulada; el data lake aporta flexibilidad; el lakehouse añade control tabular; la fabric conecta plataformas; y el mesh distribuye responsabilidades. La decisión debe considerar requisitos de latencia, estructura, volumen, soberanía, seguridad, competencias, dependencia tecnológica y coste total de operación.

12. APLICACIÓN EN EL SERVICIO ANDALUZ DE SALUD

12.1. Integración de información y gobierno del dato

El SAS gestiona sistemas asistenciales, administrativos, económicos, logísticos y de recursos humanos. La explotación corporativa necesita integrar fuentes sin alterar su función operacional. La estructura responsable de transformación digital del SAS tiene atribuidas funciones de gobernanza del dato, almacenamiento y análisis, seguridad, interoperabilidad y aprovechamiento del valor del dato para mejorar decisiones y procesos. Estas funciones sitúan la gestión del dato como una capacidad transversal, no como una tarea aislada de generación de informes.

La aplicación práctica incluye modelos corporativos, procesos de extracción y calidad, repositorios analíticos, indicadores, productos de datos y servicios de consulta. La gestión debe respetar la finalidad asistencial y administrativa de los sistemas fuente, controlar el uso secundario y mantener separación entre datos identificados, pseudonimizados y agregados según el caso.

12.2. InfoWEB y difusión de resultados

InfoWEB es una plataforma del SAS, desarrollada por la Subdirección Técnica Asesora de Gobierno del Dato, para difundir resultados obtenidos de la explotación de distintos sistemas de información. La información publicada por ayudaDIGITAL incluye ámbitos como Contrato Programa, listas de espera, indicadores de Atención Primaria, CMBD, Base Poblacional de Salud, vacunas, cribados e indicadores generales del SSPA.

InfoWEB ejemplifica la última capa de una arquitectura analítica: los datos se originan en sistemas operacionales, se integran y validan, se convierten en indicadores y se presentan conforme a perfiles y necesidades. La plataforma de difusión no sustituye el gobierno previo. Un gráfico correcto depende de definiciones, cargas, validaciones y autorizaciones correctas.

12.3. CMBD, Diraya, BDU y otros recursos

El CMBD Andalucía resume variables clínicas, demográficas y administrativas de episodios hospitalarios y constituye una fuente administrativo-clínica relevante. Diraya aporta información de historia clínica digital y procesos asistenciales. La BDU proporciona identificación poblacional y permite vincular registros mediante el identificador único establecido para el SSPA. Cada recurso tiene finalidad y semántica propias; su integración exige reglas temporales, correspondencias y control de calidad.

La explotación analítica puede apoyar planificación, seguimiento de actividad, evaluación de resultados, salud pública e investigación. Debe evitarse atribuir públicamente al SAS productos, motores o arquitecturas internas que no estén documentados. En una oposición es más seguro describir capacidades y sistemas oficiales —BPS, BDU, CMBD, Diraya e InfoWEB— que inferir marcas o componentes técnicos no publicados.

13. BASE POBLACIONAL DE SALUD (BPS)

13.1. Creación y naturaleza

La Base Poblacional de Salud es un sistema de información sanitaria de base poblacional del SSPA. La Resolución 0068/18 de la Dirección Gerencia del SAS creó formalmente la BPS para integrar datos de cada persona distribuidos en distintos sistemas de información. Su punto de partida es la identificación única de la persona en la Base de Datos de Usuarios, que permite conectar registros y reconstruir su trayectoria de salud y atención.

La BPS se basa en el usuario, no en un episodio o centro aislado. La documentación oficial la define como una base que recoge datos clínicos y del uso de recursos de las personas incluidas en la población de referencia de BDU. De cada usuario obtiene datos demográficos, diagnósticos, utilización de recursos y proveedores. Esta integración genera una «biografía sanitaria» útil para análisis longitudinales.

Publicaciones oficiales del SSPA de 2025 y 2026 sitúan la BPS en aproximadamente quince millones de registros de personas acumulados desde 2001 y describen su uso con datos clínicos anonimizados para investigación. Esta cifra es histórica y no equivale a la población residente actual: incluye personas atendidas a lo largo de los años. La BPS constituye una fuente de datos del mundo real, ya que procede de información generada durante la prestación ordinaria de servicios sanitarios.

13.2. Finalidades oficiales

La Resolución de creación enumera finalidades concretas: identificar necesidades de atención de la población y sus subgrupos; apoyar planificación y salud pública; apoyar la gestión y la distribución de recursos; compartir información entre niveles asistenciales; configurar biografías sanitarias para estudios longitudinales; anticipar necesidades futuras; y disponer de infraestructura de datos para investigación.

Estas finalidades abarcan análisis transversal y longitudinal. El análisis transversal describe una población en un momento o periodo, por ejemplo prevalencia o estratificación. El longitudinal sigue eventos a lo largo del tiempo y permite estudiar historia natural de enfermedades, incidencia, utilización, supervivencia o trayectorias. La misma infraestructura puede sostener productos distintos, siempre que cada uso tenga finalidad, base jurídica, metodología y control de acceso adecuados.

13.3. Fuentes y contenido

La documentación oficial de la BPS identifica BDU como fuente de usuarios e identificación. La información clínica y de utilización procede de Atención Primaria y hospitalaria. Entre las fuentes administrativo-clínicas destacan la Historia Clínica Digital Diraya y los CMBD hospitalarios, incluidos hospitalización, hospitales de día y urgencias. La presentación técnica también recoge diagnósticos de Atención Primaria, CMBD, consultas de salud mental, vacunas y valoraciones funcionales o cognitivas en distintas fases de incorporación.

El uso de recursos comprende consultas de Atención Primaria y Atención Especializada, urgencias, procesos de atención hospitalaria, consumo de farmacia y sesiones de diálisis. La información puede valorarse en unidades de actividad y en términos económicos según la finalidad analítica. La Resolución prevé incorporación progresiva de datos de otros sistemas del SSPA y contempla datos de ámbitos sociosanitarios o estadísticos conforme a las reglas aplicables.

13.4. Integración, ETL y longitudinalidad

La Resolución establece que la conexión entre sistemas se realiza mediante el identificador único de BDU y que se debe optimizar la interoperabilidad de los procesos de extracción, transformación y carga. Esto aporta dos ideas de examen. Primero, la integración poblacional requiere un identificador común y reglas de correspondencia. Segundo, BPS no es una mera suma de bases: exige transformar, depurar y contextualizar los registros.

La dimensión temporal es esencial. Un diagnóstico, una adscripción, un proveedor o una utilización deben interpretarse con su fecha y vigencia. El análisis longitudinal requiere conservar eventos y cambios sin perder el contexto histórico. La calidad debe controlar duplicidades, fechas imposibles, códigos obsoletos, episodios incompletos y cambios de clasificación. Los metadatos deben indicar fuente, periodo, cobertura, actualización y limitaciones.

13.5. Productos analíticos y usos

La BPS permite estimar estado de salud y comportamiento de la población respecto a los servicios; estudiar incidencia, prevalencia, historia natural y supervivencia; efectuar proyecciones de necesidades; estratificar población; analizar eficiencia distributiva y utilización por proveedores; y apoyar investigación en servicios de salud. Los resultados pueden alimentar estadísticas, estudios observacionales, planificación o productos de gestión.

El valor de los datos del mundo real reside en su cobertura y continuidad, pero presentan limitaciones: fueron recogidos para asistencia o gestión, no necesariamente para una hipótesis de investigación; puede haber variabilidad de registro, cambios de codificación, datos ausentes y confusión. Los estudios deben definir cohortes, exposiciones, resultados, ventanas temporales y métodos de ajuste. Una base grande reduce error aleatorio, pero no elimina sesgos sistemáticos.

En 2026 se ha difundido el estudio COHMET-A, basado en datos retrospectivos de BPS de 2015 a 2025, para analizar obesidad y enfermedad metabólica. El ejemplo muestra el uso de BPS como fuente de evidencia de mundo real a escala poblacional. La publicación de resultados no implica acceso libre a microdatos: el acceso y tratamiento deben seguir los procedimientos, autorizaciones y salvaguardas correspondientes.

13.6. Acceso, seguridad y protección de datos

La Resolución dispone que el acceso se realizará por personal autorizado, con identificación y autenticación segura desde la Red Corporativa de la Junta de Andalucía. Pueden acceder profesionales autorizados cuyas actividades respondan a las finalidades previstas —asistencia, administración, gestión, evaluación, inspección, investigación o salud pública— y cada profesional debe acceder exclusivamente a los datos necesarios para sus funciones.

Los datos de salud son categorías especiales de datos personales conforme al artículo 9 del RGPD. La protección exige base jurídica, limitación de finalidad, minimización, control de accesos, trazabilidad, seguridad y evaluación del riesgo. Debe distinguirse pseudonimización de anonimización: los datos pseudonimizados siguen siendo datos personales si existe información adicional que permite atribuirlos a una persona; los anonimizados quedan fuera del RGPD solo cuando la reidentificación no sea razonablemente posible.

El Reglamento (UE) 2025/327 creó el Espacio Europeo de Datos de Salud y establece reglas comunes, estándares, infraestructuras y gobernanza para uso primario y secundario. Su aplicación es gradual. Para el opositor, la idea relevante es que el uso secundario de datos sanitarios evoluciona hacia marcos más estructurados de acceso, interoperabilidad y control, sin desplazar las obligaciones del RGPD y la normativa nacional.

14. SEGURIDAD, PRIVACIDAD, CALIDAD Y ÉTICA EN LA ANALÍTICA

14.1. Seguridad por capas

Una plataforma analítica trata copias, transformaciones y resultados que pueden multiplicar la superficie de exposición. La seguridad debe cubrir identidad, autenticación, autorización, segmentación, cifrado, gestión de secretos, endurecimiento, copias, continuidad, monitorización y respuesta. Los permisos se asignan por función y finalidad; la cuenta técnica de una carga no debe convertirse en una vía de consulta interactiva.

La trazabilidad registra quién accede, a qué activo, cuándo, con qué operación y desde qué contexto. Los registros deben protegerse frente a alteración y conservarse conforme a política. La monitorización detecta extracciones anómalas, consultas masivas, accesos fuera de patrón y fallos repetidos. La seguridad debe extenderse a exportaciones, ficheros temporales, notebooks, modelos y herramientas de visualización.

14.2. Privacidad desde el diseño

La minimización exige utilizar solo variables y granularidad necesarias. La agregación, supresión, generalización, seudonimización y entornos seguros reducen riesgo, pero ninguna técnica es universal. Los cuasi-identificadores —combinaciones de edad, zona, fecha o condición rara— pueden permitir reidentificación aunque se eliminen nombre y DNI.

La evaluación de impacto resulta necesaria cuando el tratamiento puede entrañar alto riesgo, especialmente con datos de salud, análisis a gran escala o nuevas tecnologías. Debe considerar finalidad, necesidad, proporcionalidad, riesgos y medidas. La privacidad no se resuelve al final del proyecto: condiciona arquitectura, modelo de datos, perfiles y forma de publicación.

14.3. Ética, sesgo y explicabilidad

Los datos reflejan la práctica y sus desigualdades. Una población con menor acceso puede aparecer con menor utilización y, si se interpreta de forma ingenua, recibir menos recursos. Los modelos deben evaluarse por sexo, edad, territorio y otros grupos relevantes, evitando variables sustitutivas que reproduzcan discriminación. La equidad no equivale a igualdad de tasa de error en todos los casos; requiere elegir criterios coherentes con el uso.

La explicabilidad debe adaptarse al destinatario. Un técnico necesita linaje, variables y versión; un profesional, factores y límites; un directivo, impacto y incertidumbre; una persona afectada, una explicación comprensible. Los modelos de alto impacto necesitan supervisión humana, gestión de cambios y vías de revisión.

14.4. Gestión de calidad y observabilidad

La observabilidad del dato combina métricas de frescura, volumen, esquema, distribución, linaje y fallos. Permite detectar que una carga llegó tarde, que disminuyó el número de registros, que apareció un nuevo código o que cambió la distribución de una variable. Los acuerdos de nivel de servicio del dato pueden definir periodicidad, retraso máximo, disponibilidad y tiempo de resolución.

La validación debe realizarse en origen, integración y consumo. Los indicadores críticos se concilian con fuentes y periodos conocidos. Las correcciones deben versionarse para evitar que un informe histórico cambie sin explicación. La confianza se construye mostrando procedencia, fecha, definición y limitaciones, no ocultando la complejidad.

15. CONCLUSIONES E IDEAS CLAVE PARA EL REPASO

La gestión corporativa del dato transforma registros dispersos en información fiable para la decisión. El data warehouse integra historia; el data mart especializa; OLAP navega por dimensiones; la minería descubre patrones; Big Data distribuye almacenamiento y cálculo; y los DSS y cuadros de mando acercan el análisis a la acción. Ninguna tecnología sustituye la definición, la calidad y la responsabilidad.

• Data warehouse: orientado a temas, integrado, histórico y estable; optimizado para análisis.
• Modelo dimensional: la tabla de hechos contiene medidas y claves; las dimensiones aportan contexto y jerarquías; el grano define cada fila.
• OLAP: análisis multidimensional mediante roll-up, drill-down, slice, dice y pivot; MOLAP, ROLAP y HOLAP son estrategias clásicas.
• Minería de datos: descubre patrones; exige preparación, evaluación, validación, despliegue y vigilancia.
• Big Data: responde a propiedades de volumen, velocidad, variedad y veracidad; no obliga a usar una tecnología concreta.
• Hadoop: Common, HDFS, YARN y MapReduce; Spark puede ejecutarse sobre YARN y leer o escribir HDFS.
• KPI: indicador vinculado con objetivo, fórmula, fuente, periodicidad, responsable y umbrales.
• Metadatos: describen significado, estructura, procedencia, calidad, uso y seguridad.
• SAS: BDU, Diraya, CMBD, BPS e InfoWEB son referencias oficiales para comprender la integración y explotación de datos.
• BPS: sistema poblacional basado en el usuario, conectado mediante el identificador de BDU, con datos demográficos, clínicos, de recursos y proveedores, orientado a planificación, gestión, salud pública e investigación.

16. MAPA CONCEPTUAL