Desde la perspectiva de un organismo notificado: Lo que los fabricantes realmente necesitan saber sobre la clasificación, las pruebas clínicas y la evaluación de la conformidad

La pregunta parece sencilla, pero es crucial desde el punto de vista normativo: ¿Es mi software un producto sanitario? Y si es así, ¿cómo se clasifica y certifica? Según el Reglamento de Productos Sanitarios (MDR) de la UE, esto depende totalmente de la finalidad prevista. El software puede ser un producto sanitario independiente o controlar o influir en el uso de otro producto sanitario. Aquí es precisamente donde comienza el marco normativo para la clasificación, las pruebas clínicas y la evaluación de la conformidad.

Características especiales del software

El software difiere de los productos sanitarios tradicionales en un aspecto clave: cambia rápidamente. Versiones, parches, entornos en la nube, interfaces, funciones de IA y riesgos de ciberseguridad son partes naturales de su ciclo de vida. El MDR tiene esto en cuenta. Para los programas informáticos, el anexo I exige, entre otras cosas, un enfoque vanguardista del ciclo de vida del desarrollo, la gestión de riesgos, la verificación y la validación, así como requisitos mínimos para el hardware, las redes informáticas y la protección contra el acceso no autorizado. Así pues, la ciberseguridad no es una cuestión secundaria de TI, sino que forma parte de la seguridad y el rendimiento del producto.

Especialmente en el caso del software, lo importante no es el código, sino la finalidad médica. Una aplicación de bienestar no se considera software médico simplemente porque sea técnicamente compleja. Por el contrario, una aplicación aparentemente sencilla puede perfectamente entrar en el ámbito del MDR si su información se utiliza para tomar decisiones diagnósticas o terapéuticas. Las actuales directrices del MDCG sobre la cualificación y clasificación del software aclaran precisamente esta distinción.

Requisitos del MDR: ¿dónde pueden encontrarse?

Cualquiera que desee comercializar software conforme al MDR debe leer detenidamente las secciones pertinentes del reglamento. Las secciones más importantes son:

El anexo I, que establece los requisitos generales de seguridad y rendimiento. En el caso del software, los requisitos relativos al proceso de desarrollo, la gestión de riesgos, la seguridad de la información, la validación y el entorno informático son especialmente relevantes aquí.

Los Anexos II y III regulan la documentación técnica, así como los requisitos para la vigilancia posterior a la comercialización. En el caso del software, esto también incluye pruebas de verificación y validación del software como parte de la documentación del producto.

El anexo VIII, en particular la regla 11, es fundamental para la clasificación del software médico. El MDCG 2019-11, revisado en 2025, explica los tres principios básicos de la Regla 11: software que proporciona información para decisiones diagnósticas o terapéuticas; software que monitoriza procesos fisiológicos; y "el resto de software". Dependiendo de la relevancia clínica, la clasificación puede ir de la Clase I a la Clase III.

El artículo 52 y los anexos IX a XI describen la evaluación de la conformidad. Para los productos de la clase I, la declaración de conformidad suele emitirla el propio fabricante; para los de la clase IIa y superiores, se requiere la intervención de un organismo notificado.

Por último,el anexo XIV es la referencia central para la evaluación clínica y el seguimiento clínico postcomercialización (SOCM). Especialmente en el caso de los programas informáticos, se trata de un ámbito que a menudo se establece sistemáticamente demasiado tarde.

Las normas más importantes para el software médico

El MDR especifica los requisitos reglamentarios. Sin embargo, en la aplicación práctica, algunas normas son especialmente importantes porque definen el "estado de la técnica".

La IEC 62304 es la norma básica para el ciclo de vida del software médico. Describe los procesos de desarrollo y mantenimiento de software cuando el propio software es un producto sanitario o una parte integrante de un producto sanitario.

ISO 14971 es la norma de referencia para la gestión de riesgos de los productos sanitarios, incluido explícitamente el software como producto sanitario.

ISO 13485 es la norma central de gestión de la calidad de los productos sanitarios a lo largo de todo el ciclo de vida del producto. Para los fabricantes que deseen establecer una organización sólida que cumpla la MDR, sirve como base operativa práctica.

La norma IEC 62366-1 trata de la ingeniería de usabilidad. Esto es especialmente relevante para el software, ya que un funcionamiento incorrecto, una orientación engañosa al usuario o unas alarmas poco claras pueden tener consecuencias inmediatas para la seguridad.

La norma IEC 82304-1 es especialmente pertinente para el software sanitario en plataformas informáticas generales, es decir, para productos sin hardware dedicado. La norma aborda la seguridad y la protección a nivel de producto y, por lo tanto, es de gran importancia para muchos productos de software autónomos o Software as a Medical Device (SaMD). Cabe destacar que la norma IEC 82304-1 define requisitos específicos para la validación de SaMD y se menciona simultáneamente en la norma IEC 62304, armonizada en el marco del MDR.

Clasificación: El primer paso crucial

La pregunta inicial más común e importante es: ¿a qué clase pertenece mi software? Es precisamente aquí donde muchos proyectos fracasan, no debido a la tecnología, sino debido a un propósito previsto poco claro. Según el MDCG 2019-11 Rev.1, la Regla 11 se aplica esencialmente en función de si el software proporciona información para decisiones diagnósticas o terapéuticas, supervisa procesos fisiológicos o entra en la categoría residual. Los ejemplos en la guía muestran que el software de diagnóstico o de apoyo terapéutico puede caer rápidamente en la Clase IIa, IIb o III, mientras que el "resto del software" es de Clase I.

Por tanto, desde la perspectiva de un organismo notificado, está claro: la clasificación no es un paso administrativo al final, sino la base de toda la estrategia de autorización de comercialización. Influye en el alcance de las pruebas clínicas, la profundidad de la documentación técnica, los requisitos de PMS/PMCF y, por supuesto, la cuestión de si un Organismo Notificado debe participar y en qué medida.

Datos clínicos: No funcionará sin pruebas clínicas

Para el software médico, la evidencia clínica no es opcional. El MDCG 2020-1 establece explícitamente que el software médico con su propio propósito y beneficio clínico reclamado requiere evidencia clínica como parte de su evaluación de conformidad. El objetivo es demostrar que el software es seguro, alcanza su rendimiento y proporciona el beneficio clínico declarado.

En la práctica, esto significa para el software: no basta con demostrar que el algoritmo funciona técnicamente. También hay que evaluar si el software proporciona la información correcta en un contexto clínico, cómo se utiliza esta información y si realmente produce un beneficio demostrable. La evaluación clínica no es un documento único, sino un proceso continuo.

Seguimiento clínico postcomercialización (SCPM)

A menudo se subestima el seguimiento clínico postcomercialización en el contexto de los programas informáticos. El MDR define el PMCF como un proceso continuo que actualiza la evaluación clínica y debe estar anclado en el plan PMS del fabricante. Esto es precisamente lo que describe explícitamente la plantilla de PMCF del MDCG.

El PMCF es especialmente importante para el software porque los contextos de uso, los sistemas operativos, las interfaces, las ciberamenazas y los patrones de uso clínico cambian constantemente. Por lo tanto, los fabricantes no sólo necesitan una estrategia de autorización de comercialización sólida, sino también un sistema robusto para recopilar y evaluar los datos de rendimiento y seguridad del mundo real después del lanzamiento al mercado y para retroalimentar esto en las mejoras del producto.

¿Cómo funciona el proceso de certificación desde la perspectiva de un organismo notificado?

El camino hacia la certificación puede resumirse en seis pasos clave.

Primero: El uso previsto debe definirse con precisión. Esta es la única forma de determinar claramente si el software entra dentro del ámbito de aplicación del MDR.

Segundo: el software debe estar correctamente clasificado, normalmente sobre la base del anexo VIII y la norma 11.

Tercero: La empresa necesita un sistema de gestión de calidad adecuado y un proceso de desarrollo verificable y de vanguardia, normalmente basado en las normas ISO 13485, IEC 62304, ISO 14971 y otras normas en función del producto.

Cuarto: La documentación técnica debe ser completa, estructurada y trazable, incluida la verificación y validación del software.

Quinto: La evaluación clínica, el PMS y el PMCF deben estructurarse adecuadamente para el producto.

Sexto: Si la clasificación requiere la participación de un Organismo Notificado, la evaluación formal de la conformidad sigue los procedimientos establecidos en el MDR.

Conclusión

Quien quiera comercializar con éxito un programa informático como producto sanitario necesita algo más que buenos desarrolladores y buenas ideas. Lo más importante es un uso previsto claro, la clasificación correcta, un proceso sólido de desarrollo y gestión de riesgos, pruebas clínicas y un sistema postcomercialización capaz de respaldar el PMCF. Ahí radica precisamente la diferencia entre un "producto sanitario digital" y un software médicamente viable.

Desde la perspectiva de un Organismo Notificado como DQS MED: Cuanto antes establezcan los fabricantes una estrategia reguladora clara, más eficiente será todo el proceso de certificación. El Dr. Andrei Ninu está especializado en dispositivos médicos activos, seguridad del software e IA en la atención sanitaria en DQS MED, donde dirige el Grupo de Operaciones de Software.

¿Estás desarrollando software médico o planeas obtener la certificación MDR para su aplicación?

Habla con los expertos de DQS MED acerca de la clasificación, las pruebas clínicas y los requisitos normativos, para conseguir un camino más eficaz hacia el éxito de la evaluación de la conformidad.

Co­n­tá­c­ta­nos
Autor

DQS Global

Loading...

Artículos y eventos relevantes

También podría interesarle esto
Blog
Loading...

Nuevo documento del MDCG sobre vigilancia posterior a la comercialización

Blog
Loading...

La Nueva Regla QMSR del FDA: Lo que los fabricantes de productos sanitarios deben saber y hacer

Blog
Loading...

¿Un OC puede certificar la ISO 9001 de un laboratorio?