Data Act para productos sanitarios conectados

El Reglamento de Datos de la UE, conocido como Data Act, está en vigor desde el 11 de enero de 2024 y se aplica desde el 12 de septiembre de 2025. Desde entonces, los usuarios de productos conectados pueden exigir que el titular de los datos les facilite los datos de uso o los transmita a un tercero designado, también en el caso de equipos que ya estaban en uso. Además, antes de celebrar el contrato debe quedar claro qué datos genera un producto y cómo pueden obtenerse.

El 12 de septiembre de 2026 llega la segunda fase: los productos conectados y los servicios relacionados que se introduzcan por primera vez en el mercado después de esa fecha deben permitir el acceso ya por su diseño (Access by Design). Los datos y los metadatos deben estar disponibles por defecto, de forma sencilla, segura y gratuita, en un formato estructurado, de uso común y legible por máquina y, cuando sea pertinente y técnicamente viable, también directamente para el usuario. Según la interpretación de la Comisión, cuenta cada unidad, no el tipo de equipo: incluso un modelo que lleva años con marcado CE queda afectado en cuanto una unidad se introduce por primera vez en el mercado después de la fecha clave.

Los productos sanitarios están incluidos expresamente

La parte expositiva del Reglamento menciona expresamente los productos sanitarios y, según las preguntas frecuentes de la Comisión, el Data Act se aplica también a productos con su propia evaluación de la conformidad. Por tanto, antes de introducirse en el mercado, un producto sanitario debe cumplir, además del MDR, el Reglamento de Datos.

Quién está exento

Las microempresas y las pequeñas empresas están exentas de las obligaciones de acceso, siempre que no estén vinculadas a una empresa mayor ni integradas en ella como socias y no fabriquen ni desarrollen por encargo de otra. Las medianas empresas solo disponen de un periodo de gracia de un año: el primer año después de alcanzar ese tamaño y, para cada producto, el primer año después de su introducción en el mercado. Con independencia de ello, los derechos de acceso del hospital no pueden excluirse por contrato en su perjuicio; tales cláusulas no lo vinculan.

Por qué es una cuestión de seguridad

Cada interfaz adicional amplía la superficie de ataque. En el estudio ManiMed de la Oficina Federal de Seguridad de la Información (BSI), de 2020, se notificaron más de 150 vulnerabilidades en diez productos sanitarios conectados de cinco categorías, a menudo en la infraestructura asociada y rara vez en el propio producto sanitario. Es precisamente ahí donde surgen los portales, las interfaces de programación y los almacenamientos en la nube para el acceso a los datos. En Alemania, el incumplimiento de las obligaciones de diseño o de puesta a disposición puede acarrear multas de hasta 500.000 euros; desde el 30 de mayo de 2026, la autoridad competente es la Bundesnetzagentur.

Dos matices importan: los encargados del tratamiento en el sentido del RGPD no son titulares de datos, lo que afecta tanto a los proveedores de nube como al fabricante en la medida en que trate datos de pacientes exclusivamente siguiendo instrucciones del hospital. Además, el fabricante solo puede usar datos no personales del equipo para fines propios, como la mejora del producto, sobre la base de un contrato con el hospital; hasta qué punto esto afecta a los análisis de seguimiento poscomercialización exigidos por ley debe aclararse caso por caso.

Qué datos están incluidos

Están incluidos los datos brutos y preprocesados disponibles sin un esfuerzo desproporcionado, junto con sus metadatos y los mensajes de estado y de error. Lo que solo surge gracias a inversiones adicionales, como algoritmos propietarios complejos, no queda incluido en principio, salvo que se acuerde otra cosa; se trata de una excepción que solo se deriva de la parte expositiva del Reglamento y deja zonas grises. La seudonimización o el cifrado no convierten los datos en derivados. Aprovechar brechas en la protección del equipo no es una vía admisible para acceder a los datos.

El modelo de referencia consta de cuatro componentes: un equipo de diagnóstico por imagen proporciona imágenes y valores medidos. Un software de planificación deriva de ellos parámetros terapéuticos, que el personal médico revisa y aprueba. Un equipo de terapia ejecuta el plan aprobado y registra su desarrollo. A ello se suma una nube del fabricante con entornos de cliente separados (tenants) para cada hospital, gestión de usuarios, distribución de actualizaciones y un portal web con interfaz de programación (Application Programming Interface, API).

En este tipo de sistemas son habituales dos principios de diseño: la conexión con la nube se establece desde el hospital, de modo que no se necesitan accesos entrantes desde internet, y la nube está desacoplada de forma que no puede intervenir en una terapia en curso. En este modelo, forman parte de la puerta de datos en el sentido del Data Act:

• el portal web para consultar y descargar datos
• la API para consultas automatizadas desde los sistemas del hospital
• las vías de exportación para paquetes de datos voluminosos
• una función de delegación con la que el hospital designa a terceros como destinatarios
• en su caso, un acceso local en el equipo o en una pasarela (gateway)

Acceso directo, en el que el hospital consulta los datos por sí mismo, o acceso indirecto, en el que el fabricante los facilita previa solicitud: esta decisión de diseño tiene consecuencias para la seguridad. El acceso directo requiere una interfaz permanentemente accesible y protegida con solidez; el indirecto traslada los riesgos a procesos manuales.

¿Es el servicio en la nube un producto sanitario?

Depende de su finalidad prevista: un servicio que solo almacena y transmite datos no suele ser software de producto sanitario; uno que realiza evaluaciones médicas o devuelve resultados a la planificación, a menudo sí. El software complementario sin condición de producto sanitario, por ejemplo una aplicación instalable de servicio técnico o de exportación, puede quedar incluido en el Cyber Resilience Act en casos concretos; en cambio, este no abarca los servicios web puros sin un producto asociado.

La reserva de seguridad

El hospital y el fabricante pueden restringir o excluir por contrato el acceso, el uso o la difusión posterior de los datos cuando su tratamiento pueda socavar requisitos de seguridad del producto conectado establecidos por ley y, con ello, tener efectos adversos graves para la salud, la seguridad o la protección de las personas. En los productos sanitarios entran en juego sobre todo los requisitos de ciberseguridad del MDR, algo evidente aunque no esté regulado de forma expresa. El borrador de cláusulas contractuales tipo no vinculantes de la Comisión, disponible por ahora solo en inglés, prevé como opción mencionar en el contrato el requisito de seguridad concreto.

Si el fabricante deniega la transmisión, debe informar a la autoridad competente, en Alemania a la Bundesnetzagentur mediante sus formularios. El hospital puede presentar allí una reclamación o recurrir a un órgano de resolución de litigios. En el modelo de referencia sería fácil justificar que el equipo de terapia no responda a consultas en tiempo real durante un tratamiento en curso y que las configuraciones críticas para la seguridad no salgan al exterior. En cambio, sería difícil justificar que se negara al hospital la lectura de los registros de errores y eventos. En cualquier caso, el Data Act no exige acceso de escritura a la planificación ni al control.

Secretos comerciales en tres niveles

• Identificar y acordar: el fabricante marca los secretos comerciales, también en los metadatos, y fija con el destinatario medidas de protección, como acuerdos de confidencialidad, protocolos de acceso estrictos, normas o códigos de conducta.
• Retener o suspender: si no se alcanza un acuerdo, no se aplican las medidas acordadas o se vulnera la confidencialidad, el fabricante puede retener o suspender la transmisión.
• Denegar: solo en circunstancias excepcionales y caso por caso, cuando demuestre con criterios objetivos que, pese a las medidas de protección, es muy probable que sufra un perjuicio económico grave.

En el segundo y el tercer nivel, la decisión debe motivarse por escrito y comunicarse a la autoridad. Si los secretos se divulgan sin protección, puede verse afectada además su condición de secreto conforme a la ley alemana de secretos comerciales. El modelo de amenazas y el archivo de gestión del riesgo aportan justificaciones sólidas para ambos frenos de mano.

Qué cambiaría el Digital Omnibus

La propuesta de modificación «Digital Omnibus» de la Comisión, de noviembre de 2025, crearía en la protección de secretos un motivo adicional de denegación cuando exista un riesgo elevado de fuga hacia terceros países con una protección más débil; la reserva de seguridad quedaría igual. No está aprobada: el Parlamento no ha votado y en el Consejo no se había alcanzado ningún mandato de negociación hasta mediados de octubre de 2026; uno de los puntos controvertidos es precisamente la protección de secretos.

RGPD y secreto médico

Cuando hay datos personales afectados, prevalece la normativa de protección de datos; el Data Act no crea una base jurídica propia. Si el hospital es el usuario y el paciente es el interesado, la puesta a disposición necesita una base jurídica conforme al RGPD y, en el caso de los datos de salud, además una de las excepciones previstas para las categorías especiales. Por lo general, el hospital sigue siendo el responsable del tratamiento, debe garantizar la protección de datos desde el diseño y, para los sistemas de terapia conectados, suele necesitar una evaluación de impacto relativa a la protección de datos (EIPD).

A ello se suma el secreto médico, protegido penalmente, que el Data Act no suprime. Salvo dispensa del paciente o habilitación legal, los datos de pacientes solo pueden llegar a proveedores en la medida necesaria, y solo a aquellos que trabajen por encargo del hospital y se hayan comprometido a la confidencialidad. A nuestro juicio, los fines de análisis propios del fabricante no quedan cubiertos por ello.

La IEC 81001-5-1 exige para el software sanitario un modelo de amenazas específico del producto, pero no prescribe ningún método. El punto de partida es un diagrama de flujo de datos del sistema completo con sus límites de confianza (trust boundaries). Con el Data Act surge además un límite hacia destinatarios externos que elige el hospital. El límite que requiere mayor protección sigue siendo el que rodea el equipo de terapia. La guía MDCG 2019-16 ya espera, de todos modos, una visión completa de los flujos de datos de red en los productos conectados.

El método STRIDE examina cada flujo de datos en busca de seis clases de amenazas: suplantación de identidad (Spoofing), manipulación (Tampering), repudio (Repudiation), divulgación de información (Information Disclosure), denegación de servicio (Denial of Service) y elevación de privilegios (Elevation of Privilege). De forma complementaria, un árbol de ataque descompone en pasos parciales un objetivo del atacante como «datos de planificación manipulados llegan al equipo de terapia».

Evaluar e incorporar al archivo de gestión del riesgo

Para sistemas cuya nube conecta muchos hospitales, la guía de ciberseguridad de la Administración de Alimentos y Medicamentos de Estados Unidos (Food and Drug Administration, FDA) de febrero de 2026 recomienda una vista de arquitectura específica para los daños a muchos pacientes a la vez; clasifica los riesgos de seguridad según su explotabilidad y no según una probabilidad difícil de estimar. Las amenazas con posibles consecuencias de peligro se registran como causas en el archivo de gestión del riesgo conforme a ISO 14971. Si se añaden interfaces o nuevos tipos de destinatarios, el modelo debe actualizarse.

El MDR no utiliza el término prueba de penetración. Sin embargo, la guía MDCG 2019-16 califica las pruebas como el medio más importante para verificar la seguridad y menciona expresamente las pruebas de las funciones de seguridad, el fuzzing con entradas erróneas, los escaneos de vulnerabilidades y las pruebas de penetración. La IEC 81001-5-1 exige que quienes realizan las pruebas sean suficientemente independientes. El alcance de la prueba se deriva de las superficies de ataque, los límites del sistema y los escenarios del modelo de amenazas.

Puntos clave de la prueba en la puerta de datos

• Separación de clientes: con accesos de prueba para dos hospitales, el equipo comprueba si se pueden obtener registros ajenos modificando identificadores; la autorización deficiente a nivel de objeto ocupa el primer puesto del OWASP API Security Top 10 de 2023.
• Inicio de sesión y sesiones en el portal y la API, incluidas la duración, la vinculación y la reutilización de los tokens de acceso.
• Permisos funcionales: ¿puede ampliarse un acceso de lectura a funciones de escritura o de control?
• Delegación a terceros: ¿puede un atacante registrarse como destinatario o ampliar el volumen de datos aprobado?
• Vías de exportación: ¿están los paquetes de datos completos, correctamente seudonimizados y con los secretos comerciales identificados?
• Procesamiento de entradas: ¿cómo reaccionan la API y las funciones de importación ante formatos erróneos o preparados con fines maliciosos (fuzzing)?
• Registro: ¿se registran las aprobaciones y las consultas de forma completa y a prueba de manipulaciones?
• Límites de carga y desacoplamiento: ¿siguen disponibles la planificación y el funcionamiento del equipo ante consultas masivas?

Condiciones marco e informe

La prueba se realiza como prueba de caja gris (grey box), con conocimiento parcial del sistema, con conjuntos de datos sintéticos y en un entorno idéntico al de producción, nunca en un equipo en uso con pacientes. Tal como espera la FDA, el informe indica la independencia, el alcance, el periodo, la metodología y los resultados, y justifica las vulnerabilidades que quedan abiertas. La clasificación se basa en la explotabilidad y en el posible efecto sobre los pacientes; la corrección se gestiona como acción correctiva y preventiva (Corrective and Preventive Action, CAPA), con nueva prueba y archivo en la documentación técnica y en el seguimiento poscomercialización (Post-Market Surveillance). Repetida con regularidad, la prueba demuestra también la eficacia de las medidas de protección que exigen el RGPD y la ley BSI.

En la puerta de datos confluyen el Data Act, el MDR, el RGPD, la ley BSI y la ley alemana de secretos comerciales. Si asuntos regulatorios, seguridad de la información, protección de datos y asesoría jurídica mantienen catálogos y escalas de riesgo separados, las contradicciones salen a la luz, a más tardar, en la auditoría o en un incidente. Como ancla se presta el sistema de gestión de la calidad conforme a ISO 13485, que ya gobierna proveedores, riesgos, vigilancia y cambios. Como ISO 13485 no sigue la estructura armonizada común de las demás normas ISO de sistemas de gestión, ISO/IEC 27001, ISO/IEC 27701 y, en su caso, ISO/IEC 42001 se incorporan mediante una tabla de correspondencias.

Coordinar las vías de notificación paralelas

Un incidente en la puerta de datos puede activar a la vez varias obligaciones de notificación, que coordina un equipo de respuesta a incidentes de seguridad de producto (Product Security Incident Response Team, PSIRT): según la ley BSI, 24 horas, 72 horas y un mes ante el punto de notificación común del BSI y de la Oficina Federal de Protección Civil y Asistencia en Catástrofes (BBK); según el RGPD, 72 horas ante la autoridad de control y, como encargado del tratamiento, sin dilación indebida ante el hospital; según el MDR, 2, 10 o 15 días si se trata de un incidente grave. Si a raíz de ello el fabricante suspende transmisiones de datos, debe comunicarlo a la Bundesnetzagentur; para el software complementario pueden sumarse notificaciones según el Cyber Resilience Act.

Según la ley BSI, la dirección es responsable de aplicar y supervisar las medidas de seguridad. La persona responsable del cumplimiento de la normativa que exige el MDR (Person Responsible for Regulatory Compliance, PRRC) no asume el papel de responsable de seguridad de la información ni de delegado de protección de datos; como nexo ha dado buen resultado una función de seguridad de producto (Product Security). Si un hospital designa, por ejemplo, un servicio de IA como destinatario, así puede aclararse de una sola vez qué datos fluyen, sobre qué base jurídica y contractual, con qué riesgo residual y con qué evidencia.

1. 1
   Determinar la afectación

   Inventariar los productos y servicios conectados, comprobar las excepciones para pymes y determinar qué equipos se introducen por primera vez en el mercado después del 12 de septiembre de 2026.

2. 2
   Elaborar el catálogo de datos

   Recopilar todos los datos disponibles del producto y del servicio y clasificarlos como datos que deben facilitarse, derivados, personales o que requieren confidencialidad.

3. 3
   Cumplir las obligaciones de información

   Completar ofertas, contratos e instrucciones de uso de modo que el tipo, el volumen, el formato y la vía de obtención de los datos queden claros antes de celebrar el contrato.

4. 4
   Preparar los contratos

   Redactar contratos de uso de datos para análisis propios, así como cláusulas sobre la reserva de seguridad y la protección de secretos; el borrador de cláusulas contractuales tipo sirve de orientación.

5. 5
   Diseñar la puerta de datos

   Definir la vía de acceso, separar el plano de datos del de control y especificar como requisitos de seguridad la separación de clientes, la delegación y el registro.

6. 6
   Actualizar el modelo de amenazas

   Analizar con STRIDE los nuevos límites de confianza y flujos de datos, incorporar al archivo de gestión del riesgo las causas relevantes para la seguridad y documentar la justificación de los frenos de mano.

7. 7
   Probar y demostrar

   Realizar una prueba de penetración centrada en la autorización, la delegación y las vías de exportación; cerrar los hallazgos mediante CAPA y documentarlos.

8. 8
   Coordinar el cambio y las vías de notificación

   Tratar pronto la interfaz con el organismo notificado y ensayar en un ejercicio de simulación las vías de notificación a la Bundesnetzagentur, el BSI, la autoridad de protección de datos y la autoridad de vigilancia de productos sanitarios.

Esta página refleja la situación a octubre de 2026. No sustituye el asesoramiento jurídico; las cuestiones de interpretación, en particular sobre la delimitación de los datos derivados y el tratamiento de los productos heredados, deben aclararse en cada caso concreto.