MDR y Rule 11: cómo clasificar y certificar software como di - Blog

Introducción

Obtener el marcado CE para un software médico certificado MDR se ha convertido en uno de los desafíos regulatorios más complejos del sector healthtech europeo. Bajo el Reglamento (UE) 2017/745 sobre productos sanitarios (MDR), prácticamente todo software con propósito médico se clasifica como Clase IIa o superior según la Rule 11 del Annex VIII, lo que exige la intervención de un Organismo Notificado para obtener la certificación. Esta elevación automática de la clasificación ha generado un embudo regulatorio que ha dejado fuera del mercado a cientos de productos digitales de salud y ha ralentizado la innovación en un sector donde el mercado europeo de SaMD (Software as a Medical Device) se estima en 440 millones de euros en 2024, con una proyección de crecimiento hasta los 1.400 millones para 2033.

El panorama regulatorio, lejos de simplificarse, se ha vuelto más denso en 2025. La guía MDCG 2019-11 Rev.1, actualizada en junio de 2025, ha redefinido los criterios para determinar cuándo un software califica como dispositivo médico. En diciembre de 2025, la Comisión Europea publicó su propuesta de revisión del MDR (lo que muchos denominan ya "MDR 2.0"), que incluye una reformulación de la Rule 11 para alinearla con el marco internacional IMDRF. Y sobre todo ello planea la interacción con el EU AI Act, cuya entrada en vigor progresiva añade una capa adicional de requisitos para software sanitario que incorpore inteligencia artificial.

Este artículo proporciona una guía completa para fabricantes de software sanitario, responsables de calidad, consultores regulatorios y equipos técnicos que necesitan entender el proceso de clasificación y certificación de MDSW (Medical Device Software) en Europa, con atención especial al contexto español y al papel de la AEMPS. Si estás desarrollando o planificando un software médico certificado MDR, aquí encontrarás el mapa regulatorio y técnico actualizado a 2026.

Cuándo un software es dispositivo médico: la guía MDCG 2019-11 Rev.1

La primera pregunta que debe responder cualquier fabricante de software sanitario es aparentemente sencilla pero regulatoriamente compleja: ¿mi software es un producto sanitario? La respuesta depende del propósito previsto (intended purpose) que el fabricante declare, no de la tecnología empleada.

El árbol de decisión del MDCG

La guía MDCG 2019-11 Rev.1, publicada por el Medical Device Coordination Group de la Comisión Europea y actualizada en junio de 2025, establece un proceso de cualificación en cuatro pasos:

¿Es software? Se verifica que el producto cumple la definición de software según la IEC 62304: un conjunto de instrucciones que procesa datos de entrada para generar datos de salida.
¿Es un producto sanitario según el artículo 2(1) del MDR? El software debe tener un propósito médico definido por el fabricante: diagnóstico, prevención, monitorización, predicción, pronóstico, tratamiento o alivio de una enfermedad, lesión o discapacidad. Los software de propósito general (sistemas operativos, herramientas de comunicación, apps de bienestar sin finalidad médica) quedan excluidos.
¿Realiza una acción sobre los datos más allá del almacenamiento, comunicación o búsqueda simple? Esta es la línea divisoria clave. Un software que simplemente almacena, transmite, archiva o recupera datos sin modificarlos ni interpretarlos no califica como producto sanitario, incluso si esos datos son clínicos. El ejemplo clásico: un PACS que solo almacena y visualiza imágenes DICOM sin procesamiento adicional no es un dispositivo médico; un software que analiza esas mismas imágenes para detectar nódulos pulmonares sí lo es.
¿El propósito previsto entra en la definición del artículo 2(1)? Se confirma la alineación con alguna de las finalidades médicas enumeradas en el MDR.

La revisión de junio de 2025 ha clarificado varios casos fronterizos que generaban interpretaciones divergentes entre Estados miembros: los sistemas de soporte a la decisión clínica (CDSS) que proporcionen recomendaciones diagnósticas o terapéuticas específicas para un paciente se consideran dispositivos médicos, incluso si el clínico mantiene la decisión final. Los software de gestión de flujos de trabajo clínicos solo califican si procesan datos del paciente para generar información con propósito médico, no si simplemente organizan tareas administrativas.

La terminología importa: MDSW, SaMD y SiMD

El MDR utiliza el término MDSW (Medical Device Software) para referirse a todo software que califica como producto sanitario, ya sea independiente o integrado en otro dispositivo. El IMDRF (International Medical Device Regulators Forum) utiliza SaMD (Software as a Medical Device) para el software independiente y SiMD (Software in a Medical Device) para el software embebido. Aunque los términos se usan a menudo como sinónimos, la distinción tiene implicaciones para la clasificación: la Rule 11 del MDR se aplica específicamente al software que opera de forma independiente, no al software que forma parte de otro dispositivo físico (que se clasifica según las reglas aplicables a ese dispositivo).

Rule 11: la regla que cambió el tablero para el software sanitario

La Rule 11 del Annex VIII del MDR es, posiblemente, la disposición regulatoria más debatida del reglamento. Su efecto práctico ha sido elevar la clasificación de la inmensa mayoría del software médico respecto al régimen anterior de la Directiva 93/42/CEE (MDD), donde muchos software se autoclasificaban como Clase I sin intervención de un Organismo Notificado.

Texto y estructura de la Rule 11

La Rule 11 establece que el software destinado a proporcionar información utilizada para tomar decisiones con fines diagnósticos o terapéuticos se clasifica como:

Clase IIa: Si la decisión puede causar un deterioro grave del estado de salud o una intervención quirúrgica.
Clase IIb: Si las decisiones pueden causar la muerte o un deterioro irreversible del estado de salud.
Clase III: Si las decisiones pueden causar la muerte o un deterioro irreversible del estado de salud y el software está destinado a monitorizar o influir en el uso de dispositivos implantables activos.

El software destinado a monitorizar procesos fisiológicos se clasifica como Clase IIa, salvo que la monitorización sea de parámetros fisiológicos vitales cuya variación pueda resultar en peligro inmediato para el paciente, en cuyo caso asciende a Clase IIb.

La cláusula de salvaguarda final establece que todo software no cubierto por las categorías anteriores se clasifica como mínimo como Clase I. Pero en la práctica, casi todo software con propósito médico genuino encaja en las categorías de Clase IIa o superior, porque toda decisión diagnóstica o terapéutica tiene potencial de causar, al menos, un deterioro grave si la información proporcionada es errónea.

La propuesta MDR 2.0: reformulación de la Rule 11

En diciembre de 2025, la Comisión Europea publicó su propuesta de enmienda al MDR y al IVDR (Reglamento de diagnóstico in vitro), denominada informalmente "MDR 2.0". Entre las modificaciones más relevantes para el software se encuentra la reformulación de la Rule 11 para alinearla con el marco de clasificación del IMDRF.

La propuesta introduce una clasificación basada en dos ejes: la significatividad de la información proporcionada por el software para la decisión clínica (inform, drive, diagnose/treat) y la gravedad de la condición de salud del paciente (non-serious, serious, critical). Esta matriz, ya utilizada por reguladores como la FDA y Health Canada, pretende proporcionar una clasificación más granular y predecible que la actual, reduciendo el efecto de "up-classification" generalizado que ha penalizado especialmente a los software de bajo riesgo.

La propuesta está en fase de negociación legislativa en el Parlamento Europeo y el Consejo, y no se espera su aprobación definitiva antes de 2027-2028, pero los fabricantes deben prepararse para su eventual adopción monitorizando los borradores que se vayan publicando.

El proceso completo de certificación: de la idea al marcado CE

Paso 1: Determinación del propósito previsto

El fabricante debe redactar una declaración de propósito previsto precisa y delimitada, que defina exactamente qué hace el software, para qué población de pacientes, en qué contexto clínico y qué tipo de información proporciona al usuario. Esta declaración es la piedra angular de toda la documentación regulatoria: una definición demasiado amplia puede elevar la clasificación innecesariamente; una demasiado estrecha puede dejar fuera usos legítimos.

Paso 2: Clasificación según Rule 11

Aplicando la Rule 11 y la guía MDCG 2019-11 Rev.1, se determina la clase del dispositivo. Para Clase I (con función de medición o estéril), el fabricante puede autoevaluar la conformidad. Para Clase IIa, IIb y III, se requiere la intervención de un Organismo Notificado.

Paso 3: Sistema de Gestión de Calidad — ISO 13485:2016

El fabricante debe implementar un Sistema de Gestión de Calidad (SGC) conforme a la norma ISO 13485:2016, que cubre todos los procesos del ciclo de vida del producto: diseño, desarrollo, producción, instalación, servicio postventa y vigilancia. Para empresas de software, los procesos de "producción" se mapean al desarrollo y despliegue de software, incluyendo gestión de configuración, control de versiones y validación de entornos.

Herramientas especializadas facilitan la implementación del SGC: Greenlight Guru ofrece un eQMS (electronic Quality Management System) diseñado específicamente para fabricantes de dispositivos médicos, SimplerQMS proporciona un sistema pre-configurado para ISO 13485, y MatrixRequirements integra la gestión de requisitos con la trazabilidad regulatoria.

Paso 4: Desarrollo conforme a IEC 62304 + ISO 14971

El desarrollo del software debe seguir un ciclo de vida documentado conforme a la norma IEC 62304:2006+Amd1:2015, que define tres clases de seguridad del software (A, B, C) con requisitos de documentación crecientes. La enmienda de 2015 añadió la posibilidad de clasificar unidades de software individuales, permitiendo un enfoque más granular.

La gestión de riesgos se realiza conforme a ISO 14971:2019, que exige un proceso sistemático de identificación, análisis, evaluación y control de riesgos a lo largo de todo el ciclo de vida del producto. Para SaMD, los riesgos incluyen no solo los errores del software (bugs, fallos de rendimiento) sino también los riesgos derivados del uso previsto: ¿qué ocurre si el clínico actúa sobre una recomendación errónea del sistema?

La norma IEC 82304-1:2016 complementa el marco con requisitos de seguridad específicos para productos de software de salud independientes, y la IEC 81001-5-1:2021 aborda la ciberseguridad del software de salud, un requisito cada vez más exigido por los Organismos Notificados.

Las herramientas de ALM (Application Lifecycle Management) son esenciales para mantener la trazabilidad exigida: Jama Connect con su tecnología Live Traceability permite vincular requisitos, riesgos, diseño, código y verificación en tiempo real. Siemens Polarion ALM ofrece una plataforma integrada para el ciclo de vida completo. Ketryx automatiza los procesos de ALM específicos para dispositivos médicos, integrándose con herramientas de desarrollo como GitHub y Jira.

Paso 5: Documentación técnica — Annex II del MDR

El Annex II del MDR define la estructura de la documentación técnica que el fabricante debe preparar, organizada en seis secciones principales:

Descripción e identificación del producto: Propósito previsto, usuarios previstos, principio de funcionamiento, variantes y accesorios.
Información suministrada por el fabricante: Etiquetado, instrucciones de uso, material promocional.
Diseño e información de fabricación: Ciclo de vida del desarrollo, gestión de configuración, validación del proceso de producción.
Requisitos generales de seguridad y rendimiento (GSPR): Evaluación del cumplimiento de cada requisito aplicable del Annex I del MDR.
Evaluación beneficio-riesgo y gestión de riesgos: Análisis de riesgos conforme a ISO 14971, evaluación clínica.
Verificación y validación del producto: Resultados de pruebas, validación del software, evaluación de usabilidad.

Paso 6: Evaluación de conformidad por Organismo Notificado

Para software de Clase IIa y superior, un Organismo Notificado designado evalúa la documentación técnica y el SGC del fabricante. En España, el Centro Nacional de Certificación de Productos Sanitarios (CNCps), con número de designación 0318, es el organismo de referencia. El CNCps está adscrito a la AEMPS (Agencia Española de Medicamentos y Productos Sanitarios), que actúa como autoridad competente española en materia de productos sanitarios.

El Boletín de Productos Sanitarios de la AEMPS (octubre-diciembre 2025) reporta un incremento sostenido en las solicitudes de certificación de MDSW, reflejando tanto la maduración del mercado como la presión de los plazos transitorios del MDR.

A nivel europeo, la capacidad de los Organismos Notificados sigue siendo un cuello de botella: solo 42 organismos están designados bajo el MDR en toda la UE, frente a los más de 80 que operaban bajo la MDD. Los tiempos de evaluación para software de Clase IIa oscilan entre 6 y 12 meses; para Clase III, pueden superar los 18 meses.

Paso 7: Vigilancia post-comercialización

Una vez obtenido el marcado CE, el fabricante debe implementar un sistema de vigilancia post-comercialización (PMS) que incluya la recogida activa de datos sobre el rendimiento del software en uso real, la gestión de incidentes, la elaboración de informes periódicos de seguridad (PSUR para Clase IIa y superior) y la actualización continua de la evaluación clínica.

EUDAMED y el registro obligatorio desde mayo 2026

La base de datos europea de productos sanitarios, EUDAMED, se convierte en obligatoria a partir de mayo de 2026. Todos los fabricantes de MDSW deberán registrar sus dispositivos, incluyendo la asignación del UDI (Unique Device Identifier), el registro del Organismo Notificado que emitió el certificado, y la publicación de los resúmenes de seguridad y rendimiento clínico.

Para los fabricantes españoles, el registro previo ante la AEMPS mediante el Real Decreto 192/2023 (normativa española complementaria al MDR) sigue siendo obligatorio y coexiste con EUDAMED. El RD 192/2023 establece requisitos adicionales de comunicación a la AEMPS para la comercialización en territorio español.

La intersección con el EU AI Act

La guía MDCG 2025-6 aborda la interacción entre el EU AI Act y el MDR/IVDR, un tema de creciente relevancia dado que un porcentaje cada vez mayor de MDSW incorpora componentes de inteligencia artificial. El principio general es que ambas normativas se aplican simultáneamente: un software con IA que califica como dispositivo médico debe cumplir tanto el MDR como el AI Act.

El AI Act clasifica los sistemas de IA en el ámbito sanitario como alto riesgo (Annex III, punto 5), lo que impone requisitos adicionales de gestión de datos, transparencia, supervisión humana, robustez y ciberseguridad. Sin embargo, el artículo 6(2) del AI Act establece que cuando un sistema de IA es un producto sanitario sujeto a evaluación de conformidad por un Organismo Notificado bajo el MDR, la evaluación de conformidad del AI Act se integra en el proceso del MDR, evitando duplicación de certificaciones.

Para los fabricantes, esto significa que la documentación técnica debe abordar ambos marcos: los GSPR del MDR Annex I y los requisitos del AI Act Chapter 2, con especial atención a la explicabilidad del modelo, la gestión del sesgo en los datos de entrenamiento y la monitorización del rendimiento del algoritmo en producción.

Conclusión

Certificar un software médico certificado MDR en Europa es un proceso que requiere inversión significativa en tiempo, recursos y conocimiento regulatorio, pero que abre las puertas a un mercado europeo de SaMD que se proyecta hacia los 1.400 millones de euros en 2033. La Rule 11, en su formulación actual, eleva la clasificación de la mayoría del software médico a Clase IIa o superior, pero la propuesta MDR 2.0 promete un marco más proporcionado y alineado con estándares internacionales.

Los fabricantes que se anticipen implementando un SGC robusto conforme a ISO 13485, un ciclo de vida de desarrollo según IEC 62304 con gestión de riesgos ISO 14971, y una documentación técnica completa conforme al Annex II, estarán posicionados para navegar tanto el MDR actual como las futuras modificaciones, incluyendo la integración con el EU AI Act.

En Informática Médica acompañamos a fabricantes de software sanitario en todo el proceso de clasificación y certificación MDR, desde la determinación del propósito previsto hasta la vigilancia post-comercialización, con conocimiento específico del ecosistema regulatorio español (AEMPS, CNCps, RD 192/2023) y las herramientas de ALM y QMS que aceleran el camino hacia el marcado CE.

Referencias

Reglamento (UE) 2017/745 del Parlamento Europeo y del Consejo, de 5 de abril de 2017, sobre los productos sanitarios (MDR). Annex VIII Rule 11, Annex II (Technical File). Disponible en EUR-Lex.
MDCG 2019-11 Rev.1 (junio 2025): Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. Disponible en ec.europa.eu/health/mdcg.
MDCG 2025-6: Guidance on the interplay between the AI Act and the MDR/IVDR. Disponible en ec.europa.eu/health/mdcg.
Propuesta de enmienda al MDR e IVDR (diciembre 2025) — ec.europa.eu/health/medical-devices.
AEMPS: Boletín de Productos Sanitarios, octubre-diciembre 2025 — aemps.gob.es.
Real Decreto 192/2023, de 21 de marzo, por el que se regulan los productos sanitarios — BOE.
Johner Institute: MDR Rule 11 — Software Classification Under MDR — blog.johner-institute.com.
ISO 13485:2016 — Medical devices — Quality management systems — Requirements for regulatory purposes.
IEC 62304:2006+Amd1:2015 — Medical device software — Software life cycle processes.
ISO 14971:2019 — Medical devices — Application of risk management to medical devices.
IEC 82304-1:2016 — Health software — Part 1: General requirements for product safety.
IEC 81001-5-1:2021 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security.