La Regla 11 del Anexo VIII del MDR es la regla de clasificación que más ha sacudido a la salud digital. Bajo la directiva 93/42/CEE, la mayoría de los software médicos se encuadraban en la clase I, mediante autocertificación, sin organismo notificado. Bajo el MDR, la mayoría de los software de apoyo a la decisión se encuadran como mínimo en la clase IIa. El cambio de clase no es un ajuste documental: hace entrar a un organismo notificado en la vida del editor.
Lo que dice exactamente la Regla 11
El texto plantea una lógica en tres tiempos, que hay que leer en orden.
Primer tiempo: la clase IIa por defecto. Los software destinados a proporcionar información utilizada para tomar decisiones con fines terapéuticos o diagnósticos se encuadran en la clase IIa. Es el punto de partida, no la excepción. Todo software de apoyo a la decisión clínica entra en el ámbito por esta puerta.
Segundo tiempo: dos excepciones hacia arriba. Si las decisiones a las que contribuye el software tienen una incidencia que pueda ocasionar el fallecimiento o un deterioro irreversible del estado de salud, el software se encuadra en la clase III. Si pueden ocasionar un deterioro grave del estado de salud o una intervención quirúrgica, se encuadra en la clase IIb. La intervención quirúrgica es un criterio por derecho propio: un software cuyo error pueda llevar a operar, o a operar mal, es IIb aun sin una amenaza vital directa. Esas mismas consecuencias graves que elevan la clase son también las que, una vez el software en el mercado, activan las obligaciones de vigilancia y plazos de notificación.
Tercer tiempo: la monitorización. Los software destinados a monitorizar procesos fisiológicos se encuadran en la clase IIa. Pasan a la clase IIb únicamente si monitorizan parámetros fisiológicos vitales cuyas variaciones puedan suponer un peligro inmediato para la vida del paciente. Ambas condiciones son acumulativas: parámetro vital, y peligro inmediato en caso de variación. Un software que sigue la frecuencia cardíaca en reanimación cumple las dos casillas. Una aplicación que registra esa misma frecuencia cardíaca en un seguimiento de bienestar no cumple ninguna, y probablemente ni siquiera es un producto sanitario.
Todos los demás software se encuadran en la clase I. En la práctica, esta categoría ha quedado estrecha: la revisión de 2025 de la guía da un ejemplo, bajo condiciones estrictas.
Una regla de aplicación completa el dispositivo: el software que controla un producto o influye en su uso se encuadra en la misma clase que ese producto (Anexo VIII, regla 3.3). La Regla 11 se aplica al software clasificado como tal.
Por qué la reclasificación fue tan amplia
Bajo la directiva, el criterio central era el lugar del software dentro de un producto físico. El MDR desplaza el criterio hacia el impacto clínico de un error del propio software. Un software que sugiere un diagnóstico diferencial parte de IIa, sube a IIb o III según las consecuencias de una sugerencia errónea. Un software de planificación de radioterapia acaba en IIb o III: un error de dosimetría puede ocasionar un deterioro irreversible. Un software de interpretación automática de ECG sube a IIb en cuanto sus salidas orientan una decisión de consecuencias graves.
El paso de la clase I a IIa o IIb cambia la naturaleza del proceso: documentación técnica completa, evaluación clínica sustancial, ciclo de vida del software según IEC 62304, plan de PMS y PMCF, y evaluación por un organismo notificado. El editor que sube de clase descubre al mismo tiempo la ISO 13485 y debe auditar su SGC ISO 13485. Sus software, ahora clasificados como productos sanitarios, quedan además sometidos a la identificación única y registro en EUDAMED, incluso en distribución desmaterializada. El editor no rellena más formularios. Cambia de oficio regulatorio.
MDCG 2019-11 Rev.1: la revisión de junio de 2025 vuelve a repartir las cartas
La guía de referencia sobre la calificación y la clasificación de los software, MDCG 2019-11, fue revisada el 17 de junio de 2025. No es un simple retoque. Cuatro aportaciones conciernen directamente a los editores.
El fin del «standalone software». La revisión abandona la noción de software autónomo en favor de un enfoque por función: lo que cuenta es la finalidad prevista de cada funcionalidad, no el soporte que la aloja. El término europeo es MDSW (Medical Device Software). SaMD sigue siendo el vocabulario IMDRF utilizado al otro lado del Atlántico, pero un expediente europeo que razona en términos de MDSW habla el idioma de su evaluador.
El enfoque modular. Un software puede dividirse en módulos, unos con finalidad médica y otros no. Cada módulo médico debe tener una finalidad prevista definida y documentada, y el editor debe demostrar que los módulos no médicos no comprometen ni la seguridad ni el funcionamiento de los módulos médicos. La frontera se traza por escrito, en la documentación técnica.
La aparición del término MDAI. La revisión nombra por primera vez los software médicos con inteligencia artificial (Medical Device AI), subconjunto de los MDSW sometidos en paralelo al Reglamento de IA. Los editores de algoritmos de aprendizaje tienen ahora dos textos que cruzar, no uno.
La finalidad prevista como piedra angular. La revisión insiste en la exigencia de una finalidad prevista precisa, inequívoca, alineada con los datos de validación y con las alegaciones públicas del editor, sitio web y fichas de tiendas de aplicaciones incluidos. Una clasificación se construye sobre esa finalidad escrita. Una finalidad difusa produce una clasificación indefendible.
La guía distingue además los software que crean o modifican información médica de aquellos que se limitan a mostrarla o almacenarla. Un algoritmo que procesa datos para deducir de ellos un resultado clínico está en la primera categoría. Un portal que muestra resultados de laboratorio sin tratamiento está en la segunda, y la pregunta que hay que hacerle es primero la de la calificación, antes que la de la clase.
Lo que implica para un editor en 2026
Un editor que clasificó su software antes de junio de 2025 construyó su razonamiento sobre la versión de 2019 de la guía. Esa versión ha quedado sustituida. Las hipótesis de calificación de los módulos, los casos límite, los software de prevención: son otros tantos puntos que la Rev.1 resuelve de forma diferente o más fina. Una clasificación en clase I decidida en 2022 merece una relectura con el texto de 2025 sobre la mesa, sobre todo si el software incorpora funciones de apoyo a la decisión añadidas a lo largo de las versiones.
El escenario que sale caro es siempre el mismo: un software clasificado como clase I en su lanzamiento, enriquecido funcionalidad a funcionalidad, cuya finalidad real se ha deslizado hacia el apoyo a la decisión sin que la clasificación lo siguiera. El día en que un organismo notificado o una autoridad competente plantea la pregunta, la respuesta se construye con urgencia, con un historial de versiones en contra.
Releer la propia clasificación con la Rev.1 cuesta media jornada estructurada. Descubrirla obsoleta en una auditoría cuesta una revisión integral bajo presión. El buen momento para revisar de nuevo la clasificación de su software es el que usted elige, no el que le impone un auditor.
Fuentes reglamentarias: