IVDR y software IVD: cómo calificar y clasificar correctamente su software

Desde que el Reglamento (UE) 2017/746 (IVDR) entró en vigor en mayo de 2022, el mundo del diagnóstico in vitro (DIV) ha cambiado radicalmente. ¿Uno de los cambios más importantes? El papel ahora crucial de los organismos notificados: Se calcula que casi el 80% de los productos de DIV deben ser evaluados por un organismo notificado para obtener el etiquetado CE

En este contexto, el software utilizado en los DIV plantea muchas preguntas:

• ¿Está afectado todo el software?
• ¿Cuándo debe considerarse el software un producto sanitario IVD?
• ¿Qué errores deben evitarse para impedir que se bloquee la evaluación?

Este artículo resume estas preguntas basándose en el documento de posición publicado por Team-NB, la asociación europea de organismos notificados, el 17 de junio de 2025.

1. Información jurídica importante

Una mirada retrospectiva: antes del IVDR, la Directiva 98/79/CE preveía una participación relativamente limitada de los organismos notificados. El nuevo reglamento, en cambio, basa la clasificación de los productos en los riesgos asociados a su uso previsto, y los programas informáticos ocupan un lugar central en este proceso.

En 2019, elMDCG (Grupo de Coordinación de Dispositivos Médicos) publicó un documento de orientación(MDCG 2019-11) que aclara la calificación y clasificación del software tanto bajo el MDR como bajo el IVDR. Sin embargo, a muchos fabricantes todavía les resulta difícil aplicar estos textos a sus casos. Esta es la razón por la que el documento de posición del Equipo NB es tan útil: aclara lo que esperan los organismos notificados.

2. ¿Qué es el software IVD según el IVDR?

MDSW, o software de dispositivos médicos, es cualquier software destinado a un propósito médico, tal como se define en el IVDR:

• Independiente (por ejemplo, una aplicación de análisis NGS independiente).
• Integrado en un sistema (por ejemplo, el firmware de un analizador).
• Como módulo o accesorio.

Punto clave: algunos programas informáticos combinan módulos con una finalidad médica y otros no (por ejemplo, gestión de inventarios, archivado puro). Cada módulo debe estar claramente descrito y documentado.

3. 3 escenarios para cualificar su software

El documento de resumen ofrece un diagrama de flujo de decisiones claro que le ayudará a tomar la decisión correcta. He aquí una versión simplificada.

➊ Software que controla o influye en un dispositivo

Por ejemplo, firmware, módulo de control del motor. En este caso, el software se evalúa como parte integrante del sistema DIV. No se clasifica por separado.

➋ Software autónomo para DIV

Por ejemplo, aplicación NGS, software de análisis de imágenes para el cribado del cáncer. En este caso, el software es un DIV independiente. Debe clasificarse según su uso previsto y tener su propia documentación técnica.

➌ Software accesorio

Por ejemplo, middleware, conversor de formatos de imagen para análisis de IA. En este caso, el software no tiene una finalidad médica directa, sino que sirve de apoyo a un dispositivo de DIV. Se clasifica como accesorio y sigue estando sujeto a los requisitos del IVDR.

Nota: eluso previsto es el hilo

4. Ejemplos prácticos: ¿Qué aspecto tiene en la vida real?

Ejemplo 1

Software de análisis de secuencias NGS para la detección de anomalías genéticas hereditarias. Proporciona un resultado de diagnóstico directamente → IVD-MDSW independiente.

Ejemplo 2

Aplicación móvil que procesa datos de glucosa en sangre para generar alertas y ajustar las dosis de insulina. Finalidad diagnóstica o terapéutica → IVD-MDSW.

Ejemplo 3

Un módulo de middleware que convierte imágenes de portaobjetos de biopsias para su procesamiento mediante IA. No tiene una finalidad médica propia, pero permite el proceso → Accesorios.

5. Errores conceptuales que deben evitarse

• La suposición de que un software en la nube o un módulo de visualización está siempre fuera del ámbito de aplicación: Todo depende del uso previsto.
• Mezclar módulos médicos y no médicos sin límites claros: Documentar la separación.
• Olvidar que la clasificación de todo el sistema es decisiva: un módulo integrado debe seguir la clasificación del sistema.

6. FAQ - preguntas más frecuentes

¿Qué es el software no DIV?

Por ejemplo, LIMS, ERP, gestión de almacenes: sin procesamiento de datos con fines de diagnóstico → fuera del ámbito del IVDR.

Entra un LIMS en el ámbito de aplicación del IVDR?

No, a menos que una parte del sistema se utilice para la evaluación diagnóstica. Entonces este módulo debe calificarse como IVD-MDSW.

¿Qué ocurre con el software basado en la nube?

La ubicación no importa (nube, PC, móvil): sólo importa el uso previsto.

Mi software se vende por separado: ¿qué debo hacer?

Compruebe si está destinado a un uso independiente del DIV o como parte de un sistema. Esto determina el procedimiento de evaluación.

¿Puedo calificar un módulo como "no médico"?

Sí, pero debe demostrarse que no interactúa directamente con los datos de diagnóstico. Los límites y las interfaces deben estar claros.

7. Conclusión: la clave está en la finalidad prevista

Para evitar obstáculos en la revisión por parte del organismo notificado, siempre debe preguntarse: "¿Cuál es el uso previsto real?" Formúlelo con claridad, justifique sus decisiones y documente sus formularios. Y en caso de duda: no corra riesgos innecesarios.

Si no está seguro de cómo calificar o clasificar su software, CSDmed puede ayudarle a asegurar su ruta IVDR y evitar sorpresas de última hora durante la evaluación CE.

Póngase en contacto con nosotros para hablar de sus proyectos.

También puede interesarle este artículo: Nueva directriz 2025-4 del MDCG: Requisitos para aplicaciones de software de productos sanitarios en plataformas en línea