Integración de datos sanitarios para IA: cómo evitar decisiones basadas en información fragmentada

Un hospital quiere utilizar inteligencia artificial para ayudar a sus profesionales a localizar información relevante antes de una consulta. El primer piloto funciona: la IA puede leer informes, resumirlos y responder preguntas sobre el historial disponible.

El problema aparece cuando se intenta ampliar el proyecto. Parte de los resultados de laboratorio están en otro sistema, la medicación utiliza nomenclaturas diferentes según el origen, algunos antecedentes solo existen en documentos PDF y los dispositivos generan información en una plataforma independiente. Además, hay registros duplicados y determinadas actualizaciones llegan con horas de diferencia.

La IA sigue funcionando técnicamente, pero ahora trabaja sobre una visión incompleta del paciente.

Este es uno de los retos menos visibles al incorporar inteligencia artificial y datos clínicos: la calidad del resultado no depende únicamente del modelo utilizado. Depende también de qué información recibe, cómo está estructurada, de dónde procede, cuándo se actualizó y qué significado tiene dentro del proceso sanitario.

Por eso, antes de preguntarse qué modelo de IA utilizar, muchas organizaciones necesitan resolver algo anterior: cómo construir una integración de datos sanitarios capaz de proporcionar información coherente, trazable y útil para el caso de uso que quieren desarrollar.

Una IA potente no corrige por sí sola una arquitectura de datos fragmentada.

El problema no es tener pocos datos, sino tenerlos desconectados

Las organizaciones sanitarias generan una cantidad enorme de información:

• Historia clínica.
• Resultados de laboratorio.
• Pruebas de imagen.
• Prescripción.
• Citas.
• Urgencias.
• Informes médicos.
• Cuestionarios.
• Datos administrativos.
• Dispositivos conectados.
• Aplicaciones de seguimiento.
• Información comunicada por el propio paciente.

El reto no suele ser la ausencia de datos, sino que cada información puede encontrarse en un sistema diferente, haberse creado con una estructura distinta y responder a una finalidad concreta. Una aplicación conoce unas variables, el HIS otras, el laboratorio utiliza sus propios códigos, un dispositivo envía sus mediciones mediante una API y parte de la información histórica continúa almacenada en documentos.

Un proyecto de IA puede acabar trabajando únicamente con aquello que resulta más sencillo conectar. Eso crea una situación engañosa: el sistema parece tener contexto porque dispone de muchos datos, aunque en realidad tenga una visión parcial de la situación.

La Organización Mundial de la Salud señala que una buena gobernanza de datos sanitarios debe favorecer la interoperabilidad, el intercambio y la calidad del dato, y que estas condiciones resultan especialmente importantes cuando la información se utiliza en sistemas de inteligencia artificial.

En otras palabras: antes de desarrollar una capa inteligente, necesitamos saber sobre qué base de información estamos construyéndola.

Integrar datos no significa simplemente conectarlos

Dos sistemas pueden intercambiar información y seguir sin entenderse correctamente. Imaginemos que una aplicación consigue leer los datos de otro sistema mediante una API. Técnicamente existe conexión, pero todavía necesitamos saber:

• Qué significa cada campo.
• En qué unidad está expresado.
• Cuándo se registró.
• Quién lo generó.
• Si ha sido validado.
• Si existe una versión posterior.
• A qué paciente corresponde.
• Qué código clínico utiliza.
• Si puede utilizarse para ese propósito.
• Qué ocurre cuando falta.

Por eso conviene diferenciar tres niveles:

La interoperabilidad es una condición muy importante, pero interoperable no significa automáticamente preparado para IA. Una arquitectura puede transmitir perfectamente un dato incorrecto, incompleto o desactualizado.

Qué ocurre cuando una IA trabaja con información fragmentada

Una persona puede detectar muchas inconsistencias utilizando su experiencia y el contexto. Un sistema automático depende mucho más de la información que ponemos a su disposición. Esto genera varios riesgos.

Respuestas basadas en una parte del historial

Si el asistente solo tiene acceso a determinados documentos, puede elaborar una respuesta aparentemente completa sin saber que existe información relevante en otro sistema. La ausencia de un dato no siempre significa que ese dato no exista; puede significar simplemente que la integración no lo está proporcionando.

Duplicidades

El mismo paciente puede aparecer con identificadores distintos o tener información repetida procedente de varias fuentes. Si no existe una estrategia de reconciliación, el sistema puede interpretar registros duplicados como hechos diferentes.

Información desactualizada

No es lo mismo conocer qué medicación tenía prescrita una persona hace seis meses que conocer su tratamiento actual. La fecha y el estado del dato forman parte de su significado.

Diferencias semánticas

Dos sistemas pueden utilizar nombres diferentes para el mismo concepto o el mismo término para conceptos que no son exactamente equivalentes. Aquí aparece la importancia de terminologías clínicas y modelos de datos compartidos.

Ausencia de procedencia

Si una IA utiliza una información para generar una respuesta, necesitamos poder saber de dónde procede: si la introdujo el paciente, proviene del laboratorio, fue validada por un profesional, la generó un dispositivo o la produjo anteriormente otro modelo. La procedencia cambia cuánto podemos confiar en un dato y qué podemos hacer con él.

Sesgos en el conjunto de información

Un sistema puede funcionar correctamente con los datos de una población o un centro y comportarse de forma diferente cuando cambia el contexto. La OMS vincula la gobernanza de los datos con la necesidad de disponer de conjuntos de información de calidad y suficientemente representativos para reducir riesgos relacionados con sesgos y desigualdades.

La consecuencia es sencilla: no podemos evaluar únicamente la calidad del modelo. También debemos evaluar la calidad de la información que alimenta al modelo.

Qué necesita un dato sanitario para ser útil

Podemos pensar en la calidad del dato sanitario como algo bastante más amplio que comprobar si un campo está vacío. Para que una información pueda utilizarse de forma fiable necesitamos valorar diferentes dimensiones.

Exactitud

¿El dato representa correctamente lo ocurrido? Un error de transcripción o una unidad incorrecta pueden modificar completamente su interpretación.

Completitud

¿Disponemos de la información necesaria? No todos los campos tienen que estar siempre completos, pero hay que saber qué ausencias son esperables y cuáles comprometen el caso de uso.

Actualidad

¿Sigue siendo válido? La relevancia temporal cambia mucho dependiendo de si hablamos de una alergia, una medicación, una analítica o una cita.

Consistencia

¿La información coincide entre sistemas? Si dos fuentes muestran valores distintos, debemos definir cuál prevalece o cómo se presenta la discrepancia.

Estandarización

¿La información utiliza formatos y terminologías que permiten interpretarla de forma consistente?

Procedencia

¿Sabemos quién o qué sistema produjo el dato?

Trazabilidad

¿Podemos reconstruir qué transformaciones ha sufrido desde su origen hasta llegar al sistema que lo utiliza?

Adecuación al propósito

¿Ese dato es adecuado para lo que queremos hacer con él? Un conjunto de información puede tener suficiente calidad para elaborar estadísticas administrativas y no ser adecuado para apoyar un determinado uso clínico.

La calidad no existe de forma abstracta. Siempre hay que relacionarla con la decisión o proceso que queremos soportar.

Las capas de una arquitectura de datos preparada para IA

Una arquitectura de datos en salud no debería diseñarse empezando por el modelo de inteligencia artificial. Conviene pensar primero en las capas que permitirán que diferentes soluciones utilicen los datos de forma controlada.

1. Fuentes

Aquí encontramos los sistemas que generan o almacenan información:

• HCE o HIS.
• LIS de laboratorio.
• RIS/PACS.
• CRM.
• ERP.
• Plataformas de telemedicina.
• Apps.
• Wearables.
• Dispositivos médicos.
• Cuestionarios.
• Servicios externos.
• Repositorios documentales.

En GooApps® ya analizamos específicamente el reto de conectar sensores y hardware clínico en nuestra guía de integración de dispositivos médicos. Aquí damos un paso posterior: qué ocurre cuando todos esos datos deben combinarse con otras fuentes para alimentar aplicaciones analíticas o de inteligencia artificial.

2. Integración

Es la capa que permite recuperar, recibir o intercambiar información. Puede trabajar mediante APIs, HL7, FHIR, mensajería, eventos, procesos ETL o ELT, conectores específicos e integraciones con sistemas legacy. No existe una única arquitectura válida para todos los hospitales.

3. Normalización y semántica

La información procedente de diferentes fuentes debe poder compararse. Aquí entran mapeos, unidades, terminologías, identificadores, reglas de transformación y modelos de datos comunes. Esta capa evita que cada nuevo proyecto vuelva a resolver desde cero los mismos problemas de interpretación.

4. Calidad y validación

Antes de exponer el dato a otros sistemas conviene comprobar formato, rango, completitud, coherencia, duplicados, actualidad y origen.

5. Gobierno y permisos

No cualquier aplicación necesita acceder a toda la información. Hay que definir qué datos existen, quién es responsable, quién puede acceder, para qué finalidad, durante cuánto tiempo y qué acciones quedan registradas.

6. Consumo

Solo después llegamos a las aplicaciones que utilizan la información: dashboards, plataformas de seguimiento, analítica, asistentes conversacionales, motores de búsqueda clínica, algoritmos predictivos o soluciones generativas.

La IA es consumidora de una arquitectura de datos; no debería convertirse en la arquitectura de datos.

Interoperabilidad sanitaria: por qué FHIR ayuda, pero no resuelve todo

Cuando hablamos de integración de datos clínicos, FHIR, Fast Healthcare Interoperability Resources, aparece rápidamente. Es el estándar publicado por HL7® para el intercambio electrónico de información sanitaria y organiza la información en recursos que pueden representar conceptos como pacientes, profesionales, observaciones, diagnósticos, medicación o citas.

Su importancia para la IA es fácil de entender. HL7 señala que, para permitir procesamiento automático y sistemas de soporte a la decisión, los datos sanitarios deben estar estructurados y estandarizados. FHIR facilita ese objetivo porque proporciona una forma compartida de representar e intercambiar información.

Pero implementar FHIR no soluciona automáticamente:

• Registros duplicados.
• Información incorrecta.
• Campos incompletos.
• Diferencias entre terminologías.
• Datos antiguos.
• Falta de consentimiento.
• Ausencia de trazabilidad.
• Modelos de información mal definidos.

Incluso dentro de FHIR hay que decidir qué códigos y terminologías utiliza cada elemento. La propia especificación contempla la utilización de sistemas terminológicos externos como SNOMED CT o LOINC y herramientas para mapear conceptos entre sistemas.

Por eso la interoperabilidad sanitaria debe verse como un proyecto funcional y semántico, no únicamente como una integración técnica. FHIR permite que los sistemas intercambien información; el diseño de datos determina si esa información mantiene el significado que necesitamos.

Calidad del dato: qué debería comprobarse antes de utilizar IA

Antes de entrenar, conectar o desplegar una solución de IA sobre datos sanitarios, conviene responder a varias preguntas.

¿De dónde procede la información?

Debe existir un inventario de las fuentes relevantes.

¿Qué porcentaje está realmente disponible?

Una prueba realizada con veinte pacientes no debería asumir que todos los registros futuros tendrán el mismo nivel de completitud.

¿Cómo se representan las ausencias?

“No registrado”, “no aplica”, “negativo” y “desconocido” no significan lo mismo.

¿Hay cambios históricos de estructura?

Un campo puede haber cambiado de formato tras una migración.

¿Existen duplicados?

No solo de pacientes. También de pruebas, eventos o documentos.

¿Qué información es texto libre?

Los informes narrativos contienen gran cantidad de conocimiento, pero requieren un tratamiento distinto al de los datos estructurados.

¿Se conserva la dimensión temporal?

Para una IA sanitaria no basta con saber qué ocurrió. También suele importar cuándo ocurrió y cuál fue la secuencia.

¿Tenemos suficiente representatividad?

Si el modelo se validó sobre un subconjunto muy específico, no deberíamos asumir que funcionará igual en poblaciones diferentes.

Este diagnóstico puede cambiar el propio proyecto. A veces descubrimos que la prioridad no es desarrollar inmediatamente una IA más avanzada, sino mejorar primero la base de datos sobre la que va a trabajar.

¿Quieres aplicar IA pero tus datos están distribuidos entre varios sistemas?

Analiza tu proyecto

Identidad, contexto y trazabilidad

Hay tres elementos especialmente importantes cuando combinamos múltiples fuentes.

Saber que hablamos de la misma persona

Un paciente puede tener diferentes identificadores según el sistema. Si no existe una estrategia de identificación y reconciliación, podemos acabar duplicando personas, uniéndolas incorrectamente, dejando fuera información relevante o asociando información a quien no corresponde. Dependiendo del entorno, puede ser necesario trabajar con mecanismos de master patient index, reglas de emparejamiento o identificadores maestros.

Entender el contexto

Un valor aislado puede ser ambiguo. Necesitamos conocer fecha, unidad, procedencia, estado, episodio, profesional, dispositivo y relación con otros eventos. El contexto no debería reconstruirse mediante suposiciones del modelo; debe viajar con la información siempre que sea relevante.

Saber de dónde salió cada respuesta

Si una solución de IA presenta información clínica al profesional, debería ser posible relacionar sus afirmaciones con las fuentes utilizadas cuando el caso de uso lo requiera. Esto es especialmente importante en sistemas basados en recuperación de información o RAG.

No basta con que el modelo responda “El paciente presenta antecedentes de X”. Deberíamos poder identificar qué documento o registro respaldó esa información, cuándo se generó y si sigue siendo válido. La trazabilidad ayuda a transformar una respuesta generada en una información que el profesional puede comprobar.

¿Hay que centralizar todos los datos?

No. Hablar de integración no significa necesariamente construir una gigantesca base de datos con una copia de toda la información del hospital. Dependiendo del caso pueden utilizarse distintas estrategias.

Acceso federado

Los datos permanecen en sus sistemas y se consultan cuando hacen falta.

Repositorio intermedio

Determinadas informaciones se normalizan y almacenan en una capa preparada para consumo.

Data lake o lakehouse

Puede ser adecuado cuando existen necesidades amplias de analítica, investigación o explotación de grandes volúmenes de información.

Arquitectura híbrida

Parte de los datos se centraliza y otra parte continúa consultándose en origen.

La decisión depende de la latencia, el volumen, la seguridad, la disponibilidad, los casos de uso, los sistemas existentes, la gobernanza, la regulación y el coste. El objetivo no debería ser mover datos por moverlos, sino hacer accesible la información necesaria de la forma adecuada para cada uso.

Cómo limitar qué información puede utilizar cada solución de IA

Una IA no necesita conocer todo lo que sabe una organización. Si estamos creando un asistente para gestionar preparación de pruebas, probablemente no necesite acceso al historial clínico completo. Si desarrollamos una herramienta que resume un episodio concreto, quizá solo necesite determinados documentos y resultados.

Este principio reduce riesgo y complejidad. Una arquitectura debería definir:

Qué fuentes puede consultar

No todos los sistemas deben estar disponibles para todos los productos.

Qué campos puede recuperar

Incluso dentro de una fuente puede limitarse la información.

Qué operaciones puede realizar

Consultar no es lo mismo que modificar.

En qué contexto

Los permisos pueden depender del usuario, organización, episodio o finalidad.

Qué queda registrado

Las consultas y acciones relevantes deberían ser auditables.

Esto conecta directamente con el enfoque que aplicamos en Comunicación asistencial digital: cómo pasar de un chatbot aislado a una experiencia conectada: una experiencia conectada no significa que todos los sistemas compartan todos sus datos, sino que cada canal pueda acceder a la información y acciones necesarias para cumplir su función.

Del piloto aislado a una IA integrada en el sistema sanitario

Muchos proyectos empiezan de forma lógica con un alcance reducido. Se exportan unos documentos, se prepara una base vectorial, se conecta un modelo, se desarrolla una interfaz y el equipo comprueba que existe valor. Es una buena forma de validar la idea.

El problema aparece cuando se intenta transformar ese piloto en un producto:

Este paso es muy parecido al problema que analizamos al hablar de vibe coding vs. desarrollo profesional asistido por IA en salud: demostrar técnicamente que algo puede hacerse es solo una parte del proyecto. Después hay que diseñar cómo funcionará dentro del ecosistema real.

El Espacio Europeo de Datos de Salud y el nuevo escenario de interoperabilidad

La integración de datos sanitarios no responde únicamente a la llegada de la inteligencia artificial. Europa está avanzando hacia un entorno donde la interoperabilidad tendrá cada vez más peso.

El Reglamento relativo al Espacio Europeo de Datos de Salud (EEDS) entró en vigor el 26 de marzo de 2025 y establece un marco europeo para facilitar el acceso, intercambio y reutilización de datos electrónicos de salud. Su aplicación será progresiva.

Entre los hitos previstos:

• En marzo de 2027 deberían estar aprobados varios actos de ejecución.
• En marzo de 2029 comenzará la aplicación de partes clave relacionadas con historias clínicas resumidas y recetas y dispensaciones electrónicas.
• En marzo de 2031 se incorporarán otras categorías prioritarias, como imágenes médicas, resultados de laboratorio e informes de alta.

El EEDS también establece requisitos de interoperabilidad y seguridad para determinados sistemas de historia clínica electrónica. Para hospitales, aseguradoras y empresas HealthTech, esto refuerza una dirección que ya era necesaria desde el punto de vista tecnológico: el dato sanitario debe poder moverse con garantías, conservar su significado y utilizarse dentro de marcos claros de gobernanza. Esa misma base es la que necesitan las aplicaciones de IA.

Cómo plantear un proyecto de integración de datos para IA

En GooApps® no empezaríamos preguntando qué modelo quiere utilizar la organización. Empezaríamos por el caso de uso.

Discover: definir qué queremos conseguir

¿Queremos ayudar al profesional a localizar información, resumir episodios, priorizar casos, analizar evolución, automatizar documentación, construir un asistente para pacientes o crear modelos predictivos? Cada objetivo necesita datos distintos.

Durante esta fase identificamos usuarios, decisiones, sistemas, información necesaria, restricciones, riesgos, procesos existentes y resultado esperado.

Define: mapear el recorrido del dato

Después diseñamos cómo llega la información desde el sistema de origen hasta la aplicación. Hay que decidir:

• Fuente de verdad.
• Método de integración.
• Modelo de datos.
• Identificadores.
• Terminologías.
• Reglas de transformación.
• Calidad mínima.
• Frecuencia de actualización.
• Permisos.
• Trazabilidad.
• Gestión de errores.

La arquitectura se diseña alrededor del caso de uso, no alrededor del modelo de IA.

Develop: construir la integración y evaluarla junto a la IA

Las pruebas no deberían limitarse a comprobar que “la API responde”. Hay que validar:

• Que los datos corresponden al paciente correcto.
• Que no se pierden campos relevantes.
• Que los códigos se interpretan correctamente.
• Que las actualizaciones llegan.
• Que las unidades son consistentes.
• Que los permisos se respetan.
• Que los errores quedan registrados.
• Que la IA utiliza la información correcta.

Nuestra guía sobre integración de dispositivos médicos profundiza precisamente en la necesidad de testing automatizado, normalización y capas intermedias para evitar integraciones frágiles. Para la IA añadimos otra capa de pruebas: ¿cómo cambia el resultado cuando cambia la calidad de los datos?

Deliver: monitorizar también los datos

Una solución puede funcionar correctamente en el lanzamiento y degradarse después. Un sistema cambia de API, un campo deja de rellenarse, aparece una nueva nomenclatura, una migración modifica identificadores, se incorpora otro centro o cambia la frecuencia de actualización.

Por eso hay que monitorizar no solo el software, sino también la salud del dato. Una arquitectura madura debería poder detectar esas desviaciones antes de que aparezcan como errores silenciosos en la IA.

Este enfoque coincide con nuestra metodología para desarrollar soluciones de inteligencia artificial en GooApps®: Discover, Define, Develop y Deliver, integrando arquitectura, desarrollo y evolución continua en lugar de tratar la IA como una herramienta aislada.

Una capa de IA no sustituye a una estrategia de datos

En nuestra guía de casos de uso de IA en salud analizamos aplicaciones que combinan información procedente de historiales, documentación clínica, comportamiento, resultados y otras fuentes. Son casos de uso atractivos precisamente porque pueden relacionar información que antes era difícil analizar conjuntamente.

Pero esa capacidad tiene una condición: los datos tienen que estar disponibles de una forma que la aplicación pueda utilizar con suficiente fiabilidad. Por eso una organización puede encontrarse en situaciones muy diferentes:

1. Nivel 1. Tenemos muchos datos, pero no sabemos exactamente dónde están.
2. Nivel 2. Sabemos dónde están, pero los sistemas no están conectados.
3. Nivel 3. Podemos conectarlos, pero cada fuente utiliza estructuras diferentes.
4. Nivel 4. Hemos normalizado la información, pero existen problemas de calidad.
5. Nivel 5. Tenemos datos integrados y gobernados para casos de uso concretos.
6. Nivel 6. Podemos desarrollar y escalar aplicaciones de IA sobre esa base.

Intentar saltar directamente del nivel 1 al 6 suele producir pilotos llamativos y productos difíciles de operar.

Qué medir para saber si la arquitectura está funcionando

Una arquitectura de datos no debería evaluarse únicamente por disponibilidad técnica. Conviene definir indicadores.

Calidad

• Registros incompletos.
• Duplicados.
• Errores de formato.
• Inconsistencias.
• Mapeos incorrectos.

Actualidad

• Tiempo entre origen y disponibilidad.
• Fuentes retrasadas.
• Eventos perdidos.

Integración

• Errores de API.
• Procesos fallidos.
• Volumen procesado.
• Disponibilidad.

Identidad

• Pacientes duplicados.
• Registros sin reconciliar.
• Emparejamientos dudosos.

Uso

• Fuentes consultadas.
• Casos de uso activos.
• Aplicaciones consumidoras.

IA

• Respuestas sin suficiente contexto.
• Errores atribuibles a datos.
• Fuentes no disponibles.
• Recuperaciones incorrectas.
• Casos enviados a revisión.

Separar estos indicadores permite distinguir algo muy importante: ¿ha fallado el modelo o ha fallado la información que recibió? Sin esa observabilidad, ambos problemas pueden parecer exactamente iguales desde la interfaz.

La IA empieza mucho antes del modelo

Cuando una organización decide incorporar inteligencia artificial, es natural que la atención se dirija hacia el modelo: qué tecnología utilizar, qué capacidad tiene, qué puede automatizar o qué respuestas genera.

Pero en salud, una parte decisiva del trabajo ocurre antes. Hay que identificar las fuentes correctas, conectar sistemas, resolver identidades, conservar el significado de los datos, comprobar su calidad, definir permisos y mantener trazabilidad. Solo entonces la IA puede trabajar con un contexto que represente suficientemente bien la realidad sobre la que queremos actuar.

La integración de datos sanitarios no es, por tanto, un problema secundario de infraestructura. Es una parte del producto.

En GooMedical®, nuestra línea especializada en soluciones digitales para salud, trabajamos con hospitales, entidades médicas y empresas HealthTech en proyectos que combinan apps, interoperabilidad, IoT, analítica e inteligencia artificial dentro de arquitecturas adaptadas al entorno sanitario.

También colaboramos directamente con hospitales, institutos de investigación, universidades y profesionales para desarrollar soluciones sobre necesidades reales, como explicamos en nuestros marcos de colaboración con entidades médicas.

Una IA solo puede interpretar aquello que somos capaces de poner a su disposición. Y cuanto más importante sea la decisión, más importante será poder confiar en los datos que hay detrás.

Preguntas frecuentes

¿Es necesario crear un data lake antes de empezar un proyecto de IA sanitaria?

No. La arquitectura debe responder al caso de uso. Algunos proyectos pueden trabajar mediante APIs sobre los sistemas existentes; otros necesitarán un repositorio normalizado y otros justificarán una arquitectura de datos más amplia. Construir un data lake sin saber qué problemas va a resolver puede añadir coste y complejidad sin mejorar el producto.

¿Puede conectarse una IA directamente con la historia clínica electrónica?

Técnicamente puede ser posible si el sistema ofrece mecanismos de integración adecuados, pero no significa que deba disponer de acceso indiscriminado. Conviene utilizar una capa que controle qué información puede consultar, cómo se transforma, qué permisos se aplican y qué acciones quedan registradas.

¿Qué ocurre si un hospital utiliza sistemas antiguos sin APIs modernas?

Los sistemas legacy son habituales en sanidad. Dependiendo de la plataforma pueden utilizarse interfaces HL7, motores de integración, exportaciones estructuradas, conectores específicos u otras capas intermedias. La estrategia debe evaluarse caso por caso para evitar dependencias frágiles y preservar la seguridad del sistema existente.

¿Se pueden utilizar datos sanitarios anonimizados para desarrollar soluciones de IA?

En determinados casos sí, pero anonimización y seudonimización no son equivalentes y tienen implicaciones diferentes. También hay que analizar la finalidad, base jurídica, procedencia y requisitos aplicables. El EEDS establece además un marco específico para el uso secundario de datos de salud y entornos seguros de tratamiento. Antes de preparar un dataset conviene definir primero para qué se utilizará y qué nivel de identificación necesita realmente el proyecto.

¿Qué debería pedir a un proveedor tecnológico antes de darle acceso a datos sanitarios?

Además de aspectos contractuales y de protección de datos, conviene conocer qué información necesita, por qué la necesita, dónde se procesará, qué proveedores o modelos intervienen, qué datos se conservarán, cómo se controla el acceso, qué logs existen, cómo se gestionan incidencias y cómo pueden auditarse los resultados. En una solución de IA también debería quedar claro qué información se utiliza para generar cada resultado y qué mecanismos de supervisión existen.

¿Quieres aplicar IA sobre datos clínicos distribuidos entre varios sistemas?

Conoce nuestros servicios