La respuesta corta

Los datos de salud están prohibidos por defecto. El artículo 9 del RGPD prohíbe tratar categorías especiales de datos —entre ellas los relativos a la salud— salvo que se cumpla una de las condiciones que levantan esa prohibición.

Y hay una trampa que se pasa por alto constantemente: hacen falta dos cosas a la vez, no una. Una base de licitud del artículo 6 y, además, una condición del artículo 9.2. Cumplir solo una de las dos no basta.

Para la mayoría de apps comerciales de salud, la condición que aplica es el consentimiento explícito (artículo 9.2.a). Para lo que ocurre dentro del sistema sanitario, suele ser la de asistencia sanitaria o social (artículo 9.2.h), que exige base en el derecho de la Unión o de un Estado miembro.

Qué significa «explícito» de verdad

No es un matiz de redacción. El consentimiento explícito exige ser libre, específico, informado, inequívoco, documentado y revocable, y tiene que referirse de forma clara a las categorías concretas de datos de salud que se van a tratar.

Lo que no vale: deducirlo de que el usuario pulse «Aceptar» en una pantalla de términos generales.

Traducido a producto, y esto sí es diseño de pantallas:

  • Una acción afirmativa separada para los datos de salud, distinta de la aceptación de los términos y de la política de privacidad.
  • Redactada en términos de qué dato concreto y para qué.
  • Registrada: qué versión del texto aceptó, cuándo y desde dónde. Sin ese registro no puedes demostrarlo, y demostrarlo es tu obligación.
  • Revocable con la misma facilidad con la que se dio. Un consentimiento que se retira llamando por teléfono no es revocable en la práctica.

Y una consecuencia que afecta a la arquitectura: si el consentimiento se puede retirar, el sistema tiene que poder dejar de tratar y borrar. Eso no se improvisa sobre una base de datos que mezcla todo en la misma tabla.

Dónde alojar

Con el consentimiento resuelto, la pregunta de infraestructura:

  • Región europea, siempre que se pueda. Ahorra la conversación de transferencias internacionales y es lo que espera cualquier cliente sanitario en el pliego.
  • Aislamiento del dato de salud del resto. Separar el dato clínico de la identidad y del dato operativo permite minimizar, pseudonimizar y borrar sin arrastrar el resto del sistema.
  • Cifrado en reposo y en tránsito, con gestión de claves que no viva en el mismo sitio que los datos.
  • Trazabilidad de accesos: quién ha visto qué y cuándo. En un incidente, esa traza es la diferencia entre saber el alcance y suponerlo.
  • Copias de seguridad con la misma protección que el original. Es donde se cuela el dato sin cifrar más a menudo.
  • Retención decidida y ejecutada. Un plazo escrito que nadie aplica es peor que no tener plazo: es una promesa incumplida por escrito.

Si el cliente es una entidad pública o del sistema sanitario público, hay además requisitos de seguridad propios del sector — están en la landing de apps para el sector público.

Lo que hay que decidir antes de escribir código

  1. ¿Qué dato de salud tratas exactamente? Escribir la lista. Muchas apps descubren que tratan menos de lo que creían, y eso simplifica todo.
  2. ¿Puedes no tratarlo? La minimización es la mejor medida de seguridad que existe: el dato que no guardas no se filtra, no se audita y no hay que borrarlo.
  3. ¿Puede quedarse en el dispositivo? Procesar localmente evita mover el dato. Cuando el caso lo permite, es la opción más limpia.
  4. ¿Quién es responsable y quién encargado del tratamiento? Si construyes para un hospital, normalmente él es responsable y tú encargado, y eso hay que firmarlo antes de empezar.
  5. ¿Cómo se ejerce el borrado? Un procedimiento que alguien de negocio pueda ejecutar sin pedir un despliegue.

Por qué importa tanto

Las infracciones del artículo 9 están en el tramo alto de sanciones del RGPD: hasta 20 millones de euros o el 4 % de la facturación anual global, el mismo techo que las infracciones más graves.

Ese dato no es para asustar, es para presupuestar: justifica dedicar tiempo de diseño a la minimización y al modelo de consentimiento antes de construir, en vez de resolverlo con un aviso legal al final.

Los errores que se repiten

  • Un solo botón de «Acepto» para términos, privacidad y datos de salud.
  • Registrar el consentimiento como un booleano, sin versión del texto ni fecha.
  • Analítica de terceros recibiendo eventos que revelan condición de salud. Un evento llamado vio_resultado_diabetes es un dato de salud, aunque esté en una herramienta de producto.
  • Capturas y registros de depuración con datos clínicos, que acaban en el sistema de errores.
  • Guardar «por si acaso» datos que el producto no usa.

El tercero es el más frecuente y el más invisible: nadie piensa que el nombre de un evento sea un dato personal, y lo es.

Es parte del diseño previo en cualquier proyecto de apps para el sector salud: decidir qué se trata, con qué base y dónde vive, antes de que exista la primera pantalla.

(Esto es criterio técnico y de arquitectura, no asesoramiento legal: la base de licitud y los textos los valida el responsable de protección de datos del cliente.)

Marco normativo: artículo 9 del RGPD, categorías especiales de datos personales. Consultado el 14 de agosto de 2026.