Respuesta corta: una evaluación de impacto relativa a la protección de datos (EIPD) es el documento en el que se describe una operación de tratamiento, se demuestra que es necesaria y proporcionada, se evalúan los riesgos para las personas cuyos datos utiliza y se registran las medidas que reducen dichos riesgos. El artículo 35 del RGPD la hace obligatoria cuando el tratamiento es susceptible de resultar en un alto riesgo, y menciona el tratamiento a gran escala de categorías especiales, que incluye los datos de salud, como un caso. En la práctica, cada aplicación de salud con más de unos pocos usuarios y cada plataforma de datos de salud necesita una, antes de que comience el tratamiento, revisada cuando el tratamiento cambie. La plantilla a continuación sigue el artículo 35(7) y las directrices europeas; descárguela al final.
Cuándo se requiere
Se requiere una EIPD (Evaluación de Impacto relativa a la Protección de Datos) según el Artículo 35 del RGPD siempre que el tratamiento sea susceptible de generar un alto riesgo, y el tratamiento a gran escala de categorías especiales como los datos de salud se menciona como un desencadenante automático. Según los criterios del Comité Europeo de Protección de Datos (CEPD), una aplicación de salud suele cumplir varios requisitos (datos sensibles, gran escala, personas vulnerables), por lo que casi todas las aplicaciones de salud necesitan una antes de que comience el tratamiento.
El artículo 35(3) enumera tres desencadenantes automáticos: perfilado sistemático y exhaustivo con efectos significativos; tratamiento a gran escala de categorías especiales (artículo 9) o datos delictivos; monitorización sistemática a gran escala de zonas de acceso público. Los criterios de la Junta Europea de Protección de Datos (de la anterior Grupo de Trabajo del Artículo 29) añaden seis más; si se aplican dos o más, realice una EIPD: evaluación o puntuación; decisiones automatizadas con efectos jurídicos o similares; monitorización sistemática; datos sensibles; gran escala; cotejo o combinación de conjuntos de datos; datos sobre personas vulnerables (los pacientes cuentan); uso innovador de la tecnología; impedimento a las personas para ejercer un derecho o utilizar un servicio. Una aplicación de salud suele incluir datos sensibles, gran escala, personas vulnerables y, a menudo, tecnología innovadora. Las autoridades nacionales también publican listas de tratamientos que siempre requieren una EIPD (artículo 35(4)); la mayoría incluyen aplicaciones de salud y dispositivos conectados.
La lista de verificación
Una lista de verificación de EIPD para aplicaciones de salud sigue los cuatro elementos del Artículo 35(7) del RGPD: una descripción del tratamiento (fines, datos, actores, tecnología), una evaluación de la necesidad y la proporcionalidad (base jurídica, minimización, derechos, encargados del tratamiento, conservación), una evaluación de los riesgos para las personas cuyos datos se utilizan y las medidas que abordan esos riesgos, seguida de consulta, aprobación y revisión periódica.
1. Describir el tratamiento (Art. 35(7)(a))
- Finalidades, una por una: almacenamiento de los registros de la persona; intercambio con una clínica; recordatorios; estadísticas anonimizadas; funciones de IA.
- Categorías de datos por finalidad, marcando los datos de salud; fuentes (la persona, clínicas, wearables, documentos); destinatarios; conservación por categoría; transferencias fuera de la UE y su mecanismo.
- Actores: responsable(s), encargados del tratamiento (alojamiento, análisis, herramientas de soporte, proveedores de IA) con sus contratos; el DPO.
- Tecnología: arquitectura, dónde residen los datos, cifrado, identidad, registro. Un diagrama de flujo de datos es la forma más rápida de encontrar lo que olvidó.
2. Necesidad y proporcionalidad (Art. 35(7)(b))
- Base jurídica en virtud del artículo 6 y la excepción del artículo 9(2), por finalidad (Artículo 9 del RGPD explicado).
- Minimización de datos: para cada elemento de datos, por qué es necesario; qué decidió no recopilar.
- Información a las personas (artículos 13-14) y cómo se ejercen los derechos (acceso, rectificación, supresión, portabilidad, oposición, retirada del consentimiento) en el producto, no por correo electrónico al soporte.
- Encargados del tratamiento: contratos del artículo 28 en vigor; subencargados listados; derechos de auditoría.
- Conservación y supresión: periodos concretos y el mecanismo que los aplica.
3. Riesgos para las personas (Art. 35(7)(c)) Evaluar la probabilidad y la gravedad para cada uno de los tres eventos clásicos, para cada finalidad:
- Acceso ilegítimo (violación, interno, intercambio excesivo, una clínica que ve más de lo aprobado);
- Modificación no deseada (datos incorrectos en un registro en el que confía un médico, errores de sincronización, una función de IA que escribe en el registro);
- Desaparición (pérdida de un registro del que depende la persona; robo de cuenta; cierre de un proveedor). Luego, los específicos de salud: reidentificación de estadísticas "anónimas"; inferencia de condiciones a partir del comportamiento; discriminación si los datos llegan a aseguradoras o empleadores; daño por datos de niños; datos de ubicación alrededor de clínicas; SDK de terceros en la aplicación que envían datos a redes publicitarias (el hallazgo más común en auditorías regulatorias de aplicaciones de salud).
4. Medidas (Art. 35(7)(d)) Para cada riesgo, el control y el riesgo residual: cifrado en reposo y en tránsito; autenticación sólida; acceso limitado por consentimiento y tiempo, con registros que la persona puede leer; seudonimización en análisis y en registros; sin SDK de publicidad o seguimiento de terceros; entornos separados y datos sintéticos para el desarrollo; copias de seguridad con restauración probada; revisión de proveedores; respuesta a incidentes con el reloj de 72 horas; prácticas de desarrollo seguro; formación y confidencialidad del personal; exportación y supresión de datos en el producto; un interruptor de apagado para integraciones.
5. Consulta
- Se registra el asesoramiento del DPO (Art. 35(2)); se recaban las opiniones de las personas o sus representantes cuando procede (Art. 35(9)), por ejemplo, a través de un panel de usuarios o una asociación de pacientes.
- Si persiste un alto riesgo residual, consulte a la autoridad de control antes del tratamiento (Art. 36). La mayoría de las aplicaciones de salud bien controladas no llegan a este punto; las plataformas que tratan datos para muchas clínicas a veces sí.
6. Aprobación y revisión
- Aprobado por la dirección del responsable; fechado; versionado.
- Revisado cuando cambian las finalidades, los datos, la tecnología o los destinatarios, y al menos cada uno o dos años (Art. 35(11)).
Hallazgos típicos en EIPD de aplicaciones de salud
Los hallazgos más comunes en las EIPD de aplicaciones de salud son los SDK de análisis y de notificación de fallos que reciben identificadores junto con el contexto de salud, las notificaciones push que revelan afecciones en la pantalla de bloqueo, el personal de soporte con acceso ilimitado a la base de datos, las copias de seguridad fuera de la UE, los datos conservados después de cerrar una cuenta, las pantallas de consentimiento que agrupan fines y los conjuntos de datos "anonimizados" que aún identifican a las personas.
Cada uno de estos hallazgos tiene una solución concreta, y la EIPD es donde se compromete esa solución.
La plantilla
La plantilla de EIPD de esta página es un documento de Markdown rellenable para una aplicación de salud, estructurado en seis secciones (descripción del tratamiento, necesidad y proporcionalidad, riesgos para las personas, medidas, consulta, aprobación y revisión) con una tabla de riesgos y una tabla de medidas. Sigue el Artículo 35(7) del RGPD y los criterios del CEPD, y es una estructura inicial, no asesoramiento legal.
Descargue la plantilla de EIPD. Se puede importar en cualquier herramienta de documentos; su Delegado de Protección de Datos (DPO) la adaptará.
En Anpheros
Anpheros mantiene una EIPD para Anpheros Daily y otra para Anpheros Platform como encargado del tratamiento, con la estructura anterior, y las decisiones que condujeron a ellas son visibles en el producto: consentimiento por finalidad, acceso limitado y registrado, sin SDK de publicidad, alojamiento en la UE, exportación y supresión en la aplicación. Consulte Transparencia en salud.
Esta página explica la normativa para equipos de producto e ingeniería. No constituye asesoramiento legal; los textos enlazados en Fuentes son la autoridad, y su delegado de protección de datos, organismo notificado o asesor decide para su caso. Última revisión: Octubre de 2026.
Páginas relacionadas
- Artículo 9 del RGPD para datos de salud
- Desidentificación de datos de salud
- ¿Quién ha visto mi historial médico?
- ¿Es una aplicación de salud un dispositivo médico?
- ISO 27001 vs ISO 27799
- Mapa de la normativa de datos de salud
Fuentes
- Artículos 35 y 36 del RGPD, EUR-Lex
- Grupo de Trabajo del Artículo 29 / EDPB: Directrices sobre EIPD (WP248 rev.01)
- CNIL: Metodología y software de EIPD
- ICO: Evaluaciones de impacto relativas a la protección de datos
- EDPB: directrices, recomendaciones y mejores prácticas
Preguntas frecuentes
¿Necesito una EIPD para una aplicación pequeña con pocos usuarios?
Si procesa datos de salud, casi siempre sí: los datos sensibles más las personas vulnerables ya cumplen el criterio de dos puntos, y varias listas nacionales mencionan explícitamente las aplicaciones de salud. La EIPD de una aplicación pequeña es simplemente más corta.
¿Quién redacta la EIPD?
El responsable es el responsable; en la práctica, el propietario del producto y el jefe de ingeniería la redactan con el asesoramiento del DPO, porque conocen los flujos de datos. Externalizarla por completo produce un documento que nadie puede mantener actualizado.
¿Debe publicarse la EIPD?
No. Es un documento de rendición de cuentas interno que se muestra a la autoridad de control previa solicitud. Muchas organizaciones publican un resumen; el EHDS y algunas normativas nacionales exigen transparencia sobre determinados tratamientos.
¿En qué se diferencia una EIPD de una evaluación de riesgos según la norma ISO 27001?
La evaluación ISO analiza los riesgos para la organización; la EIPD analiza los riesgos para las personas cuyos datos se tratan. Comparten controles y pruebas, y un buen programa de seguridad alimenta la sección de medidas de la EIPD.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →