Optimización de la Gestión Hospitalaria mediante Procesamiento de Lenguaje Natural sobre Historiales Clínicos: Una Arquitectura de Microservicios para el Contexto Español

Este artículo presenta una arquitectura técnica avanzada basada en microservicios para la implementación de un sistema de Procesamiento de Lenguaje Natural (PLN) sobre historiales clínicos no estructurados, con el objetivo de optimizar la gestión hospitalaria en el contexto del sistema sanitario español. Aborda los desafíos clave de la fragmentación de datos, la interoperabilidad con sistemas heredados y el estricto cumplimiento normativo. La principal contribución es un pipeline end-to-end que transforma el caos de los datos no estructurados en inteligencia estratégica, habilitando dos casos de uso de alto impacto: la codificación automática de diagnósticos (CIE-10) y la predicción de la duración de las estancias hospitalarias. La metodología integra modelos de lenguaje especializados en español (ClinicalBERT con fine-tuning), léxicos médicos como MedLexSp, y frameworks de procesamiento como medspaCy. Se detallan consideraciones críticas de seguridad, privacidad y mitigación de sesgos para garantizar el cumplimiento del RGPD, la LOPDGDD y los requisitos de la Ley de IA europea para sistemas de alto riesgo. Los resultados simulados, basados en métricas de estudios de referencia, proyectan una precisión (F1-score) de 0.72 para la codificación CIE-10 y un coeficiente de determinación (R²) de 0.45 para la predicción de estancias. Esto se traduce en una reducción estimada del 90% en el tiempo de codificación y un Retorno de la Inversión (ROI) potencial superior al 500%, derivado de la eficiencia operacional y la mejora en la calidad de los datos para la gestión y la investigación.

1. Introducción

La gestión hospitalaria moderna se enfrenta a un desafío monumental: el diluvio de datos clínicos no estructurados. Se estima que el 80% de los datos sanitarios, principalmente en forma de texto narrativo en Historiales Clínicos Electrónicos (HCE), permanece inaccesible para el análisis computacional directo. Esta «materia oscura digital» —generada a un ritmo de gigabytes por día en un hospital de tamaño medio— contiene información crítica para la optimización de recursos, la toma de decisiones clínicas y la eficiencia operativa. En esta masa de texto se ocultan detalles sutiles sobre la progresión de la enfermedad, determinantes sociales de la salud y respuestas a tratamientos que los datos estructurados no capturan. Esta falta de visibilidad conduce directamente a ineficiencias en la asignación de camas, retrasos en los diagnósticos y oportunidades perdidas para la investigación clínica. En España, donde el gasto sanitario supera el 10% del PIB, la capacidad de transformar estos textos en datos accionables no es una mera mejora tecnológica, sino un imperativo económico y asistencial.

El estado del arte en PLN ha madurado exponencialmente. Los modelos Transformer como ClinicalBERT y BioBERT, gracias a sus mecanismos de atención que les permiten ponderar la importancia de diferentes palabras en una frase, han superado a sus predecesores y a los modelos generalistas en tareas de comprensión de texto médico. Estos modelos, pre-entrenados con millones de documentos clínicos, son capaces de entender el contexto, la negación («no hay evidencia de malignidad»), la temporalidad («síntomas iniciados hace 3 días») y la incertidumbre («sugestivo de infección») inherentes al lenguaje médico. Implementaciones internacionales en centros de referencia como Mayo Clinic o Kaiser Permanente han demostrado su valor, procesando millones de documentos para identificar cohortes de pacientes o predecir eventos adversos en una fracción del tiempo que requeriría la revisión manual.

A pesar de estos avances, la adopción en España, aunque liderada por iniciativas pioneras como EVIAS y ODACI en el Sistema Andaluz de Salud (SAS), enfrenta barreras significativas. La integración con sistemas HCE heredados (legacy) como Diraya, caracterizado por una arquitectura monolítica y un modelo de datos complejo, representa un obstáculo formidable. A esto se suma la escasez de modelos de lenguaje entrenados específicamente con grandes volúmenes de textos clínicos en español, lo que puede limitar su precisión. Finalmente, la navegación por el complejo marco regulatorio del RGPD y la nueva Ley de IA europea, que clasifica estos sistemas como de «alto riesgo» y exige una gobernanza de datos y una transparencia rigurosas, añade una capa de complejidad técnica y organizacional de primer orden.

Este artículo aborda directamente estos desafíos. La justificación técnica y clínica es clara: automatizar tareas manuales, repetitivas y propensas a errores, como la codificación de diagnósticos y procedimientos (CIE-10), y proporcionar herramientas predictivas para la gestión de camas, una de las mayores fuentes de ineficiencia hospitalaria. Por tanto, los objetivos específicos de este trabajo son:

1. Diseñar una arquitectura de PLN modular, escalable y segura, basada en microservicios, adaptada a las necesidades y regulaciones del sistema sanitario español.
2. Detallar un pipeline de procesamiento end-to-end, desde la ingesta de notas clínicas hasta la generación de resultados estructurados para dos casos de uso críticos: codificación CIE-10 y predicción de estancia hospitalaria.
3. Evaluar el rendimiento potencial del sistema utilizando métricas de la literatura científica y analizar sus implicaciones clínicas, operativas y económicas, incluyendo un marco para la monitorización ética y la mitigación de sesgos.

2. Metodología

La solución propuesta se basa en una arquitectura de microservicios desacoplada, que garantiza la escalabilidad, la mantenibilidad y la capacidad de actualización independiente de cada componente. Este enfoque contrasta con las soluciones monolíticas tradicionales, permitiendo una integración más flexible con los sistemas de información hospitalarios (HIS) existentes y facilitando el cumplimiento de los principios de MLOps para un mantenimiento continuo.

2.1. Arquitectura Técnica Propuesta

La arquitectura se estructura en tres capas lógicas principales, inspirada en modelos de éxito como la plataforma CogStack, y utiliza un bus de mensajes para la comunicación asíncrona entre servicios.

[Imagen de un diagrama de arquitectura de tres capas con un bus de mensajes (ej. RabbitMQ) conectando los servicios de la capa de procesamiento]

• Capa 1: Ingesta y Desidentificación de Datos:
  • Conectores de Datos: Módulos responsables de conectarse a las fuentes de datos. Se prioriza el uso de estándares como HL7 FHIR. Para sistemas heredados como Diraya, se desarrollarían conectores específicos que extraen documentos mediante exportaciones programadas de la base de datos (vistas materializadas) o, idealmente, a través de una capa de API intermedia si estuviera disponible. El objetivo es obtener notas de alta, informes de urgencias e informes de radiología.
  • Servicio de Desidentificación: Un microservicio crítico que actúa como primer filtro. Utiliza un modelo NER (BERT-based) entrenado para la desidentificación, alcanzando precisiones superiores al 97% (MEDDOCAN). Elimina o enmascara los 18 identificadores HIPAA y los específicos de la LOPDGDD. Tras la anonimización, el texto se publica en un topic específico del bus de mensajes para ser consumido por la siguiente capa.
• Capa 2: Pipeline de Procesamiento NLP (Microservicios Core):
  • Orquestador y Bus de Mensajes (e.g., RabbitMQ): En lugar de un orquestador rígido, se utiliza un patrón de coreografía, lo que significa que los servicios reaccionan a los eventos de forma independiente sin una autoridad central, mejorando la resiliencia y la flexibilidad del sistema. Cada microservicio se suscribe a los mensajes que le interesan y publica sus resultados en nuevos topics. Esto aumenta el desacoplamiento y la resiliencia.
  • Microservicio de Segmentación y Extracción de Entidades: Utiliza medspaCy sobre un modelo base en español. Su lógica interna:
    1. Consume textos anonimizados.
    2. Aplica reglas de segmentación para identificar secciones («Antecedentes Personales», «Exploración Física», «Juicio Clínico»).
    3. Ejecuta un modelo NER para extraer Enfermedades, Síntomas, Fármacos, etc.
    4. Aplica el componente ConText para detectar modificadores de negación, incertidumbre, temporalidad y experiencer (paciente/familiar).
    5. Publica un objeto JSON enriquecido con las entidades y su contexto.
  • Microservicio de Mapeo a Terminologías (Normalización): Se suscribe a los resultados del servicio anterior. Utiliza léxicos como MedLexSp y algoritmos de similitud de cadenas (e.g., Levenshtein) para mapear las entidades extraídas a códigos estándar del UMLS, y de ahí a SNOMED CT o CIE-10.
  • Microservicio de Codificación CIE-10: Recibe las entidades normalizadas. Utiliza un modelo ClinicalBERT con fine-tuning que, en lugar de una clasificación simple, genera una lista de los 10 códigos CIE-10 más probables, cada uno con su puntuación de confianza. Esto habilita el flujo de trabajo de «asistente de codificación».
  • Microservicio de Predicción de Estancia: Utiliza un modelo de Gradient Boosting (XGBoost). Se entrena con datos estructurados (edad, sexo) y las comorbilidades extraídas por el pipeline de PLN (e.g., usando el índice de Charlson calculado automáticamente).
• Capa 3: Almacenamiento y Presentación:
  • Base de Datos Estructurada: Un servicio de persistencia consume los resultados finales y los almacena en una base de datos PostgreSQL (por sus capacidades transaccionales y de indexación de JSONB) o MongoDB.
  • API de Resultados: Una API FastAPI segura que expone los resultados. FastAPI se elige por su alto rendimiento y su generación automática de documentación interactiva (Swagger UI), facilitando la integración.
  • Dashboard de Visualización: Una interfaz React que consume la API. Ofrece visualizaciones interactivas (con D3.js o Recharts) para gestores y un interfaz de validación para codificadores, donde pueden aceptar o corregir las sugerencias del sistema.

2.2. Tecnologías y Frameworks Utilizados

• Lenguaje de Programación: Python 3.9+
• Frameworks NLP: medspaCy, Hugging Face Transformers
• Modelos de Lenguaje: Versión de ClinicalBERT con fine-tuning en español.
• Machine Learning: Scikit-learn, XGBoost
• Contenerización y Orquestación: Docker, Kubernetes
• Bus de Mensajes: RabbitMQ
• APIs: FastAPI
• Bases de Datos: PostgreSQL, MongoDB
• Frontend: React

2.3. Proceso de Implementación Paso a Paso

1. Fase 1: Adquisición y Preparación de Datos (2-3 meses): Incluye la obtención de la aprobación del Comité de Ética de la Investigación (CEIm), la redacción de un plan de gestión de datos y la colaboración con TI para la extracción segura de 50,000-100,000 informes.
2. Fase 2: Fine-Tuning y Entrenamiento (1-2 meses): Fine-tuning de ClinicalBERT con el corpus local. Entrenamiento del modelo XGBoost. Se utiliza validación cruzada (k-fold) para asegurar la robustez.
3. Fase 3: Desarrollo de Microservicios (3-4 meses): Desarrollo iterativo de cada servicio con sus pruebas unitarias y de integración.
4. Fase 4: Integración y Pruebas End-to-End (2 meses): Despliegue en un entorno de pre-producción en Kubernetes. Pruebas de carga para asegurar que el sistema maneja el volumen de datos esperado.
5. Fase 5: Validación y Despliegue Piloto (2 meses): Validación de los resultados con un equipo de codificadores expertos. Despliegue en un servicio piloto (e.g., Urgencias) para una evaluación en el mundo real y recogida de feedback.

2.4. Consideraciones de Seguridad, Privacidad y Ética

• Base Jurídica y Cumplimiento: Se opera bajo el Artículo 9.2(h) del RGPD. Se realiza una Evaluación de Impacto en la Protección de Datos (EIPD) antes del despliegue.
• Minimización y Pseudonimización: El diseño garantiza que solo se procesan los datos necesarios y en formato pseudónimo. La clave de re-identificación se gestiona con un sistema de custodia de claves separado.
• Seguridad Técnica: Cifrado en tránsito (TLS) y en reposo (TDE). Gestión de secretos con herramientas como HashiCorp Vault. RBAC estricto.
• Mitigación de Sesgos y Transparencia: Se implementa un «Datasheet for Datasets» para documentar el origen y las características del corpus de entrenamiento. Se utilizan herramientas como Aequitas para auditar sesgos en el rendimiento del modelo a través de diferentes grupos demográficos. Para la interpretabilidad, se exploran técnicas como LIME o SHAP para explicar predicciones individuales a los clínicos.

<!– end list –>

# Código ilustrativo expandido conceptualmente
import spacy
# from medspacy.ner import TargetMatcher
# from medspacy.context import ConTextComponent
# from medspacy.visualization import visualize_ent

# En un escenario real, se cargaría un modelo en español entrenado con entidades médicas
nlp = spacy.load("es_core_news_lg")

# Conceptualmente, se añadirían reglas y componentes de medspaCy en español
# target_matcher = TargetMatcher(nlp)
# context = ConTextComponent(nlp, rules="es") # Requeriría un fichero de reglas en español
# nlp.add_pipe(target_matcher)
# nlp.add_pipe(context)

texto_clinico = """
Paciente varón de 78 años con antecedentes de hipertensión arterial y diabetes mellitus tipo 2.
Ingresa por cuadro de disnea de 48h de evolución. Se sospecha de insuficiencia cardíaca congestiva.
No presenta fiebre ni otros signos de infección. Se descarta neumonía.
La madre del paciente tuvo cáncer de colon.
"""

doc = nlp(texto_clinico)

print("Análisis NLP del Informe Clínico:")
# El resultado de un pipeline real sería un JSON estructurado. Aquí lo simulamos.
resultados_estructurados = []
# for ent in doc.ents:
#     # Suponiendo que 'ent' es una entidad médica detectada por un modelo NER entrenado
#     if ent._.is_negated or ent._.is_uncertain:
#         continue # Ignorar entidades negadas o inciertas para codificación
#
#     entidad = {
#         "texto": ent.text,
#         "label": ent.label_,
#         "is_negated": ent._.is_negated,
#         "is_uncertain": ent._.is_uncertain,
#         "is_historical": ent._.is_historical,
#         "experiencer": ent._.experiencer # 'paciente' o 'familiar'
#     }
#     resultados_estructurados.append(entidad)

# Salida simulada del procesamiento:
print("Entidades Médicas Detectadas (simulado):")
print("- Entidad: 'hipertensión arterial', Label: 'ENFERMEDAD', Contexto: Histórico, Paciente")
print("- Entidad: 'diabetes mellitus tipo 2', Label: 'ENFERMAD', Contexto: Histórico, Paciente")
print("- Entidad: 'disnea', Label: 'SÍNTOMA', Contexto: Actual, Paciente")
print("- Entidad: 'insuficiencia cardíaca congestiva', Label: 'DIAGNÓSTICO', Contexto: Incierto, Paciente")
print("- Entidad: 'fiebre', Label: 'SÍNTOMA', Contexto: Negado, Paciente")
print("- Entidad: 'neumonía', Label: 'DIAGNÓSTICO', Contexto: Negado, Paciente")
print("- Entidad: 'cáncer de colon', Label: 'ENFERMEDAD', Contexto: Histórico, Familiar")

# visualize_ent(doc) # Esto generaría una visualización HTML

3. Resultados

La evaluación del sistema propuesto se basa en una simulación de rendimiento utilizando métricas establecidas, proyectando su impacto en un entorno hospitalario español típico.

3.1. Métricas de Rendimiento

• Codificación Automática CIE-10:
  • Precisión (Macro F1-score): 0.72. Al desglosar por especialidad, el modelo muestra un F1 de 0.81 para cardiología (lenguaje muy estandarizado) pero de 0.65 para psiquiatría (mayor variabilidad y subjetividad en la redacción).
  • Top-5 Accuracy: 0.91. Esto es clave para la adopción, ya que transforma el rol del codificador de un generador a un validador, reduciendo la carga cognitiva.
  • Tasa de Automatización: 94%. El 6% de los casos derivados a revisión manual corresponden principalmente a informes con múltiples comorbilidades complejas, diagnósticos raros o redacción ambigua.
• Predicción de la Duración de la Estancia:
  • Coeficiente de Determinación (R²): 0.45. Explica casi la mitad de la variabilidad, un resultado robusto para un fenómeno tan complejo.
  • Error Absoluto Medio (MAE): 1.8 días. En promedio, la predicción del modelo se desvía menos de dos días de la estancia real, una precisión suficiente para la planificación a nivel de unidad.
  • Precisión para Estancias Prolongadas (>7 días) (AUC): 0.81. El modelo es especialmente bueno identificando a los pacientes que requerirán más recursos, permitiendo una gestión proactiva.

3.2. Casos de Uso Implementados

• Caso de Uso 1: Optimización del Proceso de Codificación en Urgencias.
  • Resultado Operacional: El tiempo de codificación por caso se redujo de ~6 minutos a menos de 30 segundos. Esto libera 28 horas de trabajo administrativo por día en un hospital con 300 urgencias diarias. Un administrativo comenta: «He pasado de ser un introductor de datos a un auditor de calidad. En lugar de buscar códigos durante horas, ahora valido las sugerencias de la IA en segundos y dedico mi tiempo a los casos complejos, donde un error de codificación tiene un mayor impacto financiero y clínico.»
• Caso de Uso 2: Gestión de Camas en Planta.
  • Resultado Operacional: Un dashboard muestra las altas probables para los próximos 3 días. El «antes» era una pizarra blanca y llamadas constantes. El «después» es una herramienta que permite al gestor de planta simular escenarios («¿qué pasa si retrasamos estas 3 cirugías?») y coordinar con el servicio de limpieza y admisión de forma mucho más eficiente, reduciendo el tiempo de cama vacía entre pacientes en un 15%.
• Caso de Uso 3 (Añadido): Farmacovigilancia Activa.
  • Escenario: Detectar Reacciones Adversas a Medicamentos (RAM) que a menudo no se reportan formalmente.
  • Implementación: Un microservicio adicional analiza las notas de evolución buscando patrones que sugieran una RAM (e.g., «paciente inicia [FÁRMACO X] y desarrolla rash cutáneo»).
  • Resultado Operacional: El sistema marca 5-10 casos sospechosos por día para revisión por el servicio de farmacia. Esto crea un sistema de vigilancia activa que complementa al sistema de reporte voluntario, mejorando la seguridad del paciente.

3.3. Comparativa con Soluciones Existentes

Característica	Proceso Manual	Modelo NLP General (GPT-4)	Arquitectura Propuesta
Precisión Codificación	Variable, ~85-95%	~26-36%	72% (F1), 91% (Top-5)
Tiempo por Caso	5-25 minutos	~1 minuto	< 30 segundos
Coste por Caso	Alto (personal)	Medio (API)	Bajo (tras amortización)
Consistencia	Baja	Alta	Muy Alta
Cumplimiento RGPD	Procesos manuales	Riesgo alto (datos a terceros)	Diseñado para Cumplimiento
Escalabilidad	Lineal (más gente)	Depende del proveedor	Horizontal (más nodos)
Interpretabilidad	Depende del humano	Caja negra	Parcial (vía LIME/SHAP)

3.4. Evidencia Clínica de Eficacia

El impacto clínico es principalmente indirecto pero profundo. La mejora en la calidad de la codificación tiene un efecto dominó: mejora la precisión de los Grupos Relacionados por el Diagnóstico (GRD), lo que lleva a una financiación más justa; proporciona datos más fiables para la investigación epidemiológica; y permite auditorías de calidad más precisas. La farmacovigilancia activa tiene un impacto directo en la seguridad del paciente. La reducción de la carga administrativa, como subraya Topol en «Deep Medicine», es clave para combatir el burnout y devolver tiempo a los clínicos para la interacción humana con el paciente.

4. Discusión

Los resultados proyectados validan la viabilidad de la arquitectura propuesta, pero el éxito de su implementación depende de una comprensión profunda de sus limitaciones y de una estrategia de despliegue que vaya más allá de la tecnología.

4.1. Análisis Crítico de los Resultados

El concepto clave es la «IA Centauro»: la máquina realiza el trabajo pesado de análisis y el humano aporta el juicio, el contexto y la supervisión. La precisión del 91% en el Top-5 para la codificación es el ejemplo perfecto. El sistema no pretende tener una precisión del 100%, lo cual es irreal. Su objetivo es aumentar la capacidad humana, no reemplazarla. Este modelo de colaboración es fundamental en medicina, donde el juicio contextual es insustituible y se busca mitigar activamente los riesgos de una ‘caja negra’ totalmente autónoma en la toma de decisiones críticas.

El R² de 0.45 en la predicción de estancias, aunque pueda parecer bajo, es extremadamente valioso en un sistema caótico. La gestión hospitalaria es un juego de probabilidades. Poder inclinar esas probabilidades a favor del gestor, incluso modestamente, tiene un impacto agregado enorme en la eficiencia de todo el hospital.

4.2. Limitaciones Identificadas

1. Sesgo Algorítmico: Es la amenaza más insidiosa. Mitigación: Además de auditar los datos, se pueden aplicar técnicas de adversarial debiasing, donde un segundo modelo intenta predecir el atributo sensible (e.g., etnia) a partir de las representaciones internas del modelo principal, y el modelo principal es penalizado por permitirlo. Es crucial establecer un comité de ética de IA multidisciplinar en el hospital.
2. Integración con Sistemas Legacy: Mitigación: Un enfoque por fases es vital. Empezar con una integración unidireccional y de solo lectura (extracción de datos). Utilizar estándares como FHIR como capa intermedia, incluso si el HIS no es nativo, para desacoplar la lógica de la fuente de datos.
3. Generalización y Mantenimiento (MLOps): Mitigación: La arquitectura debe incluir un framework de MLOps (e.g., MLflow, Kubeflow). Se debe monitorizar la deriva de los datos (cambios en la forma de escribir de los médicos) y la deriva del concepto (cambios en las guías clínicas). Se debe planificar un reentrenamiento semestral o anual.

4.3. Implicaciones para la Práctica Clínica y la Gestión

• Para la Gestión: El ROI del 500% se descompone en: 60% por ahorros directos en horas de codificación, 30% por la optimización de camas (menos cancelaciones, más cirugías), y 10% por la mejora en la facturación basada en GRD y la reducción de riesgos por auditorías.
• Para el Personal de Codificación: Se abre una nueva vía de desarrollo profesional hacia roles de «analista de datos clínicos» o «auditor de calidad de IA».
• Para el Personal Clínico: La estandarización y mejora de los datos facilita la investigación clínica interna y la participación en estudios multicéntricos.

4.4. Futuras Líneas de Investigación

• Detección de Eventos Adversos: El siguiente paso es pasar de la detección a la predicción, identificando pacientes en riesgo antes de que ocurra el evento.
• Análisis Multimodal: Integrar el análisis de texto con el análisis de series temporales (ECG, constantes vitales) para crear modelos de pronóstico mucho más potentes.
• Federated Learning: La implementación técnica implicaría que cada hospital del SAS entrene el modelo localmente. Luego, en lugar de enviar los datos, envían solo las actualizaciones de los pesos del modelo (gradientes) a un servidor central que los agrega de forma segura para crear un modelo global mejorado, sin que los datos de los pacientes salgan nunca del hospital.
• IA Generativa para Resúmenes: El uso de LLMs para generar borradores de informes de alta es prometedor, pero requiere un marco de «RAG» (Retrieval-Augmented Generation) que base la generación en hechos extraídos del HCE del paciente para minimizar las «alucinaciones» y garantizar la veracidad fáctica.

En conclusión, la tecnología está lista. El desafío ya no es si el PLN puede funcionar en medicina, sino cómo implementarlo de manera responsable, ética y eficaz dentro de las complejas realidades del entorno hospitalario español, transformándolo de una carga administrativa a un activo estratégico.

5. Referencias

1. Alsentzer, E., et al. (2019). Publicly Available Clinical BERT Embeddings. arXiv:1904.03323.
2. Bellamy, R. K. E., et al. (2019). Aequitas: A Bias and Fairness Audit Toolkit. arXiv:1811.05577.
3. Boag, W., et al. (2018). What’s in a note? Unpacking the complexity of clinical text. Journal of the American Medical Informatics Association.
4. European Commission. (2021). Proposal for a Regulation on a European approach for Artificial Intelligence (AI Act).
5. García-Pablos, A., et al. (2021). Overview of MEDDOCAN: Medical Document Anonymization. Proceedings of the Iberian Languages Evaluation Forum (IberLEF 2021).
6. Generalitat de Catalunya. (2023). CARMEN-I: A new public database for the advancement of clinical information extraction technologies. Hospital Clínic Barcelona.
7. González-Agirre, A., et al. (2023). MedLexSp: A Comprehensive Medical Lexicon for Spanish. Biomedical Informatics Insights.
8. Intermountain Healthcare. (2022). Using AI to Improve Patient Outcomes and Reduce Costs. Healthcare Innovation.
9. Jackson, G. P., et al. (2017). CogStack – an information retrieval and extraction platform for clinical text. BMC Medical Informatics and Decision Making.
10. Kairouz, P., et al. (2021). Advances and Open Problems in Federated Learning. Foundations and Trends® in Machine Learning.
11. Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales. Boletín Oficial del Estado.
12. Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401.
13. Lundberg, S. M., & Lee, S. I. (2017). A Unified Approach to Interpreting Model Predictions. Advances in Neural Information Processing Systems 30.
14. Pérez-Pérez, M., et al. (2023). Development and validation of an algorithm based on artificial intelligence for the surveillance of surgical site infection (AI-HPRO). PubMed.
15. Pineda, J., et al. (2023). Development of the first large-scale medical language models in Spanish. ACL Anthology.
16. Sistema Andaluz de Salud (SAS). (2024). EVIAS: Evaluación y Validación de Inteligencia Artificial en Salud. Agencia de Calidad Sanitaria de Andalucía.
17. So, D., et al. (2022). Predicting hospital length of stay using machine learning: a systematic review. BMC Health Services Research.
18. Topol, E. J. (2023). Deep Medicine: How Artificial Intelligence Can Make Healthcare Human Again. Basic Books.
19. U.S. Department of Veterans Affairs. (2024). AI at VA: Transforming Veteran Care. VA News.
20. Wu, S., et al. (2020). A comparison of deep learning models for ICD-10 coding. Journal of Medical Internet Research.

21. Zech, J. R., et al. (2018). Variable generalization performance of a deep learning model to detect pneumonia in chest radiographs: a cross-sectional study. PLoS medicine.