MDCG 2019-11 rev.1: Qué cambia la nueva versión para el software médico y de DIV

Desde 2019, la guía MDCG 2019-11 ha sido una referencia para los fabricantes de software de dispositivos médicos (MDSW) y software de diagnóstico in vitro (IVD MDSW). Pero en la práctica, la primera versión dejó muchas áreas grises: casos límite sin resolver, falta de claridad con respecto a los módulos de software e interpretaciones variables de la Regla 11

La versión revisada, publicada el 17 de junio de 2025, va mucho más allá de las actualizaciones cosméticas. Aporta importantes aclaraciones conceptuales y operativas, con especial hincapié en el concepto de finalidad prevista, las estructuras modulares de software y las interacciones con otras normativas, como la EHDS

Este artículo desglosa los principales cambios, esboza las implicaciones concretas para los fabricantes y ofrece escenarios prácticos para ayudarle a adaptar sus productos y documentación técnica

1. Recordatorio: ¿Qué cubre el MDCG 2019-11?

La orientación se centra en dos conceptos básicos

• Calificación: determinar si un producto de software cae bajo el MDR o IVDR y califica como un dispositivo médico o un accesorio
• Clasificación: asignar la clase de riesgo adecuada al software en función de su finalidad prevista (especialmente en virtud de la Regla 11 del MDR)

También aborda casos especiales

• Software que acciona o influye en un producto sanitario,
• Diferenciación entre MDSW y módulos no médicos,
• Software desplegado en la nube, en dispositivos móviles o integrado en hardware

La finalidad prevista es fundamental: determina la cualificación, la clasificación y los requisitos normativos aplicables

2. Qué cambia con la Revisión 1 (junio de 2025)

2.1 Aclaraciones introducidas

• Ampliación del ámbito de aplicación para incluir el software en el anexo XVI (productos sin finalidad médica, por ejemplo, dispositivos estéticos).
• Finalidadprevista: las directrices hacen hincapié en la necesidad de una declaración clara, precisa e inequívoca de la finalidad: cada función con finalidad médica debe justificarse clínicamente.
• Enfoque modular: El documento reconoce que el software puede dividirse en módulos. Algunos módulos pueden ser MDSW, otros no. El fabricante debe
• Definir claramente los límites funcionales,
• Documentar las interacciones,
• Demostrar que los módulos no médicos no comprometen la seguridad o el rendimiento de los módulos médicos.
• Interoperabilidad con sistemas de HCE: La guía incorpora los nuevos requisitos del Espacio Europeo de Datos Sanitarios (EHDS). Reclamar la interoperabilidad conlleva obligaciones adicionales

2.2 Nuevos ejemplos

• Casos de software destinado a tratar (sobre todo en salud mental, rehabilitación, trastornos alimentarios)
• Software terapéutico que utiliza realidad virtual o juegos interactivos
• Ejemplos en los que los módulos no médicos son esenciales para el funcionamiento pero quedan fuera del MDR/IVDR, siempre que los límites estén bien documentados
• Un ejemplo poco frecuente de software de clase I (aplicación de comunicación asistida para pacientes con autismo o parálisis cerebral)

2.3 Clasificación y Regla 11

El documento aclara las tres subreglas

• 11a: Software que proporciona información utilizada para tomar decisiones diagnósticas o terapéuticas
• 11b: Software para monitorizar procesos fisiológicos
• 11c: Todos los demás programas informáticos

También incluye una matriz útil basada en la gravedad de la situación clínica y el impacto del software en las decisiones médicas, en consonancia con el marco IMDRF

3. Escenarios prácticos: Lo que esto significa para usted

Caso 1 - Software modular de rehabilitación

Un desarrollador construye una plataforma de rehabilitación que incluye

• Un módulo terapéutico de realidad virtual (MDSW),
• Un módulo de seguimiento administrativo (no MDSW),
• Un módulo de seguimiento del compromiso del paciente

Lo que dice la Revisión 1

• Cada módulo debe evaluarse por separado
• El módulo terapéutico se clasifica en la norma 11
• Los módulos no terapéuticos deben documentarse y su interacción analizarse en el expediente técnico

Caso 2 - Software conectado a una HCE

Una herramienta de apoyo a la toma de decisiones se integra con un sistema HCE certificado

Lo que dice la Revisión 1

• Si el fabricante afirma la interoperabilidad, también se requiere el cumplimiento de la EHDS (especificaciones de interoperabilidad, documentación, ciberseguridad)
• La calificación MDR por sí sola ya no es suficiente: el marco normativo se convierte en dual

4. Preguntas más frecuentes (FAQ)

1. ¿Mi software sigue siendo de clase IIa si no he cambiado el algoritmo?

No necesariamente. Lo que importa es el impacto en las decisiones médicas. Incluso sin cambios técnicos, su posición reguladora puede evolucionar con las nuevas directrices

2. ¿Puedo declarar los módulos no médicos "fuera del ámbito de aplicación"?

Sí, pero sólo si puede justificar que no repercuten en la seguridad o el rendimiento de la MDSW

3. ¿Afecta el alojamiento en la nube a la clasificación de mi software?

No. La clasificación depende de la finalidad prevista, no de la implantación técnica. Dicho esto, pueden aplicarse requisitos adicionales (ciberseguridad, trazabilidad, disponibilidad). Véase también: Nueva Guía MDCG 2025-4: Requisitos para aplicaciones de software de productos sanitarios en plataformas en línea

4. ¿Qué ocurre si quiero conectar mi software a una HCE?

Tendrá que cumplir tanto la EHDS como la MDR/IVDR. Se requiere un expediente de interoperabilidad específico

5. Mi software se consideraba anteriormente no MDDS. ¿Debo recalificarlo?

Es posible. Los casos límite se abordan ahora de forma más clara y pueden considerarse MDSW

5. Qué deben hacer ahora los fabricantes

• Reevaluar la finalidad prevista con la alineación clínica
• Mapee su arquitectura de software: módulos, flujos de datos, interfaces
• Recalificar los módulos límite a la luz de los nuevos ejemplos
• Actualizar la documentación técnica: justificación de la clasificación, análisis de interfaces, conformidad con la EHDS si procede
• Reevaluar las estrategias de evaluación clínica y de rendimiento de cada módulo

6. Conclusión

No se trata sólo de una actualización menor: consolida el marco interpretativo, resuelve por fin algunas ambigüedades que existían desde hace tiempo (solicitudes de tratamiento, lógica modular, interoperabilidad) y refuerza la exigencia de una justificación sólida

Esto exigirá trabajo por parte de los fabricantes, pero también brinda una oportunidad: construir arquitecturas de software y expedientes técnicos más sólidos, claros y defendibles

¿Necesita apoyo estratégico?

En CSDmed, ayudamos a los fabricantes a

• Estructurar su finalidad y arquitectura de software,
• Clasificar el software según la lógica MDR/IVDR,
• Alinearse con los requisitos MDR, IVDR, AIA y EHDS sin complicar en exceso el desarrollo

¿Está desarrollando un producto de software sanitario? Empiece con la base adecuada. Hablemos.